什么时候值得让多个 agent 一起做同一件事？
如果每个 agent 都能独立回答一个问题，无须等待其他人的结果，而且这些发现能汇总成一个决定，就值得考虑并行。建议先从调查或审查入手。对于同一个代码仓库里的一处小改动，我们通常建议先让一个 agent 完成修改，再安排一次范围明确的审查。
这些工作真的互不依赖吗？
先用一句话描述每项任务，例如梳理相关代码、检查现有测试、查明文档约束。每项都要有明确产出，比如文件位置和简短的发现清单。涉及同一批文件时，先要求调查，再决定是否让多个 agent 同时修改。
Codex 的 subagent 指南建议从以读取为主的工作开始，包括探索、测试、问题分诊和摘要。指南也提醒，并行改代码可能造成冲突，增加协调工作。判断是否并行，先看能否独立推进，不要只看任务大不大。
如果后一步必须等前一步的结果，就按顺序安排。可以参考一个助手的输出交给另一个助手时要检查什么。对于这样的依赖关系，应先约定上一阶段的验收条件，再启动下一项工作。
主对话应该保留什么？
把目标、约束和最终决定留在主对话中。将冗长的调查交给其他 agent，并要求它们返回附有依据的简短摘要。Claude Code 将 subagent 描述为同一会话中的受委派助手：在自己的上下文里处理支线任务，再把摘要交回来。
Codex 也介绍了把探索笔记、测试日志等中间输出移出主线程的做法。这样主 agent 可以把注意力放在需求与结果上。要求每个 agent 说明发现了什么、还有哪些疑点，以及哪些文件支持结论。
例如，测试审查可以返回缺少的用例及理由，无须贴出读过的每一个文件。输出应便于比较，而不是让接收者重新做一遍调查。
如何合并修改并收拢结果？
委派之前，先明确由谁整合成果。对于可能修改相同文件的任务，Claude Code 指南建议使用 worktree，为会话提供独立的代码检出目录。它的 agent team 不会通过 worktree 隔离各成员；指南建议给成员划分不同的文件范围。
第一次尝试时，可以让一个 agent 负责修改，其他 agent 只做范围明确的审查。要求主 agent 根据需求核对分歧、记录未解决的问题，并检查合并后的完整结果。几份摘要只是中间产物，还需要验收。
如何收拢两个工具的结果提供了交接思路。开始新一轮审查前，先明确结果放在哪里、需要什么证据，以及何时停止。
Octuo 适合放在哪里
把目标告诉 Octuo，它会把工作交给支持的工具和 agent，带上所需上下文，再把结果收拢回来。Octuo 支持多个 agent 的协同调度，也支持 subagent。
Octuo 跟进工作并向你汇报；想看时可以查看进度，需要你拍板的事项会进入 Attention。登录自己的账号和必须由你批准的敏感操作由你做主；其余能交给它的工作由 Octuo 处理。
对于小范围的仓库修改，我们仍建议先从一个 agent 加一次审查开始。是否增加参与者，应由工作本身的分工需要决定。
常见问题
增加 agent 一定能改善结果吗？ 不一定。两份官方指南都说明，并行 agent 会增加 token 用量。先划分独立任务，再判断返回的证据是否值得增加这部分工作。
每个 agent 都应该修改相同的文件吗？ 不建议一开始就这样安排。可以划分文件归属，或使用独立的代码检出目录，再由指定的主 agent 整合并检查结果。
委派请求应该写些什么？ 写清问题、边界、所需证据和输出格式。按照 Codex 指南的建议，还应说明主 agent 是否需要等所有结果返回后再继续。
来源
上述产品名称归各自所有者所有，我们与它们没有任何关联。