消息、状态与共享记忆

• 消息结构（id、时间戳、traceId、源/目的、版本、载荷）
• 消息持久化与事件日志
• 回放与审计能力

可追溯与回放要求每条消息都有完整元数据：全局唯一消息 id、时间戳、traceId/spanId（关联调用链）、发送方与接收方、协议版本、消息类型与载荷、以及可选的因果序号。所有消息写入持久化事件日志（append-only），作为审计与回放的单一事实源。回放机制：按 traceId 重建一次协作的完整消息序列，或按状态快照 + 后续消息重放某个节点。载荷要结构化（schema 可校验），并支持幂等（同一消息重放不产生副作用）。配合版本号，能区分新旧协议消息。

可追溯 = 元数据 + 持久化；可回放 = 确定性 + 幂等。只有消息可重放，才能支撑故障恢复、审计、评测与调优。因此消息协议要从"方便传递"升级为"可审计的事件记录"。

• Blackboard 的机制（集中共享、可分片区、读写）
• 独立上下文的机制（各自私有、消息传递）
• 取舍因素（耦合、一致性、可观测、token 成本）

共享黑板是一块集中可写的共享存储，各 Agent 读写公共区域，可按主题分片区（如"检索结果区""推理区"），适合需要共享中间结果、协作紧密的场景，利于全局可观测与一致，但可能引入读写竞争与信息越权风险。独立上下文是各 Agent 私有上下文，通过显式消息交换所需信息，耦合低、隔离好、token 高效，但重复信息需显式传递，跨 Agent 共享需要额外机制。取舍：协作紧密、信息交互频繁、需要全局一致快照→黑板；Agent 职责清晰、信息需要隔离、追求低耦合与 token 效率→独立上下文+消息。也可混合：黑板存公共事实，独立上下文存私有推理。

黑板把"共享"集中化，代价是竞争与越权；独立上下文把"共享"显式化，代价是传递开销。决策依据是"信息共享的频度与一致性要求"对"隔离与成本"的权衡。

• 并发控制的锁与版本号（乐观锁、悲观锁）
• 写入合并策略（字段级合并、冲突仲裁）
• 脏读与隔离（读已提交、版本隔离）

避免冲突与脏读的核心是并发控制与版本管理。写路径用乐观锁（版本号 + CAS 条件更新）或悲观锁（行/键锁）防止覆盖；冲突通过合并策略解决：字段级合并（不同 Agent 写不同字段）、最后写胜出、或冲突仲裁（评置信度、或进入人工/仲裁队列）。读路径用"读已提交/版本隔离"避免读到半写状态，或用快照隔离读一致版本。长期记忆通常是向量库/文档库，可对文档级加版本号，更新时校验版本失败则重读合并。脏数据可加"写前校验 + 写后校验"闸门，并记录写入来源便于溯源。

长期记忆是共享可变资源，必须有并发控制。乐观锁适合冲突率低的场景，悲观锁适合写密集冲突高。要区分"合并"与"覆盖"：多数场景应合并而非粗暴覆盖，从而保留各 Agent 的增量信息。

• Schema 版本化管理（版本号、兼容性约定）
• 向后兼容的字段扩展（可选字段、默认值、前向兼容）
• 下游容错（未知字段忽略、缺字段默认、错误隔离）

消息 Schema 用显式版本号管理，兼容性约定：向后兼容（新版本可读旧版本消息）与前向兼容（旧版本可读新版本消息）。字段扩展遵循"只增不改删"：新增字段为可选，带默认值，语义明确；不改变既有字段含义与类型。序列化用 tolerant 解析：下游对未知字段忽略、对缺失必填字段用默认值或报错并走降级、对版本不匹配做适配器转换。可采用 Protobuf/JSON Schema 等自带版本兼容的格式，并使用 schema 注册表校验。变更走灰度：同时支持新旧版本一段时间，迁移后再下线旧版。

多 Agent 往往是异步、独立部署的，Schema 演进必须兼容。核心原则是"加字段不改字段、未知字段忽略、缺字段有默认"。这样新旧 Agent 可并存，避免升级触发全量联调。

• 因果序传递（因果序号、Lamport 时钟、vector clock）
• 乱序缓冲重排（序列号、按序执行、缺序等待）
• 乱序错误执行的避免（依赖校验、缓冲区）

因果依赖通过序号/时钟传递：每个消息带逻辑序号（Lamport 时钟或 vector clock）或显式的因果依赖字段（depends-on），下游据此判断顺序。乱序到达时，接收方用"序号缓冲 + 按序交付"：把消息写入按序号排序的缓冲队列，只有某条消息的前序消息（或所需依赖）已就绪才提交执行，否则等待；配超时与乱序检测（检测到缺口则等待或请求补发）。强因果场景用 vector clock 精确判断并发与依赖；弱因果可用 Lamport 时钟近似。工程上按"依赖就绪才执行"的约束，避免因乱序执行导致的错误状态。

