你不需要任何技术背景就能读懂 以下内容 。虽然新的AI工具或框架几乎每天都在涌现，但大多数基础知识都可以归结为 以下 涵盖的概念。这正是我在开始构建智能体系统时梦寐以求的参考资料。

1. 提示：基础

所有生产级人工智能系统都始于一件事：一个精心编写的提示。如果你用过 ChatGPT 或 Claude，你肯定知道提示是什么。你输入一些内容，模型就会做出回应。就这么简单。

但“嘿，帮我总结一下”和无需人工干预就能可靠运行数千次的提示之间存在着巨大的鸿沟。生产环境中的提示是精心设计的，而不是手动输入的。

提示结构框架

一个结构良好的提示包含五个组成部分，你对每个部分的定义越精确，你的输出结果就越可预测。

提示类型

即使有了结构完美的提示，如何使用它也至关重要。主要有三种提示策略，每种策略都在简洁性和准确性之间权衡取舍。

零样本学习法是最简单的。你给人工智能一个没有任何示例的任务，然后期望它能自己完成。“把这句话翻译成法语：会议在下午3点。” 当任务定义明确且模型已经掌握了模式时，这种方法效果很好。

少样本训练法是更进一步。你需要提供几个输入输出对的示例，以便模型理解你想要的确切模式或格式。与其用文字描述你的需求，不如直接展示给模型：“这里有三个邮件摘要的示例。现在请你摘要这封邮件。”这种方法在确保格式和语气的一致性方面出奇地有效。

思维链是关键所在。它不直接给出答案，而是要求人工智能逐步推理问题，最终得出结论。这正是 OpenAI 的 o1 或 Claude 的扩展思维模式等“推理模型”的驱动力。它以速度换取准确性，是处理复杂分析任务的理想选择，因为快速给出答案会忽略细微差别。

2. 从随意使用到生产系统

如果你用过 ChatGPT 或 Claude，你可能已经摸索出一套方法：发送消息，得到一个不太满意的回复，调整你的提问，再次尝试，如此重复三四次，直到得到满意的结果。这种方法在你作为人工参与者，手动引导对话时确实有效。

但在生产系统中，软件需要每天可靠、自动地执行数千次这样的操作。没有人会坐在那里点击“重新生成”或“在新消息中发送新指令”。你承担不起重试的风险。

解决方案看似简单：不要要求一个模型一次性完成所有任务。相反，首先要弄清楚人工操作的工作流程，即人类完成这项任务需要哪些步骤？然后将这些步骤分解成更小、更独立的部分，并将每个部分分配给一个专门负责的AI代理。

这就是智能体人工智能系统的核心理念。它并非采用单一模型包揽一切并寄希望于万无一失，而是将问题分解为若干个专注的步骤，每个步骤都由一个更小、更便宜、更可靠的智能体来处理。这种综合效应使得系统运行速度更快、可预测性更高，并且在出现故障时也更容易调试。

3. 子代理和模型参数

既然你已经了解了分解事物背后的“原因”，那么让我们来看看构成事物的基本要素。

子代理是指被分配到大型工作流程中某个特定、狭窄任务的 AI 模型。例如，一个代理从 PDF 发票中提取数据，另一个代理将提取的数据与数据库进行比对，第三个代理则负责格式化并发送确认邮件。由于每个子代理都专注于一项特定的任务，因此您可以使用更小、更快、更经济的模型，而不是使用一个功能强大的模型来完成所有工作。

但仅仅选择合适的模型是不够的，还需要调整模型的运行方式。其中最重要的参数就是温度。

温度控制着模型输出的“创造性”或“随机性”。可以把它想象成一个光谱。在低端（接近 0），模型会采取保守策略，每次都选择最可预测的答案。问同一个问题两次，你会得到相同的答案。这正是你希望在确定性任务（例如从文档中提取数据或对支持工单进行分类）中使用的模型。

在高值（接近 1）时，模型会承担更多风险，探索更广泛的可能性。每次运行的输出结果都会有所不同。这对于头脑风暴、写作或创意生成等创造性任务非常有用。

经验法则很简单：如果任务需要一致性，就降低 温度 ；如果任务需要创造性，就提高 温度 。

4. 智能体工作流范式

