字数 11451，阅读大约需 58 分钟

如果你一直在关注2025年的人工智能领域，你可能已经注意到每个人都在谈论智能体。这并非没有道理。AI智能体能够处理从简单的日常任务到复杂的企业级多智能体工作流程的各种事务。

而这仅仅是开始。在这个领域，我们将看到更多的创新。

如果你刚接触这个领域，我先介绍一下自己：我是Marina，是亚马逊的资深应用科学家，目前从事生成式AI相关工作。今天我将详细解析构建和使用AI智能体所需了解的一切。

我为这个主题进行了深入的研究。我参加了大量不同的课程，阅读了相关书籍，并构建了自己的智能体。我的研究笔记最终长达约150页，而我将所有这些内容精炼成一篇文章呈现给你。

以下是我们的内容安排：

首先，基础知识。 什么是AI智能体？核心概念是什么？你实际上可以在哪里使用它们？我们还会介绍一些无代码选项，如果你想不写代码就开始实验的话。

然后，中级内容。 我们将深入构建和评估解决实际问题多智能体系统。我将演示一个我制作的智能体系统，它目前每周为我节省数小时的工作时间。

然后是高级内容。 在生产环境中构建可靠智能体系统实际上需要什么？

最后是Bonus部分， 面向希望深入了解Claude Code等工具实际工作原理的开发者。

无论你是一个只想自动化自己工作流程的非技术人员，还是正在为公司构建生产级AI系统，都希望这篇文章都对你有所帮助。

初级

什么是智能体？

好的，让我们从基础开始：AI智能体到底是什么？

最简单的理解方式是：想象你需要写一篇文章。如果你使用传统的LLM提示，你基本上会说："嘿ChatGPT，帮我写一篇关于如何开始健身的文章"，然后它一次完成整篇文章，从头到尾。

但你或我实际上并不是这样写文章的，对吧？我们不会一次性创作出完美的初稿。我们会规划、列提纲、做研究、写草稿、阅读并修改。这是一个过程。

这就是智能体AI所做的事情。不是让AI在一次线性传递中完成所有事情，而是让它像人类一样迭代地工作。

那么这实际上是什么样子呢？

让我们继续用写文章的例子。以下是智能体处理它的方式：

首先，它从提纲开始。在开始写作之前，先确定结构。主要观点是什么？什么顺序合理？

然后它从提纲中确定需要什么信息，并实际获取这些信息。

它可能会搜索网页、从API获取数据或下载相关资源，然后使用这些信息来撰写文章初稿。

但巧妙之处在于它不会就此停止。智能体会反思自己的工作并进行修改，比如加强薄弱的论点、补充缺失的信息或改善整体流畅性。

这就是人们所说的ReAct循环。模型推理下一步该做什么，采取行动（通常通过调用工具，我们稍后会讨论），观察结果，然后要么给出答案，要么循环回推理阶段。

这种方法在任何需要仔细、准确且有适当来源的工作中都效果良好。你可以想到法律研究（需要引用特定案例）、医疗文档或需要在回复前查找账户详情的客户支持系统等领域。

当然，额外的专业化、准确性是有代价的——复杂性。因此引出了一个显而易见的问题：哪些任务值得构建智能体？

智能体适合哪些任务？

有些任务适合智能体，有些则不适合。让我们看一些从简单到复杂的例子。

一个非常简单的智能体系统示例可能是从发票中提取关键字段，然后保存到数据库。像这样流程清晰、可重复的任务非常适合智能体。

中等复杂度的可能是回复客户邮件。智能体查找订单、检查客户记录，并起草回复供人工审核。

再高一 level 是一个完整的客户服务智能体，处理"你有蓝色牛仔裤吗？"或"如何退货？"等问题。对于退货，智能体需要验证购买记录、检查政策、确认是否允许退货，然后引导完成整个退货流程——这个流程有很多步骤。智能体需要自己弄清楚步骤是什么，而不仅仅是遵循脚本。

思考哪些用例适合智能体的一个有效方式是使用一个双轴矩阵：复杂度和精确度。

有些问题既有高复杂度又需要高精度，比如填写税务表格。

