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 阶段是便利，在生产阶段是灾难，因为上下文的每一次拼接、截断、传递，都是一次信息的有损变换，而你对这些变换一无所知。

我后来总结，一个透明的上下文架构引擎必须显式管理四层结构，缺一层都会导致调试时抓瞎：

这四层不是框架给你的，是你必须自己设计的。框架可以帮你做执行，但上下文的语义边界必须由你定义。

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 检索从智能体内部抽出来，变成引擎级别的一个共享服务。整个任务流只检索一次（或按需检索少数几次），检索结果经过变换层统一处理，然后按各智能体的上下文契约分发。

具体流程：

1. 统一检索入口：任务开始时，由引擎根据任务目标生成检索 query，调用 RAG 服务，拿到原始结果。
2. 变换层处理：对原始结果做结构化提取、去重、置信度打分、冲突标记。
3. 按契约分发：研究员拿到完整结构化结果，分析师拿到摘要版，写手只拿到高置信度的结论。

这样做的直接好处是：检索结果在整个系统里是一致的，不会出现"研究员看到 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 消耗、置信度变化、冲突点。这份报告在复盘时特别有用，能帮你快速发现系统性的上下文设计问题，而不是每次都从头排查。这个功能实现起来不难，但价值极高，强烈建议你试试。