您已经有了子代理。现在您需要一种方法将它们连接起来。主要有两种范式，理解它们之间的区别是您最重要的架构决策之一。

第一种是基于链式的工作流。这是最简单的模式：代理 1 的输出输入到代理 2，代理 2 的输出输入到代理 3，依此类推。线性、可预测、易于调试。LangChain是构建此类工作流最流行的框架。它的主要优势在于抽象性 → 它不关心底层使用的是 Claude、GPT-4 还是其他任何模型。切换模型提供商只需极少的代码更改。它还提供了用于连接数据库、内存管理和输出格式化等常见任务的现成组件，因此您可以编写的样板代码大大减少。

第二种是基于编排的工作流。这正是它的强大之处。它不再采用固定的线性流程，而是在系统顶端设置一个单一的编排器代理。你需要告诉它有哪些子代理可用，以及每个子代理的功能。当收到任务时，编排器会读取任务信息，制定执行计划，并决定调用哪些子代理、调用顺序以及如何处理它们的输出。

关键区别在于：编排可以是循环的。编排器可以调用代理 A，将其输出发送给代理 B，获取返回结果，然后决定是否需要使用新信息再次调用代理 A，如此循环往复，直到满足某个条件。LangGraph框架正是为此而设计的。它扩展了LangChain，二者的区别就在于此：LangChain 用于线性链，而 LangGraph 用于基于图的工作流，可以动态地分支、循环和路由。

思考方式如下：如果你的任务是“先做A，再做B，再做C，完成”→ 使用链式流程。如果你的任务是“弄清楚需要做什么，然后根据情况调整”→ 使用协调器。

5. 能动模式

除了智能体之间的连接方式之外，单个智能体在执行任务时如何推理和行动也遵循既定的模式。其中最重要的两种模式是“ 反馈 ”（ReAct）和“计划与执行”（Plan and Execute）。

ReAct（推理与行动）是一个循环。当智能体接到任务时，它不会立即给出答案。相反，它会循环执行三个步骤：推理（我已知什么，还需要什么？）、行动（调用工具，获取数据）和观察（这些信息足以回答问题吗？）。如果答案是否定的，它会循环回到推理阶段并再次尝试。

这种模式之所以强大，是因为智能体具有适应性。它不会预先设定固定的计划，而是根据每一步的实际情况做出反应，这使得它非常适合那些事先不知道答案路径的任务。

计划与执行模式则采用了相反的方法。它并非逐步推理，而是先构建一个完整的计划，然后再执行任何操作。计划代理生成完整的分步分解方案，然后执行代理按顺序执行该计划。其优势在于可预测性和效率，因为您可以预先了解完整的计划，从而更容易并行化步骤、估算成本和调试故障。缺点是执行过程较为僵化：如果在执行过程中出现意外情况，则可能需要修改计划。

选择哪种方式取决于任务的性质。如果任务具有探索性或不可预测性，需要智能体根 据发现的情况进行调整，则应使用 ReAct。如果任务定义明确，需要效率、并行处理以及清晰的执行过程跟踪，则应使用 Plan and Execute。

6. 情境工程

只有掌握正确的信息，你的AI代理才能做出正确的决策。上下文工程是一门研究如何高效地将哪些信息注入到每个提示中的学科。

最简单的做法是将所有用户数据都塞进每个提示框。问题在于：提示框会变得非常庞大、运行缓慢且成本高昂。人工智能模型按 词元 （大致按字数）收费，因此，如果您只需要其中的两个段落，却发送一份 50 页的文档，那纯粹是浪费钱。

明智的做法是在发送提示之前动态地获取相关信息。根据数据存储位置的不同，主要有两种技术。

如果相关数据存储在结构化数据库（行和列）中，您可以使用工具调用运行 SQL 查询，并仅提取相关行。例如，用户询问“我的订单状态是什么？”→ 系统会查询订单数据库，找到该用户最近的订单，并将这些行插入到提示框中，客服人员即可准确回答。

如果相关数据以非结构化形式存在（例如文档、PDF、笔记、电子邮件），则无法直接运行 SQL 查询。这时就需要用到RAG（检索增强生成）。你需要构建一个流程，将所有文档分割成小块，并将这些小块转换为数值向量（一种用数学方式表示含义的方法）。当收到查询时，流程会找到与查询含义最接近的小块数据。这样，人工智能只会看到知识库中最相关的部分，而不是全部。

