多 Agent 架构上下文传递的 4 种策略

在多 Agent 系统里，上下文怎么传，决定了系统的稳定性上限、成本下限、以及排障时的血压。

最开始，很多团队把它当成「把聊天记录拼一拼」的问题。上线后就会这样的问题：

• 同样的输入，输出飘得离谱。这里的问题是上下文污染和信息密度不稳定。
• Token 成本控不住。明明一个任务只需要 10 句关键信息，每次都喂 200 句。
• 自动化评测很难做。回归集跑出来波动大到没法设阈值，最后只能靠人工验收。

从工程的角度简单定义一下「上下文传递」：在一条多步协作链路里，把下游完成任务所需的信息，以可控成本、可追踪方式送到它面前。这里面有两个关键词：可控、可追踪。

下面聊下我理解的 4 种主流策略拆解：原理、适用场景、落地细节、坑、性能和效果的取舍。

先定义一下上下文

很多争论的根源是大家说的「上下文」不是一个东西。可以在团队里先把上下文分层，后面所有策略都能对齐。这里我们把「上下文」拆成 4 类：

1. 任务上下文：当前这一步要干什么，验收标准是什么。
2. 状态上下文：链路运行到哪了，已经产生了哪些中间产物。
3. 记忆上下文：用户偏好、历史约束、长期设定，和当前任务不完全同一层级。
4. 证据上下文：引用了哪些原始材料（文档片段、对话原句、文件、数据库记录），用于追溯和评测。

策略 1：共享状态或黑板模式

这套是 LangGraph、CrewAI 这类框架最常见的默认选项。工程上它像一个「全局状态对象」，也像一个「写满便签的白板」。

机制

• 所有 Agent 对同一个 State 读写。
• Agent A 产出结果写入 State 的某个字段。
• Agent B 读取字段，继续处理，再写回。

如果我们不想把大对象放内存，也可以用文件系统或对象存储做「外置状态」，State 里只放路径和元信息。像 Manus 文章中说的「将文件系统作为存储，直接共享文件系统的路径，渐进式披露」，就是这么个逻辑：把大内容放外面，把指针放 State 里。

什么时候用

• 复杂图流转：有回路、有分支、有重试、有人工介入的链路。
• 任务跨度长：要做断点续跑、要保留每一步证据，方便回放和审计。
• 需要可视化排障：一个状态树摆在那，定位问题快很多。

这类场景里，黑板是省心的。我们不用操心「A 怎么把消息发给 B」，大家都围着同一块板子写字。

落地时的坑

坑 1：状态对象会长成「垃圾堆」

共享状态天然会诱导人偷懒：什么都往里塞。结果一周后 State 变成一个混杂体：

• 当前任务指令
• 全量聊天记录
• RAG 检索结果
• 中间产物全文
• 模型输出草稿

后果是下游 Agent 读到的信息密度越来越低，注意力越来越散。我们会直观感受到「同一个 Agent，越跑越不稳定」。

共享状态可以用，前提是要给 State 立规矩。规矩不是写在 Confluence 上那种，是写进代码和评测里那种。

常用的做法是给 State 分区，至少三块：

• 「control」：流程控制字段（步数、路由、重试次数）
• 「artifacts」：产物指针（文件路径、对象存储 key、哈希）
• 「capsules」：给 LLM 的上下文胶囊（后面会讲）

State 里尽量少放大段文本，放「引用」和「摘要」。

坑 2：并发写

多 Agent 并行时很容易出现：

• 两个 Agent 同时更新同一字段，后写覆盖前写。
• 一个 Agent 基于旧 State 做决策，写回时把别人新写入的字段抹掉。

解决思路按分布式系统处理：

• 字段级别乐观锁（版本号 / compare-and-swap）
• append-only 日志字段，避免覆盖（把「更新」变成「追加事件」），Gemini Cli 就是这个逻辑
• 把「写入」限定为少数字段，其他字段只读

坑 3：评测没法做「输入对齐」

共享状态经常带来一个隐性问题：每次运行 State 的非关键字段变化很大，导致没法保证下游 Agent 的输入一致。回归测试时同一条用例，今天多了两段日志，明天多了一个草稿，指标就会飘。

建议：评测时固定「胶囊输入」，State 可以变，但进入 LLM 的那段上下文要可快照、可对比、可复现。

成本 vs 效果的取舍

• 效果：流程可扩展，复杂图最好用。
• 成本：需要治理 State 的 schema、并发、版本、清理策略。
• 性能：状态越大，序列化 / 反序列化越痛；如果每一步都把 State 发给 LLM，更是直接烧钱。

共享状态是一把大锤。能砸钉子，也能把玻璃砸碎。关键看有没有「状态卫生」这件事。

策略 2：消息传递与直接调用

这套有点像微服务架构：上游把消息打包发给下游，下游处理完再回一个结果。

机制

