# 设计文档：用管理学治理 AI 的目标偏离

> 目标：在**每个对话**里常设一个独立的"目标评审员（Goal Steward）"，它负责确认任务的终极目标，并判断任务推进过程中是否出现目标偏离；同时**不限制任务的推进**。

本文是这个插件的设计依据。它不是"怎么实现"的说明（那在 [architecture.md](./architecture.md)），而是"为什么这样设计"的论证：每一条规则对应哪一个管理学模型、解决哪一种失败模式。

---

## 1. 问题：AI 的目标偏离有七种形态

在讨论怎么防之前，先要能命名。目标偏离不是一种病，是七种：

| # | 偏离形态 | 表现 | 管理学出处 |
|---|---|---|---|
| 1 | **目标替换** | 手段变成目的。用户要"能设置成功"，AI 优化的是"代码写得多、文档写得全" | Merton《社会理论与社会结构》目标置换（goal displacement） |
| 2 | **范围蔓延** | 需求越加越多，交付边界失守 | 项目管理 scope creep |
| 3 | **过早收敛** | 目标还没确认就开工，做完发现不是要的东西 | 规划谬误、承诺偏误（Kahneman） |
| 4 | **代理指标优化** | 优化可测量的指标，代替真正被要求的结果 | Goodhart 定律 |
| 5 | **约束遗忘** | 多轮之后，用户最早说过的"不要动那个文件""保持简洁"消失了 | 组织记忆衰减 |
| 6 | **承诺升级** | 明知这条路走不通，因为已经投入了上下文/时间而继续加速 | Escalation of commitment (Staw) |
| 7 | **汇报美化** | 把"做过"说成"做成"，把未验证说成已验证 | 委托—代理问题（principal–agent） |

第 7 类尤其重要：它和前面六类不同，它不是"走错路"，而是**掩盖走错路**。审查机制如果只查方向、不查汇报的真实性，会被第 7 类直接绕过。

## 2. 为什么可以借管理学：有限理性的共同前提

用户的前提是"AI 也会产生类人的反应"。这个前提其实和管理学的底层假设是同构的：

- 西蒙（Herbert Simon）的**有限理性**：行动者不是全知的优化器，而是"满意即止（satisficing）"的搜索者，受注意力、记忆、信息通道的约束。
- AI agent 也一样：上下文窗口 = 工作记忆；压缩/截断 = 遗忘；系统提示 = 组织文化；子代理 = 部门分工；token 预算 = 财务约束。
- 于是**组织失控的机制与 AI 失控的机制高度同构**：注意力衰减、局部最优、信息不对称、激励错配、群体思维（对 AI 是"自我确认偏误"）。

所以管理学不是比喻，而是**现成的、经过百年组织实践检验的纠偏工具库**。我们要做的是把其中与"监督—执行"关系有关的部分，移植成 agent 的运行时机制。

## 3. 定盘星：对执行者用 Y 理论，对审查者用 X 理论

这是整个设计最重要的一条判断。

麦格雷戈（Douglas McGregor）的 X 理论假设人不愿负责、必须被监督；Y 理论假设人有自驱力、在合适条件下会自我管理。多数"审查插件"失败的原因是**反过来用**了：

- 对执行者用 X 理论（层层设卡、每步审问）→ 执行者退化成"等指令的机器"，任务推进被拖死；
- 对审查者用 Y 理论（相信它会公正、会克制）→ 审查者变成橡皮图章或噪音源。

本插件反过来：

| 角色 | 假设 | 设计推论 |
|---|---|---|
| 执行者（Lead agent） | **Y 理论** | 给意图不给步骤；方法层完全不干预；被质询时可反驳 |
| 审查者（Reviewer） | **X 理论** | 默认沉默、预算化、冷却期、必须举证、可被申诉、绩效是滞后指标 |

**推论**："不限制任务推进"不是靠审查者的自律，而是靠**架构上剥夺它限制推进的能力**——它没有工具、不能改方法、不能阻塞 L1/L2、每轮最多说话固定次数。

## 4. 治理结构：三权分立 + 三道防线

借公司治理（董事会 / CEO / 独立董事）与 COSO 三道防线模型：

