提示词漂移，智能体失控的元凶？黄金轨迹如何守护你的应用

引 言

智能体 AI 建立在推理、执行和再推理的理念之上，直到 LLM 判定某次执行的目标已完成为止。在针对多种智能体方法的研究中，使用 GPT‑3.5 和 GPT‑4 的零样本方式在编码基准测试中分别达到了约 48% 和 67% 的准确率，而基于 GPT‑3.5 的迭代循环智能体 AI 则达到了 95.1% 的准确率。

即使使用相对老旧的模型，迭代式智能体的循环机制所带来的提升也超过了从 GPT‑3.5 到 GPT‑4 的基础模型升级。这对企业来说意味着什么呢？吴恩达在 Scale Up 的采访中表示，这意味着对大多数企业而言，利用智能体 AI 构建实用应用程序应成为优先事项，而非追逐最新的基础模型。

从原型到生产的鸿沟

在传统软件开发中，会首先通过原型来验证概念，再使用类似但更大规模的流程构建应用程序并将其部署到生产环境。对智能体 AI 而言，整体概念基本一致，但存在一个本质区别：智能体不具备行为一致性，因此原型的受控环境无法代表真实的环境。智能体系统面临的是非确定性行为、涌现能力（emergent capabilities）与自主决策。例如，对非确定性系统的测试，完全与成熟的软件工程中“输入—固定的预期输出”的测试场景不同。

理解智能体开发

企业级团队在不断尝试扩大智能体 AI 的应用范围，在此过程中会面临经典的产品市场适配问题。这一切均起源于两个截然相反的问题：“目前，是否存在可通过智能体 AI 解决的问题？”

vs.“

既然我想应用智能体 AI，那么哪些现有的问题最适合作为切入点？”

有一点需要明确，几乎不涉及任何主观决策的确定性工作流，用传统方法实现效果更好。智能体 AI 的优势在于处理非确定性的决策，并基于这些决策执行现实的动作。

AI 系统的软件开发生命周期（SDLC）具有本质不同的特性。A. Gill 的敏捷研究指出了 AI 系统区别于传统软件的六个属性：自主性、自适应性、内容生成、决策能力、可预测性和推荐能力。这些属性要求“在敏捷 SDLC 框架内集成决策科学”，从功能开发转向行为编排。

同样，国际标准化组织发布了 ISO/IEC 5338:2023“信息技术 — 人工智能 —AI 系统生命周期流程（Information technology – Artificial intelligence – AI system life cycle processes）”，建立了首个全面的 AI 系统开发框架。该标准强调全流程风险管理，并明确要解决自主系统行为验证所面临的挑战。

这些范式都反映出，我们构建非确定性系统软件的方式正在发生更深层次的变革。

架构与设计模式

在深入开发实践之前，我们回顾一些对智能体应用开发有帮助的架构与设计模式。开发者可使用这些通用设计模式简化智能体应用的开发。

智能体控制 LLM 的输入与输出，使 LLM 始终返回结构化的输出，这可以被解析并转换为一个或多个函数调用（称为智能体的工具）。智能体只需要在工具引用池中查找对应的工具，并使用 LLM 输出提供的参数进行调用即可。

这个过程可以仅执行一次，也可以按照各种设计模式循环执行。

智能体应用开发的核心架构模式

以下核心模式覆盖了绝大多数的生产场景，智能体应用开发者需要熟练掌握这些核心概念。

ReAct 智能体

下图展示了在宏观层面上 ReAct 智能体循环中的单次交互流程，步骤从 1 到 8 编号，每次迭代会重复执行，直到满足终止条件。图 1：ReAct 智能体循环

图 1：ReAct 智能体循环

ReAct 模式特别适合智能体需要迭代调查问题的工作流。例如，数据库调试智能体可以执行查询、分析性能缓慢的现象、检查现有索引，并持续循环直到找到根本原因。以下是核心 ReAct 循环（推理→执行→观察）的伪代码片段：

监管者智能体模式

图 2：监管者智能体模式

分层的智能体模式

例如，电商订单的履约系统可使用分层模式：总履约智能体协调区域监管者（北美、欧洲、亚洲），每个区域监管者管理专用的仓库智能体，负责库存检查、拣货、打包和发货。

下图展示了分层的智能体模式：

图 3：分层的智能体模式

人工介入模式

