1. 从提示词调优到上下文工程多智能体系统正在经历什么如果你最近半年一直在折腾多智能体系统大概率会有一种很强烈的割裂感一方面单个智能体的提示词已经被你打磨到近乎完美角色设定、输出格式、few-shot 示例全都齐了另一方面一旦把三五个智能体放进同一个任务流里整个系统就开始精神分裂——A 智能体输出的结构化 JSON 被 B 智能体当成自然语言理解C 智能体的中间推理过程污染了 D 智能体的上下文窗口最后汇总出来的结果连你自己都不敢认。这不是提示词的问题这是上下文工程的问题。我在过去一年里陆续搭过七八套多智能体协作系统从最简单的规划者-执行者-审查者三件套到带 RAG 检索、带工具调用、带长期记忆的复杂编排踩过的坑几乎都指向同一个根因大多数人把多智能体系统当成多个提示词的叠加而它本质上是一个上下文在多个推理单元之间流动、变形、衰减的架构问题。提示词工程解决的是单个智能体怎么想上下文工程解决的是多个智能体之间怎么传递、隔离、压缩、重建上下文让推理过程透明可追溯。这一篇是多智能体系统上下文工程系列的第五篇前面几篇分别聊了上下文窗口的预算分配、RAG 检索结果如何注入、智能体间消息协议的设计、以及长期记忆的读写策略。这一篇我想把视角拉高一层专门讲上下文与推理的透明架构引擎——也就是当系统里同时存在多个智能体、多轮推理、多源上下文时你怎么设计一套引擎让每一次推理的输入是什么、输出是什么、为什么这么决策全部可观测、可回放、可调试。关键词里出现了 RAG、提示词工程、推理架构、多智能体系统还有一堆关于鹈鹕骑自行车提示词这类测试用例的热词。这些热词其实反映了一个很真实的现状大家测提示词的方式还停留在单点测试——给一个模型一个刁钻的提示词看它能不能画出鹈鹕骑自行车。但多智能体系统的测试复杂度是单点的指数级你没法靠喂一个提示词看输出来判断系统好坏你需要的是推理链路的透明化。这篇文章适合谁看如果你已经写过至少一个能跑通的多智能体 demo但一到真实任务就各种翻车如果你在用 LangChain、LangGraph、AutoGen、CrewAI 这类框架但总觉得框架帮我做了太多黑盒决策如果你正在做 RAG 知识库发现检索回来的内容塞进多智能体流程后效果反而变差——那这篇就是写给你的。我会尽量少讲抽象概念多讲我实际搭引擎时的结构设计、参数取舍和踩坑记录。2. 透明架构引擎的四层结构为什么不能只靠框架默认编排2.1 大多数框架默认编排的黑盒到底黑在哪先说一个我自己的真实经历。早期我用某个主流多智能体框架搭了一个研究员-分析师-写手的流水线跑简单任务时效果惊艳但一旦任务变复杂问题就来了写手输出的内容里混进了分析师的中间推理草稿研究员检索到的原始网页片段被原封不动塞进了最终报告而且我完全不知道是哪一步出的问题。框架的日志只告诉我Agent B 调用了 Agent C但没告诉我Agent B 传给 Agent C 的上下文里到底有什么。这就是黑盒编排的典型症状。框架为了通用性默认帮你做了几件事自动拼接历史消息、自动传递上一步输出、自动管理对话轮次。这些自动在 demo 阶段是便利在生产阶段是灾难因为上下文的每一次拼接、截断、传递都是一次信息的有损变换而你对这些变换一无所知。我后来总结一个透明的上下文架构引擎必须显式管理四层结构缺一层都会导致调试时抓瞎层级职责不显式管理的后果上下文采集层决定每个智能体能看到哪些信息检索结果、历史记忆无差别注入窗口爆炸上下文变换层压缩、摘要、结构化、脱敏原始噪声污染下游推理推理执行层单次 LLM 调用的输入输出快照无法回放无法定位是哪次调用出错追溯与回放层记录完整推理链路支持重放出问题只能靠猜无法复现这四层不是框架给你的是你必须自己设计的。框架可以帮你做执行但上下文的语义边界必须由你定义。2.2 上下文采集层每个智能体应该看到什么而不是能拿到什么采集层的核心原则只有一句话按需注入而非全量传递。我见过太多系统把整个对话历史、所有检索结果、所有工具返回值一股脑塞给每个智能体理由是信息越多越好。这是错的。上下文窗口是有限资源而且更关键的是无关信息会稀释相关信息的注意力权重。我的做法是给每个智能体定义一个上下文契约Context Contract明确声明它需要哪几类信息# 上下文契约示例分析师智能体 analyst_context_contract { required: [task_goal, research_summary], # 必须注入 optional: [raw_sources], # 按需注入 forbidden: [other_agents_reasoning_trace], # 禁止注入 max_tokens: 4000, priority: [task_goal, research_summary, raw_sources] }注意forbidden这一项。其他智能体的推理草稿reasoning trace是最容易被误注入、也最容易造成污染的内容。研究员的我觉得这个来源可能不太可靠但先记下来这种内心独白如果被注入到写手的上下文里写手可能会莫名其妙地在报告里写这个来源不太可靠。推理草稿应该被隔离在产生它的智能体内部只把结论传递给下游。采集层还有一个容易被忽略的点上下文的时效性标记。RAG 检索回来的内容、长期记忆里读出的内容、当前任务实时产生的中间结果这三类信息的可信度和时效性完全不同。我会给每条上下文打上来源标签和时间戳让下游智能体知道这条信息是三天前从知识库检索的可能已经过时。2.3 上下文变换层压缩不是删减是语义重建变换层是四层里技术含量最高的一层。很多人理解的上下文压缩就是截断或者摘要但真正的变换应该是语义重建——把冗长的原始上下文重建成下游智能体真正需要的、结构化的、无歧义的信息。我常用的三种变换策略第一种是结构化提取。比如研究员检索回来一堆网页不要直接把网页文本传给分析师而是让一个轻量的提取步骤把网页内容转成结构化字段{claim, evidence, source, confidence}。这样分析师拿到的是干净的断言列表而不是一堆 HTML 噪声。第二种是分层摘要。对于长对话历史不要用一次摘要压到底而是做分层最近三轮保留原文三到十轮做段落级摘要十轮以上做要点级摘要。这样既保留了近期上下文的细节又控制了总长度。第三种是冲突消解。当多个来源的信息互相矛盾时RAG 检索到 A 说 X长期记忆里 B 说非 X变换层要显式标记冲突而不是让下游智能体自己纠结。我会生成一个conflicts字段把矛盾点列出来让下游智能体知道这里存在不确定性。提示变换层最容易犯的错是过度压缩。我踩过一次坑把检索结果压缩得太狠导致关键数字被摘要掉了下游智能体基于错误信息推理整个任务跑偏。后来我定了个规矩涉及数字、日期、专有名词的内容压缩时必须原样保留不允许摘要改写。2.4 推理执行层与追溯层让每一次 LLM 调用都可回放执行层的关键是快照。每一次 LLM 调用都要完整记录输入 messages变换后的最终版本、模型参数、输出内容、token 消耗、耗时。这不是为了日志好看而是为了回放调试。我搭的引擎里每次调用会生成一个trace_id结构大概是这样{ trace_id: task_2024_xxx_step_3, agent: analyst, input_snapshot: { messages: [...], context_sources: [research_summary_v2, task_goal], token_count: 3820 }, output: {...}, latency_ms: 4200, model: xxx }有了这个当最终结果不对时我可以沿着 trace 链一路回溯是采集层注入了错误信息是变换层压缩丢了关键内容还是执行层模型本身推理出错没有快照你只能靠猜有了快照问题定位从小时级降到分钟级。追溯层还要支持重放。我实现过一个简化版重放给定某个 trace_id用完全相同的输入重新调用一次模型看输出是否一致。这能帮我区分是上下文问题还是是模型随机性问题。如果重放输出一致说明是上下文设计的问题如果不一致说明是模型本身的方差需要调温度参数或加约束。3. RAG 在多智能体上下文里的正确接入姿势3.1 为什么 RAG 塞进多智能体后效果反而变差关键词里 RAG 出现频率极高还有rag瓶颈rag检索增强rag智能体这些词。我自己的观察是单智能体 RAG 效果通常不错但多智能体 RAG 经常翻车。原因有三个。第一检索时机错位。单智能体里检索通常发生在回答前一步检索结果直接进上下文。但多智能体里如果每个智能体都各自检索一遍会出现重复检索、检索结果不一致、检索结果互相覆盖的问题。我见过一个系统研究员检索了 5 篇文档分析师又检索了 5 篇写手再检索 5 篇最后上下文里塞了 15 篇文档其中大量重复窗口直接爆掉。第二检索结果没有经过变换就注入。原始检索片段是给人看的不是给智能体看的。它包含大量导航栏、页脚、无关段落。直接注入会严重稀释有效信息。第三检索结果的可信度没有传递。RAG 检索回来的内容质量参差不齐但下游智能体不知道哪条可信。如果检索层不标注置信度下游就会把低质量内容和高质量内容同等对待。3.2 我的 RAG 接入方案检索一次变换后分发我的做法是把 RAG 检索从智能体内部抽出来变成引擎级别的一个共享服务。整个任务流只检索一次或按需检索少数几次检索结果经过变换层统一处理然后按各智能体的上下文契约分发。具体流程统一检索入口任务开始时由引擎根据任务目标生成检索 query调用 RAG 服务拿到原始结果。变换层处理对原始结果做结构化提取、去重、置信度打分、冲突标记。按契约分发研究员拿到完整结构化结果分析师拿到摘要版写手只拿到高置信度的结论。这样做的直接好处是检索结果在整个系统里是一致的不会出现研究员看到 A 文档分析师看到 B 文档的割裂。而且检索只做一次token 成本和延迟都大幅下降。关于rag知识库能存储图片嘛这个热词我顺带说一句多模态 RAG 是趋势但在多智能体上下文里图片的处理要格外小心。图片的 token 消耗远高于文本而且图片描述本身就需要一次额外的模型调用。我的建议是图片在检索层转成结构化描述caption 关键属性以文本形式进入上下文原图只在必要时按引用传递不要直接把图片塞进每个智能体的上下文。3.3 检索结果与推理链的绑定让引用可追溯一个经常被忽略的细节下游智能体的输出应该能追溯到具体的检索来源。我在变换层会给每条检索结果分配一个稳定的source_id并要求下游智能体在引用时带上这个 id。这样最终输出里如果出现事实错误我可以直接定位到是哪条检索结果的问题而不是笼统地说RAG 效果不好。这个机制在调试时价值巨大。有一次最终报告里出现了一个错误的数字我通过 source_id 一路回溯发现是检索层把两个相似文档的段落拼接错了。如果没有这个绑定我可能要花半天才能找到根因。4. 推理透明化让智能体的思考过程可观测但不污染4.1 推理草稿该不该暴露给其他智能体这是多智能体设计里争议最大的问题之一。一派观点认为推理草稿比如思维链应该共享因为让下游知道上游怎么想的有助于协作。另一派认为推理草稿是噪声会污染下游。我的实践结论是推理草稿应该被记录但不应该被默认注入下游上下文。记录是为了调试和追溯不注入是为了避免污染。这两件事不矛盾。具体做法是每个智能体的推理草稿写入追溯层但采集层默认不把它作为下游的上下文来源。如果某个下游智能体确实需要理解上游的推理逻辑比如审查者需要判断分析师的推理是否合理那就通过一个显式的推理摘要变换把草稿压缩成结构化的推理要点再注入。这样既保留了信息又控制了噪声。4.2 用推理契约约束输出格式透明化的另一个关键是输出格式的约束。如果每个智能体输出自由文本下游根本没法可靠解析。我要求每个智能体的输出必须符合预定义的推理契约通常包含这几个字段{ conclusion: 最终结论, reasoning_steps: [步骤1, 步骤2], evidence_refs: [source_id_1, source_id_2], confidence: 0.85, uncertainties: [不确定的点] }这个契约的好处是conclusion给下游用reasoning_steps给追溯用evidence_refs给引用绑定用confidence给冲突消解用uncertainties给审查者用。一个结构化的输出同时服务了四个下游需求比自由文本高效得多。注意约束输出格式时不要用过于复杂的嵌套结构。我试过让智能体输出五层嵌套的 JSON结果模型经常漏字段或者格式错误。后来简化为两层稳定性大幅提升。格式约束的复杂度要和模型的指令遵循能力匹配。4.3 置信度传递让不确定性在系统里流动多智能体系统里最危险的情况是上游不确定下游却当成确定事实用。比如研究员检索到的信息本身置信度只有 0.6但传给分析师时没标注分析师当成 0.95 的事实推理写手再当成铁定结论写进报告。错误就这样被逐级放大。我的解决方案是让置信度成为上下文的一等公民。每条信息都带置信度每个智能体的输出也带置信度而且下游的置信度不能超过上游证据的置信度上限。如果分析师基于 0.6 置信度的证据得出 0.9 置信度的结论引擎会标记这个异常提示置信度跃升不合理。这个机制帮我抓出过很多隐蔽问题。有一次审查者发现分析师的置信度异常高回溯后发现是分析师忽略了证据里的不确定性标记。如果没有置信度传递这个错误会一路传到最终输出。5. 实战踩坑三个让我重构引擎的真实案例5.1 案例一上下文窗口的隐性溢出早期我的引擎没有做 token 预算的硬约束只是尽量控制。结果有一次任务跑到第七步模型突然开始输出乱码。排查后发现上下文已经累积到超出模型窗口框架自动做了截断但截断的是中间的关键证据导致模型基于残缺信息推理。修复方案是引入硬性 token 预算每个智能体的上下文契约里明确max_tokens采集层在注入前先算总 token超了就按优先级裁剪。裁剪顺序是先裁 optional 里优先级最低的再裁 required 里可摘要的最后才动核心目标。永远不允许框架自动截断截断必须由引擎显式控制。5.2 案例二RAG 检索结果的幽灵重复有一次最终报告里同一段话出现了三次措辞略有不同。排查发现检索层返回了三个来源内容高度相似同一篇文档的不同镜像变换层没有去重三个来源都被注入了上下文模型把它们当成三条独立证据分别引用了一次。修复方案是在变换层加语义去重对检索结果做 embedding相似度超过阈值的合并为一条保留置信度最高的来源。这个改动让上下文长度平均下降了 30%而且消除了重复引用的问题。5.3 案例三智能体间的指令漂移最隐蔽的一个坑。任务开始时我给的指令是生成一份客观的技术分析报告但经过研究员、分析师、写手三个智能体传递后最终输出变成了强烈推荐使用 X 方案。排查发现分析师在推理草稿里写了一句这个方案明显更好这句话被注入到写手的上下文里写手把它当成了任务指令的一部分。修复方案是严格区分任务指令和中间推理。任务指令只在采集层注入一次且标记为system级别中间推理永远不进入下游的 system 消息只能作为user或assistant消息的参考内容。这个区分看似简单但能避免大量指令漂移问题。6. 引擎落地的工程细节从原型到可用6.1 用 LangGraph 还是自己写编排关键词里出现了 langchain4j、rag框架这些词说明很多人在纠结框架选型。我的经验是原型阶段用框架生产阶段自己写编排层。框架LangGraph、AutoGen 等在快速验证时很香但它们的抽象层次和你的上下文契约往往对不齐。当你需要精细控制上下文注入、变换、追溯时框架的默认行为反而成了阻碍。我的做法是用框架做底层的 LLM 调用和工具调用但编排层、上下文采集层、变换层、追溯层全部自己实现。这样既享受了框架的便利又保留了架构的透明性。编排层其实不复杂核心就是一个状态机加一个上下文管理器几百行代码就能搞定。6.2 状态管理上下文不是全局变量一个常见的反模式是把上下文当成全局变量所有智能体共享读写。这会导致竞态、污染、难以追溯。正确做法是每个智能体有独立的上下文视图视图由采集层根据契约生成智能体只能读自己的视图写自己的输出。输出经过变换层处理后才能进入下一个智能体的视图。这种视图隔离的设计让每个智能体的输入输出都是确定的、可快照的。调试时你可以精确知道每个智能体看到了什么而不是面对一个不断变化的全局状态。6.3 性能与成本的平衡透明化是有成本的。每次调用都做快照、每次变换都做结构化处理会增加延迟和存储。我的经验是追溯层可以异步写入不阻塞主流程变换层的结构化提取可以用小模型不必用主模型快照可以采样存储比如只存最近 N 次调用的完整快照更早的只存摘要。在成本敏感的场景下我会把追溯层做成可开关的开发调试阶段全开生产环境只记录关键节点。这样既保证了调试能力又控制了运行成本。7. 关于透明架构我最后想说的几点经验搭了这么多套多智能体系统我最大的体会是透明性不是锦上添花而是系统能否从 demo 走向可用的分水岭。一个不透明的系统你永远不知道它为什么成功也不知道它为什么失败只能靠反复试错效率极低。而一个透明的系统每次失败都能定位到具体的上下文环节每次优化都有明确的方向。如果你现在正在搭多智能体系统我建议你从第一天就把追溯层建起来哪怕只是最简单的日志。因为等到系统复杂了再补追溯成本会高得多。另外不要迷信框架的自动编排上下文的语义边界必须由你亲手定义这是框架替代不了的。关于 RAG 和多智能体的结合我的核心建议是把检索抽出来做成共享服务检索一次变换后按契约分发。不要让每个智能体各自检索那是上下文爆炸和结果不一致的根源。最后分享一个小技巧我在引擎里加了一个上下文审计功能每次任务结束后自动生成一份报告列出每个智能体的上下文来源、token 消耗、置信度变化、冲突点。这份报告在复盘时特别有用能帮你快速发现系统性的上下文设计问题而不是每次都从头排查。这个功能实现起来不难但价值极高强烈建议你试试。