协调责任从智能体转移到执行框架
多智能体编码系统把仓库级工作拆分给多个智能体，但论文指出，交换的信息通常只作为上下文存在：每个智能体都要自行判断某条共享发现是否适用，以及自己的实现是否仍符合约定接口。作者报告说，共享发现可能未被使用，接口偏差可能未被发现，从而削弱协作的可靠性与效率。
工件排他通信协议（AECP）的应对方式是：让结构化工件成为智能体之间唯一的交换通道，并规定执行框架如何处理这些工件。当智能体访问相关代码时，框架提供相应发现；框架会筛查实现是否与记录的接口承诺不符；并要求受影响的智能体重新查看被修订的约定。这些协调步骤成为框架执行的一部分，而不是智能体必须根据先前消息主动发起的动作。
知识工件在使用点交付发现
知识工件由主张、适用作用域、可选的可执行见证以及框架维护的见证状态组成。工作者记录发现时一并记录其适用的代码作用域，框架把这些发现与作用域关联存储。当某个工作者访问匹配的代码时，框架推导出当前作用域，检索与该符号、文件或所属目录关联且未被反驳的工件，并把它们插入到该访问操作返回的观察结果中。
交付有数量和排序限制。每次查找最多交付五个工件，每次转发最多四个，按最新优先，并截断到 280 个字符，因此单次访问最多增加约 1400 个字符。发现会被转发给拥有相关模块的工作者，优先同一文件，其次是依赖图中相连的模块，再次是同一包。在 Opus-4.6 的 NL2Repo AECP 运行中，每个任务平均收到 41.9 次知识交付；由 LLM 根据轨迹判断，36% 的已交付发现被接收方用于后续工作，而经过见证检查的发现占被使用发现的 88%。
见证检查决定哪些发现继续流通
记录时成立的发现，可能随代码或执行环境变化而过时。因此 AECP 在流通前执行所附见证：退出码为零则把工件标记为见证已检查；在标记之后失败则反驳该见证并拒绝发布；在标记之前失败说明环境准备未完成，工件保持未检查状态。没有见证的工件同样保持未检查，并可被检索；每条交付的发现都带有其见证状态，接收方可以区分已检查与未检查的主张。
消费者也可以标记某条已存储的主张，促使框架重新运行见证，并把被反驳的工件排除在后续交付之外，同时保留审计记录。见证执行在进入流通前拒绝了 14% 的发布尝试，消费者平均每个任务标记 0.9 条发现，其中 0.2 条在重新运行见证后被撤回。
契约工件让依赖模块并行推进
契约工件记录某个符号的身份、如何构造或调用它，以及它的返回结构或暴露属性。框架验证契约并生成桩模块，这些桩暴露已声明的符号和签名但不实现行为，因此消费者可以在生产者仍在工作时导入已声明的接口并构建依赖模块。由于桩占据最终模块路径，生产者用实现替换桩后，消费者仍保留相同的导入。
模块提交时，验证器会把它与最新的契约工件比对：把源码解析为抽象语法树，检查已声明的符号、签名、可静态恢复的类型与形状，以及残留桩，而不执行代码。可证明的不匹配会导致提交被拒绝，并报告被违反的符号和约束，使生产者可以修复实现或修订约定。这是集成前针对签名、属性和残留桩不匹配的快速静态筛查，而不是运行时正确性检查。
修订追踪让消费者跟上接口变化
接口可能在消费者仍依赖旧版本时发生变化，而只更新生产者的契约并不能保证这些消费者重新审视自己的假设。AECP 的做法是让消费者在开发期间向框架登记自己依赖的符号，这样当约定被修订时，框架能识别受影响的工作者并要求他们重新查看。
这是框架执行的第三个协调步骤，与提供发现和筛查实现并列。知识工件与契约工件共同把共享发现和接口承诺转化为框架可以据以行动的协调状态，这也是 AECP 把这些工件设为唯一通道的原因：在这些工件之外传递的信息会绕过使协调可检查的框架检查与修订追踪。
实测增益随基线和基准而变化
评估覆盖仓库构建任务，即智能体在空工作区中根据文档或自然语言需求构建仓库，使用 Doc2Repo、NL2Repo 和 CodeProjectEval，并采用包括 Opus-4.8 和 DeepSeek-V4-Flash 在内的闭源与开源模型。跨模型和基准平均，AECP 相比单智能体把测试通过率提升 10.6%，相比使用自由形式消息或集中式集成的智能体团队分别提升 28.2% 和 8.5%，同时相比这些团队把墙钟时间减少 16.5% 和 24.9%。
这些是所测试模型和基准上的平均值，因此增益大小取决于使用哪个基线和哪组基准。论文还指出，简单任务往往更适合较少的智能体，这意味着多智能体的优势并不随任务难度均匀分布。
工件排他通信阻断经由消息的攻击
安全研究考察一个智能体被攻陷后，恶意指令如何在智能体之间传播。工件排他通信阻断了恶意指令的传递，使其到达其他智能体的比例从 95% 降至 0%，使这些智能体据此行动的比例从 40% 降至 0%。
作者指出，AECP 只移除了智能体之间的自由形式消息通道，因此不应把它视为对经由工件或共享代码传递的指令的防御。攻击案例在无网络访问的隔离容器中运行，没有载荷使用网络端点，生成的仓库在评分后被丢弃。
这些结果适用于哪里，到哪里为止
证据限于在空工作区中根据文档或自然语言需求进行仓库构建，覆盖 Doc2Repo、NL2Repo 和 CodeProjectEval 以及所测试的模型。报告的通过率和墙钟时间数字是这些模型与基准上的平均值，并不保证适用于特定仓库、语言或智能体脚手架；论文称 AECP 可迁移到不同智能体脚手架，但未在此单独量化该迁移。
安全结果的范围更窄：它覆盖论文攻击案例中经由消息通道传递的恶意指令，而不包括嵌入工件或共享代码中的指令。由编码智能体（包括 AECP）生成的代码可能包含错误或漏洞，使用前应经过审查。
本文最具决策相关性的区分是任务难度与基线选择：AECP 报告的最大优势出现在对比自由形式智能体间消息时，对比集中式集成的优势较小，而简单任务往往更适合较少的智能体。因此，在权衡多智能体协调时，读者应把工件排他通信视为让协调变得可检查的手段，而不是相对使用更少智能体的普遍胜利。
本文引用的文献
AECP: Artifact-Exclusive Communication Protocol for Multi-Agent Code Generation
在 Doc2Repo、NL2Repo 和 CodeProjectEval 上，相比使用自由形式智能体间消息的智能体团队，AECP 把平均测试通过率提升 28.2%，把平均墙钟时间减少 16.5%，并把到达其他智能体的恶意指令从 95% 降至 0%。