第三章　分析框架：三轴约束与理论视角

核心命题：Harness Engineering 需要多个理论框架协同描述。本章建立全书的分析语言——以三轴约束（Q/T/C）为工程核心，以六个理论视角为参考工具箱。这六个视角按分析对象归为三类：搜索结构（问题空间理论、计算复杂性）、系统动态（控制论、委托代理理论）、信息流动（信息论、决策理论）。它们被选入的理由是：在具体 Harness 设计问题上能提供比直觉更精确的分析语言——而非因为它们共同构成一套封闭完备的理论体系。这六个视角不必然两两严格互补，它们在不同问题上的照亮效果也参差不齐；理解它们的作用，比理解它们之间的结构关系更重要。

快速参考指南

本章分为三个层次，可按需阅读：

  • 3.1 三轴约束（Q/T/C）：全书的工程核心语言，所有读者必读。后续每章的设计决策都将在这个坐标系中表达。
  • 3.2 六个理论视角 和 3.3 横向联系：为特定工程决策提供额外的分析角度。如果你主要关心工程实践，第一次阅读可跳过这两节，在后续章节遇到具体设计问题时回查对应理论——每个构件章节都会在需要时引回本章的相关视角。
  • 3.4 工作性整合：六个视角的粗略汇总，可在跳过 3.2-3.3 后直接阅读，用于建立整体印象——这是便于记忆的工作性表述，不是严格的理论推导结论。

3.1 三轴约束：可行解集的精确定义

质量轴（Quality）：解必须满足正确性门槛——可验证的、语义符合意图的、无副作用越界的。

时间轴（Time）：解必须在可接受的时间窗口内产生。时间约束是非对称的：三天后的完美答案在需要十分钟响应的场景中价值为零。

成本轴（Cost）：解必须在可接受的资源消耗内产生。包含三个子维度：计算成本（token 消耗、API 调用）、时间成本的货币化、人类注意力成本（审批、纠错次数）。

三轴共同定义可行解集：

F={s∈S∣Q(s)≥Qmin⁡, T(s)≤Tmax⁡, C(s)≤Cmax⁡}\mathcal{F} = \{ s \in \mathcal{S} \mid Q(s) \geq Q_{\min},\ T(s) \leq T_{\max},\ C(s) \leq C_{\max} \}

可行解集的存在性不是自明的：约束过严时交集为空，任务不可行。可行解集内部存在帕累托前沿——质量、速度、成本之间存在不可消除的权衡曲面。Harness 的设计选择，本质上是在选择这条曲面上的工作点。

Q/T/C 的可测量指标（工程落地）：

  • Q：测试通过率、语义评分（LLM-as-judge）、人工审核通过率
  • T：端到端延迟、P95 响应时间、超时率、重试次数
  • C：每任务 token 消耗、每任务 API 花费、人工介入次数

3.2 六个理论视角：按分析对象分组

六个理论按分析对象归为三类，这种分类是描述性的而非规范性的——它有助于呈现各视角的关注点，但不意味着 Harness 面临的问题恰好被这三类覆盖，也不断言每组内的两个视角必然构成严格互补的对子：

组一：描述搜索结构

Agent 在什么样的空间中搜索？搜索的代价结构是什么？

理论核心洞见Harness 的对应命题主要出现章节
问题空间理论搜索在结构化的可能性空间（状态、操作、目标）中发生Harness 定义操作集 O，将解空间从指数压缩到可行域 F\mathcal{F}第三、九、十章
计算复杂性搜索的最优解通常在计算上不可行；近似是资源约束下的必然选择Plan 是将 PSPACE 问题分解为多项式子问题的启发式；Skill 是将 O(bd)O(b^d) 搜索压缩为 O(1)O(1) 检索的记忆化机制第九、十三、十四章

从这两个视角来看，同时压缩分支因子 bb 和路径深度 dd 是 Harness 的核心工作——问题空间理论刻画了这样做的几何意义，计算复杂性说明了不这样做的代价。两者在关注点上互相补充，但并非必然配对，它们各自也可以独立应用于不同的设计问题。

组二：描述系统动态

系统如何随时间演化？如何在监督条件下收敛到目标？