有些则复杂但不需要完美准确。在这种情况下，你可以想到像撰写和检查讲座笔记摘要这样的任务。

最大的价值通常来自高复杂度工作，而最快的早期成果往往是低精确度方面。这就是为什么高复杂度、低精确度的象限通常是明智的起点。你从自动化棘手的事情中获得杠杆作用，不会因为每次都需要完美输出而被阻碍。

总之，当任务需要迭代、研究或多步骤流程时，智能体真正发挥价值。通常从能够处理稍低精确度的复杂任务开始是有意义的。

自主性光谱

好的，现在你已经知道智能体适合什么了，让我们谈谈如何实际构建它们。你需要做出的第一个重大决策是：你希望给智能体多少自主性？

把这想象成一个光谱。

一端是脚本化智能体，你对每一步都硬编码。例如我们的写文章示例可能是：首先生成搜索词、调用网络搜索、获取页面，然后写文章。完成了。这是确定性的、可预测的、易于控制的。模型唯一的工作是生成实际文本，因为其他一切你已经决定了。

另一端是高度自主的智能体。现在LLM决定是否搜索Google、新闻网站或研究论文。它决定获取多少页面、是否转换PDF、是否反思和修改。它甚至可能编写新函数并运行它们。这更强大，但也更不可预测、更难控制。

在实践中，大多数现实世界的智能体都处于中间某处，是半自主的。智能体从你定义的工具中选择，并在你设置的护栏内做出决策。

上下文工程

但智能体如何知道有哪些可用工具或如何做出决策？

这就是所谓的"上下文工程"，即你决定智能体拥有哪些信息。这包括任务背景、智能体的角色、过去操作的记忆以及可用工具。

如果你把所有这些上下文组合在一起，这个上下文就会引导一个非确定性模型产生一致的高质量输出。

这就是智能体"智能"的实际基础。不是模型本身，而是你围绕它设计的上下文。我们将在整个课程中详细讨论这些组件。

任务分解

一旦智能体有了它的上下文，就该定义它应该执行的任务了。弄清楚这些任务可以说是构建智能体时最重要的事情。

从你如何执行任务开始。然后对于每个步骤，问自己："LLM能做到这一点吗？一小段代码？一个API？"如果答案是否定的，就把它分解得更小，直到可以。

让我们继续用构建一个写文章的智能体作为例子。

想想你实际上会怎么写，然后弄清楚AI可能如何执行那个任务。可能大致如下：

• • 使用LLM进行提纲规划
• • 使用LLM生成搜索词，然后调用搜索API
• • 使用工具获取页面
• • 使用LLM和那些来源撰写草稿
• • 使用LLM进行自我批评，反思并列出差距
• • 使用LLM进行修改

每个步骤都很小、可检查、清晰。当输出不够好时，你确切地知道要改进哪个步骤。

中级

评估

好了，现在我们已经掌握了基础知识，进入中级领域。

我们将从一些非常枯燥的内容开始。但是，这是区分业余爱好者和专业人士的东西：如何衡量智能体的性能。

有时候，评估可以像测量输出正确的次数一样简单。如果我问我的客服聊天机器人某件商品是否有货，它能否正确回答……

但并非所有事情都这么简单。让我们想想我们的写文章智能体。你如何衡量文章是否真的好？

一种方法是使用第二个LLM来评判输出。让它使用一致的评分标准对每篇文章进行1到5分质量评分。

你可以在组件级别评估你的系统以确保每个单独的步骤正常工作，并在端到端评估以判断整个系统的最终质量。

如果你发现系统没有你想要的那么好，第一步是检查中间步骤，这些被称为追踪。这包括智能体写的搜索查询、草稿和思考步骤。如果你仔细阅读这些，你可能会注意到一些模式，比如过于通用的查询，或者修改步骤没有正确传递批评。

这些观察成为你的下一个评估或下一个修复。

重要的是你要立即开始评估，但也不要担心从一开始就有完美的评估系统。你可以快速让某些东西工作，然后随着时间迭代。

记忆

现在我们有了简单的系统设置和一些性能测量方法，是时候实际努力改进性能了。记忆是一种非常常见的方法。

