构建高效的智能体：从简单可组合的模式出发

Building effective agents

• agents
• workflows
• tool-design
• agent-frameworks

⚠️ 原文已被更新过（见 frontmatter 中的 source_note）。本文讨论的是设计思路，具体框架和模型名可能已过时。

一句话总结#

做 LLM 应用别一上来就搞复杂智能体：先把单次调用做好，必要时用固定编排的“工作流”，只有在任务开放、步骤无法预知时才交给“智能体”自主决策，并且每加一层复杂度都要用效果证明它值得。

为什么重要#

• 它是整个工程博客的“总纲”。 后来的多智能体研究系统、长时任务 harness、评测、上下文工程等文章，都在沿用这篇定下的术语（工作流 / 智能体 / 增强型 LLM）和“简单优先”的立场。
• 给“智能体”一个可操作的定义。 业界对 agent 的说法很混乱，这篇用一个架构上的区分把问题讲清楚：流程由代码决定还是由模型决定。
• 提供了一套可复用的“模式词汇表”。 提示链、路由、并行化、编排者-工作者、评估者-优化者，几乎能覆盖大部分生产中的 LLM 编排需求，方便团队交流和选型。
• 把工具设计提升到与提示词同等的地位。 提出“智能体-计算机接口（ACI）”的概念，后续《Writing effective tools for agents》一文正是对此的展开。
• 对框架保持警惕。 提醒开发者框架的抽象层会掩盖真实的提示和响应，这对调试和成本控制都很关键。

核心概念（中英对照）#

方法 / 步骤#

1. 先回答：要不要做智能体？#

原文的立场非常明确：能简单就简单。笔者把它整理成一个三级阶梯：

1. 优化单次 LLM 调用：配合检索和上下文示例，很多应用到这一步就够了。
2. 工作流：任务定义清晰、步骤可以预先确定时使用，换来可预测性和一致性。
3. 智能体：任务开放、步骤数量无法预知、需要模型在大规模场景下灵活决策时才使用。

代价要算清楚：智能体系统通常是用更高的延迟和成本换取更好的任务表现；自主性还会带来更高成本和错误累积的风险。

2. 关于框架的态度#

• 原文列举了若干框架（Claude Agent SDK、AWS 的 Strands Agents SDK、图形化的 Rivet 与 Vellum），承认它们能简化调用模型、定义解析工具、串联调用等底层工作。
• 但抽象层会遮住底层的提示与响应，让调试变难，也容易诱使人加上不必要的复杂度。
• 建议：先直接用 LLM API，很多模式几行代码就能实现；如果用框架，务必搞懂它底层做了什么——对底层的错误假设是常见的出错来源。

3. 基础单元：增强型 LLM#

• 让 LLM 具备检索、工具、记忆能力，并且模型能主动使用（自己生成检索词、选工具、决定记住什么）。
• 两个实现重点：贴合具体用例定制这些能力；给 LLM 提供简单、文档清晰的接口。
• 原文提到 MCP（Model Context Protocol）是接入第三方工具生态的一种方式。

4. 五种工作流模式#

笔者提示：并行化和编排者-工作者“长得很像”，区分点只有一个——子任务是写死的还是模型临场决定的。

5. 智能体：本质是一个循环#

• 起点：用户下指令或与用户讨论清楚任务。
• 执行：智能体自行规划、行动；每一步都要从环境拿到真实反馈（工具结果、代码执行结果）来评估进展。
• 人类介入：可在检查点或遇到阻碍时停下来请人确认。
• 结束：任务完成即终止，也常设置最大迭代次数等停止条件。
• 实现上往往很简单——就是“LLM 根据环境反馈调用工具，循环往复”；因此工具集和工具文档的设计至关重要。
• 适用：开放式问题、步骤难以预估、无法写死路径，并且你对模型的决策有一定信任；适合在可信环境中扩展任务规模。
• 风险控制：在沙箱环境中充分测试，并配合合适的护栏（guardrails）。
• 原文自己的例子：解决 SWE-bench 任务的编码智能体；“computer use”参考实现。

6. 组合与定制#

这些模式不是教条，而是可以拼装的积木。成功的关键是测量效果、迭代实现，并且只在复杂度被证明能改善结果时才增加它。

7. 三条核心原则#

1. 简单（simplicity）：保持智能体设计简洁。
2. 透明（transparency）：显式展示智能体的规划步骤。
3. 精心打磨 ACI：充分的工具文档和测试。

框架适合快速起步，进入生产后不要犹豫去减少抽象层、用基础组件构建。

