第 18 章 | 进阶——escalation 与 architect

更新于 2026/5/11
💡 进群学习加 wx: agentupdate
(申请发送: agentupdate)

第 18 章：进阶——escalation 与 architect

学习目标

掌握"卡住自动升级"模式，让多 agent 系统在难题面前不断进化而不是死循环。

核心矛盾

如果只有一个 developer (sonnet) + 死循环阈值（如 3 次失败）：

sonnet 试 1 → 失败
sonnet 试 2 → 失败（同样错误）
sonnet 试 3 → 失败（还是同样错误）
→ 触发阈值，停手
→ 人介入

问题：反复 sonnet 在 same error 上撞墙是浪费。应该在第 3 次时换更强的 agent。

三层升级链

flowchart TB
    Start["组 N 开始"] --> Dev["developer (sonnet)"]
    Dev -->|顺利| Done["✓ APPROVED"]
    Dev -->|失败 3 轮| DeepDev["developer-deep (opus)"]

    DeepDev --> PathA["路径 A: 标记 spec 缺陷
(不写代码)"]
    DeepDev --> PathB["路径 B: 差异化重做
(用结构性不同方案)"]

    PathA --> Arch["architect (opus)"]
    PathB -->|顺利| Done
    PathB -->|还失败| Arch

    Arch --> Stuck["STUCK.md
(诊断 + 3 个 option)"]
    Stuck --> Human["⚠️ 人决策"]

    style Dev fill:#bbdefb
    style DeepDev fill:#ffccbc
    style Arch fill:#e1bee7
    style Done fill:#c8e6c9
    style Human fill:#fff9c4

deep agent 的精髓——不是更强算力，是质疑前提

developer (sonnet) 默认假设:
  "spec 是对的，design 是对的，我把它们实现就行"
   → 在错误的 spec 下反复试 = 永远失败

developer-deep (opus) 应当假设:
  "前两轮都失败，说明 spec/design 可能有缺陷
   我先停下来质疑，再去实现"
   → 找到根因，要么修 spec，要么换方案

这是 deep 的真正价值——不是"更聪明"，是"更敢于质疑"。

路径 A：标记缺陷

deep agent 发现 spec 自相矛盾 / Scenario 不可实现，不硬写代码：

[追加到 review/N.md 末尾]

## Developer Concern (escalated round)

**Suspected Defect:** spec
**Specific Item:** Requirement: 同步策略 / Scenario: Manual step 时间轴
**Conflict:** Scenario 要求"无命令注入"，但 D5 要求"在终端打字"，
            manual step 没命令时打什么？这两条相互矛盾。
**Suggested Resolution:**
- option A: 修 Scenario 加 "manual step 跳过打字阶段"
- option B: 修 D5 把"打字"改成"可选步骤"

→ 然后 stdout 输出：DEVELOPER-DEEP: PATH=A → main Claude 知道 dispatch architect。

路径 B：差异化重做

如果 spec 没问题，是前序方案错了：

前序尝试 1: 用 subprocess.Popen 控终端 → 失败（打字不流畅）
前序尝试 2: 同样 subprocess + sleep 调节 → 失败（race condition）
前序尝试 3: 加 select() polling → 失败（macOS 行为不一致）

deep 看到这些都是"在 subprocess 上打补丁" → 换思路:
PATH=B: 改用 libtmux 的 send_keys + capture_pane
        → 结构性不同方案
        → 不会撞同样的坑

→ stdout 输出 DEVELOPER-DEEP: PATH=B (commit abc123)，正常进入 tester。

architect：兜底诊断

deep 也卡住时，architect 出场。它不写代码——只读全部历史，给诊断 + 3 个可执行 option：

# Stuck: Group 7 — 编排器（同步策略）

**Diagnosed At:** 2026-05-08 14:32
**Failed Agents:** developer (3 rounds) → developer-deep (PATH=A) → tester-deep (PATH=A)
**Root Cause Category:** Spec defect

## Evidence Chain
- Round 1~3 (sonnet): developer 反复在 D5 同步策略上失败
- Round 4 (deep, PATH A): flagged "Scenario manual step 与 D5 矛盾"
- Round 5 (tester-deep, PATH A): 同时 flagged Scenario 不可测

## Root Cause Analysis
spec.md 第 47 行 Scenario "Manual step 时间轴" 要求 "无命令注入"，
但 design.md D5 第 12 行规定 "终端必须打字"。两者直接矛盾。
manual step 是无终端命令的纯讲解步骤，不应该打字。

## Recommended Decisions

### Option A: 修 Scenario
改 spec.md 第 47 行 Scenario 为 "无命令注入，跳过打字阶段"
代价: 极小，只改 1 行
风险: 无

### Option B: 修 D5
改 design.md D5 为 "终端打字仅在有命令时进行"
代价: D5 文字微调
风险: 需要确认所有依赖 D5 的代码不假设"必有打字"

### Option C: 拆 manual step
完全拆 manual step 出 spec，移到独立 capability
代价: 较大重构
风险: 影响其他组

## Recommendation
Option A——最小改动，不影响其他决策。

→ 用户读完这一份就能 30 秒内拍板。这是 architect 的全部价值——省你 30 分钟读失败日志。

死循环阈值（数字打哪)

testFailRound[N] >= 3        → 升 developer-deep
reviewerRound[N] >= 3        → 升 developer-deep
testFailRound[N] >= 5        → 升 architect
reviewerRound[N] >= 3 + deep 已用过 → 升 architect
deep PATH=A                  → 直接升 architect
E2E 失败 >= 3                → 升 architect

数字不要太大（拖时间）也不要太小（频繁打扰）。3/5 是经验值。

通知集成（marker 模式）

每次升级输出一行带 ⚠️ 的 marker：

⚠️ Group 7: escalating to developer-deep (reason: testFailRound=3)
⚠️ Group 7: STUCK — architect diagnosed root cause = Spec defect

Stop hook 监听 ⚠️ 开头的行 → 推送到 Telegram。这套通知设计在 Ch 26 详讲。

反模式

❌ deep 只换模型，不换策略           opus 当 sonnet 用，浪费
❌ deep prompt 写"用更深的推理"      模型不会因这一句改变行为，要明确不同的工作流
❌ architect 也写代码                越界，破坏诊断的独立性
❌ 阈值太高（>10）                   人介入太晚
❌ 阈值太低（=2）                    频繁打断，自治化形同虚设

你现在能做什么

  • 设计自己项目的 escalation 链
  • 写 deep agent 时让它"质疑前提"而不是"再试一次"
  • 设计 architect 的 STUCK.md 模板
  • 选择死循环阈值