记忆让智能体记住什么有效、什么失败、下次要做什么不同，这样它每次运行都能实际改进。你可能有短期记忆，智能体用它来记录正在进行的工作。在多智能体系统中，其他智能体可以读取这些笔记。智能体完成任务后，它可以反思自己做了什么，将结果与预期进行比较，弄清楚什么做得好什么做得不好，并将这些经验存储在长期记忆中。

下次运行时，它加载这些经验并应用它们。

这可以用来"训练"智能体，类似于监督学习。你可以给智能体关于它工作的反馈，这样随着时间推移，每次运行的质量都会提高。我将在本节末尾的演示中展示一个例子。

所以记忆是动态的，每次运行都会更新。而知识则是静态的参考资料，你在一开始就加载。PDF、CSV、文档或数据库访问。你给智能体一次，它就可以在需要引用准确内容时从那个库中获取。

护栏

一旦我们设置了带有任务、知识和记忆的智能体，我们就准备好让它发挥作用了！对吧？

不完全是。还有一个我们没有讨论的非常重要的步骤。

因为LLM是非确定性的，它们可能会犯错。也许它们写的东西事实错误，或者格式不对。

为了防止问题，我们需要给系统添加护栏。

护栏基本上是智能体声称完成和任务实际完成之间的质量门。

护栏有三种主要方法，大多数生产系统至少使用两种。

对于输出格式和长度等确定性内容，我们可以只使用标准代码片段。这些快速、便宜，在可能的情况下应该优先使用。

最后，有时候你只是需要人工检查工作。

智能体完成并自动发布结果，而是让它停下来先请求批准。你可以提供反馈并要求智能体重试。

设计模式

好了，我们已经涵盖了很多关于如何让系统运作的内容。现在让我们谈谈如何让系统更好质量。

有四个核心模式可以可靠地提高质量和能力：反思、工具使用、规划和多智能体协作。

让我们从最简单和最有效的一个开始：反思。

反思

简而言之，反思基本上意味着我们不会在初稿就停下来。

当你使用反思时，模型产生内容，批评它，然后在需要时重写。第二遍——由一个要求找到并修复问题的提示引导——几乎总是让事情变得更好。

让我用一个邮件示例来展示。

版本1（初稿）："嘿，我们下个月见面讨论项目吧。谢谢"

这有什么问题？日期模糊（"下个月"），没有签名，"谢谢"感觉唐突。

反思步骤：模型阅读v1并发现这些问题——时间线不清晰，缺少签名，语气感觉仓促。

版本2（修改后）："嗨Alex，我们1月5-7日之间见面讨论项目时间表。告诉我什么时间适合你。你最好的伙伴，Marina"

内容相同但更清晰、更具体、更专业。

反思在代码方面变得非常强大，因为你可以在外部添加反馈。你可以写代码，让批评智能体审查，然后实际运行它。这允许你捕获错误、测试结果和输出，并将它们反馈给模型。模型可以使用这些具体信息产生更好的v2。

特别是，当你可以结合外部反馈时，反思效果很好。比如在JSON上运行模式验证器，或在研究任务中检查缺失的引用。

缺点是它增加了延迟和成本，因为你做了多次传递。所以，确保测试有反思和没有反思的情况，以确保它真的有帮助。

工具使用

好了，让我们谈谈第二个设计模式：工具使用。

核心思想是：你给LLM一个它可以调用的函数菜单。这可以是网络搜索、数据库查询、代码执行、日历访问或你的应用程序需要的任何东西。然后模型决定何时以及使用哪些工具。

这很重要，因为LLM本身只是一个文本生成器。它不知道现在是什么时间或关于你公司销售数据的任何信息。它不能执行代码来计算精确答案。

但如果你给它工具，它可以搜索网络、查询数据库、写入CRM或运行代码。

所以如果我问智能体"现在几点了？"，LLM调用getCurrentTime()函数，返回"下午3:20"，然后用它回应。

当你给模型多个工具时，它可以将它们链接在一起。例如，假设你正在构建一个日历助手。你暴露了三个工具：checkCalendar、makeAppointment和deleteAppointment。

用户问："这周和爱丽丝安排一个会议。"

