InfoQ公众号文章

全世界只有 5000 人见过的 AI 群控,会把软件公司的差距拉到一百倍

每天几万次合并,背后就是 Karpathy 说的那种 agent 群体。

InfoQ

公众号 · 20 篇文章

图片
作者 | 彭友顺

下面视频是介绍群控差距为什么大的原理

已关注
关注
重播 分享 赞
观看更多
    InfoQ

    0/0

    00:00/01:56
    进度条,百分之0
    00:00
    /
    01:56
    01:56
    全屏

    倍速播放中
    您的浏览器不支持 video 标签

    继续观看

    全世界只有 5000 人见过的 AI 群控,会把软件公司的差距拉到一百倍

    转载
    ,
    全世界只有 5000 人见过的 AI 群控,会把软件公司的差距拉到一百倍
    InfoQ
    已同步到看一看写下你的评论

    下面视频是介绍整篇文章的视频版本

    10 月 11 日,Andrej Karpathy 在 X 上发了条长推,说大家对 AI 的理解正在分层。他画了个漏斗:

    • 大约 60 亿人,很少接触大模型;

    • 10 亿到 20 亿人,偶尔用用免费的聊天机器人,拿它查资料、改文案;

    • 大约 2,000 万人,每天用 AI 写代码、做研究,过去要做几周的项目,现在一句话交给 agent 就能做完;

    • 最顶上,大约 5,000 人,能用到前沿实验室内部的系统。

    最顶上这 5,000 人看到了什么?Karpathy 写道:

    It looks like swarms of thousands of agents collaborating over weeks on software mega projects.

    成千上万个 agent 组成一个群体,连续几周协作,完成超大型的软件项目。

    图片

    听起来像科幻,但 Anthropic 同一个月公开的数字刚好能对上:今年 5 月他们每天合并大约 2,500 个代码改动,到 9 月每天超过 30,000 个。四个月涨了十多倍,原有的版本控制工具扛不住,他们干脆自己重写了一套。

    每天几万次合并,背后就是 Karpathy 说的那种 agent 群体。这些 agent 撒在大量机器上,每个都要拉代码、编译、跑测试。Anthropic 给了个数字:他们每天光是 CI 检出就要大约 2,500 万次,这还没算开发环境、agent 沙箱和研究任务。他们自己的说法是,瓶颈在“为人类规模设计的整套开发基础设施:版本控制、构建和 CI”。

    写代码的四个时代

    拉长看,写代码大概经历四个阶段。

    第一个时代是人工。 程序员一行一行地敲,产出取决于人的手速和精力。

    第二个时代是人工加 AI 助手。 AI 帮忙补全、回答问题,人写得更快了,但主角还是人。Karpathy 自己说,就在一年前,他还在“一个字符一个字符地手敲代码,偶尔按一下 Tab 补全一小段”。

    再往后是 AI 自动化。 人提需求、做验收,一个 agent 把一件事从头做到尾。漏斗里那 2,000 万人,大多在这一层。

    终极形态是 AI 群控。 成千上万个 agent 跑在成百上千台机器上,同时开工,连续干几周。每个 agent 都有自己的工作环境,要编译、要跑测试、要过 CI,这些都是实打实的算力,得靠成片的机器撑着。人管的不再是一行行代码或单个 agent,而是一整片机器组成的系统。这一层,目前只有漏斗顶端那 5,000 人见过。

    图片

    每往上走一层,瓶颈就换个地方。前两层卡在人身上;到了 AI 自动化这层,瓶颈是单个 agent——它一次只能做一件事,活越多,上下文越长,越走越慢;到了群控这层,瓶颈变成了协同:几千个 agent 怎么分工、怎么交接、出问题怎么马上发现。

    这几步,汽车工业一百年前就走完过一遍。

    汽车工业走过的四步

    第一步,手工打造。 二十世纪初,一辆车停在一个工位上,一组技工围着它,从底盘一路装到车身。零件尺寸各有偏差,总装时要靠钳工拿锉刀一点点修到能装上。汽车又慢又贵,是有钱人的玩具。

    第二步,人加机器。 工人用上了机床和电动工具,零件变成标准件。1913 年福特搞出移动装配线,每个工位只做一件事,车在线上往前流。T 型车底盘装配时间从大约 12.5 小时压到 1.5 小时,售价从 850 美元掉到 300 美元以下。人和机器都没换,只是组织方式变了,产量直接翻了一个数量级。

    图片

    1913 年,福特工厂里的装配线。图片来源:Wikimedia Commons,公有领域。

    第三步,自动化。 1961 年,第一台工业机器人 Unimate 进入通用汽车的工厂,接手又热又危险的压铸件搬运。一台机器开始独立完成一个工位的工作。

    第四步,群控。 今天的汽车工厂里有上百上千台机器人,撒在冲压、焊装、涂装、总装几个车间,焊装车间放眼望去全是机械臂,最狠的是能关灯生产的“黑灯工厂”。每台机器人要供电、供气、供料。到这一步,竞争的重心变成了整座工厂的调度系统:每台机器人在干嘛,零件流到哪了,哪个工位刚出问题,怎么让一处故障不波及全局。

    这套调度系统,加上厂房、产线和设备,构成了一门重资产生意。汽车工业后来的赢家,都是能把整座工厂建起来、跑起来的公司。

    汽车工业一百年走过的路,软件行业正在三年内重走。福特把工人组织进流水线,产量翻了十倍;后来把机器人组织进黑灯车间,连人都省了;现在我们把成千上万个 agent 组织进同一条代码主线。机器本身不是瓶颈。工人会造车,机器人会焊接,大模型会写代码,这些都不缺。真正决定产能的,是把它们凑到一起之后怎么协同:谁先谁后,改了文件别人得知道,测试挂了得有人修。

    我们现在站在哪里

    写代码现在正处在第三步和第四步之间。

    不少团队已经开始同时开几个 agent,一般就是一台电脑上开几个终端。这更像车间里多摆了几台机器人,还算第三个时代的延伸。真正的群控,是成百上千台机器、成千上万个 agent,共用一条代码主线、同一套编译和测试设施。

    图片

    规模一旦冲出单台机器,组织方式的问题就会被放大。今天大家管多个 agent 的办法,基本都是从人类团队那里搬过来的,常见三种:

    一个 agent 从头写到尾。 这是第三个时代的做法。活少的时候很顺手,活一多,上下文越积越长,速度越来越慢。

    多个 agent,给共享文件加锁。 谁要改谁先拿锁,改完再放。这里有个和人类团队很不一样的地方:agent 拿着锁的时候,它在思考。程序里的锁一般只占几微秒,agent 拿一次锁要跑好几轮模型调用,几秒到几十秒,其他人只能在门口干等。

    每个 agent 各开一个分支,最后合并。 人类团队最熟这套,人写得慢,几天合一次完全来得及。换成 agent,问题就跟手工时代总装一样:每个零件单独看都合格,装到一起才发现对不上。中途谁改了公共接口,其他 agent 要到最后合并才知道,然后再派人去“锉”。

    第四个时代需要的组织方式,更像工厂的调度系统。我管它叫 agent 群控:所有 agent 共用一条主线,谁做完一块就马上推上去,推上去立刻检验;出了问题,相关 agent 当场收到通知自己修,其他人不停。

    图片

    Anthropic 新控制系统的第一条设计原则就是这个方向:“提交必须便宜、增量、无锁。”他们还把测试从合并之前挪到了合并之后。理由很直接:并发改动确实可能冲突,但 Claude 修冲突的速度,通常比人发现冲突还快。

    我做了一个实验

    光说不够,我做了个实验。让 AI agent 完成 60 个真实编程任务,模型和工具都一样,只换组织方式,每种做法跑 3 轮取中位数。结果:

    图片

    本节两张图里标着“Trellis”的一栏,就是 agent 群控的做法。Trellis 是我为这个实验做的协同层,见文末。

    • 一个 agent 从头写:8 分 52 秒;

    • 5 个 agent 加锁:6 分 24 秒;

    • 5 个 agent 各开分支、最后合并:3 分 52 秒,其中 47 秒花在解决合并冲突上;

    • 5 个 agent 群控(共用主线、做完就放上去):3 分 23 秒。

    这里有两个发现。

    第一个是锁的代价。同样 5 个 agent,加锁以后时间几乎翻倍。我把每次提交的时间点画了出来:加锁时,相邻两次提交最短也隔了 6 秒多,这 6 秒就是一个 agent 拿着锁在思考。只要有一个大家都要改的文件——比如更新日志——5 个 agent 就排起队来。

    第二个是分支的盲区。我又搭了个更接近真实工作的场景:一个 agent 中途改了公共接口,另外几个 agent 同时在写依赖这个接口的代码。

    图片
    • 各开分支:每个分支自己的测试都是绿的,合起来以后,3 轮全部测出问题,事后再派 agent 修,每轮要花 40 秒到 4 分钟;

    • agent 群控,每次提交都检验:接口一改,测试当场报错,相关的 agent 在半分钟到一分钟内自己修好,3 轮全部在运行过程中解决。

    当然,群控也不是万能的。活很少时,一个 agent 最快;任务彼此独立时,各开分支、处理好更新日志合并,速度跟群控差不多。任务越多、依赖越深,群控的优势才越大——就是 Karpathy 说的那种场景:几千个 agent,连续几周,一个超大型项目。

    5 个 agent 加一把锁,时间就接近翻倍。规模到了几千个 agent,组织方式带来的差距只会更大。

    下半场比的是工业化

    我的判断是,AI 写代码还非常早期。大多数人还在第二个时代,一部分进了第三个,第四个时代目前只有那 5,000 人见过。

    现在大家聊 AI,焦点基本都在模型上:谁更聪明,谁跑分更高。这有点像比谁家的机器人更好。但模型会越来越强、越来越普及,最后会像工厂里的机器人一样,谁都能买。

    真正拉开差距的,是模型之外的那套生产体系——而且注定是重资产。

    一块是算力。大家熟悉的是训练和推理模型的算力,群控还缺另一大块:agent 干活用的机器。写完代码要编译、跑测试、过 CI,几千个 agent 同时跑,就要几千个沙箱、成片的构建机和测试机。Anthropic 每天 2,500 万次 CI 检出,就是这部分的一个缩影。

    另一块是群控的调度系统,让撒在这么多机器上的 agent 协同起来。这一层才刚起步。

    图片

    Anthropic 那支 7 个人的团队,5 个月里除了版本控制系统,还做了代码评审、代码搜索、权限系统等五六个配套系统。他们在做的,就是给自己的 agent 建一座工厂。

    这样一座工厂,至少要给 agent 配齐三样东西:一份共享的工作记录,让每个 agent 都知道别人发现了什么、在哪失败过、做过什么决定;每次改动都带清楚的来历——谁做的、为哪个任务、看过哪些文件——系统才能把消息准确送到该知道的 agent 手里;再加一套能直接调用的接口,让 agent 用程序的方式协作。

    软件公司的终局,是一座工厂

    先讲三件明天就能上手的小事。活多的时候多开几个 agent:60 个任务,5 个 agent 比 1 个快 2.6 倍;但几个小任务,一个 agent 最省事。大家都要改的文件——比如更新日志——在 .gitattributes 里加一行 merge=union,大部分冲突当场消失。尽早合并,每次合并都跑测试,问题出来几秒就被看到,agent 当场修。

    这三件事,是从作坊走向工厂的第一步。再往后看,我有五个判断:

    一是软件产品会越来越像。 大家用同样几家的模型、同样的 agent 工具,一个好点子今天上线,过几天就有功能差不多的版本。功能趋同,界面趋同,连代码都可能出自同一个模型。

    二是软件会从手艺生意变成产能生意,而且是重资产。 产能比三样东西:算力——每个 agent 编译、测试、跑 CI 都要机器;token——决定能同时开多少 agent、让它们连续干多久;协同群控——决定前两样投进去能变成多少产出。前两样花钱就能买,第三样得一点点搭。三样凑齐,就是一座软件工厂。

    三是工厂和作坊的速度会差出十几倍,甚至上百倍。 单台机器上 5 个 agent 已经比 1 个快 2.6 倍;放到上千台机器、上万个 agent 上,我判断差距会拉到十几倍甚至上百倍。速度差十倍,就是对手一个季度做完的产品你一周做完,对手还在验证第一个想法你已经试完了十个。先到的人先拿到用户、数据和反馈,再拿这些继续加速,领先会越滚越大。

    四是未来最值钱的工程师,是能指挥一万个 agent 的人。 写代码的手艺会越来越便宜,把成千上万个 agent 组织成一条产线的能力会越来越贵。

    第五,时间是唯一的护城河。 模型人人能用,算力和 token 花钱能买,工厂迟早也会有人建出来。唯独时间,用掉一天就少一天。

    造车从手工打造走到黑灯工厂,用了一百年。写代码从手敲走到 AI 群控,可能只要三五年。

    这三五年里,有人还在比谁的模型分数更高,有人已经开始建工厂。等黑灯工厂里上万个 agent 日夜转起来的时候,差距早就拉开了。

    时间不等人。

    附:我做的一个 demo

    为了验证这个场景,我参考 Anthropic 公开的设计思路,用 Rust 写了一个简单的 demo:一个 agent 群控的协同层,名字叫 Trellis(英文意思是园艺用的“藤架”,让很多枝条沿着同一个架子生长)。

    • agent 在各自的工作区里修改,做完就提交到共用的主线上,由服务端自动合并,整个过程只在移动主线指针的一瞬间做一次原子操作,几毫秒完成;

    • 系统记录每个 agent 读过哪些文件,一旦这些文件被别人修改,就通知它,由它自己判断是否跟进;

    • 每次提交后自动跑测试,失败时自动生成修复任务,空闲的 agent 可以领走;

    • Claude Code、Codex 等 agent 通过命令行或 MCP 即可接入。

    它目前还是一条“试验线”。服务端可以监听网络地址,各台机器上的 agent 都能连到同一个服务;文中的实验在单台机器上完成,最多 5 个 agent,算小规模验证。提交后的测试目前在服务端这一台机器上跑,把编译和 CI 分发到多台机器是下一步。借鉴的是 Anthropic 公开的设计思路,希望能帮助大家。

    代码、设计文档、实验脚本和每一次运行的完整记录都已开源:https://github.com/askuy/multi-agent-collaborate

    作者:彭友顺,微信(yoyolovem)

    文献:

    https://www.anthropic.com/engineering/redesigning-source-control

    https://x.com/karpathy/status/2109361546505966046

    今日好文推荐

    PostgreSQL 19 发不出来?AI“找茬”太快,人类修Bug的速度跟不上了

    PingCAP 遭大规模数据泄露!黑客声称窃取 10.6TB 数据,涉及 18 万条组织记录

    代码迁移准确率从 5.4% 飙至 97.9%!OpenAI 挑战 COBOL,几十年的老系统真能交给 AI 了?

    刚刚,DeepSeek开源最新推理框架:单集群日吞吐155万亿Token,KVCache可保存7天

    图片

    前往微信阅读全文

    内容来自公众号,可前往微信查看原文。

    查看作者的更多文章 →订阅更新、RSS 与阅读指南 →