在近期技术圈的热议中，“2025年将成为AI Agent元年”这一观点频频出现。Agent领域的确令人振奋，但坦率来说，很长时间里我都觉得Agent不过是“大模型应用的另一种叫法”，直到读到Anthropic在官网发布的一篇深度文章，才真正理清了其内在逻辑。

这篇文章系统梳理了Anthropic过去一年与众多团队合作构建大语言模型智能体的实战经验。从智能体的定义、典型应用场景、框架选型，到工作流与智能体的不同模式，再到构建高效智能体的实用建议，几乎把Agent这个看似抽象的概念分解得十分透彻。无论你是刚踏入此领域的新手，还是希望深入理解Agent的资深开发者，都值得认真读一读。

什么是Agent？

关于智能体的定义，可能比想象中更加灵活。有的客户把智能体理解为“可以长时间独立运行、利用多种工具完成复杂任务的完全自主系统”；也有人用它来描述预先设定好的工作流程。在Anthropic的语境下，所有这类系统都被归为“智能体系统”，但工作流（Workflow）与智能体（Agent）之间存在一个关键的架构性区别：

• 工作流（Workflow）：预先编排好大模型和工具的组合流程。每一步该调用什么、顺序如何，由人在设计阶段就明确指定。

• 智能体（Agent）：由大模型自主规划流程、感知环境、调用工具，并完成任务的系统。能走哪一步、下一步做什么，完全由LLM自身决定。

何时使用Agent？

一个容易被忽视的忠告是：在用LLM构建应用时，优先寻找最简单的解决方案，只有在确实需要时才增加复杂度。这意味着，很多场景下你根本不需要构建智能体系统。智能体系统通常以更高的延迟和成本来换取更好的任务性能，关键是要权衡清楚这种交换是否划算。

当需要更高复杂度时，工作流能提供可预测性和一致性——适合那些定义清晰、重复性高的任务；而智能体则在需要灵活性、规模化以及模型驱动决策时胜出，适合开放性问题。但说到底，对于大量常见应用场景，仅仅通过优化单个LLM调用——比如改进检索质量、提供更精准的上下文示例——往往就已经足够。

何时以及如何使用框架？

目前市面上有不少框架可以帮助开发者更轻松地实现智能体系统，例如LangChain的LangGraph、Amazon Bedrock的AI智能体框架、Rivet（拖放式GUI工作流构建器）以及Vellum（另一个用于构建和测试复杂工作流的GUI工具）。

这些框架确实降低了入门门槛——它们封装了调用LLM、定义和解析工具、串联调用等底层工作。但也要意识到，它们会引入额外的抽象层，反而可能掩盖底层的提示词和模型响应，导致调试困难。更常见的问题是，有些开发者明明可以用更简单的方式解决问题，却被框架“带偏”去构建复杂的系统。

建议是：先直接使用LLM的API——很多常见模式用几行代码就能实现。如果真的要用框架，务必搞清楚底层代码在做什么。对底层逻辑的错误假设，往往是最终用户出错的根源。

构建模块、工作流程和智能体

接下来这部分是文章的重头戏。Anthropic从最基础的构建模块“增强型LLM”开始，逐步增加复杂度，直到自主智能体。读图基本就能理解。

1/ 增强型LLM

智能体系统的基础模块，是一个经过增强的LLM——增加了检索、工具调用、记忆等能力。好消息是，当前的主流模型已经能够主动使用这些能力：发起搜索查询、选择合适的工具、自主决定保留哪些信息。

关键点在于两方面：一是针对自己的具体场景定制这些增强功能；二是确保为LLM提供简单、接口清晰的调用方式。Anthropic近期发布的模型上下文协议就是一个不错的实践——开发者可以通过简单的客户端，集成不断增长的第三方工具生态。

2/ Workflow：提示词的连接

提示链就是把一个大任务拆分成若干小步，每一步交给LLM处理，前一步的输出作为后一步的输入。中间可以插入程序化检查（“门”）来确认流程是否正常推进。

什么时候用？当任务可以清晰拆解成固定子任务时。本质是用延迟换取准确性——每个LLM调用的任务更简单，出错率自然更低。

