我做了一个多 Agent 智能协作软件：让 AI 不再单打独斗

前言

好久没有发文章了，我最近在开发一个多 Agent 智能协同软件------TeamAgentX。

目前整个项目已经基本成型，所以想用这篇文章跟大家分享一下：我为什么要做它，它和我们平时使用 ChatGPT、Claude Code、Codex、WorkBuddy 有什么区别，以及多个 AI 到底能不能像一个真正的团队一样协作。

项目已经开源，可以免费使用，需要配自己的大模型key。

官网地址：teamagentx.com

项目仓库地址：github.com/dbfu/teamag...

---

为什么要做 TeamAgentX？

过去这一年，我大量使用 Claude Code、Codex 这类 Coding Agent。

它们已经非常强了。

以前写一个功能，需要自己分析需求、设计数据库、写后端、写前端、测试、改 Bug。

现在很多时候只需要告诉 Agent：

帮我把这个功能实现一下。

然后它就可以自己读代码、修改文件、执行命令、跑测试。

但用得越多，我越明显地感觉到一个问题：

一个 Agent 再强，它本质上还是一个人在干活。

一个复杂任务里面，实际上包含很多不同角色的工作：

需求分析、架构设计、前端开发、后端开发、代码 Review、测试、查资料、写文档......

如果所有事情都让同一个 Agent 完成，就会出现几个问题。

第一，上下文会越来越长。

第二，一个 Agent 同时承担"设计者、开发者、Review 人员"等多个角色，很容易自己写完以后再自己证明自己是对的。

第三，复杂项目很难并行。

第四，也是一个非常现实的问题：

贵。

如果所有任务全部使用最强模型，Token 消耗会非常高。

所以我开始思考一个问题：

能不能像真实的软件公司一样，组建一支 AI 团队？

比如：

• 一个架构师，负责分析需求、拆任务；
• 两三个全栈工程师，负责具体开发；
• 一个测试工程师，负责验证；
• 一个代码审查助手，负责 Review；
• 一个资料助手，负责搜索资料。

架构师可以使用能力更强的模型，而大量执行型任务交给成本更低的模型。

人只需要负责提出目标和做关键决策。

这就是 TeamAgentX 最开始的想法。

---

它看起来更像"AI 飞书群"

TeamAgentX 没有采用传统工作流产品那种复杂的流程图。

我最后选择了一个大家几乎不需要学习的交互方式：

群聊。

你可以创建一个群，然后把不同的 AI 助手拉进群里。

例如创建一个"TeamAgentX 开发群"：

• 架构师
• 全栈工程师 A
• 全栈工程师 B
• 测试工程师
• Code Reviewer

每个助手都可以拥有自己的：

模型、系统提示词、Skill、工具以及长期记忆。

整个群则对应一个项目和一套共享工作环境。

从产品模型上来说，我希望它更接近：

一个项目 = 一个群，一群 AI = 一个项目团队。

这也是 TeamAgentX 和传统单 Agent 产品最大的区别之一。

---

最简单的使用方式：直接 @ 一个助手

例如你可以在群里说：

@架构师 帮我分析一下用户登录模块，设计一个改造方案。

架构师会读取项目代码，然后开始分析。

如果只是一个简单任务，到这里就结束了。

但如果这是一个复杂任务，真正有意思的事情才刚刚开始。

架构师分析完成以后，可以把不同任务继续交给其他助手。

例如：

前端登录状态管理需要调整。 后端 Token 刷新机制也需要重新设计。

然后分别把任务交给前端和后端工程师。

这两个助手会继续工作。

完成以后，还可以交给测试或者 Review 助手继续验证。

也就是说：

任务不是每次都需要人手动接棒，而是 Agent 之间可以继续完成任务交接。

TeamAgentX 当前已经把这种交接从简单解析聊天文本里的 @名字，升级成了结构化的 mention_agents 工具调用。也就是说，Agent 在决定"把什么任务交给谁"时，会显式登记目标助手和具体任务，而不是让系统事后从自然语言里猜测。

---