关键在于，上下文工程的重点在于精准性，而非数量。提示信息中无关的干扰信息越少，智能体的表现就越好。

7. 能力工程

如果说情境工程关注的是智能体接收哪些信息，那么能力工程关注的是智能体具备哪些能力和行为。这就像钓鱼一样，合适的鱼饵才能带来合适的收获。

在智能体工程中，最常用的工具是技能（Skills）。技能是一个 Markdown 文件（一个简单的文本文件），它描述了智能体在特定情况下应该如何行动。它不是用户任务提示，而是嵌入在智能体系统中的行为指南。

例如，电子邮件回复代理可能有一个名为“电子邮件回复代理”的文件email-reply-skill.md，其中规定：始终以客户姓名开头，在未检查政策工具之前绝不承诺退款，回复字数保持在 150 字以内，并与收到的电子邮件的语气保持一致。

代理程序在设置过程中会读取此技能文件，并在每次编写电子邮件时遵循这些规则。技能使代理程序的行为更可预测，也更容易更新——您只需编辑 Markdown 文件即可更改行为，而无需重写整个提示。

这两层共同构成了完整的图景。上下文工程确保你的智能体拥有正确的信息。而能力工程则确保它能利用这些信息做出正确的决策。

8. RAG 与微调

几乎每次讨论如何改进特定用例中的人工智能模型时，都会提到这两个概念，而且人们常常将它们混淆。它们解决的是截然不同的问题。

RAG（增强检索）会改变模型获取的信息。这就好比在考试前给聪明人提供一本合适的参考书。模型本身并没有改变，你只是确保它在正确的时间能够获取正确的数据。这种方法成本相对较低，你可以随时更新数据，而且它是你应该首先尝试的方法。

微调会改变模型的内部权重，也就是它的思维方式。这就好比送这个人去“学习”一年。模型会学习不同的行为方式：特定的语气、特定的格式、特定的推理风格。这很耗费资源，需要训练计算和标注数据，而且这些改变会永久地融入模型中。

经验法则：先尝试 RAG（ 检索增强 算法）。它速度更快、成本更低、更新也更方便。 只有当你确认瓶颈在于模型的行为或思维模式，而不是它所掌握的信息时，才需要进行微调。如果你的智能体总是弄错事实，那就是上下文问题 → 使用 RAG。如果你的智能体掌握了正确的事实，但表达方式或推理模式错误，那就是行为问题 → 考虑进行微调。

9. 工具调用和 MCP

你的AI代理从训练数据中掌握了大量信息，你可以利用我们刚才介绍的技术为其提供相关的上下文信息。但有时它需要实时外部数据，而这些数据既不存在于训练数据中，也不存在于你的数据库中。

假设你想让 代理 在推荐某个创作者之前先查看一下他的 Instagram 粉丝数。这个数字每天都在变化，而且不在你的系统里。这时就需要用到工具了。

定义工具时，只需给智能体提供一个简单的规范：工具名称、功能描述、所需输入和返回值。智能体无需了解实现细节，只需知道工具的存在及其用途即可。当智能体在执行任务过程中需要跟随者数据时，它会生成正确的 API 调用，获取数据并将其用于推理。

工具本质上是一个外部功能目录，你将其提供给代理程序。代理程序决定何时以及使用哪些工具。

现在，为每个外部服务手动定义工具很快就会变得非常繁琐。MCP（模型上下文协议）正是解决方案。MCP 是一种开放标准，允许外部服务以标准化格式发布其工具。您无需编写每个工具的定义，服务会托管一个 MCP 服务器，您的代理程序会连接到该服务器。连接后，代理程序会自动发现服务器上所有可用的工具，并知道如何使用它们。

您可以把它想象成一个面向人工智能代理的插件商店。像 Apify、Slack 和 Google 这样的公司都发布了 MCP 服务器。您的代理只需连接到一个端点，即可立即访问数十种工具，无需手动集成。

10. 生产环境中的可靠性：判断代理

在演示环境中让智能体系统运行一次很容易，但要在生产环境中保证其数千次正常运行才是难点。可靠性包含两个方面：确保输出结果良好，以及确保系统持续稳定运行。

法官特工

