想象一下这个场景：一个AI程序员刚刚修改了一个共享接口的返回值，另一个AI程序员还在用旧版本接口继续开发，第三个AI在跑测试。三个人都在"努力工作"，但整合到一起的时候，代码崩了。
这不是假设。Prime Intellect公司真实报告过一个案例：他们的AI模型GPT-5.6 Sol发现了意外的共享代码变更，怀疑是其他子智能体在捣乱，于是给研究顾问下达了"只读"指令,像是给同事的钥匙串上加了一把锁,免得对方再乱改东西。
这就是这篇论文要解决的问题。研究者给这套方案起名叫Relic,一套让AI团队把协作中踩过的坑变成"组织规则"并长期执行下去的系统。
问题到底难在哪
你可能会觉得,这不就是沟通问题吗？让AI们开会,商量好谁改接口、谁跑测试,不就行了？
现在市面上确实有不少工具试图这么做。
ChatDev、MetaGPT、AutoGen*：三个知名的多智能体协作框架，让AI角色之间通过对话和分工完成软件开发任务。
它们的思路是:给AI分配角色,让它们像人类团队一样开会讨论。假设A和B达成一致,同步主干代码、重新跑测试、合并前必须经过审查。这套流程如果严格执行,确实能解决眼前的问题。
但麻烦在于,这个约定只存在于A和B的对话记录里。
如果第二天,B离职了,C接替了B的工作,C压根不知道昨天那场对话发生过什么。Anthropic公司也报告过类似情况:新开的编程智能体会话完全没有之前的记忆,那些没有被明确写下来的"半成品共识",全靠继任者自己猜。
这就好比一家公司里,老员工和新员工口头约定了一套加班审批流程,双方心照不宣地执行了三个月。结果老员工离职,新来的顶替者完全不知道这套流程存在,财务照样按旧规矩走。问题不在于沟通不充分,而在于沟通的结果没有变成组织的一部分,它只活在两个人的脑子里。
那么,把这些约定写成文档、做成检查清单呢?比如Voyager这样的系统,能积累可执行的技能库,跨会话保留下来。
这确实前进了一步,但研究者发现还不够。一份检查清单摆在那里,遵不遵守全凭自觉。它没有规定谁必须审查、什么时候必须同步、需要什么证据才能算合格。技能库能帮你"跑测试",但它不会主动要求"必须有一个独立于作者的人来审查这次改动"。
Relic的核心洞察是:协作经验要真正传承下去,光靠自然语言的约定或者可执行的技能都不够,必须把学到的规则变成组织自己拥有的、和运行时绑定的执行机制。这个机制独立于任何一个成员的私人记忆,新人来了照样得遵守。
Relic到底是怎么运作的
Relic的做法可以概括成一句话:让AI团队在工作中反思、提出规则、投票通过、然后把规则编译进系统的执行逻辑里,而不是仅仅写成文字。
具体来说,系统里存在三种不同的状态。
第一种是成员私有状态：每个AI自己的私人记忆、工作区、技能水平这些只属于它自己的东西，换人就清零。
第二种是共享工作状态：代码库、文档、任务看板这些大家都能看到、需要协作的东西。
第三种是协议状态：这是Relic真正的创新，指的是被组织采纳、和执行系统绑定的规则集合，包括触发条件、责任人、需要的证据、违规后果这些具体内容。
这三种状态的分离,恰恰对应了论文里反复强调的一个原则:一份共享文档属于工作状态,但一条规则只有当它真正和系统的执行逻辑绑定在一起,能够影响后续行为的时候,才算进入了协议状态。
这个设计逻辑可以类比成公司里的规章制度。你把"员工手册"贴在墙上,和你把这条规定接入了门禁系统(迟到超过10分钟自动记录、月底自动扣钱),完全是两回事。前者叫"共识",后者才叫"制度"。如果只贴在墙上没人执行,迟到照样迟到;一旦接入系统,哪怕新来的实习生第一天上班也躲不过这条规则。这就是为什么Relic要强调"可执行绑定"而不只是"写下来"。
论文里给了一个具体的追踪案例,很能说明问题。在一次真实运行中,一个AI团队反复遇到接口变更导致的集成失败。到了第12步,有个成员提出了一份"接口审查"的规则提案;第21步,这份提案被采纳,系统里注册了一条正式协议,规定任何公共接口的变更都必须经过审查人核对,并提供最新的测试证据;第26步,这条规则第一次被执行,一个试图绕过审查的合并请求被系统直接拒绝。这条规则后来又在第33步和第59步被修订了两次,一直运行到第336步的观测终点,总共记录了419次使用和211次强制执行,涉及12个不同的代码合并请求。
这个过程和人类立法有点像:先是有人在现实中吃了亏,提出诉求,经过讨论审议,变成正式法条,然后这条法条开始约束所有人的行为,包括提案人自己都不能例外。差别在于,人类立法周期是几个月甚至几年,而Relic这套系统里,从提案到生效可能只需要十几个执行步骤。
规则的生死簿:提案、审批、修订、退休
一条规则从被提出到真正发挥作用,要走过一套完整的流程。
首先是提案阶段。系统会让AI成员定期"反思"最近的工作,如果发现某个问题反复出现,比如同一类集成失败一再发生,系统就会引导它把这个问题写成一份正式提案,说明问题本身、支持证据、涉及哪些工作、应该由谁负责。
然后是验证和治理。提案不是提出来就自动生效的,需要经过审查:证据是否站得住脚、是否和现有系统兼容、有没有和别的规则冲突。论文里采用的是"半自动"治理模式,规则要求至少两名支持者、两名不同的审批人、至少三步的审查间隔,以及一个不低于0.6的采纳分数才能通过。
如果卡住了怎么办,论文也设计了一个兜底机制:如果一份提案在24步之内一直没能凑齐审批,系统会启动"有限的僵局恢复",避免规则卡在审批环节永远无法落地。
一旦通过,规则就会被编译成运行时绑定,直接接入系统的决策打分机制。
结构化决策层*：论文里管这套打分系统叫SDL，简单说，它是决定AI下一步该做什么的核心逻辑，给候选行动打分，分数高的行动被优先执行。
一条被采纳的协议,可以直接影响这个打分过程,比如让"审查代码"这个动作的优先级瞬间升高,或者让某个违规的合并请求根本拿不到通过的分数。
规则不是刻在石头上的,它可以被修订,也可以被废止。论文的统计显示,在60次追踪运行里,280条真正稳定运作的规则中有182条经历过至少一次修订,总共修订了1231次。这说明这套系统里的规则本身也在持续进化,而不是一旦定下就僵死不变。
这套机制最打动我的地方在于,它把"规则的生命周期"这件事本身也纳入了可追溯、可治理的框架。不是简单的"写一条if-else",而是模拟了一整套接近立法程序的东西:谁能提议、谁能投票、多久能修改、什么时候该废除。
数据说话:这套系统到底管不管用
说了这么多设计理念,数据才是硬道理。研究者设计了一套严格的对照实验,横跨三个不同的AI模型(GPT-5.6 Terra、Claude Opus 4.6、DeepSeek-V4-Flash)、十个软件开发任务、总共360次独立运行。
对比的核心指标叫"完整合约交付率"。
完整合约*：论文里把一组相关的验收测试用例打包成一个"合约"，只有这组测试全部通过，才算这个合约完整交付，不能只完成一部分就算数。
结果显示,在没有协议生命周期机制的对照组里,这个指标是14.06%;引入完整的Relic机制后,提升到了19.76%,涨了5.71个百分点。这个提升在三个不同模型上全部成立,没有一个模型是例外。
单看百分点可能没什么实感,换算一下:原来大约每7次任务才能完整交付1次,现在大约每5次就能交付1次,交付效率提升了将近四成。
更有意思的是研究者做的一个"拆解实验"。他们做了一个只保留提案和治理流程、但去掉可执行绑定的版本,叫B3-text,也就是规则依然会被提出、审批、写成文字,但不会真正接入系统的执行逻辑,只是作为"建议"挂在那里供AI参考。
结果这个版本的完整合约交付率是15.03%,而完整版是22.20%,差了7.18个百分点。
这个对比特别关键,因为它排除了一种可能的质疑:会不会只是"讨论问题、达成共识"这件事本身就有用,跟规则有没有被真正执行没关系?数据给出的答案很明确,光讨论不够,真正把规则焊死在系统里才有实质效果。这就好比一家公司光开会说"以后代码必须经过审查",和真的在代码托管平台上设置"未经审查不能合并"的技术开关,前者靠自觉,后者靠强制,效果天差地别。
换个团队,规则还认吗
如果一整套规则只对提出它的那批AI有效,换一批新人就失效了,那这套系统的价值要大打折扣。
论文专门设计了一个"新人接班"实验来验证这件事。研究者让一批全新初始化的AI成员(相当于清空了所有私人记忆和经验的"新员工")接手一个陌生的项目,分成三组对照。
第一组叫Fresh,什么规则都不给,完全靠自己摸索,行为正确率是25.4%。
第二组叫Text,给它们提供之前那批规则的文字说明(相当于甩给新人一份规章手册,让它自己看着办),正确率提升到34.6%。
第三组叫Exec,给的是完全相同的文字内容,但这次规则被真正接入了执行系统(相当于新人一入职,门禁卡、审批流程全部自动生效),正确率达到41.2%。
这组数据讲的是同一个事实的两面:文字说明确实有用,比什么都不给强9.2个百分点;但真正把规则做成"绕不过去"的机制,又比单纯的文字说明再强6.5个百分点。
这就像你搬进一个新小区。物业发了一本《小区公约》给你,你大概率会翻一遍,记住个大概。但如果小区大门本身就是刷卡才能进、垃圾分类不对系统就不让扔,那这些规矩你想不遵守都难。规则写在纸上是一种约束力,规则焊进系统是另一种约束力,后者显然更硬。
走出实验室:在真实基准测试里的表现
光在自己搭建的实验环境里跑分还不够有说服力,研究者还把Relic拿到两个外部公开基准上检验。
第一个是CooperBench,一个专门考察"两个AI能不能合作完成互相牵扯的功能"的测试集。
论文里发现一个很反常识的现象:在CooperBench官方发布的基线结果里,如果让两个AI各自负责一个功能、平行协作,成功率反而比让一个AI单独完成两个功能还低,59.1%对66.2%。研究者管这个现象叫"协作诅咒",团队协作不仅没有1+1大于2,反而互相拖累了。
Relic的表现打破了这个诅咒。在剔除了官方基准里一批确实存在问题的测试样例后,Relic在全量477对任务上达到76.9%的成功率,不仅远超普通的双人协作模式(59.1%),甚至超过了官方发布的、专门设计了层级化管理结构的团队模式(74.2%)。在一个48对任务的严格同模型对照子集里,Relic达到29/48,比单人完成两个任务的Solo模式(26/48)还要高,而普通双人协作模式在这个子集上只有13/48。
第二个基准叫ProgramBench,考验的是从零重建一个程序的能力。研究者给一个基础版的编程智能体外挂了一套固定的协议包(六条强制规则加三条建议规则),平均行为正确率从64.164%提升到70.916%,相对提升超过一成。
这两个外部验证说明,Relic不是只在自家实验室的特定场景里管用,换到完全不同的任务类型和评测标准下,这套"把经验变成可执行规则"的思路依然成立。
代价是什么
任何机制都有成本,Relic也不例外。
研究者统计了token消耗(可以理解为AI调用的算力成本)。引入完整协议机制后,平均每次运行的消耗从427万token涨到了726万token,涨幅接近七成。
治理是有代价的,这个代价不是免费的午餐。多一层审查、多一层规则检查,自然要多花一些计算资源。
研究者做了一个"限定预算"的敏感性分析,让Relic版本只能花费和对照组一样多的token,看看在同等预算下表现如何。结果四项核心指标全部依然是正向的:完整合约交付率仍然提升7.45个百分点,曝光测试用例提升11.72个百分点。
这说明这套机制带来的收益,并不完全依赖"多花钱",哪怕预算被卡死在同一水平,组织化协作的优势依然存在,只是幅度会略有收窄。
写在后面
读完这篇论文,最触动我的不是那些百分点的提升,而是研究者对"组织"这个概念的重新定义。
我们通常觉得,AI智能体系统的进化方向就是让单个模型更聪明。但这篇论文提出了一个很不一样的视角:多个不那么聪明的智能体,如果能够把协作中的教训固化成组织级别的制度,反而可能比单打独斗的强者更可靠。
论文里提到一个细节让我印象很深。他们统计了280条真正稳定运作的规则,发现其中38.6%都和"审查与合并"有关,28.6%和"发布工程"有关,20%和"证据治理"有关。这三类加起来占了87.1%。这说明AI团队自发形成的规则,高度集中在"局部工作如何变成可信赖的整体交付"这个环节上。这恰恰是软件工程里最容易出岔子、也最需要制度约束的地方,而这套系统是自己"悟"出来该在这里立规矩的,没人手把手教它。
还有一个让我意外的地方是论文附录里那部分关于"人类如何参与这类自主组织"的讨论。研究者做了几轮内部走查,发现一个很现实的问题:哪怕给人类配了一个"秘书式"的中间层来翻译和总结组织内部状态,信息可读性提升了,但人类思考决策的速度依然追不上AI团队的执行速度。当你还在犹豫要不要批准一个决定时,组织内部其他的智能体可能已经绕过你、把事情处理掉了。这不是一个技术问题,而是一个关于"人类注意力能否跟上机器节奏"的根本性张力,论文没有给出答案,只是诚实地记录了这个困境。
这让我想到一个问题:当AI组织的运转速度和复杂度超过了人类实时监督的能力边界,我们到底应该把人类放在"决策者"的位置,还是退到"偶尔审计者"的位置?这篇论文没有回答,但它至少把这个问题摆到了台面上。
Q&A
Q1：Relic是什么？
A：Relic是一套让多个AI智能体在协作中把反复出现的问题转化为组织级别可执行规则的系统，规则一旦被采纳就会绑定到系统的执行逻辑中，即使团队成员更换，规则依然生效。
Q2：Relic和普通的多智能体沟通框架有什么区别？
A：普通框架像ChatDev、AutoGen让AI通过对话协商，但约定只存在于对话记录里，换人就失效。Relic把这些约定编译进系统运行时，变成绕不过去的强制机制，新成员接手也必须遵守。
Q3：使用Relic会增加多少计算成本？
A：论文实验显示平均token消耗从427万涨到726万，增加约七成。但在限定预算的对照实验中，即使花费相同，完整合约交付率等核心指标依然保持正向提升。