理论核心洞见Harness 的对应命题主要出现章节
控制论目的性行为通过反馈回路实现；必要多样性定律决定控制器最小规模Harness 是控制器；Loop/Hook 是反馈回路的制度化实现；收敛与发散的判别决定了 Hook 的设计第四、十一章
委托代理理论委托人（人类）与代理人（Agent）之间存在信息不对称与行为难以直接观察System Prompt 是激励合约；Plan 是行动前报告；Hook 是监督装置；Human on the Loop 是监督成本最小化的工程解第七、十、十五章

控制论从工程动力学视角关注收敛（反馈如何驱动系统朝目标状态演化），委托代理理论从经济学激励视角关注对齐（监督如何在信息不对称下维持行为合规）。两者在 Hook 的设计问题上往往从不同方向指向类似的结论——但这种汇合是局部的，不意味着它们描述的是同一件事。

组三：描述信息流动

意图如何在有限带宽下被传递？行动如何在不确定性下被选择？

理论核心洞见Harness 的对应命题主要出现章节
信息论通信在有限带宽信道中发生；信息损耗在压缩中不可避免Context 是受限信道；Harness 最大化 I(意图;输出)I(\text{意图}; \text{输出})；Compaction 是必要的有损压缩第五、八章
决策理论在不确定性下，行动选择应最小化期望损失工具风险分级有期望损失公式依据；升级策略是阈值决策问题；评估是接受/拒绝的统计决策第十、十一、十三章

信息论关注意图如何被传递（从人类到 Agent 的信道效率），决策理论关注信息接收后如何选择行动（在不确定性下的损失最小化）。两者在关注点上顺序衔接：Context Engineering 与 Hook/Tool 设计分别是各自较为直接的工程落地——但这种对应关系是事后观察到的，而非理论设计使然。

3.3 视角之间的横向联系

不同视角在处理同一个 Harness 设计问题时，有时会从不同方向指向相近的结论。这些交叉不是必然存在的，但当它们出现时，往往说明该结论有多重分析依据——在实践中值得优先关注。以下是几个观察到的交叉点：

  • 搜索结构 ↔ 信息流动：计算复杂性从可处理性视角约束 Context 的上界（过长的 Context 导致推理退化）；信息论从带宽视角约束 Context 的构建策略（token 预算的分配）。两者从不同维度照亮了 Context Engineering 的边界条件，在这个具体问题上，Q/T/C 约束在两个视角中都有理论根基。

  • 系统动态 ↔ 搜索结构：操作集 O 的边界设计（问题空间视角）与反馈回路的收敛设计（控制论视角）在分析层面互相呼应——前者限制可能的动作，后者保证已执行动作的方向收敛；委托代理的激励约束设计（允许列表）与问题空间理论的最小操作集原则，也恰好从不同出发点指向相近的工程建议。

  • 信息流动 ↔ 系统动态：信道容量不足（信息论视角）是信息不对称（委托代理视角）的工程来源之一；提升意图传递效率（信息论优化）是缓解信息不对称的一条工程路径。决策理论与委托代理理论在 Hook 升级阈值设计问题上也有交叉——前者提供期望损失最小化的阈值计算依据，后者提供激励相容的分层设计视角。

框架交叉对照表：

描述搜索结构描述系统动态描述信息流动
描述搜索结构—操作集设计与反馈收敛互为约束计算复杂性与信息论共同约束 Context 边界
描述系统动态最小操作集原则 ↔ 最优合约设计—信息不对称的根源是信道容量不足
描述信息流动Q/T/C 约束的双重理论来源决策理论 + 委托代理在 Hook 中汇合—

计算复杂性与委托代理理论的特别说明：这两个理论对工程师而言相对陌生。

  • 计算复杂性：为什么 Agent 任务必须近似？因为最优搜索在计算上不可行——不是工程做得不够好，而是长链推理可类比为 NP 难问题（甚至更难）。Harness 提供的结构化启发式（System Prompt 约束、Plan 分解、Skill 记忆化）将指数搜索压缩到多项式级别的可行域。边界说明：此处描述最坏情况理论下界；实际 LLM 行为是概率性的，不适用经典确定性假设。

  • 委托代理理论：原始场景中代理人是有主观利益的人类，LLM Agent 的行为偏差来自训练分布而非利益驱动。框架在结构层面成立（信息不对称、监督成本真实存在），但干预机制有根本差异：对人类代理需要利益绑定，对 LLM Agent 需要约束与验证。四个核心问题的 Harness 对应：信息不对称 → Plan-before-Act；道德风险 → System Prompt 约束 + Hook 检查；逆向选择 → Skill 的预验证机制；监督成本 → Hook 的分层传感器设计。

