作者继八月 AI Native 实践后，记录从 Stage 7 迈向 Stage 8 的多 Agent 工作方式探索。核心实践包括：用「测试测试」验证测试有效性（借鉴变异测试）；要求 Agent 交代判断依据；采用 1+N 组织方式，由 Captain 统筹调度其他 Agent，并保护其上下文不陷入实现细节；用 logbook Kit（lbkit）串起需求到上线的完整交付流程，通过 Preflight 预演减少中途打断；让 Delivery 与 Verify 两种角色形成对抗，发现分歧。作者强调多 Agent 有成本需按任务规模挑选，目标是保护人的完整注意力与决策密度，认为对抗机制比单纯循环更重要。
文章系统阐述了 AI 产品中 router（路由）的设计方法。Router 是产品调度台，决定用户请求进入哪个能力模块、走什么流程、承担什么成本。作者强调意图边界应由产品能力而非用户 query 归纳决定，建议采用'两级意图 + 槽位'的分层结构。在实现上，推荐规则、小模型、大模型三层配合：规则处理确定性请求，小模型处理高频语义分类，大模型处理复杂混合意图。此外，文章讨论了路由迭代的关键指标（准确率、任务成功率、fallback 率、人工改派率等）以及 token、延时与准确率之间的平衡策略，如精简 prompt、结构化输出、安全前置和结果缓存。
文章介绍如何用 AI 搭建一个几乎自动运转的业务团队：将业务拆分为客户、线索、交付、报表、财务五个通道，每个通道在 Slack 独立频道中运行，配以一次性写好的固定上下文（岗位说明、可交付物、上报规则、不可逾越的限制）和一个持续积累的裁定文件。作者强调前三步不涉及 AI：分通道、写上下文、划定审批线（可逆操作自动执行，对外或涉及金钱的操作必须等待人工批准）。随后为每个通道编写具体任务简报，并设置定时调度，使各通道每天自动产出站会、报告和草案。作者用 AI 员工 Viktor 实测一天，亮点是其在数据缺失时拒绝编造、只输出有依据的结论。整个体系一个下午即可搭建，让个人经营者从执行任务转为每天两次审批队列。