模型思考步骤：

1. 1. 检查我的日历可用性
2. 2. 找一个空闲时段——看起来周四下午3点可以
3. 3. 用爱丽丝和那个时间调用makeAppointment
4. 4. 向用户确认

好的，但这里有个问题：LLM只生成文本。它们不执行代码。那么它们如何"调用"函数？

它们实际上不调用。它们请求函数调用。

内部循环是这样的：

1. 1. 用户发送提示
2. 2. LLM查看其可用工具并决定是否需要一个
3. 3. 如果需要，它输出一个特殊请求，如"我想用timezone Pacific/Auckland调用getCurrentTime"
4. 4. 你的代码看到那个请求，实际运行函数并获取结果
5. 5. 你将那个结果作为新上下文反馈给LLM
6. 6. LLM用它完成答案——或者如果需要，再请求另一个工具

就这么简单。LLM请求但不实际执行代码。

设计好的工具

为了让LLM能够找到和请求工具，我们需要一种一致的方式来定义它们。每个工具有两个部分：

1. 1. 智能体的接口。这包括工具名称、关于何时使用的英文描述，以及类型化的输入模式。

例如："ReadWebsiteContent"，描述"获取并返回网页文本"，一个输入：url（字符串）。

1. 2. 实现代码。无论你需要什么，如SQL查询、认证、重试、节流和解析。

智能体只看到接口。所有混乱的实现细节都被隐藏。

好的工具还要考虑错误处理、自我恢复和速率限制。它们可能使用缓存来记忆化相同输入的结果以减少延迟、成本和外部API负载。它们应该有异步支持，这样智能体（或其他智能体）可以在长时间工具请求完成时继续工作。

工具应该像产品一样构建，有版本控制、适当的文档和足够的测试。维护一个经过审查的工具内部注册表很有用，包含文档、版本和所有权。

把这一切放在一起，你就给了智能体与世界互动的方式。这很棒！但我们需要确保智能体知道它在现实世界中需要做什么，这就引出了第三个设计模式：规划。

规划

规划的核心思想是：不是硬编码固定序列的步骤，而是让LLM决定做什么以及按什么顺序。

但当有人问你没有预料到的事情时会发生什么？或者当同样的问题根据上下文需要不同步骤时？

使用规划，你给智能体一个函数工具包，如get_item_descriptions、check_inventory、get_item_price、process_return，让它弄清楚使用哪些工具以及何时使用。

基本循环是这样的：

1. 1. 你给智能体访问工具
2. 2. 你提示它创建计划："列出回答这个问题的逐步行动"
3. 3. 你逐步执行计划——LLM选择正确的工具，你运行它，你把结果反馈回去
4. 4. 重复直到完成

基本上是"计划→行动→观察→继续"，但用的是你的工具。

一个具体例子：零售太阳镜

用户问："有100美元以下的圆形太阳镜吗？"

智能体可能计划：

步骤1：使用get_item_descriptions找到圆形镜框步骤2：对该列表运行check_inventory步骤3：对有货的商品调用get_item_price并筛选100美元以下步骤4：撰写回复

你没有预定义这个确切的配方。LLM从可用工具中选择了它。

现在一个不同的问题来了："我想退货我买的金色镜框太阳镜，不是金属的。"

计划在这种情况下完全改变：

步骤1：识别用户的先前购买步骤2：匹配金色镜框产品步骤3：调用process_item_return步骤4：确认结果

让模型输出结构化JSON计划可能会有帮助。

规划增加了自主性，这意味着它也增加了不可预测性。你需要对权限、工具调用的验证以及管理将一个步骤的输出传递给下一个步骤等方面设置护栏。

目前，规划最强大的用例是高度智能化的编码系统。模型将编程任务分解为步骤并逐步完成。

对于其他领域，规划绝对有效，但更难控制，因为你无法提前知道模型会创建什么计划。不过工具和护栏正在快速改进，采用率也在增长。

但如果你有一个系统需要做很多事情，可能是同时做呢？这就是多智能体协作的用武之地。

多智能体

想想你在现实生活中如何处理复杂项目。你不会雇佣一个超级通才来做所有事情。你建立一个团队。你有在特定领域非常擅长的专家，他们互相交接工作。

