# 推理偏移、监督机制与上下文预算管理

> **背景**: Yandex 研究者 Rodionov (2026.04) 发现 LLM 在长上下文中不是"找不到信息"，而是"主动减少思考量"——推理 token 缩水高达 53%，且推理能力越强的模型偷懒越严重。
> **影响**: 所有 Agent 框架（包括 lambdagentpaas）的 ReAct 循环和多步管道都受此影响。
> **应对**: lambdagentpaas 的三层防御——形式化保证（不依赖模型行为）、架构抗偏移（短上下文设计）、运行时监督（CEK Yield 注入）。

---

## 一、推理偏移：模型在偷懒，不是在犯错

### 核心发现

Rodionov 的《Reasoning Shift》论文揭示了一个反直觉的现象：

```
实验: 同一道奥数题，在不同上下文条件下让 LLM 做

  基线 (干净):      准确率 74.5%,  推理 token 28,771
  + 64K 莎士比亚:   准确率 67.8%,  推理 token 16,415  ← 缩水 43%!

  模型完全知道莎士比亚无关 ("这跟几何题无关，专注几何")
  但还是少想了 43%
```

**关键数据**：

| 指标 | 发现 | 含义 |
|------|------|------|
| 推理 token 缩水 | 最高 53% (Qwen 深度思考) | 模型不是想错了，是想少了 |
| 自我检查率 | 43% → 32% | 模型跳过了验证步骤 |
| 128 token 触发 | 仅 2-3 句话就砍掉 18% 推理 | 极其敏感的偷懒机制 |
| 能力越强越偷懒 | 深度思考模式缩短 53% vs 普通模式 19% | 训练推理能力加剧了偷懒 |
| "wait/but/maybe" 频率 | 下降 50-75% | 犹豫、自我质疑被系统性砍掉 |

### 两种"失败"的区分

```
致命失败 (结构性错误):
  API 返回 500 / 解析异常 / 工具崩溃
  → 模型无法继续
  → lambdagentpaas 的 lint/type_check 可在编译时拦截

推理偏移 (认知节省):
  模型看到长上下文 → 主动减少思考量
  → 跳过自我验证
  → 该深入的地方草草带过
  → 不报错、不坦白、只是极其自信地给出敷衍的答案
  → 这是最危险的——你无法从输出中看出它偷懒了
```

### 对 Agent 系统的影响

```
所有依赖 LLM 多步推理的系统都受影响:

  ReAct 循环:
    Step 1-3: 上下文短 → 推理充分
    Step 8-10: 上下文长 → 推理缩水 → 选错工具/跳过验证
    Step 15-20: 推理严重衰减 → 回答质量不可预测

  多智能体协作:
    第 1 轮 GroupChat: 每个 Agent 推理充分
    第 5 轮: 对话历史累积 → 后面的 Agent 开始敷衍
    第 10 轮: 综合质量远不如单 Agent 执行

  LLM Wiki Ingest:
    前 100 个文件: 实体提取全面
    第 500 个文件: 提取开始变粗糙 (如果上下文累积)
```

---

## 二、为什么 lambdagentpaas 的架构天然抗偏移

### 2.1 形式化保证不依赖模型行为

```
模型偷不偷懒，以下保证都成立:

  类型安全 (T-Compose):
    output(f) <: input(g) → 不管模型输出什么质量的内容
    类型不兼容在编译时就拦截，不进入运行时

  成本上界 (分级类型):
    跑 20 步 Opus = $0.27 → 不管模型推理多深或多浅
    上界是数学计算，不是模型行为的函数

  终止性 (Theorem 5.4):
    fix_n 在 n 步后终止 → 不管模型是否找到答案
    即使模型每步都在偷懒，也不会无限运行

  并行安全 (Proposition 30):
    writes(f) ∩ writes(g) = ∅ → 不管模型输出什么
    Store independence 是静态分析，不受推理质量影响
```

**这就是形式化方法的价值**：模型行为不可靠时，数学保证仍然可靠。

### 2.2 LLM Wiki 模式：短上下文设计