乱序是分布式异步通信的必然。错误执行源于"未满足依赖就执行"。缓冲重排的本质是"把乱序恢复为因果序再执行"，用依赖就绪校验替代盲目执行，牺牲一点延迟换取正确性。

• 强一致 vs 最终一致的定义与代价
• 一致性模型选择依据（业务要求、并发、延时）
• read-your-writes 机制（会话粘性、版本、写后读同步）

强一致（linearizable）保证读总能看到最新的已提交写，代价是延迟高、可用性受限（需要多数派/锁），适合资金、库存、单一事实等必须精确的场景。最终一致允许短暂不一致，最终收敛，代价低、吞吐高，适合可容忍短暂风险的场景（如聚合统计、缓存）。选择依据：业务对"读到旧值"的容忍度、并发写冲突概率、延迟要求。read-your-writes 保证"自己写的一定读得到"：用会话粘性（写后读路由到同一节点）、写版本回传（客户端记住写入版本，读时校验）、或写后同步读（写入后强制刷新到读路径）。这在多 Agent 协作中很关键，避免"自己刚写的结果马上读不到"。

一致性是"正确性 × 性能"的权衡，没有银弹。read-your-writes 是比强一致更轻量的保证，常配合最终一致使用，满足"我的操作立即可见"而其他 Agent 可短暂延迟。工程上按数据与操作分级选择模型。

• 事件溯源的概念（以事件为唯一事实源）
• 事件建模（Agent 动作、状态变更、决策）
• 状态重建与调试回放

事件溯源把"状态"看作"事件序列的投影"：不直接保存可变状态，而是把所有 Agent 的动作、状态变更与决策作为不可变事件追加进事件日志。多 Agent 协作中，每个关键动作（委派、工具调用、结果返回、决策、审批）都记录为事件，含 traceId、时间戳、Agent、动作与载荷。调试时：按事件流重建任一时间点的状态（投影），重放事件序列复现行为，定位是哪个事件导致的问题；配合快照（snapshot）加速长流的重建。事件库作为审计与回放的单一事实源。

事件溯源的价值在于"可完全重放、可审计、不丢失历史"。相比只存最终状态，它保留了变更的完整过程，尤其适合多 Agent 这种多步骤、需追责的协作。代价是事件模型复杂、存储增长，需快照与压缩。

• 原始上下文 vs 摘要的取舍
• 质量影响（信息丢失、细节保留）
• 成本影响（token、延迟）

原始上下文保留全部细节，质量最高，但 token 成本高、延迟大，且可能携带无关信息稀释重点。压缩摘要 token 成本低、响应快，但会丢失细节，可能遗漏关键信息或引入摘要偏差，导致下游质量下降。工程做法是"分层传递"：按需传递——关键字段（结构化结果、引用、决策）传原文，背景信息传摘要；分级压缩——先摘要再按下游需要还原/补充；对高质量主线传原文，对支撑性上下文传摘要。可用缓存与引用传递避免重复传输。

这是"质量 × 成本"的权衡。核心不是"全传或全摘要"，而是"按信息重要性分层传递"：不可丢失的细节必须原文，可省略的可压缩。关键字段结构化、可校验，摘要只用于背景。

• 消息队列（异步、解耦、持久化、可靠投递）vs RPC（同步、直接、低延迟）
• 延迟与可靠性的权衡
• 适用场景与组合

RPC（gRPC/HTTP）同步直接、延迟低、编程简单，适合对延迟敏感、需要即时响应的调用（如 Agent 调用工具、请求子 Agent 结果），但紧耦合、弱过失容（超时/重试需自己处理）。消息队列（Kafka/RabbitMQ）异步解耦、消息持久化、可靠投递（at-least-once）、支持削峰与背压，适合对可靠性要求高、允许异步、需解耦的场景，但延迟更高、顺序需管理。权衡：延迟敏感且链路短→RPC；可靠性优先、可异步、需解耦→MQ。工程上常混合：关键短路径用 RPC，长任务、事件驱动、跨系统用 MQ，并用重试与幂等兜底。

RPC 用"即时性"换"耦合"，MQ 用"解耦"换"延迟"。可靠性上 MQ 更强（持久化+重投），RPC 需自建超时/重试/幂等。选择依据是"延迟敏感度"与"可靠性要求"的优先级。

• 锁机制（乐观/悲观、粒度）
• 版本号与条件更新
• 写入合并策略（字段级、追加、冲突仲裁）