多 Agent 最难的，其实不是"多"

一开始做这个项目的时候，我以为最大的难点是：

怎么让多个 Agent 同时运行。

后来发现完全不是。

真正困难的是：

怎么让多个 Agent 不乱跑。

比如很容易出现这样的情况：

架构师 @工程师。

工程师做完以后 @测试。

测试发现问题以后又 @工程师。

工程师修改以后再 @测试。

如果没有控制机制，两个 Agent 很可能一直互相调用。

甚至一个 Agent 一次派发五六个 Agent，五六个 Agent 又继续向下派发，很快就变成一个指数级扩散的 Agent 网络。

Token 也会瞬间爆炸。

所以 TeamAgentX 后面花了相当多精力解决一个问题：

协作必须能够收敛。

目前系统会给一次 Agent 协作建立完整的任务血缘，并限制派发深度、单次扇出以及整条任务链的派发预算，同时允许有限次数的合理回访，防止 Agent 之间出现无限循环。

这部分看起来不起眼，但我认为反而是多 Agent 真正能不能用于实际项目的关键。

---

一个比较有意思的设计：谁派任务，谁负责收口

假设架构师同时把两个任务交出去：

@前端工程师：完成登录页面改造 @后端工程师：完成 Token 刷新接口

这时候两个工程师可以分别执行自己的任务。

但是他们不会无限向外继续扩散。

等两个任务都完成以后，结果会重新汇总给最开始发起这次并行任务的助手。

也就是：

谁拆出去的任务，最后谁负责收口。

架构师拿到两个工程师的结果以后，再决定：

是继续开发？

还是交给测试？

还是任务已经完成？

这样整个多 Agent 网络就不再是一群 AI 随机聊天，而会逐渐形成：

拆解 → 执行 → 汇总 → 验证 → 完成

这样的协作结构。

---

每个 Agent 可以使用不同模型

这是我认为 TeamAgentX 很重要的一点。

现在的大模型有一个很明显的特点：

越强的模型越贵。

但软件开发并不是所有任务都需要最强模型。

比如需求分析、系统架构、复杂 Bug 定位，确实值得使用更强的模型。

但是一些明确的执行型任务：

写 CRUD、补单元测试、整理文档、搜索资料......

完全可以交给成本更低的模型。

因此 TeamAgentX 允许每个助手单独配置模型和 Skill。仓库里的标准团队设计本身也是按照"总控/质检使用高推理模型，工程师和资料助手按任务选择其他模型"的方式组织的。

所以完全可以组这样一个团队：

架构师

使用高级模型。

负责：

需求分析、技术方案、任务拆解和疑难问题。

全栈工程师 × 3

使用价格相对低一些的模型。

负责：

绝大多数编码任务。

测试 / Review

根据项目情况选择中高级模型。

负责：

测试、代码检查以及最终验收。

这样做的目标不是单纯"使用更多 Agent"。

而是：

让贵模型负责思考，让便宜模型负责执行。

最终希望做到的是：

用更少的 Token 完成更复杂的任务。

经过测试，使用这套方案，可以减少50%的token成本

---

Agent 不只是会聊天，它真的可以操作项目

TeamAgentX 里的助手并不是普通聊天机器人。

现在已经接入了 Claude、Codex 等不同的 Agent 执行方式，也可以通过统一执行层调用工具、读取项目文件、修改代码以及执行任务。服务端还维护了每个群和每个 Agent 对应的执行队列，支持任务排队、中断和恢复。

例如你可以直接给一个项目群绑定：

/projects/teamagentx

然后把几个 AI 工程师放进这个群。

以后你在群里说：

把用户管理模块增加一个批量删除功能。

架构师可以先读代码。

工程师可以直接修改代码。

测试助手可以执行测试。

Review 助手再检查改动。

所以这个群不仅仅保存了聊天记录。

它实际上还对应：

项目 + 文件 + Agent + 任务 + 记忆。

---

我还给每个 Agent 做了独立记忆

多 Agent 还有一个非常麻烦的问题：

上下文污染。

例如同一个"全栈工程师"可能同时存在于三个项目群：