评判代理是一个独立的AI模型，它的唯一任务是审查系统的输出并判断：这是否真正正确回答了用户的问题？它会读取原始输入和最终输出，然后给出判决。

部署评判器有两种方式。在顺序部署中，每个输出在到达用户之前都会先经过评判器。如果评判器拒绝该输出，则由优化代理尝试纠正，然后循环重复，直到通过评判器为止。这种方式会增加延迟，但能保证质量，适用于对准确性要求极高的场合。

在并行架构中，用户可以立即获得答案。评委在后台进行审核，如果发现问题，系统会发出警报（通常是 Slack 消息或审核队列条目）。这样既不会增加用户的延迟，又能帮助团队发现错误。这是更常见的生产环境模式。

两个关键细节：首先，评判模型要与系统所使用的模型不同。模型往往会对自己输出的结果给予更高的评价。如果你的系统运行在 GPT-4 上，就使用 Claude 作为评判模型，反之亦然。其次，启用评判模型的“扩展思考模式”。这种模式下，评判模型会分析输出结果好坏的原因，而不仅仅是简单的通过/失败，这样可以提高评判的准确性，并为团队提供更有用的调试信息。

LLM门户网站

评估输出质量是可靠性的一个方面。另一方面则更简单：系统是否真的在运行？

每个人工智能服务提供商都有请求速率限制。一旦达到上限，你的请求就会开始失败。服务提供商有时也会宕机。如果你的整个系统都依赖于某个服务提供商的某个模型，那么他们的宕机也会影响到你。

LLM 网关位于所有模型调用之前，充当流量控制器的角色。它负责两项工作：速率限制管理（如果达到 OpenAI 的速率限制，它会将溢出流量路由到第二个 API 密钥或完全不同的提供商）和故障转移（如果某个提供商持续出现故障，它会将流量重定向到另一个提供商）。您的系统将持续运行，用户不会察觉到任何异常。

你可以把它想象成一个负载均衡器，但专门用于 AI 模型 API。像LiteLLM这样的流行开源方案也提供了统一的 API，因此你的代码无需知道它在任何给定时刻正在与哪个模型通信。

11. 智能体系统中的记忆

当对话简短明了时，内存不是问题。但如果对话长达五十条消息呢？或者当代理工作流中途崩溃需要恢复时呢？内存管理在生产系统中就成了至关重要的一环。

你已经在 ChatGPT 中看到了这种蛮力式方法。每次你发送第五条消息时，系统都会悄悄地将你之前的四条消息和四个 AI 回复打包，然后再次发送给模型。这就是 AI 如 何“记住”之前说过的话。这种方法虽然有效，但无法扩展。随着对话时间的延长，每次请求发送的令牌数量也会增加。成本上升，速度下降，最终你会达到模型的上下文限制。

更明智的做法是在系统中添加一个摘要代理。每处理完一批消息（例如每十条），摘要代理就会读取当前对话内容，并生成一个精简的内存对象：关键事实、决策和上下文，以结构化摘要的形式存储。之后，无需发送之前的全部五十条消息，只需发送精简的摘要以及最近几条完整消息即可。这样既能保持提示信息的简洁，又能保留重要的上下文信息。

但内存不仅仅用于存储对话。在多步骤代理工作流中，如果你的系统有五个子代理，并且在第三步崩溃，你肯定不想从第一步重新开始。检查点机制可以解决这个问题。每个子代理完成任务后，其输出都会保存到持久存储中。如果工作流在运行过程中失败，重试会从上一个成功的检查点继续执行。这既是一种可靠性模式，也是一种成本节约模式，避免了重复执行已经成功完成的工作而浪费计算资源。

12. 可观察性：了解实际发生了什么

构建智能体系统是一回事，了解它在每次运行中的具体行为又是另一回事。可观测性是指记录和检查智能体执行的每一步，它决定了我们最终是“出了点问题”还是“我确切地知道哪里出了问题以及原因”。

最常用的工具是Langfuse。每次代理系统运行时，Langfuse 都会记录一个跟踪信息：详细记录每一步操作，包括调用了哪个代理、接收到的提示信息、模型返回的内容、 每一步耗时以及使用的令牌数量。