3.4 工作性整合

以下表述不是从六个视角推导出的共同结论，而是一个便于定位的工作性汇总——它概括了这些视角在 Harness 设计问题上的大致共同关切，但省略了各视角自身的边界条件与内部差异。请将它作为导航工具，而非分析起点：

在质量、时间、成本的三重约束下，将 Agent 行为的可能性空间工程化：在结构化的搜索空间中定义可达的行动边界（问题空间理论），在有界计算资源下接受并设计近似解（计算复杂性）；在有限带宽信道上最大化意图传递效率（信息论），在不确定性下最小化行动选择的期望损失（决策理论）；通过反馈回路使系统收敛到目标状态（控制论），通过监督机制与激励约束对抗信息不对称（委托代理理论）——使期望输出成为在三轴约束内最可能的系统结果。

章末案例剖析

同一个技术任务类型——代码分析——在两种截然不同的部署场景中，产生了截然不同的 Harness 设计。三轴约束框架提供的分析语言，使这种差异不再是”直觉上的不同”，而是可以精确定位的设计选择：每一个差异都可以追溯到 Q/T/C 可行解集中不同约束的主导地位，以及随之产生的帕累托工作点的移动。

说明：以下两个场景的具体数值（响应时间阈值、token 单价、每日预算、批处理窗口、命中比例等）均为基于作者工程实践的说明性示例，旨在量化呈现 T 主导与 C 主导两种工作点下的结构性差异，非实测基准。

场景一：交互式编程助手（T 主导）

场景描述：工程师在 IDE 中使用 AI 辅助编写代码，频繁提问（语法、逻辑、调试），期待即时响应。典型请求包括：“这个函数有什么问题？""帮我把这段代码改成异步版本。“每次会话持续几分钟，工程师注意力连续投入。

Q/T/C 约束的实际值：

  • T_max ≈ 8 秒：认知流被打断的阈值。超过这个时间，工程师会切换注意力，等响应回来时已经失去上下文。时间约束是刚性的——三天后的完美答案价值为零（§3.1 的非对称性在此最为显著）。
  • Q_min：较低。工程师会立即看到输出，若有误立刻追问。输出质量的下界不是”绝对正确”，而是”足够接近正确以触发有意义的对话”。错误不是灾难——它是下一次交互的输入。
  • C_max：相对宽松。单次请求成本通过订阅分摊，工程师不直接感知 token 消耗。成本主要以”响应延迟的机会成本”而非”API 费用”计量。

Harness 设计选择（T 主导下的权衡）：

  • System Prompt：简短紧凑，优先加载速度。避免列举边界情况（每条额外指令是 input token，input token 的延迟贡献不可忽视）。接受模糊性——人类在环，边界案例可以追问。
  • Context Manager：激进截断。当前文件 + 光标附近的函数 + 最近 3 轮对话，其余丢弃。不是因为其他信息不重要，而是信息密度换延迟在此处是正确的选择——贡献最大的上下文代价最小。
  • Plan：对简单查询跳过规划阶段（一次额外的 LLM 调用 ≈ 3-5 秒延迟）。只有明确的多步任务（“重构这个模块”）才触发 Plan，且 Plan 本身通过流式输出与执行并行呈现。
  • Tool：只暴露低延迟工具（文件读取、符号查找、语法检查）。任何响应时间超过 1 秒的工具都不在 Action 的默认工具集中。
  • Hook：Pre-Hook 只做输入安全检查（拒绝包含凭证的 Context），Post-Hook 不使用 LLM-as-judge（额外一次 LLM 调用的延迟不可接受）。质量保障的主要机制是人类即时审查而非系统内部验证。
  • 反馈结构：流式输出（Streaming），用户在生成过程中即开始阅读。人类注意力成本（C 的第三个子维度）通过即时可见的进度降低。

场景二：批量代码审查（C 主导）

场景描述：一个工程平台在每次 PR 合并前，自动对代码变更进行安全漏洞、性能问题和规范合规检查。每天处理约 300 个 PR，结果写入 PR comment 供人工复核。没有用户在等待——任务在后台运行，工程师次日早晨查看报告。

