一次线上事故让我重新认识了Multi-Agent系统三个专职Agent并行协作单看每个角色都设计得无可挑剔可合成结果却漏洞百出——A Agent拿到的用户意图已经过期B Agent参考的上下文和数据源互相对不上C Agent干脆把自己工具调用返回的原始JSON当成了最终答案。排查到最后问题不出在模型、不出在提示词、也不出在哪个Agent的逻辑上而是整个系统根本没有一套像样的上下文工程Context Engineering机制。那一刻我才意识到Multi-Agent的真正瓶颈根本不是让多少个Agent跑起来而是让它们共享同一套可信、有序、新鲜的上下文。这篇文章我想把这段时间摸出来的上下文工程方法论完整梳理一遍。这篇文章适合谁看如果你是做Agent应用的开发者或者正在从单Agent往Multi-Agent架构迁移又或者已经踩过多Agent互相打架的坑但没有找到系统性的解决思路那这篇内容应该能给你一条比较清晰的路径。我会把Context Engineering是什么、它和Prompt Engineering的边界在哪里、在Multi-Agent里具体怎么落地、以及我实际踩过的坑和排查思路都摊开来讲。1. 为什么说上下文才是Multi-Agent系统的真正瓶颈先讲一个我自己的教训。有个模拟项目我搭建了一套由调度Agent、信息检索Agent、内容生成Agent组成的协作链路每个Agent都用了当时效果很好的模型提示词也做了精细调优单测全过。结果一上真实流量立刻出现一个让人头疼的现象调度Agent给检索Agent派活时传过去一段被截断的对话摘要检索Agent基于这段不完整的信息去查资料然后把结果原样传回给生成Agent生成Agent没意识到这部分内容已经被污染了直接把错误的中间产物写进了最终回复。整个链路没有一个环节抛错但整条链路的结果就是错的。这个案例说明了一个很反直觉的道理Multi-Agent系统的能力上限不取决于单个Agent的推理能力也不取决于提示词写得多精妙而是取决于上下文在Agent之间流转时的完整性、一致性和保鲜度。1.1 单Agent时代被掩盖的三个隐患单Agent时代上下文工程的问题被极大掩盖了因为上下文只在一条链路里跑用户输入进模型模型返回输出偶尔加个工具调用路径很短、变量很少。即便上下文写得乱一点、旧一点出错的概率和影响范围都有限。Multi-Agent一上来至少三个隐患会立刻暴露第一上下文一人一份变成了多人传阅。每个Agent都有自己的一段上下文窗口而Agent之间传递信息的唯一方式就是上下文拼接。只要有一个Agent在传递时做了删减、压缩或者格式转换信息就会失真。失真后的信息再叠加到下一个Agent的上下文里错误就成倍放大。第二上下文时效性失控。单Agent场景下模型对话的上下文天然是时间有序的。到了Multi-Agent里多个Agent可能是并行跑的它们各自拿到的状态可能是同一时刻的不同切片。调度Agent分配任务的那一刻和检索Agent真正执行检索的那一刻之间数据可能已经变了。第三上下文长度预算争夺。每个模型的上下文窗口是有限的而Multi-Agent系统天然会往上下文里塞更多东西角色设定、工具定义、历史消息、中间结果、其他Agent的输出。塞得越多模型真正用来推理的有效空间就越小。没有一套上下文预算管理机制系统会慢慢变得什么都知道一点但什么都想不清楚。1.2 本质上下文在Multi-Agent里是一种需要治理的数据流我后来想明白了一件事如果把Multi-Agent系统看成一个组织那上下文就是这个组织的工作记忆。组织里每个人都在读写这份工作记忆有的人写得潦草有的人读得马虎有的人改了别人的记录有的人拿到的还是昨天的版本。没有治理组织必然混乱。这也是Context Engineering和普通工程手段最根本的区别它不是在优化某个Agent的某次输入输出而是把上下文当作一条跨Agent流动的数据流来做设计、监控和治理。要考虑它从哪里来、经过哪里、在哪里被改写、在哪里被消费、在哪里过期。所以我的判断是任何一个Multi-Agent项目如果做到第二个里程碑之后还没有一套显式的上下文管理方案那它离失控就不远了。不是危言耸听是上下文问题都会以偶发性的结果质量下降这种最隐蔽的方式出现等到你意识到的时候整条链路的信任已经崩了。2. 把Context Engineering和Prompt Engineering的边界彻底掰开很多人一听上下文工程第一反应是这不就是写提示词吗真不是。它在概念上和Prompt Engineering有明确边界但实操中二者又有很强的互补性。2.1 两者到底有什么不同我用一个交通类比来拆解。Prompt Engineering更像是给每个司机Agent发一张详细的路书什么时候该转弯、遇到路口怎么判断、目的地附近有什么标志。它优化的是单个Agent在给定信息下做判断的质量。Context Engineering则是负责整个交通系统的基础设施路网怎么规划、红绿灯怎么联动、哪条路要临时封闭、哪个路口的通行优先级更高。它优化的是信息在多个Agent之间如何被传递、如何被保持新鲜、如何被合理分配。一个管微观判断一个管宏观流动。放在项目里看区别就更明显了Prompt Engineering的产出物是一份份精调过的提示词模板它的调试对象是一个Agent单次输入输出Context Engineering的产出物是上下文的结构定义、流转规则、压缩策略和预算分配方案它的调试对象是整条多Agent链路的上下文生命周期。2.2 为什么Multi-Agent必须把上下文工程单独拎出来做我在早期项目里犯过的最大错误就是试图用把提示词写得更详细来解决多Agent协作的问题。比如检索Agent返回的信息格式不稳定我就在提示词里加一句请严格按照JSON格式输出——结果发现治标不治本因为问题根本不是Agent不听话而是下游Agent拿到的JSON里嵌套了一层意外的数据结构解析错了。这类问题的责任方不在提示词而在上游Agent的上下文输出协议不明确、结构契约缺失。再怎么写提示词也解决不了跨Agent的数据契约问题。打个更具体的比方Prompt Engineering是让一个Agent读得更懂Context Engineering是让一条流水线传得更稳。前者靠语言表达后者靠结构设计、规则约束和监控反馈。2.3 两者正确的关系是互补不是替代不是说做了上下文工程就不用调提示词了。在Multi-Agent架构里我的实践感受是上下文工程先把信息流转的管道修好Prompt Engineering再在管道两端把信息的理解质量调优。管道不通提示词再精致也白搭管道通了但提示词写得含糊每个Agent的理解质量也会拖后腿。具体到项目里的分工我习惯这样切上下文工程负责定义每一跳之间传什么结构的数据、每个字段的语义是什么、什么情况下数据要被刷新或淘汰、每个Agent的上下文窗口里放哪些内容Prompt Engineering负责在既定的上下文结构里把每个Agent的角色行为、判断依据、输出格式约束描述清楚。两条线各管各的但产出的文档和配置要放在一起评审因为上下文结构一变提示词里的引用字段可能就失效了。3. 拆解Multi-Agent场景下上下文管理的四个核心维度Context Engineering在Multi-Agent里不是一个单一动作它至少包含四个互相咬合的维度。我在项目里把它们分别叫作记忆分层、预算分配、信息路由、生命周期治理。四个维度缺一不可否则就会出现各种看起来没问题但总不对劲的系统性症状。3.1 维度一记忆分层——别把所有历史都塞进同一个口袋很多Multi-Agent系统最常见的偷懒做法是把所有Agent共享的对话历史、工具调用记录、中间结果全部拼在一起作为一个大上下文传给每个Agent。这个做法有两个致命问题一是每个Agent都背着和自己无关的信息白白占用上下文窗口二是Agent分不清哪些信息是当前这个任务必须关注的哪些是历史参考。我的做法是把上下文按记忆类型分层每层职责清晰每层有独立的读写策略。这个思路很多做过单Agent长对话的人可能不陌生但Multi-Agent场景下的分层维度会更细全局记忆层存放跟整个会话相关的稳定信息比如用户的长期偏好、当前会话目标、核心约束条件。这一层所有Agent都能读但只有调度或协调Agent能写。任务记忆层存放当前这个多Agent协作任务的过程数据比如任务拆解结果、每个子任务的完成状态、关键决策记录。这一层由协调Agent管理其他Agent按需读写。局部记忆层存放单个Agent执行任务时产生的临时数据比如检索Agent的候选列表、筛选过程中的中间判断。这一层默认只对产生它的Agent可见只有被显式提升为产出物的内容才会进入任务记忆层。瞬时记忆层存放单次工具调用的输入输出、单次模型推理的中间步骤。用完即弃除非有明确理由否则不进入高层记忆。这套分层方案的价值在于它让每个Agent拿到的上下文是量身定制的而不是全家桶式的。我见过不少项目的上下文长度爆炸本质上就是没有分层什么东西都往全局层里塞。3.2 维度二预算分配——上下文窗口是一项需要精打细算的稀缺资源模型上下文窗口再大也是有限的。Multi-Agent场景下上下文里要装的东西远比单Agent多所以不做预算管理等于慢性自杀。我把上下文预算拆成四个桶每个桶有硬性占用比例上限角色与规则桶放Agent的人设、职责边界、行为准则一般控制在总预算的10%-15%。这个桶基本是静态内容一旦确定很少变动。工具与数据桶放工具定义、API说明、可用的数据源信息控制在15%-20%。工具定义能压缩就压缩能精简描述就精简描述这部分是最容易被忽视的隐性占用。任务上下桶放当前任务的目标、约束、历史关键节点控制在30%-40%。这部分要动态管理随时根据任务进展调整。模型输出预留桶给模型生成留出足够的推理空间我会刻意留出20%-30%。很多系统上下文塞得满满当当模型只能挤着生成输出质量肉眼可见地下降。这组比例不是拍脑袋定的我按不同模型、不同任务类型调过好几版最终发现模型输出预留桶一旦低于15%结果质量会明显劣化。用个类比来说上下文窗口就像工作台工具、图纸、材料全堆上去之后总得留出动手操作的空间。3.3 维度三信息路由——每个Agent只该看到它该看到的东西Multi-Agent系统里信息天然是分散在各个Agent手里的。信息路由要解决的核心问题是一个Agent在什么时候需要另一个Agent手里的什么信息以及以什么形式拿到。我在做信息路由设计时会强制自己画清楚一张信息依赖表每个Agent的输入信息从哪里来、输出信息往哪里去、信息的时效要求是什么、格式要求是什么。这张表一旦画出来很多隐藏问题就现形了——比如两个Agent之间居然有一条谁都没意识到的隐性依赖或者某个Agent的输入信息源头已经过期了但没人负责刷新。形式上信息路由可以分为主动拉取和被动推送两种。需要最新数据的Agent主动向数据源拉取需要事件驱动的场景则由上游Agent在关键节点完成后向下游推送事件通知。设计原则是能拉取的尽量不推送因为推送容易产生过期的副本。3.4 维度四生命周期治理——上下文要保鲜而不是永久保存这是最容易被忽略的一个维度。很多Multi-Agent系统的上下文一旦写进去就再也不会被清理久而久之整个上下文充满了已完成的子任务细节、已失效的中间结果甚至相互矛盾的信息。生命周期治理要定义三件事过期策略哪些上下文在什么条件下算过期、刷新机制过期后由谁负责刷新、从哪个源头刷新、淘汰顺序预算不足时先淘汰哪部分内容。实践里我养成了一个习惯上下文里的每一条关键信息都打上时间戳和来源标识。时间戳用来判断新鲜度来源标识用来追踪它是哪个Agent在哪个阶段写入的。有了这两个字段排查上下文污染问题的时候效率能高一倍。4. 落地一套参考架构以模拟项目X的上下文流水线为例理论说得再多不如一个具体项目的落地过程有说服力。这里我用一个自己实际搭过的模拟项目X来演示这个项目的目标是用两个专职Agent协作完成从用户原始诉求到结构化方案的任务中间涉及检索外部知识、分析用户意图、生成结构化方案三个环节。4.1 项目背景与架构选型模拟项目X的业务场景是这样用户提交一个相对模糊的需求描述系统需要理解用户的真实意图从知识库中检索相关内容然后生成一份结构化的建议方案。单Agent也能做但效果一般——要么检索不够精准要么方案结构不稳定。拆成调度Agent、检索Agent、生成Agent三个角色之后各角色专精一条链路效果明显改善。三个Agent的协作模式是顺序执行加事件通知调度Agent解析用户输入并生成任务计划发出检索任务启动事件检索Agent监听事件后执行检索完成后将结果写入共享的任务记忆层并发出检索完成事件调度Agent收到事件后启动生成Agent生成Agent从任务记忆层读取检索结果和任务计划生成最终方案。4.2 上下文流水线的五个关键设计这条流水线看着不复杂但里面每一处细节都是上下文工程的具体落地。我按从输入到输出的顺序拆开讲。第一步统一上下文入口做标准化解析。所有Agent拿到的原始输入先经过一个解析器把非结构化的用户需求转成标准化的上下文对象包含用户原话、解析后的意图标签、疑似隐含需求、不确定项等字段。这一步的价值是让后续所有Agent面对的数据结构一致不会出现你传你的纯文本我传我的JSON这种各说各话的局面。第二步按角色定制上下文装配器。每个Agent在启动前会从一个装配器里领取自己的上下文。装配器知道这个Agent的角色、当前任务阶段、哪些信息对它有用然后从全局记忆层、任务记忆层、局部记忆层各取所需拼成一个定制上下文集。调度Agent拿到的上下文集包含完整任务计划检索Agent拿到的上下文集包含用户意图标签和检索范围但不包含历史对话全文。第三步输出协议化。每个Agent的输出不是自由文本而是符合预定义协议的结构化产出。比如检索Agent的产出必须是候选条目列表每条包含来源ID、摘要、相关度评分、时间戳生成Agent的产出必须是包含建议方案、依据引用、风险标注的结构化文档。为了做到这一点光靠提示词约束不够我会在Agent输出后加一个轻量的校验环节发现协议不合法就触发一次重试重试仍失败就直接报错并走降级流程。第四步共享上下文用版本号管理。任务记忆层里的关键条目都带版本号任何Agent在写入更新时会递增版本。这样既能追踪上下文演变过程也能避免上一个Agent写入的数据被下一个Agent用旧版本覆盖这类并发问题。版本冲突检测很简单但非常管用尤其是并行执行的场景。第五步上下文审计日志。每一次Agent读上下文、写上下文、压缩上下文、淘汰上下文的行为都会被记录到审计日志里包含被操作的上下文ID、操作类型、操作前后摘要、时间戳。这个设计在开发和调优阶段帮了大忙——任何一次结果异常我都能顺着审计日志反推是哪一跳的上下文出了问题。4.3 实测数据上下文工程介入前后的对比这套架构上线后我做了一个针对性对比测试同样一批20条测试用例在无显式上下文管理的对照组和完整上下文流水线的实验组里各跑一遍。结果是实验组的任务完成率从65%提升到90%上下文平均体积下降了约40%单任务平均耗时基本持平但返工和重试次数明显减少。有个现象特别值得说对照组的失败案例里有相当一部分是检索Agent明明给了正确结果但生成Agent输出时引用了错误的历史上下文导致方案和检索结果对不上。实验组把检索结果模板和历史对话做了隔离之后这类信息串线问题几乎绝迹了。5. 上下文污染排查实战三个典型翻车场景与修复过程再好的设计落到线上也会遇到幺蛾子。我整理三个真实踩过的坑完整的排查过程比答案本身更有价值。5.1 翻车场景一Agent记忆串线——把别的任务的信息当成当前任务的依据现象是用户连续提交两个不同领域的任务第二个任务的结果里居然混入了第一个任务的元素。初步判断是上下文清理不彻底但深挖下去发现原因更微妙——第二个任务的上下文装配器在从任务记忆层取值时读到了旧任务的残留数据因为新旧任务使用了相同的上下文存储键而旧任务的清理动作只清了全局层没清任务层。修复方案分两步第一给任务记忆层加了领域标签每个任务的数据绑定唯一的命名空间第二新任务启动时用任务ID领域标签双键定位从根本上杜绝跨任务的意外读取。这个坑提醒我上下文治理必须做到按任务隔离不能所有任务共用同一块上下文区域。5.2 翻车场景二上下文叠罗汉——无用中间结果把有效信息挤出窗口现象是系统连续跑几轮任务之后Agent的输出质量越来越差。一开始怀疑是模型稳定性问题但审计日志揭了底——某轮任务中一个Agent把大段原始JSON中间结果原封不动写入了任务记忆层后续所有Agent在装配上下文时这些垃圾数据又都占用了预算。几次任务叠加有效上下文占比越来越低。这个坑的教训在于上下文压缩不能只靠事后清理必须在写入环节就立规矩。我给写入任务记忆层的每条数据加了三道闸门数据源是否可信、是否包含可被后续步骤消费的结构化字段、是否经过必要的格式规整。不满足写入标准的数据直接留在局部记忆层或瞬时记忆层不让它污染任务层。5.3 翻车场景三并发冲突——两个Agent同时更新同一条上下文导致覆盖现象比较隐蔽并行执行的两个Agent常出现各自都成功但共享结果互相矛盾的现象。查审计日志后发现A Agent和B Agent在相近的时间窗口内都改写了同一条共享上下文后写入的一方直接覆盖了先写入方的更新。修复方案是在共享上下文层引入读改写的版本校验机制Agent在读取上下文时携带版本号写入时如果发现版本号已变更就触发冲突回调由协调Agent决定基于哪个版本合并。这个机制上线后并发冲突从偶发变成几乎为零也给后续引入更复杂的多Agent并行协作打了个基础。5.4 排查链路方法论怎么快速定位上下文污染源上面三个案例背后我沉淀了一套自己的排查链路分享出来供参考第一步看审计日志圈定第一现场。不要一上来就怀疑模型先去审计日志里找到结果异常发生前最后一次正常的上下文快照对比异常发生前后哪些上下文数据发生了变化。这个步骤能把问题范围从整条链路缩小到某一跳的某一段数据。第二步查来源标识定位污染源头。上下文里每条数据都有来源标识一旦锁定异常数据就能直接找出是哪个Agent在哪个阶段写入的。如果找不到来源标识说明数据写入环节不合规这本身就是隐患。第三步做隔离实验验证根因。把嫌疑数据从上下文里摘出去单独跑一次同样的任务。如果结果恢复正常根因基本就锁定了如果结果没好继续向前回溯。第四步修复后补一条回归用例。把污染场景固化成一条回归测试用例防止同类型问题再次上线。6. 上下文调优的经验阈值与量化思路排查完问题之后很多人的下一个困惑是上下文工程做到什么程度才算够用这个问题没法拍脑袋回答但可以通过几个量化指标来判断。6.1 我最常盯的五个指标上下文有效密度有效信息占比。我用任务关键信息Token数除以总上下文Token数来做衡量。任务关键信息的判定依赖分层设计每层的信息密度分开统计更好。经验阈值是任务层密度低于15%就要警惕低于10%基本可以判定上下文已被无效信息淹没。信息新鲜度关键上下文数据的平均年龄。给每条上下文数据打上时间戳之后可以算出任务层数据的平均年龄。如果一轮任务跑完某些关键数据已经有隔夜年龄了说明刷新策略失效了。上下文写入合规率通过三道闸门校验的写入请求占总写入请求的比例。理想情况是接近100%如果这个比例很低说明Agent输出协议约束失效或者写入拦截规则太严格需要调整。干扰信息命中率最终答案中出现非当前任务相关信息的比例。这个指标在测试集上人工标注一旦归零我的上下文隔离基本就算做到位了。返工重试率因为上下文导致的返工重试占总调用次数的比例。这是一个综合指标我长期监控的变化趋势。6.2 调优过程中的一般节奏我的调优顺序是先把结构搭对再调预算再压缩冗余最后做细节调优。具体来说第一阶段重点检查信息依赖表是否完整、每个Agent是否只拿到需要的信息这个阶段一般能解决掉大部分上下文串线问题第二阶段按前述预算比例调整各区域的Token占用确保模型输出预留充足这个阶段往往会带来立竿见影的效果第三阶段针对每个Agent实际消耗的上下文逐项做冗余压缩比如精简工具描述、删除已完成的中间步骤这个阶段是细节活收益是持续性的。6.3 上下文工程不是一次性工作我见过最大的误区是把上下文工程当成一个做完就完事的配置任务。实际上上下文结构、Agent角色、业务场景都在演化任何一个环节变了上下文设计就得跟着调整。我现在的做法是把它纳入常规迭代节奏重点观察信息依赖表是否有变动一旦发现依赖关系变了就追着它把上下文设计重新过一遍。7. 一些更深的工程思考与边界写完方法论我还想聊几个不太被人提起但很重要的点。Context Engineering听起来很工程化但真正的对抗对象其实是Multi-Agent系统固有的信息熵增风险。Agent越多上下文变体越多信息在传递中被扭曲、被稀释的可能性就越大。上下文工程本质上是在对抗这个熵增过程手段包括结构约束、路由规则、生命周期管理、审计追踪。另一个容易被忽略的边界是上下文工程解决的是信息流动问题但解决不了Agent能力问题。如果一个Agent本身的推理能力不足以完成任务再完美的上下文设计也只是让它更清晰地犯错。所以不要神话上下文工程它和模型能力、任务设计、各Agent的专业能力是并行的支柱。还有一点涉及成本上下文压缩和审计日志都是有代价的。压缩算法会引入额外延迟审计日志会放大存储开销。在资源敏感的项目里我会做分层采样——全量审计在高风险节点保留低风险节点只记录关键事件摘要。工程的意义在于平衡不在于堆料。安全边界也值得提一句上下文里经常包含用户私人信息在Multi-Agent之间流转时要确保访问范围符合隐私约定。任务隔离的设计同时承担了合规隔离的职责这个点可以在架构评审阶段就纳入考量而不是事后补救。最后再分享一个实际体会Context Engineering上手的第一步不是去写复杂框架或引入重武器而是先给自己的系统建立一个简单的上下文审计日志。哪怕只是把每条上下文数据的来源、时间戳、写入阶段记录下来都会带来巨大的感知差异。我在这套方法论里的很多认知都是靠翻审计日志翻出来的。先用最简单的手段做到可见再谈优化和治理。这一步做完你大概率会看到一个不一样的Multi-Agent系统。