本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
佬友们好，介绍下我正在开发的开源项目openteams，它的核心功能是通过多Agent协作来实现开发提效。
我想套用知乎上的3W1H法则（Why, What, Who, How）来介绍下这个项目。
Why（为什么要开发这个项目）
先讲一下为什么想开发这个项目？有两个原因：
-
装×：我认为多Agent协作是AI Agent发展的必然趋势。我们能不能在AI时代跑在前面，很大程度上取决于个人能调度出多少 Agent 的能力。单人+AI团队的工作形态会成为未来3~5年大部分开发者的常态。基于对这个未来的判断，我觉得自己应该做点什么：提供一套真正能帮开发者发挥出Agent能力的工具。
-
实际经历：我之前跑多个任务的时候，都是开一堆会话来独立运行任务。会话之间反复切换真的非常消耗我的注意力，经常一个下午过去了，总感觉自己很忙，但是又觉得自己啥也没干，非常空虚… 所以我当时花了两天时间vibe coding了一个界面把所有agent放一个群里，然后指挥着它们干活，这就是最初的openteams。后来用久了发现，单纯给它们发消息来实现协作的效率比较低，所以在学习和总结了前辈们的多Agent经验的基础上，开发了工作流模式。
What（openteams是什么）
openteams的核心设计理念是通过多Agent协作来提升工作效率，"提效"是这个工具的核心价值。
按照使用场景的不同，我把openteams分成了两种模式：自由聊天模式和工作流模式。
自由聊天模式
首先是自由聊天模式。自由聊天模式下，我们可以通过@符号将消息定向发送给指定的Agent，让它执行对应任务，也可以把不同任务分配给不同Agent并行执行。比较适用于那些需要即时反馈的简单任务。
这个模式的用法有点类似于CC或Codex中的多线程任务，但是有两点关键区别。
第一、会话是以群聊的形式组织，所有Agent共享一个群聊上下文，这种形态的好处是可以让不同的Agent能无缝接续执行。举个例子：我让Codex实现了一个前端界面，但是很丑，这时我可以直接让gemini来优化它。新增的gemini成员能通过读取聊天历史就知道它需要优化哪个界面、哪个组件，省得我反复给它解释。除此之外，还能通过引用某条消息来提醒Agent必须读取这条消息的内容。
第二、Agent之间能相互收发消息。这就意味着整个Agent协作处于一种完全开放的状态，非常适合让它们进行一些自主探索。但过度开放又会导致它们之间执行发散或者陷入对话死循环。所以我加了两个约束：
-
团队准则：由使用者去制定具体的规则来约束这些Agent的行为。比如只允许某一个Agent能主动给其他Agent发消息，其他Agent不允许主动发起对话，等等。
-
对话深度限制：通过限制对话深度避免陷入对话死循环，当两个Agent的连续互发次数达到指定上限时自动停止消息的收发。该数值可以在设置->代理链式调用中进行调整，默认是8。
所以自由聊天模式不只是"把任务分发给不同 Agent"这么简单，它还为开发者探索自己专属的多Agent协作模式留出了空间，其玩法上限非常高。比如之前我对象用openteams来搭了一个夸夸群，并给Agents们灌输了一些关于她的个人资料，设置好团队准则。几个Agent真的能把人夸得心花怒放，哈哈哈，用来在工作摸鱼的时候解解压也是不错的~
工作流模式
接下来说工作流模式，这个模式主要面向的是复杂需求的开发。
为什么要开发这个模式？主要是我开通了GPT Pro会员，发现光靠自由聊天模式根本用不完限额；而且当我要开发一个复杂功能的时候要反复和Agent进行确认、审核，整个实现过程也不够直观。
我也找了oh-my-codex, superpower这些插件来用，它们的设计思路很好，但是个人不太喜欢TUI——跑单Agent时TUI的体验确实不错，但同时跑多个Agent，我根本找不到哪个Agent执行的是什么任务，可以说非常混乱。
基于计划执行过程可视化，多Agent并行执行任务这两个需求，我在openteams上加了工作流模式，其核心的设计思路借鉴了superpower。
具体流程：先用brainstorming技能来确认方案——让主Agent反复向我提问来梳理出具体的需求；然后用write-plans技能来写计划，核心是按照TDD的思路来拆解每项任务，并按职责把不同任务分配给不同的子Agent。主Agent在产出计划时，我会要求它同时输出每项任务的要求、验收条件，以及任务之间的依赖关系。这样openteams就能将计划转化成一张DAG图——当计划从文字转换成图像以后，整个流程就一目了然，每一步干什么，前置任务是什么，清清楚楚。
和superpower最大的区别就是任务调度。无论是superpower还是oh-my-codex，都是让主Agent去调度任务和审核结果，我认为这存在两个问题：
-
调度可靠性：基于模型输出的调度本质上是一个松散调度，它存在出错概率的。比如一个任务的前置任务没有完成，那么当前任务可能就会胡乱执行，自然后续的任务都会跟着乱套，导致整个计划失败。
-
上下文污染：omx中所有审核都交给主Agent去完成，上下文污染被污染，导致模型降智。
我在openteams工作流模式中给出的解决方案是：
-
独立的调度程序：计划确定后，执行调度是一个100%确定的事情。所以我单独写了一个任务调度程序来管理整个计划的调度运行，严格按照计划节点的依赖关系运行每个节点，保证调度逻辑按计划绝对正确的执行。
-
干净上下文的审核Agent：每个任务节点执行完以后，系统会分配一个全新上下文的Agent来运行结果审核。系统会要求审核Agent读这个该节点的任务要求，独立做出判断，不轻信执行Agent的输出结果。
-
开发者最终把关：默认情况下，每个节点执行+审核完成后还需要开发者进行最终审核，只有开发者审核通过才能进入下一个节点。
当然鉴于佬友们的token余额和对AI的信任程度不同，我把上面两道审核都做成了可开关的设置，佬友们可以关掉主Agent审核来节省点token，也可以把用户审核关了来节省点精力。但坏处就是，结果可能不那么可控了。
最后一个小建议：执行的Agent和审核的Agent用不同的模型，这样审查出问题的概率会更大一些。
总的来说，在工作流模式下：关掉用户审核就基本是全自动运行，你只需要验证最终结果；开启全部审核虽然过程稍重，但每一步都是预期效果，最终交付几乎不会偏离预期。具体怎么用，开发者们可以根据自己的实际情况灵活调整。
我在实际开发任务中，通常是将两种模式结合起来使用。修复一个小bug直接@对应的Agent让它修复即可。当需要开发一个功能需求时，我会先在工作流模式下和主Agent对齐需求方案，然后执行计划。计划执行完后有较大的改动，我会开启第二轮迭代。如果结果基本可用，当测试过程中发现bug时，我会在一个会话中切换到自由聊天模式指定某个Agent进行修复。
PS: 刚发现最新版的Claude Code也实现了独立的workflow调度，说明我们的开发方向没有问题。
Who（为谁开发的）
最初这个项目只是我自己拿来提效的小玩具，后来分享给同事用过以后，他们反馈说确实帮他们省了一些事，我就把它开源了出来，并且也一直在持续打磨。
我希望openteams能真正帮助开发者在日常工作中实现提效，而不只是停留在概念层面的多Agent玩具。目前项目也处于刚起步的阶段，还有很多需要完善的地方，还恳请开发者们不要吝啬你们的批评，狠狠地喷openteams，你们的每一次鞭策都能让openteams更好用，也能更多的开发者从中受益，感谢。
How（怎么使用openteams）
下面我会从首次使用者的角度来一步一步讲述openteams应该如何使用。
下载安装
首先我们到github主页，找到quick start：GitHub - openteams-lab/openteams: Plan, Build, and Ship — with a team of AI agents instead of one · GitHub
如果是使用Mac的开发者，请输入npx openteams-web启动网页端
如果是windows和linux的开发者，可以去Release下载桌面端.msi文件和.deb文件，你也可以选择启动网页端。
Code Agent依赖
然后请确保你的电脑上已经安装了CC, Codex, OpenCode等支持的十种编程Agent中的一个，都没安装的话参考文档配置模型服务商。
创建团队
然后点击创建团队，选择全栈开发团队，给每个成员配置Agent模型，然后导入。我这里不需要ux和reviewer，我把他们从我的团队里面移除掉。然后将我的这个团队保存我的专属开发团队，编辑下团队准则，规定只有协调官能给我发消息。
好了，现在通过自由聊天模式和backend分配任务。然后我再切换到工作流模式，我这里想重构一下openteams的后端，让主Agent（协调官）给我出一个方案，内置了brainstorming技能，它会和我确认方案选择。
确认完毕后，让它生成计划，生成后就能看到这样类似的DAG执行图，点击执行计划，然后设置下每个节点的审核者，默认是主Agent和开发者都要审核，设置完成后开始执行计划。
计划跑起来以后需要开发者审核时会弹出一个提示框，点击后会进入对话框中，选择批准或者拒绝并填写拒绝理由，这个节点就会根据反馈重新运行。
反思
这款开源产品的产品形态在开发之初就定位于多Agent协作的开发提效工具。但是产品设计上并没有完全按照产品的核心目标来进行打造，我经过反思后发现有以下问题：
-
首先从UI上其实就不是开发者友好，不专业，不够简洁，颜色杂乱；主要原因是我在开发过程中又想兼容非开发人员的需求&审美，想做到小白化，导致现在的外观和功能的割裂。
-
面向开发者的功能不够全面，比如作为开发者我们非常关心token成本，尤其是多Agent场景下，但是openteams现在没有。没有github集成，不能直接让github上的PR或者Issue转换成任务等等开发者常用的功能。
-
现在openteams里面的团队模板和技能库太杂乱，什么都有，没有专注在开发领域，看起来很多，但其实大部分都无法带来真实提效。
-
第一次使用的流程太长，不够简洁，不能自动感知和配置Code Agent等等
虽然openteams现在问题还有很多，但是我有信心能让openteams越来越好用，也欢迎能有更多佬友加入，一起把openteams打造成开源社区中最好用的多Agent协作工具。
我后面会在L站定期开贴更新我的开发情况和openteams的最新进展，欢迎感兴趣的佬友们关注~
下一期文章我想分享我对workflow工作流模式的设计思考。
