第 4 课 · 多智能体协作：从项目助理到任务小队（学员手册）

文件路径：/Users/apple/Documents/4.0 Sanyuan/2.4 环境公益"新"力量/course/part-04-scenario/README.md

时长 90 分钟　|　课后产出：多智能体协作图 + 交接协议 + 主场景验收测试

前置：完成第 1–3 课，手上有一个已跑通的项目助理（至少挂载 1 个技能 + 1 个知识库，并完成第 3 课 10 问诊断）。

一、这节课要解决什么

第 3 课解决的是：把技能和知识库装进一个统一入口，让项目助理能判断意图、检索资料、调用能力。

第 4 课解决的是另一个问题：当任务变长、风险变高、步骤变多时，一个项目助理不能再「一口气从头做到尾」。它需要拆成一支小队：有人分派任务，有人查资料，有人写初稿，有人做合规审核，有人决定什么时候必须停下来问人。

一句话：第 3 课讲「一个项目助理如何会办事」；第 4 课讲「多个智能体如何一起办成一件事」。

二、先分清三件事

判断是否需要多智能体，不看「听起来高级不高级」，只看四个信号：

1. 任务天然分角色：查资料、写作、审核、发布明显不是同一种判断。
2. 中间产物要传递：上一步输出会成为下一步输入，不能只靠聊天记忆。
3. 错误代价高：涉及隐私、对外承诺、资金申请、公开发布。
4. 需要复用团队经验：不同同事负责不同环节，希望 AI 也按这个协作方式工作。

不满足这些信号时，不要硬拆。单一项目助理 + 清晰工作流就够了。

三、四种多智能体协作模式

3.1 流水线协作：一步交给下一步

流水线协作适合步骤明确、前后依赖关系清晰的任务。整个任务被拆成若干连续环节，上一步的输出经过整理后交给下一步，直到形成最终成果。

例如，把活动素材转化为公众号草稿，可以拆成：

资料员搜集并核验事实
→ 结构员整理提纲和素材位置
→ 写作员生成初稿
→ 审核员检查事实、隐私和发布风险
→ 人工确认是否发布

每个智能体只负责一种主要判断。资料员不替写作员发挥，写作员不擅自补充缺失数据，审核员发现问题后也不直接重写全文，而是指出问题并退回对应环节。

这种模式适合报告撰写、案例整理、传播内容制作等具有稳定流程的任务。使用时要为每一步规定清楚：

• 接收哪些材料。
• 完成什么任务。
• 输出什么格式。
• 哪些内容不能自行判断。
• 出现什么情况必须停止或退回。

流水线的优势是过程稳定、责任清楚、便于检查；不足是灵活性较低。如果前面一步出现错误，问题可能沿着流程传递，因此每次交接都需要传递经过整理的任务包，而不是只依赖聊天记录。

3.2 主控分派：一个主控决定谁来处理

主控分派适合入口复杂、用户表达多样、任务类型较多的项目助理。用户只面对一个统一入口，由主控智能体判断任务属于哪一类，再交给相应的专责智能体处理。

例如，主控可以按照以下方式分派任务：

项目文书需求 → 文书智能体
历史案例查询 → 案例智能体
公众号或社交媒体内容 → 传播智能体
资料不足或意图不清 → 先向用户追问
涉及隐私、资金或公开承诺 → 转入审核与人工确认

主控智能体的核心职责是判断任务归属、拆分任务和控制边界，而不是亲自完成所有工作。它需要先识别用户的目标、已有材料、期望成果和风险等级，再决定由谁处理。

如果一个任务包含多个彼此独立的部分，主控还可以同时分派给多个专责智能体。例如，「调研三个同类项目并提出借鉴建议」，可以由三个调研智能体分别查找资料，再由汇总智能体比较异同、形成结论。这样可以缩短处理时间，也能避免一个智能体在大量资料之间来回切换。

如果某个子任务本身需要大量检索、分析或工具操作，主控也可以把它作为一个独立任务交出去。专责智能体完成后，需要把结论、依据、缺失信息和风险提示一起交回，由主控统一整合。

这种模式适合同时处理文书、案例、传播和综合问答的项目助理。使用时要特别注意：

• 主控只负责判断和协调，不要变成「什么都自己做」的万能智能体。
• 分派规则要明确，避免多个智能体重复处理同一任务。
• 并行任务必须采用统一的输出格式，方便后续汇总。
• 无法判断任务归属时，应先追问，不要强行猜测。
• 所有分支最终都要回到统一的审核或交付出口。

3.3 同伴互审：两个智能体互相挑错

同伴互审适合对准确性、完整性和表达质量要求较高的任务。一个智能体负责产出，另一个智能体站在审核者的角度，按照预先设定的清单检查问题。

