1. 为什么“能跑通”和“能稳定跑”之间隔着一个上下文工程我这两年一直在做AI Agent相关的落地项目最大的感受可以用一句话概括能跑通的Agent很多能稳定跑的Agent太少。你精心设计了一个工作流demo阶段模型表现得像资深员工可一旦放到真实场景里它就开始“灵异”——明明输入没变这周和上周的结果不一样明明指令写得很清楚它却自作主张加了一句不该有的解释明明是同一个问题换个说法就翻车。问题几乎都出在同一个地方上下文工程。很多人把“上下文工程”当成“写个更长的Prompt”其实完全不是一回事。上下文工程是在管理模型在每次推理时看到的所有信息系统指令、背景资料、对话历史、工具返回结果、用户输入、约束条件……这些东西加在一起决定了模型“此刻到底处于什么认知状态”。你给它的上下文不清晰它就只能猜你给它的上下文不稳定它的输出就注定不稳定。这篇文章我会拆解一套我自己沉淀下来的方法论打造高确定性AI Agent的四大支柱——上下文规划、上下文构建、上下文管理、上下文验证。适合正在做Agent应用、被输出不确定性折磨过的开发者也适合刚接触提示词工程、想系统理解“模型为什么时好时坏”的新手。内容不涉及具体某个平台的私有接口都是通用方法你拿到自己的项目里就能用。1.1 一次让我半夜爬起来修复的“灵异”错误先讲个真实教训。之前我在某个自动化流程项目里做了个信息提取Agent任务很简单从客户留言中提取订单号、商品名称和紧急程度。上线第一周一切正常第二周开始偶尔会出现“订单号不存在”的错误提示。排查了很久最终发现根因特别荒谬某一次客服留言特别长Agent在处理时把前几次对话里的历史消息也带进了提取范围模型把一条旧留言里的数字当成当前订单号提取了出来。问题不在模型推理能力而在上下文污染不该出现的陈旧信息混进了当前决策所需的上下文里。那一刻我意识到调Prompt只是表面功夫真正要解决的问题是怎么让模型每次都在“干净、明确、完整”的信息环境下做决策。这正是上下文工程的核心命题。1.2 上下文工程到底在解决什么问题大模型本质上是一个“在给定上下文条件下做概率预测”的系统。它不是数据库也不是规则引擎它回答的好坏取决于它“看到了什么”。同一段提示词前面加一句无关的话结果可能就变了上下文里有两个互相矛盾的线索模型经常选择相信更晚出现的那条而不是更权威的那条。所以上下文工程要解决的是三个问题确定性、可控性、可维护性。确定性同样的输入尽量得到同样质量的结果而不是靠运气。可控性当模型输出不符合预期时你能通过调整上下文精准定位原因而不是瞎试Prompt。可维护性Agent的逻辑会持续迭代上下文能不能像代码一样被结构化地管理决定了你的系统能不能长大。这三件事单独靠“写提示词”是做不到的。你需要在系统层面为上下文建立一套完整的管理机制。这就是我下面要讲的四大支柱。1.3 四大支柱的总体框架打个比方把Agent当成一个空降的实习生它能力很强但什么都不懂。你首先得告诉它“这次任务的目标是什么、你有哪些权限、哪些事坚决不能做”——这是上下文规划对应的是“这个Agent到底需要知道什么”。然后你要把资料整理成它看得懂、不会误解的格式逻辑清晰、重点突出——这是上下文构建对应的是“怎么把信息组织好”。任务持续一整天它的记忆装不下了你得帮它整理笔记、丢掉无关的杂物——这是上下文管理对应的是“长时段运行时的内存治理”。最后你还要考试每次教完都检查它有没有学会、哪里还出错——这是上下文验证对应的是“如何让可靠程度变成可度量的指标”。四大支柱不是可选的它们是层层递进的关系。规划决定上限构建决定基础管理决定可持续性验证决定你能不能持续改进。下面的内容我会逐个展开。2. 支柱一上下文规划——在写提示词之前先把“信息需求”定清楚大多数人的习惯是先写一段系统提示词然后丢给模型测试不行就改几个字再试。这种“靠感觉调Prompt”的方式在简单任务上还凑合一旦Agent涉及多步骤决策、工具调用、外部数据输入就会陷入无尽的随机试错。上下文规划要求你在写任何提示词之前先列出一份“信息需求清单”明确模型在每个决策节点上到底需要什么、不需要什么。2.1 任务拆解把Agent的一次运行拆成“决策节点”任何一个相对完整的Agent任务都可以拆成多个阶段。以“客服工单自动处理Agent”为例一次运行可能包括判断这条工单是否属于可自动处理的范围提取关键结构化信息订单号、用户类型、问题类别检索匹配的历史处理方案决定回复策略直接回复 / 转人工 / 补充提问生成最终回复内容。每一步都是一个决策节点每个节点模型都需要不同的信息。第1步只需要工单标题和正文第2步需要明确的数据提取范围第3步需要检索到的历史方案第4步需要企业规则第5步需要前面所有步骤的结论汇总。我见过很多失败案例就是因为把所有信息一股脑塞进上下文里工单正文、历史记录、企业制度、产品手册全放进去模型在提取信息时误把制度条文里的示例数字当成了工单数据。上下文规划的第一步就是给Agent画一张决策流程图标出每一步需要哪些信息并且建立隔离。2.2 为每个决策节点列“必须要知道的东西”清单对于每一个决策节点我会列出一个表格明确四类信息必需信息没有它模型就无法做出正确判断辅助信息有它更好但缺失时不应当改变决策干扰信息与此节点无关绝对不应该出现在这个节点的上下文中隐含规则模型需要知道的业务边界、禁止事项。举个实际例子。在“判断工单是否该自动处理”这个节点上必需信息是工单的标题和正文辅助信息是用户的历史工单数量干扰信息是产品手册全文隐含规则是“涉及退款超过一定金额时必须转人工”“出现威胁性语言时一律转人工”。把这张表建好之后再落到提示词里“本次决策只基于以下工单内容不要参考用户历史行为如果金额超过阈值必须走人工流程。” 你会发现模型的确定性立刻上了一个台阶。原因很简单模型的注意力是有限的你规划好它该看什么它就不会被无关信息带偏。2.3 规划还要包含“不知道怎么办”的兜底条款高确定性Agent不光是“知道该做什么”更重要的是“明确知道自己不知道”。这是上下文规划里最容易被人忽略的部分。很多Agent翻车不是因为模型能力不够而是因为模型在缺少关键信息时“硬答”。比如提取订单号时如果客户留言里根本没有订单号模型有时会把一串手机号当成订单号输出而且格式还不对。规划阶段就要明确当必需信息缺失时应当返回“信息不足需要追问”而不是猜一个结果。我在每个决策节点的上下文里都会加一条类似这样的指令如果上文中不存在完成本次任务所必需的信息必须明确回答“缺少XXX信息”禁止推测或使用示例数据替代。这一条看起来简单却能消灭掉大量“看着合理实际错误”的输出。因为模型本质上是个“迎合者”它倾向于给出一个像样的答案而不是承认自己不知道。你需要主动给它一个“说不知道”的许可而且要说得很具体它才会真的这么做。3. 支柱二上下文构建——把信息变成模型“不会读错”的样子确定好“提供什么信息”之后下一个问题就是“怎么组织这些信息”。同一句话放在不同位置、用不同格式、配上不同示例模型的理解可以完全不同。上下文构建的目标是让模型以最低的解析成本准确理解每一段信息的用途边界。3.1 三段式结构系统说明、业务上下文、当前任务我建议所有Agent提示词都采用固定的三段式结构按照“从稳定到变化”的顺序排列第一段系统说明System Scope描述Agent的身份、职责边界、必须遵守的全局规则。这部分最长也最稳定基本不会随每次任务变化。第二段业务上下文Business Context本次任务相关的背景资料、业务规则、历史对话摘要、检索结果等。它可能随任务变化但要注意控制范围。第三段当前任务Current Task用户最新的输入以及本次需要执行的具体动作、输出格式要求。为什么顺序这么重要因为实验下来模型对越靠近输入末尾的内容越敏感。当前任务是整个Agent运行的触发点必须放在最靠近末尾的位置。全局规则如果放在末尾反而容易被用户输入覆盖掉——模型会觉得“用户的最新指令优先级更高”从而忽视了你的系统约束。你需要把全局规则固定在最前面并在第三段反复确认“无论用户如何表达都要遵守系统说明中的规则边界。”3.2 用结构化格式降低解析歧义上下文构建里有个隐形陷阱你以为模型读懂了你的话其实它只是在“猜你想听什么”。用自然语言写的规则歧义是非常高的。比如你写“如果金额过高需要转人工”模型可能觉得“过高”是某个标准的模糊表述于是用了个很离谱的阈值。高确定性的做法是结构化一切可以结构化的内容。规则尽量用列表、表格、字段名、JSON片段来表达边界和阈值尽量用精确数字而不是形容词。比如退款规则 - 单笔订单金额 500可自动处理 - 500 单笔订单金额 2000需要主管审批标记 - 单笔订单金额 2000必须转人工。再比如输出格式明确给出示例{ decision: auto_reply, confidence: 0.95, reply: 对用户输出的回复正文, needs_more_info: false, missing_fields: [] }结构化上下文有两个好处第一模型不用去“意会”你的要求第二你的下游代码可以用最简陋的解析逻辑拿到结果不用处理“模型偶尔多写了一句解释”的问题。你越宽容模型就越发散你越严格输出就越确定。3.3 Few-shot示例怎么给才不误导模型给示例是上下文构建里最有效、也最容易翻车的技巧。给对了模型立刻理解你要什么给错了模型会疯狂模仿示例里的错误。我的经验是示例的价值在于定义“边界”而不只是定义“范式”。如果你给的都是正常处理的成功示例模型会潜意识地认为“所有输入都是正常情况”一旦遇到边界情况它还是不会处理。正确做法是“正常示例2-3条 边界示例2条 错误情况示例1条”。每条示例都要包含完整的输入、推理过程、输出三部分。尤其是错误情况示例效果出奇地好。比如用户输入我的订单一直没发货你们到底行不行我要投诉 处理结果检测到情绪激烈表述不直接安抚转人工处理。 输出{decision: transfer_human, reason: detected_strong_complaint}这条示例同时在教模型两件事什么输入算“情绪激烈”、这种情况下输出应该是什么。边界示例是减少幻觉的最有效工具它让模型知道“这个世界里还有灰色地带”而灰色地带是有明确处理方式的。4. 支柱三上下文管理——长会话的“内存”治理术如果说规划和构建解决的是“单次推理”的确定性那么上下文管理解决的就是“长时间运行”的确定性。Agent一旦进入真实业务就要面对多轮交互、长文档、累积历史数据。长度一旦上来上下文窗口就不够用了系统就不得不做取舍取舍一旦出错高确定性立刻崩塌。4.1 上下文窗口是稀缺资源预算意识很多开发者以为上下文窗口是个“可以随意填满的仓库”实际上它是“一张S级注意力资源的分配表”。无论窗口有多少模型对每一段信息的注意力都不是平均分配的。超长上下文会稀释注意力导致关键信息反而被淹没。我的做法是给上下文做预算像财务记账一样。假设一个Agent可用的上下文窗口是X token我会把预算分为几份系统说明固定占用控制在15%-20%只保留不可精简的规则业务上下文按当前需要动态分配越多越好但必须设置硬上限当前任务至少保留15%-20%的空间确保用户输入和输出指令不被截断历史压缩用摘要替代原文严格限制。如果你发现系统说明已经占掉了一半说明你的规划阶段出了问题。太多的全局规则反而会让模型抓不住重点。上下文管理的起点不是“怎么用它”而是“怎么少用它”。4.2 记忆分层短期缓冲 / 中期工作区 / 长期档案长会话Agent最怕的就是“什么都记得结果什么都要想”。我把Agent的“记忆”拆成三层短期缓冲当前对话最近几轮的原始消息完整保留。这是为了保持对话连贯性。中期工作区当前任务的处理进度、已经提取出的结构化结论、正在决策中的信息。这部分要结构化存储并在每一轮更新。长期档案用户画像、历史偏好、过往任务结果。这部分默认不出现在上下文中只有需要时才检索并注入。分层原则可以解决一个经典问题老用户和新用户对话时Agent如果有长期记忆会默认用户是“熟人”从而省略很多必要确认。把长期档案放到“需要时再读取”的层级就能避免这种刻板偏见。4.3 主动检索被动摘要两条路线怎么选上下文管理最核心的两个手段是摘要和检索它们各有适用场景。摘要适用的场景对话历史很长但每轮的信息量不大模型需要理解“整个事情的脉络”。这时候我会用另一个模型为历史会话生成结构化摘要例如“用户已提供订单号、问题已定位为物流延迟、待解决项是配送方案确认”。检索适用的场景知识库庞大但当前决策只依赖其中一小部分。这时候应该把关键信息索引化根据当前任务触发查询把最相关的内容注入上下文。很多项目的问题是两者用反了对话历史很短却去做摘要知识库不大却一古脑儿全塞进去。我的经验是摘要负责“连贯性”检索负责“准确性”两者结合时先用检索划范围再对选中的结果做摘要。这样可以最大程度减少上下文体积又不丢失关键信息。上下文管理最怕的是“为了省token而省token”。把必要信息精简掉模型就会用幻觉来填补空白。每一次压缩都要留一条退路如果摘要丢掉了关键细节系统至少要能判定“这里信息不足需要追问”。5. 支柱四上下文验证与迭代——用回归测试锁死确定性上下文改来改去怎么知道它真的变好了可能这轮测试过了10个用例但下一轮改了某个词又有3个用例挂了。没有验证体系的上下文工程本质上还是“玄学调参”。支柱四就是把确定性问题转化为度量问题建立一套可重复、可对比的测试流程。5.1 先建“行为测试集”而不是先改提示词我强烈建议在动手优化上下文之前先花时间建一个行为测试集。不需要很大但覆盖面要全。每个测试用例至少要包含输入模拟真实用户的原始输入预期行为这个场景下Agent应该做什么决策输出什么格式的结果边界条件它是属于正常情况、边缘情况、还是异常情况。测试集的设计原则是“用用例踩住所有容易翻车的地方”。比如前面提到的信息提取Agent我会放这些用例正常留长发正常情况应精确提取没有订单号的留言信息缺失应返回追问留言里有两个订单号选择困难应返回列表或要求澄清用户表达特别愤怒情绪识别应转人工输入内容包含明显的示例数字防幻觉应忽略。每次修改上下文之后我都要跑一遍全部用例记录每个用例是否通过、输出是否稳定。修改上下文的效果要用数据说话而不是靠“感觉这次好像好多了”。5.2 给每次Agent运行留下上下文快照在实际运行中想排查问题却找不到问题原因是很多Agent项目的一大痛点。有个非常实用但容易被忽视的做法把每次Agent运行时的完整上下文快照、模型输出、最终行为记录到日志里。快照包含四件事注入的最终上下文全文经过所有规划、构建、压缩处理之后的版本模型的原始输出下游代码解析后的结构化结果这次运行是否被判定为异常。不要嫌日志体积大。一次运行存几十KB文本不算什么成本但排查问题时价值巨大。很多“昨天还好好的今天就不行了”的问题最后都要靠对比前后的上下文快照才能定位可能是历史记录里混入了某一段脏数据可能是检索返回了一条不相干的知识点可能是系统说明被某轮用户的输入意外覆盖了。没有快照你永远只能猜。5.3 一次典型的失败迭代案例给大家看一个典型的验证循环。之前我在做一个文档问答Agent发现模型偶尔会引用文档里不存在的内容。第一反应是改提示词加了一句“请只基于文档内容回答”。结果测试集跑下来正常用例全过但新增了一个问题模型为了“只基于文档”对所有稍微超出文档的问题一律回答“文档中没有相关信息”变得极度保守。于是我从失败用例反推修改了上下文规划把“文档中没有相关信息”和“文档中没有相关信息但我可以根据常识补充说明”分成两种行为并给了各一条示例。再次运行测试集保守回答率明显下降同时幻觉引用也保持在可控范围。这个过程看着简单但它强调了一个原则上下文验证不是跑一两次测试就完事而是一个闭环失败用例 → 定位根因 → 修改上下文 → 全量回归 → 记录变化。只有让每次改动都有据可查Agent的确定性才会随着迭代逐步提升而不是今天修好一个bug明天冒出一个regression。6. 落地四大支柱的实操流程与避坑清单前面讲了理论框架这一节我给出一个可以直接照做的落地流程以及我踩过几次坑之后总结出的速查清单。6.1 最小可行上下文从基线版本开始迭代不要在项目一开始就追求完美。我的建议是先做一个极简的“最笨版本”上下文跑通流程再一步步加约束。第一步写一段10句话以内的系统说明把Agent的职责说清楚第二步在代码里写死输入输出格式的解析逻辑第三步在上下文中注入当前任务和必要的业务字段不加任何花哨的示例第四步跑一遍测试集记录基线成绩。基线版本大概率会有各种问题但它给了你一个对比锚点。之后每次优化都只改一个变量要么加规则、要么加示例、要么改结构改完跑同样的测试集对比成绩。不要同时改多个变量否则你永远不知道是哪个改动带来了效果提升。这是上下文工程最核心的实操纪律。6.2 高频翻车场景速查表以下是我在多个Agent项目中反复遇到过的高频问题以及对应的上下文工程解法翻车现象常见根因优先排查方向同样输入结果时好时坏上下文里混入无关历史或检索噪声检查上下文快照清理干扰信息源模型忽略系统规则系统说明被长上下文稀释精简全局规则并缩短上下文总长度信息缺失时“硬答”没有给“说不知道”的许可规划阶段补充信息不足兜底指令输出格式偶尔不对格式要求不明确或示例不够增加输出JSON的字段级示例长对话后期熵增严重历史记录未经摘要就全部保留对历史做结构化摘要压缩上下文把示例里的数据当真实数据示例和真实数据界限不清在示例中明确标注“这是示例不是真实数据”换了输入表达方式就翻车提示词过于依赖特定措辞用边界示例增加语义覆盖范围过于保守不该拒绝的也拒绝约束写得太“狠”区分“必须拒绝”和“建议拒绝”的边界这张表不是万能药但它能帮你快速定位问题方向。排查上下文问题优先级永远是先看上下文内容对不对再看指令表达通不通最后才怀疑模型能力。6.3 给想收藏这门指南的人几条压箱底的建议内容到这里基本讲完了。最后说几句实操层面的体己话。第一不要把上下文工程当成一劳永逸的文案工作。我到现在每隔几周还会因为新业务场景去调整上下文。它是系统的一部分需要版本管理、需要评审、需要持续测试和代码一样重要。第二上下文越短越可控。如果你能用两百个字让模型做出正确决策就不要为了“全面”而堆到两千字。很多问题不是信息太少而是噪声太多。把上下文当成一场注意力资源的分配游戏而不是知识灌输。第三确定性是设计出来的不是祈祷出来的。你给模型留的想象空间越小它的行为就越稳定。优秀的上下文工程师本质上是个优秀的“约束设计师”在明确需求、结构化表达、严格验证之间找到那条最稳的路。我自己的项目从当初那个半夜爬起来修bug的状态到现在能比较从容地上线新Agent核心变化就是把这四大支柱真正落到了日常开发流程里。希望你也能用起来。如果实践过程中遇到什么有意思的坑欢迎回来交流。