第 31 章 控制谱系：从自动补全到完全自主的滑动条

自主性不是一个开关，是一个谱系

第七部分讲完了多智能体怎么规模化。第八部分进入最后一段："与人协作与产品化"，落地最后一公里。

先从最实际的问题说起：Agent 该有多自主？ 答案不是"全自主"或"全手动"，而是一个谱系。从最简单的代码补全，到完全独立干活的后台 Agent，中间有好几档。一刀切的自主任谁都不满意：新手想要更多辅助，老手想要更多控制；简单任务想直接干，复杂任务想看着点。

这一章讲三个模式，覆盖"控制谱系"的完整设计：

1. Spectrum of Control（控制谱系）：设计多档自主性，用户能平滑切换。
2. Seamless Background-to-Foreground Handoff（后台转前台交接）：后台干 90%，前台补 10%。
3. Signal-Driven Agent Activation（信号驱动激活）：Agent 不用人催，看信号自己激活。

模式一：控制谱系（Spectrum of Control / Blended Initiative）

问题

编码这类任务的 AI Agent 可以提供从简单补全到复杂多步操作的各种协助水平。对 Agent 自主性一刀切，满足不了用户的多样需求，也适应不了任务的复杂度差异。 用户需要在"直接控制"和"把任务交给 Agent"之间流畅切换。

方案

把人和 Agent 的交互设计成一个控制谱系，让用户按当前任务或对代码库的熟悉程度，选择合适的 Agent 自主性水平。提供多个交互模式或特性：

• 低自主（高人工控制）：简单行内辅助，比如代码的 Tab 补全。主要是人在驱动，AI 增强输入。
• 中自主：对更受限任务的辅助，比如按特定指令编辑选中的代码区域或整个文件（"Command K"功能）。人定义范围和顶层目标。
• 高自主：Agent 接手更大、跨文件的任务或复杂重构，可能多步，每步的人直接指导更少（"Agent"功能）。
• 极高自主（异步）：后台 Agent 独立接手整个复杂任务，比如实现一个功能或修一批 bug 并创建 pull request。

用户按需在模式间顺畅切换，这就是"混合主动性"（blended initiative）：人和 AI 都有效贡献。

人工控制: Tab 补全
共享控制: Command K - 编辑区域/文件
Agent 控制: Agent 功能 - 多文件编辑
自主 Agent: 后台 Agent - 整个 PR
（四档可来回切换，不是单向递进）

证据

• 证据等级：高（high），来自 Aman Sanger（Cursor）。
• 学术根基深厚：Sheridan-Verplank（1978）建立自动化水平（LOA）；Parasuraman 等人（2000）提出被广泛引用的 4 阶段模型；各大 AI 编码工具普遍采用相似的 4-5 档谱系。
• 未验证：最优控制水平选择启发式的纵向研究。

怎么用

• 人和 Agent 在交接中共享工作所有权时用。
• 从清晰的交互契约开始：审批、覆盖、升级。
• 用结构化形式捕获用户反馈，提示词和工作流才能改进。
• 实现模式切换控件（快捷键、UI 开关）做显式的自主性水平选择。
• 高自主级别的高风险操作，配人在回路审批（第 21 章）。

取舍

• 好处：人机交接更清晰；通过渐进自主建立信任；低级别能遏制错误；按场景选合适控制水平。
• 代价：多种模式呈现不清楚会困惑用户；要建设和维护多条交互路径；用户可能难选合适的自主性水平。

模式二：后台转前台交接（Seamless Background-to-Foreground Handoff）

问题

后台 Agent 能自主处理长时复杂任务，但可能达不到 100% 正确，或没有完全匹配用户细微的意图。如果 Agent 在后台完成了任务的 90%，剩下 10% 需要人的巧劲，那么一个笨拙的交接过程会抵消自动化的好处。

方案

设计 Agent 系统，让后台（自主）工作到前台（人在回路或人直接控制）工作无缝转换。 即：

