从提示工程到上下文工程：Agent架构的范式转移与实战改造

过去这一年，我花在拆Agent问题上的时间比写prompt的时间还多。不是赶时髦，纯粹是工作里堆了一堆跑着跑着就“失控”的Agent：上一秒还在按计划执行，下一秒突然把一个错误工具的结果当成真理继续推理，或者嘴上说着“记住这个约束”，下一轮就把约束忘得干干净净。

拆到最后，我得到一个很朴素的判断：大部分Agent的问题不是出在prompt写得不精致，而是出在上下文管理上——往模型里塞了什么、什么顺序、什么时候塞、哪些信息该被省略，这些才是决定Agent质量的核心。这就是业内已经形成共识的判断：Context Engineering（上下文工程）正在取代Prompt Engineering（提示工程），成为Agent架构的核心命题。

这篇文章我想做两件事：一是把当前六家头部AI厂商的Agent架构思路完整解剖一遍，看看它们各自怎么处理上下文；二是把我实际做过的一次上下文工程改造，从问题定位到五步实施完整写出来。如果你正在搭Agent，或者搭出来的Agent总在真实环境里翻车，这篇应该能帮你少走不少弯路。

1. 从提示工程到上下文工程：Agent开发者正在经历的范式转移

1.1 Prompt Engineering的红利期为什么正在结束

Prompt Engineering在单轮生成时代确实是黄金技能。那时候模型面对的输入基本是静态的，你给它一段指令、几个例子、一个输出格式，它就能稳定地执行任务。调整措辞、增删示例、微调输出结构，每一分投入都能直接看到输出变化。早期做业务落地，靠一手精致的prompt就能把模型调得像精通某个行业的老手一样。

但Agent改变了这个玩法。Agent不是一次性生成，而是循环决策：规划、调用工具、观察结果、再规划、再调用。每一轮循环都会产生新的上下文——工具返回的JSON、API报错、环境状态、用户的追加指令、历史对话摘要。这些内容在系统里不断累积，最后全部指向同一个问题：下一轮调用时，模型到底应该看哪些内容？

prompt本质上是“静态指令”，它管的是模型“怎么说、按什么格式输出”。而Agent真正需要解决的是“给模型看什么、按什么顺序看、看多少、哪些该丢掉”——这是范围完全不同的工程问题。我在实际项目中见过太多类似场景：system prompt写得堪称范文，任务拆解也逻辑清晰，但Agent一旦跑进真实环境，几轮工具调用之后就开始跑偏。原因几乎都是上下文里的杂质太多，关键信息被挤出了有效注意力范围。所以Prompt Engineering不是没用了，而是它的收益曲线明显变平，继续调词的边际收益越来越低，真正能撬动结果的杠杆已经转移到了上下文工程上。

1.2 上下文才是Agent决策质量的真正瓶颈

为什么上下文质量比指令措辞更决定Agent的成败？这要从模型的注意力机制说起。Transformer处理长输入时，注意力会被“稀释”：上下文越长，模型对每一条信息的平均关注度越低。而且模型对输入不同位置的信息敏感度不一样，开头和结尾的信息权重更高，中间大段内容很容易被“一带而过”。这就导致一个很尴尬的局面：你花了很多token把背景资料全塞进去，模型却未必真正“看见”了它们。

用打工人来类比特别直观。你让一个实习生做调研，给他10G原始资料让他自己翻，和帮他筛出3份高度相关、附带重点标注的材料，后者的产出质量大概率高得多，时间还省一半。Agent也是一样，它的推理能力是固定的，能看多少、看得准不准，完全取决于我们喂进去的上下文怎么组织。

所以我一直跟团队强调：Agent的决策质量，约等于它每一轮看到的上下文质量。幻觉率高、漏掉约束、错误调用工具，这些表面上像模型能力问题，拆到根上常常是上下文组织失当的次生灾害。模型确实可能有能力上限，但对绝大多数生产环境里的Agent来说，还没轮到模型背锅，上下文就已经先拖后腿了。

1.3 上下文工程到底管什么

很多同学一想到上下文工程就以为是RAG，或者以为是“提示词拼接术”，这些理解都偏窄了。我给团队做的定义是：对进入大模型的信息做全生命周期管理——采集、筛选、组织、压缩、存储、检索、注入、回收，每一步都有明确策略。

