Building Effective Agents：从可组合工作流到自主 Agent

原始来源

Anthropic，2024-12-19：Building effective agents。

本页是原创学习导读，不含原文复刻；文章版权与完整内容以原始来源为准。

学完这一篇，你应该能做到什么

• 准确区分增强 LLM、workflow 和 agent，而不是把所有多步调用都叫 Agent。
• 解释 Prompt Chaining、Routing、Parallelization、Orchestrator–Workers 与 Evaluator–Optimizer 的控制流和适用条件。
• 针对一个真实产品任务，选择最小够用结构，并说明为什么还不需要更复杂的方案。
• 为自主 Agent 明确写出环境反馈、权限边界、最大步数、成功条件和人工检查点。
• 同时评估质量、成本、延迟、可诊断性和错误累积，而不是只比较“自动化程度”。

一句话抓住它

这篇文章给 Agent 工程建立了一条很实用的复杂度阶梯：先把单次增强 LLM 做好，再按任务结构组合固定 workflow；只有步骤确实无法预先写死、而且环境能持续提供真值时，才把过程控制权交给自主 Agent。

先分清三个层次

增强 LLM：所有结构的基础块

普通 LLM 调用只接收输入并生成输出；**augmented LLM（增强 LLM）**还可以使用检索、工具和记忆。例如，它可以检索产品规范、调用库存 API、读取品牌术语表，并决定哪些信息值得保留。

增强 LLM 仍不必是 Agent。开发者完全可以写死“先检索，再调用一次模型，最后校验 JSON”的路径。增强描述的是能力，workflow 和 agent 描述的是谁决定控制流。

Workflow：代码预先决定大部分路径

Workflow 中，模型和工具沿开发者定义的代码路径运行。模型可以在某一步生成内容或分类，但“下一步调用谁、结果交给谁、失败后去哪”大体由代码决定。它的优势是可预测、可测试、容易给每个边界写校验。

Agent：模型根据状态动态决定路径

Agent 中，模型读取当前任务和环境反馈，自主选择下一步、工具和子目标；循环持续到外部成功、需要人类判断、发生阻塞或触发停止上限。它的价值来自开放路径，也因此更容易产生高延迟、高成本和累积错误。

维度	单次增强 LLM	Workflow	Agent
谁决定步骤	开发者只安排一次主要调用	开发者预定义控制图	模型在运行时动态选择
适合任务	输入输出明确，一次推理可完成	能稳定拆成固定步骤或类别	步数和所需工具难以预知
反馈位置	通常在最终输出后	每个固定关口可校验	每轮都必须从环境取真值
停止方式	调用返回或校验失败	路径终点、分支失败或人工审批	成功条件、最大轮数、预算、阻塞或人工接管
主要风险	输出质量不足	上游错误沿链传播、路由错分	成本与错误随轮次累积，行为更难复现

“更自主”不是“更成熟”

自主性是用可预测性、成本和延迟换灵活性。固定问题如果已经能稳定解决，改造成 Agent 通常只会增加新的失败面。

用一个产品任务贯穿全部结构

后面统一使用一个例子：电商团队需要发布新品页面。输入包括供应商规格、品牌术语、目标市场和发布日期；输出包括合规的产品文案、英文与中文版本、CMS 草稿和预览验收结果。

这个任务可以很简单，也可以很开放。关键不是它叫“商品发布”，而是你怎样约束目标：

• 若只需根据规范写一段摘要，一次调用可能足够；
• 若必须按固定顺序提取事实、检查合规、写文案和翻译，适合 Prompt Chaining；
• 若不同品类有不同法规，适合 Routing；
• 若多个独立检查能同时做，适合 Parallelization；
• 若每个市场需要多少材料无法预知，可能需要 Orchestrator–Workers；
• 若文案可以按明确评分标准反复改进，适合 Evaluator–Optimizer；
• 若目标变成“自行完成新品上线，处理未知 CMS 错误并根据预览修复”，才接近 Agent。