1. 后台 Agent 完成任务（比如生成 PR）。
2. 用户审查 Agent 的工作。
3. 工作不完全满意时（比如 90% 正确），用户能轻松"接管"或把任务带进自己的活跃前台环境。
4. 用户用前台的同款（或相关）交互 AI 工具和直接编辑能力，精化、纠正、完成任务的剩余部分。
5. 后台 Agent 工作的上下文应该可用来支持前台交互。

无缝交接的核心机制：

• 上下文保留：后台 Agent 生成提炼的摘要和产物（PR、分支、决策日志），而不是转移完整对话历史，达到 10:1 到 100:1 的上下文压缩。
• 实时进度可见性：WebSocket 流式推送 Agent 进度，让用户识别最佳交接时机，自主执行期间保持信任。
• 基于产物的协调：Git 工作流，分支对任务、草稿 PR，提供能跨越进程边界存活的持久交接点。
• 工具对等：后台 Agent 用和开发者相同的工具（IDE 终端、代码库注释），保证工作区原生执行，消灭上下文转换。

用户: 后台重构 X → 后台 Agent 干活 → 提 PR
用户审查 PR → 90% 正确 → 用户接管精化 → 用前台工具/IDE 完成 → 最终 PR
         → 100% 正确 → 直接到最终 PR

证据

• 证据等级：新兴（emerging），来自 Aman Sanger（Cursor）。
• 学术基础：Allen & Guinn（2000）混合主动系统综述；Zou 等人（2025）的综述验证人在回路是比完全自主更主流的范式。

怎么用

• 人和 Agent 在交接中共享工作所有权时用。
• 从清晰的交互契约开始：审批、覆盖、升级。
• 用结构化形式捕获用户反馈，提示词和工作流才能改进。

取舍

• 好处：人机交接更清晰、运维信任更好；90% 自动化 + 保留 10% 人的专业判断；任务需要细微判断时比纯自主好。
• 代价：要显式的流程设计和协调；交接边界的上下文保留加实现复杂度；要实时进度可见性基础设施。

模式三：信号驱动激活（Signal-Driven Agent Activation）

问题

大多数 Agent 工作流是命令驱动的：用户输入提示词，Agent 行动。这造成瓶颈，Agent 只在有人叫它时才干活。

在销售、安全、DevOps、金融这些领域，行动的时机由外部信号决定（潜在客户访问定价页、CVE 公布、部署失败、股价触及阈值）。等人注意到再提示 Agent，窗口往往已经关了。

轮询仪表盘或靠人工分流扩不了规模。Agent 需要一个机制盯信号，条件满足时自我激活。

方案

把 Agent 激活和用户命令解耦，在外部数据源和 Agent 工作流之间加一个信号层。

三个组件：

1. 信号收集器（Signal Collector）

后台进程监控外部源，发出结构化事件：

# 通用信号收集器，输出 JSON 事件
$ signal-watch --source webhook --filter "event=page_visit AND page=/pricing" \
  | jq '{type: "intent", source: "web", entity: .visitor_id, score: .engagement}'

{"type":"intent","source":"web","entity":"acme-corp","score":82}

信号源可以是 webhook、RSS 订阅、API 轮询、日志尾随、或消息队列。收集器把它们归一化成公共事件 schema。

2. 激活规则（Activation Rules）

声明式规则集，把信号映射到工作流：

rules:
  - signal: intent
    condition: "score >= 70"
    action: enrich-and-engage
    cooldown: 24h

  - signal: anomaly
    condition: "severity == 'critical'"
    action: investigate-and-alert
    cooldown: 0

  - signal: drift
    condition: "delta > 0.05"
    action: retrain-pipeline
    cooldown: 7d

规则带冷却期（防止同一实体重复激活）和条件过滤（设激活阈值）。

3. 工作流派发（Workflow Dispatch）

规则触发时，Agent 收到信号载荷当上下文，执行预定义工作流：

# Agent 收到信号上下文，自主行动
$ agent run enrich-and-engage \
    --context '{"entity":"acme-corp","score":82,"source":"web"}' \
    --output json

