Agent任务编排：计划、工具选择与子Agent拆分完整指南

模型可以推理，但它不一定会自动把复杂目标组织成可执行过程。

“把这个项目做好”“研究一下这个行业”“解决所有测试问题”都是人类容易理解、机器却难以验收的目标。认知与编排原语要做的，就是把模糊目标变成有边界、有依赖、有状态、有完成条件的任务流程。

这一层不替代模型推理，而是决定模型在什么上下文中推理、看到哪些工具、先做什么、何时暂停，以及怎样证明已经完成。

一、任务目标和完成条件要分开

目标说明方向，完成条件说明终点。

例如：

目标：优化当前项目的启动速度。

这句话没有告诉 Agent 速度如何测量、不能改变什么、需要支持哪些环境。更可执行的定义是：

目标：减少当前项目的首次启动时间。

完成条件：
1. 记录修改前后的启动耗时；
2. 不改变公开 API 和业务功能；
3. 不删除现有测试；
4. 构建、类型检查和测试通过；
5. 输出修改文件、测量方法和剩余风险。

完成条件应该尽量依赖外部证据，而不是“模型觉得已经不错”。目标管理原语可以保存状态、截止条件和阻塞原因，让完成判断从一段自然语言变成可以审计的生命周期。

二、计划为什么要有状态

自然语言计划很容易漂移。下面这段话人能看懂，但系统无法稳定判断当前在哪一步：

先检查项目，然后修复问题，最后测试一下。

结构化计划至少需要步骤和状态：

[
  {"step": "检查项目结构和启动命令", "status": "completed"},
  {"step": "记录基线指标", "status": "completed"},
  {"step": "实施最小修改", "status": "in_progress"},
  {"step": "运行构建和测试", "status": "pending"},
  {"step": "整理 Diff 和剩余风险", "status": "pending"}
]

pending、in_progress 和 completed 的价值，不是让界面看起来像项目管理工具，而是为恢复、暂停和用户干预提供一个共同状态。任务中断后，Agent 可以从最后一个明确状态继续，而不是重新猜测已经做过什么。

三、计划不是越详细越好

计划有两个常见极端：太粗导致 Agent 不知道下一步，太细导致每个小动作都需要人工维护。

比较实用的拆分粒度是“每一步都有独立输入、输出和验证”。例如：

步骤 1：读取项目配置
输入：项目目录
输出：框架、入口、构建命令和未知项
验证：引用具体文件路径

步骤 2：记录构建基线
输入：构建命令
输出：耗时、错误、产物大小
验证：保存命令输出

步骤 3：实施一类修改
输入：步骤 1 和 2 的结果
输出：代码 Diff
验证：运行对应测试

如果一个步骤内部还包含完全不同的风险和回滚方式，就应该继续拆开；如果两个步骤总是一起执行、一起验证，则不必机械拆分。

四、工具选择是认知原语

工具描述会影响模型是否能选对工具。一个工具的名称、参数、返回结构和失败提示，都会进入模型的决策过程。

一个糟糕的工具接口可能是：

run_tool(input: string) -> string

它什么都能做，但模型不知道允许范围、失败方式和副作用。更好的工具描述应该明确：

run_tests(
    command: string,
    working_directory: string,
    timeout_seconds: integer
) -> {
    exit_code: integer,
    stdout_path: string,
    stderr_path: string,
    duration_ms: integer
}

结构化参数让模型更容易填写，结构化返回让它更容易判断下一步。工具还应该说明：是否修改文件、是否访问网络、是否产生副作用、是否可以安全重试。

五、工具太多时需要选择机制

如果每次都把全部工具完整描述给模型，会浪费上下文，也增加相似工具之间的选择困难。Tool Search、按需加载和工具分组可以把工具集合变成一个可检索目录。

可以按任务阶段划分：

探索阶段：文件读取、搜索、Git 状态
执行阶段：编辑、Shell、浏览器、API
验证阶段：测试、截图、日志、Diff
交付阶段：文档、提交、构建产物、发布

让 Agent 先找到“能解决当前问题的工具”，再加载完整参数，比把数十个工具同时放进上下文更容易控制。工具选择结果也应该可观察：用户需要知道它为什么选择浏览器、为什么调用某个外部连接器。

六、工作模式可以改变决策风格

