Agent 是怎么被组织起来的：六种编排方式与选择

上一篇《Agent 为什么会反复调用 LLM：Loop、停止条件与 Outcome》讲完了单 Agent 的执行闭环：Runtime 调用 LLM，模型决定是否使用工具，Runtime 执行工具并回填结果，直到生成 Outcome。

但真实研发任务通常不只需要一个 Agent。

例如完成"新增数据导出功能"，可能需要：

• 产品 Agent 明确范围和验收标准；
• 研发 Agent 分析代码、实现和自测；
• 测试 Agent 独立验证；
• 监工 Agent 检查权限、风险和最终结果。

这些角色谁先开始、失败后回到谁、什么时候询问用户，就是 Agent 编排要解决的问题。

Agent 编排不是让多个模型同时说话，而是决定在什么状态下，由哪个 Agent，拿着哪些上下文，完成什么任务，之后流转到哪里。

一、Agent、Harness 与编排分别负责什么

先分清三个层次。

Agent：专业角色

Agent 定义"谁擅长干什么"，包括角色职责、System Prompt、模型、工具、Skill 和行为边界。例如 product_lead 负责需求，development_lead 负责开发，test_lead 负责验证。

Agent 是角色定义，真正干活的是本次任务中创建出来的 Agent 实例。

Harness：执行底座

Harness 负责组装上下文、调用模型、执行工具、创建 Agent 实例、驱动 Agent Loop，并管理权限、会话和 Outcome。

编排：协作关系

编排决定：

先执行谁
→ 根据什么条件选择下一个 Agent
→ 传递哪些上下文
→ 失败后重试、回退还是询问用户
→ 什么条件代表整个任务完成

三者的关系是：

flowchart TD A[用户任务] --> B[编排层选择当前角色] B --> C[Harness 创建 Agent 实例] C --> D[Agent 使用 LLM 和工具完成子任务] D --> E[返回结果和状态] E --> B B -->|满足完成条件| F[最终 Outcome]

简单概括：

Agent：负责干什么
Harness：负责真正运行
编排：负责多个 Agent 怎么协作

二、编排时一定会调用模型吗

不一定，取决于谁来做路由决策。

固定路由：不需要调用模型

如果程序已经规定"新需求必须先交给产品 Agent"，Harness 可以直接按代码或配置创建 product_lead，这次编排决策不需要 LLM。

动态路由：需要调用模型

如果任务类型和下一步无法提前确定，Harness 会调用入口模型或主管模型做判断：

用户任务
→ Harness 调用入口模型
→ 模型读取编排规则并选择角色
→ Harness 创建对应 Agent
→ Agent 再调用自己的模型干活

所以一次多 Agent 任务通常会调用很多次模型：入口模型负责路由，各专业 Agent 调用自己的模型，监工还可能再次调用模型验收。

Harness 负责推动编排；具体路由既可以由固定程序决定，也可以调用模型决定。

三、六种常见编排方式

1. 说明式编排

说明式编排是在 System Prompt 或 AGENTS.md 中写清协作规则。

- 新需求先交给 product_lead 明确范围。
- 产品结论交给 development_lead 实现。
- 实现完成后必须交给 test_lead 验证。
- 测试失败时返回研发修复。

模型读取规则并判断下一步，Harness 负责创建和运行 Agent。

优点是简单、灵活、修改方便；缺点是依赖模型理解，相同任务不一定每次走完全相同的路线。

需要注意：

AGENTS.md 更像团队制度，不是写死的工作流引擎。

提示词可以要求"未经确认不要发布"，但真正的权限限制仍然要由 Harness 或工具落实。

2. 配置式编排

配置式编排把节点和流转写进 YAML、JSON 或 TOML，由运行时读取并执行。

start: product_review
nodes:
  product_review:
    agent: product_lead
    on_success: development
  development:
    agent: development_lead
    on_success: test
  test:
    agent: test_lead
    on_pass: completed
    on_fail: development

它比说明式更清晰，也方便调整节点顺序。缺点是需要配置执行器；条件太复杂时，配置本身也会变成一种编程语言。

配置是否属于强约束，取决于执行器是否真正校验节点、状态和权限，而不取决于文件是不是 YAML。

3. 代码式编排

代码式编排直接使用 Java、Python 等语言控制执行顺序。

ProductResult product = productLead.run(requirement);
if (product.requiresUserDecision()) {
    return Outcome.waitingForUser(product.question());
}
DevelopmentResult development = developmentLead.run(product);
TestResult test = testLead.run(development);
if (!test.passed()) {
    test = testLead.run(developmentLead.fix(test));
}
return test.passed() ? Outcome.completed(test) : Outcome.failed(test);

它的执行路径明确，可以测试，也容易控制超时、重试和权限。缺点是流程调整需要改代码，复杂后容易出现大量条件分支。

代码式适合流程稳定、合规要求高、需要精确验证的场景。

4. 图工作流编排

图工作流把 Agent 定义成节点，把流转条件定义成边，并维护一份共享状态。

flowchart TD A[产品定义] --> B{范围是否明确} B -->|否| C[询问用户] C --> A B -->|是| D[研发实现] D --> E[测试验证] E -->|代码问题| D E -->|需求歧义| A E -->|通过| F[Outcome]

