面向生产的工程化Agentic AI：分布式系统视角-尧图网络科技

虽然Agentic AI的演示案例屡见不鲜，但能够真正投入生产的Agentic AI系统仍为数不多。二者之间的差距并非源于模型本身，而主要体现为工程实现层面的挑战——而分布式系统工程师恰好具备解决这类工程问题的独特优势。

大多数开发团队倾向于将大型语言模型（LLM）视为核心难点：微调、提示词设计、模型规模的选择，然后直接发布。然而，一旦智能体进入包含规划、工具调用、结果观察与重新规划的循环之后，该模型本身反而成为不需过度关注的环节。

真正制约Agentic AI系统投入生产的关键因素，在于模型周围的配套机制：如何跨多轮对话管理上下文；失败如何通过多步计划进行传播；在嵌套多层工具调用后如何有效观测错误原因；以及如何防止单一糟糕计划造成不可逆的损害。这些问题本质上是披着人工智能外衣的分布式系统工程难题。

本文作为一份实践指南，重点聚焦于大多数团队所忽略的两个关键层级：上下文工程（Context Engineering）和管控工程（Harness Engineering）。二者共同决定了Agentic AI系统是仅能完成演示级别的运行，还是能够在生产环境中（例如无人值守的凌晨时段）实现持续、稳定的工作。

一、技术堆栈

在进一步讨论之前，有必要准确理解Agentic系统的五个逻辑层：

1.基础模型（Base Model）：即大型语言模型（LLM）。在生产环境中，模型权重通常是固定的，所有与业务相关的适配逻辑均在此层之上实现。

2.智能体循环（Agent Loop）：即“计划—行动—观察”的循环。模型针对既定目标进行推理，选择调用的工具，观察执行结果并迭代更新。该循环是ReAct模式的核心机制。

3.上下文工程（Context Engineering）：每次调用LLM时向其输入的内容，包括指令、记忆、检索到的文档、工具输出以及对话历史。这一层属于内循环问题。

4.编排（Orchestration）：指多个智能体之间的协同工作方式。例如，规划智能体分解任务，子智能体执行具体任务，并在智能体之间的边界上共享状态。

5.管控工程（Harness Engineering）：即外循环。涵盖可观测性、成本控制、重试逻辑、安全约束及效果评估。这一层直接决定了系统在生产环境中的可靠性。

大多数团队将资源大量投入第1和第2层，对第3层投入不足，并基本会忽略第4层和5层——直到出现严重故障才被迫关注。本文重点讨论第3至第5层。

图1 Agentic AI技术堆栈。模型权重固定，可靠性是在第1层之上通过工程手段构建的

二、上下文工程：内循环

每次智能体循环调用 LLM 时，Agentic AI系统都会构建一个上下文窗口——即模型需要推理下一步的所有内容的快照。对于短周期任务，这一做法尚可管理；但在长周期任务中，上下文管理将成为核心的工程瓶颈。

一种简单的实现方式是直接追加所有内容：原始系统提示词、完整的对话历史、每个先前步骤中产生的全部工具输出。尽管当前上下文窗口已扩展至128K甚至200K token，为何不直接采用这种做法？主要存在三方面的问题：

成本与延迟：随着上下文规模增大，计算成本与响应延迟同步增长；
信号质量：当窗口中充斥过时或无关信息时，信号质量会下降；
行为可预测性：最为关键的是，当模型处理的上下文中充满历史决策与过时计划时，其行为将变得难以预测。

研究文献中明确指出了两种具体的失效模式：一是简洁性偏差（brevity bias）：当自动提示优化过程丢弃丰富的领域知识，转而采用精炼的通用指令时，上下文虽然变得更短、更清晰，却丧失了使其具备实际价值的特殊性。二是上下文坍缩（context collapse），这一现象更为严重：当系统迭代地将累积的上下文重写为单个压缩摘要时，会逐步删除细节，如同反复覆盖同一文档导致旧版本信息永久丢失。例如，一个客服智能体若在对话中途发生上下文坍缩，便可能丢失三轮之前对用户作出的承诺。