论文发现推理偏移的触发条件是**上下文长度**。LLM Wiki 的设计恰好规避了这个条件：

```
传统 RAG:
  Query 时: 塞 5 个文档块 (几千 token) → 上下文长 → 触发偏移
  
  用户问 "有哪些安全风险？"
  → 检索 5 个原始文档块 (每个 500 token = 2500 token)
  → 塞进 prompt → 总上下文 ~4000 token
  → 论文数据: 即使 128 token 就能砍掉 18% 推理深度

LLM Wiki 模式:
  Ingest 时: LLM 在短上下文中阅读单个文件 → 写 wiki 页面
    每次 Ingest 只看一个文件 → 上下文短 → 不触发偏移
    知识被"编译"成结构化 wiki → 以后不需要重新处理
    
  Query 时: 读 index.md → 只读 2-3 个 wiki 页面
    wiki 页面是已编译的精华 (比原始文档短 5-10 倍)
    → 上下文更短 → 推理偏移更小
    → 而且 wiki 的交叉引用已经建好，不需要 LLM 自己推理关联

本质: 把"一次长上下文推理"拆成了"多次短上下文编译 + 一次短上下文查阅"
```

### 2.3 三层编程模型限制上下文增长

```
Layer 1 — Skill (原子能力):
  每个 Skill 是独立的短任务
  上下文 = Skill 自己的 prompt + 当次输入
  不累积历史 → 不触发偏移
  
  例: answer-generator Skill 每次只看 "检索到的 wiki 页面 + 问题"
      不看之前所有的对话历史

Layer 2 — Pattern (协作模式):
  fan_out_merge: 每个并行分支独立执行，上下文不共享
    → 3 路并行中每路只看自己的上下文
    → 不会因为分支 A 的输出让分支 B 的上下文变长

  review: 每轮审查是独立的 LLM 调用
    → 审查者只看"当前回答 + 参考原文"
    → 不累积前几轮的审查历史

  escalation: 每级只看上一级的最终结果
    → L2 不看 L1 的完整推理过程
    → 上下文不膨胀

Layer 3 — Orchestration (YAML 编排):
  声明式编排把大任务拆成小步骤
  每步的上下文是 YAML 定义的，受控的
  不会出现"整个任务历史塞进一个 prompt"
```

### 2.4 CEK Machine 的结构化执行

```
Python 递归调用栈:
  整个 ReAct 循环共享一个上下文
  Step 1 的输出 + Step 2 的输出 + ... 全部累积
  → 上下文线性增长 → 推理偏移线性加剧

CEK Machine:
  每个 Yield 点是一个状态快照 ⟨C, E, K, σ, c⟩
  上下文 E 可以在 Yield 点被压缩/重置
  → 上下文增长可控
  → 在偏移信号出现时主动干预
```

---

## 三、三级监督机制

lambdagentpaas 的 CEK Yield 机制天然支持在 Agent 执行过程中注入监督。

### Level 1: 规则监督（已实现）

编译时和运行时的自动化检查，不需要 LLM 参与：

```
编译时:
  lint (26 规则):     "没有 terminate 工具，会死循环"
  type_check:         "Stage 2 输出 Json, Stage 3 期望 Str"
  cost_predict:       "这个管道最多花 $0.42，成功率 63%"
  store_independence:  "两个并行 Agent 写同一个 key"

运行时 (CEK Yield 点):
  成本熔断:     machine.state.cost.money > budget → 暂停
  循环检测:     连续 3 步 state hash 相同 → 停止
  步数上限:     step_count > max_steps → 终止

特点: 零 LLM 成本，毫秒级，确定性
局限: 不理解内容，只检查结构和数值
```

### Level 2: 模型监督（可实现）

用一个轻量 LLM 作为"监督者"，每 N 步检查 Agent 的输出质量：

