8 万 Star 的开源公司，把写代码、派活、查 Bug 全交给了 AI

大多数团队谈 AI 编程，画面还是“一个人对着聊天框，让模型补几段代码”。LobeHub 的做法更彻底：把 AI 直接编进研发组织里，让 Agent 自己接需求、拆任务、派活、写代码，再让另一个 Agent 做代码审查。人不再盯着每一步，只在关键节点做验收。

一分钟速览

• LobeHub 是一个在 GitHub 上拿到约 8 万 Star 的开源项目，主打开源 AI 协作平台。
• 团队从今年 5 月起把 Agent 引入日常研发，让它们参与派任务、写代码、排查 Bug 和代码审查。
• 在一个真实功能任务里，Agent 创建任务、提交 PR，另一个 Agent 审查挑问题，第三个 Agent 修改补测试，最终由人工审阅合并。
• 有研发成员表示，已经整整三个月没有在本地启动过 Dev Server；团队自测中，优化后的 Agent Harness 用 Kimi K3 在 30 道软件工程任务里完成 21 道，超过 Codex 和 Claude Code。

一个 PR 是怎么被三个 Agent 接力做完的

事情的起点很普通：团队想给任务工具和命令行界面加一个功能，让 Agent 在创建任务时可以直接指定使用哪个模型。接到需求后，负责项目协调的 Agent“Nasa”创建了编号 T-1149 的任务，把活派给对应的 Coding Agent。

接下来的过程，和人类开发团队几乎一模一样。Coding Agent 完成功能实现、补充测试、检查运行结果，交出一个正式的 Pull Request。代码刚提交，另一个 AI 同事“Codex”赶来审查，很快挑出几个需要处理的问题；负责修改的“Dario”接到反馈后，转头去改代码、补测试，再把作业交回去。一个写，一个挑错，你来我往打磨了几轮，这份 PR 最终通过人工审阅，合并进 LobeHub 的代码库。

更值得注意的是跨项目协作。当 Agent-foundry 项目需要 lobe-ui 组件库增加自定义中性色支持时，过去少不了两边开发者沟通需求、协调修改、再通知对方更新。现在，一个 Agent 提出需求，另一个 Agent 完成修改；随着 lobe-ui 发布 6.0.1 版本，上游项目收到升级通知，功能顺利接上。人类在两个项目之间来回传话的环节，被 Agent 自己打通了。

“三个月没启动 Dev Server”意味着什么

LobeHub 团队一位研发成员的说法很有冲击力：他已经三个月没有在本地启动过 Dev Server。按照他的体感，采用这套工作方式后，开发效率有明显提升。这个数字没法直接外推到所有团队，但它说明一件事：当 Agent 能接管“改代码—跑测试—看结果”的闭环，开发者的工作重心会从“亲手写”转向“定义问题、验收结果”。

这背后不是单个模型变强，而是 Harness 的设计。LobeHub 把任务系统、Agent 身份、工具权限、代码仓库和审查流程连在一起，让不同角色的 Agent 能在同一套上下文里接力。谁负责拆任务，谁负责实现，谁负责审查，谁有权合并，都有明确分工。人不再需要把同一段背景反复讲给每个模型听。

把同一套系统拿去办编辑部

为了验证这套协作方式换个场景还灵不灵，量子位的编辑用 LobeHub 组了一支“AI 编辑部”：一个主编 Agent Sienna，带着三位分别盯大厂人事、开源项目和大模型动态的小编。主编接到选题需求后，自己拆方向、派人、收稿、汇总。

不到 8 分钟，三位 AI 小编就带着选题和一手信源链接回来交差。Sienna 没有照单全收，而是逐条检查质量；遇到信源模糊、找不到一手报道的选题，它会列出验收清单，等人类批准后再提醒对应 Agent 补查。最后交上来的是一份包含 6 条最新 AI 动态的简报，候选标题、新闻日期、核心事实、推荐理由、信源链接一个不少，还附上了每位小编的任务回执，标出哪些细节需要人工复验。

临时加活也能接住。人类突然追问某位大厂高管的动向，负责该方向的 Agent 没有反问“Tibo 是谁”，而是顺着此前的人事线索继续查，很快把调岗时间和公开动向梳理清楚，甚至给出一个“把这条和最近跳槽到其手下的另一位高管放在一起写”的选题建议。

多智能体落地的难点，不在“聪明”

从 LobeHub 的实践看，多智能体真正难的地方有三个。第一是上下文连续：任务交接时，接手的 Agent 要知道前面做了什么、为什么这么做，否则就会重复劳动或改错方向。第二是权限边界：谁能改代码、谁能合并、谁能调用外部工具，必须清楚，不能让所有 Agent 共用一把“万能钥匙”。第三是验收标准：AI 说“完成了”不算完成，要有测试、有截图、有可复现的结果。

这也解释了为什么“多 Agent”喊了很久，真正跑进生产流程的案例并不多。把几个模型放在群里聊天很容易，让它们围绕一个目标稳定分工、互相审查、对结果负责，才是工程问题。LobeHub 的价值不在于展示了多少个 Agent，而在于它把一套协作协议做成了产品，并且自己先用了起来。

对正在观望的团队，比较稳妥的路径不是一上来就“全自动”，而是从边界清晰、可验证的任务开始：补测试、修 lint、更新依赖、处理重复的 CRUD。等 Agent 在这些任务上稳定交付，再逐步放开到跨模块改动。人保留合并权和发布权，Agent 承担执行和自检，这种分工短期内最现实。