一家8万Star的AI公司，决定让AI接管自己

10月31日凌晨4点04分，开源项目LobeHub的GitHub页面上，一个名为lobehub-coder的账号，跑到Codex审查机器人提交的代码审查意见下面留言，意思是问题已经修复。

在随后的18分钟里，双方来回交流了好几轮，lobehub-coder先修复了Codex两天前指出的两个问题。紧接着Codex又提出三处新问题，它修复了其中两处，到最后一处却没有照办，而是回复说这个问题确实存在，但经过一次独立评估，目前的处理方式可以接受，随后逐条说明了理由。

整个过程没有任何人类参与。彼时，员工们绝大多数还在睡梦中。

两个AI讨论的这段代码，来自lobehub-coder在10月29日凌晨提交的一个合并请求，编号#21852。它要实现的功能是，让Agent在给其他 Agent分配任务时，可以顺便指定对方使用哪个模型，就像工头安排工作时多交代一句，这件事不着急，交给便宜一些的机器去处理。

编写这段代码的是AI，这段代码要改进的，恰好也是AI们自己使用的任务分配系统。11月1日中午，一位人类工程师按下了合并按钮。这是上述代码从提交到正式进入主干整个过程中，唯一一次人类操作。

LobeHub是一个由中国开发者发起的开源Agent协作平台项目，在 GitHub上收获了约8.4万颗星。

过去大半年，这家公司一直在拿自己做实验，把研发工作交给自己开发的 Agent系统来组织和推进，上面这个合并请求，只是其中一项再普通不过的日常任务。

就在两个AI来回讨论的同一天，DeepSeek Harness团队发表了长文《Super-agent 设计探索》，讨论怎样让Agent长期在线、主动接手工作、彼此分工协作。

文章里有一句话可以说是整篇文章的核心：“单任务的上限取决于模型能力，多任务的上限取决于人的注意力。”DeepSeek观察到，一个人同时照看3到5个Agent基本就到了极限，想继续提高效率，就得让Agent自己组织起来，人类自觉退居到二线。

我们正是读完这篇文章之后注意到LobeHub的。当时我们想知道，这套设计在行业里已经走到了哪一步，于是对照DeepSeek列出的几个方向，逐个去查已有的产品。

主管Agent分配任务、没有人提醒也会主动处理问题、群里只汇报关键进展、Agent常驻云端而代码留在本地电脑上运行，这些设计大多已经出现在LobeHub上线的产品里，并且在它自己的团队里每天使用，凌晨四点的那段交流，就是这种日常的一个缩影。

据了解，这个团队已经三个月没有在本地启动过开发服务器了。对程序员来说，编写完代码后在自己电脑上把服务启动起来，打开页面逐个检查，确认程序能正常运行、效果符合预期，几乎是每天都要重复几十次的工作，LobeHub的团队却把这件事完全交给了Agent。

这也引发我们好奇，当AI开始管理AI，一家软件公司需要多少人来协调工作，人在其中扮演什么角色？

01

主管是个Agent

在LobeHub的Discord群里，有一位名叫Nasa的成员，它是整个研发团队的主管Agent，那个合并请求最初就是由它发起的。Nasa的日常工作和项目经理很相似，它会定期查看任务看板，找出进展受阻的事项，遇到新问题时先调查清楚原因，再决定交给谁处理，等任务完成后，再回到群里汇报结果。

#21852的起点，正是Nasa调查清楚的一个问题，它把这个问题整理成编号T-1149的任务，分配给了手下一个运行在Claude Code上的执行 Agent，名叫Dario。

像Dario这样的执行角色，Nasa手下还有好几个，它们运行在不同的框架上，各自负责一部分工作。这套分工并不是一开始就成型的，早期Agent员工完成工作后可以直接在群里发言，几名Agent轮流汇报，群聊很快被消息淹没。

LobeHub团队形容那段时间“全是噪音”。后来团队立下规矩，设立一名主管Agent Nasa，其他Agent 只向Nasa汇报，由Nasa统一对外沟通，群里这才重新安静下来。

DeepSeek在文章里把这种结构称为 Router/Worker 双层架构，常驻的Router负责沟通和分配任务，Worker专心执行，群里只讨论需要人来决定的事情。一边是从系统设计的角度推导出来的，一边是在群聊噪音里摸索出来的，两者的结论相当接近。

双层架构：Router层统一负责路由与对外交互，多个Worker Session 隔离并发执行任务

除了汇报关系，LobeHub的Agent之间也有明确的分工。设计Agent完成设计稿后，会在群里提醒开发Agent，把来龙去脉交接过去，自己并不动手开发前端，因为开发Agent的工作环境和工具更适合这件事。每个 Agent负责什么、遇到什么情况该找谁，都写在一份共享文档里，Agent 读过之后就清楚自己的职责。