```
            ┌─────────────────────────────┐
            │  董事会：用户（Principal）    │  拥有目标定义权
            │  唯一能改"稳定层"的人          │  只在 L3 升级时被打扰
            └──────────────┬──────────────┘
                   升级通道  │
            ┌──────────────┴──────────────┐
            │  CEO：执行者（Lead agent）    │  拥有执行权与方法选择权
            └──────────────┬──────────────┘
              质询（可反驳） │
            ┌──────────────┴──────────────┐
            │  独立董事：Reviewer           │  只有质询权 + 升级权
            │  无工具、无指挥权、无写权限     │  默认沉默
            └─────────────────────────────┘
```

**三道防线**（COSO 三线模型）：

| 防线 | 谁 | 机制 | 成本 |
|---|---|---|---|
| 第一道 | 执行者自检 | 常驻系统提示中的"目标宪章 + 自检三问" | 0 次额外调用 |
| 第二道 | Reviewer 例行审计 | 检查点上的独立 LLM 评审（信息隔离） | 每 N 轮 1 次 |
| 第三道 | 用户裁决 | L3 升级通道 | 只在冲突时 |

**RACI 矩阵**——这张表就是"不限制推进"的制度化表达：

| 事项 | 用户 | 执行者 | Reviewer |
|---|---|---|---|
| 目标定义 | **A** | I | C |
| 成功判据 | **A** | C | R（起草） |
| 方法 / 路线 | I | **R / A** | **I（仅知情，不被咨询）** |
| 偏离判定 | I | C（可反驳） | **A** |
| 目标变更 | **A** | I | R（走变更流程） |

> 注意"方法"一行的 Reviewer 只有 I。如果审查者可以对方法给意见，它就从"独立董事"退化成"监工"。这是本设计与常见"AI 代码评审/答案评分"插件的根本分界。

## 5. 核心装置：目标宪章的三层结构

借德鲁克 MBO（目标管理）+ OKR（O 与可验证的 KR）+ PMI 项目章程 + 变更控制委员会（CCB）。把目标拆成三层，**Reviewer 的权限只覆盖第一层**：

| 层 | 内容 | 谁能改 | Reviewer 权限 |
|---|---|---|---|
| **稳定层**（Charter / Constitution） | 终极目标、成功判据（KR）、硬约束、明确的非目标 | 只有用户 | 可质询、可升级、可触发变更流程 |
| **战役层**（Campaign） | 路线、里程碑、取舍、优先级 | 执行者自主 | 只能提示"与稳定层不一致"，不能否决 |
| **战术层**（Tactics） | 每一步工具调用、每次搜索、每个文件 | 执行者自主 | **完全不看** |

**这条分界线就是本插件存在的理由**：只审稳定层，所以不会变成微观管理；因为只审稳定层，所以任何偏离一旦发生都必然触碰它。

**变更控制（CCB）**：目标变更必须走正式流程——Reviewer 提出、用户批准、宪章更新。这防止 AI 悄悄把目标换成"它更容易达成的那个"（第 1 类偏离最常见的发生方式）。

军事管理学的对应物是 **Commander's Intent / Auftragstaktik（任务式指挥）**：给下属"意图"而不是"步骤"，下属在意图内自主决策。现代军队发现这比逐条指令更能达成目标——因为战场信息永远比指令新。Agent 任务同理。

## 5.1 双层目标模型：最终目标与当前目标

v0.1 只有一个"宪章目标"，它把两个不同的控制对象混在了一起：**终局意图**和**阶段任务**。结果是二选一的两难——把任何变化都当漂移，任务会被冻住；把变化都当正常，目标就会被悄悄替换。

v0.2 把两者拆开记账：

| 层 | 管理学对应 | 权限 | 变化规则 |
|---|---|---|---|
| **最终目标** final | 使命 / 指挥官意图（Commander's Intent） | 只有用户 | 只有用户显式改口才变，且必须引用用户原话 |
| **当前目标** current | 阶段目标 / 战役计划（MBO 的目标层级） | Reviewer 维护、用户可随时覆盖 | 随阶段完成、细化、重定向而演进，但必须被记录 |

