构建有效的智能体

Over the past year, we've worked with dozens of teams building large language model (LLM) agents across industries. Consistently, the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns.

过去一年中，我们与数十个跨行业团队合作构建大语言模型（LLM）智能体。一致地看，最成功的实现方案并非依赖复杂的框架或专用库。相反，它们都是用简单、可组合的模式构建的。

In this post, we share what we've learned from working with our customers and building agents ourselves, and give practical advice for developers on building effective agents.

在这篇文章中，我们分享从客户合作和自建智能体过程中学到的经验，为开发者提供构建有效智能体的实用建议。

什么是智能体？

"Agent" can be defined in several ways. Some customers define agents as fully autonomous systems that operate independently over extended periods, using various tools to accomplish complex tasks. Others use the term to describe more prescriptive implementations that follow predefined workflows. At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents:

"智能体"可以有多种定义。一些客户将智能体定义为在较长时期内独立运行的完全自主系统，使用各种工具来完成复杂任务。另一些人则用这个词来描述遵循预定义工作流的更具规定性的实现。在 Anthropic，我们将所有这些变体统称为智能体系统，但在架构上区分了工作流和智能体：

Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

工作流是通过预定义代码路径编排 LLM 和工具的系统。

Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

智能体则是 LLM 动态指导自身流程和工具使用的系统，自主控制完成任务的方式。

何时使用（或不使用）智能体

When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all. Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.

在用 LLM 构建应用时，我们建议先找最简单的解决方案，仅在需要时才增加复杂度。这可能意味着根本不需要构建智能体系统。智能体系统通常以延迟和成本换取更好的任务表现，你需要权衡这种取舍是否值得。

When more complexity is warranted, workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale. For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough.

当确实需要更多复杂度时，工作流为定义良好的任务提供可预测性和一致性，而智能体则在需要大规模灵活性和模型驱动决策时是更好的选择。然而，对于许多应用来说，通过检索和上下文示例优化单次 LLM 调用通常就够了。

何时以及如何使用框架

There are many frameworks that make agentic systems easier to implement, including: The Claude Agent SDK; Strands Agents SDK by AWS; Rivet, a drag and drop GUI LLM workflow builder; and Vellum, another GUI tool for building and testing complex workflows.

有很多框架可以让智能体系统更容易实现，包括：Claude Agent SDK；AWS 的 Strands Agents SDK；Rivet（拖拽式 GUI LLM 工作流构建器）；以及 Vellum（另一个用于构建和测试复杂工作流的 GUI 工具）。

These frameworks make it easy to get started by simplifying standard low-level tasks like calling LLMs, defining and parsing tools, and chaining calls together. However, they often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug. They can also make it tempting to add complexity when a simpler setup would suffice.

这些框架通过简化标准底层任务（如调用 LLM、定义和解析工具、链接调用）让入门变得容易。然而，它们通常会创建额外的抽象层，可能掩盖底层的提示和响应，使调试变得更困难。它们还可能诱使你在简单设置就足够时添加不必要的复杂度。

We suggest that developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code. If you do use a framework, ensure you understand the underlying code. Incorrect assumptions about what's under the hood are a common source of customer error.

我们建议开发者从直接使用 LLM API 开始：许多模式只需几行代码就能实现。如果你确实使用框架，确保理解底层代码。对底层运作方式的错误假设是客户错误的常见来源。

基础组件：增强型 LLM

The basic building block of agentic systems is an LLM enhanced with augmentations such as retrieval, tools, and memory. Our current models can actively use these capabilities—generating their own search queries, selecting appropriate tools, and determining what information to retain.

智能体系统的基础构建块是经过增强的 LLM——添加了检索、工具和记忆等能力。我们当前的模型可以主动使用这些能力——生成自己的搜索查询、选择合适的工具、决定保留哪些信息。

We recommend focusing on two key aspects of the implementation: tailoring these capabilities to your specific use case and ensuring they provide an easy, well-documented interface for your LLM. While there are many ways to implement these augmentations, one approach is through our recently released Model Context Protocol, which allows developers to integrate with a growing ecosystem of third-party tools with a simple client implementation.

