附录　理论背景 | 深度驭具工程

附录

附录 A　理论背景（选读）

为希望深入理论的读者提供严格的数学与物理背景，与正文的工程导向内容分离。

A.1 信息论要点

Shannon 熵

对于离散随机变量 $X$ ，其概率分布为 $p(x)$ ，Shannon 熵定义为：

$H(X) = -\sum_{x \in \mathcal{X}} p(x) \log_2 p(x)$

熵度量的是随机变量中的”不确定性”或”信息量”。在 Context Engineering 中，上下文熵 $H(C)$ 度量的是当前 Context 中信息分布的均匀程度——高熵意味着注意力难以聚焦，低熵意味着信息高度集中。

互信息

两个随机变量 $X$ 和 $Y$ 之间的互信息定义为：

$I(X; Y) = H(X) - H(X|Y) = H(Y) - H(Y|X)$

互信息度量”知道 $Y$ 后，关于 $X$ 的不确定性减少了多少”。Context Engineering 的目标 $\max I(\text{意图}; \text{输出})$ 是这一概念的直接应用：最大化 Context 对输出质量的信息贡献。

Rate-Distortion 定理

对于信源 $X$ 和允许的失真度 $D$ ，Rate-Distortion 函数 $R(D)$ 定义了在失真不超过 $D$ 的条件下所需的最小编码速率：

$R(D) = \min_{p(\hat{x}|x): \mathbb{E}[d(X,\hat{X})] \leq D} I(X; \hat{X})$

工程含义：Compaction 是有损压缩，Rate-Distortion 定理告诉我们存在一个理论最优的压缩率，超过这个点继续压缩必然引入更多失真。这为”Compaction 应该压缩到什么程度”提供了理论参照（详见第六章 §6.1）。

Channel Capacity 定理

信道容量定义为互信息在所有可能输入分布上的最大值：

$C = \max_{p(x)} I(X; Y)$

Shannon 信道编码定理：当传输速率 $R < C$ 时，存在编码方案使错误概率任意低；当 $R > C$ 时，错误不可避免。在 Harness 语境中，Context 窗口是一条有限容量信道，“Lost in the Middle”效应使实际有效容量低于名义 token 上限（详见第六章 §6.2）。

A.2 控制论要点

反馈回路的稳定性分析

一阶线性反馈系统： $x_{n+1} = f(x_n) = a \cdot x_n + b \cdot e_n$ ，其中 $e_n$ 是误差信号。系统在 $|a| < 1$ 时收敛（误差衰减），在 $|a| > 1$ 时发散（误差放大）。在 Agent 系统中， $a$ 对应反馈增益——Hook 的纠正力度相对于 Agent 偏差的比例。

Ashby 必要多样性定律

若系统的扰动有 $D$ 种可能状态，控制器至少需要 $\log_2 D$ 比特的状态多样性来实现有效控制。Ashby（1956）的原始不等式形式为：

$H(\text{输出}) \geq H(\text{扰动}) - H(\text{控制器})$

要使输出的不确定性 $H(\text{输出})$ 被压制为零（即完美控制），必须有 $H(\text{控制器}) \geq H(\text{扰动})$ ——这是第五章 §5.1 引用的紧化形式。两者数学等价：紧化形式是原始不等式在”完美控制”目标下的特例。

工程推论：Harness（控制器）的复杂度下界由 Agent 行为的复杂度（扰动）决定。一个过于简单的 Harness 无法约束一个行为高度多样的 Agent——这是 Harness 最小规模的理论依据。

Lyapunov 稳定性

若存在一个正定函数 $V(x)$ （Lyapunov 函数），使得在系统的每个状态 $x$ 处， $V$ 沿系统轨迹递减（ $\dot{V}(x) < 0$ 或离散情况下 $V(x_{n+1}) < V(x_n)$ ），则系统在平衡点处渐近稳定。