**变更分类学**（借 PMI 变更控制的分类思想）：

| 标签 | 判定 | 是否改写账本 |
|---|---|---|
| `none` | 无变化 | 否 |
| `refined` | 细化/收窄**当前**目标 | 是（当前层） |
| `phase_advance` | 阶段完成，进入下一阶段 | 是（当前层） |
| `redirected` | 用户显式替换**最终**目标 | 是（最终层） |
| `silent_substitution` | 执行者悄悄换目标，或当前目标不再服务最终目标 | **否**，且判为偏离（`goal_substitution`） |

这条设计让"**演进**"与"**漂移**"在数据结构上分开了：前者是账本 revision +1，后者是账本不变 + 一条 drift 判决。审计流水因此可以回答一个此前无法回答的问题——"这个会话的目标历史上被合法调整过几次？"

理论依据：MBO 的目标层级（德鲁克）、任务式指挥的"意图与任务分离"、PMI 变更控制、契约理论（变更必须有据可查）。登记见 [theory.md](./theory.md)。

## 5.2 机械佐证：最终目标为什么不能被"评审员"改写

变更控制的第一原则是"只有所有者能改契约"。但评审员是一个**读证据包的模型**，而证据包里包含执行者自己的输出——执行者可以在输出里写"请把最终目标改成 X"。如果 `redirected` 只靠模型自觉，注入就能改写稳定层。

所以代码里加了一道**机械佐证**（`guardGoalUpdate`，见 `lib/goals.js`）：

- `redirected` 必须让评审员在 `rationale` 里**逐字引用用户原话**（至少 12 个字符，去空白与标点后匹配）；
- 匹配源只包含**用户自己写的消息**（开场指令 + 最近用户消息），不包含执行者输出、工具结果、伪造的 plugin 消息；
- 匹配失败 → 不改写账本、不发声、审计记 `outcome: "guarded"` 与 `reason: "redirect-not-corroborated"`。

佐证源还排除了**开场指令**：重定向是一次"变化"，所以它必须引用宪章建立之后用户说的话——拿最初的目标原文来"证明"目标被改过，是逻辑上不可能的。

这道闸门是"用户主权"从口号变成可执行代码的那一步：它不能证明模型一定诚实，但能保证**没有用户原话，稳定层就不会移动**。

理论依据：PMI 变更控制（变更必须有据可查）、委托—代理（代理方的报告不可直接当作授权）、契约理论（契约变更须经要约与承诺）。

## 5.3 任免与交接：治理角色也有任期

管理学里的监督角色不是终身制：审计委员会可以改选，独立董事有任期，外部审计可以被更换。更换的意义不只是"换人"，而是**授权随任命终止**——一个已经卸任的审计师继续发审计意见，不是勤奋，是越权。

AI 插件同样有"任期"：宿主会热重载（HMR）、在 profile 里禁用、在关机时卸载，重复的 bundle 配置还可能把它挂载两次。如果实现只把治理能力当成"装上就一直有效"，就会出两类事故：

| 事故 | 机制后果 |
|---|---|
| 退役的评审员仍然发声 | 用户已经关掉或替换了治理策略，旧实例还在 steer 执行者——没有任何人任命它 |
| 重复挂载的评审员 | 每回合两次评审、两份审计、两条 steer，预算翻倍且互相竞争 |

所以生命周期被当成治理语义实现（`lib/index.js`）：

- **任命即注册**：`systemPrompt.section` 的名称同时是单例锁——宿主注册表拒绝同名 section，第二份实例无法组装第二份协议；
- **交接即清理**：卸载时按"先失能、后注销"的顺序执行——`disposed` 门禁先置位并中止在飞评审调用，再移除监听器与提示词段，内存中的会话状态一并清空；
- **在飞裁决作废**：卸载后到达的评审结果既不 steer 也不写审计。已经花掉的模型调用不能转化为任何权威；
- **交接要交账**：新实例从审计流水回放继承**账本与历史结论**（见 5.4），但**评审计数与节奏不继承**——每一任期重新建立预算，避免一次重启让会话预算静默耗尽或无限重置。