我们建议关注实现的两个关键方面：根据特定用例定制这些能力，以及确保它们为 LLM 提供易于使用、文档完善的接口。虽然实现这些增强的方式很多，一种方法是通过我们发布的 Model Context Protocol（MCP），它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。

工作流：提示链

Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one. You can add programmatic checks (see "gate" in the diagram below) on any intermediate steps to ensure that the process is still on track.

提示链将任务分解为一系列步骤，每次 LLM 调用处理前一步的输出。你可以在任何中间步骤添加程序化检查（即"门控"），确保流程仍在正轨上。

When to use: This workflow is ideal for situations where the task can be easily and cleanly decomposed into fixed subtasks. The main goal is to trade off latency for higher accuracy, by making each LLM call an easier task.

适用场景：当任务可以轻松、干净地分解为固定子任务时。主要目标是用延迟换取更高的准确率——让每次 LLM 调用都更简单。

Examples: Generating marketing copy, then translating it into a different language. Writing an outline of a document, checking that the outline meets certain criteria, then writing the document based on the outline.

示例：先生成营销文案，再翻译成另一种语言。先写文档大纲，检查大纲是否满足特定标准，再基于大纲撰写完整文档。

工作流：路由

Routing classifies an input and directs it to a specialized followup task. This workflow allows for separation of concerns, and building more specialized prompts. Without this workflow, optimizing for one kind of input can hurt performance on other inputs.

路由对输入进行分类，并将其导向专门的后续任务。这种工作流实现了关注点分离，可以构建更专业的提示。如果没有路由，为一种输入做优化可能会损害其他输入的性能。

When to use: Routing works well for complex tasks where there are distinct categories that are better handled separately, and where classification can be handled accurately.

适用场景：路由适用于有明确类别且最好分别处理的复杂任务，以及分类可以被准确执行的场景。

Examples: Directing different types of customer service queries (general questions, refund requests, technical support) into different downstream processes. Routing easy/common questions to smaller, cost-efficient models like Claude Haiku 4.5 and hard/unusual questions to more capable models like Claude Sonnet 4.5.

示例：将不同类型的客服查询（一般问题、退款请求、技术支持）导向不同的下游流程。将简单/常见问题路由到更小、更具成本效益的模型（如 Claude Haiku 4.5），将困难/异常问题路由到更强大的模型（如 Claude Sonnet 4.5）。

工作流：并行化

LLMs can sometimes work simultaneously on a task and have their outputs aggregated programmatically. This workflow, parallelization, manifests in two key variations: Sectioning (breaking a task into independent subtasks run in parallel) and Voting (running the same task multiple times to get diverse outputs).

LLM 有时可以同时处理一个任务，然后通过程序聚合输出。这种并行化工作流有两种关键变体：分区（将任务拆分为独立子任务并行运行）和投票（多次运行同一任务以获得多样化输出）。

Examples (Sectioning): Implementing guardrails where one model instance processes user queries while another screens them for inappropriate content. Automating evals where each LLM call evaluates a different aspect of performance.

示例（分区）：实现安全护栏——一个模型实例处理用户查询，另一个检查内容是否不当。自动化评估——每次 LLM 调用评估模型表现的不同方面。

Examples (Voting): Reviewing a piece of code for vulnerabilities, where several different prompts review and flag the code if they find a problem. Evaluating whether content is inappropriate, with multiple prompts evaluating different aspects.

示例（投票）：代码漏洞审查——多个不同提示分别审查代码，发现问题就标记。内容审核——多个提示从不同角度评估内容是否不当。

工作流：编排者-工作者

In the orchestrator-workers workflow, a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results.

在编排者-工作者工作流中，一个中央 LLM 动态分解任务，将子任务委派给工作者 LLM，然后综合它们的结果。

When to use: This workflow is well-suited for complex tasks where you can't predict the subtasks needed. Whereas it's topographically similar to parallelization, the key difference is its flexibility—subtasks aren't pre-defined, but determined by the orchestrator based on the specific input.

适用场景：适用于无法预先确定所需子任务的复杂工作。虽然它与并行化在拓扑上相似，但关键区别在于灵活性——子任务不是预定义的，而是由编排者根据具体输入动态决定。

