Agent上下文工程的七大组件：生产级上下文装配清单

一家财富100强保险公司在顶级前沿模型上花了230万美元、耗时六个月，搭建了一套多智能体理赔系统。编排干净利落，工作流梳理清晰。上线后第一周，它批准了一笔40万美元的欺诈理赔。

事后复盘并没有发现推理失误，而是三个问题：智能体对该索赔人的历史交互毫无记忆；欺诈检测规则存在于另一个它无法访问的系统；它的系统提示只有两句话——"你是一个乐于助人的保险理赔助手，请准确高效地处理理赔。"模型足够聪明，只是没有被给到做决策所需的东西。

这正是当前阶段典型的失败模式。模型够好，框架成熟，团队却仍在交付昂贵的演示品。因为决定决策质量的东西既不是模型也不是框架，而是在调用那一刻，最终落进上下文窗口里的内容。

心智模型：LLM是CPU，上下文窗口是RAM，上下文工程是操作系统

Andrej Karpathy将上下文工程描述为"用恰到好处的信息填充上下文窗口以服务下一步的精妙艺术与科学"。

对架构师而言，有一个类比能把它讲清楚：LLM是CPU，负责对输入进行推理；上下文窗口是RAM，是每次决策的工作记忆；上下文工程则是操作系统，决定什么被加载、何时加载、以何种格式加载。

当笔记本内存耗尽时，应用会变慢、崩溃、报错，即便CPU完全有能力处理。上下文窗口错误或不完整的智能体表现一模一样。换一颗更快的CPU，解决不了一个加载了错误数据的操作系统。

这也解释了提示工程与上下文工程的本质差异。提示工程是人为单次对话手写一段静态字符串；上下文工程是一个系统，在运行时从多个来源动态装配上下文，跨越多个步骤，每一步都建立在上一步之上。正是这个差别，让单纯调提示词在生产环境中走不远。

上下文工程（Context Engineering）这一概念由Andrej Karpathy在2025年前后正式提出，用以区别于更早期的"提示工程"（Prompt Engineering）实践。提示工程诞生于单轮对话场景，核心是手工调优一段固定文本以获得更好的模型输出；而上下文工程面向的是多步骤、多智能体的自动化流水线——在这类系统中，没有人在每次调用前手工审阅提示词，上下文必须由代码在运行时动态装配。两者的差距，类比到软件开发，相当于"在终端手动输入命令"与"编写一套完整的调度系统"之间的差距。这也解释了为什么许多在内部演示中运行良好的智能体一旦进入生产环境就开始出错：演示场景通常由人工精心准备好上下文，而生产环境中没有这道人工保障。

Agent上下文的七大组件

设计生产级智能体系统时，可以把上下文拆分为七个组件。任何一个出错，都可能引发连锁反应。触发器（用户、智能体、定时任务或事件）启动工作，上下文装配器整合七类输入，交由LLM推理，最终产出结构化输出，并反向更新状态与长期记忆。

1. 指令 / 系统提示

系统提示是一份契约，而非随手一写的"感觉"。在生产中，它需要明确角色、边界、决策标准和升级规则。对理赔智能体来说，这意味着精确的自动审批阈值、任何5万美元以上赔付前的强制欺诈检查，以及边缘情况的升级规则。"准确处理理赔"是演示用的提示，真正的系统提示应当被当作一份有版本管理的规格说明，像审查代码一样审查对它的每一次改动。

2. 长期记忆

这是大多数企业级智能体悄然崩坏的地方。智能体需要跨会话的持久化记忆：关于实体、关系和历史决策的结构化记忆，而不仅仅是聊天记录。一个电信业的例子很说明问题：客户致电咨询账单问题。没有长期记忆时，智能体给出标准的50美元抵扣；有了长期记忆，上下文显示这是一个年消费45.6万美元、有过多次投诉升级历史的账户，正确的响应是高管级别的客户挽留干预。两种情况下模型完全相同，决策却天差地别。

3. 状态 / 短期历史

在多智能体工作流中，各个智能体需要知道其他智能体已经做了什么。以三智能体理赔流水线为例，若没有状态传递，第三个智能体要么重做前两个的工作，要么在不知道它们结论的情况下直接决策——这就是"失忆问题"。

状态需求也会随自主度上升而增长。路由型智能体传递分类元数据，副驾型智能体传递草稿回复，解决型智能体传递完整执行上下文。如果状态管理不随智能体自主度提升而演进，上下文就会断裂。

4. 检索信息（RAG）

RAG只是入场券，真正要紧的是检索的质量与用量纪律。问一个理财顾问智能体"这位客户能投资私募股权基金吗？"一个糟糕的管道会把五份松散相关的合规文档、约8000个token的法律文本一股脑塞进上下文，智能体便会编造出一套政策解读。好的管道会窄范围检索、排序、裁剪，并附上来源出处。

还要把检索当作一个攻击面。每一份检索到的文档都是潜在的注入向量。一份藏有隐藏指令的被污染文档会被当作合法上下文处理（即跨域提示注入XPIA）。将检索文本包裹在清晰分隔、带标签的块中，并明确告诉模型这些块内的内容是数据、绝非指令，就能消除大部分攻击面。