flowchart TD
    T["新品发布目标"] --> B["增强 LLM：检索 + 工具 + 记忆"]
    B --> Q{"一次调用 + 校验够用？"}
    Q -->|"是"| O["直接输出"]
    Q -->|"否"| K{"路径能预先定义？"}
    K -->|"是"| W["选择固定 Workflow"]
    W --> C["Chaining"]
    W --> R["Routing"]
    W --> P["Parallelization"]
    W --> H["Orchestrator–Workers"]
    W --> E["Evaluator–Optimizer"]
    K -->|"否"| G{"环境反馈可靠且风险可控？"}
    G -->|"否"| M["缩小任务 / 增加人工决策"]
    G -->|"是"| A["自主 Agent 循环"]

五种 Workflow，核心差别是控制图

1. Prompt Chaining：固定流水线

机制：把任务拆成确定顺序，每个模型调用处理上一步输出。中间可以加入程序化 gate，未满足条件就停止或返回修复。

新品任务可以写成：

提取供应商规格
    → Schema 校验：必填字段完整吗？
    → 生成事实摘要
    → 合规检查：是否出现禁止宣称？
    → 写营销文案
    → 翻译并检查术语表
    → 创建 CMS 草稿

这里每一步更简单，代价是多次调用增加延迟，前一步遗漏的事实可能一路传播。好的 chaining 不是把一段提示机械拆成十段，而是让每个边界都能检查：例如规格不完整时停止，而不是让后续模型编造缺失参数。

适用条件：步骤稳定、顺序固定、每一步输入输出都能清楚定义。

2. Routing：先分类，再走专用路径

机制：路由器读取输入并输出类别，代码把任务送往对应的专用 prompt、模型或工具链。

新品可以先分成普通消费品、食品、医疗相关设备和高风险未知类。不同类别使用不同合规规则；低置信度或高风险类直接交给人工审核。

route = classify(product_spec)
if route.confidence < 0.85 or route.label == "high_risk_unknown":
    return request_human_review(route)
return run_specialized_workflow(route.label, product_spec)

路由的价值来自 separation of concerns：每条路径只处理相对同质的输入。最大风险是误分类——下游流程可能运行得很“成功”，却从一开始就采用错误规则。因此路由必须保留置信度、兜底路径和误分类评测。

适用条件：输入存在清晰类别，而且分类能达到所需可靠度。

3. Parallelization：同时处理独立部分，或多次独立判断

文章把并行分成两种：

1. Sectioning（分区）：把不同子任务同时执行。新品任务中，事实核对、品牌语气检查、SEO 建议和法规初筛可以并行，只要它们不依赖彼此尚未生成的结果。
2. Voting（投票）：让多个独立调用判断同一个问题，再按规则聚合。例如多个审查器分别标记潜在违规宣称，通过阈值平衡漏报和误报。

并行不会自动提高正确率。若子任务共享同一个错误输入，它们会一起错；若输出互相冲突，聚合器必须决定优先级。并行的停止条件不是“所有模型都说完了”这么简单，还包括超时、部分失败、最低响应数和冲突升级。

适用条件：子任务真正独立，或多视角的收益高于额外调用成本。

4. Orchestrator–Workers：运行时才决定子任务

机制：中央 orchestrator 先理解具体输入，再动态拆分任务、委派 workers，最后综合结果。它看起来像并行，但关键区别是：子任务不是开发者提前列好的，而是 orchestrator 根据这次输入产生的。

例如新品突然要同时进入三个市场。Orchestrator 发现：市场 A 需要电池运输说明，市场 B 需要本地尺寸表，市场 C 还缺图片替代文本，于是临时创建不同 worker。另一个产品可能只需要一个 worker。

需要显式维护的状态包括：任务 ID、子任务说明、依赖关系、worker 状态、证据来源、已完成结果和待合并冲突。若没有这些状态，最常见的问题是重复调查、漏掉子任务或综合时丢失关键证据。

适用条件：总体目标清楚，但子任务的数量和形状只有看到具体输入后才能确定。

5. Evaluator–Optimizer：有标准的反馈循环

机制：generator 生成候选结果，evaluator 根据明确标准给反馈，optimizer 再修改；循环到达通过阈值或迭代上限。