示例：生成营销文案，再将其翻译成不同语言；或者，先写大纲，检查大纲是否符合标准，再根据大纲写正文。

3/ Workflow：自动路由

路由分两步走：先对输入进行分类，再将其交给专门的后续任务。这个模式能让不同场景的提示词“各司其职”，互不干扰。

什么时候用？任务存在明显可区分的不同类别，且可以通过LLM或传统分类模型准确划分。

示例：客服系统中，将一般问题、退款请求、技术支持分别交给不同的流程和工具。或者，简单问题用小模型（如Claude 3.5 Haiku），复杂问题用大模型（如Claude 3.5 Sonnet），以优化成本和质量。

4/ Workflow：并行化

LLM有时可以同时处理一个任务的不同子任务，然后通过编程方式汇总结果。这个模式有两种变体：

• 分段：将任务分解为独立并行运行的子任务。
• 投票：多次运行同一任务，获取不同输出后再决策。

什么时候用？当子任务可以并行来提速，或者需要多个视角提高可信度时。

示例：分段——用一个模型处理用户请求，另一个模型同时做内容安全审查；投票——多个提示同时审查代码漏洞，找到问题就标记；或用不同提示评估内容是否不适当，设置不同阈值来平衡误报和漏报。

5/ Workflow：协调器-工作器模式

这个模式中，有一个中心LLM（协调器）负责动态分解任务，交给多个工作LLM执行，最后整合结果。

什么时候用？用于复杂任务，你事先无法预测需要哪些子任务——比如代码修改中，需要改哪些文件、每个文件怎么改，完全取决于任务本身。

示例：对多个文件进行复杂修改的编码产品；需要从多个来源收集信息、综合分析才能找到答案的搜索任务。

6/ Workflow：评估器-优化器模式

一个LLM负责生成响应，另一个LLM在循环中做评估和反馈，不断迭代改善输出。

什么时候用？评估标准明确，且迭代改进能带来可衡量的提升。两个标志：一是人类反馈意见清晰时，LLM响应能明显改善；二是LLM本身能给出有价值的反馈。这很像人类作者修改文章的过程。

示例：文学翻译——翻译LLM可能捕捉不到细微差异，但评估LLM能指出问题；多轮搜索和分析任务——评估器判断是否需要进一步查询。

7/ 智能体Agent

智能体从人类指令或互动讨论开始工作。一旦任务明确，就自主规划和执行，但过程中可能需要返回给人类获取更多信息或判断。执行中必须从环境（工具调用结果、代码执行等）获取“真实信息”来推进。碰到障碍或遇到检查点，可以主动暂停等待人类反馈。任务完成后自然终止，但通常也会设置停止条件（如最大迭代次数）来保持控制。

智能体可以处理非常复杂的任务，但它的实现往往很简单——本质上就是一个在循环中基于环境反馈调用工具的LLM。因此，工具集的设计和文档质量至关重要。

什么时候用？无法预测步骤数的开放性问题，且无法硬编码固定路径时。必须对大模型的决策有一定信任。智能体的自主性使它非常适合在可信环境中扩展任务——但也意味着更高成本和潜在的累积错误。建议在沙盒环境中做充分测试，并设置适当的保护措施。

示例：解决SWE-bench任务的编码智能体（需要根据任务描述对多个文件进行编辑）；Anthropic的“计算机使用”参考实现——Claude用计算机完成任务。

总结

在LLM领域做得好，不在于构建最复杂的系统，而在于构建适合需求的系统。从简单的提示词开始，用全面的评估来优化，只有在更简单的方案确实不够用时，才考虑加入多步骤的智能体系统。

如果真的要构建智能体，Anthropic给出了三个核心原则：

• 保持智能体设计的简单性。

• 通过明确展示计划步骤，优先考虑透明度。

• 精心设计智能体-计算机接口（ACI）——做好工具文档和测试。

框架能帮你快速入门，但进入生产环境后，不妨大胆减少抽象层，回归基础组件来构建。遵循这些原则，你就能打造出功能强大、可靠、可维护且值得用户信任的智能体。