在 Harness 设计中，一个合适的 Lyapunov 函数可以是”当前状态与目标状态之间的距离度量”——如果每次反馈后这个距离确实在减小，系统是收敛的。发散检测（§11.5）的本质是检测 Lyapunov 函数是否不再单调递减。

A.3 决策理论与计算复杂性

期望效用理论

在不确定性下的理性决策，选择使期望效用最大化的行动：

$a^* = \arg\max_{a \in \mathcal{A}} \mathbb{E}[U(a, \theta)] = \arg\max_{a} \sum_{\theta} U(a, \theta) \cdot P(\theta)$

其中 $U(a, \theta)$ 是行动 $a$ 在世界状态 $\theta$ 下的效用， $P(\theta)$ 是对世界状态的信念。工具风险分级（§10.1）中的期望损失公式是这一框架的直接应用。

Exploration-Exploitation 权衡

多臂赌博机（MAB）问题的核心权衡：利用已知最优选择（exploitation）vs. 探索未知选择以获取更多信息（exploration）。在 Harness 设计中，这一权衡出现在多个层面：Agent 是沿已知有效路径执行还是尝试新策略？Skill 库是利用已验证的解法还是探索新的行动序列？

经典解法（ $\epsilon$ -greedy、UCB、Thompson Sampling）为 Harness 中的动态策略选择提供了理论基础。

资源有界计算

在有界计算资源（时间、空间、能量）约束下，最优决策不再追求全局最优，而是追求”在给定资源约束下的最优”——这是 Harness Engineering 中 Q/T/C 约束思想的理论根基。Simon 的”满意化”（Satisficing）概念与此密切相关：Agent 不需要找到全局最优解，只需要找到满足所有约束的”足够好”的解。

计算复杂性与 Agent 规划

NP-hard：给定一个解可以在多项式时间内验证，但找到解在最坏情况下需要指数时间。LLM 的长链推理中，验证（运行测试）远比生成（产生正确代码）容易——这是 NP 难的直觉。
PSPACE-complete：单 Agent 规划问题的计算复杂性类。Plan 分解是将 PSPACE 问题通过启发式拆解为多项式子问题的实践方法。
NEXP-complete：Dec-POMDP（Multi-Agent 联合规划）的计算复杂性类，比 PSPACE 难指数量级——这是 Swarm 模式成本失控的理论根据。

A.4 委托代理理论与人机关系

Principal-Agent 核心模型

委托人（Principal）将任务委托给代理人（Agent），但面临两个结构性问题：

逆向选择（Adverse Selection）：委托人无法完全了解代理人的能力类型——在 Harness 语境中，人类无法精确评估 Agent 在特定任务上的能力边界，Skill 的预验证机制（§13.4）是对这一问题的工程回应。
道德风险（Moral Hazard）：代理人的行为无法被完全观察——在 Harness 语境中，LLM 的内部推理过程不可审计，Hook 是使部分行为可观测的工程手段。

Holmström 最优合约理论

最优合约在代理人的报酬和可观测结果之间建立联系： $w = w_0 + \alpha \cdot y$ ，其中 $y$ 是可观测产出。核心洞见：合约的激励效果取决于可观测性——可观测的行为越多，合约的约束力越强。

System Prompt 作为”合约文本”（§7.2）的有效性，直接取决于其中每条规则的可观察性——能被 Hook 验证的规则才有约束力。

LLM Agent 与人类代理的本质差异

委托代理理论的经典场景假设代理人有主观利益和理性选择能力。LLM Agent 的偏差来源根本不同：不是利益驱动的策略性行为，而是训练分布的结构性偏差。这意味着：

利益绑定机制（奖金、声誉）在 LLM Agent 上无意义
约束与验证（System Prompt + Hook）替代了传统的激励设计
“信任”的建立基于行为统计（§15.5 动态信任模型），而非社会契约

A.5 马尔可夫决策过程（MDP）：Newell-Simon 框架的随机推广

本节为第四章 Newell-Simon 问题空间框架（§4.1）和第五章随机状态转换（§5.5）的严格随机对应，面向希望建立精确数学模型的读者。

