当Prompt写得足够清楚，Agent依然不稳定时，问题可能出在上下文工程上。本文提出一套产品经理可用的诊断框架：从检索、压缩、记忆、隔离四格定位问题，用预算表、门禁和上线清单管理Agent的上下文，让团队跳出“出错就补Prompt”的循环。

一、指令明明写对了，Agent 为什么还会做错

先看一个典型的产品现场。

一家公司上线了合同审核 Agent。产品经理在系统提示里写得很清楚：任何对外发送动作，都必须先由用户确认。测试前几轮一切正常，Agent 能抽取条款、标记风险，也会在发送邮件前停下来询问。

到了第 18 轮，事情变了。

Agent 读完补充材料，调用邮件工具，把尚未确认的审核意见直接发给了供应商。复盘时，团队发现系统提示里的审批规则一个字都没少。问题出在同一轮输入的其他地方：工具列表里塞着二十多个相似动作；检索结果带进来一份过期流程，写着“审核完成后自动通知”；对话历史经过一次压缩，摘要保留了合同结论，却漏掉了“对外发送前再次确认”这条临时约束。

模型当时看见的是一套互相打架的信息。它没有简单地“忘记 Prompt”，而是在过期规则、相似工具和残缺摘要之间做了错误选择。

会后最容易出现的动作，是在系统提示末尾再加一句：严禁未经确认发送。

这句话当然可以加，但它只修了最顺手的那一角。过期流程还在被检索，相似工具还在同时出现，压缩策略仍然会漏掉约束。下一次事故也许不再是误发邮件，而是调用错工具、引用旧价格，或者在长任务后半段忘掉最初目标。

这就是很多 Agent 团队正在经历的循环：出错，补一句 Prompt；再出错，再补一句。系统提示越来越长，Agent 却没有同比变稳。

真正需要回答的问题是：

当 Prompt 已经写得足够清楚，Agent 还是不稳定，接下来该查什么？

答案藏在模型每一次推理前真正看见的全部信息里。这篇文章会把它拆成一套产品经理能使用的框架：先分清 Prompt 工程和上下文工程，再用检索、压缩、记忆、隔离四格定位问题，最后把诊断变成预算表、门禁和上线清单。

二、Prompt 管一句话，上下文工程管整张桌子

Prompt 工程关注的是如何写和组织指令，让模型更准确地理解任务。上下文工程关注的范围更大：每一次推理时，哪些信息应该进入窗口，哪些不该进入，信息以什么顺序出现，用完之后如何退出，需要跨会话保留的内容又如何更新。

Anthropic 在上下文工程实践中给出的区分很实用：Prompt 是上下文的一部分；上下文还包括工具说明、外部数据、消息历史、记忆、示例和工具返回结果。Agent 每执行一步，这个集合都会变化。上下文工程不是在任务开始前配置一次，而是在整个执行过程中不断做取舍。

这一区别为什么到了 Agent 才变得重要？

普通问答往往只有一次输入和一次输出，Prompt 在总输入里占比很高。Agent 会反复调用模型、工具和环境：上一轮搜索到的资料会进入下一轮，工具返回的日志会越积越多，中间结论可能写入记忆，失败重试还会产生新的轨迹。任务越长，最初那段 Prompt 在整个信息系统中的占比越小。

可以把模型窗口想成一张有固定面积的工作台。系统提示只是桌角的一张任务卡。桌面上还摊着工具说明书、历史对话、检索片段、业务规则、临时状态和执行日志。任务卡写得再漂亮，也挡不住其他材料过期、重复或互相矛盾。

所以，上下文工程首先是一笔预算。

这里的预算不只指 token 费用。每多放入一段信息，模型就多一个需要辨别的对象；每多暴露一个工具，模型就多一个可能选错的分支。Anthropic 把这种约束概括为有限的注意力预算：好的上下文工程追求的不是“把知道的都塞进去”，而是用尽量少的高信号信息，提高模型做出目标行为的概率。

第一张值得建立的表，不是 Prompt 版本记录，而是上下文预算表：

