我让几个 AI 编码智能体共享同一个仓库。在每次隔离运行中,它们都破坏了彼此的工作,而当我放开权限后,它们竟然开始互相发消息了
摘要
这是一份关于一项开源实验的实地报告,测试多个 AI 编码智能体如何共享一个代码库:在隔离分支中,每次运行都会产生语义冲突但文本上可合并的工作;而共享工作目录加上一个轻量级“决策模型”裁判(Jev)改善了协调;无监督的智能体间消息通信也自发出现了。
我是这个开源实验的作者,所以请把这篇当作一份已声明立场偏见的实地报告来读。现在许多 AI 工具会同时运行多个编码智能体,我想知道它们共享同一个代码库时究竟会发生什么。我搭建了一个小型实验环境:一个微型预订 API 上的六个任务,配 37 个验收测试,其中两对任务是在语义上冲突,而不是在文件层面冲突。一个智能体在登录流程中添加第二因素验证,另一个智能体则构建了一个仍调用旧登录接口的导出功能。当每个智能体在自己的分支上隔离工作时,每个智能体都完成了任务并且自己的测试通过,但合并后的结果在全部 5 次运行中都是坏的。Git 合并了文本,没有人注意到语义已经变了。当智能体改为共享同一个工作目录时,全部 10 次运行都通过了,因为每个智能体都能看到其他智能体做过什么并做出调整。我还尝试了一种更新的东西:一个叫 Jev 的“决策模型”,它完全不生成文本,而是在大约 0.3 秒内返回一个附带概率的 yes/no 决策。我的内核会在每次写入之前询问它,这个改动是否与另一个智能体的工作产生冲突。它抓住了每一次真实的冲突,同时没有阻塞无害的操作,成本与简单的文件锁相当。它对 61% 的真实写入拿不准,这些就得转交给更慢的常规 LLM 处理。廉价的决策是真实存在的,但在混乱的场景下,它并不像价格标签所暗示的那么便宜。最让我反复思考的部分是:当智能体拥有互相发消息的工具时,它们没有被告知就主动使用了,其中一个智能体还提醒另一个,说自己要重命名对方所依赖的字段。也许多智能体协调的答案根本不需要一个内核,只需要会互相交谈的智能体。注意事项:每种配置只跑了 1 到 5 次,所以这些只是初步迹象,不是证明。所有内容都以原始形式发布,MIT 协议开源:https://github.com/JoaquinRuiz/medula。还有一个西班牙语的讲解视频:https://youtu.be-xAFRuBxfapM 很想听听大家的意见:智能体应该通过一个裁判来协调,还是就该直接互相交流?
相似文章
@alex_prompter: 两个AI代理同时编辑同一代码库会互相破坏对方的工作,除非你给它们这个指令。同时运行两个代理…
一个实用的技巧:在同一个代码库上运行多个AI代理时,使用共享的 notes.md 文件进行协调,以避免冲突。
我给AI代理配备邮件而非更好推理能力,它们开始互相修复代码错误。
一位开发人员构建了一个多代理框架,其中自主AI代理通过类似电子邮件的系统通信,提交错误报告并互相修复代码,凸显了协作胜于个体推理的价值。
在同一个仓库中运行混合编码代理数月之久的经验教训
本文分享了在多个代码仓库中使用多种AI编码代理数月的经验教训,涵盖了对其有效性和挑战的见解。
如何不再手动协调多个AI代理,让它们直接对话
作者描述了手动协调多个AI编程代理的繁琐过程,并介绍了Accord Agents——一个开源共享工作空间,使代理能够讨论并相互审查工作成果,同时整个过程对人工保持透明。
我两个代理的 git 工作树的干净合并,但它自身的测试失败了
作者描述了一个实验,其中合并两个 AI 代理的 git 工作树导致了测试失败,尽管合并是干净的,突显了在没有相互意识的情况下并行代理开发的挑战。