原文链接 别再盲目堆 Agent 了！Anthropic 官方教你从简单做起

Anthropic 官方教程：别急着上 Agent，先把 Workflow 玩明白

最近，AI 圈有一个词被严重"通货膨胀"了——Agent。

打开任何一个 AI 产品的官网，不管是做客服的、写代码的、还是搞自动化的，清一色都在喊"我们是 Agent"。仿佛不贴上这个标签，就跟不上时代一样。

但说实话，很多所谓的"Agent"，本质上就是几个 API 调用串在一起，离真正的自主智能体还差十万八千里。

就在这个人人都在炒作 Agent 的当口，Anthropic（Claude 的母公司）发了一篇工程博客：《Building Effective Agents》。

这篇文章的核心观点，用一句话概括就是：

能用简单方案解决的问题，就别上复杂系统。

听起来像废话？但当你看到多少团队在为了"看起来酷"而堆砌复杂架构时，就会明白这句话有多珍贵。

今天，我就来拆解一下这篇文章的核心内容。

一、先搞清楚：Agent 和 Workflow 到底有什么区别？

在开始之前，我们得先把两个核心概念掰扯清楚：

• Workflow（工作流）：你提前编排好了 LLM 和工具的调用顺序，程序按既定路线走。你是导演，AI 是演员。
• Agent（智能体）：LLM 自己决定调用什么工具、按什么顺序执行。AI 既是演员，也是导演。

一个是"按剧本演"，一个是"即兴发挥"。

那什么时候该用哪个呢？

Anthropic 给出了一个非常务实的判断标准：

场景	推荐方案
任务流程确定，追求可预测性和一致性	Workflow
任务流程不确定，需要灵活决策	Agent
大多数日常任务	先别急，优化好单个 LLM 调用就够了

没错，很多时候你根本不需要 Agent，甚至不需要 Workflow——通过检索增强（RAG）和上下文示例优化一个 LLM 调用，就能解决问题。

二、关于框架：用还是不用？

市面上有很多 LLM 编排框架，比如 LangChain、LlamaIndex，还有 Anthropic 自家的 Claude Agent SDK、AWS 的 Strands Agents SDK 等等。

这些框架确实能帮你快速搭建原型，省去很多重复劳动。但 Anthropic 也直言不讳地指出了它们的问题：

1. 黑盒化严重：框架加了太多抽象层，你根本看不到发送给模型的真实 Prompt 和原始响应。
2. 调试困难：出了问题，你很难判断是框架的锅还是 Prompt 的锅。
3. 很容易让人陷入"为了用框架而用框架"的陷阱：框架提供了一堆花里胡哨的功能，诱惑你去构建复杂系统，但其实很多任务直接调 API 就能搞定。

所以 Anthropic 的建议是：

直接用 LLM 的原生 API。如果非要用框架，一定要搞懂它底层在干什么。

快速原型可以用框架，但上生产环境时，尽量减少抽象层。

三、五种 Workflow 模式，按需取用

好，接下来是干货部分。Anthropic 总结了五种常见的 Workflow 模式，从简单到复杂，覆盖了大多数实际场景。

模式一：Prompt 链（Chaining）

核心思想：把一个大任务拆成一串小任务，像手链一样串起来，一步一步执行。中间还可以加"检查站"（Gate），确保每一步的输出符合预期再往下走。

什么时候用：任务可以被清晰地分解为多个子任务时。

为什么有效：降低单次任务的复杂度，提升准确率。让 LLM 每次只专注做好一件小事。

举个例子：

• 先生成一份营销文案，再翻译成多国语言
• 先写文章大纲，确认大纲没问题后，再根据大纲扩写正文

模式二：路由（Routing）

核心思想：先对用户输入进行分类，然后导向不同的处理流程。

什么时候用：你有多个独立的任务类别，每个类别需要不同的处理逻辑。

为什么有效：职责分离。如果所有任务都挤在一个 Prompt 里，优化 A 任务可能会拖累 B 任务的表现。分开处理，各管各的。

举个例子：