拆开来说，至少包括三层。第一层是内容分级，哪些信息属于系统级（不随会话变化）、哪些属于会话级（当前对话的流水）、哪些属于任务级（当前步骤需要的临时状态），要分得清。第二层是生命周期策略，什么信息该在什么时机写入、什么时候过期、什么时候压缩成摘要归档，要定得清。第三层是成本与质量权衡，同样的信息，用完整原文还是摘要？什么时候值得多花token保留细节，什么时候可以大胆砍掉？要算得清。

这三个“清”做得到，提示词层面的压力会大幅下降。上下文工程不是某个新库、某个新框架，而是一套设计Agent系统时的思维方式。理解这一点，再看下面六家厂商的架构，会清晰很多。

2. 六家头部AI厂商的Agent架构流派拆解

业界公认站在头部的六家AI厂商，各自对Agent架构的理解存在明显差异。很有意思的是，虽然对外展示的框架形态完全不同，但内核都在往同一个方向收敛——上下文怎么管。为了避免把讨论变成“猜厂名”的八卦，下面用厂商A到F来代称，重点是看架构逻辑本身，看它们各自用什么方式解决上下文注入、流转和生命周期问题。

2.1 厂商A：模型原生工具调用派

厂商A的思路很明确：工具调用不是外面套一层编排就能解决的，干脆把“什么时候该调工具、怎么构造调用参数”这件事做成模型的原生能力。

它的Agent架构极简。模型直接决定要不要调用某个工具，输出结构化的调用指令，外部系统执行完调用后，把结果作为新的上下文消息再注入回模型，循环往复，直到模型认为自己拿到了足够信息可以生成最终答案。中间没有复杂的编排层，整个Agent就是模型加工具的一对一联动。

在这种架构里，Prompt Engineering并没有消失，但重心变了。我做这类Agent时感受最深的是：工具描述文档怎么写，几乎直接决定了模型选工具的准确率。一份好的工具说明书应该包含触发条件、参数含义、边界说明，还要有一到两条清晰的使用范例。工具返回结果也一样，在注入主上下文之前必须做清洗——把几百行JSON压成几个关键字段，否则模型会像面对一堆无关噪音一样无从下手。这个派别的短板在于对模型自身能力要求很高，工具数量一旦多起来，单次决策视野就会不够用，很难支撑超长任务链。

2.2 厂商B：规划器与执行器分离派

厂商B走的是“想”和“做”分开的路子。一个规划器（通常用推理能力更强的模型）负责把用户目标拆解成可执行的任务清单，然后把一个个具体任务交给执行器去完成，执行器负责任务对应的工具调用。任务完成后的状态和产物，会统一写回规划器可见的区域。

这种架构真正漂亮的地方在于上下文隔离。执行器不需要看到整张任务清单，只需要看到当前任务的最小上下文——要处理什么、有哪些边界条件；规划器也不需要每时每刻都在，它只在关键节点读取执行反馈、决定下一步怎么走。这从一个侧面印证了上下文工程的核心理念：不同角色应当看到不同粒度的上下文，而不是一股脑共享所有信息。

我在做这类系统集成时发现，最容易翻车的点恰恰是任务清单这个“共享上下文”。清单写得太粗，执行器接到的任务包含的上下文不足，执行结果就会跑偏；清单写得太细，token浪费还是小事，规划器自身的上下文也会被塞爆。所以任务清单本身需要一个专门的上下文管理策略：只保留任务摘要加最后一步执行结果，把完整执行历史放到外部存储，需要的时候再按需拉取。

2.3 厂商C：统一协议生态派

厂商C的侧重点不在模型本身，而在工具接入的标准化。它主导了一套让工具方按统一格式发布“能力描述”的协议，Agent运行时可以动态发现并匹配工具，工具调用和返回结果也按照统一的schema流转。

从上下文工程的角度看，这套标准化的意义比表面看到的更大。工具描述文件本质上就是Agent的“上下文字典”，模型在做工具选择时，参考的正是这些结构化描述。描述写得好，Agent就能精准命中合适的工具；描述写得含糊，就算工具本身很强大，模型也只会把它当“不知道能干什么的野生接口”跳过去。

统一协议带来的还有一层隐性好处：工具的返回报文有了统一schema，Agent可以在协议层就把大字段截断、过滤、转换，让干净的结果进入主上下文。这种“标准化即可治理”的思路，在工具数量上百时特别值钱。生态型架构的代价是所有工具都要先经过标准化封装，前置成本高一些，一旦跑起来，三角色之间的上下文流转会显得非常规整。

2.4 厂商D：超大上下文窗口派