```
实现方式:

  class SupervisedCEKEngine(CEKEngine):
      def __init__(self, supervisor_llm, supervise_every=3, **kwargs):
          self.supervisor = supervisor_llm
          self.supervise_every = supervise_every

      def execute(self, term, input_val, ctx, **opts):
          machine = AgentCEKMachine(...)
          machine.load(term, input_val)
          step = 0

          while not machine.state.is_terminal():
              transition = machine.step()
              step += 1

              # Level 1 检查 (已有)
              self._check_cost_budget(machine)
              self._check_loop(machine)

              # Level 2 检查 (新增): 每 N 步用监督 LLM 检查
              if step % self.supervise_every == 0:
                  verdict = self._supervise(machine.state, transition)
                  if verdict.action == "STOP":
                      break
                  elif verdict.action == "CORRECT":
                      machine.state.control = verdict.corrected_value
                  elif verdict.action == "COMPRESS":
                      machine.state.env = self._compress_context(machine.state.env)

监督者的检查内容:
  1. 推理偏移检测:
     "当前输出 (500 token) 比第 1 步 (2000 token) 短 75%，可能存在推理缩水"
     → 建议: COMPRESS (压缩上下文后重试)

  2. 方向偏离检测:
     "Agent 连续 3 步在搜索无关关键词，偏离了原始目标"
     → 建议: CORRECT (注入纠正信息)

  3. 质量衰减检测:
     "回答中缺少来源引用，且置信度异常高 (偷懒的典型特征)"
     → 建议: 要求 Agent 重新检查并补充引用

成本:
  主 Agent (Opus): $0.015/次
  监督者 (Haiku): $0.00025/次 (便宜 60 倍)
  每 3 步监督一次: 额外成本 ≈ 主 Agent 的 2%
```

### Level 3: 人类监督（可实现）

CEK Yield 暂停 → 推送给人类审批 → 等待确认后继续：

```
实现方式:

  class HumanSupervisedEngine(CEKEngine):
      def __init__(self, approval_callback, require_approval_for=None, **kwargs):
          self.approval_callback = approval_callback
          self.require_approval = require_approval_for or [
              "WriteFile", "EditFile", "Bash", "DeleteFile"
          ]

      # 在 Yield(tool) 点检查是否需要人类审批
      if transition.label.kind == LabelKind.TOOL:
          if transition.label.name in self.require_approval:
              approved = await self.approval_callback({
                  "tool": tool_name,
                  "input": transition.label.input,
                  "cost_so_far": machine.state.cost,
              })
              if not approved:
                  break  # 人类拒绝 → 终止

适用场景:
  - Agent 要删除生产数据库 → 暂停，推送给人类确认
  - Agent 要修改敏感配置文件 → 暂停，人类审阅 diff
  - WikiIngest 发现矛盾 → 暂停，人类判断哪个版本正确

成本:
  最贵但最安全
  适用于高风险操作（不是每步都需要）
```

### 三级监督的成本效益对比

```
场景: Agent 跑 20 步，第 5 步走错方向

不监督:
  20 步全跑完 → 第 5-20 步全浪费 → $0.06 → 结果错误

Level 1 (规则):
  第 10 步检测到循环 → 停止
  $0.03 → 结果仍然错误，但省了钱

Level 2 (模型):
  第 6 步监督者发现方向错 → 纠正
  Agent 从第 7 步走对 → 第 12 步完成
  $0.04 + $0.002 (监督成本) → 结果正确

Level 3 (人类):
  第 5 步人类发现走错 → 手动纠正
  Agent 从第 6 步走对 → 第 10 步完成
  $0.03 + 5 秒人类注意力 → 结果正确且最优
```

---

## 四、推理偏移检测器

### 设计原理

基于 Rodionov 论文的发现，推理偏移有可量化的症状：

```
症状 1: 输出长度递减
  正常: Step 1 → 2000 token, Step 5 → 1800 token, Step 10 → 1600 token (缓慢下降)
  偏移: Step 1 → 2000 token, Step 5 → 1200 token, Step 10 → 600 token (加速下降)

症状 2: 自检词消失
  正常: "wait" 11%, "but" 46%, "maybe" 23%
  偏移: "wait" 5%, "but" 20%, "maybe" 9%

症状 3: 首答到终结的距离缩短
  正常: 找到答案后继续验证 (43% 概率)
  偏移: 找到答案后直接输出 (68% 概率)

症状 4: 置信度异常升高
  正常: "我认为...""可能是...""根据文档..."
  偏移: "答案是...""显然...""毫无疑问..."
  (偷懒的模型反而更自信)
```