8. 附录要点（一）：两个落地领域#

原文认为智能体最有价值的任务通常同时具备：既要对话又要行动、成功标准清晰、能形成反馈回路、有有意义的人工监督。

• 客户支持：对话流程天然 + 需要查客户数据、订单、知识库 + 退款、改工单等动作可程序化 + 成功可按“问题是否解决”衡量。原文提到有公司按“成功解决次数”计费，体现了对效果的信心。
• 编码智能体：代码可以用自动化测试验证、可以用测试结果迭代、问题空间结构化、质量可客观衡量；但人工评审仍然关键，用来确认方案符合更大的系统要求。

9. 附录要点（二）：给工具做“提示工程”#

• 同一个动作可以有多种表达格式（例如改文件用 diff 还是整文件重写；结构化输出把代码放 Markdown 还是 JSON），对程序是等价的，但对 LLM 的难度差别很大：写 diff 需要预先知道改动行数，代码塞进 JSON 需要大量转义。
• 选格式的建议：
  • 给模型足够的 token 先“想一想”，避免把自己写进死胡同；
  • 格式尽量贴近模型在互联网文本里常见的样子；
  • 去掉格式负担，比如精确计数几千行、给代码做字符串转义。
• 做好 ACI 的方法：
  • 站在模型角度看：仅凭描述和参数，能否一眼看懂怎么用？好的工具定义通常包括示例用法、边界情况、输入格式要求，以及与其他工具的明确边界；
  • 像给团队新人写 docstring 一样改参数名和描述，相似工具多时尤其重要；
  • 用大量样例输入测试模型怎么用工具，观察错误并迭代；
  • 做防呆（poka-yoke）：调整参数设计，让模型更难犯错。
• 原文案例：做 SWE-bench 智能体时，团队花在优化工具上的时间比优化整体提示还多；模型在切换出根目录后使用相对路径容易出错，于是把工具改成必须使用绝对路径，问题随之消失。

图解#

图 1：智能体系统的分类——工作流 vs 智能体#

flowchart TB
    AS["智能体系统<br/>agentic systems"]
    AS --> WF["工作流 workflow<br/>代码预先决定执行路径"]
    AS --> AG["智能体 agent<br/>LLM 动态决定流程与工具"]

    WF --> WF1["✅ 可预测、一致"]
    WF --> WF2["适合：定义清晰、可拆解的任务"]
    AG --> AG1["✅ 灵活、可处理开放问题"]
    AG --> AG2["⚠️ 成本更高、错误可能累积"]
    AG --> AG3["适合：步骤无法预知、可信环境"]

    BB["基础单元：增强型 LLM<br/>augmented LLM<br/>（检索 + 工具 + 记忆）"]
    BB -.支撑.-> WF
    BB -.支撑.-> AG

图 2：复杂度阶梯——什么时候该往上走一级#

flowchart TD
    S([新需求]) --> L1["第 1 级：单次 LLM 调用<br/>+ 检索 + 上下文示例"]
    L1 --> Q1{"效果够了吗？<br/>（用评测衡量）"}
    Q1 -- 够了 --> DONE([停在这里，别加复杂度])
    Q1 -- 不够 --> Q2{"任务能否预先拆成<br/>固定步骤 / 固定类别？"}
    Q2 -- 能 --> L2["第 2 级：工作流<br/>提示链 / 路由 / 并行化<br/>编排者-工作者 / 评估者-优化者"]
    Q2 -- 不能，步骤无法预知 --> L3["第 3 级：智能体<br/>LLM + 工具 + 环境反馈循环"]
    L2 --> Q3{"复杂度是否带来<br/>可测量的提升？"}
    L3 --> Q3
    Q3 -- 是 --> KEEP([保留并持续迭代])
    Q3 -- 否 --> BACK([退回更简单的方案])

图 3：五种工作流模式一览#

flowchart LR
    subgraph P1["① 提示链 prompt chaining"]
        direction LR
        a1[输入] --> a2[LLM 1] --> g{gate<br/>程序检查}
        g -- 通过 --> a3[LLM 2] --> a4[LLM 3] --> a5[输出]
        g -- 不通过 --> a6[中止/分流]
    end

    subgraph P2["② 路由 routing"]
        direction LR
        b1[输入] --> r{LLM 路由器<br/>分类}
        r --> b2[专用流程 A]
        r --> b3[专用流程 B]
        r --> b4[专用流程 C]
    end

    subgraph P3["③ 并行化 parallelization"]
        direction LR
        c1[输入] --> c2[LLM 调用 1]
        c1 --> c3[LLM 调用 2]
        c1 --> c4[LLM 调用 3]
        c2 & c3 & c4 --> c5[程序汇总<br/>分段拼接 / 投票]
    end

