OpenTeams：把多个编程Agent放进同一个可控工作台

项目简介

现在的编程Agent已经不少了。Claude Code写实现，Codex补测试，Gemini CLI做另一轮检查，单独看都能干活。麻烦出在Agent一多，项目背景要重复解释，结果要来回复制，谁改了什么也容易散在不同窗口里。

OpenTeams补的是中间这一层。它不是新的模型，而是一个本地优先的多Agent协作工作台，把Claude Code、Codex、Gemini CLI、Qwen Code和OpenCode等工具放进共享会话，让它们看到同一份上下文，也能通过@提及把任务交给指定成员。
简单任务可以留在群聊里完成，复杂任务则能拆成可查看、可审查和可重试的工作流。再把Issue、独立工作区和构建统计接起来，开发者看到的不只是聊天记录，而是任务、代码变化、交付结果与消耗之间的关系。

食用指南

访问地址
官网：https://openteams-lab.com/
Github 开源：https://github.com/openteams-lab/openteams

OpenTeams开源仓库

官方提供Windows、macOS和Linux桌面版本，也可以通过npx openteams-web启动。软件本身采用Apache 2.0协议，不过真正运行前仍要配置模型Provider，或者安装准备接入的编程Agent。OpenTeams免费，不代表Claude Code、Codex或其他模型调用也免费。

操作与体验

主界面先把多个Agent放进同一个会话。输入任务时可以直接@指定成员，右侧能看到会话成员、关联事项和文件变化。一个Agent完成修改后，另一个Agent可以沿着现有上下文继续检查，不需要再把项目背景从头讲一遍。

多个Agent共享会话并继续处理代码

成员并不是换个名字就结束了。配置页面可以给不同成员绑定运行方式、模型和技能，把写代码、审查、修复CI之类的工作分给更合适的Agent。这种组合的价值不在于Agent越多越好，而在于每个成员承担的任务是否清楚。

为不同Agent配置技能

群聊适合临时协作，任务一长就需要更明确的执行顺序。OpenTeams的工作流会把任务拆成节点，显示依赖、状态和负责成员；点开节点还能看到具体指令与执行记录。某一步失败时，可以停在这个节点检查或重试，不必把整项任务重新跑一遍。

工作流节点、依赖和任务详情

这套流程没有把项目决定权交给Agent。Issue仍由开发者维护，可以记录优先级、状态和外部GitHub Issue，再关联到实际执行会话。Agent负责干活，但哪些需求要做、什么时候合并，仍然留在人手里。

OpenTeams中的Issue列表

多个Agent同时改代码时，真正容易出问题的是工作目录。OpenTeams可以为会话启用隔离工作区，让并行任务进入独立的Git worktree。完成后再审查、合并或丢弃，能减少两个Agent在同一份未完成代码上互相覆盖的情况。

创建会话时启用隔离工作区

最后还有一块很实用的构建统计。页面会把交付功能、修复Bug、Token用量和模型成本放在一起看，也能按会话和模型拆开。它不能自动判断代码质量，却能回答一个更现实的问题：这些Agent究竟交付了什么，又花掉了多少资源。

按会话和模型查看交付与成本

这也暴露了多Agent协作的主要代价。成员越多、工作流越长，模型消耗越容易放大；Provider、Agent CLI、权限和工作区都需要自己配置。所谓本地优先，主要指工作台和运行记录留在本机，不代表连接云端模型时数据不会离开电脑。

写在最后

OpenTeams最有价值的地方，不是一次叫来更多Agent，而是把分散的Agent执行变成能看、能停、能审查的开发过程。对于已经同时使用两三种编程Agent，又经常处理长任务和并行分支的人，这种共享会话加工作流的组合会比较顺手。

如果平时只是偶尔让一个Agent改几行代码，额外搭团队、配Provider和维护工作流反而会增加负担。更稳妥的尝试方式，是先拿一个有明确验收条件的小功能，安排两个Agent完成实现与审查，再看节省的协调时间是否抵得过模型成本和配置工作。

转自：https://mp.weixin.qq.com/s/TiQ-hV78PI95pDgsPJFL1g