智能体工程是一门学科，而非一种感觉

大多数智能体系统在生产环境中失败，并不是因为底层模型能力不足。它们失败是因为围绕模型构建的工程设计过于草率。模型在第三步偏离了方向，但没人注意到，直到第八步，最终答案虽然言之凿凿却是错误的，而且没有任何护栏来拦截它。这不是模型问题，而是架构问题。

智能体工程在三年内至少经历了两个完整的炒作周期。AutoGPT 和 BabyAGI 在 2023 年春季引发了巨大的狂热，随后在 GPT-4 不可靠的工具调用现实面前折戟。第二波浪潮随 2024 年的多智能体框架和智能体 RAG 而来。现在，到了 2026 年，超过半数的受访工程团队报告已有智能体在生产环境中运行——其中大多数团队也发现，部署一个智能体与维持一个可靠的智能体是完全不同的问题。成功的团队将智能体工程视为一门严谨的学科，而挣扎中的团队仍将其视为一种“感觉”（vibe）。

领域内无法达成统一定义——而这正是一个信号

询问十位从业者对“AI 智能体”的定义，你会得到十个不同的答案。OpenAI 从运行时模型、指令和工具的角度来描述智能体。LangChain 的定义核心在于 LLM 对执行流的控制程度。研究论文则将智能体分解为感知、大脑、规划、行动和协作层。

这种分歧不仅仅是学术上的。当你的团队无法就什么是智能体达成一致时，就无法就它应该具备哪些属性、什么可能导致失败以及需要进行怎样的工程设计达成一致。这种定义上的模糊性，是生产部署经常忽略关键设计决策的原因之一。

一个实用的工作框架涵盖了六个维度：

• 意图（Intent）：智能体如何理解目标——包括多模态输入、任务分解和成功标准
• 记忆（Memory）：智能体如何在轮次和会话之间保持连贯性——上下文状态、外部存储和技能库
• 规划（Planning）：智能体如何安排行动顺序——从线性链到树搜索，再到自我修正循环
• 控制流（Control flow）：谁或什么决定下一步——是 LLM、确定性代码，还是混合模式
• 权限（Authority）：智能体被允许做什么以及在什么条件下进行——信任边界、确认闸门、回滚能力
• 工具（Tools）：智能体可以调用哪些外部能力——API、搜索、代码执行、浏览器

一个有趣的观察是，大多数智能体失败都可以追溯到这些维度中的某一个未被明确定义。无限循环的智能体存在规划问题。在没有检查点的情况下执行不可逆操作的智能体存在权限问题。在二十轮之后偏离目标的智能体存在记忆问题。

控制流是杠杆率最高的设计决策

一个真正的智能体系统的定义特征是 LLM 影响了控制流。在传统的软件系统中，控制流是明确的：如果这样，就那样。在智能体中，LLM 读取上下文并决定下一步采取什么行动。系统越具有“智能体性”，这些分支决策就越多地存在于模型内部。

这既强大又危险。

其力量在于灵活性。智能体可以处理设计时从未明确预见到的新情况。它可以从局部故障中恢复，根据中间结果调整计划，并通过开发者从未规划过的路径追求目标。

危险在于，智能体系统中的控制流错误在累积之前是隐形的。在传统代码中，错误的分支会产生错误的结果。在智能体中，第三轮的错误决策会污染为第四到第十轮提供信息的上下文。智能体不会崩溃。它会在过时或错误的中间状态基础上，充满自信地继续运行。

工程上的应对方案是流程工程（Flow Engineering）：将智能体决策的拓扑结构视为一等公民的设计产物，而不是一种随之而来的属性。这意味着要明确哪些转换是由 LLM 控制的，哪些是确定性的。这意味着要识别那些一旦分支错误就会导致不可逆下游影响的决策点，并在这些点添加强制闸门。这意味着在编写 Prompt 之前，先画出状态机。

在生产环境中取得成功的团队，往往会在每个 LLM 控制的决策点应用一个简单的测试：如果这一步返回了一个看似合理但错误的答案，下游会发生什么？如果答案是“智能体悄无声息地导向了一个糟糕的结果”，那么该决策点要么需要确定性的回退方案，要么需要人工确认闸门，或者需要触发重试的置信度阈值。

在几乎所有生产系统中，记忆都被低估了

记忆是大多数团队视作事后补全、而大多数生产系统都会搞错的组件。对于短会话，上下文内记忆（In-context memory）表现良好。但对于任何涉及超过几千个 Token 的会话、多会话持续性或并发智能体之间的共享状态，上下文内记忆是不够的。

大多数生产环境失败中出现的模式是：智能体是为短会话设计的，并在测试中表现良好。部署后，用户会有更长的会话或返回进行后续交互。智能体失去了连贯性。早先确定的事实被截断出了上下文。智能体自相矛盾，或者询问它已经拥有的信息。

生产级记忆架构至少需要三个层级：

1. 工作记忆（Working memory） —— 当前会话的上下文状态，通过摘要总结和关注每一步实际所需的信息来管理
2. 情节记忆（Episodic memory） —— 过去会话的压缩摘要，结构化程度足以准确检索，且不会因过于冗长而导致检索噪音
3. 语义记忆（Semantic memory） —— 持久的事实、用户偏好和领域知识，存储在外部并通过足够的结构化处理进行检索，以避免困扰原生 RAG 实现的检索失败问题

最难的部分不是孤立地构建其中任何一个层级，而是管理它们之间的接口，并决定哪些信息在层级之间移动以及何时移动。过度压缩情节记忆的智能体会丢失细节。检索过于宽松的智能体会用无关的过去上下文稀释工作记忆。正确的平衡取决于具体应用，需要通过经验调优，而非默认设置。