• Agent A 产出一个「消息」发给 Agent B。
• 消息可以走 HTTP、RPC、队列，也可以是框架内的函数调用。
• 每条消息都应该有明确的结构和版本。

什么时候用

• 流水线式任务：每一步都很明确，上游输出就是下游输入。
• 要强可观测性：链路追踪、审计、回放都好做。
• 团队边界清晰：不同组负责不同 Agent，接口契约能拉齐。

这类场景用消息传递灵活性更强一些，但是如果规模不大，直接单体应用来搞，函数间调用吧。

落地时的坑

坑 1：消息里塞进「全量上下文」

很多团队为了省事，会把上游拿到的所有东西都塞进消息里。看起来省了裁剪逻辑，实际上把问题推给了下游：下游 LLM 要在一堆噪声里找信号。

如果走消息传递，消息必须有「字段语义」。比如：

• 「task」字段是当前要做的事
• 「constraints」字段是硬性限制
• 「evidence」字段是引用（原文片段或路径）
• 「history」字段如果存在，必须明确是「最近 N 轮且强相关」

这里的关键词是「必须明确」。否则会出现消息看着结构化，内容依然是散装的。

坑 2：接口版本失控

多 Agent 系统迭代快，接口字段会频繁变动。如果经历过一次「某个 Agent 升级后，下游全挂」就会理解版本的重要性。

建议至少做到：

• 每条消息带「schema_version」
• 下游支持 1~2 个旧版本的兼容解析
• 重要字段改动要有灰度期，别全量切

Agent 世界里「prompt 和策略」变化太快，不做版本控制就是堵薄。

坑 3：把「LLM 输出」当成接口返回

LLM 输出天然存在幻觉。如果我们直接把自由文本当成 RPC 返回，然后让下游再去解析，事故率会非常高。

有一个简单的方法：固定栏位的轻量输出格式，别一上来就上复杂 schema，也别放任自由发挥。它在工程上有一个很大的价值：解析稳定，回归测试有抓手。

类似于这样：

PROMPT:
...

NEGATIVE:
...

PARAMS:
- aspect: 16:9
- notes: ...

成本 vs 效果的取舍

• 效果：可追踪性强，调试体验好。
• 成本：要做接口契约、版本管理、兼容逻辑。
• 性能：网络开销和序列化开销可控；真正的成本往往来自传了多少无用字段。

如果业务链路更像「微服务编排」，消息传递会比共享状态更干净。

策略 3：上下文压缩与自然语言传递

核心思路：下游 Agent 不该负责考古。

把「长历史」变成「短胶囊」，把「噪声」变成「任务卡」，再交给执行 Agent。

机制

上游做三件事：

1. 从历史里抽取和当前任务强相关的信息
2. 把冲突的约束做决策或提出澄清问题
3. 输出一个高密度、可控的自然语言指令

「上下文胶囊（context capsule）」

把给下游 Agent 的输入，固定成一个胶囊，结构大概是：

• 必须给：任务卡（Planner 压缩/改写后的自然语言描述）

• 可选给（按需）：

• 最近 N 轮「与任务强相关」的对话原句（最多 3–8 句）

• 一段「用户偏好/风格记忆」摘要（1–3 句）

• 坚决不直接给：全量聊天记录（除非做的就是风格延续式创作，而且做了脱敏）

它解决的是「你能不能控制它理解什么」。

示例：

这段话有几个关键点：

• 主体、场景、风格、画幅、禁忌、用户偏好都在
• 有「缺失信息时的行为规则」
• 不需要表单，依然可评测、可回归

工具描述要写成「契约」

工具描述很重要。

我更喜欢把工具说明写成「契约」，至少包含：

• 工具支持的参数（prompt / negative / size / seed / style 等）
• 哪些信息必须出现（画幅、用途、限制）
• 输出必须遵守的格式（哪怕只有 PROMPT/NEGATIVE/PARAMS）

可能翻车的地方

以一个增强提示词的 Agent 为例

翻车 1：指代延续没被写进任务卡

用户说「按刚才那张风格」「把她换成红裙子」，Planner 如果没有把「刚才那张」总结成可引用的描述，下游增强 Agent 根本无从得知。

补救方式使用「证据上下文」：把关键原句作为 1~3 条引用附在胶囊里。

翻车 2：约束冲突没被处理

用户一会儿要极简纯色，一会儿又要复杂赛博城市场景。Agent 去解决冲突会很糟糕，因为它的职责是「增强表达」，不是「做产品决策」。

冲突要在 Planner 层解决：要么做裁决（按最新指令为准、按用户偏好为准），要么问澄清问题。别把锅甩给执行 Agent。

翻车 3：压缩带来的信息损失

上下文压缩是有损的。 压缩做得越狠，成本越低，翻车概率越高；压缩做得越松，成本越高，稳定性也未必更好，因为噪声会上来。

建议做一个「胶囊长度预算」，按任务类型分档：