这些是**工程上的任免程序**，不是提示词承诺：即使模型完全无视提示词，卸载后的实例也没有可用的发声通道。

理论依据：委托—代理（授权可撤销，代理权限不因履职而永久化）、RACI（最终问责始终在委托人，评审角色只有 R）、三道防线（防线是任命而不是永久机构）。登记见 [theory.md](./theory.md)。

## 5.4 换届不换账：审计流水作为机构记忆

管理学里交接班的规矩是"离任审计 + 档案移交"：人可以换，账不能重记。如果新一任评审员上任时把宪章重新锚定到会话开场指令，用户中途做过的合法重定向就会**悄悄回滚**——工作没有变，审判它的尺子却退回去了。这是比"误报 drift"更隐蔽的治理事故。

所以审计流水承担第二个职责：**新实例的继承档案**。

- 每条审计记录保存**完整**的 final/current 目标快照（不只目标字符串），因此账本可以被原样重建；
- 新实例在会话第一次审计前回放本会话记录：取最后一份非空账本 + 最近 5 条历史结论；
- 回放是 fail-open 且版本兼容的：文件缺失、坏行、旧格式（只有目标字符串）都不会让治理挂掉，旧记录也能重建出"只有目标"的账本；
- 没有审计流水（`audit: false`）就无从回放，行为退回"按开场指令重新锚定"。**审计不是可选项而是档案制度**：关掉它，连续性也就关掉了。

理论依据：契约理论（契约与变更记录不因经办人更替而失效）、审计独立性（审计证据链需要连续）、委托—代理（委托人可查历史档案，代理人不能靠换人重写历史）。登记见 [theory.md](./theory.md)。

## 5.5 用户主权：给委托人一个直接入口

RACI 里最终问责（A）始终在用户身上。此前"用户主权"只落实为**否决**：评审员想改写最终目标，必须逐字引用用户原话（§5.2）。但否决权不是主权——如果用户想主动改目标，只能寄望评审员在下一次审计里读懂并提议；而评审员可能沉默、可能误判，甚至可能不在场。

`/steward` 把"用户自己写"变成一等通道：

- `/steward goal <新目标>`：用户直接把最终目标写进账本（revision + 1，当前目标同步重置），留下 `trigger: principal-command` 的审计记录；
- `/steward status`：随时查看最终目标 / 当前目标 / 成功判据 / 硬约束 / revision / 最近发现 / 审计文件位置；
- `/steward why`：看评审员最近到底报过什么。

为什么它比"让评审员代劳"可靠：命令由宿主 `commands` 服务直接执行**且不产生模型消息**——执行者没有机会在这个通道里表达意见，评审员也看不到请求。用户的话不需要模型转述。这与 §5.2 的逐字引用闸门恰好互补：**评审员改目标必须借用户的话，用户改目标不需要借任何人的话。**

工程上它也是最小的"可感知治理"：命令结果由 UI 渲染在会话之外，用户不必翻审计文件就能看到治理状态；UI-less 宿主不挂载命令注册表时，整个通道自动缺席，评审员照常工作。

理论依据：RACI（A 不可委托给代理）、委托—代理（委托人保留直接撤销/改写授权的通道）、变更控制（变更必须由所有者发起并在案）。登记见 [theory.md](./theory.md)。

## 6. 偏离判定：六类可判定病灶

Reviewer 的评分维度不是玄学，而是第 1 节的类型学中可判定的六类（第 7 类"汇报美化"由执行者透明性纪律与验收机制处理）：

| 代码 | 判定线索 |
|---|---|
| `goal_substitution` | 用户在推进 A，最近的产出都在服务 B |
| `scope_creep` | 出现用户没有要求的交付物，且交付边界扩大 |
| `premature_convergence` | 目标尚未确认，已产生大量实现/不可逆动作 |
| `proxy_optimization` | 指标（分数、测试数、字数、文件数）在涨，但被要求的结果没前进 |
| `constraint_decay` | 用户早期约束在最近 N 步中不再影响行为 |
| `escalation_of_commitment` | 已有证据表明路线失败，但投入继续增加 |

