当皇上源码解析任务状态机task-store如何解决多Agent协作的信息孤岛【免费下载链接】danghuangshangOpen-source multi-agent collaboration system inspired by Chinese governance — deploy and coordinate specialized AI agents with OpenClaw.项目地址: https://gitcode.com/gh_mirrors/bo/danghuangshang在多 Agent 协作系统里最大的坑不是Agent 不会干活而是干活的信息互相看不见——兵部写完了代码礼部却拿不到结果皇上也查不到整体进度。开源项目**当皇上danghuangshang**给出了一个简洁的答案一个名为task-store的任务状态机。它以共享 JSON 文件为账本用 7 种状态 依赖关系把散落在各 Agent 会话里的信息串成一条可追溯的流水线。一、先理解痛点多Agent协作为什么会信息孤岛想象你让 3 个 AI Agent 协作完成实现登录 API 并写文档问题没有共享状态时上游输出丢失兵部完成了 API但礼部开新会话时根本不知道代码在哪状态黑盒皇上问进度如何只能挨个去问答案全凭记忆错误裸奔某一步失败了没人知道下游继续空转上下文爆炸把 50 条讨论记录全塞给下一个 Agenttoken 直接打爆根源在于每个 Agent 的会话是独立记忆的彼此之间没有公共白板。二、task-store一部 362 行的朝廷账本整个方案的核心源码只有 scripts/task-store.js 一个文件约 360 行设计非常克制存储一个 JSON 文件默认放在~/.clawd/task-store/tasks.json可用环境变量TASK_STORE_DIR覆盖零数据库依赖读写readDB()/writeDB()两个函数完成全部持久化使用方式Agent 通过 CLI 命令操作任何 Agent 都能读写同一本账node scripts/task-store.js create --id task_20260321_120000 --plan plan.json创建时task-store 会把内阁生成的 Plan步骤 依赖关系展开成一组初始状态为pending的步骤并记录时间戳这就是后续所有状态流转的起点。三、7 种状态让每一步都有名有分状态机定义在源码开头scripts/task-store.js#L33-L41状态含义通俗理解pending等待执行还没轮到running执行中正在干活success成功完成交差failed失败重试耗尽办砸了retrying自动重试中再试一次cancelled已取消圣上收回成命revision_required审查驳回需返工都察院打回更妙的是任务整体状态是自动推导的calculateTaskStatus 函数根据所有步骤的状态算出任务级结论——全部 success 才算完成有步骤失败且重试 ≥3 次则整体失败只要有 running 就算进行中。皇上用户随时执行status命令就能拿到2/3这样的进度快照彻底告别状态黑盒。四、信息孤岛终结者get-input 自动聚合上游输出这是 task-store 最核心的设计。当礼部要开始写文档时不需要有人手动把兵部的结果转告它而是执行node scripts/task-store.js get-input --task task_XXX --step 2getInput 函数会做三件事查依赖读该步骤的dependencies字段找到上游步骤校验状态如果上游还没success直接报错阻断防止下游空转聚合输出把上游的output结果、代码链接、产物文件打包进upstreamOutputs连同任务背景一并返回下游 Agent 拿到的是一份结构化的交接单——上游是谁、做了什么、产出了什么一目了然。信息不再依赖会话记忆传递而是通过共享存储显式流转这就是孤岛变大陆的关键一步。五、错误不再是裸奔两种错误两种处置源码把错误分为三类scripts/task-store.js#L44-L48transient临时错误网络超时、限流 → 司礼监自动重试最多 3 次超过则步骤置为failedpermanent永久错误逻辑 bug → 停止重试等待人工介入rejected / revision_required审查驳回都察院审查不通过 → 带上驳回原因打回原部门返工每种错误都带结构化记录error.messageerror.type配合list --status failed命令所有失败步骤可被统一检索。六、配套利器上下文压缩防止交接单变话痨光有状态传递还不够——如果兵部的完整对话50 条消息、8000 token原样塞给礼部token 照样爆炸。项目用配套的 scripts/context-compressor.js 解决按重要性评分决策、交付物、错误 讨论、尝试过程压缩对话官方数据压缩率可达90%左右只保留关键结论和摘要再进入output。七、一次完整协作是怎么跑起来的用户下旨 → 司礼监接旨 → 内阁生成 Plan标注依赖 → task-store create建账本 → 兵部 get-input → 执行 → updatesuccess 输出 → 礼部 get-input自动拿到兵部输出→ 执行 → update → 都察院审查 → status 汇报进度 3/3 → 交付用户全程司礼监调度者人格定义见 configs/ming-neige/agents/silijian.md只负责派活 记账 汇报每个环节的状态变更都落盘到 task-store任何时刻中断都可以凭账本恢复。八、延伸阅读相关文件与文档想深入这块源码建议按这个顺序读核心源码scripts/task-store.js —— 状态机全部逻辑使用指南docs/task-state-machine.md —— 含完整工作流、错误处理、最佳实践上下文压缩scripts/context-compressor.js —— 交接信息的瘦身单元测试tests/test-task-store.js —— 创建、更新、聚合输入三类核心用例协作流程背景docs/sansheng-flow.md —— 内阁前置 都察院后置的三省流程总结task-store 用最朴素的方式——一个共享 JSON 文件加一套严格的状态机——解决了多 Agent 协作中最容易被忽视的问题信息在 Agent 之间如何可靠传递。它告诉我们多 Agent 系统的成熟度不取决于单个 Agent 多聪明而取决于账本是否清晰。如果你正在搭建自己的多 Agent 系统这 360 行源码值得逐行读一遍。【免费下载链接】danghuangshangOpen-source multi-agent collaboration system inspired by Chinese governance — deploy and coordinate specialized AI agents with OpenClaw.项目地址: https://gitcode.com/gh_mirrors/bo/danghuangshang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考