state-management

状态管理

在多 Agent 系统中，状态是关于已发生的事情、正在进行的事情以及已作出决定的共享事实。没有状态管理，Agent 就会依据过时或相互冲突的信息开展工作，用户则要承担重复提问、答案矛盾和进度丢失的代价。

状态管理是多 Agent 设计中的 管道工程 技能。做得不对，插件中的其他每项技能都会变得更加困难。

状态类型

• 任务状态：整体任务处于生命周期的哪个阶段。哪些子任务已完成、正在进行或尚未开始。
• 上下文状态：每个 Agent 了解什么。哪些内容已共享、已摘要或已舍弃。
• 用户状态：偏好、历史记录和当前情绪状态。
• 决策状态：已作出的决定、已考虑的选项、已否决的选项（以及原因）。
• 错误状态：哪些环节失败过、重试过或升级处理过。

状态架构模式

• 集中式状态：所有 Agent 都读写同一个共享存储。简单、易于调试。规模扩大时有瓶颈风险。
• 分布式状态：每个 Agent 都维护自己的状态，并与其他 Agent 同步。灵活，但有一致性风险。
• 事件溯源状态：根据事件日志构建状态。每次变更都会记录，可审计，但复杂。
• 黑板模式：共享工作区，Agent 可在其中发布结果并读取其他 Agent 的贡献。适用于协作式问题解决。

面向用户设计状态

用户对系统会记住什么抱有以下预期：

• 会话内状态：本次对话中说过的所有内容都应一致地保留
• 跨会话状态：过去会话中的偏好、决定和上下文应延续到后续会话
• 跨 Agent 状态：如果一个 Agent 学到了某些内容，其他 Agent 也应知晓
• 用户可控状态：用户应能够查看、编辑和清除系统记住的内容

决策规则

• 默认采用集中式状态。 只有在测量确认跨 Agent 延迟确实成为瓶颈时，才考虑分布式状态。大多数团队过早选择分布式架构，之后便长期为一致性问题所困。
• 如果某项状态只存在于单个 Agent 的工作记忆中，就应视为已丢失。 模型调用之间的记忆并不可靠；任何需要持久化的内容都应转移到共享存储中。
• 跨会话状态需按类别明确征得同意。 “记住偏好”≠“记住我们的讨论内容”。设计的关键约束是细粒度控制，而非锦上添花。
• 对于状态冲突，应优先检测，而非静默合并。 呈现给用户并由其解决的冲突可以恢复；静默合并的不一致则会造成无法察觉的损害。
• 用户看不见的状态，就无法获得用户信任。 任何用于个性化行为的状态，都必须能让用户在约 30 秒的界面导航内找到并查看。

反模式

• 上下文过时错误：某个 Agent 根据已被另一个 Agent 更新的状态采取行动。这种问题难以发现，因为该 Agent 单独来看似乎没有出错。可通过为每次读取添加版本号来缓解。
• 唯一事实来源之争：两个 Agent 都声称对同一状态片段拥有控制权。解决规则含糊不清，导致间歇性地由最后一次写入胜出。
• 隐式状态：状态存在于 Agent 的提示词上下文中，而非共享存储中。重启后会丢失，无法转移，也无法调试。
• 状态蔓延：随着功能不断增加，架构不断扩张。六个月后，没人知道哪些内容仍在使用、哪些已废弃，哪些不可或缺。
• 延迟同步：为提高效率而批量写入，但失败时写入内容会被丢弃。用户看到“已保存”，状态却从未真正写入。
• 不可见的个性化：状态影响了用户看不到也无法覆盖的行为，逐渐偏向操纵用户。

何时不应使用

• 单 Agent 产品 — 模型的上下文窗口 就是 状态。此时应选择 context-window-design。
• 无状态事务性功能（一次性补全、图像生成调用）— 显式状态架构会增加开销，却没有收益。
• 原型阶段 — 过早设计状态架构会固化本应保持灵活的选择。使用尽可能简单的存储，仅在 decision-state 中记录决策。

另请参阅

• handoff-protocols — Agent 之间的上下文传递依赖状态架构；请一并设计。
• observability-design — 状态变更是最有用的追踪记录。应同时设计日志记录和存储内容。
• consent-and-agency — 跨会话和跨 Agent 的状态默认涉及同意。
• task-decomposition — 任务状态架构由分解形式决定；请协同设计。

设计产物

• 状态架构图（集中式／分布式／事件溯源／黑板）
• 状态架构定义（存储内容、存储位置、负责主体和 TTL）
• 状态生命周期规范（创建、更新、归档、删除）
• 各状态切片的冲突解决规则
• 面向用户的状态可见性和控制设计

示例 — 多 Agent 客户支持流程的任务状态：

{
  "task_id": "tk_8b2",
  "owner_agent": "router",                  // who currently holds the task
  "status": "in_progress | escalated | done",
  "subtasks": [
    {"id": "verify_account", "status": "done", "result_ref": "ctx_a91"},
    {"id": "check_refund_eligibility", "status": "in_progress", "owner": "billing_agent"}
  ],
  "user_state_ref": "us_482",               // pointer, not embedded copy
  "decisions": [
    {"at": "...", "by": "router", "choice": "billing_agent", "rejected": ["faq_agent"], "why": "intent: refund"}
  ],
  "errors": [],
  "version": 7                              // increments on every write; readers check before acting
}

版本字段是防范上下文过时错误最简单的方法。带有 rejected 的 decisions 日志，让人们在事件复盘期间能够看清路由过程。

改编自多 Agent 系统共享心智模型的相关研究，以及分布式系统一致性文献（Lamport 关于逻辑时钟的研究；关于隔离状态的 Actor 模型）。