• 低风险任务（格式化、简单问答）：胶囊可以短到 200~400 tokens
• 中风险任务（生成、改写、推理）：600~1200 tokens
• 高风险任务（工具调用、多约束、多回合创作）：1200~2000 tokens，再往上就该考虑别的策略了

这样，可以让成本和稳定性可控一些。

成本 vs 效果的取舍

• 效果：稳定性提升非常明显，Token 成本能压下来，评测也更容易做。
• 成本：要多一个 Planner/Summarizer 步骤，链路延迟会上升；压缩质量要靠回归集打磨。
• 工程判断：这套是「多 Agent 真正开始像工程系统」的起点。

策略 4：路由分发与层级管理

如果说策略 3 解决的是「给下游喂什么」，策略 4 解决的是「谁有资格看到什么」。

我喜欢用「最小信息原则」去设计多 Agent：每个 Agent 只拿自己需要的那一部分上下文，别让它看到不该看的东西。

机制

• 一个 Supervisor（主管）拿到全量上下文。
• Supervisor 拆任务、选 Agent、裁剪上下文。
• 子 Agent 只看到被裁剪后的输入，产出结果回传 Supervisor。
• Supervisor 汇总，决定下一步。

把「路由」和「信息裁剪」集中起来做，能显著减少上下游互相污染。

这本质就是一个主从的逻辑。

什么时候用

• 权限和合规敏感：有 PII、有商业机密、有分级数据。
• 子 Agent 职责清晰：比如「检索」「评审」「生成」「合规检查」。
• 系统要长期维护：人员流动、策略变动、模型替换都很频繁。

层级路由把复杂性收敛到 Supervisor 这一点上。依赖它，也更容易把它做好。

落地时的坑

坑 1：Supervisor 变成性能瓶颈

所有东西都过 Supervisor，它会成为热点：吞吐、延迟、可用性全压在它身上。

解决办法通常有三种：

• Supervisor 只做「路由与裁剪」，不要在它身上做重推理
• 对路由做缓存（同一类任务走同一条路径）
• Supervisor 逻辑尽量确定性，LLM 参与度降低

我见过很多团队把「大脑」写成一个超级 prompt，然后让它既拆任务又生成内容又做审查。这样迟早会蹦。

坑 2：裁剪策略一开始过度依赖「拍脑袋」

裁剪不是凭感觉。裁剪是一套数据工程问题：哪些字段必须给，哪些字段给了会干扰。

用「失败用例驱动」去迭代裁剪：每次线上翻车，都回放当时给子 Agent 的胶囊，问一个很残酷的问题：

• 该给的没给，是哪一类信息缺失？
• 不该给的给了，是哪一类噪声触发了跑偏？

把这两类问题沉淀成裁剪规则，会越做越稳。

坑 3：子 Agent 之间产生「隐性耦合」

很多系统表面上是层级的，实际上子 Agent 会通过共享外部资源互相影响，比如：

• 共用同一个向量库检索空间，检索结果被不同策略污染
• 共用同一个临时文件目录，路径命名冲突
• 共用同一个「用户偏好记忆」，写入时缺少版本控制

如果走 Supervisor 模式，「写入边界」会比较重要：哪些 Agent 允许写记忆，哪些只能读；写入要不要审批；写入是否带证据引用。

成本 vs 效果的取舍

• 效果：稳定性和安全性非常强，复杂系统更容易控住。
• 成本：Supervisor 设计难度高，容易成为瓶颈；需要更完善的可观测性和回放能力。
• 工程判断：当开始被「数据泄露」「上下文污染」「责任边界不清」折磨时，Supervisor 往往是解药。

选择策略时，如何判断

可以用四个可执行的问题来选方案：

1. 谁需要看到全量上下文？谁只需要胶囊？ 如果答案是「大多数都只需要胶囊」，策略 3 和 4 优先级会上来。
2. 要不要并发？要不要异步？ 需要并发、异步，策略 5 的价值会非常直接。
3. 失败主要来自哪里：信息缺失，还是噪声过多？ 信息缺失优先补证据引用；噪声过多优先做裁剪和胶囊预算。
4. 是否真的在做回归评测？ 没有回归，就别指望系统会「越调越稳」。上下文传递策略的好坏，最终都要落在可复现输入上。

小结

不做结构化，并不等于不做「约束与契约」。

我见过的高质量落地项目，往往走的是「看起来很自然，实际上约束很硬」的路线。用户体验上像聊天，工程实现上像协议。

如果准备做多 Agent 的上下文传递，至少把三件事落下来：

• 「上下文胶囊」：任务卡 + 少量强相关原句 + 记忆摘要
• 「工具契约」：写清楚工具能力边界和必填信息
• 「受控输出格式」：固定栏位，解析稳定，评测可做

这三件事做完，再谈共享状态、Supervisor、消息传递，才有意义。

以上。