多智能体系统借用了同样的思路。

每个智能体都有明确的角色。每个智能体专注于它擅长的东西。输出更好，因为你在每一步都有专业化。

除了专业化，多智能体系统还有一些其他优势：

• • 它避免任何单个智能体拥有巨大的上下文窗口。
• • 你可以使用多个LLM。你可以为高容量简单任务混合使用更快、更便宜的模型，为精确任务（如策略、敏感的客服回复或长篇写作）保留更大、更强大的模型。这让你在成本和性能两方面都有灵活性。
• • 你可以并行化工作。
• • 如果你有很长的运行操作，你可以分开工作，查看哪些智能体在做什么，帮助用户理解正在发生的事情。

如果你有一个简单的任务，跳过多智能体系统。它们可能会减慢速度，使调试更困难。

这是因为多智能体系统引入了一层全新的复杂性。你可能有资源冲突——如果两个智能体试图修改同一个文件；有智能体之间的通信开销；还有复杂的任务依赖。还有API速率限制的问题，以及如果一个智能体失败怎么办——其他的是继续还是回滚？你如何将多个智能体产生的内容合并成一个连贯的输出？

这并非无法管理，但你需要为此设计。你需要强大的编排、良好的错误处理，以及智能体如何通信的清晰协议。

多智能体系统设计

所以让我们更深入地谈谈如何设计这些多智能体系统。让我们用创建营销手册的例子来说明我们的选项。

角色模型

第一步是通过角色定义你的智能体。每个智能体获得一个明确的工作描述和仅它完成工作所需的工具。

对于我们的营销手册，你可能有：

一个研究智能体，发现市场趋势和竞争对手动向。这个智能体可能有网络搜索、检索和笔记工具。

一个图形设计师智能体，用工具创建图表和视觉资产，如图像生成、图像操作或用于绘制图表的代码执行。

一个写作智能体，将发现和资产转化为最终文案。这个智能体可能只是LLM本身，不需要外部工具。

一旦你定义了智能体，你需要决定它们如何通信。有四种主要模式，我们从最简单到最复杂讨论。

模式1：顺序

这是最简单和最可预测的。每个智能体完成其工作，然后将其输出传递给下一个智能体。

就像流水线。易于调试，有可预测的时间和成本。

你应该从这里开始。根据你的用例，这可能就足够了。

模式2：并行

但顺序不是唯一的选择。当步骤不相互依赖时，你也可以并行运行智能体，这非常适合减少延迟。

这加快了速度，但增加了协调复杂性。

模式3：单一管理者层级

如果你开始进入更复杂的工作流程，添加一个计划和管理的管理者智能体可能会有帮助。专家智能体做他们的工作并向管理者报告，而不是相互报告。

这可能是当今生产多智能体系统中最常见的模式。

对于更复杂的工作流程，你可以有更深的层级，其中一些智能体管理自己的子智能体。

模式4：全对全（自由聊天）

最后，我们有全对全模式，可能非常混乱。在这个模式中，任何智能体可以在任何时候给任何其他智能体发消息。这在生产中很少见，因为它难以预测和控制。输出可能因运行而差异很大。

协调陷阱

我们已经多次谈到协调挑战。这里有两个最常见的陷阱。

首先，冗余工作。多个智能体可能重复相同的搜索或调用相同的工具。这可以通过缩小任务范围和在智能体之间有明确的分工来解决。

其次，不必要的序列化。将可以并发运行的步骤链接起来会拖慢一切。要解决这个问题，识别真正独立的任务并异步运行它们，然后只路由下一步需要的上下文片段。

一般来说，你希望从最简单的协调方法开始，只有在需要时才添加复杂性。

最佳实践

无论你选择哪种模式，在设计系统时都要记住四个关键最佳实践：

1. 定义接口，而不是感觉。

每个智能体需要一个清晰的输入输出模式。它需要知道：什么字段？什么类型？传递什么ID或引用？

交接失败比模型失败更频繁。如果你的研究员返回一个非结构化blob，而你的设计师不知道如何解析它，整个系统就会失败。