同一个 Agent 在不同阶段不应该使用完全相同的行为模式：

规划模式

只读项目、澄清目标、列出方案和风险，不修改真实环境。

执行模式

按照已确认计划修改文件、运行命令和调用工具，遇到高风险动作暂停。

审查模式

独立查看 Diff、测试输出和完成条件，重点寻找遗漏和回归，而不是继续扩展功能。

诊断模式

优先收集证据、复现错误和缩小范围，不急着修改多个地方。

模式切换应该有明确触发条件，而不是让模型自行决定“现在我已经审查过了”。例如完成所有代码修改后自动进入审查模式，测试失败后进入诊断模式，发现需要用户授权时进入暂停状态。

七、子任务如何拆分

复杂任务适合拆成互相独立、输入输出明确的子任务：

主任务：完成一份技术选型报告。

子任务 A：收集官方文档和版本信息。
子任务 B：整理部署条件和维护成本。
子任务 C：设计三个实际测试场景。
子任务 D：检查事实、日期和引用。

主 Agent：统一合并、去重、处理冲突并完成最终交付。

拆分时要明确：

• 子任务之间是否有依赖；
• 哪些任务可以并行；
• 每个子 Agent 能看到哪些上下文；
• 子 Agent 能修改哪些文件；
• 结果用什么格式返回；
• 冲突由谁裁决。

多 Agent 并行不是简单地启动更多模型。没有责任归属和结果协议，最后只会得到几份互相矛盾的答案。

八、什么时候不能并行

以下任务通常不适合多个 Agent 同时修改：

• 同一个数据库的迁移；
• 同一个配置文件的发布；
• 互相依赖的代码重构；
• 对同一个线上资源的操作；
• 需要统一口径的最终文档。

这些任务可以并行分析，但执行和合并最好由一个明确的主流程负责。共享文件系统也不是天然的协作协议，多个 Agent 同时读写同一文件时仍然可能互相覆盖。

九、反思和独立复核

让同一个模型先做事再说“我检查过了”，不一定是真正的独立验证。更可靠的复核要使用外部证据，或让一个隔离的 Reviewer 按完成条件重新检查。

例如：

你现在是独立 Reviewer。
不要继续修改代码，也不要相信之前的完成结论。
只根据需求、Diff、测试输出和实际页面检查：
1. 每个完成条件是否有证据；
2. 是否引入功能回归；
3. 是否存在未处理的错误路径；
4. 是否有超出范围的修改；
5. 最终是否可以交付。
输出通过项、问题项和需要补充的证据。

反思提示可以帮助模型发现问题，但它不能代替测试、类型检查、浏览器验证和人工审查。把“反思”当成唯一质量保证，是把主观判断重新包装了一遍。

十、一个完整的编排状态机

可以把复杂任务表示成状态转移：

created
  |
  v
planning -----> blocked
  |
  v
awaiting_approval
  |
  v
executing ---> failed ---> retrying
  |                         |
  v                         v
verifying <-----------------+
  |
  +--> completed
  +--> needs_human_review

每个状态都应该定义进入条件、允许动作、退出条件和超时处理。例如 executing 可以调用工具，awaiting_approval 不能偷偷继续高风险动作，failed 需要保留错误证据，completed 需要完成审计而不是只依赖模型回复。

十一、编排层的验收清单

设计一个 Agent 任务编排器时，可以检查：

• 目标和完成条件是否分开保存；
• 计划是否能显示当前步骤和阻塞原因；
• 工具是否有结构化参数和结构化返回；
• 工具副作用和重试安全性是否明确；
• 子任务是否有输入、输出和责任归属；
• 用户能否中途调整方向或暂停任务；
• 审查是否有独立证据；
• 任务失败后能否从检查点恢复。

结论

认知与编排原语把模型的推理能力变成有结构的任务过程。目标、完成条件、计划、工具描述、工作模式、子任务路由和独立复核共同决定 Agent 是否能稳定推进复杂工作。

一个好的编排层不会替模型思考，而是减少模糊状态，让模型知道当前目标、可用工具、已经完成的工作和下一步的验收方式。对用户来说，它也提供了中途纠正和最终审查的入口。

参考资料

• Anthropic：Building Effective Agents，用于理解工作流拆分和 Agent 编排边界。
• Model Context Protocol Specification，用于理解工具和外部服务的结构化连接方式。