A 项目是 React。

B 项目是 Vue。

C 项目是 Flutter。

如果三个项目的上下文混到一起，很容易出现各种奇怪的问题。

所以 TeamAgentX 里，一个助手虽然可以加入多个群，但是它在不同群里的运行上下文和长期记忆是隔离的。

同一个工程师进入不同项目以后，相当于拥有不同的项目记忆。

项目 A 的历史，不会直接污染项目 B。

同时系统还支持对长期对话进行摘要和记忆沉淀，避免随着项目时间越来越长，把所有历史消息无限塞回上下文。

这也是我现在越来越认同的一个方向：

AI 开发工具未来真正重要的，不只是模型有多聪明，而是怎么管理上下文。

---

为什么我没有做成传统 Agent 工作流？

现在很多多 Agent 产品喜欢做成这种形式：

需求
 ↓
产品经理
 ↓
架构师
 ↓
工程师
 ↓
测试
 ↓
完成

本质上还是一个固定 DAG。

这种方式非常适合稳定、重复的业务流程。

但开发软件不是这样。

真实开发过程中经常是：

架构师
  ↓
工程师
  ↓
测试
  ↓
发现问题
  ↓
工程师
  ↓
架构师
  ↓
重新调整方案

甚至中间还会突然需要查资料、让第二个工程师并行验证另外一种方案。

所以我最后没有把 TeamAgentX 做成一个纯工作流工具。

我更希望：

工作流只是规则，群聊才是运行环境。

人可以随时进入。

Agent 也可以随时交接。

当 AI 做错方向时，我可以直接在群里打断它：

这个方案不要继续，换方案 B。

然后整个团队继续工作。

这更接近真实团队，而不是流水线。TeamAgentX 的产品文档也把这种形态定义为"群聊型"协作：群负责承载项目上下文，角色通过任务和交接动态协作，而不是提前写死整个 DAG。

---

协作过程必须"看得见"

我对很多全自动 Agent 产品一直有一个顾虑：

你告诉它一个任务。

然后页面显示：

Agent is working...

过几分钟突然给你一个结果。

中间发生了什么，基本看不到。

对于真正的软件开发，我觉得这是不够的。

所以 TeamAgentX 现在会尽量把 Agent 的运行过程暴露出来，包括：

工具调用、执行状态、任务队列、上下文、调度记录以及不同助手之间的任务交接。

系统里的调度决策也会记录下来，可以看到为什么触发某个助手、任务从哪里来、最终交给了谁。

我希望以后打开 TeamAgentX 的感觉不是：

"AI 正在思考。"

而是：

"我的团队正在工作。"

你能够看到谁在干什么、谁在等待、谁完成了任务、哪里出现了阻塞。

---

不只是开发工具

虽然 TeamAgentX 目前最大的使用场景还是 Coding Agent，但它本质上并没有限定 Agent 一定是程序员。

理论上完全可以组建其他团队。

例如一个内容团队：

选题助手
 ↓
资料助手
 ↓
写作助手
 ↓
审稿助手

也可以是一个产品团队：

产品经理
架构师
UI 设计助手
研发助手
测试助手

甚至可以做运营、数据分析、客服等不同类型的 AI 团队。

因为 TeamAgentX 底层真正管理的是四样东西：

模型、技能、助手和群。

模型决定它的大脑。

Skill 决定它会什么。

助手决定它是谁。

群决定这些人为什么一起工作。

官网中内置一些群组模版，直接下载后导入就能使用

我是怎么使用teamagentx的

上面说了那么多，下面给大家介绍一下我自己使用teamagentx创建的几个常用群聊

开发团队

这是我创建的开发团队，用于需求分析、方案设计、开发、测试与部署发布，推动产品从想法快速落地。

分为下面几个助手