厂商D选的路线是最“大力出奇迹”的——窗口开得足够大，复杂检索、复杂编排统统先不做，把历史对话、知识库片段、工具定义一股脑塞进长上下文，靠模型的长距离依赖能力硬读。

坦白说，这个路线在前沿研究阶段很有诱惑力，因为架构复杂度最低，跑demo确实快。但一进入生产环境，问题全暴露了。第一，成本递增往往超线性，塞的token越多，单次推理越贵、延迟越明显。第二，上下文越长，注意力在关键信息上的密度就越低，模型越容易迷失在长文中间。第三，长窗口不等于长记忆——上次会话的内容，这次还是要重新检索、重新注入。

即便如此，这个流派给了上下文工程一个很直接的启示：哪怕是长窗口模型，也必须做内容分区和优先级排序。把关键指令放在最前，把最新动态放在最后，中间区域只放参考性质内容，是我实测下来最稳妥的配置。尤其在长上下文场景里，这个位置排序带来的约束遵守率差异可以非常明显。

2.5 厂商E：中心化记忆派

厂商E把记忆做成独立的基础设施。它的Agent架构里有一个专门的记忆服务，分为短期记忆、工作记忆和长期记忆三层。短期记忆保存当前会话的原始轮次；工作记忆保存当前任务正在进行的中间状态；长期记忆以向量化形式沉淀跨会话的偏好、事实和已确认结论。Agent每次推理前，先向记忆服务发起一次“相关记忆拉取”，拿到一个记忆注入包，再进入模型。

中心化记忆派是我个人最推崇的方向之一，因为它真正把上下文工程当成了一个有边界的系统问题来解。它不再靠手工拼串，而是有一整套写入、更新、过期、检索的策略。比如用户长期记忆里的一个事实，在后续多轮对话中要稳定注入；工作记忆在当前任务结束后，要么写回长期记忆，要么直接清理。

这个流派最大的工程挑战是记忆污染。如果某条错误信息被写进了长期记忆，Agent会在之后非常长的时间里一直“坚信”这个错误结论。所以记忆系统必须具备溯源性、可信度打分和人工修正通道。这个细节没做好，中心化记忆反而会变成系统性幻觉的温床。

2.6 厂商F：全托管会话派

厂商F面向的是企业级场景，做法是把Agent的完整会话状态托管在平台上，每轮运行时的上下文都会形成快照。出现问题时，人工可以直接查看快照、修改上下文、再把Agent放回运行轨道，实现人机协同闭环。

这个流派让我印象最深的是可观测性。无论你采用哪种架构，如果无法回答“这轮Agent到底看到了哪些上下文”，你就不可能调试好它。厂商F把上下文记录和审计当成Agent基础设施的一部分，每次调用的输入输出都能追溯，这个思路是所有做生产级Agent的团队都应该抄走的作业。

当然，全托管也有自己的代价：平台层面的托管状态让深度定制变得受限，尤其是复杂业务逻辑需要嵌入自定义策略时，灵活性会打折扣。它更适合标准化程度高、安全和合规要求重的行业。但“上下文快照加人工介入通道”这套设计，值得任何正式项目借鉴。

2.7 六个流派背后的同一条主线

把六个流派放到一起看，有一个特别明显的信号：没有一家还在把“写一段好prompt”当成Agent的核心卖点，大家的竞争焦点都在上下文的组织方式上。厂商A在优化工具描述和返回清洗，厂商B在管理任务清单这个共享上下文，厂商C在标准化上下文的流转schema，厂商D在跟长窗口的位置效应死磕，厂商E干脆把上下文建成了独立记忆系统，厂商F在做上下文快照和审计。

为方便对照，我把六家的技术特征汇总成一张表。这张表建议收藏，后续做架构选型时可以直接翻出来参考。

看完这张表你会发现，“取代”不是否定。Prompt Engineering并没有消失，它降级成了上下文工程里一个不起眼的子环节——在信息注入之前，决定用什么样的措辞把它包装成模型最容易消化的形态。

3. 上下文工程的四大核心技术组件与一个关键细节

有了架构层面的视野，接下来要落到能直接上手的组件上。不管哪家厂商的方案，跑进我们自己的项目里，真正起作用的都是下面这四个组件。它们之间有依赖顺序，通常建议从检索重排做起，再逐步加上压缩、路由和记忆，每一步都能看到可量化的效果。

3.1 检索与重排：让正确的信息在正确的时刻进场