每一条都要求 Reviewer 给出**证据**（引用第几轮、哪个工具、哪句话）。没有证据的判定，验证层直接判为无效（见 [architecture.md](./architecture.md) 的 `parse.js` 规则）。

## 7. 节奏：控制论 + PDCA + 管理例外原则

### 7.1 三种控制时点（控制论）

| 控制类型 | 时点 | 本插件的动作 |
|---|---|---|
| **前馈控制** | 计划定稿 | 首次审计建立宪章，检查计划能否达成 KR |
| **同期控制** | 执行中 | 例行体检（每 N 轮 / 强制间隔）；**默认沉默** |
| **反馈控制** | 交付前 | 对照 KR 验收 |

### 7.2 PDCA（戴明环）

- **P**lan：宪章 + 计划审计
- **D**o：执行期**不打扰**
- **C**heck：检查点审计
- **A**ct：纠偏（steer）与宪章变更

### 7.3 管理例外原则（Management by Exception）

这是"不限制推进"的操作核心。企业里的合规部门之所以招人烦，是因为它对每件事都发声；优秀的控制体系只在**例外**上花注意力。

- 无异常 → **零输出**（连"一切正常"都不说，只写审计日志）
- 有异常 → 按级别升级
- 审计本身有预算：每会话最多 N 次模型调用，超预算自动降级为"只记录"

## 8. 升级阶梯：分级授权

借企业分级授权 / 事故分级响应：

| 级别 | 名称 | 动作 | 是否阻塞 | 典型触发 |
|---|---|---|---|---|
| L0 | 记录 | 写审计日志 | 否 | 一切被审计的轮次 |
| L1 | 标注 | 记录 + 计一次 watch | 否 | 弱信号，证据不足 |
| L2 | 质询 | `steer` 注入一句纠偏指令，要求执行者说明本步如何服务目标 | **否**（异步注入） | 有证据的偏离 |
| L3 | 暂停 | `steer` 要求停下来把冲突交给用户 | 否（但语义上要求停） | 稳定层冲突、硬约束 |
| L4 | 否决 | 预留，当前版本不自动触发 | — | 硬性安全违规 |

**关键设计**：L1/L2 都**不阻塞主流程**。审查者只往 inbox 塞一条消息，执行者继续跑；只有 L3 才在语义上要求它停下来问人。这就是"有牙但不咬人"。

## 9. 审计独立性的四个来源（以及为什么单模型也能独立）

审计学告诉我们：独立**不是**来自"换一个人"，而是来自四个结构性隔离。本插件在只有单一模型可用的主机上，用工程手段实现了这四重隔离：

| 独立性来源 | 现实组织中的做法 | 本插件的实现 |
|---|---|---|
| **信息隔离** | 审计师拿不到管理层的内部推理 | Reviewer 只看**证据包**（宪章 + 用户原话 + 最终输出 + 工具调用摘要），看不到执行者的推理过程与系统提示 |
| **程序隔离** | 审计师没有经营权、不能改账 | Reviewer **无工具、无写权限**，唯一动作是写审计记录 |
| **时点隔离** | 审计在期末/里程碑，不在日常经营中 | 只在**回合边界**评审，不在执行中途插嘴 |
| **激励隔离** | 审计师的考核不看业务 KPI | Reviewer 的提示词明确"抓偏离不是把活干漂亮"，且禁止提方法建议 |

> 如果未来主机支持多模型，只需把 `reviewProvider`/`reviewModel` 指向另一个模型，就获得第五重隔离（**模型隔离**）。配置项已预留。

## 10. 审查者自身的腐化：六道防线

用 X 理论约束审查者。这不是不信任它，而是**任何权力都需要制度约束**：