Examples: Coding products that make complex changes to multiple files each time. Search tasks that involve gathering and analyzing information from multiple sources.

示例：需要对多个文件进行复杂更改的编程产品。涉及从多个来源收集和分析信息的搜索任务。

工作流：评估者-优化器

In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop.

在评估者-优化器工作流中，一个 LLM 调用生成响应，另一个在循环中提供评估和反馈。

When to use: This workflow is particularly effective when we have clear evaluation criteria, and when iterative refinement provides measurable value. The two signs of good fit are, first, that LLM responses can be demonstrably improved when a human articulates their feedback; and second, that the LLM can provide such feedback.

适用场景：当我们有明确的评估标准，且迭代优化能提供可衡量的价值时特别有效。两个适配信号：一，当人类明确表达反馈时，LLM 的响应可以显著改善；二，LLM 能够提供这样的反馈。

Examples: Literary translation where there are nuances that the translator LLM might not capture initially, but where an evaluator LLM can provide useful critiques. Complex search tasks that require multiple rounds of searching and analysis.

示例：文学翻译——翻译 LLM 可能最初无法捕捉某些微妙之处，但评估 LLM 可以提供有用的批评。复杂搜索任务——需要多轮搜索和分析。

智能体

Agents begin their work with either a command from, or interactive discussion with, the human user. Once the task is clear, agents plan and operate independently, potentially returning to the human for further information or judgement. During execution, it's crucial for the agents to gain "ground truth" from the environment at each step (such as tool call results or code execution) to assess its progress. Agents can then pause for human feedback at checkpoints or when encountering blockers. The task often terminates upon completion, but it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control.

智能体从人类用户的命令或交互式讨论开始工作。任务明确后，智能体独立规划和执行，可能在需要时回到人类这里获取更多信息或判断。在执行过程中，智能体必须在每一步从环境中获取"地面真相"（如工具调用结果或代码执行结果）来评估进展。智能体可以在检查点或遇到阻碍时暂停以获取人类反馈。任务通常在完成时终止，但也常设置停止条件（如最大迭代次数）以保持控制。

Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop. It is therefore crucial to design toolsets and their documentation clearly and thoughtfully.

智能体可以处理复杂任务，但其实现通常很直接。它们通常只是 LLM 在循环中基于环境反馈使用工具。因此，清晰、周到地设计工具集及其文档至关重要。

When to use agents: Agents can be used for open-ended problems where it's difficult or impossible to predict the required number of steps, and where you can't hardcode a fixed path. The LLM will potentially operate for many turns, and you must have some level of trust in its decision-making. Agents' autonomy makes them ideal for scaling tasks in trusted environments.

何时使用智能体：智能体适用于开放式问题——难以或无法预测所需步骤数量，无法硬编码固定路径。LLM 可能会运行很多轮，你必须对其决策有一定程度的信任。智能体的自主性使其非常适合在可信环境中扩展任务。

The autonomous nature of agents means higher costs, and the potential for compounding errors. We recommend extensive testing in sandboxed environments, along with the appropriate guardrails.

智能体的自主性意味着更高的成本和错误累积的潜在风险。我们建议在沙盒环境中进行广泛测试，并配备适当的安全护栏。

组合与定制这些模式

These building blocks aren't prescriptive. They're common patterns that developers can shape and combine to fit different use cases. The key to success, as with any LLM features, is measuring performance and iterating on implementations. To repeat: you should consider adding complexity only when it demonstrably improves outcomes.

这些构建块不是规定性的。它们是开发者可以根据不同用例塑造和组合的常见模式。成功的关键——与任何 LLM 功能一样——是衡量性能并迭代实现。再次强调：只有当复杂度能明显改善结果时才应该添加。

总结

Success in the LLM space isn't about building the most sophisticated system. It's about building the right system for your needs. Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.

在 LLM 领域的成功不在于构建最复杂的系统，而在于构建适合你需求的正确系统。从简单的提示开始，通过全面评估来优化，只有在更简单的方案不够用时才添加多步智能体系统。