由此得出的核心启示在于：上下文不应被视作字符串，而是一种具有显式生命周期语义的数据结构。哪些内容需要原样保留、哪些内容需要整理为摘要、哪些内容应彻底清理、以及在何时执行这些操作——这些都属于工程决策，而非系统的默认行为。

斯坦福大学与Samba Nova公司提出的ACE框架，通过采用“演进剧本”模型体现了这一理念：它不对全部上下文进行重写，而是通过“生成—复盘—筛选”循环实现增量的、逐项更新。其结果是，上下文能够在不断积累知识的同时避免量坍缩，在智能体基准测试中相比传统方案取得了10.6%的性能提升。

可操作原则

·将上下文视为分层存储。热上下文（当前计划、即时工具输出）保持不变；温上下文（近期历史、相关事实）进行摘要处理；冷上下文（早期轮次、过时状态）予以清理或归档。

·避免无限制地追加日志式上下文。应定义明确的压缩触发条件，例如令牌阈值、步数限制以及计划转换。

·将持久状态与单次调用的视图相分离。智能体的完整记忆应持久化存储于外部存储系统中；每次LLM调用所构建的是基于该状态的编译视图，并针对当前步骤进行优化。

在上述原则之外，还有一些值得采纳的技术方法：

1.具有选择性保留机制的滑动窗口

最简单的压缩策略是滑动窗口：保留最近N轮对话，丢弃更早的记录。该策略对短周期任务有效，但对长周期任务（例如早期决策在40步后仍然具有重要性）则会失效。

其改进方法为选择性保留：与其批量丢弃历史条目，不如根据每一条目与当前计划步骤的相关性进行评分，高价值信息无论时间远近均予以保留。相关性判定可采用简单的方法（如匹配目标关键词），也可通过任务查询向量与条目嵌入之间的相似度计算实现。

2.分层摘要

不要将整个上下文压缩为单一摘要（这正是上下文坍缩的成因），而应该采用分层摘要策略。对已完成的子任务分别进行独立摘要，并将这些摘要存储为离散的、带标签的条目。当前任务的细节保持完整，已完成的工作则被压缩。当某个先前完成的子任务再次变得相关时，可以单独检索其摘要，而无需引入其他所有内容。可以这样理解：如同每个代码提交都有一个独立的变更日志条目，而不是将整个代码库的历史重写为单个段落。

3.工具输出截断与规范化

工具输出通常是导致上下文失控增长的最大因素。返回500行的数据库查询、包含深度嵌套结构的JSON响应、保留了导航标记的网页抓取结果——这些都不应原封不动地进入上下文窗口。

管控层应在工具输出注入上下文之前对其进行后处理：按深度嵌套预算进行截断、提取智能体声明的所需字段、剥离样板内容。这类似于API网关中的响应过滤，应置于同一管控层级。

4.结构化记忆槽位

不要依赖模型从冗长的历史记录中提取相关事实，而应定义结构化记忆槽位，由智能体主动写入以下内容：目标、约束条件、已做出的决策、未解决的问题、当前计划步骤。这些槽位位于上下文顶部，始终存在且保持紧凑。其后可追加滚动对话记录。这为模型提供了一个可靠的锚点，防止其过度聚焦于窗口中间存在的过时或冗余信息。

5.计划修订时的上下文失效机制

当智能体在任务执行中途修订其计划时，大量已累积的上下文可能变得过时。在旧计划下收集的工具输出可能不再相关，甚至对新计划产生误导。管控层应将计划修订视为一个上下文检查点：归档修订前的历史，将活动上下文重置为“目标+约束条件+新计划”，随后允许智能体重新开始。这一机制本质上是分布式系统中模式变更时所对应的缓存失效策略。

三、管控工程：外循环

如果说上下文工程关注的是“模型能够看到哪些信息”，那么管控工程则负责处理系统运行过程中出现的异常状况。在Agentic AI系统中，会出现传统软件中从未有过的新型故障。