2. 按智能体限定工具范围。

给每个智能体只有它实际需要的工具。最小权限访问。

这有助于安全，使系统更容易推理、更容易审计和更容易调试。

3. 记录追踪。

保留每个步骤的产物。每个智能体计划了什么？它使用了什么提示？它做了什么工具调用？收到了什么结果？

当某事破裂时，这个追踪使错误分析快速。你可以准确地看到哪里出了问题。

4. 评估组件和端到端

你需要两种评估：

组件级别：研究相关吗？图像高质量吗？文案语气合适吗？

以及端到端：最终手册好吗？它符合要求吗？

如果你的端到端评估显示问题但你的组件评估都看起来不错，你就知道这是一个交接或集成问题。如果特定的组件评估失败，你就知道要改进哪个智能体。

高级

好了，欢迎来到高级部分。如果你已经读到这部分，你是认真要在现实世界中构建真实智能体系统的。

让你从零到原型的技术不会让你从原型到生产。你需要不同的工具、不同的心态和更多的纪律。

让我们开始讨论。

多智能体系统的高级任务分解

我们已经讨论过任务分解。但当你与多智能体系统一起工作时，这变得越来越复杂。

有四种主要模式可以用来很好地指导你做这件事。顺便说一句，我改编自这个精彩的博客——查看它获取更多细节！）

模式1：功能分解

在这个模式中，我们按技术领域或专业知识拆分任务。这正是我们到目前为止在示例中使用的——按需要做什么类型的工作来拆分任务。

模式2：空间分解

你也可以按文件或目录结构拆分。当你在处理大型代码库有很多可以独立处理的文件时，这特别强大。

假设你正在进行大规模重构——也许更新所有API端点到新的认证系统，你有很多跨不同服务的文件。

你按空间分解：