检索是上下文工程最重要的一道入口。它的目的不是“找到一些相关文档”，而是“找到刚好够模型做决策的那几条核心证据”。在实际项目里，我习惯把检索拆成两步：先召回，再精排。

召回阶段用向量检索，把top 20到top 30的候选文档捞出来，这个阶段看的是召回率，宁多勿漏。真正决定质量的是精排阶段——用一个rerank模型对top候选做交叉编码打分，只取top 3到5条进入模型上下文。我做过对比实验，同样的知识库，加了重排步骤之后，答案准确率能提升超过二十个百分点，token使用量反而因为只喂了top 5而明显下降。

还有一个前置步骤是查询改写。用户问“这个政策怎么执行”，如果直接拿原句去检索，召回结果往往很散。先把问题改写成“政策执行流程 申报材料 审批时限”这样的查询句式，再去做向量检索，召回准确率会完全不同。改写可以交给轻量模型，也可以做一套规则，成本都很低。

3.2 压缩与摘要：给模型吃精粮而不是原粮

第二个组件是压缩。很多Agent项目里，工具调用返回的大段JSON、日志、原始文档，直接就被塞进上下文。这不但浪费token，更致命的是让模型抓不住重点——它分不清哪些字段是决策关键，哪些只是日志噪音。

压缩不是简单截断，而是结构化摘要。我通常的做法是：工具返回先过一层解析器，抽取对当前任务有影响的字段；再结合当前用户目标，生成一段不超过一百字的摘要；只有摘要进上下文，完整原文进外部存储，需要时再按traceId回溯。

压缩时必须特别注意保留两类信息：数值型字段（数量、额度、时间）和否定词（不、禁止、除…外）。我踩过一回“该员工不在参保范围内”被压缩成“已确认参保条件”的坑，整个流程直接跑歪。从那以后我的压缩规则里永远有一条：否定词必须原样保留，数值必须二次校验。

这个细节看起来小，实际影响极大。压缩省下的token确实爽，但信息失真带来的业务风险可能远超节省的那点成本。

3.3 上下文路由：让简单问题和复杂问题各行其道

路由组件解决的是“什么任务该花多少成本”的问题。不是所有用户请求都需要上最大的模型，简单问题用大模型又慢又贵。路由本质上是一个轻量分类器，判断当前用户意图属于哪一档复杂度，然后决定进哪个模型、用多大的上下文预算。

我项目里的默认路由策略分三档：FAQ类问题走小模型，上下文预算控制在2k token以内；普通业务问答走中等模型，预算4k；复杂任务（多条件推理、跨文档比对、工具调用链）才走大模型，预算按需放宽。这个策略上线后，系统整体成本下降了约30%，但用户体验几乎没有降级，因为多数问题根本不需要最高负载。

路由的难点在于边界情况。改错分类的兜底机制一定要有——当分类置信度低于阈值时，宁可升档送到大模型，也不要冒险降档。我之前踩过分类器把复杂问题判成简单FAQ的坑，从那以后对降档操作设置了强制门槛：置信度低于某个值时自动升档。

3.4 记忆三件套：短期、工作、长期记忆的协同

记忆是上下文工程里最容易做得稀烂的部分。很多Agent所谓的“记忆”，就是把最近几轮对话原封不动拼进prompt。这个做法在第五轮以内勉强够用，一旦对话变长或者跨会话，立刻垮掉。规范做法是拆成三层。

短期记忆保存当前会话最近N轮对话原文，N通常取6到10轮。工作记忆保存当前任务进行中的中间状态，比如审批流程走到哪个环节、已确认了哪些条件。长期记忆最容易被忽略：把跨会话沉淀下来的用户偏好、已确认事实、历史任务结论，向量化后存入记忆库，下一轮对话需要时按相关性检索注入。

三层记忆的注入策略也不一样。短期记忆每次必进，工作记忆只在任务进行中进，长期记忆则是在每次对话开始或主题切换时做一次检索拉取。你看看这个设计，本质上就是给Agent做了一套“便利贴、工作台、档案柜”的分工。少了任何一层，Agent的上下文都不完整。

3.5 一个经常被忽略的细节：上下文位置效应

最后说一个很小但非常影响效果的细节：上下文位置效应。Transformer架构的模型对上下文开头和结尾的内容关注度更高，中间部分容易被“一带而过”。所以同样的信息，放在上下文的不同位置，模型对它的重视程度完全不同。