### 检测指标

```
推理密度 (Reasoning Density):
  RD(step) = output_tokens(step) / max(output_tokens(step_1), 1)
  
  RD ≈ 1.0: 推理深度保持
  RD < 0.5: 推理深度衰减 50%+，高度疑似偏移

推理密度衰减率 (Decay Rate):
  DR = (RD(step_1) - RD(step_n)) / n
  
  DR < 0.02/步: 正常衰减
  DR > 0.05/步: 快速衰减，偏移确认

自检词频率 (Self-Check Frequency):
  SCF(step) = count("wait"|"but"|"maybe"|"however"|"等一下"|"不过"|"也许") / total_words
  
  SCF 基线: 从 Step 1 采样
  SCF < 基线 × 0.5: 自检行为被砍掉一半，偏移确认

综合偏移分数 (Shift Score):
  SS = 0.4 × (1 - RD) + 0.3 × DR_normalized + 0.3 × (1 - SCF/SCF_baseline)
  
  SS < 0.2: 正常
  SS 0.2-0.5: 轻度偏移 (告警)
  SS > 0.5: 重度偏移 (干预)
```

### MCP 工具接口

```
工具名: monitor_reasoning_shift

输入:
  {
    "trace": [
      {"step": 1, "input_tokens": 500, "output_tokens": 2000, "output_text": "..."},
      {"step": 2, "input_tokens": 2500, "output_tokens": 1800, "output_text": "..."},
      ...
    ]
  }

输出:
  {
    "shift_score": 0.62,
    "severity": "HIGH",
    "reasoning_density": [1.0, 0.9, 0.75, 0.5, 0.3],
    "decay_rate": 0.175,
    "self_check_frequency": [0.11, 0.09, 0.06, 0.04, 0.02],
    "onset_step": 3,
    "recommendation": "Step 3 后推理密度下降 65%。建议: (1) 在 Step 3 压缩上下文 (2) 拆分为两个独立子任务 (3) 对 Step 4+ 的输出启用 Guard 验证"
  }
```

---

## 五、上下文预算管理

### 扩展成本分级

在原有的 `CostGrade(p, p_fatal, t, l, m)` 基础上，新增上下文负载维度：

```
扩展后:
  CostGrade(p, p_fatal, t, l, m, context_tokens, context_load)

  context_tokens: 累积输入 token 数（所有步骤的 input 之和）
  context_load:   = context_tokens / model_context_window

  context_load 是推理偏移的先导指标:
    < 30%:  安全区 → 推理偏移风险低
    30-60%: 警戒区 → 开始出现轻度偏移
    60-80%: 危险区 → 推理密度可能衰减 30-50%
    > 80%:  红线区 → 推理偏移几乎必然发生
```

### 上下文预算规则

```
每个 Agent 编译时计算上下文预算:

  ReAct 循环 (maxSteps=10, Sonnet 200K window):
    每步估算: system_prompt (2000) + history (step × 1500) + tools (500)
    
    Step 1:  2000 + 0 + 500 = 2,500 (1.25% load) → 安全
    Step 5:  2000 + 7500 + 500 = 10,000 (5% load) → 安全
    Step 10: 2000 + 15000 + 500 = 17,500 (8.75% load) → 安全
    
    结论: 10 步 Sonnet 循环的上下文负载始终 < 10%，偏移风险低

  GroupChat (5 agents, maxRounds=10):
    每轮: 5 agents × 1500 token/轮 = 7,500
    10 轮: 75,000 token → 37.5% load → 进入警戒区!
    
    建议: 第 6 轮后启用上下文压缩 (smart windowing)

  Pipeline 5 级 (每级 Opus 调用):
    每级输入: 上一级输出 (约 3000 token) + system_prompt (2000)
    → 上下文不累积 (每级是独立调用) → 始终安全
    
    这是 Pipeline 相比 ReAct 的天然优势: 上下文不膨胀
```

### 上下文压缩策略

