在多 Agent 系统里，上下文怎么传，决定了系统的稳定性上限、成本下限、以及排障时的血压。
最开始，很多团队把它当成「把聊天记录拼一拼」的问题。上线后就会这样的问题：
-
同样的输入，输出飘得离谱。这里的问题是上下文污染和信息密度不稳定。 -
Token 成本控不住。明明一个任务只需要 10 句关键信息，每次都喂 200 句。 -
自动化评测很难做。回归集跑出来波动大到没法设阈值，最后只能靠人工验收。
从工程的角度简单定义一下「上下文传递」：在一条多步协作链路里，把下游完成任务所需的信息，以可控成本、可追踪方式送到它面前。这里面有两个关键词：可控、可追踪。
下面聊下我理解的 4 种主流策略拆解：原理、适用场景、落地细节、坑、性能和效果的取舍。
先定义一下上下文
很多争论的根源是大家说的「上下文」不是一个东西。可以在团队里先把上下文分层，后面所有策略都能对齐。这里我们把「上下文」拆成 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。
机制
上游做三件事：
-
从历史里抽取和当前任务强相关的信息 -
把冲突的约束做决策或提出澄清问题 -
输出一个高密度、可控的自然语言指令
「上下文胶囊（context capsule）」
把给下游 Agent 的输入，固定成一个胶囊，结构大概是：
-
必须给：任务卡（Planner 压缩/改写后的自然语言描述） -
可选给（按需）： -
最近 N 轮「与任务强相关」的对话原句（最多 3–8 句） -
一段「用户偏好/风格记忆」摘要（1–3 句）
-
-
坚决不直接给：全量聊天记录（除非做的就是风格延续式创作，而且做了脱敏）
它解决的是「你能不能控制它理解什么」。
示例：
任务卡：生成一张用于电商 banner 的图。主体是一只穿宇航服的柯基站在月球上，远处能看到地球。风格写实摄影，冷色调，高对比，电影感侧逆光。横向 16:9。不要任何文字、logo、血腥或恐怖元素。用户偏好极简、冷色、不要文字。若信息缺失请提 1–3 个澄清问题，否则直接输出可用于生图的 prompt 与 negative prompt。
这段话有几个关键点：
-
主体、场景、风格、画幅、禁忌、用户偏好都在 -
有「缺失信息时的行为规则」 -
不需要表单，依然可评测、可回归
工具描述要写成「契约」
工具描述很重要。
我更喜欢把工具说明写成「契约」，至少包含：
-
工具支持的参数（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 往往是解药。
选择策略时，如何判断
可以用四个可执行的问题来选方案：
-
谁需要看到全量上下文？谁只需要胶囊？
如果答案是「大多数都只需要胶囊」，策略 3 和 4 优先级会上来。 -
要不要并发？要不要异步？
需要并发、异步，策略 5 的价值会非常直接。 -
失败主要来自哪里：信息缺失，还是噪声过多？
信息缺失优先补证据引用；噪声过多优先做裁剪和胶囊预算。 -
是否真的在做回归评测？
没有回归，就别指望系统会「越调越稳」。上下文传递策略的好坏，最终都要落在可复现输入上。
小结
不做结构化，并不等于不做「约束与契约」。
我见过的高质量落地项目，往往走的是「看起来很自然，实际上约束很硬」的路线。用户体验上像聊天，工程实现上像协议。
如果准备做多 Agent 的上下文传递，至少把三件事落下来：
-
「上下文胶囊」：任务卡 + 少量强相关原句 + 记忆摘要 -
「工具契约」：写清楚工具能力边界和必填信息 -
「受控输出格式」：固定栏位，解析稳定，评测可做
这三件事做完，再谈共享状态、Supervisor、消息传递，才有意义。
以上。