例如：

写作智能体输出初稿
→ 审核智能体检查事实、格式、隐私、语气和缺失项
→ 输出问题清单及修改建议
→ 写作智能体只修改存在问题的部分
→ 审核智能体再次确认
→ 人工查看最终版与风险提示

审核智能体不应只给出「写得不好」「语气需要调整」这类笼统评价，而应明确指出：

• 问题出现在哪里。
• 属于事实、结构、表达还是风险问题。
• 判断依据是什么。
• 应该退回给哪个环节。
• 修改后需要满足什么标准。

例如，人数缺少来源，应退回资料核验环节；文章结构混乱，可以退回写作环节；出现真实姓名或未经确认的承诺，则应立即停止并进入人工审核。

同伴互审的价值不是让两个智能体反复重写全文，而是尽早发现问题并进行局部返工。为了避免无休止循环，可以预先规定审核清单、最多返工次数和最终升级条件。连续两轮仍无法解决的问题，应交给人工判断。

3.4 人机共审：高风险节点必须停下来

人机共审适合涉及隐私、资金申请、对外承诺、政策判断和公开发布等高风险任务。在这种模式中，AI 可以搜集材料、生成初稿、核对清单和提示风险，但不能代替人作出最终决定。

典型流程是：

AI 完成初步处理
→ AI 标记事实依据、缺失信息和风险项
→ 人工负责人检查关键内容
→ 人决定通过、退回修改或停止任务
→ 通过后才允许提交、发送或发布

以下情况应强制进入人工确认：

• 出现真实姓名、联系方式、精确地址或未授权照片。
• 涉及项目预算、资金用途、资助申请或合同内容。
• 涉及项目成果、合作承诺或机构正式立场。
• 知识库中没有可靠依据，但内容使用了确定性表述。
• 需要向外部人员发送邮件、提交材料或公开发布。
• 用户要求「直接发布」「不用审核」或「先编一个数字」。

AI 在交给人审核时，不应只提供一份看似完整的结果，还应同时提供资料来源、未确认信息、风险提示和建议处理方式。人的职责也不只是点击「同意」，而是对关键事实、公开口径和最终行动负责。

人机共审的核心原则是：AI 可以提高准备和检查效率，但高风险决策权、对外行动权和最终责任必须由人掌握。

这四种模式并不互相排斥。一个完整任务可以先由主控分派，再进入流水线处理，由同伴智能体互审，最后在公开发布前进入人工确认。

四、交接协议：多智能体能不能协作，关键看这一张表

多智能体最常见的失败不是「某个智能体不够聪明」，而是上游没有把任务交清楚。下游只拿到一段含糊聊天记录，就会重复劳动、漏掉事实、甚至接错方向。

每次交接，至少传这 8 项：

交接协议不是额外文书，它就是多智能体协作的「接口」。接口不清，协作一定乱。

五、课堂案例：青澜的公众号发布任务小队

学员跟读本章 + handbook.html 第四节。

5.1 17:20，收到一句「今晚发」

虚构机构「青澜环境政策研究中心」刚做完一场社区减塑活动。17:20，宣传同事在群里留言：

晚上 8 点前给我一版可发的公众号稿。
突出活动效果，照片从共享文件夹里选。

这不是一个干净的「写篇文章」任务。打开共享材料，你会同时看到：

先别开写。请先说出这个材料包里至少三个冲突。你应该能看到：时间要求与审核时间的冲突、三种人数口径的冲突、真名与公开发布的冲突、照片可用性与肖像授权的冲突。

课堂中的机构、人物和数据均为虚构。这些细节的作用是还原真实工作中的「多个文件各说一部分」，不是影射任何真实机构。

5.2 单一助理为什么会把冲突「拉平」

问题不在于模型是否聪明，而在于同一个上下文被同时赋予了三个互相拉扯的目标：

这就是单一智能体在长任务里常见的结构性问题：生成者、证据核验者和发布审校者是同一个角色。它不仅要辨认问题，还要推翻自己刚刚建立的叙事。

多挂一个「写公众号」技能不会自动解决这个问题。技能提升的是某一步怎么做；多智能体设计要解决的是谁有权做哪一种判断、什么时候必须停。

5.3 多智能体不是「多几个角色名」

5.4 拆成五个专责角色

可 Fork：env-ngo-wechat-research / env-ngo-wechat-template / env-ngo-wechat-humanize / env-ngo-wechat-publish + env-ngo-story-desensitize。

5.5 交接的不是「一段聊天」，而是可检查的任务包

