dsh-goal-steward

给每个对话常设一位独立的目标评审员：它确认任务的终极目标，审计推进过程中的目标偏离，但不限制任务推进。

English: An independent goal-governance layer for DeepSeek Harness. Every conversation gets a standing goal charter plus a role-isolated reviewer that audits stable-layer alignment at turn boundaries. The reviewer has no tools, no authority over method, and defaults to silence — it steers the executor only when it can cite evidence of drift. The design is derived from management science (MBO, PDCA, management-by-exception, COSO three-lines, RACI, change control) rather than ad-hoc prompt engineering. See docs/design.md.

---

它解决什么问题

AI 执行任务时最贵的失败不是"做错了"，而是"做完了才发现做的不是用户要的"。这类失败有七种形态：

形态	例子
目标替换	用户要"能设置成功"，AI 在优化"代码写得多"
范围蔓延	需求越加越多，交付边界失守
过早收敛	目标没确认就开工
代理指标优化	测试数在涨，但被要求的功能没前进
约束遗忘	多轮后忘了用户早先说的"不要动那个文件"
承诺升级	明知路线失败，因沉没成本继续加速
汇报美化	把"做过"说成"做成"

常见的"AI 审查"插件审的是输出质量或完成声明是否属实；本插件审的是过程级的目标对齐——任务进行到一半就发现跑偏。

两层机制

第一层（零成本，每轮生效）
  常驻系统提示：目标宪章 + 自检三问 + 六类偏离 + 升级规则
  → 执行者自己的"第一道防线"

第二层（管理例外，按节奏触发）
  回合边界 → 证据包 → 独立 Reviewer（角色隔离/信息隔离/程序隔离/时点隔离）
           → 严格 JSON 裁决 → L0 记录 / L1 标注 / L2 质询 / L3 暂停升级
  → 默认沉默；只有能举证的偏离才发声

为什么它不会限制推进：

• 只审稳定层（目标 / 成功判据 / 硬约束 / 非目标），方法层完全不看；
• L1/L2 只往 inbox 注入一条消息，不阻塞主流程；
• 每轮最多 1 次评审、每回合最多 2 次说话、有会话总预算；
• 无证据的判定直接作废（宁可漏报，不可误报）；
• 执行者可以反驳，争议升级给用户。

设计论证见 docs/design.md，理论登记表见 docs/theory.md，技术实现见 docs/architecture.md。

理论支撑（Theory）

这个项目不是拍脑袋的 prompt 工程：它把管理学里经过组织实践检验的控制模型，逐条翻译成 agent 运行时机制。理论登记在代码里（lib/theory.js），理论文档由代码生成（docs/theory.md），CI 强制追溯完整性——一条运行时机制没有理论依据、或一条引用没有落成机制，测试直接失败。

管理学模型	落成的机制
X/Y 理论（麦格雷戈 1960）	非对称姿态：对执行者用 Y 理论（不干预方法），对审查者用 X 理论（默认沉默/预算化/必须举证）
有限理性 / 满意即止（西蒙 1947）	解释 AI 为什么会漂移；审计补的是全局视角，不是质疑能力
目标置换（默顿 1949）	六类偏离分类法中的 goal_substitution
MBO · OKR · SMART（德鲁克/格鲁夫/多兰）	三层目标宪章 + 可验证的成功判据
PDCA + 前馈/同期/反馈控制（戴明/维纳）	首轮建章 → 执行期沉默 → 强制间隔审计 → 交付前验收
例外管理原则（泰勒以降）	默认沉默；只在显式触发点评审；发声预算
COSO 三道防线	自检（第一道）→ 独立评审（第二道）→ 用户裁决（第三道）
RACI（PMI）	方法选择的 Reviewer 只有 I（仅知情），结构上禁止微观管理
变更控制 / CCB（PMI）	稳定层变更必须走宪章更新，禁止静默换目标
审计独立性（IIA）	信息 / 程序 / 时点 / 激励四重隔离
监管俘获（斯蒂格勒 1971）	防止评审员退化成橡皮图章
古德哈特定律（1975）	防代理指标优化；通过率不是评审员指标
承诺升级（斯托 1976）	用历史结论识别"明知失败还加速"
委托—代理问题（詹森/麦克林 1976）	诚实汇报规范 + 可复盘的审计流水
任务式指挥 / Auftragstaktik	给意图不给步骤：执行者拥有路线选择权
契约理论（科斯/威廉姆森）	把硬约束写成条款而非礼貌，防止约束衰减