这张表最重要的是最后一列。很多系统里，所有模块都有权往窗口里放东西，却没有人对窗口总量和冲突负责。最后只能靠模型自己在杂物堆里判断轻重，而模型恰恰不知道哪份材料代表你真正的业务优先级。

Prompt 工程没有失效。句子仍然要清楚，示例仍然要准确，边界仍然要写明。变化在于顺序：先决定模型该看见什么，再优化这些内容怎么写。只做后半步，解决不了信息供给、生命周期和权限边界的问题。

三、窗口变大，为什么仍然需要管理

一个常见反问是：模型窗口越来越大，等它装得下全部资料，上下文工程是不是就不重要了？

这个判断混淆了容量和利用率。

更大的窗口解决“能不能放进去”，没有自动解决“模型能不能稳定使用”。2023 年的 Lost in the Middle 研究在多文档问答和键值检索任务上发现，相关信息所处位置会显著影响部分模型表现，开头和结尾往往比中间更容易被利用。不过，这个结论不能被写成所有模型的永恒缺陷。Google 后续研究显示，新模型在简单事实检索上已经能显著缓解位置问题。

真正没有过时的判断是：标称窗口长度，不等于复杂任务中的有效窗口。

简单的“从长文本里找到一个明确句子”，和 Agent 在多份相似规则、工具返回、历史状态之间做决策，不是同一道题。Chroma 在 Context Rot 技术报告中测试了多种模型，观察到随着输入增长，模型在受控任务上的表现仍会出现非均匀下降；干扰项越相似，问题越明显。它说明的不是“长窗口没用”，而是输入长度、干扰内容与任务难度会一起改变可靠性。

对产品经理来说，至少有三笔账不能交给窗口长度代替。

第一笔是相关性。五十份资料都正确，不代表五十份都与当前决定有关。无关内容进入窗口，不会因为“没有错误”就变成零成本。

第二笔是时效性。旧价格、旧规则、旧用户状态可能在写入时完全正确，过期后却会与新信息直接冲突。模型不会天然知道哪一份拥有更高权威。

第三笔是可管理性。系统能装下多少是一项模型能力；团队是否知道每类信息从哪里来、何时更新、谁能修改，是产品与工程的共同责任。窗口越大，随手塞入材料的诱惑越强，治理难度反而会上升。

因此，容量扩张会改变具体阈值，却不会取消选择、压缩、更新和隔离。就像仓库扩建不会自动带来库存准确率，货架更多只会让错误库存藏得更深。

四、四格：管理上下文的产品地图

上下文工程相关概念很多。LangChain 曾用 write、select、compress、isolate 概括常见策略；MemGPT 则借用了操作系统的分层内存和换入换出。对产品设计而言，可以进一步收束成四个问题：需要的信息怎么进来，装不下时什么出去，有价值的状态如何跨会话保存，不该出现的信息如何被拦住。

下面这张四格是本文的产品分析框架，不是行业标准。它的价值在于让团队分工，而不是争论术语。

四格看上去简单，真正落地时，每一格都对应不同的产品错误。

检索解决供给。它不只是 RAG。文件搜索、数据库查询、API 调用、按需读取规则，都是把外部信息带进窗口。检索格首先要回答的不是“相似度高不高”，而是“当前这一步到底需要什么”。

假设一个售后 Agent 同时检索到“用户计划参加马拉松”和“用户脚踝受伤暂停训练”。两条记录在语义上都与运动高度相关，但对“本周训练计划”意味着相反动作。向量相似只能说明内容像不像，不能替产品决定哪种状态更新、哪条记录已经失效。

供给策略可以先用三档做粗分：

判断顺序应当从下往上：默认不进入；能写出触发条件，升级为按需；能够证明每轮都需要且出错代价高，才升级为常驻。很多系统正好反过来，先把资料全部塞进系统提示，等窗口膨胀后再想办法删。

压缩解决长任务的连续性。压缩不是简单删掉旧消息，也不是把所有历史变成一段漂亮摘要。它要保住能改变后续行动的信息。