When implementing agents, we try to follow three core principles: Maintain simplicity in your agent's design. Prioritize transparency by explicitly showing the agent's planning steps. Carefully craft your agent-computer interface (ACI) through thorough tool documentation and testing.

在实现智能体时，我们遵循三个核心原则：保持设计简洁。优先透明——显式展示智能体的规划步骤。精心打造智能体-计算机接口（ACI）——通过完善的工具文档和测试。

Frameworks can help you get started quickly, but don't hesitate to reduce abstraction layers and build with basic components as you move to production. By following these principles, you can create agents that are not only powerful but also reliable, maintainable, and trusted by their users.

框架可以帮助你快速起步，但在进入生产环境时，不要犹豫减少抽象层并用基础组件构建。遵循这些原则，你可以创建不仅强大，而且可靠、可维护、被用户信任的智能体。

附录 1：智能体的实际应用

客户支持

Customer support combines familiar chatbot interfaces with enhanced capabilities through tool integration. Support interactions naturally follow a conversation flow while requiring access to external information and actions; Tools can be integrated to pull customer data, order history, and knowledge base articles; Actions such as issuing refunds or updating tickets can be handled programmatically; Success can be clearly measured through user-defined resolutions.

客户支持将熟悉的聊天机器人界面与通过工具集成的增强能力相结合。支持交互自然遵循对话流程，同时需要访问外部信息和操作；可以集成工具来拉取客户数据、订单历史和知识库文章；退款或更新工单等操作可以通过程序处理；成功与否可以通过用户定义的解决方案清晰衡量。

编程智能体

Code solutions are verifiable through automated tests; Agents can iterate on solutions using test results as feedback; The problem space is well-defined and structured; Output quality can be measured objectively. In our own implementation, agents can now solve real GitHub issues in the SWE-bench Verified benchmark based on the pull request description alone.

代码解决方案可以通过自动化测试验证；智能体可以使用测试结果作为反馈来迭代解决方案；问题空间定义明确且结构化；输出质量可以客观衡量。在我们自己的实现中，智能体现在可以仅根据 PR 描述解决 SWE-bench Verified 基准测试中的真实 GitHub issue。

附录 2：工具的提示工程

Tools enable Claude to interact with external services and APIs by specifying their exact structure and definition in our API. Tool definitions and specifications should be given just as much prompt engineering attention as your overall prompts.

工具通过在 API 中指定精确的结构和定义，使 Claude 能够与外部服务和 API 交互。工具定义和规范应该与整体提示一样，给予同等的提示工程关注。

There are often several ways to specify the same action. Some formats are much more difficult for an LLM to write than others. Writing a diff requires knowing how many lines are changing in the chunk header before writing new code. Writing code inside JSON requires extra escaping of newlines and quotes.

同一种操作通常有多种指定方式。某些格式对 LLM 来说比其他格式难写得多。写 diff 需要在写新代码之前知道 chunk header 中有多少行在变化。在 JSON 中写代码需要额外转义换行符和引号。

Our suggestions for tool formats: Give the model enough tokens to "think" before it writes itself into a corner. Keep the format close to what the model has seen naturally occurring in text on the internet. Make sure there's no formatting "overhead" such as having to keep an accurate count of thousands of lines of code.

我们对工具格式的建议：给模型足够的 token 来"思考"，避免把自己逼入死角。保持格式接近模型在互联网文本中自然见过的形式。确保没有格式"开销"——比如不需要精确计算数千行代码。

One rule of thumb is to think about how much effort goes into human-computer interfaces (HCI), and plan to invest just as much effort in creating good agent-computer interfaces (ACI). Put yourself in the model's shoes. Is it obvious how to use this tool based on the description and parameters? Test how the model uses your tools. Poka-yoke your tools—change the arguments so that it is harder to make mistakes.

一个经验法则：想一想人机界面（HCI）投入了多少精力，然后计划在创建良好的智能体-计算机界面（ACI）上投入同等的精力。站在模型的角度思考——根据描述和参数，这个工具的用法是否一目了然？测试模型如何使用你的工具。防呆设计（Poka-yoke）你的工具——修改参数让出错更难发生。