• 客服系统：常见问题走 FAQ 流程，退款请求走退款流程，技术问题走技术支持流程
• 把简单任务路由给便宜的模型（如 Haiku），复杂任务路由给强力模型（如 Opus）——都是因为钱包兜不住啊

模式三：并行（Parallelization）

核心思想：让 LLM 同时处理多个任务，最后汇总结果。

这种模式有两种玩法：

• 任务分解：把一个任务拆成多个独立的子任务，并行处理
• 投票机制：同一个任务跑多次，得到多样化的输出，综合判断

什么时候用：任务可以并行加速，或者需要从多个角度审视同一个问题。

举个例子：

• 任务分解：一个模型处理用户请求，另一个模型审核内容是否合规，比让同一个模型"既当运动员又当裁判"要靠谱得多
• 投票：用多个 Prompt 从不同维度检查代码安全漏洞，提高检测覆盖率

模式四：编排者-工作者（Orchestrator-Workers）

核心思想：一个"老板" LLM 负责拆解任务、分配工作，多个"打工仔" LLM 负责执行具体任务，最后老板汇总结果。

什么时候用：你无法提前知道需要哪些子任务。

和并行模式的区别：并行模式的子任务是预先定义好的，编排者-工作者模式的子任务是动态生成的。

举个例子：

• 代码修改任务：你不知道需要改哪些文件、改多少，让编排者 LLM 先分析，再分配给工作者去执行
• 多源信息搜索：编排者决定搜索哪些来源，工作者分头执行，最后汇总

模式五：评估器-优化器（Evaluator-Optimizer）

核心思想：一个 LLM 负责生成结果，另一个 LLM 负责评估和反馈。如果不达标，就打回重做，循环往复，直到通过评估。

什么时候用：你有清晰的评估标准，并且迭代改进能带来实际价值。

举个例子：

• 文学翻译：第一次翻译可能有些细微之处没处理好，评估器指出问题，优化器再改一版
• 复杂搜索任务：可能需要多轮搜索才能获取全面信息，评估器决定是否需要继续

四、终于轮到真正的 Agent 了

聊完五种 Workflow，现在来说说真正的 Agent。

随着 LLM 在复杂推理、规划、工具调用、错误恢复等方面的能力日趋成熟，Agent 开始具备了进入生产环境的条件。

一个典型 Agent 的工作流程是这样的：

1. 用户给出指令
2. Agent 自主规划和执行任务
3. 执行过程中，根据环境反馈调整策略
4. 遇到问题时，向用户请求帮助
5. 任务完成或达到停止条件时结束

什么时候使用 Agent：

如果你无法为某个任务画出确定的流程图，并且愿意信任 AI 的自主判断，那就适合使用 Agent。

但这里有个重要提醒：

Agent 的自主性是有代价的——更高的成本、更多的 API 调用、以及错误可能层层累积的风险。

所以 Anthropic 建议：先在沙箱环境里充分测试，做好防护措施，再考虑上生产。

实际案例：

• SWE-bench 任务：根据任务描述，让 Agent 自主修改多个代码文件
• Claude Computer Use：让 Claude 像人一样操作电脑完成任务

五、这些模式不是教条，而是工具箱

Anthropic 特别强调：

这些模式不是必须遵循的流程，而是常见的设计参考。

你完全可以根据实际情况组合、变形、或者干脆不用。核心原则只有一条：

只有当增加复杂性确实能显著提升效果时，才值得引入。

六、结语：奥卡姆剃刀，永远不过时

读完 Anthropic 这篇文章，我最大的感受是：

在 AI 应用开发领域，奥卡姆剃刀原则依然是最高指导思想。

解决问题的关键，不在于你的系统有多复杂，而在于你是否构建了恰到好处的系统。

Anthropic 给出了三条核心原则：

1. 保持简洁：能简单就别复杂
2. 确保透明：让 Agent 的规划步骤清晰可见
3. 打磨接口：工具文档写清楚，测试做充分

最后，再强调一遍那个朴素但重要的道理：

从简单的 Prompt 开始。只有当简单方案无法满足需求时，再考虑引入多步骤的 Agentic 系统。

别为了 Agent 而 Agent。

原文链接：Building Effective Agents - Anthropic