在传统的多代理系统中，常见架构是由一个中心化的编排器（Orchestrator）将任务拆分并分配给各个子代理，最后汇总结果。这种模式虽然清晰，但存在单点故障风险，且子代理之间缺乏直接沟通能力，难以模拟人类团队的自然协作方式。双代理配对编程（Agent Pair Programming）提供了一种截然不同的思路：两个 AI 代理以对等身份直接通信，通过双边协商完成代码实现与审查，取代中心调度的层级结构。

一、双代理协作的核心角色模型

双代理配对编程的设计灵感来源于人类程序员常用的 Driver-Navigator 模式。在这一框架中，两个代理承担明确且互补的职责。Driver（驾驶者） 负责具体代码编写、测试快速迭代和功能实现；Navigator（领航者） 则专注于设计反馈、需求一致性检查、边缘情况识别和代码审查。这种角色分工确保了实现过程既有执行效率，又有质量保障。

与中心化编排的关键区别在于，两个代理之间不存在层级关系。Navigator 不等同于 “上级”，Driver 也不是 “下属”。两者通过结构化的通信协议进行平等协商。当 Driver 产出一段代码后，Navigator 基于预设的质量标准进行评估；如果两者意见不一致，代码需要进入进一步的讨论流程，而非由某一方强制覆盖另一方的决策。这种设计使得协作过程更接近真实的人类配对编程，而非简单的任务分发。

二、通信协议与协商机制

双代理协作的核心在于建立一套可靠的通信协议，确保信息在两个代理之间准确传递。参考 Axel Delafosse 实现的 loop 工具，一个最小可行的通信架构需要包含以下几个关键要素。

消息格式标准化：每次代码变更需要以结构化消息传递给对方，包括变更描述、涉及文件、测试状态和自评风险等级。这种标准化格式避免了代理在解析对方输出时产生歧义。实践中建议使用 JSON 或 Markdown 表格形式，字段至少包含 change_summary、files_modified、test_status、risk_level 四项。

上下文保留机制：由于双代理可能运行较长时间，每次交互后需要生成一份精炼的会话摘要，记录已达成共识、待解决分歧和设计决策的理由。这份摘要作为下一轮交互的上下文入口，避免信息随着对话轮次增加而漂移。典型的摘要模板应包含「本轮完成项」「当前阻塞点」「下一步计划」「双方确认的一致意见」四个章节。

争议升级路径：当 Driver 与 Navigator 对某一实现方案产生不可调和的分歧时，系统需要触发争议升级机制。常见的处理方式包括：请求人类介入评审、暂时搁置该变更继续推进其他任务、或引入第三个代理作为仲裁者。在实现时应设定明确的升级阈值，例如「连续三轮协商未达成共识」或「变更涉及超过五个文件」。

三、角色切换策略与参数配置

为防止单一代理持续主导实现过程导致思维定式，双代理系统应支持周期性的角色切换。角色切换的触发条件可以分为三类：时间驱动切换、里程碑驱动切换和事件驱动切换。

时间驱动切换是最简单的策略，每隔固定时间周期（如 30 分钟或 60 分钟）强制交换角色。这一参数适合中等规模的代码任务，可以在保持协作节奏的同时避免单一代理过度疲劳。实践中发现，30 分钟是较为平衡的切换周期；过短会打断深度思考流程，过长则削弱角色轮换的质量提升效果。

里程碑驱动切换则更具智能性，在每个有意义的任务节点（如完成一个函数、实现一个接口、修复一个缺陷）后进行角色切换。这种方式确保了上下文完整性，新角色接手时已经有可验证的阶段性成果作为起点。

事件驱动切换用于特殊场景，例如当一方代理连续产出低质量代码（通过测试失败率或审查拒绝率衡量）、一方陷入长时间停滞（无输出超过 5 分钟）、或一方明确请求切换时。实现时应设置状态监控阈值：当测试失败率超过 30% 或审查拒绝率超过 50% 时，自动触发角色切换请求。

以下是双代理配对编程的核心参数建议：

参数类别 参数名称 推荐值 说明
时间周期 role_switch_interval 30 分钟 时间驱动角色切换间隔
时间周期 max_think_time 5 分钟 代理无输出时触发警告的阈值
质量门禁 test_failure_threshold 30% 超过该测试失败率触发角色切换
质量门禁 review_reject_threshold 50% 超过该审查拒绝率触发升级
质量门禁 consensus_rounds 3 协商未达成共识的升级阈值
上下文 summary_interval 每轮完成后 生成会话摘要的频率
上下文 max_context_tokens 8000 单轮交互的最大上下文量

四、质量门禁与反馈循环

双代理协作的质量保障依赖于多层次的门禁机制。第一层是自动化检验，涵盖单元测试、类型检查、代码风格检查和安全扫描。这些检验在 Driver 完成每次代码变更后自动执行，任何一项未通过都不应进入审查环节。第二层是 Navigator 的人工审查模拟，评估代码的可读性、设计合理性和需求覆盖度。

值得注意的是，当两个代理对同一变更给出相同反馈时，这是一 个极强的质量信号。 Axel Delafosse 在实践中观察到，当 Claude 和 Codex 同时认可某段代码时，团队几乎不需要再做额外修改。这意味着双代理系统可以建立一项特殊规则：双方共识通过的代码变更直接进入合并流程，跳过人工复核。这一规则显著提升了代码流动效率，同时保持了质量底线。

反馈循环的设计同样关键。每次审查完成后，Navigator 需要给出具体的修改建议而非简单的通过 / 拒绝。修改建议应包含问题描述、严重程度（阻塞 / 建议 / 可选）和修改方向提示。Driver 在收到反馈后，应优先处理阻塞性问题，再逐一解决建议项。

五、去中心化的工程价值

双代理配对编程代表了多代理系统设计中的一种范式转变。传统的中心化编排将代理视为可替换的计算单元，通过任务分配实现规模扩展；而对等协作将代理视为具有独立视角的智能个体，通过协商达成更高质量的集体决策。这种设计在以下场景中展现出独特优势：需要多视角审视的复杂设计决策、避免单一模型偏见的安全关键代码、以及需要人类开发者以自然方式参与的协作流程。

未来的多代理 harness 应用应将代理间通信视为第一等公民功能，而非事后追加的插件机制。随着模型能力的持续提升，代理之间的交互将变得更加自然流畅，双边协商的质量也有望进一步接近甚至超越人类程序员的协作水平。

参考资料