可观测性

单个智能体任务可能涉及数十次LLM调用，这些调用分布在规划步骤、工具调用以及子智能体委派等多个环节。当执行失败或产生错误输出时，若缺乏结构化的链路追踪，便难以准确定位是哪一轮调用引发了问题。

分布式系统领域提出的解决方案是：对每次操作进行追踪，跨边界传递追踪上下文，并为每个跨度（span）附加结构化的元数据。将该思路应用于Agentic AI系统，意味着将每一次LLM调用视为一个跨度，其属性包括令牌计数、模型版本、上下文大小以及对应的计划步骤；工具调用则作为子跨度处理，而子智能体调用需携带父级追踪ID。Agentic AI系统应具备从初始目标到最终结果重建完整因果链的能力，并在每个节点上实现成本归因。

与标准分布式追踪相比，一个更具挑战性的方面在于：Agentic AI系统的调用图在部署时并非预先定义，而是在运行时由模型的规划过程动态生成。因此，可观测性基础设施需要具备处理动态、深度可变的调用树的能力，而非仅能应对静态的服务依赖图。

令牌预算和背压

在Agentic AI系统中，令牌成本的行为类似于分布式系统中的无界队列深度：一切看似正常，直到问题积累到一定程度才暴露出来，而损失已经造成。如果允许模型不受约束地持续重新规划，一个原本仅需10步的计划可能被扩展至40步以上。

正确的模式应直接借鉴背压（backpressure）机制：为每个任务、每个计划阶段以及每类工具调用分别设定明确的令牌预算。当预算接近上限时，管控层向智能体发出信号，要求其结束当前任务——例如总结已有发现、返回部分结果或升级交由人工处理。一旦超出预算，管控层应直接终止任务。

断路器模式同样适用。如果某个工具持续返回错误或异常庞大的负载，管控层应停止向该工具路由调用——正如断路器在检测到下游服务降级时会切断请求一样。允许智能体对同一个有问题的工具进行无限重试，本质上等同于引发智能体层面的“重试风暴”。

重试逻辑与幂等性

在Agentic AI系统中，重试所带来的困境比标准RPC中更为严峻，原因在于被重试的操作并非简单的读取或写入，而是具有实际副作用的工具调用。对发送电子邮件、修改数据库记录或提交API请求等操作进行重试，需要具备与“至少一次”交付系统同等的幂等性保证。

在决定重试策略之前，Agentic AI系统应根据副作用类型对工具调用进行分类：只读检索类调用可以自由重试；写操作需要配备幂等性密钥；而不可逆操作（即任何涉及“发送”、“提交”或“发布”语义的操作）在执行前应获得明确的用户确认，并且在失败时不应自动重试，除非经过人工复核。然而，在实践中，大多数Agentic AI框架对所有工具调用采取统一的重试处理方式。其后果是：智能体可能会重复执行已失败的电子邮件发送（导致邮件重复发送），或者因规划错误而重新提交部分完成的订单。

保障智能体安全：沙箱、信任边界与提示词注入

图2 智能体安全威胁模型：四种攻击面及其相应的防御措施

Agentic AI系统的安全性与传统服务存在本质差异。如果将二者等同对待，开发团队将面临意料之外的风险。在标准API中，威胁面仅限于请求本身：验证输入、校验调用方身份以及授权操作。而在Agentic AI系统中，威胁面还扩展至模型自身的推理过程。攻击者无需入侵基础设施，只需将恶意指令注入智能体的上下文，即可构成威胁。

攻击影响范围最小化与最小权限工具管控。基础安全原则不变：智能体可调用的工具越多，攻击成功时造成的破坏范围就越大。当模型编造错误参数、误解规划步骤或做出错误决策时，其风险不在于“是否会出问题”，而在于“损害会有多大”。因此，工具权限应仅开放当前任务所必需的最小集合，而非智能体潜在可能用到的全部权限。具体而言：文件读写操作应通过沙箱隔离至独立工作目录；API调用统一经过代理网关，限制单操作的调用频次，并配置接口访问白名单；破坏性操作（如删除、发布、金融交易等）应置于确认层之后，需经人工批准或满足可验证的前提条件方可执行。