```
当 context_load 超过阈值时的自动干预:

策略 1: Smart Windowing (已有)
  保留: system_prompt + 最近 N 步 + 关键中间结果
  丢弃: 早期步骤的完整输出
  → context_load 回落到 30% 以下

策略 2: Summary Compaction
  对早期历史做摘要: "Step 1-5 完成了文件读取和初步分析，发现 3 个关键问题: ..."
  替换原始历史 → 信息保留但 token 大幅减少
  → 需要额外 1 次 LLM 调用 (用便宜模型)

策略 3: Context Reset (最激进)
  在 CEK Yield 点完全重置上下文
  只保留: 当前任务目标 + 到目前为止的最终结果
  → context_load 回到接近 0%
  → 最有效但可能丢失细节

自动选择:
  context_load < 30%: 不压缩
  30-60%: Smart Windowing
  60-80%: Summary Compaction
  > 80%: Context Reset
```

---

## 六、与 Harness Engineering 的关系

### 文章的论点

Rodionov 和 Anthropic 的研究暗示：如果能从模型内部解决推理偏移（通过情绪向量注入等手段），外部的 Harness（Todo list/Checkpoint/子代理验证）就不再需要。

### lambdagentpaas 的定位

```
会过时的 (外部约束):
  ✗ Todo list 强制模型按步骤做
  ✗ Checkpoint 定期验证中间结果
  ✗ 子代理交叉验证
  ✗ 上下文压缩/窗口管理
  → 模型足够可靠后，这些都是多余的脚手架

不会过时的 (lambdagentpaas 核心):
  ✓ 类型安全 → 数学定理，和模型行为无关
  ✓ 成本上界 → 算术计算，和推理深度无关
  ✓ 终止性保证 → Y 组合子性质，和模型质量无关
  ✓ 并行安全 → 集合论性质，和上下文长度无关
  ✓ Skill/Pattern 架构 → 短上下文设计，天然限制偏移触发条件
  ✓ LLM Wiki → 知识编译模式，根本不依赖长上下文推理

关键区别:
  Harness = "管住一个不可靠的模型" → 模型可靠后不需要
  λA 类型系统 = "数学保证组合的正确性" → 永远需要
```

### 两层护城河

```
第一层 (短期): 模型还在偷懒
  → 推理偏移检测 + 三级监督 + 上下文预算管理
  → 这是当前有价值的能力
  → 随着模型进化，这层价值会递减

第二层 (永久): 不管模型多完美
  → 类型检查: output(f) <: input(g) 是数学事实
  → 成本预测: 20 步 × $0.015 = $0.30 是算术事实
  → 终止性: fix_20 在 20 步后终止是定理
  → 这些和模型是否偷懒完全无关
  → 这层价值永不递减
```

---

## 七、总结

```
推理偏移的本质:
  不是 bug，不是能力不足
  是模型学到的"认知节省策略"——省力但不报错
  越聪明的模型越会偷懒（因为它知道怎么走捷径）

lambdagentpaas 的三层防御:

  Layer A — 架构抗偏移 (天然):
    LLM Wiki 短上下文编译
    Skill 独立执行
    Pattern 分支隔离
    → 从结构上限制上下文增长，不给偏移可乘之机

  Layer B — 运行时监督 (CEK Yield):
    Level 1 规则: 成本熔断 + 循环检测 (零成本)
    Level 2 模型: 监督 LLM 每 N 步检查 (低成本)
    Level 3 人类: 高风险操作暂停审批 (高安全)
    → 在偏移发生时实时检测和干预

  Layer C — 形式化保证 (永久):
    类型安全 + 成本上界 + 终止性 + 并行安全
    → 不依赖模型行为，数学保证永远成立
    → 即使模型偷懒到极致，这些保证仍然有效

这就是为什么 lambdagentpaas 不怕"Harness 被模型进化吞没":
  Harness 是外部脚手架 → 会被淘汰
  λA 类型系统是数学定理 → 不会被淘汰
  推理偏移检测是过渡期工具 → 有当前价值
  LLM Wiki 是架构选择 → 天然抗偏移
```
