问题描述：

各位佬友好，我最近在思考一个多智能体协作的问题

最近我在用Claude来写代码，Codex来Review，有时候还会哈基米写前端

看起来互不冲突，但是Review的模型，在review完之后，上下文都缓存好，直接让他改代码就会更方便，然后越搞就越冲突。。。之前用过一个叫蜂巢的项目，前端时间还挺火的，但那是一整套系统，我不能分别使用各家AI的原生IDE或CLI。

所以

我现在在设计一个项目，暂定叫 Vault 吧，以便后文提到能有个名字。
是一个本地外挂服务 / sidecar，专门解决多 Agent 协作中的共享状态、交接、冲突、回放和按需读取问题。

也就是他是一个各个Agent的通用数据库

所有agent在运行前都按需读取当前所有Agent运行情况的快照

来知道
发生了什么，现在需要做什么，什么我不能做，什么已经有人做了

真心想请各位从架构、工程可行性、协议设计、几个角度狠狠干我一顿，看看这东西有没有走偏。

---

先说我想解决的问题

现在很多的多 Agent 协作，实际做法还是下面这几种：

1. 一个 Agent 把一大段上下文直接丢给另一个 Agent
2. 让 Agent 之间通过自然语言互相同步
3. 调度器保存聊天记录，然后下一个 Agent 接着读
4. 用一个超长上下文窗口硬顶
5. 压缩上下文互相丢
6. 多Agent共同维护一个“LOG”（不止见到一个人这么做了）

这几种方式的问题我觉得都很明显：

• token 成本高
• 信息失真严重
• 历史很难回放
• 很难做真正的“按需读取”,token利用度真的很低
• 多个 Agent 同时干活时，没有明确 ownership

所以我想换个思路：

不要让 Agent 直接传大量上下文，直接让它们把阶段性工作结果提交到一个外部状态层里。

Agent可以像读Skill一样以这个方式使用：

1. 先读任务快照
2. 再读相关 commit 摘要
3. 必要时再下钻读 artifact 正文
4. 修改前先声明 scope
5. 完成后再提交结构化 commit

这个项目就是干这个的。

当前技术路线我准备这样做：

• Node.js
• SQLite
• 对外提供 CLI + HTTP API + MCP

我的核心设计思路

1. 共享状态外置

Agent 之间不要默认共享完整上下文，而是共享：

• task_id
• workspace_id
• scope
• latest_commit_id
• snapshot_version

也就是共享“引用”和“结构化状态”，而不是共享整段聊天文本
当模型觉得需要的时候，再去读具体的artifact

2. 默认摘要优先

读取顺序

1. 读 snapshot
2. 读相关 commit summary
3. 只有命中时才读 artifact 正文

3. Git-like，但不是 Git 本身

我受 Git 的启发很大，具体概念：

• 有 commit 概念
• 有 parent 关系
• 有 artifact 证据
• 有可回放时间线
• 有 scope ownership
• 有版本化快照

4. skill 只负责“教会 Agent 怎么用”

毕竟我不可能去维护或适配各家的Coding代码，当然要找一个通用层了
我应该目前只有Skill这一个选择
而且其实这个项目也是因为一直以来从MCP到Skill的发展路程，从MCP占用很多上下文到Skill按需读取，这一路发展也给了我很大的启发。

整体架构图

总体架构

flowchart LR A["Agent / IDE / Orchestrator"] --> B["Skill做使用规范"] B --> C A --> C["Vault Access Layer"] C --> D["CLI"] C --> E["HTTP API"] C --> F["MCP Server"] D --> G["Vault Core Service"] E --> G F --> G G --> H["Task Service"] G --> H1["Run Registry"] G --> I["Scope Lease Service"] G --> J["Commit Service"] G --> K["Artifact Service"] G --> L["Snapshot Service"] G --> M["Search Service"] G --> N["Event Log"] H --> O["SQLite"] H1 --> O I --> O J --> O L --> O M --> O N --> O K --> P["Local Artifact Store"]

---

一个典型的Agent回合

sequenceDiagram participant Agent participant Vault participant DB as SQLite participant FS as Artifact Store Agent->>Vault: register_run(task_id, workspace_id) Vault->>DB: create/find run DB-->>Vault: run_id Vault-->>Agent: run_id Agent->>Vault: get_task_snapshot(task_id, run_id, workspace_id, scope) Vault->>DB: query task/workspace/commits/leases DB-->>Vault: snapshot data Vault-->>Agent: snapshot + snapshot_version Agent->>Vault: claim_scope(task_id, run_id, workspace_id, scope) Vault->>DB: check overlap + insert lease DB-->>Vault: lease result Vault-->>Agent: lease_id / conflict info Agent->>Vault: heartbeat_lease(lease_id) Vault->>DB: refresh lease heartbeat Agent->>Vault: append_commit(payload + idempotency_key + observed_snapshot_version) Vault->>DB: verify idempotency Vault->>DB: verify snapshot version Vault->>FS: write artifacts Vault->>DB: write commit + relations + events Vault-->>Agent: commit_id or STALE_SNAPSHOT Agent->>Vault: release_scope(lease_id) Vault->>DB: release lease

---

我现在最困惑的点

1. 这个项目到底是不是“重复造轮子”

我自己也在反复问：

• 这是不是“Git + issue tracker + RAG + MCP”的缝合怪
• 这是不是本质上只是在做一个“高级一点的共享记忆库”

2. Commit 的结构化程度应该到哪里为止

我现在是强约束：

• summary
• scopes
• assumptions
• risks
• next_actions
• artifacts

但我不确定这会不会太重。

如果太轻：

• commit 没信息量

如果太重：

• Agent 懒得写
• tool 调用负担上升
• 最后反而没人遵守协议

3. MCP / HTTP / CLI 到底谁应该是主入口

我目前是三套都想做：

• CLI 方便本地调试
• HTTP 方便前端控制台
• MCP 方便 Agent 直接调

但真实实现中，很可能最后只有一个是主心骨。

4.这真的行得通吗？

• 也许吧

---

还是比较笼统，而且好想很多真正细节上的东西还完全没有设计好
希望各位佬友有想法能和我交流

网友解答：

---

--【壹】--：

我理解这几个东西的重心还是不太一样。

Hindsight 更像是在解决“怎么记住、怎么学习”的问题。
OpenViking 更像是在解决“怎么统一管理上下文”的问题。

而我现在想做的，如果能成立，我希望它更偏“多 agent 协作时的共享状态层”。

也就是说，我关心的重点是多个 agent 围绕同一个任务时：

• 当前到底是谁在做什么
• 各自进展怎么交接
• 状态怎么同步
• 冲突怎么发现
• 历史怎么回放
• 怎么避免大家又退回到互相扔大段上下文

当然这也是我现在最没完全想透的地方。
如果最后做出来发现本质上还是个 memory/context 系统，那或许说明我步子走大了，或者这玩意在底层上和LLM五行相克（）。

---

IDE和CLI应该更多是易用性的区别吧，我理解AI IDE就是包装过的CLI，这两者在AI运作逻辑上应该本质上区别不太大

---

--【贰】--：

sidecar我个人觉得也是可以做的，不过模式和现在的外挂记忆库没有太大区别，如openviking, hindsight这种也可以实现记忆共享。
当前顶尖模型的task delegate和task routing都很成熟，会不会在一个harness中做agent协作会方便管理一点？
一点拙见
说起来，原生的ide跟cli的优势是啥？