Anthropic 在长任务实践中把 compaction 作为重要手段：接近窗口限制时，压缩已有历史，让 Agent 带着关键状态继续工作。同时，官方也明确指出，只有压缩还不够；摘要一旦漏掉关键状态，后续执行仍然会猜错。

一个可执行的压缩模板只保留三类内容：已经做出的决定、尚未解决的事项、任务的关键约束。工具的冗长返回、已经验证失败的中间尝试和重复对话，可以落盘后退出窗口。决定丢了会返工，未决项丢了会漏活，约束丢了会跑偏。

记忆解决跨会话复用。难点不在“存”，而在什么有资格被写入、发生变化时如何更新、过期后怎样退出。一条未经验证的模型推断如果直接进入长期记忆，下一次检索到它时，就会被当成事实继续放大。

记忆至少需要四个动作语义：写入门槛、合并或覆盖、权威来源、失效时间。下面这张“唯一口径卡”适合管理高风险事实：

只保存正确版本还不够。过期版本可能已经散落在历史文档和缓存里，必须显式标记废止。否则每一次检索，都有机会把旧事实重新带回窗口。

隔离解决边界。它既是安全策略，也是质量策略。不同用户、项目、阶段和子任务的上下文混在一起，模型就会把别人的偏好用到当前用户，把旧项目规则套到新项目，或者让一个负责生成方案的 Agent 先看到评审答案。

真正的隔离要落在权限、目录、数据租户和工具可见性上，不能只在 Prompt 里写“请不要读取”。提示词是一种软约束；访问控制和工作区分区才是硬边界。

四格在评审会上可以直接变成四个问题：这一步需要的信息从哪里来？装不下时保留什么？哪些状态值得跨会话保存？谁不应该看见什么？如果四个问题没有明确答案，继续调 Prompt 往往只是把系统问题往后推。

五、Agent 出错时，先别急着改 Prompt

上下文问题最麻烦的地方，是症状看上去很像。Agent 答错了，可能是缺资料，也可能是资料太多；可能是记忆里有假信息，也可能是两份都正确但已经互相冲突。病因不同，修复动作甚至相反。

社区里常用 Poisoning、Distraction、Confusion、Clash 描述四类失效。它们不是学术标准，却是一套好用的排查语言。再加上产品里最常见的供给失败与过期问题，可以得到一张症状优先的诊断卡：

这张表的用法不是看到“跑偏”就机械归类，而是建立一条排查顺序。

第一步，还原。把出错那一次模型真正收到的完整输入拉出来，包括系统提示、工具定义、检索片段、压缩摘要、记忆和最近的工具返回。不要只看最后一句用户问题。

第二步，对症。根据异常信号判断先查哪一格。资料根本没进来，就补供给；资料过多，就做压缩；事实错误，就查记忆写入；内容串线，就查隔离。别在还不知道病因时，统一给系统提示加一句“务必注意”。

第三步，单变量回归。一次只改一个来源或一条策略，用同一任务重跑。四格一起改，即使结果变好，也无法知道哪一个动作有效，更无法建立稳定的回归集。

有一句诊断原则值得贴在评测台旁边：

别急着问模型为什么做错，先还原它当时看见了什么。

模型不会向你展示完整的因果解释，但输入是可以审计的。上下文工程的优势正在这里：很多问题不需要靠猜模型心理解决，而可以通过检查信息流、版本和权限找到工程证据。

六、落地时，产品经理要拍板五件事

四格是地图，落地还需要明确决策。产品经理至少要把五件事写进方案和评审记录。

第一，谁拥有上下文预算。每个模块能放多少内容、哪类信息可以常驻、窗口接近阈值时谁负责清理，必须有统一 owner。没有总账，各模块都会从局部合理地多塞一点，最后得到一个全局不可控的窗口。

第二，供给按什么条件触发。不要只写“接入知识库”。要写清用户意图、任务阶段、查询字段、路由条件和空结果处理。按需加载的价值不只在省 token，更在减少无关信息参与决策。