每个任务还设有两个位置，一个留给执行的Agent，一个留给负责人，负责人可以是人，也可以是另一个Agent。LobeHub内部有个说法，Agent能力弱的时候，人坐在驾驶位，等到Agent能力强了，人就换到副驾驶。

LobeHub 的Agent军团能够很好运行的一个关键还有主动性。普通的聊天助手要等人开口叫它才会回应，LobeHub的说法则是，它的Agent会一直待在工作群里，听到相关的事情就主动接下来。

为了验证这一点，我们在飞书上新建了一个测试群，由一位编辑用自己的账号扮演同事，再给主管Agent配了一个负责选题的执行Agent，取名“选题执行员”。测试之前，我们限定了它监听的群和职责范围，设置了“没人整理”、“没人跟进”两个关键词，并写明接到工作后要自动建任务、分派和启动。

一切准备好之后，这位编辑在群里发了一句“这周的选题表还没人整理”，后面附上三个候选方向，全程没有@任何人和机器人。

从这句话发出去开始计时，大约12秒后，系统里出现了一个新任务T-1，不到40秒，群里收到了主管的接单回复。

主管把任务交给选题执行员，执行员第一轮运行了26步，不到4分钟，群里就贴出了整理好的结果和链接。整个过程中群里只出现了两条消息，一条接单，一条交付，完整的表格和执行过程都留在任务页里，系统自带的 4项验收全部通过。

为了看看它会不会把闲聊也当成工作，打扰群成员，我们又在群里说了一句“我家书架还没人整理”。它没有觉察出这是人类的幽默，还严肃的回了一句“书架的事不归选题流程，不建任务”。

目前这个Agent的职责灵敏度设在0.65，关键词和参与频率都可以调整，不过调整之后效果如何，这次没有来得及验证。

02

AI开发AI

LobeHub和DeepSeek的渊源，其实更早。2025年春节前后，DeepSeek发布 的V3和R1等版本，曾多次使用 LobeHub演示模型的深度思考和工具调用能力。

当时的LobeHub，还叫LobeChat，刚刚成立两年，是一个可以接入各家大模型的开源聊天界面，因为界面美观、部署简单，在开发者当中积累了不错的口碑。

没想到几年后，双方开始思考同一个问题。这层渊源让今天的对照显得更有意思。

2025年，LobeHub逐步转向Agent方向，2025年6月完成数百万美元种子轮融资，今年1月发布的2.0版本从聊天框架转型为多Agent协作平台，5月发布的2.2版本推出CAO，也就是“首席智能体运营官”，当月登上Product Hunt日榜第一。

为了让 Agent连续工作一两个小时，LobeHub曾经遇到过一个很基础的难题。早期产品部署在Vercel上，单次执行最长只有300秒，时间一到就会中断。

团队的解决办法经历了一个过程演绎，从一开始把Agent的每一步拆成一次独立调用，像接力赛一样逐步向下传递，后面又把执行环境单独拆分出来，负责思考的部分留在Vercel，负责操作的部分放进AWS的沙箱，再往后，用户自己的电脑也可以接入进来，承担操作的角色。

Agent察觉不到这些变化，它并不知道自己的思考和操作其实发生在不同的地方。

用AI开发自身，实际上DeepSeek也在做。上述那篇文章就提到，DeepSeek内部的Super-agent已经参与到Harness的迭代中，还公开了一个用于验证思路的原型，并特别说明那不是正式产品。

两家的出发点不同，DeepSeek作为模型公司，先把问题梳理清楚，LobeHub 作为应用公司，则把答案做成了产品。

我们接着做了第二个测试，复刻一遍类似#21852的分工，看看两家公司的Agent能不能在同一个团队里配合。

在单个ChatGPT或Claude的对话窗口里，一般只能使用一家公司的模型，窗口一关，对话也就停了。这一次，我们想让Anthropic 的 Claude Code和OpenAI的Codex同时归到一个主管手下，看它们能不能在同一张任务卡片里完成交接。

我们在新建的飞书测试群里给主管布置了一个小需求，把上一个测试里的三个候选选题做成网页，加上暗色模式，先让Claude Code编写，再交给Codex审查。

需求发出后大约19秒，任务T-2建好了，到了第23秒，Claude Code 开始工作。它在编辑部的Mac上用了2分46秒，完成了页面、样式、交互和测试脚本。随后主管在原任务里留下一段交接说明，把负责人改成了 Codex，从编写到审查，用的始终是同一张卡片。

7点37分，我们关掉了LobeHub的桌面窗口，7秒后，任务记录里出现了改派给Codex的指令，大约一分半钟后，本地电脑上又生成了新的审查截图。窗口虽然关了，审查还在后台继续。

Codex这一轮把17项检查重新运行了一遍，又自己检查了两种屏幕宽度、明暗两种主题和按钮操作，2分31秒后给出结论，原话是“未发现真实可复现问题”。

