🤔 这个场景为什么需要Agent，而不是WorkFlow

Building effective agentshttps://www.anthropic.com/engineering/building-effective-agents

总结：任务可预测、流程更稳定、普通脚本可解决时，引入Agent反而会带来不确定性

当整个行业都在追逐 "全自主智能体" 的概念，争相堆砌复杂框架与多层抽象时，Anthropic 用一篇《Building Effective Agents》给业界浇了一盆冷静的水。基于与数十家企业客户的合作实践与内部研发经验，他们得出了一个反直觉却又符合工程常识的结论：最成功的 Agent 系统，往往不是用最复杂的框架搭建的，而是由最简单、可组合的模式逐步构建而成。

这篇文章与其说是技术教程，不如说是一份 AI 时代的工程哲学宣言。它提醒我们：在 LLM 应用开发中，复杂性从来不是能力的证明，而是需要审慎权衡的成本。

一、重新定义 Agent：控制权在哪里？

"Agent" 这个词在行业里早已被用得泛滥。有人说它是能长期自主运行的系统，有人说它是按预设流程执行的脚本。Anthropic 没有纠结于名词之争，而是提出了一个更本质的划分标准 ——控制权的归属。

他们将所有 "类 Agent 系统" 划分为两大范式：

• 工作流（Workflows）：控制权在代码手中。LLM 与工具的调用通过预定义的代码路径编排，每一步做什么、怎么做，都由开发者提前设定。
• 智能体（Agents）：控制权在模型手中。LLM 动态决定自身的执行流程与工具调用策略，自主掌控任务完成的路径与方式。

这个划分的价值在于，它跳出了 "是不是 Agent" 的语义辩论，直接指向系统设计的核心矛盾：你愿意把多少决策权交给大模型？

工作流像铁轨，列车必须沿着预设轨道前进，稳定、可预测、易于调试；智能体像自动驾驶汽车，可以根据路况自主选择路线，灵活、适应性强，但也伴随着不确定性与风险。没有绝对的优劣，只有场景的适配。

二、渐进式构建：从单次调用到自主智能体

Anthropic 给出了一条非常务实的构建路径 —— 不要一开始就想着做 "全能智能体"，而是从最简单的模块开始，按需逐步增加复杂度。整个演进路径可以分为三个层级。

第一层：基础构建块 —— 增强型 LLM

一切 Agent 系统的起点，都是一个被增强的大语言模型。所谓 "增强"，指的是为 LLM 配备三种基础能力：

• 检索（Retrieval）：从外部知识库获取信息
• 工具调用（Tools）：与外部系统交互的能力
• 记忆（Memory）：留存关键信息的机制

这就像给一个人配备了图书馆、工具箱和笔记本。不要小看这个基础单元 —— 大多数业务场景，一个做好了增强的单次 LLM 调用就足够解决问题。很多团队急于上框架、做编排，却连最基础的工具定义和检索质量都没做好。

第二层：五种经典工作流模式

当单次调用无法满足需求时，不要直接跳到全自主智能体，而是先考虑工作流。Anthropic 总结了五种经过生产验证的工作流模式，几乎覆盖了绝大多数复杂场景。

1. 提示链（Prompt Chaining）

将一个大任务拆解为连续的多个步骤，前一步的输出作为后一步的输入，中间可插入程序化的校验门控。比如写文章时，先列大纲、再审大纲、再写正文。这种模式用延迟换准确率，适合任务边界清晰、步骤可预见的场景。

2. 路由（Routing）

先对输入进行分类，再分发到专门的处理链路。客服系统是典型例子：退款请求走退款流程，技术问题走技术支持，简单问题用轻量模型，复杂问题用强力模型。分离关注点，让每个链路都能做到极致优化。

3. 并行化（Parallelization）

把任务拆成多个独立部分同时处理，最后聚合结果。又分为两种思路：

• 分段式：不同维度并行处理，比如一个生成回答，另一个并行做安全审查
• 投票式：同一任务多次运行，通过多数表决提高置信度，比如代码漏洞审查

4. 协调者 - 工作者（Orchestrator-Workers）

一个中央协调器 LLM 负责拆解任务、分派工作，多个工作者 LLM 并行执行，最后由协调器整合结果。与并行化不同的是，子任务不是预先定义的，而是由协调器动态生成。这种模式特别适合代码修改、多源调研这类无法预知工作量的任务。