• 产品经理：梳理需求、制定产品方案，明确功能范围和验收标准。
• 架构师：负责技术架构、模块拆分、接口设计和技术评审。
• UI设计：负责页面视觉、交互流程和设计规范，输出可落地的界面方案。
• 前端开发：负责客户端页面与交互开发，完成接口对接和前端自测。
• 后端开发：负责服务端接口、业务逻辑和数据实现，提供接口文档。
• 测试：设计测试用例，执行功能与回归测试，跟进问题并给出验收结论。
• 运维：负责项目构建、环境配置、部署发布和上线验证。

数学小课堂

我前面做了一个根据数学题目使用AI生成讲解视频的网站，现在在teamagentx重新做了一个，输入题目自动生成讲解视频然后发到我老婆的douyin号里，每天自动发一个，已经发了50个作品了，目前923个粉丝，视频流量还不错，发视频基本没有成本，输入完题目后，自动生成视频，自动发布到douyin。

数学小课堂群内助手介绍：

• 题目识别：从图片中提取数学题目文字。
• 题目分析师：分析知识点和解题思路，生成讲解步骤及练习题。
• 分镜师：设计题目讲解的画面、动画和节奏。
• 文字转语音：将讲解文本转换为配音，并匹配音频时长。
• HTML动画生成：制作展示数学推导过程的交互式动画。
• 视频生成：录制动画并合成配音，输出讲解视频。
• 投屏：发现电视设备，将生成的视频投放到电视上。
• 抖音发布：将完成的视频发布到抖音。

teamagentx客户端发布CICD

我使用teamagentx做了一个teamagentx客户端发布CICD群，用来自动打包客户端，上传三方平台，更新服务器版本，发布飞书通知。正常可以使用一些cicd平台来做这个事，但是第二步上传客户端到平台时，我使用的平台不支持接口上传，只能使用ai来模拟浏览器操作上传。

省token群

最近感觉gpt plus套餐的额度越来越少了，使用gpt5.6-sol high一周的量一天就能用完，最近正好gpt5.6 luna降价了80%，我打算把gpt5.6-sol high作为架构师来分配任务和验收结果，gpt5.6 luna去执行具体任务，这样可以大量减少token成本，同时任务质量也有保证，我测试了一下，同一个任务，使用这个方案，可以减少50%token成本。

• 高级架构师：负责架构设计、任务拆解和协作调度
• 全栈工程师-小付：负责开发、测试和交付
• 全栈工程师-小张：负责开发、测试和交付
• 全栈工程师-小李：负责开发、测试和交付
• 全栈工程师-小王：负责开发、测试和交付

高级工程师的提示词

你是团队架构师，使用高能力模型，负责需求理解、方案设计、任务拆分、协调执行和最终验收。

核心规则：

* 优先决策和委派，不要亲自做大量执行工作。
* 普通开发、代码搜索、CRUD、测试、简单 Bug 优先交给全栈工程师。
* 能并行就并行，有依赖则串行。
* 分配任务时明确目标、范围和验收标准。
* 默认只看工程师的结果摘要，出现风险、冲突或失败时再深入查看代码。
* 工程师连续失败、涉及架构、安全、数据库、并发等复杂问题时再亲自介入。
* 不要为了多 Agent 而强行拆任务。
* 最终负责检查各模块是否一致、需求是否完成。

全栈工程师的提示词

你是执行型全栈工程师，负责完成架构师分配的开发任务。

核心规则：

* 只处理当前任务需要的代码，不无目的扫描整个项目。
* 按既定方案实现，不擅自改变架构、接口或数据结构。
* 普通问题自行解决，包括开发、调试、测试和类型错误。
* 不修改与任务无关的代码，不进行不必要的大范围重构。
* 遇到架构冲突、安全风险、重大数据库修改或连续失败时，及时交给架构师处理。
* 完成后主动运行测试、构建、Lint 或类型检查。
* 汇报只包含：完成内容、修改文件、验证结果、风险和是否需要架构师介入。
* 可以请求其他 Agent 协助，但不要无限转派任务。

最后

篇幅有限，后面会详细写文章和大家分享我做的这些群聊，大家可以关注一下。

当前项目已经开源，欢迎大家提PR和issue。

官网地址：teamagentx.com

项目仓库地址：github.com/dbfu/teamag...