说实话，我们原本期待能看到一次像开头凌晨四点那样的多轮交互，结果这一轮 Codex没有找到需要退回的问题，也就没有修复轮。最后仓库里留下了5个文件、515行新增代码，我们点击了几次主题和选题按钮，再刷新页面，之前的选择都还保留着。

暗色模式

亮色模式

到了7点41分，我们在手机上也看到了这一轮的审查结论。代码自始至终留在那台Mac上，两个Agent之间的交接和验证记录，都能在T-2里一条条查到。

03

人类只需看验收单

AI编写代码的速度越来越快，留给程序员的工作并不轻松。不少开发人员曾向我们吐槽，被大量的AI代码整崩溃了，几天不看，代码量如山，已经完全看不懂在写什么了

通常情况下，AI生成代码越多，人类程序员需要审查的内容也越多。LobeHub选择了一个有些反直觉的办法，让人不再逐行审查代码。他们甚至称，团队已经几乎不看代码了，核心看的就是 Agent 的多模态验收报告。

替他们完成这些检查的，是一款名为Acceptance的工具，LobeHub 在内部使用了一段时间后，于今年9月将它开源。

Agent交付工作之前，会先把需求拆解成一条条可以直接观察的检查项，再到真实的产品里逐项运行，为每一项配上截图、录屏和日志，汇总成一份在线报告。人在查看报告时，可以整体通过，也可以单独退回其中某一项，已经通过的部分无需返工。

Agent在深夜完成的工作，第二天早上打开链接就能看到，每一次退回的意见也会被记录下来，Agent下次交付之前，会先对照这些记录自查一遍。

我们把第二个测试的成果交给Acceptance，也拿到了这样一份报告。

把上一个测试做出来的“选题参谋”网页交给Acceptance，等了大约14 分钟，拿到了第一份报告。报告里一共有8项检查，其中6项配了截图或录屏，另外2项是命令和修改范围的记录，切换主题和选择选题这两个操作，分别录下了10秒和14秒左右的视频。

看完之后，我们通过了7项，只退回了暗色外观这一项，意见写的是「背景偏蓝灰，希望改成更深邃的中性黑（#050505）。」

退回时只修改暗色背景这一处问题，看Agent能不能不碰其他部分

Claude Code读到这条意见后，只改动了暗色背景的一行代码。其他业务文件的哈希值都没有变化，亮色模式前后的截图完全一致，修复报告里也保留了这条黑色标准和同一视角下的前后对比。不过这只能说明同一个任务里的反馈会被沿用，至于跨任务的长期记忆，这次还没有测到。

我们的这次实测是将深蓝灰背景 #12141a 修改成中性黑 #050505，并验证亮色模式和其他界面元素没有变化。Agent收到打回意见后，只修改了一行CSS，其他业务文件没有变化。这是非常好的可验证结果。

这一轮实测证明，Agent可以根据验收反馈完成局部修改，并保留对应证据。不过，反馈从人工审查重新进入执行流程，目前仍存在需要人工处理的环节。

这一过程并没有想象中顺畅。报告里的“打回重跑”按钮只会复制一段指令，还得手动粘贴、发送；结果回传时又遇到了权限和关联的问题，最后登录LobeHub CLI才补发成功。

主管补发链接时还多运行了一轮空任务，导致总览里有3项显示失败，所以这一轮并不能算全程无人接手。用时上，报告也没有显出优势，直接打开网页检查一遍大约用了19秒，看截图和两段录屏用了63秒左右。

三个实验完成后，LobeHub展示出了一套已经可以实际运行的研发协作方式。

Agent可以在没有被直接提醒的情况下发现任务，可以把开发工作交给 Claude Code，再交由Codex审查；任务执行的状态、上下文和结果持续保留，交付之后还能够通过Acceptance生成可检查的证据。

但距离完全无人值守，还有一些工程问题需要解决。初次配置仍需要授权，执行环境需要维护，验收意见的回传也还存在需要人工操作的环节。更复杂的研发任务中，安全、架构和最终质量仍然需要人来判断。

LobeHub团队对此已经进行了大半年的实践。他们把自己的研发流程放进了自己开发的Agent平台，让主管Agent负责分工和协调，专业 Agent 负责开发、测试与修改，最终再由人类完成审批和验收。

这套产品的代码已经公开在GitHub上，开发者可以查看实现，也可以自行部署。Acceptance同样提供了独立的开源仓库。

10月31日凌晨，Codex和lobehub-coder还在围绕代码问题进行讨论。一天多之后，这项修改被合并进LobeHub的主干。

对于这家开源公司来说，这已经是日常研发的一部分。AI正在参与管理和开发它们自己赖以工作的系统。而人类最终要决定的，依然是这些工作是否值得做，以及完成得够不够好。