这很重要，原因有二。首先是调试。当系统产生错误输出时，你无需猜测。你可以打开该次运行的跟踪日志，逐步排查。是否注入了错误的上下文？子代理是否接收到了格式错误的输入？判断代理是否正确触发？跟踪日志会告诉你答案。

其次是评估。当您试图了解系统随时间推移是在改进还是退步时，跟踪数据可以提供原始证据。您可以比较运行结果，测量子代理之间的延迟，并确定哪个步骤是瓶颈。

把可观测性想象成你系统的黑匣子记录仪。你希望用不上它，但一旦出了问题，它就是你首先要查看的地方。

13. 人机交互（HITL）

并非所有决策都应该完全由人工智能代理做出。HITL（人机交互流程）是一种设计模式，它有意在工作流程中设置环节，让人工审核、批准或调整，然后再由系统继续执行。

最简单的形式是聊天界面。每次AI回复后，用户都可以做出反应：要求修改、纠正错误或在下一步开始前进行确认。简单有效，但用户体验并非总是最佳的。

更明智的方法是使用专门设计的界面。以生成网页的AI系统为例。一个简单的HITL设计是：显示页面，让用户在聊天框中描述他们不喜欢的地方，然后重新生成整个网页。这种方法既慢又令人沮丧。更好的方法是提供直接编辑界面，用户可以点击任何元素，更改图片，修改文案，调整布局→而无需返回AI进行细微修改。AI负责繁重的工作，而用户则通过专门设计的控件进行微调。

HITL 还起到安全阀的作用。还记得前面提到的判断代理吗？如果判断代理对某个输出结果不确定，它不会直接将其发送给用户或自动重试，而是会将输出结果路由给人工审核员，并附上一条备注：“我不确定这封邮件是否应该发送。您能否在发送前审核一下？” 这对于不可逆操作尤为重要，例如发送电子邮件、进行支付、删除记录和公开发布内容。任何无法撤销的操作都非常适合设置人工审核点。

好的 HITL 设计实际上是一个 UX 问题：如何以最小的摩擦让用户在合适的时机纠正或引导系统？

14. 结构化输出

LLM 默认生成自由格式文本。如果输出内容是供人阅读，这没问题。但在生产环境中的智能体系统中，一个智能体的输出通常是下一个智能体的输入。如果智能体 2 期望特定的 JSON 格式，而智能体 1 返回的内容略有不同，那么整个流程就会崩溃。

结构化输出可以解决这个问题。与其让代理返回任意文本，不如定义一个精确的模式：一个数据结构，它指定了哪些字段必须存在以及每个字段的类型。例如，发票提取代理可能需要返回一个包含vendor_name字符串、invoice_date日期、total_amount数字和line_items数组的 JSON 对象。每次代理运行时，其输出都会在到达时立即根据此模式进行验证，然后再进行后续操作。

这一点至关重要，因为如果没有模式验证，缺失的字段可能要到流程的第三步才会导致错误，而此时追溯到原始代理将非常困难。及早发现错误可以使错误显而易见、快速修复且易于记录。大多数 LLM 提供商现在都原生支持结构化输出或 JSON 模式，而像 LangChain 这样的框架也内置了对定义和强制执行输出模式的支持。

15. 综合运用

这就是生产环境中智能体系统在所有这些组件组合在一起时的实际样子。每一层都解决特定的问题：提示层确保每个智能体都能获得清晰的指令；子智能体将工作分解成专注的小块；上下文工程确保智能体拥有正确的信息；工具工程确保它们的行为一致；工具调用和 MCP 将它们连接到外部世界；结构化输出保持管道稳定；判断智能体保障质量；内存保持上下文的有效性；可观测性便于调试；而 HITL 则确保在关键时刻人为控制。

这就是全貌。这些层级并非孤立存在，而是协同工作。上下文工程为协调器提供正确的信息。协调器具备相应的技能，将任务分配给专注的子代理。这些代理使用工具和 MCP 与外部世界交互。结构化输出确保数据在它们之间顺畅流动。判断代理在错误到达用户之前将其捕获。内存确保上下文在长时间对话和多步骤工作流中保持有效。可观测性记录所有信息，以便进行调试和改进。而 HITL 则确保在关键时刻，人始终参与其中。

几乎每天都有新的AI工具或框架发布，但其基本原理变化并不快。如果你理解了这些概念，你就拥有了评估任何新事物的思维模型。

本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