为何生产环境中的AI智能体需要比优质提示词更多的条件

在演示中，人工智能智能体看起来简直易如反掌。给大型语言模型设定一个目标，连接几款工具，加入一些记忆功能，再将其置于循环结构中。很快它就能进行推理、调用API、搜索文档并完成任务，最初的构建过程仿佛带有魔法般的效果。而真正的工程工作才刚刚开始。

一旦投入足够时间研究智能体系统，核心问题就会发生变化。让模型变得足够智能已不再是难点，更棘手的问题是如何将一个聪明但非确定性的组件整合进一个整体行为仍可预测的系统中。几乎所有的架构选择都是由此决定的。

不仅仅是带工具的大型语言模型

通常的简化说法是，智能体由大语言模型、工具和记忆组成。这种说法有助于解释概念，但在实际应用中并不够全面，因为真正需要考虑的因素还包括推理、上下文、工具、状态、工作流程、约束规则、可观测性以及恢复能力。大语言模型固然重要，但它只是其中一个组成部分。

以文档分析智能体为例。用户上传文件并请求进行分析，而系统在处理这一请求时可能需要完成以下操作：

1. 检查请求是否有效。
2. 从文档中提取信息。
3. 获取相关上下文。
4. 构建合适的提示词。
5. 让模型根据这些证据进行推理。
6. 验证模型返回的结果。
7. 调用额外的工具。
8. 计算必须精确的结果。
9. 保存分析结果。
10. 向界面报告处理进度。
11. 重新尝试任何失败的操作。

记录日志和追踪信息，以便日后调试。

此时工作已不再是简单的界面设计，而是包含大语言模型的分布式系统设计。明确划分职责会有所帮助。

输入与上下文

上下文包括智能体对当前任务的了解：用户指令、文档、数据库记录、前期步骤的工作流状态、获取的知识以及应用元数据。关键在于，增加上下文并不一定有好处——向模型提供过多信息只会带来噪声、提高成本，并使它的推理过程更难预测。应力求使用最少的上下文来支撑决策。

推理层

这就是大语言模型发挥作用的地方。它能够解读含糊的信息、阅读文档、对比证据、选择工具、撰写解释、对事物进行分类以及规划下一步行动。有一条规则值得强调：不要把那些普通代码就能可靠处理的决策交给模型。

假设某条业务规则为 差异率 <= 5% → 通过。其实根本不需要大语言模型来判断3.8%是否低于5%，直接计算即可。在需要推理的情况下使用模型，在能够确定结果的情况下则用代码。这样的分工能让智能体系统更易于测试。

工具让智能体变得实用

没有工具的大型语言模型主要负责描述动作，而拥有工具后则能实际执行这些动作。常见的工具包括搜索功能、数据库、API、文档检索、代码执行、内部服务以及工作流系统。通常的流程是从用户请求开始，由智能体选择工具并执行，观察执行结果后再继续下一步。

这正是ReAct模式的核心：推理、行动、观察，然后再进行推理。该模式的强大之处在于智能体无需预先掌握所有信息，可以在任务执行过程中随时查找所需内容。

每个工具也都是可能出现故障的环节。API 可能会超时，凭证可能过期，数据库可能宕机，工具可能会返回格式错误的数据，模型也可能会传入错误的参数。调用工具绝不能仅仅意味着将大语言模型的请求发送给 API 然后寄希望于最好的结果。实际应用中需要具备验证机制、超时设置、重试功能、错误处理措施、权限控制以及明确的故障状态定义。

记忆并非囤积行为

在智能体设计中，记忆是最容易被误解的方面之一。人们通常认为，记住更多信息的智能体会更聪明，但事实往往并非如此。如果将每一次交互都永久存储下来并全部注入后续请求中，智能体得到的将是杂乱无章的信息而非真正的记忆。

采用分层思维会有所帮助：

• 工作记忆用于存储当前任务所需的信息，比如工作流程状态、最近的工具处理结果以及中间计算结果。
• 长期记忆用于存储在不同任务中都有用的信息，比如用户偏好、之前已确认的事实以及历史结果。
• 外部知识是指已经存储在其他地方的数据，仅在需要时才会被调取，比如文档、政策文件、数据库记录以及向量搜索的结果。

关键问题不在于智能体能记住多少信息，而在于它此刻需要了解什么。这种思维方式的转变就能显著简化系统架构。

处理多个智能体时要谨慎

多智能体架构非常有趣。协调器可以派生出文档处理智能体、研究智能体、验证智能体和报告智能体，每个智能体负责问题的不同部分。虽然这样的图表看起来很吸引人，但不应作为默认的起点。