Q/T/C 约束的实际值：

  • C_max 严格：300 PR/天 × 平均成本上限 0.15/PR=0.15/PR = 45/天 的 API 预算。每次 token 消耗都乘以处理量，边际成本直接影响项目可行性。
  • Q_min：高，且不对称。漏报（false negative）的代价远高于误报（false positive）：遗漏一个真实安全漏洞的代价 >> 多报一个不存在问题的代价。质量约束主要是”不能漏”，不是”不能多”。
  • T_max ≈ 4 小时：夜间批处理窗口内完成即可。时间约束极其宽松——这个宽松的时间预算可以被交换为计算精度的提升。

Harness 设计选择（C 主导下的权衡）：

  • System Prompt：长且精确，强调不对称的质量要求——“宁可误报，不可漏报”明确写入指令。System Prompt 的 token 成本被摊薄在 300 次调用上；每条额外指令如果减少哪怕 2% 的重试率，都是成本正收益。
  • Context Manager：智能预过滤而非激进截断。静态分析工具（AST 解析、调用图）在 LLM 调用前运行，只将 diff 中涉及的函数的完整调用关系注入 Context。目标：每个 LLM 调用的信息密度最大化，避免为冗余信息支付 token 成本。
  • Plan：多阶段流水线。第一阶段：小模型（低成本）对所有 PR 做分类（安全相关/性能相关/无显著问题），输出分类标签；第二阶段：大模型只处理第一阶段标记为”安全相关”的 PR，进行深度分析。这将昂贵调用的数量从 300 降到约 60（假设 20% 的 PR 涉及安全敏感路径）。
  • Tool：优先使用确定性静态分析工具（Semgrep 规则匹配、依赖版本检查），LLM 只在静态工具无法覆盖的语义问题上才被调用。每个被静态工具截获的问题节省了一次 LLM 调用成本。
  • Hook：Pre-Hook 重量级——在任何 LLM 调用前验证输入（diff 格式、文件大小、语言类型），不合规输入直接返回”跳过”而非消耗 token 试图处理。Post-Hook 包含完整的 JSON Schema 校验 + 去重 + 严重度分级。LLM-as-judge 用于高严重度输出的二次确认（此时额外 token 成本相对于漏报代价是合理投入）。
  • 缓存层：相同或高度相似的代码模式（如 diff 只修改注释）使用语义哈希判重，命中缓存则直接返回上次结果。

两个场景在各构件上的设计差异

构件交互式助手（T 主导）批量代码审查（C 主导）
System Prompt简短；接受模糊性；不枚举边界长且精确；明确不对称质量要求
Context激进截断；优先局部相关性智能预过滤；最大化信息密度
Plan简单查询跳过；仅复杂任务规划强制多阶段（分类 + 深度分析）
Tool仅低延迟工具；动作集受限静态分析优先；LLM 工具按需门控
Hook最小化；无 LLM judge前置重量级验证；后置 LLM judge 选择性用
反馈机制人类即时反馈为主要质量保障系统内部 Hook 为主要质量保障
错误处理用户追问纠错（成本低）重试 + 降级 + 告警（用户不在场）

理论视角的印证

这两个场景的差异在本章的六个理论视角下各有对应：

从计算复杂性看：批量场景以宽松的 T_max 换取了可以执行更深搜索（多阶段分析）的计算预算，帕累托权衡点向质量轴移动；交互场景则相反，以牺牲搜索深度换取响应速度。这不是工程水平的差异，而是可行解集内两个不同工作点的选择。

从信息论看：两个场景对 Context 信道的使用策略恰好相反——交互场景用高带宽的人类反馈弥补 Context 截断的信息损失（人类在环是隐式的纠错信道）；批量场景用更精准的 Context 构建弥补人类不在场的缺位（预处理是显式的信息密度提升）。

从委托代理理论看：交互场景中人类监督成本极低（即时可见输出），可以接受更少的系统内部监督装置（Hook 最小化）；批量场景中人类次日才审查，监督成本高，因此系统内部监督必须更完备（多层 Hook + 严重度分级）。

结论：Q/T/C 框架的价值不只在于命名三个维度，而在于将”设计风格”转化为”约束优先级的显式选择”。当工程师说”这个场景我要做得快一点”时，Q/T/C 框架迫使他们明确：快多少（T_max 的数值）、以牺牲什么为代价（Q 下限的放松或 C 上限的上移）、这个权衡在帕累托曲面上的位置是否可行（可行解集是否非空）。同一个技术问题，因为 Q/T/C 工作点的不同，产生了逻辑上完全一致但形态截然相反的 Harness 设计——这正是三轴约束框架作为分析语言的核心作用。