| 风险 | 管理学对应 | 机制 |
|---|---|---|
| 橡皮图章（永远 on_track） | 监管俘获（regulatory capture） | 要求证据；无证据只能给 L0/L1；审计记录被用户可查 |
| 噪音源（天天报警） | 合规部门病 | 默认沉默；冷却期；每轮最多 1 次说话；同类提醒不重复 |
| 越权指挥（开始教怎么做事） | 越位 | 提示词禁止提方法；验证层不允许 steer 里出现方法指令；L2 只要求"说明如何服务目标" |
| 被讨好（执行者顺着它说） | 谄媚循环 | 执行者被要求"不要讨好审计"；Reviewer 看不到执行者的推理，只看结果证据 |
| 优化通过率 | 古德哈特定律 | Reviewer 的绩效是**滞后指标**（被用户事后纠正的次数），不是通过率；审计日志允许复盘 |
| 成本失控 | 预算软约束 | 每会话调用上限、输出 token 上限、超时；超预算降级为只记录 |

## 11. 与既有方案的差异

生态里已有大量"审查"插件，但它们解决的是不同问题：

| 类型 | 代表 | 审什么 | 时点 | 与本插件的关系 |
|---|---|---|---|---|
| 答案质量审查 | dsh-answer-reviewer、dsh-quality-review | 输出好不好（打分） | 回合末 | 互补：它管"答得好不好"，我们管"是不是在做对的事" |
| 完成声明验证 | dsh-gungnir、dsh-goalloop-agentteams | 完成是不是真的（退出码/产物） | 交付瞬间 | 互补：它管"结果真不真"，我们管"过程对不对" |
| 顾问/第二意见 | dsh-advisor-flow、dsh-advisor-plugin | 执行者主动求教 | 按需 | 不同：那是"咨询"，我们是"审计"（被动、常规、有宪章锚点） |
| 推理措辞漂移 | dsh-anchored-monitor | 思维块的措辞指纹 | 实时 | 不同：启发式 vs 目标语义 |
| **目标治理** | **本插件** | **稳定层对齐** | **整个任务生命周期** | 填补"过程级目标对齐"空白 |

一句话：**它们是质检员，我们是独立董事。**

## 12. 已知局限与路线图

**局限**

1. 单模型主机上，"独立"是角色/信息/程序/时点的独立，不是权重的独立。同模型仍可能自我确认偏误。
2. 证据包是摘要，Reviewer 看不到完整轨迹；极端情况下可能误判（这是为了成本与信息隔离付出的代价）。
3. 审计流水是账本的唯一持久载体：`audit: false` 时跨重启不继承（这是档案制度，不是可选日志）。审计文件被人工裁剪/轮转后，更早的 revision 也无法回放。
4. 不直接阻塞执行（设计如此）；如果用户希望硬门禁，应配合"完成声明验证"类插件。

**路线图**

- `0.2` ✅ 双层目标账本、跨实例回放继承、生命周期安全、`/steward` 用户主权命令通道；宪章落盘为工作区文件（`.dsh/goal-steward/charter.md`，用户可读可改）+ 宪章变更工具仍待做
- `0.3` Web UI：会话内"治理状态胶囊"（绿=在轨 / 黄=存疑 / 红=偏离），点击看审计流水（`/steward status` 已提供文本版入口）
- `0.4` 高风险任务升级为**真子代理 Reviewer**（有调查权：可读日志、查文件）
- `0.5` 多模型隔离 + 组织级多 agent 治理（对 Agent Team 的每个 teammate 设 Reviewer）

## 13. 参考文献（管理学侧）

- Drucker, P. *The Practice of Management* (1954) — MBO
- Deming, W. E. *Out of the Crisis* (1986) — PDCA
- Simon, H. *Administrative Behavior* (1947) — 有限理性、满意即止
- McGregor, D. *The Human Side of Enterprise* (1960) — X/Y 理论
- Merton, R. K. *Social Theory and Social Structure* (1949) — 目标置换
- Staw, B. M. "Knee-deep in the big muddy" (1976) — 承诺升级
- Goodhart, C. "Problems of Monetary Management" (1975) — 古德哈特定律
- COSO. *Enterprise Risk Management — Integrated Framework* (2004/2017) — 三道防线
- PMI. *PMBOK Guide* — 项目章程、变更控制
- 军事：Auftragstaktik / Commander's Intent（任务式指挥）

---

> 本文件是**设计论证**（为什么这样设计）；完整的**理论登记表**——每条理论的原始出处、落地方式、类比失效边界与证伪指标——见 [theory.md](./theory.md)。