第13章 一个项目里如何分工：人、Agent 与多个 Agent

当一件事需要几天时间、好几份资料和多轮修改时，单独的聊天窗口很快会变成“找不到上一版”的文件堆。项目可以把消息、文件和产物放在同一个上下文里，但它不是自动项目经理；Agent 也不会因为被加入项目就自动知道该做什么。

这一章以“虚构内容包练习”为主线：把一份选题说明和两段虚构素材整理成一份内部待确认内容包。我们先判断一个 Agent 是否足够，再决定是否需要第二个 Agent，最后用交接卡把责任、输入和下一步写清楚。重要边界是：官方当前说明中，Agent 不能直接 @ 其他 Agent，必须由人类成员派发任务。多 Agent 不是越多越好，而是要在收益大于交接成本时才值得使用。

先选择规模：对话、项目、一个 Agent 还是多个 Agent

可以先问四个问题：

选择	适合的情况	主要代价
普通对话	一次性问题，资料很少	背景不会长期沉淀
一个 Agent	一个清楚的任务、一个主要产物	复杂任务容易把多种责任混在一起
一个项目 + 一个 Agent	需要保留文件、消息和阶段产物	需要自己维护版本和交接
一个项目 + 多个 Agent	不同环节有不同规则，且能清楚交接	上下文传递、费用和错误定位更复杂

“多个 Agent”只有在角色真的不同的时候才有意义。资料整理和事实核查可以是两个角色；如果只是让两个 Agent 都写同一篇文章，通常会增加重复和合并成本。一个 Agent 先跑通低风险路径，往往比一开始组建复杂团队更容易发现问题。

主案例：虚构内容包练习

本章只使用下面的虚构资料：

选题说明（虚构）：准备一篇面向 AI 初学者的“如何把一次对话整理成可重复任务”短文。
素材摘录 A（虚构）：读者只会使用电脑，希望少看术语，步骤要能跟着做。
素材摘录 B（虚构）：文章不能承诺自动成功、涨粉或发布效果；事实和引用需要人工核对。
背景资料（虚构）：主题方向已讨论，作者署名、发布日期、发布平台和配图来源待确认。

最终产物不是已发布文章，而是包含标题候选、正文草稿、事实与来源、待核实项、版权/配图检查的“内部待确认内容包”。人负责选题方向、事实确认和交付决定；Agent 负责整理和起草，不负责批准或发布。

什么时候一个 Agent 已经足够

如果输入只有三段资料，输出只是一个有固定栏目且可人工核对的初稿，一个 Agent 可以依次完成“资料盘点—草稿—问题清单”。此时增加第二个 Agent，不一定能提高质量，因为人仍然要检查引用和状态。

只有出现以下信号，才考虑第二个 Agent：起草规则和核查规则明显不同；每次都要重复做事实/版权检查；不同角色可以使用清楚的交接格式；人有时间查看中间产物。若任务包含决策、发送、付款或公开发布，增加 Agent 不能替代责任人。

项目中的责任和交接

人、Agent 和产物之间要形成可追溯链条：

项目负责人：确定选题、受众、发布范围和最终状态。
资料整理 Agent：从虚构资料提取事实、受众、待确认项和来源线索。
起草 Agent：依据盘点结果生成内部初稿，不补写事实。
检查 Agent（可选）：只列出无来源、夸大承诺、版权和状态问题。

交接卡不需要复杂格式，但必须让下一角色知道自己拿到哪一版：

资料版本：{版本}
本次产出：{产物名称}
已确认：{有依据的内容}
待确认：{缺少来源或需要人决定的内容}
需要下一角色处理：{下一步}
责任人：{人工责任人}

这张卡解决的是“上下文交接”，不是让 Agent 自动接力。每次交接前，人要确认文件版本和允许处理的范围。

在 Coze 项目中操作

如果当前账号显示项目入口，可以创建一个只含虚构资料的“虚构内容包练习”项目，把选题说明和两段素材放入项目背景。再查看项目设置中可见的 Agent 列表；添加 Agent 不等于已经分配任务，仍需要人类成员明确指派。

第一轮先只用一个 Agent，输入：

请只完成资料盘点，不写文章。
输出：资料版本、已确认、待确认、来源线索和下一步。
只使用“虚构内容包练习”中的资料，不补写姓名、日期、平台或引用。

人工确认盘点后，再输入：

请根据刚才确认的资料盘点，生成内部内容初稿。
标题、正文和事实依据分开；没有来源的内容写“待确认”；不要发送、分享或公开发布。

若当前账号支持第二个 Agent，人类成员再 @ 检查 Agent：

请只检查上一份内容初稿，列出无来源事实、夸大承诺、版权/配图缺口和状态问题。
不要直接修改正文，不要 @ 其他 Agent，不要批准发布。