• • 智能体1处理/services/users/*
• • 智能体2处理/services/orders/*
• • 智能体3处理/services/payments/*
• • 智能体4处理/services/notifications/*

在这种情况下，你通过确保智能体在代码库的不同部分工作来最小化冲突。它们可以并行工作。但如果你的文件之间有复杂的依赖关系，空间分解就会崩溃。

模式3：时间分解

模式3是将任务分解为顺序阶段，其中后期阶段依赖于早期阶段的完成。

让我们用产品发布作为例子。你不能某天醒来就开始发送促销邮件。有一个逻辑顺序：

阶段1：市场研究 — 分析竞争对手，调查目标客户，识别定位机会阶段2：发布计划 — 定义信息，设置定价，创建时间表，识别渠道阶段3：资产创建 — 撰写文案，设计图形，构建登录页面，准备邮件序列阶段4：发布和监控 — 执行活动，追踪指标，响应反馈，实时调整

每个阶段都有自己的智能体或智能体团队。阶段2直到阶段1完成并审核后才开始。

模式4：数据驱动分解

最后，我们可以按数据分区拆分。这个不太常见，但对某些用例非常强大，特别是涉及可以分区数据和处理块独立的大型数据集的任务。

假设你正在分析应用程序日志以识别性能问题。你有上个月的大量日志。

你按时间或服务分区：

• • 智能体1处理第1周日志
• • 智能体2处理第2周日志
• • 智能体3处理第3周日志
• • 智能体4处理第4周日志

每个智能体独立运行分析，然后在最后汇总结果。

你也可以混合这些模式。例如，全栈功能可能使用功能分解作为主要结构（前端、后端、数据库），但后端智能体在内部使用时间分解（设计API → 实现逻辑 → 添加测试）。

提高质量

好了，假设这时候我们有一个工作系统，我们已经做了全面评估发现错误，我们仍然对性能不满意。以下是该怎么办。

首先要理解的是，你处理的是两种根本不同的组件类型，它们需要不同的改进策略。

首先是非LLM组件。这些是像网络搜索、RAG检索、代码执行、语音识别、视觉模型、PDF解析器之类的东西。

这些可以通过两种主要方式改进：

• • 调整旋钮。 摆弄像网络搜索日期范围、top-k结果、RAG块大小、相似度阈值之类的东西。
• • 或者，切换提供商。 尝试替代网络搜索API。不同的OCR或视觉模型，等等。

然后我们有LLM组件。这些用于生成、提取、推理——任何你使用语言模型本身的地方。

我们可以做很多事情来改进这部分：

• • 更好的提示。 添加明确的指令、约束、模式。使用少量输入输出对向模型展示你想要什么。
• • 尝试其他模型。 有些模型更擅长遵循指令，有些擅长代码或事实回忆。不要假设一个模型对所有事情都是最好的。
• • 将困难任务分解成更小的块。
• • 最后才考虑微调。 微调很强大但代价高昂。把它留给你需要最后几个百分点质量且你已经用尽其他一切的成熟系统。

减少延迟

搞定输出质量应该是你的第一步。之后，让我们谈谈减少延迟。

1. 1. 获得基线

第一步是对工作流程中的每一步进行计时。你可能会发现像LLM生成搜索词需要7秒，网络搜索需要5秒，起草文章需要11秒等等。

这给了你一个基线，这样你就知道应该优化什么。

1. 2. 并行化

接下来，运行任何可以并行运行的东西。例子可能是网页获取、多次搜索或解析多个文档。这通常是最容易的胜利。

1. 3. 正确调整模型大小

在任务简单的地方使用更小更快的LLM，如关键词生成，把重量级模型留给综合和推理。

1. 4. 尝试更快的提供商。

吞吐量和token流速度差异很大。优化良好的服务提供商可以在不做任何提示更改的情况下减少几秒钟。

1. 5. 最后，修剪上下文。

更短的提示和上下文意味着更快的解码，所以尽量只保留步骤真正需要的东西。

降低成本

在质量和延迟得到控制后，你准备好看看成本了。首先，你要像测量延迟一样测量每一步的成本。

智能体系统有几个成本来源：

LLM调用： 这由输入token和输出token决定。它们通常分别定价（输入token更便宜，输出token更贵）。

API调用： 像网络搜索、PDF转换、图像生成、语音转文本之类。这些通常有按调用或按单位定价。

基础设施： 如果你运行自己的检索系统、向量数据库或代码执行计算。

假设你正在构建一个写文章的研究智能体。一次运行的成本可能是这样的：

如果你每天运行1000次，那是每天80美元或每月2400美元。

• • 首先攻击大桶。 如果网络搜索每次调用成本2美分，你每次运行调用10次，那就是20美分。尽最大努力减少调用、缓存结果或批量查询。
• • 分层你的模型。 在简单任务上使用便宜模型，只在真正重要的地方使用前沿模型。
• • 积极缓存。 确定性结果如搜索响应、嵌入、块检索或中间摘要不应该每次都重新计算。
• • 约束输出。 用指令要求结构化、简洁的结果，如"返回带有这些必需字段的JSON。" "最多给我5个要点。" 更少的token，更低的账单。
• • 以及批量处理。 如果你处理很多类似的项目，尽可能捆绑操作。例如，在AWS上批量处理是按需成本的50%。

可观测性和监控

所以你有了一个质量、延迟和成本都满意的系统。现在我们需要确保它扩展后继续按预期运行。

这就是监控和可观测性发挥作用的地方。可观测性涵盖可调试性、质量监控和幻觉追踪。基本上，任何帮助你观察智能体行为和性能的东西。

棘手的是AI系统的可观测性与传统软件根本不同。

对于传统软件，你可以追踪清晰的执行路径。函数A调用函数B，函数B查询数据库，返回数据，渲染页面。诸如此类。

AI系统不那样工作，原因有很多：

• • 它们是非确定性的。相同的输入可以根据模型响应产生不同的输出。你不能只是重放请求并期望相同的结果。
• • 它们有分布式执行，工具并行运行，智能体生成子智能体等等。
• • 有很多潜在故障点的外部依赖，这些都在你控制之外。
• • 还有更多！

为了管理这一切，我们需要两种可见性：

• • "放大"指标帮助你调试单次运行。这是你的完整追踪：提示、工具调用、token使用、重试尝试和每个决策点。基本上重现错误和准确看到哪里出问题所需的一切。
• • "缩小"指标告诉你整个系统在多次运行中的表现。这包括自动化质量检查（通常使用LLM作为评判器）、幻觉率、成功/ROI度量，以及显示更改是在帮助还是在损害的趋势线。

你不仅要记录智能体做了什么，还要记录为什么这样做。例如，你可能记录："智能体选择使用网络搜索而不是RAG，因为查询包含'recent'"或"反思阶段识别出3个问题：缺少引用、日期模糊、语气错误"

当你同时运行数千个智能体时，你不能手动查看每个追踪。这就是质量采样的用武之地。不是深入检查每个单独的执行，而是定义一个采样率——比如一定百分比的总运行——来评估质量和幻觉。系统然后使用那部分执行来计算智能体的整体质量分数和幻觉分数。

这让你能够优先修复和改进领域。

除了技术指标，你还需要了解用户行为。

• • 人们实际在问什么？ 他们按预期使用你的智能体，还是找到了创意变通方法？
• • 他们在哪里卡住了？ 他们会重新措辞和重试吗？那是一个信号，说明第一次尝试没有成功。
• • 他们用输出做什么？ 如果他们立即要求修改，初始质量不够好。
• • 会话多长时间？ 很短的会话可能意味着快速成功或立即失败。很长的会话可能意味着智能体有能力但效率不高。

这些定性数据与你的技术指标一样指导你的产品路线图。

安全

最后，我们需要谈论构建健壮系统中最不令人兴奋但最重要的部分：安全。

就像可观测性一样，AI智能体的安全不同于传统应用程序安全。你不只是保护免受外部攻击——你实际上必须保护免受你自己的系统做出危险决策或被操纵成有害行为的侵害。

这些是要注意的事项：

• • 提示注入： 用户输入或外部数据中的恶意内容劫持你的智能体指令
• • 不安全的代码生成： 智能体编写访问敏感数据或执行危险操作的代码
• • 数据泄漏： 通过智能体输出或工具调用暴露的PII或专有信息
• • 资源耗尽： 智能体启动昂贵的操作或无限循环

让我们特别深入研究代码执行。代码执行是智能体的终极工具。它非常强大，因为智能体可以编写代码来生成图表、创建markdown文件、处理数据，通常可以在你给它们的范围内"做任何它们想做的事"。

这是一把双刃剑。

许多任务可以被定义良好的自定义工具覆盖，所以你的系统并不总是需要回到自由形式编码。但当你确实启用它时，你需要护栏。

以下是如何安全地执行代码：

• • 沙箱执行。 使用Docker或受限运行器环境。将代码执行与主应用程序完全隔离。代码应该在一个容器中运行，每次执行后被销毁。
• • 资源限制。 设置超时、内存上限、CPU限制。阻止危险导入，除非明确需要网络访问，以及在你指定的临时目录之外的文件系统写入。
• • 仅白名单库。 只允许特定的、安全的库如pandas、numpy或datetime。不允许任意安装。如果智能体需要一个库，你明确地将其添加到白名单。
• • 验证加反思循环。 如果代码执行出错，捕获traceback并让模型修复代码。给它一到两次尝试，并确保你有断路器。
• • 确定性I/O。 让代码返回一个小而结构化的结果——一个数字、一个列表、一个JSON对象。然后你为用户格式化。不要让代码直接输出给用户或写入他们可以访问的文件。
• • 以及输入和输出清理，这样所有输入在到达智能体之前都被验证，所有输出都扫描敏感数据如API密钥或PII。

这就涵盖了高级部分！有了所有这些，你就准备好构建能在生产中扩展和服务用户的真实系统了。

Bonus

但正如承诺的，我们为超级高级用户准备了一个额外的Bonus。

我们今天讨论的大部分内容假设你使用像LangGraph或CrewAI这样的框架。但如果你是一个对理解Claude Code等智能体工具的内部工作原理感兴趣的开发者，我强烈推荐这篇关于智能体系统设计的博客：

它涵盖了像三个核心层（终端UI、LLM"智能"层和工具层）、如何使用异步生成器构建反应式命令循环、流式+工具调用的模式，甚至还有一个并行执行引擎和智能工具调度（读vs.写），看起来很像在Claude Code和Cursor底层驱动的东西。