一个 Agent 还是多个 Agent：从任务结构决定分工

任务复杂，不一定意味着需要更多 Agent。关键在于工作能否拆成相对独立、可以分别检查的部分，以及合并结果需要花多少精力。

先把任务画成几个步骤。如果下一步必须等上一步的答案，顺序执行通常更清楚。如果不同部分可以同时推进，且各自都有明确产物，再考虑并行。

先判断有没有可独立完成的部分

工作情况	可以尝试的安排
修改一段文案，意见还在变化	一个 Agent 与人反复确认
比较三份公开资料，各自都有同一张提取表	分别提取，再统一比较
多人同时修改同一段代码	先明确文件和责任边界，必要时顺序处理
交付物已经完成，需要找遗漏	独立复核，提供产物与验收条件

安排多个角色之前，先确保它们接到的是不同任务。如果每个角色都在从头思考整个项目，最后常会得到几份互相重叠的方案。

给每个角色一份交付约定

明确它负责的问题、能够读取的材料、交付格式和完成条件。若任务之间有依赖，写出谁等谁；涉及共同文件，指定谁负责整合。

例如准备公开报告，可以让不同任务分别核实资料和检查数字，由一个负责人组织正文。核实者交付来源及不确定项，数字检查者交付计算过程，整合者才有机会判断它们是否一致。

计算人的协调成本

除了等待时间，还记录你花了多少时间解释背景、解决冲突和删除重复内容。多 Agent 方案如果更快地产生结果，却让人用更长时间收拾结果，就没有完成优化目标。

用一组相近任务比较单 Agent 与多 Agent 的总耗时、返工量和遗漏。样本很小时，把结果当作选择线索，不推广成所有工作的结论。

角色名称只是入口

产品经理、编辑、研究员等名称便于人理解职责，但不能证明系统具备相应能力。真正要检查的是它读到了哪些事实、允许做什么、怎样验收，以及错误由谁处理。

长期角色还需要持续的真实反馈。如果它没有稳定输入，也没有明确负责人使用结果，先设立一个常驻岗位可能只增加维护成本。

不同产品对 team、subagent 和会话的定义不同，具体能力以当前产品文档为准。本篇讨论的是任务安排方法，不把某一种工具的术语视为通用架构标准。