这三段操作展示了“人派发—Agent 产出—人检查”的路径。若当前账号没有多 Agent 入口，就在同一个 Agent 中分阶段输入三段 Prompt，并保留交接卡，结果仍可复现。

关键设置和协作成本

项目范围决定哪些消息、文件和产物会进入共同上下文；初学者只放虚构资料，避免把无关聊天混进来。Agent 成员列表决定谁可能被人派发任务，不代表它会自动读取所有项目文件。交接消息应引用版本，不要写“请用最新文件”让 Agent 自己猜。

多一个 Agent 就多一份调用和交接成本：可能重复总结、产生不同版本、消耗更多积分，也会让错误定位变难。对每个角色写“只负责什么”和“不负责什么”，比给所有 Agent 同一份万能说明更重要。

项目的价值不只是把资料放在一个文件夹里。它还提供了一个可以回看工作的边界：哪份资料属于本项目，哪条指令是在什么背景下提出的，哪个版本的产物交给了谁。初学者最容易忽略的是“背景一直在变”。如果今天把新素材直接丢进项目，却没有写版本号，下一次 Agent 可能把旧结论和新资料混在一起。每次新增资料时，建议在交接卡中补上资料名称、版本、加入时间和允许使用的范围；如果无法确认资料属于哪一版，就先标为待确认。

协作成本也不只体现在积分。人要阅读中间产物、比较差异、处理权限、决定是否继续；多个 Agent 还可能使用不同的工作说明。一个实用的判断方法是：先估计新增角色能省下多少人工检查，再估计交接、合并和返工所需的时间。若第二个 Agent 只是把同一段文字再说一遍，收益通常很小；若它负责一套不同且可复核的标准，例如只检查来源和权限，才可能值得加入。

交接时不要只传“请继续”。应把上一版的产物作为明确输入，并告诉下一角色哪些字段不能改。这样即使项目成员、账号权限或界面发生变化，人也能从交接卡恢复工作，而不是依赖某个 Agent 的隐含记忆。交接卡最好同时记录生成者和确认者：前者说明谁产生了内容，后者说明谁检查过内容；这两个身份不能混为一谈。

迁移案例：学习资料整理

把内容项目换成学习资料：一个 Agent 提取章节目标，第二个 Agent 检查练习题是否覆盖目标。若课程只有三页，单 Agent 足够；只有当“提取”和“检查”长期重复、标准不同，才考虑多 Agent。新增风险是 Agent 可能把教材版本差异当成知识错误，最终仍需学习者回到原资料确认。

失败排错：第二个 Agent 没拿到上一版产物

现象：检查 Agent 说没有看到初稿，或者引用了旧版本。

先检查：两个 Agent 是否在同一项目；人是否明确 @ 指派；交接卡是否写了版本和产物位置；当前成员是否有查看权限。不要让 Agent 自己猜“最新文件”。

修正：由人重新发送交接卡，只提供目标版本和必要资料；如果项目不支持多 Agent，就回退单 Agent 分阶段处理。不要为了让流程继续而复制所有历史文件。

恢复标准：下一角色能准确复述版本、已确认和待确认项，并知道自己的责任边界；最终仍由项目负责人决定是否进入交付。

责任归属的实际判断

如果资料 Agent 把素材中的推测写成事实，项目负责人负责决定是否退回；如果起草 Agent 漏了一个栏目，交接卡就应记录这个缺口；如果检查 Agent 把建议写成“已通过”，人仍不能据此批准发布。每个产物都要带“生成者”和“确认者”两个字段。Agent 可以生成，只有人能确认。

项目成员能否读取文件、添加自己的 Agent 或移除其他 Agent，可能受项目创建者和账号套餐影响。初学者不要先邀请真实成员测试；用虚构项目观察当前可见权限，并把不能确认的权限标为待实测。

没有多 Agent 入口时，仍可以把一个 Agent 当作三个阶段角色使用：第一轮资料盘点，第二轮起草，第三轮检查。每轮保留版本号和交接卡，回退路径依然可复现。

本章产物与验收

• 一张单 Agent/多 Agent 选择记录。
• 一张项目分工表和一份带版本的交接卡。
• 一份资料盘点或初稿，以及人确认的下一步。

验收时问：每个角色是否只有一个主要责任？交接是否依赖明确产物？是否由人类成员派发任务？是否保留了责任人和人工确认点？当前账号没有多 Agent 能力时，是否能用单 Agent 分阶段完成？

本章小结与下一步

可控协作不是 Agent 越多越好，而是让责任、输入、产物和下一步都能回看。下一章从不涉及敏感数据的提醒开始，理解即时任务、后台任务、Heartbeat 和定时任务的差异。

阅读第 14 章：定时与后台任务。