新品文案可以用以下标准评价：事实一致、无禁止宣称、品牌术语一致、标题长度合格、关键信息齐全。只有当反馈可以被明确表达、而且修改后能客观检查是否改善时，循环才有价值。

生成草稿 → 评估器输出逐项分数与可执行反馈
   ↑                         ↓
   └──── 未达阈值且仍有预算：定向修改 ────┘
                  达阈值 / 达迭代上限：停止

如果“好文案”没有可操作标准，评估器可能只是换一种口吻表达偏好；如果生成器与评估器共享同一盲点，它们会在错误方向上反复强化。必须限制轮数，并保存每轮分数与修改理由，判断迭代是否真的带来增益。

适用条件：成功标准清楚，人类反馈能改善结果，模型也能产生类似的有效反馈。

自主 Agent：控制权发生了什么变化

现在把目标改成：“在给定权限内完成新品页面上线；遇到信息缺失、CMS 错误或预览问题时自行处理，只在需要业务判断时询问人类。”开发者无法预写每个步骤：Agent 可能先查规格、发现字段缺失、询问供应商系统、生成草稿、打开预览、看到布局溢出、修改内容，再运行验收。

一个最小 Agent 循环包含：

state = initialize(goal, permissions, budget)
 
while not externally_verified(state):
    if state.steps >= MAX_STEPS or state.cost >= MAX_COST:
        return stop_with_checkpoint(state)
 
    action = llm_choose_action(state.current_context)
 
    if action.requires_ungranted_permission:
        return ask_human_for_authorization(action, state)
 
    observation = execute_in_environment(action)
    state.record(action, observation)
 
    if observation.is_blocked or action.requires_product_judgment:
        return ask_human_for_judgment(state)
 
return publish_verified_result(state)

Agent 必须持有的状态

• 目标状态：什么才算“上线完成”，哪些验收仍未通过；
• 世界状态：CMS 当前草稿、已用素材、预览 URL、工具返回和错误；
• 计划状态：当前子目标、待办、已放弃路线及原因；
• 权限状态：能读什么、能写什么、哪些动作必须审批；
• 资源状态：步数、token、费用和截止时间；
• 证据状态：每个完成声明对应哪条环境结果。

停止条件不是一句“任务完成”

可靠停止通常组合多种条件：

1. 外部成功条件：CMS 草稿存在、必填字段完整、预览检查通过，而不是模型口头声称完成。
2. 安全边界：真正发布、付款、删除或对外发送前需要授权。
3. 资源上限：最大轮数、成本、时长或重复动作次数。
4. 阻塞升级：缺少业务事实、权限或连续多次工具失败时交给人类。
5. 失败终止：留下当前状态、已验证事实和可恢复下一步，而不是静默结束。

一张表决定该用哪种结构

你观察到的任务结构	首选	不要升级的信号
一次调用加检索已达到验收	单次增强 LLM	只是为了“看起来像 Agent”
固定步骤能降低每一步难度	Prompt Chaining	步骤拆分后没有可校验边界
输入有稳定类别与专用处理	Routing	类别含糊、低置信度又无兜底
子任务独立或需要独立多视角	Parallelization	子任务强依赖、聚合规则不清
子任务数量随输入动态变化	Orchestrator–Workers	实际任务清单早已固定
有明确、可迭代改善的标准	Evaluator–Optimizer	评估只有主观改写，没有增益证据
路径开放且环境能持续验证	Agent	成功无法观测、权限过大、错误不可恢复

实际系统可以组合这些结构。例如先 Routing，把高风险产品交给人工；普通产品进入 Prompt Chaining；其中合规与 SEO 检查并行；文案使用最多两轮 Evaluator–Optimizer。组合时仍要为每一条边写输入输出契约，不能因为“框架支持”就默认连接正确。

这篇文章提供了什么证据

原文是 Anthropic 根据自身构建经验以及与多个行业团队合作总结的工程文章，不是随机对照实验，也没有用统一 benchmark 证明六种结构的全局排名。它提供的是：

• 一套从增强 LLM 到 workflow 再到 agent 的共同词汇；
• 生产实践中反复出现的控制流模式；
• 每种模式的适用条件、例子和工程警告；
• 客服与编码等适合 Agent 的原因：目标可对话、动作可通过工具执行、结果可反馈，并能保留人工监督。

