从提示工程到上下文工程：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就能精准命中合适的工具描述写得含糊就算工具本身很强大模型也只会把它当“不知道能干什么的野生接口”跳过去。统一协议带来的还有一层隐性好处工具的返回报文有了统一schemaAgent可以在协议层就把大字段截断、过滤、转换让干净的结果进入主上下文。这种“标准化即可治理”的思路在工具数量上百时特别值钱。生态型架构的代价是所有工具都要先经过标准化封装前置成本高一些一旦跑起来三角色之间的上下文流转会显得非常规整。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在做上下文快照和审计。为方便对照我把六家的技术特征汇总成一张表。这张表建议收藏后续做架构选型时可以直接翻出来参考。流派架构核心上下文工程重点主要短板适合场景厂商A模型原生工具调用派工具调用内化为模型能力工具描述文档与返回清洗依赖模型原生能力工具多时视野受限单Agent快速落地、工具少于10个厂商B规划器执行器分离派规划拆解目标、执行器干活任务清单共享上下文与状态隔离双模型开销清单同步易出问题长流程任务、需要中断恢复厂商C统一协议生态派工具接入与调用标准化工具能力描述字典与schema过滤标准封装前置成本高平台型产品、第三方工具众多厂商D超大上下文窗口派长窗口硬读全部信息内容分区与优先级排序成本高、注意力稀释、长窗≠长记忆原型验证、对延迟不敏感的离线分析厂商E中心化记忆派独立记忆服务分层存储记忆写入、更新、过期、防污染记忆一致性维护成本高长时间运行的业务Agent、跨会话场景厂商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消耗82005100首token平均响应4.2秒1.8秒幻觉事件人工抽查每百次约11次每百次约2次升档/降档占比无升档约6%降档约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消耗跑一两天再回头看你会立刻知道下一步该动哪里。我每次接新项目都从这一步开始几乎没有任何一次是无功而返的。