每增加一个智能体就会带来新的提示、状态转换、故障模式、通信边界，以及更高的延迟和更多需要调试的问题。一个拥有三件优质工具的智能体往往比四个互相交流的智能体更有效。

一个可行的原则是先从能够解决问题的最简单设计开始，只有当明确需要独立推理或承担责任时才增加智能体。多智能体设计应旨在解决架构问题，而非仅仅为了让整体看起来更出色。

故障规划

想象这样一个工作流：上传文档、提取内容、获取上下文、进行分析、调用工具并生成报告。但现在，在分析完成后代理程序就崩溃了。所有操作都需要重新开始吗？是否有内容已经被写入数据库？重复执行该操作安全吗？界面还会显示任务正在运行吗？还有其他工作节点可以接手这个任务吗？

这时，传统的后端工程技术就显得至关重要了。生产环境中的代理程序需要：

• 重试机制，以避免临时故障破坏整个工作流。
• 幂等性，确保重试不会产生重复的副作用。
• 检查点，让漫长的工作流能够知道哪些步骤已经完成。
• 超时设置，因为代理程序不应无限期地运行。

断路器机制与限制，包括迭代次数、工具调用次数、成本以及运行时间的上限。

明确的状态标识，如QUEUED → RUNNING → COMPLETED或QUEUED → RUNNING → FAILED → RETRYING。

这些听起来都不如提示工程那么吸引人，但正是它们让智能体具备可信度。

查看智能体的操作过程

普通应用程序已经需要日志和指标，而智能体则需要更多。当智能体产生错误结果时，仅知道HTTP请求返回了200 OK几乎无法说明问题。真正重要的是整个流程：请求的发起、上下文的获取、提示语的构建、模型的调用、工具的选择、工具的执行、结果的评估以及最终响应。

对于每次运行，团队都应能够获取以下信息：

• 智能体所接收的上下文
• 运行的模型
• 调用的工具及其顺序
• 每一步所耗时间
• Token消耗量
• 失败原因，是基础设施问题还是推理问题
• 评估环节的结论

这就是追踪与评估为何会成为智能体生态系统中如此重要组成部分的原因之一。无法观察到的问题就无法得到改进。

测试非确定性行为

传统软件遵循一条简单的规则：输入A会产生输出B。而大语言模型并不一定如此，因为两个正确的答案可能用完全不同的方式表达。因此测试需要多层验证。

确定性部分会通过常规方式进行测试：API、计算、模式、状态转换以及数据库操作。而模型驱动的部分则从事实准确性、完整性、相关性、推理质量、工具选择以及指令遵循等方面进行评估。真实的端到端工作流程应使用具有代表性的数据来运行，这样才能发现孤立提示所遗漏的问题。即便拥有强大的工具组合，也无法覆盖所有现实世界的输入情况，因此部署后仍需持续进行评估。

自主性需兼顾风险控制

有些人认为“真正的”智能体必须具备完全的自主性。这种观点忽视了风险控制的重要性。以三种操作为例：总结文档、建议修改财务记录以及自动执行高影响交易。它们不应采用相同的审批机制。合理的安排应如下所示：

• 低风险：自动执行。
• 中风险：先执行，再记录日志或进行审核。
• 高风险：执行前需人工批准。

目标并非最大程度的自主性，而是具有可控风险的实用自主性。

综合来看，情况已经很清晰了，而大语言模型在其中其实只是个相对较小的部分。这是有意为之。

选择框架前的问题

在挑选框架或编写复杂的提示语之前，有几点问题值得思考：

1. 哪些决策真正需要人工智能？ 单一的推理步骤并不足以让整个工作流程具备智能性。
2. 哪些部分可以保持确定性？ 计算、验证、权限控制以及关键的业务规则都应该放在代码中。

代理真正需要什么上下文？应选择性地获取信息，避免输出完整的提示内容。

如果它在执行过程中出错会怎样？应在正式投入使用前设计好重试与恢复机制。

如何评判质量？在为首个成功的演示庆功之前，先明确评估标准。

六个月后如何进行调试？从一开始就建立追踪机制和结构化的日志记录。

是否有必要使用多个代理？如果理由无法阐明，或许现在还不需要。

提示词工程、模型选择和RAG依然重要。但实际应用需要更全面的考量：以概率智能为基础构建的软件架构。最优秀的设计并非拥有最多智能体、最大模型或最复杂的编排框架，而是能够明确界定智能体的知识范围、能力边界、正确性评估标准、故障时的处理方式以及系统的恢复机制的设计。唯有如此，AI智能体才能从简单的演示工具转变为值得信赖的软件。