第三，什么时候压缩或重启。触发条件可以是 token 阈值、轮次、工具结果体积，也可以是连续多轮无进展。压缩后保留哪些状态、由谁验证摘要、何时干脆开一个干净窗口，也要一起设计。

第四，什么有资格进入长期记忆。用户明确表达、系统验证事实、模型推断和一次性状态不能使用同一写入门槛。高风险事实需要来源、时间、置信度和撤销方式。记忆写得越多，未来需要治理的债务越大。

第五，边界如何被系统执行。敏感数据、跨租户信息、过期规则和评审答案，应该由权限和数据结构挡住，而不是寄希望于模型自觉。工具也要按任务暴露；二十个相似工具全量常驻，会把工具选择变成新的检索问题。

这五个决定可以落进三层规则结构，避免所有内容都挤在一个系统提示里：

分层的判断标准很朴素：一条规则在哪个范围内成立，就放在哪一层。把任务临时约束写进全局层，会让后续任务受到污染；把安全边界留在任务层，又可能在新会话中丢失。

为什么 Coding Agent 往往是理解上下文工程的好样本？不是因为它有某个神奇 Prompt，而是它天然拥有较完整的信息闭环：能按需读取项目文件，能调用搜索、编辑和测试工具，能从测试结果获得环境反馈，也能用规则文件和进度记录把关键状态留给下一轮。更重要的是，diff、权限确认和版本历史让用户能审计它做了什么。

这里真正拉开差距的，是上下文供给与边界：Agent 能否接近真实工作环境，又能否只在正确时间看到正确部分。模型能力决定上限，信息系统决定它能否稳定接近上限。

七、我更愿意把上下文工程理解成一种克制

写到这里，我的判断其实和“上下文越多，Agent 越聪明”这一直觉相反。一个 Agent 是否成熟，不该只看它能读多少文档、挂多少工具、记住多少历史，更要看团队有没有能力把大部分信息挡在窗口之外。

这听起来有点反常识。做产品时，我们习惯把“能力增加”理解为功能增加：接上知识库，加一层记忆，再开放几个工具，窗口也尽量拉长。但在 Agent 系统里，每多一种信息来源，就多了一套版本、权限和失效问题。功能列表变长很容易，说明“为什么这条信息此刻必须出现”反而更难。

所以我不赞成把上下文工程包装成 RAG、长窗口、记忆和工具调用的功能拼盘。四格也不是一张采购清单。检索、压缩、记忆、隔离的意义，在于迫使团队回答几类不太舒服的问题：哪些内容虽然正确，却与当前决定无关；哪些事实昨天有效，今天必须退役；哪些资料即使可能提高回答质量，也不能越过权限边界。

如果一个 Agent 做错了，我不会先打开系统提示继续补规则。我的第一反应会是把那一轮的完整输入摊开：它拿到了什么，哪一份材料拥有更高权重，哪些旧信息本该退出却还留在里面。只有当信息供给、版本和边界都没有问题，我才会继续判断是 Prompt 写得不清楚，还是模型能力确实不够。这个顺序看似慢，长期反而省事，因为它不会把每一次故障都变成系统提示里的新补丁。

但我也不认为所有 AI 功能都需要一套复杂的上下文工程。单轮、低风险、信息稳定的任务，清楚的 Prompt 加少量必要材料通常已经足够。真正需要治理的是那些会跨轮次、跨工具、跨数据源继续行动的 Agent，尤其当一次错误会带来真实状态变化时。上下文工程的投入，应该跟任务长度、信息冲突概率和错误代价一起增长，而不是因为它是热门概念就默认全量建设。

文章写到这里，比四格图更值得带走的，其实是一种排查习惯：先问模型当时看见了什么，再讨论它为什么那样回答。能把这件事说清楚，团队才有机会把问题落到检索、压缩、记忆、隔离或 Prompt 的具体一层；说不清楚，所谓调优大多仍是在黑箱外面猜。