许多工作流存在一些特殊的决策点，这些决策点必须要由人工监督和审批才能推进。这类场景可以结合 AI 驱动的高效率与人工的决策 / 审核，实现巨大的生产力提升。微软的 Magentic-UI 研究了专门聚焦人工介入（human-in-the-loop）的智能体系统。

我们以贷款审批工作流为例说明该模式。

图 4：人工介入模式

其他可参考的模式

下表列出了其他的智能体 AI 模式及链接，供进一步学习。

表 1：其他模式的参考表

规划智能体实现

第一步，通过多轮迭代回答几个简单问题，找出应用中适合智能体 AI 的组成部分。答案在多轮迭代中的演进有助于简化决策。

表 2：智能体 AI 组件的迭代评估示例

完成以上宏观层面的分析后，我们就可以开始设计各工作流的能力矩阵（参见表 3），或规划其他的开发活动了。

认真执行上述流程可以作为后续开发的指导清单。例如，上表中的第三个问题（即“是否为每个工作流准备了能力矩阵？”）可以用来为应用的每个工作流创建能力矩阵（参见下一节的表 3），这样就能将每个工作流范围拆分为智能体与非智能体部分。需要记住，智能体涉及 LLM 调用与工具调用，可能以循环方式运行。从基于 LangSmith 的智能体追踪图中可以看到（参见图 5），LLM 调用会引入显著延迟，因此我们不希望用智能体实现确定性或固定规则的组件。这里的指导原则是，如果代码可以基于固定规则做出清晰无歧义的决策，那么应用中的这些部分就不需要智能体推理，因为通过 LLM 实现的智能体推理会牺牲简洁性与性能。

实现智能体的功能（能力矩阵法）

智能体应用开发中最常见的一个反模式就是试图将所有内容都智能体化。基于我们上述的原则，智能体应用的需求分析必须包含一个系统化的流程，识别应用的哪些部分应利用非确定性的 LLM 推理，哪些部分应采用确定性的规则。对某些更适合确定性实现的任务，必须避免这种反模式。我们以一个智能体客服系统为例，该系统编排了端到端的客服工作流。表 3 列出了该示例工作流的每一步，并说明实现目标的正确方式。

我们将每个工作流步骤进行拆解，分析其应为确定性的（基于规则、可预测）还是非确定性的（需要 LLM 推理）。核心要点就是，大多数生产应用会同时包含确定性（固定规则）与非确定性（基于推理）的能力。

表 3：工作流能力矩阵

大多数应用即便适合采用智能体方案，仍然会有相当一部分功能应基于规则而非智能体来实现。

架构与开发应该由可靠的需求来驱动。没有模糊解释，或者会导致明确失败并阻塞功能的场景，必须要使用确定性方式的实现，例如，SLA 应基于工单类型设置为固定的值，或者，工单 ID 的生成要遵循固定逻辑。存在多种合理解释的功能可以从 LLM 推理中获益，例如，基于当前方案与用户个性化生成不同的措辞、不同的 API 调用或查询。

成本优化也应该考虑进来，因为 LLM 调用成本较高，应该仅用于真正的非确定性任务。因此，任何智能体工作流或用例都应定义如下的内容：宏观层面的确定性容器，定义工作流的边界每个工作流步骤的映射基于推理需求的工作流步骤分类开发工作流开发者工作流 — 实现智能体角色与规划逻辑智能体的编排方式没有限制，可顺序、并发或使用任意的协调策略。但大多数的应用可归入某个标准的编排模式。微软 Azure 的智能体编排研究指出了五种主要的协调模式，每种都针对不同的运营需求进行了优化：

图 5：顺序编排（参考微软的编排模式）

并发编排

多个智能体并发执行任务并汇总结果。该模式能够降低独立子任务的延迟。Google Cloud 的 Agent Assist 体现了并发处理优势，客服对话处理量提升了 28%，响应速度加快了 15%。

图 6：并发编排（参考微软的编排模式）分层编排

自主级别设计

开发者工作流 — 版本管理智能体系统带来了更复杂的版本管理需求。与典型非智能体后端应用的标准版本管理相比，智能体系统引入了多个新的交叉节点，从而产生了新的故障点，例如，系统提示词、工具、LLM 配置和其他资源。我们逐一评估这些组件的版本管理方式。

工具清单