5. 评估者 - 优化器（Evaluator-Optimizer）

生成与评估分离，形成闭环迭代。一个 LLM 负责产出初稿，另一个专门负责打分和提修改意见，反复迭代直到达标。文学翻译、复杂检索、高质量文案创作这类有明确评价标准、越打磨越好的任务，最适合这种模式。

第三层：自主智能体

当以上工作流都无法应对完全开放的问题时，才需要真正的智能体。

有趣的是，Anthropic 笔下的智能体架构异常简洁：本质上就是一个 LLM 在循环中根据环境反馈调用工具。没有复杂的状态机，没有多层记忆模块，核心就是 "感知 - 决策 - 行动" 的循环。

但简单不等于容易。智能体的真正难点不在于架构，而在于工具集的设计 —— 工具的边界是否清晰、文档是否完备、返回结果是否结构化，直接决定了智能体能否稳定工作。这也是为什么 Anthropic 专门用一个附录来讲 "工具的提示工程"。

智能体适合的场景非常明确：开放性问题、步骤不可预知、需要在沙盒环境中规模化执行的复杂任务。比如代码智能体解决真实的 GitHub Issue，或者 "计算机使用" 智能体直接操作终端与浏览器。

三、框架迷思：别让工具成为你的枷锁

如今 LangGraph、Bedrock Agents、Rivet、Vellum…… 各类 Agent 框架层出不穷，似乎不用个框架都不好意思说自己在做 Agent。

Anthropic 对此的态度非常清醒：框架能帮你快速起步，但也会制造抽象壁垒。当框架封装了太多底层细节，你就失去了对提示词、响应格式、调用链路的可见性，调试会变得异常困难。更糟糕的是，框架会诱使你过度设计 —— 本来几行代码能解决的问题，非要套上完整的 Agent 架构。

他们的建议很直接：从直接调用 API 开始。很多模式真的只需要几十行代码就能实现。如果确实需要框架，也请先搞懂它底层在做什么 —— 对框架机制的错误假设，是生产环境中最常见的故障来源。

这让人想起 Unix 的 KISS 原则。工具永远是手段，不是目的。真正的工程能力，体现在知道什么时候该用框架，什么时候该手写那几行代码。

四、两个被验证的落地方向

在文章附录中，Anthropic 特别提到了两个 Agent 价值最明确的领域 —— 客服与代码开发。它们有几个共同特征：天然的对话交互、目标清晰可衡量、存在有效的反馈闭环、可以引入人工监督兜底。

客服智能体是最自然的 Agent 形态。用户用自然语言描述问题，智能体调用工具查询订单、调取知识库、执行退款操作，最终以问题解决率作为核心指标。这个赛道已经跑通了按效果付费的商业模式。

代码智能体则是另一个极致场景。代码有明确的对错标准 —— 测试能不能通过。智能体写完代码、跑测试、根据报错修改、再跑测试，形成自闭环。SWE-bench 这类基准测试的快速进步，已经证明了这条路的可行性。当然，最终的代码质量与架构合理性，仍然离不开人的审核。

这两个场景的成功也暗示了一个规律：Agent 最容易落地的地方，不是完全无人的 "全自动"，而是人机协作的 "半自主"—— 机器负责执行与迭代，人负责目标设定与质量把关。

工程哲学的回归

读完这篇文章，最大的感受不是学到了什么新奇的架构，而是一种久违的工程常识的回归。

在 LLM 这个充满新概念的领域，我们太容易被 "自主"、"通用"、"革命性" 这样的词汇裹挟，陷入 "越复杂越先进" 的认知误区。但 Anthropic 用实践告诉我们：构建有效 Agent 的秘诀，从来不是堆砌更多组件，而是 ——

从简单开始，用数据证明复杂度的必要性；保持透明，让每一步决策都可追溯；精耕接口，让工具与模型的交互清晰可靠。

好的工程，从来不是把简单的事情做复杂，而是把复杂的事情，拆解成一个个简单可靠的模块，然后优雅地组合起来。

这或许就是 AI 应用开发从 "炼金术" 走向 "工程学" 的必经之路。