实战里，我会把最关键的约束指令放在system prompt里（开头），把用户最新的指令和最近的对话轮次放在尾部（结尾），中间区域只安排参考性质的知识内容。这个习惯在长上下文场景下作用尤其明显。你可以做个实验：同一个任务，把关键指令从中间挪到开头，把最新用户消息放到最后，观察Agent的约束遵守率变化，多半会惊到你。

另外一个位置技巧是检索知识的放置顺序：与当前问题最相关的知识片段，排在所有检索结果的最后、也就是离模型当前推理位置最近的地方。这个“就近原则”能有效提高模型对关键证据的利用率，和上文提到的“开头结尾高权重”一脉相承。

4. 一次真实的上下文工程改造：从高频幻觉到稳定可用

方法论说了一堆，没有实战验证就容易变成纸上谈兵。下面我把上季度帮某公司内部团队做的一次Agent改造完整复盘一下。这个项目不算复杂，但非常典型——它的病征，我估计很多团队都遇到过，而且大概率正在被同样的问题折磨。

4.1 改造前的系统：一个“能跑但不敢用”的问答Agent

这是一个企业内部知识库问答Agent，主要处理员工关于政策、流程、审批的咨询。改造前的实现很常见：用户问题上屏，系统拿问题去向量库检索top 10文档片段，然后把“用户问题、最近6轮对话、检索到的10个片段、一段固定system prompt”全部拼到一起，喂给一个长窗口大模型。

表面上看，该有的都有了，但实际运营数据很不好看。最大的两个问题：一是幻觉，模型会在回答里引用知识库里根本不存在的政策条款，员工照着做就掉坑里；二是贵且慢，平均每个请求要消耗八千多token，首token响应经常超过四秒。我接手后第一反应就是：模型没问题，拼装上下文的方式有问题。

4.2 五步改造过程：查询改写、重排、压缩、路由、记忆摘要

改造没有推倒重来，而是在原有拼装逻辑上逐步加了五个环节，每一步都可以单独回滚。

第一步，查询改写。用户问题先过一遍实体识别和意图分类。比如“这个补助我能申请吗”，会被改写成“补助申请条件 我 是否符合”，作为后续检索的输入。这一步让检索召回的精准度明显提升，相关片段出现在top结果里的概率大了很多。

第二步，检索重排。检索从top 10改成先召回top 30，再用一个轻量rerank模型精排，最终只保留top 5进上下文。为了控制延迟，重排模型只跑一次，限时在一百毫秒以内。这一步是整个改造里效果最直接的一环，准确率提升大半都来自这里。

第三步，结果压缩。5个文档片段各自生成八十字以内的相关性摘要，关键数字和否定词强制保留。如果某个文档被判定为低相关，直接丢弃，不让它占上下文位置。这样做之后，token消耗的第一个拐点出现了。

第四步，路由分流。FAQ类问题直接走一个便宜的轻量模型，上下文预算控制在2k token；复杂政策解读才走大模型。分类置信度低于阈值的，自动升档而不是降档。这一步的成本收益立竿见影，但对参数调整非常敏感。

第五步，记忆摘要。多轮对话进行中，每两轮把“已确认的约束条件和已回答过的结论”压缩成一条记忆摘要，在下一轮注入上下文；原始对话轮次只保留最近4轮，更早的内容归档到外部存储。这一步解决了长会话里“前面说了后面忘”的老毛病。

4.3 改造效果与三个印象深刻的坑

改造上线后跑了两周，效果对比如下：

整体token用量下降了近四成，延迟砍掉一半以上，幻觉率从两位数降到个位数。这个结果不算惊艳，但胜在稳健，而且所有改造项都是一两周内能交付的工程量级，没有引入任何新的重型基础设施。

过程中的三个坑值得写一笔。第一个坑在查询改写：一次用户问“离职后公积金怎么提取”，改写模块把“公积金”实体识别错乱，导致检索召回一堆社保流程，回答自然全错。后来给改写模块加了fallback机制，改写结果置信度过低时直接用原句检索。

第二个坑在压缩环节：前面也提过，把“该员工不在参保范围”压缩成“已确认参保条件”，直接让流程判定反转。我们立刻改成规则强制保留否定词和所有数字，压缩后还会跑一个简单的逻辑校验，防止摘要丢关键属性。

第三个坑在路由置信度阈值。一开始阈值设得过高，大量普通问题被分流到升档，成本不但没降反而升了。后来把降档阈值从0.85调低到0.7，并让分类置信度曲线在真实流量上跑了一周再固化参数。这个教训说明路由参数不是拍脑袋设的，必须基于实际分布调整。

