第 29 节 · 多 agent 协作：从「一个」到「一群」¶
一群 agent 怎么交接、怎么互相质疑、怎么不陷入礼貌的敷衍。这一节讲协作，也讲它的管理学底色。
一、从「一个员工」到「一家公司」¶
上一节算过一笔账：这台机器上定义了 49 个角色。
49 个角色，如果只是并排摆在那里，那不叫团队，叫花名册。花名册不会干活，关系图才会干。
先看这 49 个是怎么分域的。分法不是按"人"，是按"活"：量化那条线独占十个（数据、特征、回测、组合、风控、执行、合规、报表、基建、Alpha），内容线十几个，剩下的是治理与支撑——总经理、财务、法务、架构、项目管理、运维、提交、开源运营、夜班等，再挂一个个人域（生活教练、主厨、学习教练、考纲分析等）。
分完域，才轮到真正的问题：这些角色之间，活是怎么流过去的？
一家公司不是 49 个人，是 49 个人之间的那条关系图。关系图画不出来，49 个人就是 49 个各干各的孤岛。
对内容这条线来说，"关系图"有两条组织方式。第一条是分域——谁归谁管；第二条是分流——同一件活，怎么在角色之间一站一站往下传。这一节主要讲第二条，因为它是多 agent 协作里最容易翻车的地方。
图 A-29-1（待出）：49 个角色定义的分域图 —— 量化线、内容线、治理与支撑线、个人域四块，以及内容线内部的一站式流转
二、流水线不是直线，是按品类分叉的图¶
先给数：内容这条线的流水线，最短的一条 4 个阶段就收工，最长的一条要走 9 个阶段。
我一开始想的就是一条直线：选题 → 写作 → 审稿 → 发行，谁干完传给下一个。真做起来才发现，不同品类的活，阶段数根本不一样：
| 品类 | 阶段链 | 阶段数 |
|---|---|---|
| 技术文 | 选题 → 写作 → 配图 → 审稿 → 发行 | 5 |
| 小红书 | 选题 → 写作 → 审稿 → 发行 | 4 |
| 视频 | 选题 → 写作(脚本) → 视频 → 审稿 → 发行 | 5 |
| 短剧 | 选题 → 设定 → 结构 → 写作(剧本) → 视频 → 审稿 → 发行 | 7 |
| 网文 | 选题 → 设定 → 结构 → 写作 → 审稿 → 运营 → 发行 → 商务 → 复盘 | 9 |
它不是一条直线，是一张按品类分叉的有向图。
入口只有一个：主编 agent 先判品类，判完再按品类把活路由到对应的那条链上。跳过的阶段不触发——一篇技术文不会去走"设定"和"商务"，一部网文也不会跳过"结构"直接开写。
这件事像医院分诊：所有人从同一个门进来，但进了门之后，看内科的走内科的流程，看骨科的走骨科的流程。没人会要求所有病人都把全部科室走一遍。一条流水线能覆盖的只有一种活；一张分叉的图，才覆盖得了一个内容公司。
这里要留一句实话：分叉图是定义层的覆盖。五种品类的阶段链都写清楚了，但"九阶段全链"不是每条都真跑过——定义画得出，跑满是另一回事。
图 A-29-2（待出）：按品类分叉的流水线有向图 —— 单一入口（判品类），五条分支链长短不一，跳过的节点不触发
三、每个角色都带一条「不做什么」¶
角色卡谁都会写"做什么"。真正决定组织不出事的，是"不做什么"那一栏。
这条链上的九个角色，每一个都带了一条负向边界：
| 角色 | 做什么 | 不做什么 |
|---|---|---|
| 主编 | 判品类、定方向、画像、选题、路由 | 不陷入写作细节 |
| 设定师 | 世界观、人物、关系、风格 | 不自己写故事线 |
| 编剧 | 弧线、伏笔、爆点、节奏 | 不亲自写每一章 |
| 写手 | 文章/章节/笔记/脚本/剧本、文风 | 不改设定、不改故事线 |
| 审稿 | 结构/情绪/节奏/一致性、分级把关 | 不跳过审查直接发布 |
| 运营 | 转化、社群、留存、传播 | 不刷量、不追虚荣指标 |
| 发行 | 多平台发布 | 不改内容、不跳过发布检查 |
| 商务 | 会员、付费墙、产品化 | 不在平淡处卡付费墙 |
| 复盘 | 反馈、复盘、经验沉淀 | 不写流水账，要提取规则 |
"不做什么"不是谦虚，是防越权。
写手能写，但不能改设定。为什么？因为设定是上游的产出，写手一改，改的是别人已经签过字的地基，后面所有基于这份设定的活全跟着漂移，而且没人接得住。同理，审稿能拦稿，但不能自己下场重写——审稿一旦下场，它就既是运动员又是裁判，"通过"这个动作就失去意义了。
一个角色的边界，往往不是画在"我能覆盖什么"，而是画在"我绝对不能碰什么"。能做什么决定它有没有用，不做什么决定它会不会把别人搞乱。角色卡里那条"做什么 / 不做什么"的边界，其实是写给两拨人看的："做什么"写给干活的人自己，"不做什么"写给所有要跟它交接的人。
图 A-29-3（待出）：九张角色卡的解剖 —— 每张卡 = 职责（正） + 一条"不做什么"（负），负向边界才是防越权的那道墙
四、协作靠「交接单」和带轮次上限的走查门¶
角色分好了，活怎么从甲手上交到乙手上？
靠一张交接单。它不长，骨架固定，头部几行就把话说清：这份活从哪来、给谁、要什么。正文把下游要干的活编上顺序，每一条后面都挂一句可验收的完成信号——不是"做好了"，而是"冷启动能自动加载""回归测试不破""失败时给得出可操作指引"这种能被回头检查的东西。
关键在最后一句：关键交接单里往往带一条红线。红线写的是"这部分绝对不许碰"——比如"只设计不训练""零预算""不改 App 代码"。交接单传的不只是活，还有这条活不许越的界。
但交接会出错。上游以为说明白了，下游以为懂了，两边都"完成"了——这就是协作最怕的东西：礼貌的敷衍。每个 agent 都回一句"收到""已完成"，但没有任何人真的回头核对上一环。
防这个，靠的是带轮次上限的走查门。
走查门是一道关卡：上游交出东西，下游不是直接接手，而是先回头确认"这东西做得对不对"。全链条一共有五道这样的门——选题、设定、剧本、审稿、复盘。那些会把东西打回的门写死了上限：最多 2 轮。第一轮打回，改完再走一轮；第 2 轮还不过，不许再循环，直接上报给真人。
这里有个容易混的区分：走查不是质疑。走查是快速确认"做得对不对"，质疑是深度拷问"做得好不好"。前者是门，后者是手术。混在一起，要么门形同虚设，要么每道门都变成一场大会。门要便宜、要快，才能每道都真的走一遍；手术慢、贵，只能挑最要紧的地方动。这两件事混着做，最后多半是门被绕开、手术没人敢做。
一句话：走查门把"确认"从人情变成了流程。不过就是不过，最多两轮，再不过就升级给人——而不是靠下游不好意思说、上游不好意思问。
五、机制完备，但执行回路是短板¶
上面这套东西，听起来挺齐。但把它拿到真实的时间轴上看，会发现另一个问题。
先看制度的规模：一个多月里攒下的早会记录有 12 份——注意，不是"每日"，中间有整段的断档。这份记录的形式本身就带设计：按业务线分节独立呈报，不合并汇总。每条线一节，每节只写三样——线名 + 主理 + 昨日/今日/阻塞。总经理 agent 不把各线揉成一坨，决策者直接逐线看。
其中最硬的一条机制叫 Top3：每个早会最多三件事；每件事必须带两样东西——一个具名的 owner，一句可验收的完成信号；"推进中""已安排"这种话不许写进 Top3。下次早会第一件事，就是逐项对账上一次那三件；没闭环的必须说明原因并升级，不得静默顺延。阻塞超过两天，自动往上跳一级。（这套完整规则，是 9 月 10 日才定下、9 月 11 日起生效的。）
纸面上，这是一套相当完整的管理循环。
然后现实给了它一记耳光。
9 月 1 日定下的 Top3，到 9 月 10 日——三项全部未闭环。 那 9 天里，全仓的提交稀稀拉拉——其中六天一次提交都没有，有提交的日子也集中在个别的两三个时间点。
更要命的是它是怎么被发现的：不是靠什么监控告警，是靠 9 月 10 日那一天，有人真的回头翻了 9 月 1 日的记录，一项一项核对。那份记录里写下的结论我原样搬过来——这不是"上周的问题"，这是"早会决议没有执行回路"。
同一天，追加了一条"决议闭环节"的规矩。第二天它第一次运行，闭环率 2.5 / 3——三项里两项半闭环，唯一没闭环的那一项，卡在真人手上，不在 AI 手上。
机制完备，不等于执行闭环。 写下规则的那一天，和执行规则的那一天，中间隔着整整 9 天。这套协作系统，画得出全图，跑不满全图。短期里，它最薄的那一环从来不是"定义得够不够细"，而是"有没有人真的回头对账"。对账这件事没有技术含量，只有成本——它要的是一次真实的回头，而这一下省不掉。
六、为什么一个 AI System 需要一个协作层¶
回到全书那条链：Model → Small Model → Model Pool → Router → Context → Knowledge/Memory → Agent →（协作/交接）→ Harness/State。
一个模型解决"一次回答"。一个 agent 解决"一件活"。一群 agent 要解决的，是"活与活之间的接口"。
接口没说清，49 个角色就是 49 个孤岛——每个都能干，合起来什么都不成。这就是为什么 Agent 之后必须补上协作层：不是为了让 agent 更聪明，是为了让它们接得上。交接单定义接口（传什么、什么算完、哪里不许碰），走查门定义回退（错了怎么退、退几轮），对账清单定义谁来认账（谁签的字、什么时候回来看）。
而这一层最反直觉的地方在于——它的零件里没有一行是模型技术。交接单、走查门、对账清单，本质是管理学，不是算法。你可以在任何一家公司找到它们的血缘：岗位说明书的"不做什么"、评审会的轮次上限、晨会第一件事先对昨天的账。
到这里，协作层解决的是"活怎么传"。但它还没解决更难的那件事：传着传着，半路断了怎么办？ 一份交接单交出去，下游 agent 跑到一半崩了、会话断了、进程没了——前面那些环节白做吗？这就是下一个零件要回答的问题。
数据与出处¶
- 角色定义总表（49 个角色的分域与调用方式）
- 内容线协作流程定义（品类分叉的五条阶段链、九角色职责与"不做什么"、五道走查门与打回轮次上限、交接单与级联路由）
- 交接单实例（上游 → 下游：任务来源、任务摘要、验收标准、红线）
- 早会记录存量（12 份，含断档）与早晚会模板（按线分节呈报、Top3 提名格式、决议闭环节）
- 9 月 1 日与 9 月 10 日两份早会记录（9 月 1 日 Top3 到 9 月 10 日三项全部未闭环；9 天里 6 天零提交；"早会决议没有执行回路"的原话）
- 9 月 11 日一次对账清单（决议闭环节首次运行，闭环率 2.5 / 3）