LangGraph多智能体状态传递：结构化交接设计实践

转录回放与状态摘要的两难困境

在构建基于 LangGraph 的多智能体系统时，一个核心而棘手的问题浮出水面：当一个 Agent 将控制权交给下一个 Agent 时，究竟应该传递什么状态？

最直接的做法是传递完整的对话转录（full transcript）。这种方式确实保留了所有细节，但代价高昂——下游 Agent 不得不重新"发现"哪些决策已经最终确定、哪些工具调用结果是权威的、以及哪些问题仍然悬而未决。这不仅浪费 token 和推理算力，还引入了误读风险。

另一个极端是传递一份简短的摘要。摘要成本低，但同样危险：它可能抹除关键证据，更糟糕的是，它会把"推断"（inference）悄然变成"事实"（fact）。当摘要写着"用户偏好方案 A"时，下游 Agent 无法判断这究竟是明确的决策还是模型的猜测。

这正是多智能体架构设计中的核心痛点：如何设计一种结构化的交接机制（handoff structure），既避免全量回放的冗余，又不丢失关键的可信度信息。

结构化交接：从对话流到字段化状态

解决上述问题的成熟思路是——放弃扁平的文本传递，转而使用字段化的交接对象。具体来说，可以将 Agent 间传递的状态拆分为以下独立字段：

• 目标（objective）：当前任务要达成什么
• 已接受的决策（accepted decisions）：哪些结论已经定案，不容再议
• 约束条件（constraints）：任务边界与限制
• 权威输入（authoritative inputs）：可信的数据来源
• 产物路径与修订 ID（artifact paths and revision IDs）：文件位置及其版本标识
• 工具调用凭证（tool-call receipts）：工具执行的记录与结果
• 未解决的问题（unresolved questions）：仍需处理的不确定项
• 下一步允许的动作（next allowed action）：明确授权的后续操作

这种设计的精妙之处在于，它在数据结构层面就把"事实"和"推断"、"已定"和"待定"区分开来。下游 Agent 不必重新推理这些分类，而是直接读取语义明确的字段。

溯源机制：为每个字段建立"户口本"

更进一步，建议为每个字段附加元数据：是谁（或什么）产生了这个字段，它属于哪个检查点（checkpoint）。

这本质上是给状态引入了"溯源"（provenance）能力。当一个决策标注为"由验证 Agent 在 checkpoint-7 确认"时，它的可信度远高于"由规划 Agent 初步提出"。这种溯源信息让多智能体系统具备了可审计性——当结果出错时，可以精确回溯到是哪个环节引入了错误假设。

分层存储：图状态与持久化外部记录的划分

在 LangGraph 多智能体架构中，另一个关键的设计决策是：哪些状态应该放在图状态（graph state）里，哪些应该作为持久化的外部记录（durable external records）？

一个经过实践验证的划分原则如下：

适合放入图状态的内容

轻量、易变、与当前执行流强相关的信息，比如目标、未解决问题、下一步动作、以及对外部记录的"引用"（如 artifact 路径和修订 ID）。图状态需要在节点间频繁流转，保持精简至关重要。

适合放入外部持久化存储的内容

体积大、需要长期保存、或需要跨会话复用的数据，比如实际的产物文件、完整的工具调用日志、大型数据集。图状态只需持有指向它们的指针（路径 + 版本 ID），而非内容本身。

这种"引用而非内嵌"的模式，既控制了图状态的膨胀，又保证了数据的完整性和可追溯性。它类似于软件工程中"传值 vs 传引用"的经典权衡，只不过在 Agent 系统中，引用还必须携带版本信息以应对状态变化。

陈旧交接的陷阱：版本一致性问题

多智能体状态传递中一个容易被忽视但极具破坏力的问题是：如何防止陈旧的交接（stale handoff）在底层文件已经改变之后被恢复执行？

这是分布式系统中经典一致性问题在 Agent 领域的重现。设想这样的场景：Agent A 在 checkpoint-5 生成了交接对象，引用了 report.md 的 revision-3；但在 Agent B 恢复执行之前，report.md 已被更新到 revision-5。如果 B 盲目地基于旧的假设继续工作，产出就建立在过时的前提之上。

修订 ID 作为乐观锁

交接对象中记录的 revision ID 不应只是元数据，而应作为执行前的校验条件。当下游 Agent 恢复时，先对比引用的 revision ID 与当前实际的 revision ID。如果不匹配，则触发重新评估流程——要么中止执行，要么重新读取最新状态并判断此前的决策是否仍然成立。

这本质上是数据库领域"乐观锁"（optimistic locking）机制在 Agent 交接场景中的应用，避免了在"文件已变"的情况下静默使用陈旧数据。

内容哈希作为兜底校验

除了显式的 revision ID，还可以引入内容哈希（content hash）作为补充校验手段。将关键 artifact 的哈希值嵌入交接对象，恢复时重新计算并比对。这种方式对那些没有显式版本管理的资源尤其实用。

面向生产可靠性的Agent状态设计原则

综合以上分析，可以提炼出几条通用的多智能体状态设计原则：

语义显性化优于隐式推断。 与其让下游 Agent 从文本中猜测哪些是决策、哪些是事实，不如在数据结构中直接标明。这减少了误读，也降低了推理成本。

可信度与溯源不可或缺。 在多智能体协作中，信息的"出处"和"确定程度"与信息本身同样重要。缺乏溯源的状态传递会导致错误不可控地累积。

分层存储 + 引用机制控制复杂度。 图状态保持精简，重资产外置存储，通过带版本的引用将二者连接起来。

一致性必须显式保障。 Agent 系统本质上是异步、可暂停、可恢复的，这意味着陈旧读取等分布式一致性问题会真实存在。版本校验、乐观锁、内容哈希是应对这些问题的有效工具。

随着 LangGraph 等框架推动多智能体架构走向生产环境，Agent 之间的"通信协议"设计正在从工程细节上升为决定系统可靠性的关键因素。字段化、溯源化、版本化的交接结构，是让 Agent 协作从"演示可用"迈向"生产可靠"的必经之路。