从确定性问题空间到 MDP

Newell-Simon 框架 $P = \langle \mathcal{S}, \mathcal{O}, s_0, \mathcal{G} \rangle$ 将状态转换建模为确定性函数 $o: \mathcal{S} \to \mathcal{S}$ （参见第四章 §4.1）。当真实环境引入不确定性时（参见第五章 §5.5 引入的概率转换 $P(s' \mid s, o)$ ），这一框架扩展为马尔可夫决策过程：

$M = \langle \mathcal{S}, \mathcal{A}, P, R, \gamma \rangle$

其中：

$\mathcal{S}$ ：状态空间（对应 Newell-Simon 的 $\mathcal{S}$ ）
$\mathcal{A}$ ：行动集（对应 Newell-Simon 的 $\mathcal{O}$ ，此处视行动为概率性算子；以下 $a$ 即正文中 $o$ 的随机推广）
$P(s' \mid s, a)$ ：状态转换概率分布——给定状态 $s$ 与行动 $a$ ，到达状态 $s'$ 的概率（替代确定性函数；与第五章 §5.5 中 $P(s' \mid s, o)$ 的工程直觉对应）
$R(s, a, s')$ ：奖励函数——Agent 从状态 $s$ 执行行动 $a$ 到达 $s'$ 后获得的即时奖励
$\gamma \in [0, 1)$ ：折扣因子——未来奖励的权重衰减系数

两框架的概念对应关系：

Newell-Simon 概念	MDP 对应概念	扩展方向
状态空间 $\mathcal{S}$	状态空间 $\mathcal{S}$	相同
操作集 $\mathcal{O}$ （确定性）	行动集 $\mathcal{A}$ （概率性）	转换函数 → 转换分布
初始状态 $s_0$	初始状态分布 $P_0(s)$	点 → 分布
目标状态集 $\mathcal{G}$	奖励函数 $R$ （目标编码为高奖励）	集合成员 → 连续奖励信号
路径（解）	策略 $\pi(a \mid s)$	确定性序列 → 概率性决策规则

策略与最优性

在 MDP 中，Agent 的目标不是找到一条从 $s_0$ 到 $\mathcal{G}$ 的确定路径，而是找到最优策略 $\pi^*$ ：

$\pi^*(s) = \arg\max_{\pi} \mathbb{E}_{\pi}\left[ \sum_{t=0}^{\infty} \gamma^t R(s_t, a_t, s_{t+1}) \mid s_0 = s \right]$

最优策略在不确定性下最大化累积期望奖励——这对应 Harness Engineering 的目标：在概率性环境下，设计使期望输出满足 Q/T/C 约束的系统结构。

Hook 的反馈回路与策略优化的对应

MDP 提供了一个精确语言，描述 Hook 的反馈回路为在线策略优化（Online Policy Optimization）：

计算型 Hook（linter、测试）对应确定性奖励信号： $R$ 在该状态下为固定值，反馈即时且精确
语义型 Hook（LLM-as-judge）对应随机奖励信号： $R$ 是带噪声的奖励估计，需要多次采样校准
动态 Plan 修正对应在线规划（Online Planning）：Agent 在执行过程中根据新的状态观测更新策略，而非在初始状态一次性规划到底

重试策略的 MDP 最优性分析

第五章 §5.5 指出”无限重试在期望成本上是灾难性的”。MDP 提供了严格的形式化：若工具调用的成功概率为 $p$ ，成本为 $c$ ，成功奖励为 $r$ ，则最优重试次数 $n^*$ 满足：

$n^* = \left\lfloor \log\left(\frac{c}{r(1-p)}\right) / \log(1-p) \right\rfloor$

当 $p$ 极低（工具频繁失败）或 $r/c$ 较小（成功收益相对成本不高）时， $n^*$ 可以为 0——即最优策略是不重试，而是升级至人工确认或切换路径。

适用边界说明：MDP 的最优性分析假设状态转换满足马尔可夫性质（下一状态只依赖当前状态和行动）。真实 LLM Agent 的 Context 窗口使历史信息影响当前行为，严格意义上违反马尔可夫性。因此，MDP 在此处是近似模型而非精确描述；其价值在于提供可分析的理论框架，而非定量预测 Agent 的行为。

附录 B　工程模板库

B.1 System Prompt 设计模板

通用基础模板

# 角色定义
你是 [角色名称]，专注于 [领域/能力范围]。

# 能力边界
你可以：
- [允许的操作 1]
- [允许的操作 2]
- [允许的操作 3]

你不可以：
- [禁止的操作 1]
- [禁止的操作 2]

# 工作原则（按优先级排列）
1. [最高优先级原则——通常是安全或正确性相关]
2. [次要原则——通常是质量相关]
3. [第三原则——通常是效率或风格相关]

# 输出规范
- 格式：[JSON / Markdown / 纯文本 / 结构化报告]
- 必须包含：[必要字段列表]
- 不确定时：[如何表达不确定性——如"标注置信度"或"请求人工确认"]

代码工程场景模板

# 角色定义
你是一个高级软件工程师，在 [语言/框架] 代码库中工作。

# 能力边界
你可以：读取文件、搜索代码、编辑文件（apply_patch）、运行测试、运行 linter
你不可以：删除文件、修改 CI/CD 配置、安装依赖、推送到主分支

# 工作原则
1. 先理解再修改——读取相关模块和测试，理解接口契约后再动手
2. 最小修改原则——只改需要改的，不做未经要求的重构
3. 每次修改后验证——编辑文件后立即运行相关测试
4. 保持一致性——遵循现有代码风格和架构约定

# 输出规范
- 代码修改使用 apply_patch 格式
- 每次修改附说明：改了什么、为什么改
- 遇到不确定的设计决策时，列出选项和各自的权衡

数据分析场景模板

# 角色定义
你是一个资深数据分析师，擅长从数据中提炼有价值的洞察。

# 能力边界
你可以：加载数据、数据清洗、统计分析、生成可视化、编写报告
你不可以：修改原始数据源、访问外部网络、安装新库

# 工作原则
1. 数据优先——任何结论必须有对应的数据支撑
2. 方法适配——统计方法的前提假设必须与数据特征匹配
3. 先探索再聚焦——不跳过探索性数据分析直接下结论
4. 诚实标注——标注分析的局限性和不确定性

# 输出规范
- 报告结构：执行摘要 → 数据概览 → 核心发现 → 方法论 → 局限性
- 每个核心发现配支撑性可视化
- 统计方法注明前提假设和检验结果

B.2 Plan Schema 模板

标准版

{
  "goal": "[任务目标的一句话描述]",
  "context": "[当前状态摘要，支撑目标理解]",
  "steps": [
    {
      "id": 1,
      "action": "[具体行动描述]",
      "expected_output": "[该步骤的预期产出]",
      "verification": "[如何验证该步骤完成——测试、检查项、人工确认]",
      "fallback": "[该步骤失败时的替代方案]",
      "estimated_cost": {
        "tokens": 0,
        "time_sec": 0
      },
      "risk_level": "low|medium|high",
      "requires_approval": false
    }
  ],
  "success_criteria": "[可验证的完成标准]",
  "abort_conditions": [
    "[条件1：触发中止的具体条件]",
    "[条件2]"
  ],
  "total_budget": {
    "max_tokens": 0,
    "max_time_sec": 0,
    "max_retries": 0
  }
}

轻量版（适用于简单任务）

{
  "goal": "[目标]",
  "steps": [
    { "action": "[步骤1]", "check": "[验证方式]" },
    { "action": "[步骤2]", "check": "[验证方式]" }
  ],
  "done_when": "[完成标准]",
  "stop_if": "[中止条件]"
}

B.3 Tool 权限声明模板

tool_permissions:
  - name: "[工具名称]"
    description: "[工具功能描述]"
    risk_level: "read_only | idempotent_write | non_idempotent_write | irreversible_write"
    side_effects:
      - type: "[副作用类型：文件修改 / 网络请求 / 状态变更]"
        reversible: true | false
        scope: "[影响范围：单文件 / 项目 / 外部系统]"
    approval_policy:
      default: "auto_allow | plan_step_confirm | human_confirm | blocked"
      conditions:
        - when: "[特定条件]"
          then: "[该条件下的策略]"
    rate_limit:
      max_calls_per_minute: 0
      max_calls_per_task: 0
    monitoring:
      log_level: "minimal | standard | verbose"
      alert_on: "[触发告警的条件]"

示例：文件编辑工具权限

tool_permissions:
  - name: "apply_patch"
    description: "对指定文件应用补丁修改"
    risk_level: "non_idempotent_write"
    side_effects:
      - type: "文件修改"
        reversible: true  # git 可回退
        scope: "单文件"
    approval_policy:
      default: "auto_allow"
      conditions:
        - when: "修改文件不在 Plan 声明的文件列表中"
          then: "plan_step_confirm"
        - when: "修改配置文件（*.config, *.yml, *.env）"
          then: "human_confirm"
    rate_limit:
      max_calls_per_minute: 30
      max_calls_per_task: 200
    monitoring:
      log_level: "standard"
      alert_on: "单次修改超过 100 行"

B.4 Hook Pipeline 模板

单 Agent 版

hook_pipeline:
  pre_tool_use:
    - name: "权限检查"
      type: "computational"
      latency: "< 1ms"
      action: "block | warn | log"
      rules:
        - "操作必须在当前 Agent 的允许操作集内"
        - "目标资源必须在允许的范围内"

    - name: "输入格式验证"
      type: "computational"
      latency: "< 5ms"
      action: "block"
      rules:
        - "工具参数符合 Schema 定义"
        - "必要参数均已提供"

    - name: "危险模式检测"
      type: "rule_based"
      latency: "< 10ms"
      action: "block | escalate"
      rules:
        - "不可逆操作需要对应审批级别"
        - "检测已知的危险操作模式"

  post_tool_use:
    - name: "输出格式验证"
      type: "computational"
      latency: "< 5ms"
      action: "warn | retry"

    - name: "错误检测与分类"
      type: "rule_based"
      latency: "< 10ms"
      action: "log | update_context"
      output: "结构化错误信息回写 Context"

    - name: "发散检测"
      type: "rule_based"
      latency: "< 10ms"
      action: "warn | force_replan"
      rules:
        - "同一工具连续 N 次相似失败"
        - "token 消耗速率加速"

    - name: "语义质量评估"
      type: "semantic"
      latency: "~2s"
      trigger: "高成本操作完成后 / 采样执行"
      action: "score | suggest_revision"

  stop:
    - name: "完成标准验证"
      type: "computational"
      action: "pass | fail"
      rules:
        - "Plan 中的 success_criteria 全部满足"

    - name: "整体质量评估"
      type: "semantic"
      action: "pass | revision_needed | escalate"

  escalation_policy:
    levels:
      - level: 1
        name: "自动纠正"
        trigger: "可逆操作 + 已知错误模式"
        action: "Hook 直接修正，记录日志"
      - level: 2
        name: "人工确认"
        trigger: "不可逆操作 / 偏离 Plan / 成本异常"
        action: "中断执行，等待人类批准"
      - level: 3
        name: "任务中止"
        trigger: "安全红线 / 成本熔断 / 发散失控"
        action: "立即中止，告警通知"

  storm_prevention:
    max_hook_depth: 5
    max_same_hook_per_minute: 10
    cost_circuit_breaker: "总 Hook 成本 > 任务预算的 20%"

Multi-Agent 扩展版

在单 Agent 版基础上增加：

multi_agent_extensions:
  global_hooks:
    - name: "跨 Agent 成本汇总"
      scope: "system"
      trigger: "每 60 秒 / 每个 Agent 完成一个步骤"
      action: "更新全局成本仪表盘"

    - name: "状态一致性检查"
      scope: "system"
      trigger: "任何 Agent 修改共享状态后"
      action: "验证版本戳 / 检测写-写冲突"

    - name: "全局发散检测"
      scope: "system"
      trigger: "每 5 分钟"
      rules:
        - "已完成任务数是否在增长"
        - "消息队列是否积压"
        - "任何 Agent 沉默超过 N 分钟"

  observability:
    tracing:
      format: "{trace_id, span_id, parent_span_id, agent_id, timestamp, operation, input_hash, output_hash, cost}"
    message_timeline: true
    observer_agent: true

B.5 Skill 文档模板

# Skill: [名称]

## 元信息
- 版本：[v1.0]
- 创建日期：[YYYY-MM-DD]
- 最后验证：[YYYY-MM-DD]
- 验证次数：[N 次成功应用]
- 状态：[活跃 / 待验证 / 已弃用]

## 适用场景
[精确描述何时应该使用这个 Skill——包含正向条件和边界条件]

## 不适用场景
[明确描述何时不应该使用——这与"适用场景"同等重要]

## 前提条件
- [条件 1：使用前必须满足的技术条件]
- [条件 2：使用前必须满足的环境条件]

## 步骤
1. **[步骤名称]**
   - 操作：[具体行动]
   - 预期结果：[该步骤完成后应该看到什么]
   - 关键上下文：[执行此步骤时需要关注的信息]

2. **[步骤名称]**
   - 操作：[具体行动]
   - 预期结果：[预期结果]
   - 关键上下文：[关键信息]

## 常见陷阱
- **[陷阱名称]**：[陷阱描述] → 避免方式：[如何避免]
- **[陷阱名称]**：[陷阱描述] → 避免方式：[如何避免]

## 验证标准
[如何判断 Skill 是否被正确执行——可观测的成功标志]

## 演化记录
- [YYYY-MM-DD] v1.0：初始版本，基于 [N] 次任务经验
- [YYYY-MM-DD] v1.1：[修改描述]，触发原因：[什么信号触发了更新]

附录 C　评估指标参考

C.1 Q/T/C 度量指标完整清单

质量维度（Q）

指标	定义	数据收集方法	适用场景
功能正确率	通过验收标准的任务比例	自动化测试 + 验收检查	有明确正确性标准的任务
测试通过率	通过的测试用例 / 总测试用例	CI/CD 集成	代码生成/修复任务
LLM-as-judge 评分	语义质量的 0-10 分评估	独立 judge 模型调用	无客观标准的输出质量
人工审核通过率	人类审核通过的输出比例	人工审核记录	所有场景（黄金标准）
输出一致性	相同输入多次运行的输出方差	多次采样 + 相似度计算	要求稳定性的场景
回归率	引入新问题的任务比例	回归测试套件	代码修改任务
幻觉率	包含不正确事实的输出比例	事实核查（自动 + 人工）	知识密集型任务

时间维度（T）

指标	定义	数据收集方法	告警阈值参考
端到端延迟 P50	50% 任务在此时间内完成	时间戳记录	视场景而定
端到端延迟 P95	95% 任务在此时间内完成	时间戳记录	P95 > 3× P50
端到端延迟 P99	99% 任务在此时间内完成	时间戳记录	P99 > 5× P50
每任务步骤数	完成任务所需的工具调用次数	日志计数	> 2× 历史均值
超时率	超过时间预算的任务比例	超时记录	> 10%
重试次数	因失败重试的平均次数	重试日志	> 3 次/步骤
首次成功率	无需重试即成功的步骤比例	日志分析	< 70%

成本维度（C）

指标	定义	数据收集方法	告警阈值参考
每任务 token 消耗	完成一个任务的总 token 数	API 调用记录	> 2× 历史均值
token 消耗细分	分到各构件的 token 消耗	结构化日志	任一构件 > 50%
每任务 API 成本	完成一个任务的货币成本	计费记录	> 预算上限的 80%
人工介入率	需要人工介入的任务比例	介入记录	> 30%（成熟系统）
人工平均处理时间	每次人工介入的平均耗时	时间记录	> 5 分钟/次
成本方差	任务成本的标准差 / 均值	统计计算	CV > 1.0
Hook 成本占比	Hook 运行的 token 消耗 / 总消耗	结构化日志	> 25%

C.2 LLM-as-judge 评估框架设计指南

Judge Prompt 结构

# 评估任务
你将评估一个 [Agent 类型] 的输出质量。

# 评估维度（按权重排列）
1. [维度 1]（权重 [W1]%）：[评估标准的精确描述]
2. [维度 2]（权重 [W2]%）：[评估标准的精确描述]
3. [维度 3]（权重 [W3]%）：[评估标准的精确描述]

# 评分标准
- 9-10：[该分数段的具体表现描述]
- 7-8：[该分数段的具体表现描述]
- 5-6：[该分数段的具体表现描述]
- 3-4：[该分数段的具体表现描述]
- 1-2：[该分数段的具体表现描述]

# 评估流程
1. 首先，逐维度分析输出的表现，给出每个维度的具体得分和依据
2. 然后，计算加权总分
3. 最后，给出改进建议（如果总分 < 7）

# 输入
## 任务描述
[原始任务]

## Agent 输出
[待评估的输出]

# 输出格式
{
  "dimensions": [
    { "name": "[维度]", "score": 0, "justification": "[具体依据]" }
  ],
  "total_score": 0,
  "improvement_suggestions": ["[建议]"]
}

已知偏差与校准方法

偏差类型	表现	校准方法
长度偏差	更长的输出获得更高评分	在 prompt 中明确”简洁性是质量维度”
自我一致偏差	偏好与自身生成风格相似的输出	使用不同模型或参数作为 judge
位置偏差	靠前的选项获得更高评分	随机化选项顺序
权威偏差	更正式的语气获得更高评分	评估维度聚焦于实质内容
锚定偏差	评分受前一个评估影响	独立评估，不累积历史

校准流程

准备标定数据集（50-100 个样本，含人类标注的质量评分）
用 judge 评估标定集，计算 judge 评分与人类评分的相关性
识别系统性偏差方向和幅度
调整 judge prompt 或后处理逻辑
重新评估，直至相关性 > 0.7（Pearson r）
定期（每月或每 1000 次评估后）用新标定样本重新校准

C.3 成本基准：常见 Agent 任务的 token 消耗参考范围

以下数据基于中等复杂度的实际任务，使用主流模型（GPT-4 级别），仅供参考——实际消耗受任务复杂度、Harness 设计质量、模型版本等因素显著影响。

任务类型	Token 消耗范围（典型）	步骤数范围	关键成本驱动因素
简单代码修复（单文件）	20K - 80K	5-15	上下文加载 + 测试轮次
中等功能实现（多文件）	100K - 400K	15-40	代码理解 + 迭代修复
复杂重构（跨模块）	300K - 1M+	30-80+	状态管理 + 回归测试
数据探索与分析	150K - 600K	20-50	数据探索 + 可视化生成
文档生成	50K - 200K	10-25	源材料理解 + 多轮修订
Multi-Agent 代码审查	200K - 800K	—	多 Agent 通信 + 审查轮次

成本优化的常见杠杆点：

Context 分层：将低价值历史从 Context 移除，可减少 20-40% 的 token 消耗
Compaction 时机：在 70% 而非 90% 触发 Compaction，可避免关键步骤中的 Context 溢出
工具结果精炼：要求工具返回结构化摘要而非原始输出，可减少 30-50% 的回写成本
Plan 粒度：过细的 Plan 步骤增加 Plan 本身的 token 开销，最优粒度使规划成本 < 总成本的 15%
语义型 Hook 采样：不是每次工具调用后都运行 LLM-as-judge，而是按风险级别采样触发

附录 D　本书知识谱系

D.1 与现有文献的关系

本书与以下领域的文献有直接的理论关联：

实践操作手册类

Building LLM Apps、Prompt Engineering 实践指南等——这类文献提供了操作层面的”怎么做”。本书与它们的区别在于：本书追问”为什么这样做有效”，试图为经验实践提供理论根基。两类文献互补而非竞争——读者可以在本书的理论框架下重新理解实践手册中的具体技巧，也可以用实践手册中的具体案例验证本书的理论命题。

Andrew Ng 的 AI Agent 框架

Ng 提出的 Agentic Design Patterns（Reflection, Tool Use, Planning, Multi-Agent Collaboration）与本书的构件设计有直接对应关系。本书的额外贡献在于：为这些模式提供了来自控制论、信息论、决策理论、委托代理理论的分析语言，使设计决策可以在理论框架内被论证而非仅凭直觉。

控制论经典文献

Wiener《Cybernetics》（1948）、Ashby《An Introduction to Cybernetics》（1956）——反馈回路、必要多样性定律等核心概念直接进入本书的分析框架（第五章、第十一章）。本书的特殊贡献是将这些经典概念应用于概率性智能系统——一个 Wiener 和 Ashby 时代尚不存在的系统类型。

决策理论经典

von Neumann & Morgenstern《Theory of Games and Economic Behavior》（1944）、Savage《The Foundations of Statistics》（1954）——期望效用理论、统计决策理论。Sutton & Barto《Reinforcement Learning》（2018）——MDP 框架与策略优化。本书将这些框架从”Agent 学习”的语境迁移到”Agent 约束”的语境——不是训练 Agent 选择更好的策略，而是设计 Harness 使好的策略更容易被选到。

计算复杂性经典

Garey & Johnson《Computers and Intractability》（1979）——NP 完全性理论的经典参考。本书引用的 PSPACE-complete（单 Agent 规划）和 NEXP-complete（Multi-Agent 联合规划）结果为 Harness 设计的必要性提供了计算理论依据。

委托代理理论经典

Holmström（1979）的最优合约理论、Jensen & Meckling（1976）的代理成本理论——本书将经济学中的委托-代理框架迁移到人机系统设计中，但明确标注了关键差异：LLM Agent 的偏差来自训练分布而非利益驱动，约束机制应相应调整。

软件工程经典

Brooks《人月神话》（1975）——“没有银弹”的论断在概率性系统中有新的含义。Gamma 等《设计模式》（1994）——模块化、关注点分离等原则在概率性范式中的深化（§19.2）。本书试图回答：当软件系统的核心组件从确定性算法变为概率性 LLM 时，哪些工程原则保持不变、哪些需要在新维度上重新理解。

D.2 未解决的开放问题

Harness Engineering 仍然是一个年轻领域。本书有意在第十八章对以下四个根本性开放问题进行展开讨论，此处仅作索引：

Agent 评估的根本难题——如何验证”足够好”？当 Agent 能力超过评估者时，质量度量面临认识论挑战（参见 §18.1）。
Harness 的自动优化极限与自指设计悖论——系统修改约束自身规则时，安全性保证依赖于被修改前的规则（参见 §18.2）。
多 Agent 系统的涌现行为预测与形式验证边界——整体行为无法从单 Agent 行为叠加预测（参见 §18.3）。
人类判断的不可替代边界——是能力边界（持续收缩）还是合法性边界（结构性稳定）（参见 §18.4）？

关于术语规范的说明

本书中，“驭具”是”Harness”的中文对应词，首次出现后交替使用，含义相同。“Harness Engineering”（驭具工程）与”Agent Engineering”在本书语境中视为同义词，前者强调框架视角，后者强调领域范畴。公式符号体系： $\mathcal{F}$ （可行解集）、Q/T/C（三轴约束）在全书中保持一致，首次使用后不再重复定义。

附录

附录 A 理论背景（选读）

附录 B 工程模板库

附录 C 评估指标参考

附录 D 本书知识谱系

附录 A　理论背景（选读）

附录 B　工程模板库

附录 C　评估指标参考

附录 D　本书知识谱系