Guides vs Sensors：Harness 的双核控制框架

系列第 2 篇 · 前置：第 1 篇 Harness Engineering 入门：Agent = Model + Harness

上一篇讲了 Harness 是什么------包裹在模型外面的七层系统。这一篇讲 Harness 最核心的控制框架，也是整个领域最有用的心智模型：Guides vs Sensors。

一、两种控制：前馈 vs 反馈

Harness 通过两种互补的控制方式来约束 Agent：

swift 复制代码

Guides（前馈控制）------ 在 Agent 行动之前引导它
  目标：提高第一次就做对的概率
  例子：CLAUDE.md、架构文档、Skill 指令、bootstrap 脚本、LSP 集成

Sensors（反馈控制）------ 在 Agent 行动之后观察它，让它能自我修正
  目标：发现做错了，反馈给它改
  例子：linter、类型检查、测试、代码评审 Agent、LLM-as-judge

一句话区分：

Guides 管"做之前" ------告诉它该怎么做
Sensors 管"做之后" ------检查它做得对不对

二、为什么必须两个都有

只有 Guides 没有 Sensors，是希望（hope）------靠模型自觉。

只有 Sensors 没有 Guides，是空转（thrashing）------瞎试不收敛。

只有 Guides（没有反馈）= 希望

objectivec 复制代码

你写了一份完美的 CLAUDE.md：
  "代码必须遵循 MVVM 架构，token 必须持久化，UI 不能自己判断登录状态"

AI 读完了，开始写代码。
→ 它写得对不对？你不知道。
→ 它可能遵守了，也可能忘了。
→ 你只能"希望"它遵守了。

这就是 hope------把质量寄托在模型的记忆力和自觉性上。

只有 Sensors（没有引导）= 空转

arduino 复制代码

你什么规范都没写，只配了一堆检查工具：
  linter、类型检查、单元测试、代码评审 Agent

AI 开始写代码。
→ 测试失败了 → AI 改 → 又失败了 → 又改
→ 它不知道"正确长什么样"，只能瞎试
→ 改了五轮还在同一个地方打转

这就是 thrashing------有反馈但没有方向，反复试错但不收敛。

两个都有 = 闭环

arduino 复制代码

Guides 告诉 AI "正确长什么样"（MVVM、token 持久化、状态驱动）
AI 按 Guides 写代码
Sensors 检查 "写出来的对不对"（编译、测试、评审）
不达标 → Sensors 给出具体反馈 → AI 对照 Guides 改
→ 收敛到达标

一个真正的 Harness 是闭环：Guides 给方向，Sensors 给反馈，两者配合才能收敛。

三、Guides 和 Sensors 各有两种类型

不管 Guides 还是 Sensors，都分两种：

类型	性质	速度/成本	例子
Computational（计算型）	确定性，CPU 跑，可靠	毫秒到秒，便宜	测试、linter、类型检查、正则守卫
Inferential（推理型）	非确定性，GPU/NPU 跑，需要判断	慢，贵	语义分析、AI 代码评审、LLM-as-judge

Guides 的两种类型

objectivec 复制代码

Computational Guides（确定性引导）：
  bootstrap 脚本（自动生成项目骨架）
  LSP 集成（实时提示 API 用法）
  代码模板（固定文件结构）
  → 这些是"程序强制"的引导，不会忘

Inferential Guides（推理性引导）：
  CLAUDE.md（模型读了自己理解）
  架构文档（模型读了自己参考）
  Skill 指令（模型读了自己遵守）
  → 这些是"建议"，模型可能忽略

Sensors 的两种类型

bash 复制代码

Computational Sensors（确定性检查）：
  ./gradlew assembleDebug（编译通过吗？）
  ./gradlew test（测试通过吗？）
  ktlint / detekt（代码规范吗？）
  → 客观、可靠、便宜，每次都该跑