向量库/文档库的并发控制：写操作用乐观锁（读取版本号，更新时带版本条件校验，冲突则重读重试）或悲观锁（按文档/键加锁，串行化写）。粒度过细增加锁开销，过粗降低并发。写入合并策略：字段级合并（不同 Agent 写不同字段互不覆盖）、追加式合并（新增向量/片段）、冲突仲裁（同字段冲突时按置信度、时间戳或规则裁决）。读写并发时，读要隔离（读已提交/快照），避免读到半写状态。向量检索与文档更新可分离：先写文档库，再异步更新向量索引，保证索引与源一致。

共享记忆并发控制的核心是"保证写不丢、读不脏"。乐观锁冲突率低时性价比高；合并策略决定冲突时可保留多少信息。文档与向量索引分离更新，避免索引与源不一致。

• 三层记忆的划分与用途
• 记忆的汇总（短期→长期沉淀）
• 记忆的淘汰与过期（保留期、容量、遗忘策略）

工作记忆是当前会话内、上下文窗口中的临时信息，随会话结束而清空，用于当前推理。短期记忆是跨会话但不要求长期保存的信息，如最近几轮对话或临时任务状态，有容量与保留期限制。长期记忆是跨会话持久的知识、偏好、事实，存入向量库/知识库，支持检索。生命周期：会话结束把有价值的信息从工作记忆汇总为短期记忆，再经提炼（去重、结构化、摘要）沉淀为长期记忆；淘汰采用保留期（TTL）、容量上限、相关性与重要性评分，配合遗忘策略（低频、过期、被更正的信息优先淘汰）。旧记忆可用"更新而非追加"避免重复与冲突。

记忆分层解决"上下文窗口有限"与"信息需持久"的矛盾。关键是"沉淀"与"淘汰"两条流水线：有价值的信息逐级沉淀，冗余/过期信息按策略淘汰。工程设计要区分"事实"与"临时"，避免把临时信息误存为长期事实。

• 结构化消息类型（任务、状态、结果、错误）
• 协议版本管理
• 字段演进兼容规则

消息按类型定义实体：Task（任务描述、输入、验收标准、约束）、Status（进度、阶段、状态码）、Result（输出、置信度、元数据）、Error（错误码、消息、可重试标记）。每个消息带协议版本号与 schema 标识。字段演进遵循"只增不改删"：新增字段可选、带默认值；不改变既有字段语义；采用 tolerant 解析（忽略未知字段、缺字段用默认或报错降级）。用 schema 注册表登记版本，兼容性校验（新旧版本可互通）。变更灰度迁移，避免全量切割。

结构化消息让 Agent 间可确定性交互与校验，版本让演进可控。核心是"类型化 + 版本化 + 向后兼容"。字段演进规则决定旧 Agent 能否处理新消息，是异步系统平滑升级的基础。

• 三种投递语义的定义与代价
• 去重机制（幂等、消息 id 去重）
• 乱序处理（序号、缓冲、按序）

at-most-once：发一次不重试，可能丢消息，代价最低，适合可容忍丢失的场景。at-least-once：至少一次，MQ 默认，重试保证不丢，但可能重复，需接收方幂等（去重）处理。exactly-once：恰好一次代价最高（需分布式事务/两阶段提交或幂等+去重+顺序保证），通常用"at-least-once + 幂等"近似实现。去重：接收方用消息唯一 id 去重表（幂等键）判断是否已处理。乱序：消息带序号，接收方缓冲并按序/依赖就绪后执行，配超时补发。实际工程多数用 at-least-once + 幂等，满足"不丢、不重做"。

"exactly-once"在分布式中几乎不可严格实现，普遍用"at-least-once + 幂等"模拟。代价排序：at-most-once < at-least-once < exactly-once。选择语义取决于"丢 vs 重"哪个代价更大，配合去重与乱序处理。

• 优先级队列（高优插队、优先级调度）
• 死信队列（DLQ）与失败判定
• 自动重投与人工介入

高优任务用优先级队列：消息带优先级，调度时优先取高优，支持插队（可在支持优先级的分区/队列中），但要防止高优饿死低优（用加权轮询或时间片）。失败消息进死信队列（DLQ）：消息重试超过上限或不可重试时路由到 DLQ，携带失败原因与重试次数。DLQ 处理：自动重投（按规则、退避）或人工/运营介入（查看、修复、手动重投）。要区分"可重试错误"（超时、限流，自动重试）与"不可重试错误"（参数错误、版本不兼容，直接进 DLQ）。记录死信原因，支持回放与告警。

优先级与死信的协同，保证"高优不被阻塞、失败不丢责任"。关键是把"重试"与"死信"分界：可重试自动，不可重试进 DLQ。优先级调度要防饿死，DLQ 要可审计、可重投。