完整推导（每条理论的落地方式、类比的失效边界、以及如何证伪这套设计）见 docs/theory.md。

双层目标模型：最终目标 vs 当前目标

一个"目标"其实混了两个控制对象。本插件把它们分开记账：

层	定义	谁能改	变化是否合法
最终目标（final）	委托人的终局目标	只有用户显式改口	不能悄悄换
当前目标（current）	当前阶段正在做的事	Reviewer 按对话演进并记入账本	本来就该随阶段推进而变

每次审计，Reviewer 会给观察到的目标变更打上五类标签之一：

标签	含义	对账本的影响
none	没变，工作服务于已记录目标	不改
refined	用户或证据细化了当前目标（最终目标不变）	写当前目标
phase_advance	当前阶段完成，合法进入下一阶段	写当前目标
redirected	用户显式改变了最终目标	写最终目标（须引用用户原话）
silent_substitution	执行者悄悄换目标，或当前目标不再服务最终目标	不改账本，判为偏离并纠偏

这样"根据对话调整目标"和"防止目标漂移"不再矛盾：演进被允许并被记录，替换被发现并被拦下。账本带 revision 与历史，审计流水里能看到 final / current / goalChange。

用户主权：/steward 命令

否决权不等于主权。评审员改写最终目标必须逐字引用你的原话，但你自己也需要一个直接写目标的入口——/steward 就是这个人机通道：命令由宿主直接执行，不产生模型消息，执行者没有机会插话，评审员也看不到请求。

/steward                    # 查看最终目标 / 当前目标 / 成功判据 / revision / 最近发现 / 审计文件
/steward goal <新的最终目标>  # 由你直接设定最终目标（账本 revision +1，写入审计）
/steward why                # 看评审员最近报过什么（最近 5 条结论）

命令结果由 UI 渲染在会话之外；UI-less 宿主没有命令注册表时，这个通道自动缺席，评审员照常工作。详见 docs/design.md §5.5 与 docs/architecture.md §12。

安装

尚未发布 npm 包；以 tarball / 本地路径 / git 地址 安装。每次发布 tag 会在 GitHub Release 附带构建好的 dsh-goal-steward.tgz。

方式 A：Desktop（图形界面，推荐）

Desktop 的 profile 由桌面进程管理，npm CLI 会拒绝操作 desktop profile；请在 插件管理 界面里安装，包地址三选一：

file:D:/project/dsh-goal-steward
https://github.com/Frac0103/dsh-goal-steward/releases/download/v0.2.0-alpha.10/dsh-goal-steward.tgz
github:Frac0103/dsh-goal-steward

安装后重启 DSH 生效（host 插件与命令面都在启动时装载）。

方式 B：CLI profile（web / headless / 自定义）

# --profile 是 profile 名；desktop 之外的名字由 CLI 管理
npx -p @deepseek-ai/dsh dsh plugin --profile <profile> add "file:D:/project/dsh-goal-steward"
npx -p @deepseek-ai/dsh dsh plugin --profile <profile> add "https://github.com/Frac0103/dsh-goal-steward/releases/download/v0.2.0-alpha.10/dsh-goal-steward.tgz"
npx -p @deepseek-ai/dsh dsh plugin --profile <profile> add "github:Frac0103/dsh-goal-steward"

dsh plugin 会把参数转发给 profile 目录里的 pnpm，并自动把带 dsh.bundle 的包记入 dsh.profile.bundles。GitHub 分发获取的是源码而非构建产物：本包无构建步骤（纯 ESM），但 pnpm ≥10 默认拦截 Git 依赖的安装脚本——本包没有 prepare 脚本，因此无需放行。