Inferential Sensors（推理性检查）：
  独立评审 Agent（"这段代码架构合理吗？"）
  LLM-as-judge（"这个回答准确吗？"）
  语义分析（"这个函数职责单一吗？"）
  → 主观、有判断、贵，留到检查点跑

四、设计原则：计算型每次跑，推理型留检查点

反面教材：

arduino 复制代码

错误做法 1：全靠 Inferential
  每次改完代码都让一个独立评审 Agent 审一遍
  → 慢、贵、而且评审 Agent 自己也可能出错
  → 一个简单的编译错误，花 30 秒等 LLM 评审才发现

错误做法 2：全靠 Computational
  只跑编译和测试，不做任何语义评审
  → 编译通过、测试通过，但架构一塌糊涂
  → "能跑"不等于"做得对"

正确做法：

复制代码

每次改代码后：
  → 跑编译（Computational，2秒）
  → 跑单元测试（Computational，10秒）
  → 跑 linter（Computational，1秒）

每轮迭代结束时（检查点）：
  → 独立评审 Agent 对照标准审一遍（Inferential，30秒）
  → 只在检查点跑，不每次都跑

Computational 防"明显错"，Inferential 防"微妙错"。 前者是底线，后者是质量上限。

五、用登录模块看 Guides vs Sensors 怎么落地

拿之前 Loop 系列里的登录模块当例子，看看一个完整的 Harness 控制闭环长什么样：

Guides（行动前引导）

bash 复制代码

Computational Guides：
  项目骨架已生成（Compose + MVVM + Hilt）
  .editorconfig 固定代码风格
  LSP 实时提示 API

Inferential Guides：
  CLAUDE.md："登录模块遵循 MVVM，UI 只看 ViewModel 状态"
  Skill/login-dev："token 用 SharedPreferences，7 天过期"
  设计文档：八条验收标准

Sensors（行动后检查）

bash 复制代码

Computational Sensors（每次改完都跑）：
  ./gradlew assembleDebug → 编译通过
  ./gradlew test → 单元测试通过
  ktlint → 代码规范

Inferential Sensors（每轮结束跑）：
  独立评审 Agent 对照八条标准检查
  → "token 用了内存变量，重启丢失 | 严重"
  → "UI 自己维护登录判断，应靠 ViewModel | 中等"

闭环

arduino 复制代码

Guides 告诉 AI "八条标准是什么"
AI 写代码
Computational Sensors 查 "能不能跑"（编译/测试）
Inferential Sensors 查 "做得对不对"（独立评审）
不达标 → 反馈带位置+证据 → AI 对照 Guides 改
→ 直到八条全过

六、一个最容易犯的错：把 Guides 当 Sensors 用

objectivec 复制代码

错误：在 CLAUDE.md 里写 "写完代码后请自行检查是否符合规范"
  → 这是让模型自己当 Sensor
  → 同一个模型写的代码，同一个模型检查
  → 就是 Loop 系列里讲的"自己评自己"→ 假达标

正确：用独立的工具/Agent 当 Sensor
  → 编译是工具跑的，不是模型说的
  → 测试是工具跑的，不是模型说的
  → 评审是另一个 Agent 做的，不是写代码的那个

Guides 是"告诉模型规则"，Sensors 是"独立于模型验证规则"。 让模型自己验证自己，等于没有 Sensor。

七、这一篇总结

markdown 复制代码

1. Harness 通过两种控制约束 Agent：Guides（前馈）+ Sensors（反馈）
2. Guides 管"做之前"------给方向；Sensors 管"做之后"------给反馈
3. 只有 Guides = hope（靠自觉）；只有 Sensors = thrashing（瞎试）
4. 两者配合才是闭环，才能收敛
5. 每种控制都分 Computational（确定性/便宜）和 Inferential（推理/贵）
6. 设计原则：Computational 每次跑，Inferential 留检查点
7. Guides 不能当 Sensors 用------让模型自己查自己 = 假达标

下篇讲 Harness 的七层解剖------从 Instructions 到 Observability，每层具体是什么、怎么落地、常见坑在哪。