5. 看完六家架构后，我对落地选型的一些判断

解剖完六家厂商的架构，又做完自己的实战改造，我对Agent落地选型的一些判断也成型了。这里不是替谁站台，而是说如果是我的团队要上新项目，我会怎么选、怎么看。不同阶段的团队，适合的架构差异非常大，跟着大厂方案走不一定适合自己。

5.1 不同规模团队的架构选型参考

如果团队只有三到五个人，正在做第一个Agent产品，我会建议走厂商A的思路起步：单Agent加原生工具调用，工具数量控制在10个以内，工具描述写细，返回结果做好清洗。这个方案的架构成本最低、出活最快，足够支撑从0到1的验证，也最容易观察上下文工程到底在解决什么问题。

当Agent开始处理长流程任务、或者需要跨会话记忆时，再去加中心化记忆层和路由组件。这个阶段对应厂商E和前面实战案例的做法，是并行的两件事，不需要等模型能力进化。记忆服务和路由策略可以独立交付，各自都能带来立竿见影的效果。

如果团队已经做到企业级交付、面对的是合规要求高的行业客户，我会认真考虑厂商F的全托管会话方案，或者至少把会话快照、审计日志、人工介入通道这几个能力做进自己的平台。可观测性在Agent生产环境里是刚需，不是可选项。出问题不能复盘，再好的上下文工程策略也无法持续迭代。

统一协议生态类的标准化方案，更适合平台型产品。它解决大量第三方工具接入时的描述混乱问题，早期引入会比较重，但会随着生态扩大产生复利。如果你的产品只是内部用、工具是自研的，这个方案的优先级可以放低。

5.2 哪些架构设计未来会被模型进化削弱

模型能力还在快速进化，有些架构设计的护城河会被逐渐削弱。最典型的是纯吃超大上下文窗口的方案。如果下一代模型的长窗口能力继续变强、成本继续下降，部分过去必须靠外部检索才能完成的任务可能真的可以靠窗口硬读。但注意，这个趋势不是取消上下文工程，而是改变它的重心——从“怎么筛信息”变成“怎么组织信息以对齐人类偏好”。

另一个会被削弱的设计是纯模板化的prompt管理。当模型越来越擅长理解口语化和非结构化指令时，精心堆砌的提示词模板价值会继续下降。但反过来，工具描述的工程化、记忆的可信度管理、路由的收益优化，这些需求只会越来越强。

大家没必要对“被模型进化淘汰”太焦虑。上下文工程本质上是把Agent当作一个系统来设计的思维，模型进化可能改变系统中某个组件的权重，但不会取消“系统设计”本身。那些把上下文工程修炼成肌肉记忆的团队，换什么模型都能快速适应。

5.3 上下文工程方向上的学习路线

最后给一条我自己带人时用的学习路线。第一步，先把单Agent加工具调用跑通，熟悉工具描述和返回清洗的重要性。第二步，给Agent加记忆摘要，体会短期、工作、长期三层记忆的差异。第三步，做检索重排和查询改写，把外部知识注入的质量提上来。第四步，引入路由，学会在不同成本档位之间做权衡。等基本功都扎实了，再去研究多Agent编排和复杂图结构。

每一步都可以在上一步的基础上增量式改造，做完都有可量化的效果。我建议每完成一步，就在Agent的日志里加上一句上下文统计，记录每轮注入多少个token、分别来自哪些来源。跑一天下来，你会对自己系统里的上下文现状有一个非常直观的认识，然后才知道该往哪个方向优化。

说回这篇文章的主题。拆完六家厂商的架构，又做了一次完整的实战改造，我最大的感受是：Agent的世界已经从“靠一张嘴写指令”进化到了“靠一套系统管理信息”的阶段。上下文工程不是什么玄学，它就是一套朴素的工程方法——该筛的筛掉，该留的留住，该放在前面的不放在后面。

如果只让我留一条经验，那就是：在考虑换更大的模型之前，先把当前模型每一轮看到的上下文拉出来复盘一遍。绝大多数生产事故，根源都藏在那堆被塞进上下文的信息里。最后分享一个小技巧：在Agent的主循环里加一行结构化日志，记录每次注入的上下文来源和token消耗，跑一两天再回头看，你会立刻知道下一步该动哪里。我每次接新项目都从这一步开始，几乎没有任何一次是无功而返的。