• traceId/spanId 的生成与传播
• 跨 Agent 调用链的关联
• 追踪与回放的可观测实现

在请求/任务入口生成全局 traceId，随消息传递分发到每个 Agent；每个 Agent 内生成 spanId，父子关系（parentSpanId）串成调用链。消息携带 traceId/spanId 元数据，接收方透传。采集层把各 Agent 的 span（含 LLM 调用、工具调用、耗时、token）上报到追踪系统（LangSmith/Langfuse/OpenTelemetry），按 traceId 聚合出完整调用链与瀑布图。回放：按 traceId 检索该协作的所有消息与 span，重现执行过程与中间状态。要保证 traceId 在消息、异步、重试场景下不丢失。

可观测的关键是"唯一标识 + 全程传播 + 统一采集"。跨 Agent 追踪让"一次任务涉及哪个 Agent、哪步最慢、token 花在哪"一目了然，是调优与异常定位的基础。回放依赖 traceId 的完整关联。

• 检索（相关性排序、重排、过滤）
• 更新（冲突合并、版本）
• 遗忘策略（TTL、容量、重要性）

检索：用向量相似度 + 元数据过滤（时间、来源、类型）初筛，再用重排（如分数加权、时间加权）排序，兼顾相关性与时效。更新：写前校验冲突（同主题不同版本），用字段级合并、时间戳或置信度仲裁，配版本号防止覆盖。遗忘：按 TTL、容量上限、低频访问与重要性评分淘汰，被更正的信息标记失效而非删除（保留纠错历史）。检索结果可标注来源与置信度，供下游判断可信度。

共享记忆要"检索准、更新稳、遗忘得当"。检索准靠向量+重排与过滤；更新稳靠版本与合并；遗忘避免记忆膨胀与陈旧信息误导。遗忘策略要保留纠错链，防止错误信息回潮。

• 序列化格式（JSON/Protobuf/JSON Schema）与兼容性
• 新旧版本共存（灰度、兼容层）
• 平滑迁移策略

序列化选带版本兼容能力的格式：JSON Schema（可校验、可扩展）、Protobuf（字段编号、向后/前向兼容）。契约变更时遵循"只增不改删"：新增可选字段、不改既有语义。新旧版本共存：发布方先出新版本（兼容旧字段），消费方升级支持新字段，两者在过渡期并存；用版本号路由，或加适配器转换新旧消息。迁移走灰度：先一小部分流量走新版本验证，再逐步扩大，最后下线旧版本。全程校验 schema，记录版本差异，回滚可逆。

平滑迁移的关键是"兼容性 + 灰度"。兼容性让新旧可互操作，灰度让风险可控。只要严格"加字段不改字段"，旧消费方读到新消息也能忽略未知字段，新消费方读旧消息用默认值兜底，即可平滑过渡。

• 压缩与摘要的机制
• 质量 vs 成本权衡
• 触发时机（上下文长度、会话轮数、成本阈值）

上下文压缩在 token 接近窗口上限或成本超阈值时触发：把历史消息压缩为摘要（保留关键结论、决策、引用、未完成项），丢弃细节。权衡：摘要省 token 但可能丢细节，导致后续协作上下文缺失；因此压缩要"保住关键信息"——结构化结果、决策、验收标准保留原文，过程性对话压缩为摘要。触发时机：按上下文窗口占用率（如 80%）、会话轮数、或预算。压缩后要把摘要与未压缩部分衔接，必要时保留引用供还原。可做"分层压缩"：先摘要，需要时再按引用取回原文。

压缩是"窗口有限"的必然手段。核心是"何时触发 + 压缩什么"：触发要早于窗口溢出，压缩要保住关键信息、丢可丢弃细节。宁可摘要保结论，不因压缩丢决策与引用。

• 快照机制（定期快照、版本号）
• 回滚到一致性点
• 快照频率权衡（成本 vs 恢复粒度）

定期快照把某时刻的完整状态持久化，并关联版本号；配合事件日志（增量变更），可回滚到任意一致性点：先取最近快照，再重放该快照之后的事件到目标版本。回滚用于错误恢复、审计回放与版本回退。快照频率权衡：频率高→恢复快、丢失进度少，但存储与 IO 成本高；频率低→成本低，但恢复需重放大量事件、丢进度多。通常按"快照成本 × 变更速率"设置频率，快照间配增量日志（WAL/事件流）缩小恢复窗口。快照要原子（一致性点），避免半写状态。

快照 + 事件日志 = 可恢复 + 可回滚。快照频率的本质是"恢复成本 vs 存储成本"的折中，配增量日志可在低频快照下仍保持小恢复窗口。一致性点保证回滚到的是合法状态。