项目 · 2026 · 作者

Fulcrum:local-first 的 agent 控制面

为并行 AI 编程 agent 舰队设计的任务追踪、WIP 限制执行、混合记忆召回和 Chief-of-Staff 上下文系统--因为一张便利贴撑不住五个并发 agent,我不得不亲手把这个工具造出来。

Screenshot of the Fulcrum GitHub repo page showing topic tags, branches, and commit history

大多数工作日,我同时跑五个 AI 编程 agent。Claude Code、Codex、Gemini CLI、Pi、OpenCode—每个都很能干,每个都完全不知道其他人在做什么。在 Fulcrum 之前,我的「编排层」是一张便利贴和一句祷告。这不是夸张,是真的有一张便利贴。

为什么它存在

问题不是单个 agent 不好用,它们令人惊叹。问题是单个高效 agent 会话和一个不会把你脑子烧掉的多 agent 工作流之间的鸿沟。

我评估过的每一个厂商框架要么锁定单一提供商(绝对不行),要么为无状态的请求-响应循环设计(对于跨几小时的会话毫无用处),要么需要一个我不想把工作进行中的上下文托付给它的云后端。我想要的是在本地运行、能撑过笔记本重启、每次打开新 terminal tab 不需要从头解释整个项目历史的东西。

所以我建了我想用的那个东西。叫 Fulcrum,因为 agent 是杠杆,控制面才是决定杠杆真正落在哪里的东西。

它是怎么工作的

Fulcrum 暴露一个 MCP server—Anthropic 为 Claude Code 推出的标准工具调用接口 Model Context Protocol。每个连接进来的 agent 都能访问同一套原语:任务管理、运行生命周期追踪,和一个混合记忆存储。

存储层是带 FTS5 全文搜索的 SQLite,加上用于语义检索的向量索引。当一个 agent 想召回什么—「上周二我们对 auth schema 做了什么决定?」—Fulcrum 跑三阶段检索:FTS5 关键词匹配、向量余弦相似度、以及对查询中提到的实体做图遍历。结果通过加权倒排排名融合,在命中 agent 上下文窗口之前按置信度下限过滤。

记忆有三个层级。L0 是原始 dump—逐字、不可变、只追加。L1 是 LLM 策展人维护的策展 wiki 页面,带置信度分数、保留层级,以及到 L0 来源的反向引用。L2 是 L1 上的向量索引。当你让 Fulcrum 召回什么时,你拿到的是带 L0 溯源的 L1 页面,所以你总能把一个声明追溯到产生它的原始会话记录。

任务管理强制执行 WIP 限制。如果你的团队深陷五件事,有人想开第六件,Fulcrum 会推回去。这不是讲究—这是我发现的对防止 agent 上下文碎片化最有效的单一手段。同时在纠缠十二件开放任务的 agent,比专注在两件事的 agent 产出质量差得多。

Chief-of-Staff 角色是编排层:它从活跃任务、运行中的 agent 和近期事件构建世界状态快照,然后用这些快照向专业角色 dispatch 工作。COS 不能写代码,专业角色不能催生子编排。角色层级在工具层强制执行,不在 prompt 层。

有意思的地方

开发过程中最让我意外的事:最难的部分不是记忆检索,而是运行生命周期。

Agent 会崩,terminal 会关,笔记本盖子会合上。两小时前「进行中」的运行可能永远不会完成它的 complete_agent_run 调用。Fulcrum 有一个陈旧运行清除器,在会话开始时运行,中止任何最后心跳时间早于陈旧阈值的运行。没有它,工作区状态就会被幽灵运行中的 agent 塞满,你的 Chief-of-Staff 会开始基于鬼魂做规划决策。

另一个不明显的事:当你有五个并发 agent 都可能从稍微不同的角度捕获同一个架构决策时,让记忆写路径幂等比听起来要难得多。策展人的工作是去重、取代、维护一个连贯的 L1 界面—这意味着原始 L0 层需要承受高写入量,策展步骤需要优雅地处理冲突解决。

我开始把记忆层想成不像数据库,更像报纸档案馆:原始 dump 是每日版(永远别扔掉),策展页面是百科全书(新证据到来时更新),置信度分数是关于一个声明是否经受住了时间考验的编辑共识。

我会改什么

向量索引目前是每工作区的,这是个错误。跨工作区召回—「我上个月在支付服务 repo 里解决过一个类似的问题」—会真正有用,检索链路已经在那里了。我只是还没正确连接好范围。

我也想强化策展人的冲突解决逻辑。现在,如果两个 agent 捕获了关于同一个实体的矛盾信息,策展人会选择置信度更高的版本。这在实践中没问题,但它会静默丢弃少数派观点。正确的行为可能是把矛盾浮现为一个标记对,让人类或 COS 明确解决它。

dispatch 路径—COS 实际为专业角色 spawn 一个 Claude Code 子进程的地方—现在是 fire-and-forget。我想要正确的 stdout 流式传输,让 COS 可以观察正在发生什么,在运行偏离轨道时介入,而不需要等待心跳变冷。

Fulcrum 是我在认真跑 agent 时希望就已经存在的那块基础设施。构建它让我了解到,多 agent 编排主要是一个分布式系统问题,上面有一层薄薄的 LLM 特定关切,而分布式系统的问题才是会首先咬你的那些。