DevMesh

DevMesh

是什么启发我构建它

我同时使用着每一个编码 agent——但它们彼此都不知道对方的存在。

一个终端标签页里是 Claude。另一个里是 Codex。Gemini 在别处。第四个窗口里我在尝试 opencode。没有共享上下文，没有协作——只有我像一个人肉 API 网关一样在窗口之间复制粘贴，把整个计划都装在脑子里，因为这些工具都做不到。

某一刻我停下来问自己：为什么我是集成层？

我不会通过在同事桌子之间传话来管理人类队友。我想要的是一种像在带一个小型开发团队的体验——分配角色，让他们协作，观察工作进展，在需要时介入。

那个工具并不存在。所以我构建了它。

我真正想解决的问题

1. 供应商锁定是开发者要付的一种税。每个模型都有各自最擅长的事情，但工具却迫使你选择一个生态系统。DevMesh 可以并排运行 Claude、Codex、Gemini 和 opencode——用你的账号通过 OAuth 登录，或者带上你自己的密钥。你的模型，你的账单，你的选择。

2. “一个超级 agent”不如一个协调一致的团队可靠。单个 agent 可以写代码。但交付软件需要规划 + 构建 + 审查 + 测试——不同视角有不同优先级。这是团队问题，不是提示词问题。所以 DevMesh 有 Swarm 模式：Coordinator 分解目标，Builders 负责实现，Scouts 负责探索，Reviewers 和 QA 检查工作——所有这些并行进行，并通过共享看板和邮箱来协作。

3. Agentic 工具变成了黑盒，而开发者讨厌黑盒。我不想要 agent 做了什么决定的摘要——我想阅读终端。DevMesh 把所有内容都保留在标签式终端中，你可以实时查看。完全透明，也可以完全介入。

4. 你的源代码不应该为了获得这些能力而离开你的机器。DevMesh 是 local-first 的。Agents、终端和状态都在你的 Mac 上运行。没有任何内容通过别人的云端中转。这不是功能卖点——这是整个基础。

构建过程中，这种方法是如何演进的

它最初只是一个周末原型：一个带标签式终端的 Electron 应用。说实话，它只是一个更好用的方式，用来管理我本来就在使用的那些标签页。

然后我加入了在同一个窗口中运行来自不同提供商的 agents 的能力——那是它第一次让我感觉不只是一个终端多路复用器。混合使用模型不是噱头；这正是核心。

但独立的 agents 还不够。它们会重复工作、互相干扰、在原地打转中消耗 token。那时我意识到，没有协调的并行只会是更快的混乱——于是 Swarm 模式诞生了：角色、协调者、结构化通信层。

一些我通过踩坑学到的事：

- 多 agent 编排 80% 是通信设计，20% 是模型能力。难点不在模型，而在于它们如何彼此沟通。

- 开发者不想要仪表盘。他们想要可以阅读的终端。每当我增加抽象层，体验就会变差。于是我不断把它们删掉。

- 一个协调良好的中端模型团队，胜过一个包揽一切的前沿模型。人类团队也是如此。

- 到了 2026 年，桌面应用依然是一条可行路径。并不是所有东西都需要做成 SaaS——而且事实证明，“local-first”不是小众偏好，而是最受欢迎的需求。

如今，它是我每天用来构建它自身的工具。现在它也已经向所有人开放。

编排每一个编码 agent。本地运行。→ devmesh.app