Relic: 从多智能体协作到持久化组织能力
在组织中,多个 agent 常常发生冲突:一个 coding agent 修改了仓库中的接口,另一个却仍在旧版本上继续开发,导致已有测试失效。一次对话能解决当下的 Episode,但当参与者更换后,是什么让这一教训继续约束团队? 我们提出 Relic,把反复出现的协作失败转化为组织所有、可执行的协议。成员反思可见的工作、提出规则并主导其采纳;被采纳的协议将触发器、责任、所需证据与执行后果绑定到运行时,同时保持可修订与可退役。 在一个被追踪的案例中,反复出现的集成摩擦催生出一条接口评审规则,约束了后续 pull request,并随工作推进被修订。在覆盖 10 个软件工作负载与 3 个模型的 360 次受控运行中,Relic 将 完整契约交付率 从 14.06% 提升至 19.76%(+5.71 个百分点),优于缺少协议生命周期的匹配结构化团队,并在每个模型分层中都改善了全部四个经过验证的生产端点。在新成员迁移下,行为正确率为 25.4%(无继承协议)、34.6%(以可读文本给出相同规则)与 41.2%(可执行绑定),比纯文本高出 +6.5 个百分点。 在完整的 CooperBench 基准上(剔除损坏的基准对后),Relic 达到 367/477(76.9%),为同类结构化系统中已报告的最佳结果;在固定的 48 对同模型子集上,Relic 也超过 Solo(29/48 对 26/48),扭转了官方同类基线所表现出的协调损失。这些结果表明,协作经验可以成为持久的组织状态,并在创造它的成员离开后依然有用。
论文精读
TL;DR Relic 将多智能体协作中的反复失败转化为可执行的组织协议，并绑定运行时触发、责任与后果；它使完整交付率从 14.06% 提升至 19.76%，成员更替时行为正确性比纯文本规则高 6.5 个百分点。
问题
问题背景
多智能体协作系统（如编码代理团队）正被用于自动化软件工程任务，核心挑战在于经验持久化：如何将一次协作中的教训转化为组织能力，而非仅存在于个体记忆。
现有方法局限
现有方法大多依赖单次对话解决冲突或临时规则约束，缺少组织级协议生命周期。例如，一个代理更改接口，另一个代理基于旧版本继续开发，导致测试陈旧；对话虽能解决当前冲突，但参与者更换后，规则无法自动延续。即使将规则以文本形式提供给新成员，其可执行绑定仍缺失：无法在触发器发生时强制要求证据、责任划分与执行后果，也无法随工作推进修订或淘汰。这导致一系列协作失败反复出现，团队无法积累可复用的组织知识。
为什么这个问题难/重要
难在需将隐性协作经验 转化为显式可执行协议，并纳入运行时治理：协议需绑定触发器、职责、必需证据和执行后果，同时保持可修订性。技术上涉及规则表示、采纳治理、运行时集成与多智能体状态管理。业界对多智能体系统抱以厚望，但协调损失和知识流失是规模化落地的关键障碍。
行业类比
类似软件开发中的CI/CD 检查规则：一次集成事故催生一条自动化检查，后续提交自动执行该规则，而 Relic 将这一机制泛化到多智能体组织的所有协作环节。
核心洞察
- Relic 将多智能体协作中的失败经验转化为组织级可执行协议，而非仅靠对话解决。与已有的多智能体反思或记忆机制不同，Relic 的协议直接绑定运行时触发器、职责、所需证据和执行后果，并支持修订与退休，使协作规则成为组织持续改进的载体。这一点从摘要中的接口审查规则案例可以看出：重复集成摩擦催生规则，并随工作继续被修订，体现了组织能力的动态演化而非静态知识库。
- Relic 验证了可执行绑定在知识传承上优于纯文本规则。在新鲜成员转移实验中，行为正确性在无协议时为 25.4%，提供可读文本规则为 34.6%，而可执行绑定达到 41.2%，比文本高出 6.5 个百分点。这揭示了一个工程洞察：将组织知识编码为运行时约束与后果，比仅提供文档更能确保新成员遵循既有流程，因为协议在执行路径上强制约束，而不依赖个体自觉。
- Relic 在完整 CooperBench 基准上取得 367/477 (76.9%) 的最佳结果，并在固定同模型子集上反超 Solo（29/48 vs 26/48），逆转了官方 peer baseline 的协调损失。这表明组织协议生命周期能有效抵消多智能体协作中的协调开销，并将协作经验转化为可量化产出提升。与仅结构化团队但无协议生命周期的 baseline 相比，Relic 的完整契约交付率从 14.06% 提升至 19.76%，+5.71 个百分点，进一步证明持久组织能力的价值。
方法
输入
- 多代理协作的可见工作记录：代码变更、接口修改、拉取请求、测试结果等。
- 反复出现的协作失败事件，例如一个代理更改接口，另一个基于旧版本开发导致测试失效。
关键模块
- 反思与提议：成员基于可视工作记录，识别重复性失败模式，提出具体的规则建议。
- 治理与采纳：组织级协议库（protocol repository）对规则建议进行治理评估，采纳为可执行协议。
- 协议绑定与运行时执行：采纳的协议将触发器（如“创建 PR 前”）、责任（如“接口变更必须审查”）、所需证据（如“全部测试通过”）和执行后果（如“阻止合并或强制回滚”）绑定到运行时，自动执行。
- 修订与退休：协议持续开放，根据后续协作反馈动态修订或退休，保持适应性。
输出
- 组织拥有的持久化可执行协议集合，不再依赖具体成员。
- 协议在后续合作中自动触发，约束代理行为，提升整体交付一致性与质量。
与同类方法的差异：Relic 将协作经验固化为组织级、可执行、有生命周期的协议，而非静态规则文本或个体代理记忆，实现了跨成员、跨任务的持续治理与自我进化。
行业影响
落地场景
Relic 的核心机制是将多智能体协作中的反复失败转化为组织级可执行协议，适用于需要多个 Agent 长期协同、且成员可能变动的复杂任务。例如：
- 软件开发自动化：多个编码 Agent 修改接口、维护测试，协议可约束接口变更必须触发 review 流程。
- 企业级 Agent 工作流：跨部门自动化流程（如订单处理、审批、数据同步）中，Agent 间职责冲突可通过协议固化。
- 多模型参与的推理/决策系统：不同模型 Agent 处理不同子任务时，协议确保输入输出契约一致。
商业价值
- 降低协作损耗：将临时协商转为持久规则，减少重复故障排查，提升任务完成率（实验中完整合同交付从 14.06% 提升至 19.76%）。
- 成员可替换性：协议作为组织资产，新 Agent 加入即可继承，降低 onboarding 成本，行为正确性比仅提供文本规则高 +6.5 个百分点。
- 合规与审计：协议绑定执行证据，便于追踪决策责任，满足企业治理要求。
集成接口
可作为增强层集成到现有 多 Agent 框架（如 LangGraph、AutoGen、CrewAI）中，通过事件钩子捕获 Agent 交互，注入协议触发条件与执行后果。协议本身可与 CI/CD 流水线、版本控制系统打通，支持提案、修订、退休的生命周期管理。无需替换既有 Agent 实现，以 middleware 形式部署。
示例场景：电商订单处理多 Agent 系统（库存、支付、物流）中，协议规定库存扣减必须在支付确认后执行，并记录证据，避免超卖；内容平台多 Agent 推荐与审核冲突时，协议规定以特定置信度阈值触发人工复核，保证一致性。
局限
- 论文实验集中在软件工程任务，如接口变更、持续集成等，协议机制在更广泛的多智能体场景（如机器人协作、科学发现）中的泛化性尚未验证。协议生命周期高度依赖 LLM 的反思与提案质量，在较弱模型上可能无法生成有效规则，导致协议采纳率低或引入错误约束。
- 协议制定和修订要求成员显式反思并提出规则，这会引入额外的推理延迟和计算开销，不适合实时性要求高的协作环境。多个活跃协议之间可能产生冲突或过时，虽然支持修订和退休，但论文未深入探讨协议一致性管理、冲突消解以及大规模协议库的维护成本。
- 与直接注入可读文本规则相比，Relic 需要实现可执行绑定和运行时检查，工程实现复杂度显著更高。此外，CooperBench 基准中排除损坏对的做法可能影响结果公平性，使得报告的 76.9% 准确率在未清洗数据上的表现存疑。