我维护着 Fulcrum — 一个用于协调多 agent 编程工作的本地优先 agent 控制面。2026年市场上有几十个 agent 框架。“为什么要再造一个？“这个问题值得一个诚实的回答，而答案就是：没有一个其他框架把那些让这个模式在每年3400次提交规模下真正可用的枯燥运维部分做好。

Fulcrum 到底是什么

Fulcrum 是一个小型 TypeScript 运行时，通过 MCP server 和 CLI 暴露了少数几个任何 coding agent（Claude Code、Codex、Gemini、Cursor，任何能说 MCP 的工具）都能调用的原语：

  • 任务追踪 — 开始/更新/完成一个工作单元，支持 WIP 上限和阻塞追踪。
  • 混合记忆召回 — FTS5 + vector + 可选图存储，带超越追踪和置信度跟踪，让 agent 无需每次重新总结就能在 session 间积累持久上下文。
  • Chief-of-Staff 上下文 — 一个其他 agent 可以消费的世界状态快照，相当于”这是工作区里正在发生的事”的简报，而不是每个 session 重新发现状态。
  • Agent 运行生命周期 — 注册、心跳、阻塞、完成。一个空转但未完成的运行会在 CLI 里浮现，而不是悄悄消失。

所有东西都持久化在本地。没有托管组件，默认没有遥测，没有供应商锁定。它和你的编辑器、你的 agent 运行在同一台机器上。

它在解决的那块空间

2026年市场上大多数 agent 框架为两种形态之一做了优化：

形态 A：云端托管的编排器。 LangChain 托管、LlamaIndex 托管、各家供应商专属版本。它们的原语假定你可以接受 agent 的任务状态住在别人的机器上，他们的计费方案应用于每个步骤。

形态 B：编辑器内的运行时。 Claude Code、Cursor 等内置的 agent。它们的原语假定你一次在一个编辑器里用一个 agent，是短暂的，任何持久化的东西都是用户自己的问题。

当你像我一样工作时，这两种形态都会失败：多个 agent 轮换跨越多个工作事项，有真实的上下文需要跨 session 持久化，还有一个 agent 可以看到的任务追踪工程纪律。

Fulcrum 活在第三种形态：本地优先、多 agent、agent 可见。 Agent 可以直接查询任务列表和记忆；状态属于你，不属于供应商；运维原语（WIP、阻塞、心跳）是一等公民。

值得捍卫的设计选择

几个我会在评审中为其辩护的决策：

1. Agent 有读权限，人类有写权限

默认情况下，agent 可以读一切，但写的很少。一个 agent 可以记录它拥有的任务的进度；它可以写入记忆层；它可以发心跳。它不能把任务重新分配给其他 agent，不能升级权限，不能调用团队。这些由人类（我，或者操作者）来做。

这和你给一个初级工程师的”自由读、谨慎写”姿态是一样的。它也能防止多 agent 运行变成一个所有人都把所有人的工作重新分配给自己的霍布斯式状态。

2. 记忆是分层的，不是扁平的

记忆层有三个层级：L0（原始 dump，不可变，零截断）、L1（经过策展的 wiki 式页面，有置信度和保留期，由策展 agent 编辑）、L2（L1 上的 vector）。召回通过 L1 进行，带 L0 反向引用，所以 agent 可以追溯任何说法到其原始来源。

这个架构本身不新颖（MemGPT 及相关谱系给了很多启发），但它的实现方式让溯源链路很便宜。当 Fulcrum 告诉一个 agent 某件事时，agent 可以问”这是从哪里来的？“并得到答案。

3. 角色边界是强制的，不是建议的

Fulcrum 有 agent 角色的概念（工程师、测试员、评审员、chief-of-staff 等）。只有 chief_of_staff 可以调用团队。只有角色合适的 agent 才能认领某些任务。这些不是约定——它们在 MCP 层检查。如果一个 software_engineer agent 尝试调用团队，会收到一个报错。

内置这个的原因：没有它，agent 工作流很快就会崩溃成”所有人做所有事”，而这恰恰是多 agent 本该避免的病症。

4. 它离线可用

核心操作不需要网络调用。整个东西跑在本地 SQLite、本地 vault markdown 文件和本地 embedding 上。如果 homelab 的网络断了，Fulcrum 继续工作，指向它的 agent 也继续工作。

它不是什么

澄清一下预期：

  • 它不是前沿 agent 框架。 它不试图成为一个模型。它是一个控制面，坐在你已经在运行的任何 agent 旁边。
  • 它不是托管产品。 没有托管版本。你 clone 仓库，你运行它，你拥有数据。
  • 它不是在大规模上经过实战检验的。 它在我的规模上经过实战检验——多个 agent、多年的 session 历史、真实工作事项。当别人在他们的规模上运行时，会浮现粗糙的边角。这就是它开源的原因。

“为什么要折腾”的答案

对”为什么在 X 存在的情况下还要写这个”最诚实的回答是：我写了它，因为用 X 每个 session 要额外付出20分钟的开销，而 Fulcrum 只需要30秒。 多 agent、多工作事项的工作有固定开销，这些开销复利很快。要么你一直付，要么你一次性投资一个让它们消失的工具。我选择了一次性投资。

如果你做的是类似的工作——多个 agent、持久上下文、真实的任务纪律——试试 Fulcrum。如果你做的是单 agent、单 session、短暂性的工作，你不需要它。没关系。它不是要成为一切的。

这个模式会推广

Fulcrum 里我最引以为傲的不是代码。是模式：本地优先、agent 可见、多 agent、持久化。这个模式在未来两年会吃掉托管编排器市场的很大一块。那些建在供应商锁定编排器之上的团队会在某天醒来，发现他们想要这种形态而没有。我宁愿站在正在构建这个形态的一侧，也不愿站在等别人来做的一侧。

另外：我过去一年的 commit 图主要是 Fulcrum 和你正在读的这个网站。如果你想知道”席间”时的 Mo 把时间花在哪里，答案就是这个。失业期从没交付过这么多 commit。