共享状态通常记录当前节点、产品结论、研发证据、测试证据和重试次数。

它适合分支、循环和回退较多的任务。LangGraph 等框架采用的就是状态、节点和边的思路。

缺点是需要维护统一状态和节点数据契约，图太大后也会难以理解。

5. 动态主管编排

动态主管编排会设置一个 supervisor 或 router，根据当前任务和已有证据决定下一步找谁。

flowchart TD A[用户任务] --> B[supervisor] B -->|需求不清| C[product_lead] B -->|需要查代码| D[code_explorer] B -->|需要实现| E[development_lead] B -->|需要验证| F[test_lead] C --> B D --> B E --> B F --> B B -->|满足完成条件| G[Outcome]

主管模型只生成路由决定，Harness 仍然负责创建 Agent、传递上下文和等待结果。

它适合入口不确定、责任归属动态变化的任务。代价是增加模型调用和 Token 消耗，路由也存在一定不确定性。

因此关键权限、最大步数和停止条件仍然应该由程序控制。

6. 工作流引擎编排

跨小时、跨天或跨系统任务，可以把 Agent 当成 Temporal、Camunda、Flowable 等工作流引擎中的 Worker。

工作流引擎
→ 持久化状态、定时器、重试、人工审批和审计
→ 调用产品/研发/测试 Agent Worker
→ Agent Harness 完成节点内部的模型和工具循环

它可靠、可恢复，适合长流程和云端团队协作；但系统和运维成本更高，本地小任务使用它通常过重。

四、六种方式怎么选择

用同一个需求对比，六种方式的核心区别如下：

编排方式	谁决定下一步	约束程度	适合场景
说明式	主 Agent 根据规则判断	较弱	本地探索、规则经常变化
配置式	配置执行器	中等	节点稳定、希望快速调整
代码式	程序代码	强	路径明确、需要严格测试和权限控制
图工作流	状态图和条件边	强	分支、回退和循环较多
动态主管	主管模型实时判断	灵活	入口和责任归属不确定
工作流引擎	持久化流程实例	很强	长任务、跨系统、需要恢复和审计

它们并不互斥。真实系统经常组合使用：

说明式规则
负责角色职责和协作原则
        ↓
代码或图工作流
负责主路径、状态、重试和停止条件
        ↓
动态主管 Agent
负责局部不确定的路由判断
        ↓
Harness
负责创建 Agent、调用模型、执行工具和收集结果
        ↓
工作流引擎
负责长任务持久化、恢复和跨系统协作

系统不需要一开始就具备全部层次，应该从最小可用组合开始。

五、哪些东西不是完整编排

• Agent 列表只说明有哪些角色，没有执行顺序、状态和停止条件。
• Handoff 只表示一次 Agent 交接，没有定义完整生命周期。
• A2A 主要解决 Agent 发现能力、发送任务和返回结果，属于通信协议。
• Skill 约束一类任务的处理方法；顶层 Skill 可以形成轻量编排，但仍需要 Harness 执行。

六、本地研发 Agent 的推荐组合

本地需求开发不需要一开始就搭建完整的 LangGraph 或工作流平台。

可以先使用下面的组合：

各层职责如下：

• AGENTS.md：团队制度、协作原则和授权边界；
• Agent TOML：角色提示词、模型、推理强度和工具范围；
• Router/顶层 Skill：识别需求、Bug、线上问题等入口场景；
• Codex Harness：创建 Agent、调用模型和工具、等待并收集结果。

先让说明式规则和现有 Harness 跑起来，再把稳定、重复、容易出错的部分逐步下沉到配置、代码或状态图。

七、什么时候需要升级

可以按下面的顺序判断：

流程简单且经常变化
→ 先用说明式编排
节点稳定，只需要调整顺序
→ 增加配置式编排
权限、重试和异常必须精确控制
→ 使用代码式编排
分支、循环和回退已经难以阅读
→ 使用图工作流
入口任务无法预先分类
→ 局部增加动态主管
任务需要跨天、恢复、审计或跨系统
→ 接入工作流引擎

决定编排方式的不是 Agent 数量，而是路径是否稳定、状态是否需要持久化、失败是否需要恢复，以及权限是否必须强制控制。

总结

六种 Agent 编排方式可以概括为：

说明式：把协作原则写给模型
配置式：把节点和流转写进配置
代码式：由程序精确控制路径
图工作流：用状态和边表达分支循环
动态主管：让主管模型实时选择角色
工作流引擎：可靠运行长流程

对于本地研发场景，一个合适的起点是：

AGENTS.md 定义团队制度
+ Agent TOML 定义角色能力
+ Router/Skill 固化常用入口
+ Codex Harness 运行 Agent 实例

最后可以用一句话概括：

说明文件告诉 Agent 应该怎样协作，工作流决定任务实际怎样流转，Harness 负责把每一个 Agent 真正运行起来。

参考资料

• LangGraph Graph API：State、Node 与 Edge
• Temporal：Durable Execution
• Camunda：Process Orchestration
• Flowable：Process and Case Management