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

最近我在用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.这真的行得通吗？

• 也许吧

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

2 个帖子 - 2 位参与者

阅读完整话题