使用 JSON/YAML 规范定义可用函数、参数与权限需求。工具清单（tool manifest）需要类似软件包那样的依赖管理功能，因为工具添加或修改可能从根本上改变智能体的能力。例如，如果将工具调用的输出加入下一次 LLM 调用的提示词中，这可能会影响智能体工作流下一步的 LLM 决策行为。

下图描述了通用版本管理流程中所涉及的版本化组件。图 7：智能体版本管理组件点击查看大图 版本化控制的提示词与策略需要说明的是，提示词是控制智能体系统中 LLM 行为与决策的最直接的方式，因此需要精细管理以避免出现（有意或无意的）漂移。事实上，RisingWave 的研究将提示词漂移列为最关键的故障模式。大多数生产环境的智能体故障都可追溯到不受控制的提示词修改，这些修改与系统更新或数据变化产生了不可预测的交互。

图 7：智能体版本管理组件

版本化控制的提示词与策略

需要说明的是，提示词是控制智能体系统中 LLM 行为与决策的最直接的方式，因此需要精细管理以避免出现（有意或无意的）漂移。事实上，RisingWave 的研究将提示词漂移列为最关键的故障模式。大多数生产环境的智能体故障都可追溯到不受控制的提示词修改，这些修改与系统更新或数据变化产生了不可预测的交互。

因此，提示词应被视为基础设施即代码（Infrastructure as Code，IaC），存储在 Git 仓库中，并遵循正式的变更审批流程。采用这种方式的组织使用渐进式的交付模式，包括提示词变更的 A/B 测试，当行为指标漂移超出可接受阈值时自动回滚（参见 Open Policy Agent）。

回归测试的黄金轨迹

那么，智能体 AI 行为回归测试的基础是什么？我认为是 “黄金轨迹（golden trajectories）” 的概念。黄金轨迹指的是经过验证的智能体交互序列，本质是追踪记录，不仅捕获最终输出，还包括完整的推理链、工具调用与决策点。LangChain 和 LangSmith 等框架允许我们对智能体的工具函数和代码的其他部分进行埋点以实现可追踪性。这种可追踪性提供了审计智能体与工具、LLM 及其他接口交互的方法。以下系统示例展示了工作流执行期间的所有智能体交互。

图 8：使用 LangSmith 追踪平台的黄金轨迹剖析

智能体的自动化测试

智能体系统的测试与传统应用的测试方法有何差异呢？智能体应用（无论是否自动化）的测试必须要基于对确定性系统与非确定性系统之间架构差异的深入理解来开展。智能体应用是非确定性的，因为它们使用 LLM 进行推理，并通过工具调用采取行动。

测试方式

系统调用（System Shell）

包含确定性的组件，如 API 接口、集成组件与工具调用模块。

编排

负责使用当前应用的状态、用户输入与其他变量来构建 LLM 运行时的输入提示词。该提示词来自智能体的静态系统提示词模板，包含运行时值占位符，这些值可能来自用户输入或应用状态计算的结果。

LLM 推理核心

核心 LLM 服务被视为黑盒，但可以通过提示词操作和 / 或当前应用状态对其施加影响。基于这一理解，我们来看一下在 全面指南 中探索非确定性软件必备的测试范式。

基于属性的测试（Property-Based Testing）

行为测试工具（Behavioral Test Harnesses）

行为测试工具提供 mock API、模拟用户交互与受控的故障场景。

蜕变测试（Metamorphic Testing）

测试类型、范围、检查项与工具的映射

如下的表格展示适用于所有智能体应用的各类测试方法、适用范围、相关检查项与识别的框架 / 工具。

表 4：智能体应用的测试类型

结论智能体 AI 应用开发在生产环境大规模铺开时会面临独特的挑战，这些挑战涵盖了识别智能体组件，以及实现、部署、测试与追踪。实际上，使用智能体 AI 的应用很少是完全智能体化的，这意味着应用程序很可能包含一部分非智能体的组件。因此，每项开发实践都会因智能体的引入而变得更加复杂，这会影响实现、测试与应用的其他方面。例如，为测试定义预期输出不再那么直观，因为相同输入在不同时机运行时，智能体可能产生不同但同样可接受的行为（这源于 LLM 输出的差异）。我们试图追踪这些影响开发实践的因素，并使用在真实生产环境部署智能体 AI 应用的过程中积累的实用解决方案来应对这些挑战。