{"status":"completed","actions_taken":["enriched_profile","sent_email"],"entity":"acme-corp"}

Agent 在工作流范围内完全自主，但不能超出它，激活规则就是护栏。

外部源 → 信号收集器 → 激活规则 → Agent 工作流

证据

• 证据等级：新兴（emerging）。
• 事件驱动架构在分布式系统里早已成熟（AWS EventBridge、Kafka），这个模式把同一原则用到 Agent 激活。
• 安全编排（SOAR）平台（Splunk SOAR、Palo Alto XSOAR）用信号驱动 playbook 激活当核心机制。
• 销售互动平台用意图信号（6sense、Bombora）触发自动序列，在生产里验证了"信号到动作"的流水线。

怎么用

从一个信号源和一个工作流开始。 示例用例：

• DevOps：监控部署日志 → 检测异常 → 触发回滚调查。
• 安全：盯 CVE 订阅 → 匹配依赖列表 → 开修复 PR。
• 销售：跟踪意图信号 → 丰富匹配的账户 → 发起外联。
• 金融：监控价格流 → 检测阈值穿越 → 执行对冲策略。

前置条件： CLI 优先的技能集（见第 12 章）；至少一个结构化信号源；每种信号类型定义激活阈值。

关键考虑：

• 从高置信度信号（低误报率）开始建立信任。
• 记录每次激活和信号上下文，供审计。
• 冷却期一开始设保守，验证后再收紧。
• 实现一个总开关，能暂停所有信号驱动激活。

取舍

• 好处：Agent 在正确时机行动，不需要人工分流；扩到人海战术盯不过来的信号量；可组合，新信号源和工作流独立接入；可审计，每个动作都能追溯到具体信号事件。
• 代价：误报触发不必要的工作流（噪音信号浪费资源）；前期要投信号归一化；调试链（信号 → 规则 → 工作流）比调试直接命令难；冷却期和限流没执行好有失控激活的风险；冷启动问题，规则要先调才能用。

三个模式怎么选

场景	推荐模式
用户要在直接控制和委托之间切换	控制谱系
后台干 90%，剩下要人精修	后台转前台交接
Agent 要盯外部信号自己激活	信号驱动激活

三个模式是人机协作的三个维度：控制谱系决定"用户能在哪些自主级别之间滑动"，后台转前台解决"自主干活和人精修怎么顺畅衔接"，信号驱动让 Agent 在没人催时也能在正确时机启动。谱系管交互、交接管边界、信号管时机，三个配上，人机协作才顺。

实践清单

• 设计 4-5 档自主谱系：补全 / 区域编辑 / 多文件 / 后台整个任务
• 模式切换做显式控件（快捷键、UI 开关），别让用户猜
• 高自主 + 高风险操作，配人在回路审批
• 后台 Agent 生成提炼摘要和产物（PR/分支/决策日志），10:1 到 100:1 压缩，别传完整对话历史
• 实时进度可见性（WebSocket 流式），用户能挑交接时机
• 后台和前台用同一套工具（IDE 终端、代码库注释），消灭上下文转换
• 外部信号驱动激活：信号收集器归一化成公共 schema + 声明式规则 + 冷却期
• 激活规则当护栏，Agent 在规则范围内自主、不能越界
• 记录每次激活和信号上下文，从高置信信号开始，配总开关

本章小结

• 控制谱系：补全到整个 PR 的多档自主性，用户顺畅切换，混合主动性。
• 后台转前台交接：后台 90% + 前台 10%，上下文压缩保留、实时可见、工具对等。
• 信号驱动激活：信号收集器 + 激活规则 + 工作流派发，Agent 在正确时机自我激活。
• 人机协作的设计目标：想自己干就自己干，想交出去就交出去，衔接不卡壳。

下一章也是全书的最后一章：团队与产品。团队共享配置、工厂而非助手、面向 Agent 的代码库优化、需求发现。