【交接包：写作员 → 审核员】
任务目标：检查初稿 v1 能否进入人工发布确认
输入材料：初稿 v1；素材卡 v2；肖像与脱敏规则
已确认事实：活动日期、社区名称、三个活动环节（来自活动记录）
待确认项：实际到场居民人数；两张正脸照片的肖像授权
当前写法：正文暂不写人数；配图仅使用不可识别人物的环境图
输出格式：问题位置 / 规则依据 / 风险级别 / 退回给谁 / 是否可进人审
停止条件：出现无来源人数、真名或未授权正脸图 → 不得建议进入人审
下一步：有问题时指定退回对象；全部通过后交人工宣传负责人

关键不是每个字段都写得很长，而是对待确认项不装作已确认，并让审核员知道出问题时该退给谁。

5.6 协作链不是只往前跑：退回、拦截与人审

5.7 课堂收束：请说清「为什么拆」

1. 56、41 和「约 50」中，哪个可以直接写进正文？为什么？
2. 写作员明明看到群里说「约 50 人」，为什么仍无权把它改成已确认事实？
3. 审核发现只有语气问题，该退给谁？若是人数口径问题呢？
4. 审核员说「检查通过」后，这篇稿可以自动发布吗？

青澜这条链 = 样板库 M3 传播小队主路径。如果你的主场景是文书或案例沉淀，下一节会把同样的分工原理迁移过去。

5.8 场景型任务小队

多技能挂载后，要问清：谁调用哪个技能、中间产物怎么交、哪里必须人审。完整速查与角色卡见 场景型任务小队样板库。

纪律：只选一条主场景；周报→推文、节点↔FAQ 是传播变体。

选队后写下：

我的主场景走 _____ 小队；主控交给 _____ / _____ / _____；
人审点在 _____（具体触发条件，不要写「注意一下」）。

六、动手练习：把你的主场景拆成一支任务小队

先对照样板库，再自己拆。 完整速查表、三条深写小队（文书 / 案例沉淀 / 传播）、交接包示例与预制测试，见：

- 网页：场景型任务小队样板库

个人进度对照样板库速查表填写。本课公开材料只用脱敏场景类型。

6.1 选择一个主场景

不要同时拆三个场景。先选最希望同事稳定使用的一条链路：

台账→周报→推文、节点宣发↔FAQ 等变体，见样板库速查表，不必另开第三条主场景。

6.2 写角色卡

每个智能体只写 5 件事：

示例：

智能体名称：审核员智能体
只负责什么：检查公众号初稿是否可以进入人工发布确认
必读资料：脱敏规则、发布审校清单、素材卡来源
输出格式：问题清单 / 风险等级 / 是否建议进入人工发布
不能做什么：不能替机构做最终发布决定，不能删除事实来掩盖风险

6.3 写交接包

【交接包】
任务目标：
输入材料：
已确认事实：
不确定项：
输出格式：
风险标签：
停止条件：
下一步交给：

练习要求：任选两个相邻智能体，至少写出 1 份真实交接包。

6.4 标出共享状态

不是所有信息都要塞给每个智能体。按三类分清：

共享状态越清晰，越不容易出现「下游不知道上游已经确认过什么」或「敏感信息被不必要地扩散」。

七、协作验收测试

课堂最后用 5 条测试判断任务小队是否真的能工作。

记录表：

八、课堂时间分配

九、课后作业（分层）

下课带走一句话：「我的主场景由 _____ 主控，交给 _____ / _____ / _____ 处理，最后由 _____ 审核收口。」

十、给技术同学的框架对照

本课不要求写代码，但你会在主流多智能体框架里看到相同概念：

无代码平台也能练这些概念：用角色提示词、工作流节点、表格模板、人工审核点来模拟；有技术储备的机构后续再把它迁移到代码框架。

十一、交给第 5 课的发布候选包

第 5 课不再只看「项目助理能不能回答」，而要看这条协作链是否可以交给同事内测。

下课前，请填写：

• 第 4 → 第 5 课交接包：/Users/apple/Documents/4.0 Sanyuan/2.4 环境公益"新"力量/course/bridge-materials/templates/04_to_05_release_candidate_pack.md
• 课程产物跟踪表：/Users/apple/Documents/4.0 Sanyuan/2.4 环境公益"新"力量/course/bridge-materials/templates/cross_lesson_artifact_tracker.md

第 5 课会重点检查：主场景是否有清晰角色分工、交接包是否完整、人工审核点是否明确、5 条协作测试是否通过。

十二、下一课预告

多智能体协作图完成后，你已经知道「谁做什么、怎么交接、哪里必须人审」。第 5 课《成果盘点与预发布》会把这条链路变成可内测的发布候选：跑演示、分级缺陷、确定试用同事，并写好上线后的反馈写回规则。