正确的证据用法

可以把文章当作设计假设和评审清单，然后用自己的任务集验证。不能仅凭“官方文章推荐”就断言某个结构在你的数据、模型和风险条件下更好。

常见失败模式

1. 框架先行：先选多 Agent 框架，再寻找问题去填。结果是控制流被抽象层隐藏，调试只能看表面日志。
2. 链条过长：每一步都引入一次模型调用，却没有新的校验边界。延迟上升，错误仍照样传播。
3. 错误路由后一路成功：专用流程内部全通过，但类别一开始就错了。必须单独评测路由并保留拒绝路径。
4. 伪并行：子任务其实依赖同一中间结果，却被同时启动，最后只能重做。
5. Orchestrator 委派含糊：worker 不知道交付格式、证据要求和边界，综合器收到几份不可比较的回答。
6. 评估器循环自嗨：分数不断变化，但外部用户或规则没有改善。需要最大轮数和独立验收。
7. Agent 没有环境真值：模型只能阅读自己的上一步文本，于是“计划—声称成功—继续计划”形成封闭幻觉。
8. 高风险动作无审批：系统把生成草稿与真实发布视为同一种工具调用，扩大了错误后果。

历史贡献与今天的工程解释

2024 年文章的核心贡献

它没有发明所有模式，而是把当时生产实践中常见的简单结构整理成一张选择地图，并强调 workflow 与 agent 的架构区别。更重要的是，它反对用框架复杂度衡量系统先进程度，把评判标准重新放回任务表现和工程代价。

今天仍然值得保留的原则

• 从可测的最小系统开始，只有真实失败证据才证明需要升级复杂度。
• 先画控制流和反馈边，再选择框架；框架不能替你定义成功。
• Agent 每轮都必须接触环境真值，长期循环必须有资源上限和人工检查点。
• 工具说明、参数和错误反馈本身需要像提示词一样测试，这与 SWE-agent 的 ACI 观点一致。
• 用质量、成本、延迟、恢复时间和人工介入率共同评估结构。

不能机械照搬的部分

模型、SDK 和框架会变化，某个模式的最佳实现也会变化；文章中的客户经验不是普遍因果定律。特别是“简单优先”不等于永远拒绝复杂系统，而是要求复杂度有可观测收益。

与其他原典的连接

ReAct 给出思考、行动和观察的基本循环；AutoGen 展示多 Agent 会话怎样被编排；本文提供“什么时候值得使用这些结构”的工程地图。后面的 Context Engineering 与 Harness Engineering 则解释多轮系统怎样维护注意力和可验证环境。

自测：不要只会背模式名称

1. 为什么一个能调用检索和工具的 LLM 不一定是 Agent？
2. 对新品发布任务，Prompt Chaining 与 Orchestrator–Workers 的根本差别是什么？
3. 什么条件同时满足时，Evaluator–Optimizer 才值得使用？
4. 写出一个自主发布 Agent 的三个外部成功条件、两个停止上限和一个必须人工审批的动作。
5. 若一个固定 workflow 已达到 96% 验收通过率，你会要求什么证据才同意升级成 Agent？

答案与提示

1. 检索和工具是能力增强；Agent 的关键是模型在运行时动态控制过程。若代码已经预定调用顺序，它仍可以只是 workflow。
2. Chaining 的子步骤和顺序在运行前已知；Orchestrator–Workers 看到具体输入后才决定需要哪些子任务，并负责委派与综合。
3. 需要清楚评价标准、反馈能被生成器采取、重复迭代有可测增益，以及明确的通过阈值和迭代上限。
4. 示例：成功条件为必填字段完整、合规检查通过、预览无布局错误；上限为最多 20 步和固定费用；真正点击“公开发布”必须人工审批。
5. 应看到固定路径确实无法覆盖的一类真实任务、Agent 在代表性数据上带来的净收益，以及成本、延迟、回归、权限和恢复风险仍在可接受范围内。

上一篇：SWE-agent · 下一篇：Effective Context Engineering · 返回 里程碑原典目录