上述设计可视为一种应用于LLM工具使用的、基于能力的安全模型：智能体仅获得当前任务所需的特定密钥，而不是每个集成模块的万能密钥。

提示词注入。提示词注入是Agentic AI系统中独有的攻击类别，也是最容易被团队低估的一类。该攻击发生在恶意指令被嵌入到智能体所检索并处理的内容中，例如：抓取的网页、读取的文档、查询的数据库记录、收到的工具输出等。由于智能体无法区分系统指令与检索内容中隐含的注入指令，因此可能执行这些恶意指令。其后果包括数据泄露（智能体被指示将敏感上下文汇总并发送至外部端点）和动作劫持（智能体被重定向执行未经授权的破坏性操作）。在2025年的一起数据泄露事件中，Replit编码智能体在收到看似正常的清理指令后删除了生产数据库，这便是动作劫持的一个具体实例。

防御提示词注入需要将所有检索到的内容视为不可信输入，无论其来源如何。Agentic AI系统中的系统提示词与任务指令，应与上下文中的检索内容实现结构化分离，而不仅仅是位置上的分离。工具输出应标记为外部数据，并在模型进行推理之前经由过滤层处理。对于高风险操作，可引入“规划者-评论者”模式：第一次模型传递生成操作，第二次传递独立审查该操作是否符合原始任务目标，随后才执行。评论者的职责是捕捉那些提议操作与用户实际要求不符的情况。

上下文作为攻击面。根据前述分析，进入智能体上下文窗口的所有内容均可能成为注入向量。具体包括：系统提示（可能被敌对的输入泄露或覆盖）；RAG检索到的文档（可能包含嵌入式指令）；先前会话中持久化的记忆条目（可能在早期交互中被投毒）；MCP工具响应（由第三方服务器控制）。

针对上述来源，需要实施来源追踪，记录内容包括：内容来自何处、何时检索、该来源的可信度如何。从内部经过身份验证的知识库中检索到的文档，与从任意URL获取的网页，应当采取不同的处理策略。

智能体操作的审核日志记录。在传统系统中，通常仅记录请求与响应。而在Agentic AI系统中，则需要记录完整的推理链：智能体被要求做什么、它生成了什么计划、进行了哪些工具调用、基于每个工具的输出做出了什么决策，以及最终采取的行动是什么。这不仅仅服务于调试目的，更重要的是为了问责。当智能体在生产环境中执行了意外操作时，必须能够准确地重建其采取该操作的原因。

以任务ID为密钥的结构化审计日志，记录每个规划步骤和工具调用，使得这种重构成为可能。缺乏这些日志，无异于在调试一个没有追踪能力的非确定性系统。

评估作为持续部署的保障措施

在传统服务中，使用单元测试和集成测试来验证系统的正确性。然而，在Agentic AI系统中，正确性是概率性的且依赖于上下文：同一任务可能在90%的情况下成功执行，而在剩余10%的情况下以难以预测的方式失败。静态测试是必要的，但远不足以保证系统的可靠性。

在此可借鉴混沌工程与金丝雀部署的思路。应该维护一组具有代表性的任务和配套的评估工具，并针对系统的每一项进行有意义的变更：模型版本升级、提示词修改、上下文工程调整以及新工具的集成。评估工具不仅要衡量任务成功率，还应衡量步骤效率（例如，是否在合理的步数内完成）、每项任务的成本，以及与先前已知良好行为之间的回归情况。

这便是面向非确定性系统的持续集成与持续交付（CI/CD）。其评判标准不再是“所有测试均通过”，而是“输出结果落在可接受的范围内”。跳过这一评估步骤的团队，往往会在生产环境中发现回归问题，并且通常出现在最糟糕的场景下。