方式 C：手工挂载（开发调试）

把仓库放进 profile 的 node_modules（或 pnpm add link:D:/project/dsh-goal-steward），并在 profile cordis.patch.yml 追加：

- insert:
    - id: goal-steward
      name: 'dsh-goal-steward'
      config:
        preset: standard

零配置即可运行：默认 standard 档。安装路径已在本机真实验证：headless profile + 真实模型跑通一次完整审计闭环，记录见 docs/verification/l4-headless-dogfood.md。

配置

三档预设，也可逐项覆盖：

档位	审计频率	说话门槛	适合
gentle	只在目标变更时	仅 L3	几乎零打扰
standard（默认）	首轮 + 每 3 轮 + 强制间隔 6	L2	平衡
strict	每轮	L1	高风险/长链路任务

- insert:
    - id: goal-steward
      name: 'dsh-goal-steward'
      config:
        preset: standard
        reviewEveryTurns: 3
        steerSeverity: 2
        maxSteersPerSession: 12
        # reviewProvider: other-provider
        # reviewModel: other-model

完整配置表见 docs/architecture.md#9-配置。

审计与复盘

每一次评审（包括跳过与失败）都会写一行 JSONL：

$DSH_HOME/goal-steward/audit.jsonl

你可以复盘"它报过什么、为什么没报、有没有该报没报"。

与其他插件的关系

类型	代表	本插件的位置
答案质量审查	dsh-answer-reviewer、dsh-quality-review	互补：它管"答得好不好"，我们管"是不是在做对的事"
完成声明验证	dsh-gungnir、dsh-goalloop-agentteams	互补：它管"结果真不真"，我们管"过程对不对"
顾问/第二意见	dsh-advisor-flow、dsh-advisor-plugin	不同：那是"咨询"，我们是"审计"
推理措辞漂移	dsh-anchored-monitor	不同：启发式 vs 目标语义

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

状态

0.2.0-alpha.10 — 早期版本，接口与提示词仍会变。当前已实现：常驻治理协议、回合边界审计、证据包、严格裁决校验、分级 steer、审计流水、三档预设、双层目标账本（final / current）与目标变更分类、最终目标重定向的逐字引用闸门、可卸载/可重载的治理实例（退役不发声、重复挂载只审一次）、审计流水回放继承（换届不换账）、/steward 用户主权命令通道（status / goal / why）、197 个测试（纯函数 + 对抗性 + 假上下文 + 真实组装）与覆盖率门禁、真实宿主 + 真实模型的 L4 实机验证。

路线图见 docs/design.md#12-已知局限与路线图： Web UI 治理胶囊 → 真子代理调查 → 多模型隔离与组织级治理。

开发

npm ci            # 需要 devDependencies（真实宿主服务包，用于真实组装测试）
npm run check     # 每个 lib/*.js 用 node --check 解析
npm run check:docs # 文档相对链接与锚点门禁
npm test          # 197 个测试：纯函数 122 + 对抗性 30 + 假上下文 37 + 真实组装 8
npm run test:redteam  # 只跑对抗性测试（契约攻击 / 证据注入 / 结构性边界）
npm run test:compose  # 只跑真实组装层（真实服务 + 真实 AgentLoop，脚本化模型边界）
npm run test:coverage # 覆盖率报告（Node 22+ CI 用 line 99 / branch 85 / function 95 门禁）
npm run verify    # check + check:docs + test

发布：推送 v* tag 触发 release workflow，从 CHANGELOG 生成发布说明并附上 dsh-goal-steward.tgz。L4 实机验证记录见 docs/verification/l4-headless-dogfood.md。

测试分四层（L1 纯函数 / L2 假上下文 / L3 真实组装 / L4 实机），设计依据与后续缺口见 docs/testing.md。

欢迎 issue 与 PR，尤其是：不同管理模型的映射论证、证据包字段的取舍、Reviewer 提示词的对抗性测试。

许可

MIT © 2026 Jiahao Ma