RAG（Retrieval-Augmented Generation，检索增强生成）是一种在调用LLM时，先从外部知识库动态检索相关文档、再将这些文档连同用户问题一起送入模型的架构模式。它的出现解决了LLM两个固有限制：知识截止日期（训练数据有时效性）和私有知识盲区（企业内部文档不在训练集中）。典型的RAG管道包含三个环节：文档向量化（将文本转为可做相似度检索的嵌入向量）、相似度检索（根据当前查询找出最相关的文档片段）、以及上下文注入（将检索结果插入提示词）。XPIA（跨域提示注入，Cross-domain Prompt Injection Attack）则是RAG带来的一类安全威胁：攻击者在被检索的文档中预先嵌入隐藏指令，当这份文档被当作上下文注入模型时，其中的恶意指令可能被模型误认为合法指令执行，从而绕过系统提示的约束。

5. 提示 / 输入

这是启动工作的触发器。在企业系统中，"用户"往往是另一个智能体、一个定时任务或一个来自外部系统的事件，而不是正在打字的人。请为这些调用者设计输入契约，而不只是为聊天场景。

6. 可用工具

工具定义了智能体能做什么，而不只是它知道什么。上下文窗口中的工具定义告诉模型存在哪些动作、需要哪些参数、预期哪些输出。MCP的意义正在于此：它让工具在不同服务间可被一致地发现和调用。一个知道自己拥有欺诈检测API、理赔数据库和文档验证服务的智能体，才能围绕它们制定计划。工具定义应保持干净、确定，草率的工具描述本身就是上下文噪声。

MCP（Model Context Protocol，模型上下文协议）是Anthropic于2024年底发布的开放标准，旨在统一LLM与外部工具、数据源之间的连接方式。在MCP出现之前，每家工具供应商、每个智能体框架都有各自的工具调用格式，导致工具定义无法跨平台复用，企业在多供应商环境下需要为同一工具写多套适配层。MCP采用客户端-服务器架构：工具提供方暴露一个MCP Server，声明自己提供哪些工具及其参数schema；智能体通过MCP Client发现并调用这些工具，协议层屏蔽底层差异。这使得"工具可发现性"从各家自定义的实现变为可互操作的标准，也让工具定义的版本管理和安全审计有了统一的切入点。

7. 结构化输出

下游系统不应去解析散文式的自然语言。理赔智能体完成时，应输出包含决策、索赔ID、风险分、推理链和审计信息的结构化JSON。这样的输出可直接喂给支付系统、通知服务和审计日志，无需人工解读。reasoning数组给出可审计的决策轨迹，audit块告诉合规团队到底是哪个模型、哪些工具产生了这个决策。再配合低温度、严格schema和校验门禁——你追求的不是逐字相同的文本，而是从非确定性组件中设计出确定性的结果。

让一个决策走完整条栈

每一步，决策都完全取决于窗口里有什么。触发阶段，客户提交理赔，编排器加载系统提示、来自长期记忆的索赔人历史、通过RAG获取的理赔文档，以及工具列表（欺诈检查、赔付系统、升级队列）。推理阶段，理赔智能体调用欺诈工具拿到风险分并加入工作上下文，检索相似历史理赔并核查保单限额。决策阶段，批准（结构化输出至支付）、标记复核（带完整上下文摘要移交）或拒绝（带推理的结构化输出）。

漏掉欺诈分，你会得到一个糟糕的决策；步骤之间丢失状态，你会得到重复或自相矛盾的动作；检索到错误文档，你会得到一个幻觉出来的保单条款。

为什么上下文是你其他问题背后的根因

原始材料中最有力的论点是：可靠性、安全性、成本和平台碎片化，最终都能追溯到上下文。

可靠性。非确定性迫使你锁定输入（版本化提示、系统消息、检索源）、约束输出（schema）、保持工具定义稳定——每一项都是上下文决策。松散的上下文意味着不稳定的行为。

安全性。所谓"致命三要素"是：访问私有数据、暴露于不可信token、以及存在数据外泄通道。伪造发票攻击之所以奏效，是因为未经净化的不可信内容进入了窗口。这是上下文管道问题，不是模型问题。

成本。一个预期10倍ROI最终只实现2倍的项目，不是算错了账，而是漏算了上下文成本。臃肿的上下文抬高每次调用的token，糟糕的检索把token烧在无关文档上，缺失的记忆迫使重复推理。

平台碎片化。那个案例里，横跨四家供应商的六个试点各有独立的身份模型、数据契约、检索模式和记忆存储，没有一个智能体能装配出统一的组织上下文。问题不在工具，而在于上下文无法流动。上下文是智能体系统的控制平面，要么刻意地去工程化它，要么事后为它付出代价。

上线前检查清单

智能体投入生产前，针对七个组件逐一回答：系统提示是否编码了阈值、升级规则和强制检查，并有版本管理？长期记忆能否让智能体跨会话看到实体历史？状态——每个智能体向下一个传递什么，是否随自主度扩展？RAG——检索内容的token预算、排序和来源出处如何？提示——是否处理非人类触发（智能体、事件、定时）？工具——定义是否干净、精简、可发现（MCP）？输出——是否经过schema校验、可审计、可被机器消费？

如果你今天去审计生产中的智能体，七个组件里哪一个会被发现缺失或被敷衍带过？你能否赶在第一个代价高昂的决策之前就抓住它？