flowchart LR
    subgraph P4["④ 编排者-工作者 orchestrator-workers"]
        direction LR
        d1[输入] --> o[编排者 LLM<br/>动态拆分任务]
        o -.按需生成.-> w1[工作者 1]
        o -.按需生成.-> w2[工作者 2]
        o -.按需生成.-> w3[工作者 N]
        w1 & w2 & w3 --> sy[编排者综合结果] --> d2[输出]
    end

    subgraph P5["⑤ 评估者-优化者 evaluator-optimizer"]
        direction LR
        e1[输入] --> gen[生成者 LLM]
        gen -- 方案 --> ev[评估者 LLM]
        ev -- 反馈 --> gen
        ev -- 达标 --> e2[输出]
    end

图解：编排者-工作者模式里，编排者 LLM 动态拆分任务并综合各工作者的结果；评估者-优化者模式里，生成者 LLM 出方案，评估者 LLM 给反馈，直到达标。

图 4：自主智能体的运行循环#

sequenceDiagram
    autonumber
    participant H as 人类用户
    participant A as 智能体（LLM）
    participant T as 工具 / 环境
    H->>A: 下达任务或讨论澄清需求
    A->>A: 规划下一步
    loop 直到完成或触发停止条件（如最大迭代次数）
        A->>T: 调用工具 / 执行代码
        T-->>A: 返回真实反馈（ground truth）
        A->>A: 评估进展，调整计划
        opt 到达检查点或遇到阻碍
            A->>H: 请求确认或补充信息
            H-->>A: 反馈
        end
    end
    A-->>H: 交付结果

关键原话#

“They are typically just LLMs using tools based on environmental feedback in a loop.” —— 智能体通常不过就是：LLM 根据环境反馈、在循环中调用工具。

“you should consider adding complexity only when it demonstrably improves outcomes.” —— 只有当复杂度能被证明改善结果时，才考虑增加它。

实践建议#

选型 checklist

• 先做一个只用单次调用（+检索/示例）的基线，并配套一个最小评测集；没有基线就无法判断后续复杂度是否值得。
• 能用固定步骤描述的任务，优先用工作流；把“子任务是否可预知”作为选择并行化还是编排者-工作者的判断标准。
• 上智能体之前，确认三件事：环境是否可信 / 可沙箱化；有没有清晰的完成标准；有没有停止条件和人工检查点。
• 使用框架时，至少能打印出每一次实际发给模型的完整提示和收到的原始响应。

工具（ACI）checklist

• 让一位没参与开发的同事只看工具描述去用它，卡住的地方就是模型也会卡住的地方。
• 工具描述里写清：用途、示例、边界情况、输入格式、与相似工具的区别。
• 尽量消除格式负担（转义、行数计数），优先选模型“见得多”的格式。
• 用参数设计防呆，例如强制绝对路径、用枚举代替自由文本。
• 跑一批样例输入，统计模型用错工具的类型，针对性改名、改描述、改参数。

笔者补充（非原文观点）

• 把这篇的五种模式当作“画架构图的词汇”，在设计评审时先说清系统属于哪种模式（或哪几种的组合），能显著减少沟通成本。
• 原文发表于 2024 年底，后续 Anthropic 在长时任务和托管智能体方面的文章（见下方延伸阅读）对“harness 应该做多少事”有新的反思，建议对照阅读。

延伸阅读#

站内笔记（按推荐顺序）

• 第 2 篇：上下文工程 — 把“增强型 LLM”的上下文管理讲深。
• 第 3 篇：为智能体编写高效工具 — 本文附录 2（ACI）的系统展开。
• 第 12 篇：SWE-bench Verified 与 Claude 3.5 Sonnet — 本文多次提到的编码智能体案例。
• 第 16 篇：多智能体研究系统 — 编排者-工作者模式的生产级实现。
• 第 20 篇：Managed Agents — 原文顶部注释推荐的“当前做法”。

原文中引用的官方资源

• 基础工作流模式 cookbook
• Claude Agent SDK 文档
• Managed Agents 文档
• Model Context Protocol 介绍
• Computer use 参考实现

本笔记依据 2026-10-17 抓取的在线原文撰写。原文：Anthropic,《Building effective agents》。