上下文管理才是AI落地的胜负手

---

去年秋天搞了个客服Agent，差点把自己整抑郁了。

真事儿。

用的是GPT-4o，prompt改了27版——对，27版，我数过。few-shot示例加到12个，知识库塞了800多篇文档。测试环境跑得那叫一个丝滑，结果一上线直接翻车。用户说“我想退那个蓝色的”，Agent当场懵了，开始问“请问您的订单号是多少”。

问题是，用户三句话前刚说过订单号。

不是模型傻。

是我们傻。

那会儿我还沉浸在“找那句完美prompt”的迷思里，觉得只要提示词写得够精妙，模型就该自己搞定一切。后来被现实抽了一巴掌——不是prompt的问题，是上下文的问题。用户说过的信息丢了，工具返回的结果淹没了关键数据，系统提示词里塞了太多废话挤占了真正的推理空间。

这就是Context Engineering的起点，虽然当时我还不知道这词儿。

花了三个月才真正理解一件事：上下文不是聊天记录，上下文是喂给模型的“全部信息集合”。这概念比我最初想的复杂得多。第一次看到上下文的三分类法时——指导性上下文、信息性上下文、行动性上下文——感觉脑子被敲了一下。听起来学术，但用大白话说就是：告诉模型该干什么、该知道什么、能做什么。你写的system prompt是指挥棒，RAG召回的知识是弹药库，工具调用和返回结果是手脚。三者缺一不可，少了哪个都瘸腿。

但知道分类只是第一步。

真正棘手的是怎么管理这些上下文。

去年12月接手的一个营销Agent项目，平均每次调用要烧掉15K tokens。15K啊。其中将近40%是重复的工具返回结果，还有一堆早就过时的执行轨迹。用户问“上次那个方案改一下”，Agent需要翻完整个历史才能找到“那个方案”是什么。翻车了，翻得很彻底。

我开始意识到，上下文工程有四个核心操作：写入、选取、压缩、隔离。

写入是最基础的——在系统提示词里定义规则，在工具定义里描述接口，在记忆模块里存用户偏好。都是“写”进去的。但写进去容易，拿出来难。选取才是真正考功夫的地方。我现在的做法是Agentic RAG配合即时上下文——别一次性把所有相关文档都塞进去，而是在每一步推理前，动态检索最需要的那一小撮信息。讲真，效果拔群。

说个实操数字：我们用Claude 3.5 Sonnet做客服Agent，原来每次塞5篇知识库文档，平均12K tokens，准确率大概78%。改成即时策略后，每次只检索1-2篇，token降到6K，准确率涨到89%。原因很简单——噪音少了，模型不会在“退货流程”和“会员权益”之间迷失。你品，你细品。

但选取不是万能的。

有些东西必须进上下文，可它真的太长。

这就得说压缩了。我踩过最深的坑，就是以为模型自己会忽略冗余信息。Chroma团队有个概念叫“上下文腐败”，说的是噪音不只是占位置，它还会主动破坏推理逻辑。信噪比一降，幻觉就起飞。有次Agent在处理一个退款申诉，工具返回了完整的支付日志——200行的JSON，其中真正有用的就三条记录。模型愣是从中“推理”出一个不存在的优惠券，还一本正经地跟用户说“您的5元优惠券将在3个工作日内退回”。

绝了。真的绝了。

现在的做法是：长轨迹用摘要压缩，工具输出只保留关键字段，失败的中间步骤直接剔除，只留结论。上下文预算不是无限的，你得像个吝啬鬼一样精打细算。每一token都得花在刀刃上。

最后是隔离，这个很多人会忽略——不对，应该说，是压根没意识到。

不同任务之间的上下文要隔开，否则Agent会把上一个用户的偏好套到下一个用户身上。这事儿细想起来挺可怕的。我们用sub-agent架构，每个子任务独立上下文窗口，主Agent只管编排和汇总。效果立竿见影——串扰率从12%降到不到2%。从12%到2%，这差距比我预想的大得多。

说到这，得提一嘴MCP。

刚开始我也觉得这又是哪个组织在造概念，但看了Anthropic的设计思路后——怎么说呢——大概是理解了它的野心。MCP本质上是为“行动性上下文”和部分“信息性上下文”做标准化接口。工具怎么定义、数据怎么交换、结果怎么格式化，全给你规范好。

挺有意思的这东西。以前我们对接一个工具得写一堆胶水代码，格式不统一，错误处理各搞各的，debug到凌晨三点是常事。MCP如果能推开来，上下文工程的“写入”和“选取”会省力很多。Anthropic在做标准这件事上，确实是走在前头，得承认。

不过我现在的感受是，选取这块发展得最快——Agentic RAG、即时上下文这些已经很成熟了。但压缩、写入、隔离还在早期阶段，大家都在摸索。尤其是压缩，咋整都感觉不够优雅。

这让我想起Andrej Karpathy那条推文——对，就是那条说“新技能不是写prompt，而是context engineering”的。他看得挺准。这哥们儿总是能一句话戳中要害。

我有时候会想，等这几个方向都成熟了，长时运行的Coding Agent瓶颈会从“怎么管上下文”变成“怎么分解任务和定义目标”。Agent的上限，就是你描述问题的清晰度。但那是后话了，扯远了。

现在的现实是啥呢。

多数AI Agent的失败，跟模型能力没关系。就是上下文工程没做好。你给它塞了10K tokens的垃圾，然后抱怨它笨。

真的。

前几天看Anthropic那篇《Effective context engineering for AI agents》，他们提了句slogan：Do the simple thing that works。我觉得这就是上下文工程的核心哲学——别一上来就搭复杂的记忆层，先把最小闭环跑通。固定系统提示词，定义清楚工具边界，整理少量高质量示例，跑通一组真实任务轨迹，再一步一步加RAG、摘要压缩、缓存。一步一个脚印，别想着一步登天。

我现在做项目，都是先让上下文可观察、可评估，再谈优化。连agent每一步能看到什么、用了多少token都搞不清楚，就急着上multi-agent架构——那是给自己挖坑。深坑。

写到这，想起《The Line》里那句歌词：Will they still let me over, if I cross the line？

模型能力在跨过某个阈值，Agent也在跨。跨过去之后会发生什么？我不知道。但至少在上下文工程这件事上，我感觉摸到了一点门道。把随手塞prompt的毛病，改成有预算、有优先级、有证据链的上下文组装。

这事儿，够我琢磨一整年。

你们觉得呢？