state-management

用途

状态管理是多智能体系统中的“管道”技能，用于维护关于“发生了什么、正在进行什么、已决定了什么”的共享真相。若缺少状态管理，各智能体将基于陈旧或冲突的信息工作，用户会为此付出代价：重复提问、答案矛盾、进度丢失。该技能指出，状态管理做不好，插件中的其他技能都会变得更难。

状态类型

任务状态：整体任务在生命周期中的位置，哪些子任务已完成、进行中或待处理。
上下文状态：每个智能体知道什么，哪些内容已被共享、摘要或丢弃。
用户状态：偏好、历史以及当前情绪状态。
决策状态：已做出的决策、考虑过的选项、被拒绝的选项及其原因。
错误状态：哪些失败、已重试、已升级。

状态架构模式

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

面向用户的状态设计

用户对系统记忆有预期：

会话内状态：本次对话中说过的一切应保持一致。
跨会话状态：过去会话中的偏好、决策和上下文应延续。
跨智能体状态：一个智能体学到的东西，其他智能体也应知道。
用户可控状态：用户应能查看、编辑和清除系统记住的内容。

决策规则

默认采用集中式状态。只有在实测跨智能体延迟确实成为瓶颈时才考虑分布式。多数团队过早选择分布式，并长期为一致性缺陷付出代价。
若某状态仅存在于单个智能体的工作记忆中，应视为已丢失。跨模型调用的记忆不可靠；任何需要持久化的内容都应提升到共享存储。
跨会话状态需要按类别明确征得同意。“记住偏好”不等于“记住我们讨论过的内容”。粒度是设计约束，而非可选项。
对于状态冲突，优先检测而非静默合并。用户可解决的显性冲突是可恢复的；静默合并的不一致则是不可见的损害。
用户看不见的状态，用户就无法信任。任何用于个性化行为的状态，都必须能在用户约 30 秒的界面导航内找到。

反模式

陈旧上下文缺陷：智能体基于已被其他智能体取代的状态行动。由于智能体单独看是正确的，因此难以检测。缓解方式是对每次读取进行版本化。
单一真相源之争：两个智能体都声称对同一状态切片拥有权威，解决规则模糊，间歇性地“最后写入获胜”。
隐式状态：状态存在于智能体的提示上下文中，而非共享存储。重启即丢失、不可转移、无法调试。
状态蔓延：随着功能累积，模式无界增长。六个月后没人知道哪些在用、哪些已死、哪些是关键支撑。
同步延迟：为效率批量写入，失败时被丢弃。用户看到“已保存”，但状态从未真正写入。
不可见个性化：状态塑造了用户看不见也无法覆盖的行为，逐渐滑向操纵。

不适用场景

单智能体产品：模型的上下文窗口就是状态，应改用上下文窗口设计。
无状态事务功能（一次性补全、图像生成调用）：显式状态架构只会增加开销而无收益。
原型阶段：过早的状态架构会冻结本应保持灵活的选择。使用尽可能简单的存储，仅在决策状态中记录决策。

设计产物

状态架构图（集中式/分布式/事件溯源/黑板）
状态模式定义（存储什么、存在哪里、由谁存储、TTL 是多少）
状态生命周期规范（创建、更新、归档、删除）
每个状态切片的冲突解决规则
面向用户的状态可见性与控制设计

示例：多智能体客服流程的任务状态

{
  "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
}

version 字段是防御陈旧上下文缺陷的最简单手段。带有 rejected 的 decisions 日志使路由在事故复盘时对人类可读。

该技能改编自多智能体系统中共享心智模型的研究，以及分布式系统一致性文献（Lamport 的逻辑时钟；actor 模型关于隔离状态的思想）。

技能介绍

用途