微信可能是 AI Agent 最好的界面？开源项目 OpenMausBot 把 Claude、Codex 组成团队

一个挺有意思的开源项目：OpenMausBot。顾名思义，它就是开源的 MausBot。

这个项目做了一件更有想象力的事情：把每个 AI Agent 变成通讯录里的一个联系人。

你可以给它们起名字、分配岗位、选择模型，甚至让每个 Agent 拥有一台自己的电脑。它们不只是回答问题，还能打开软件、执行任务、连接外部服务。这个思路让我重新思考了 Agent 产品的交互形态。

它不是把所有 AI 都塞进一个聊天框

现在不少 AI 产品的使用方式，依旧是“打开聊天框——输入问题——等待答案”。可现实工作并不是这样。做一个项目，需要产品经理、程序员、测试工程师，也需要有人协调任务。

OpenMausBot 借用了我们熟悉的即时通讯体验：每个聊天对象，背后都是一个真正在运行的 Agent。

你可以配置一个使用 Claude 的架构师、一个使用 Codex 的开发助手，再创建专门处理邮件和资料的 Agent。不同机器人可以拥有独立的角色、模型、对话上下文和工具。

它还支持频道、团队模板和定时任务。AI 不再只是一个问答入口，而是逐渐变成可组织、可分工的数字团队。

真正的变化：Agent 开始拥有“手和脚”

在我看来，OpenMausBot 最值得关注的并不是多 Agent，而是 Computer Use。

项目允许 Agent 使用云端 Linux 电脑、隔离的本地虚拟机，或者在一些受支持的平台上经用户授权操作宿主电脑。你可以实时查看它的桌面画面，必要时直接接管操作。

这意味着，过去需要人手动完成的流程，现在有机会交给 Agent：打开页面、查找资料、操作应用、整理结果。

与此同时，它通过 Composio 接入 Gmail、GitHub、Slack、Notion 等外部服务，让 Agent 不只会“点鼠标”，还能调用应用接口。

当然，云电脑和第三方集成并非天然免费，也不意味着数据始终留在本地。

那么，它真正做对了什么？

翻看项目架构后，我更感兴趣的是它的 Agent Harness 设计。

整个系统大致分为两层：前端采用 Electron、React；本地 Harness Server 负责管理 Claude、Codex、Grok 等 CLI 进程。

前端通过 HTTP 下发命令，再通过统一的 SSE 事件流接收执行进展。不同 Agent 原生协议的差异，被封装在 Driver 层。

这个设计的价值，是让模型执行、权限控制和用户界面解耦。

换模型，不必重写整个客户端；增加工具，也不用把复杂逻辑塞进前端。它还提供 MCP 服务 和命令行接口，方便外部系统调度机器人。

更重要的是，命令执行、文件修改等敏感操作可以通过审批卡片交给用户决定。Agent 可以有执行能力，但不应该默认拥有无限权限。

我更看重的，是它背后的产品方向

如果把这个思路放进企业研发，我们完全可以创建架构评审 Agent、编码 Agent、测试 Agent 和质量分析 Agent，让它们围绕同一个任务协作。

但团队化并不自动等于可靠。任务如何交接、结果怎样验收、权限能否隔离、失败以后如何恢复，这些才是企业落地真正要解决的问题。

OpenMausBot 也仍处在快速演进阶段：部分 Linux 桌面控制能力受限，远程访问需要妥善配置；本地配置文件中的 API Key 还需要特别保护。它更适合技术爱好者体验、验证 Agent 工作流，而不是未经评估就接入敏感生产环境。

想体验的话，可以从官方发行版安装，也可以在准备好 Node.js 24+ 和 Agent CLI 后运行：

npx openmausbot

写在最后

回头看，过去我们总希望做出一个“无所不知”的 AI 助手。

但 OpenMausBot 提醒了我：未来的 AI 产品，可能不是一个更强大的聊天框，而是一支可以沟通、分工、执行、被监督的 Agent 团队。

真正值得投入的，也许不只是模型能力，而是让这支团队可靠工作的组织与运行系统。

项目地址： https://github.com/milind-soni/OpenMausBot