团队一致低估的规划失败模式

大多数 Agent 框架都提供了一个规划循环：生成计划、执行步骤、观察结果、修订计划。这听起来很稳健。但在实践中，它引入了团队一致低估的失败模式。

过早收敛 (Premature convergence)。一个生成了计划并致力于执行它的 Agent，在中间观察结果显示有更好的路径时，仍会执行次优计划。规划循环需要显式的修订触发器 —— 即 Agent 停止并重新规划而非继续执行的条件。

无限循环 (Infinite loops)。如果没有任何超时或最大迭代次数限制，困在子任务中的 Agent 将无限期地重试。超时并不是你的 Agent 出故障的迹象，它们是任何生产级规划循环的必需组件。

对不可逆性的盲目 (Irreversibility blindness)。规划 Agent 本身并不具备识别哪些操作是可逆的、哪些是不可逆的感官。一个安排了会议、发送了邮件，然后意识到自己误解了用户意图的 Agent 无法撤回邮件。规划需要区分可逆和不可逆的操作，并在执行不可逆操作之前要求更高的置信度阈值。

复合近似误差 (Compounding approximation)。多步计划会积累微小误差。每一步的输出都成为下一步的输入，近似误差会不断复合。如果每一步的准确率是 95%，那么在误差相互独立的情况下，十步之后的准确率大约只有 60% —— 而它们往往不是独立的，因为早期步骤的错误会为后期步骤创造系统性偏见。

针对这些失败模式的工程响应不是避免规划循环 —— 它们对于复杂任务确实非常强大。响应方式是将规划循环视为具有显式转换的状态机，并使这些转换可测试。

权限是感觉像政策问题的可靠性问题

权限 (Authority) —— 即 Agent 被允许做什么以及在什么条件下做 —— 经常被视为由产品经理做出的政策决策，而不是由构建者做出的工程决策。这是一个错误。

权限的技术实现对可靠性有直接影响。一个没有权限约束的 Agent 在误解目标时会乐于执行破坏性操作。一个具有过度僵化权限约束的 Agent 则会在合法任务上失败并产生用户可见的错误。正确的实现两者都不是；它应该是一个分层权限模型，在具有高后果的操作处设置显式的确认门限。

安全工程中的最小必要权限概念在这里同样适用。一个执行研究任务的 Agent 不应具有生产数据库的写入权限，即使写入权限在技术上是可用的。安排会议的 Agent 在没有显式确认的情况下不应能够取消现有会议。提前约束权限比调试由于 Agent 拥有了不该使用的权限而导致的生产事故要便宜得多。

权限还有一个时间维度。许多生产环境中的 Agent 需要执行长时间运行的任务 —— 跨越数分钟或数小时的操作序列。这些 Agent 需要检查点 (Checkpoints)：在这些点上，它们可以被暂停、检查、恢复或重新定向，而不会丢失之前所有的工作。一个没有检查点的长运行 Agent 是一种负担：如果它在第二十步出错，唯一的恢复选项就是从头开始。

调试 Agent 不同于调试代码

当传统程序失败时，你会阅读堆栈跟踪。当 Agent 失败时，通常没有堆栈跟踪。从 Agent 自身的角度来看，它已成功完成 —— 它只是产生了一个错误的答案，采取了错误的行动，或者进入了一个最终达到超时的循环。

调试 Agentic 系统需要大多数团队在首次遇到生产故障时还不具备的可观测性基础设施。生产级 Agent 的最小可行可观测性栈包括：

• 步骤级追踪 (Step-level tracing) —— 记录每一次 LLM 调用、每一次工具调用和每一次状态转换，以及每一步的输入和输出
• 统计监控 (Statistical monitoring) —— 会话成功率、每会话步骤数和工具错误率的基准指标，警报根据统计偏差而非硬性阈值进行校准
• 重放能力 (Replay capability) —— 能够使用固定种子从检查点重新执行特定会话，以便确定性地重现失败进行调试

LLM 的非确定性使得重放能力最难构建，但也最有价值。如果没有它，观察到一次的失败无法可靠地重现，而在没有重现的情况下进行修复只是猜想。

在拥有生产级 Agent 的团队中，大约 94% 的团队报告已经建立了某种形式的可观测性，但只有不到 52% 的团队报告在测试集上运行了系统性的离线评估。这意味着大多数团队知道他们需要观察 Agent 的行为，但很少有人将评估 Agent 行为是否正确的实践操作化。

那些做对了的团队有哪些共同点

生产环境中可靠的 Agent 系统往往具有一系列结构性特征，这些特征与模型选择关系不大，而与在编写第一个 Prompt 之前的工程决策息息相关。

他们将 Agent 的控制流视为需要显式设计的制品，而非从模型智能中自发产生的属性。对于这样一个问题，他们有清晰的答案：在每个决策点，如果这一步返回了一个看似合理但实际错误的结果，其失败模式是什么？

他们针对实际使用模式而非测试模式构建记忆架构。这意味着他们理解生产环境中的会话比测试会话更长且更多样化，并据此设计记忆层。

他们默认应用最小必要权限，并且对于 Agent 拥有的、并非任务严格要求的每一项能力，都要求提供明确的理由。

他们在 Agent 上线生产环境之前就部署好了可观测性基础设施，而不是在发生第一次事故之后。

此外，他们将 Agent 工程视为一项融合了产品思维、数据基础设施和可靠性工程的独特技能，而不是一种语法不同的软件工程。到 2026 年仍在苦苦挣扎的团队，很大程度上仍将其视为后者。