第五章　反馈系统 | 深度驭具工程

第五章　反馈系统：收敛、发散与控制论基础

核心命题：一切 Harness 机制的底层，是反馈回路。理解反馈回路的动态行为——特别是收敛与发散的判别条件——是设计可靠 Harness 的起点。

5.1 最简单的 Agent 回路

感知 → 推理 → 行动 → 感知。没有这个回路，LLM 只是一个函数；有了这个回路，它才成为 Agent。反馈回路是控制论（Wiener, 1948）的核心概念——通过将系统输出反馈至输入端，使系统获得目的性行为（goal-directed behavior）。必要多样性定律（Ashby, 1956）进一步给出控制器的最小规模约束：控制器的状态多样性 $H(\text{控制器})$ 必须足以吸收被控系统的扰动多样性 $H(\text{扰动})$ （详见附录 A.2）。这条定律直接决定了 Harness 不能任意简化——一个过于简单的 Harness 无法约束行为多样的 Agent。

5.2 逻辑斯蒂映射作为直觉工具

$x_{n+1} = r \cdot x_n(1 - x_n)$

边界说明：逻辑斯蒂映射是一维确定性系统；Agent 是高维概率性系统。此处将其作为直觉工具，帮助建立对”非线性增益参数 r 如何决定系统动态”的定性理解，不作为对 Agent 行为的定量预测。

定性对应：r 较小（系统响应被过度抑制）→ 收敛至单一不动点，行为过于保守、丧失灵活性；r 适中（增益与衰减平衡）→ 周期轨道或有限吸引子，行为动态稳定且具备探索能力；r 较大（响应被过度放大）→ 进入混沌区，对初值极度敏感、行为不可预测、成本失控。“混沌边缘最优”是启发性假设，不是已证定理（Langton 假说的学术争议在附录中讨论）。

5.3 收敛还是发散：核心判别

设计反馈回路时的核心问题：这个回路是在帮助系统收敛（朝向目标状态），还是在制造发散（放大误差、陷入循环）？

收敛型回路的特征：每次反馈减少与目标的距离；误差信号被适当衰减后传回。发散型回路的特征：误差被放大而非衰减；小的初始偏差导致越来越大的振荡；最终耗尽时间或成本预算而无质量产出。

可操作的判别形式：定义一个状态距离度量 $V(s_n) \geq 0$ ，刻画当前状态 $s_n$ 与目标集 $\mathcal{G}$ 的”距离”——可以是失败测试数、未满足的必要子条件数、与目标之间的语义差距等任何随距离单调的量。回路收敛的工程判据是 $V(s_{n+1}) < V(s_n)$ 在多数轮次成立（Lyapunov 单调递减条件的离散弱化形式，详见附录 A.2）；当 $V$ 长时间不再下降甚至上升，回路即进入发散态。

实际案例：一个常见的发散模式——Agent 收到测试失败信号后，产生了错误的修复，新的错误触发新的测试失败，陷入无限循环。此时 $V(s_n)$ （失败测试数）不仅不减反而上升。识别这类模式的早期信号：相似的失败消息重复出现、每轮对话的 token 消耗增大而 $V$ 无进展。

5.4 失败作为收窄信号：信号有效性的判别

收敛/发散的判别给出了”何时反馈在起作用”的标准；接下来的问题是：反馈信号本身的有效性如何评估？ 这一节将焦点从”回路整体动态”下降到”单次失败信号的信息含量”。

失败不是终点，是解空间的一次收窄。每一次工具调用失败、每一次测试不通过，都在减少需要继续搜索的区域——这是搜索过程的内在机制，不是意外事故。从控制论角度，失败是反馈信号的一种形态；从信息论角度，失败携带了”这条路径不可行”的信息量。问题的关键不在于失败本身，而在于失败携带的信号是否有效——是能驱动搜索收敛的精确信号（使 $V$ 单调下降），还是制造误导的噪声（使 $V$ 在解空间中随机游走）。如何设计 Hook 以捕获、传递和利用失败信号，是第十一章的工程主题。

5.5 随机状态转换：从确定性假设到概率现实

§5.4 将失败重新定义为”携带信息的反馈信号”，但这一重新定义还需要一个形式化基础——失败必须在状态转换模型中拥有正式的位置，而非作为”例外”被排除在外。第四章 §4.1 已显式标注：Newell-Simon 框架将操作建模为确定性函数仅是简化假设；Harness 面对的真实环境并非如此：工具调用可能因网络超时而失败、同一个 Prompt 在不同轮次产生不同输出、外部 API 返回的结果本身是随机的。这些不确定性不是工程实现的缺陷，而是 Agent 运行环境的内在属性。本节将这一假设松弛正式化。

确定性假设的失效场景：当工具失败时，Agent 到达一个”错误状态”而非”预期状态”——但在 Newell-Simon 框架中，这个失败本身没有正式的表示位置。失败变成了”操作集外的例外”，而非搜索空间的一部分。

工程后果：将不确定性视为例外而非结构，导致两类设计盲点：

过度乐观的计划：Plan 假设工具调用总会成功，没有为失败路径预留 fallback
低效的反馈设计：Hook 只监控成功路径的质量，而非将失败本身纳入上下文窗口

引入概率转换的直觉：将 $\mathcal{O}$ 中的每个操作 $o$ 理解为状态分布的映射，而非确定函数：给定状态 $s$ 与操作 $o$ ，下一状态 $s'$ 按某个概率分布 $P(s' \mid s, o)$ 采样。这个概率分布的支撑集（support）通常包含：一个高概率的”成功目标状态”，以及若干低概率的”失败状态”（超时、格式错误、权限拒绝等）。

对 Harness 设计的三个直接影响：

确定性视角的设计	概率视角的重新诠释
工具调用失败是”例外处理”	失败状态是解空间的正式组成部分，Hook 应覆盖其检测
Plan 是到目标的唯一路径规划	Plan 是一棵概率加权的路径树，高概率路径优先，低概率路径有 fallback
重试是”临时补救”	重试是在 $P(s' \mid s, o)$ 下多次采样的必然策略，其终止条件应被显式设计

与控制论的连接：概率转换使反馈回路的收敛分析从确定性稳定性转向随机稳定性——系统不再”一定收敛”，而是”以某概率在期望步数内收敛”。这为 Hook 的重试上限设计提供了理论依据：当 $P(\text{成功} \mid s, o)$ 极低时，无限重试在期望成本上是灾难性的。

严格的 MDP 处理见附录 A.5——本节仅建立工程直觉，为 Harness 设计者提供在真实不确定性环境中思考问题空间的语言框架。

章末案例剖析

两个反馈回路设计，面对同一个任务，一个发散、一个收敛——差异不在于 Agent 的能力，而在于 Hook 传递给 Agent 的失败信号携带了多少可操作信息。

任务设定：Flask 应用在启动时抛出数据库连接错误，服务无法启动。Agent 被要求诊断并修复配置问题。已知：错误来自数据库连接层，但具体原因（密码错误、端口不通、SSL 证书缺失、连接池配置异常……）未知。目标 $\mathcal{G}$ ：应用成功启动，健康检查接口返回 200。

设计 A：模糊反馈 → 发散

Hook 设计：Post-Hook 捕获启动异常，仅返回异常类型名称：

# Hook 伪代码（设计 A）
try:
    app.start()
except Exception as e:
    return {"status": "failed", "error": type(e).__name__}
# 返回示例：{"status": "failed", "error": "DatabaseConnectionError"}

这个 Hook 携带的信息量接近 1 bit——“连接失败”本身是已知的，DatabaseConnectionError 没有告知失败发生在哪一层、涉及哪个参数、尝试连接时的具体行为。

执行轨迹：

第 1 轮：Agent 看到 DatabaseConnectionError，最可能的猜测是密码错误（训练数据中最常见的原因）。修改 DB_PASSWORD，重新启动。同样的错误，同样的信号。
第 2 轮：密码已排除（但 Hook 不记录已排除的假设），Agent 的下一个猜测是端口。修改 DB_PORT 从 5432 到 5433。同样的错误。
第 3-4 轮：依次尝试 DB_HOST、DB_NAME，每次相同的信号返回，Agent 在配置参数空间中做随机游走。
第 5 轮：Context 中积累了 4 次失败尝试的记录，但没有任何一次失败提供了”为什么错”的信息——只有”它错了”。Context 的 token 消耗在增长（每轮约 +800 tokens），信号密度（可操作信息量/token）在下降。
第 6-8 轮：Agent 开始尝试更边缘的假设（SSL 配置、连接池大小、驱动版本）。部分修改破坏了原本正确的配置，引入了新的错误。但 Hook 仍然只返回 DatabaseConnectionError——新错误与原始错误的信号完全相同。
第 9 轮：token 预算耗尽，任务失败。实际原因（SSL 证书路径错误）从未被 Agent 触及。

发散的早期识别信号（§5.3）：第 2 轮即可观察到——相同的错误类型重复出现；Agent 的修改在逻辑上不相关（密码 → 端口 → 主机）；每轮 Context token 消耗递增但 status 字段没有变化。这是 §5.3 描述的发散特征：误差信号在放大（越来越多的错误修改堆积），而非衰减。用 §5.5 的语言表述： $P(\text{正确修复} \mid \text{"DatabaseConnectionError"}) \approx 1/N$ ，N 是配置参数的数量，每轮采样都在低概率区间反复碰壁而无收敛。

设计 B：精确反馈 → 收敛

Hook 设计：Post-Hook 捕获异常时，主动收集连接尝试的完整上下文：

# Hook 伪代码（设计 B）
try:
    app.start()
except DatabaseConnectionError as e:
    conn = get_connection_attempt_details()
    return {
        "status": "failed",
        "error_type": type(e).__name__,
        "error_message": str(e),              # 完整错误信息
        "traceback_tail": format_tb(e)[-3:],  # 最近 3 层调用栈
        "connection_params": {                # 实际尝试连接时的参数（脱敏）
            "host": conn.host,
            "port": conn.port,
            "ssl_enabled": conn.ssl,
            "ssl_cert_path": conn.ssl_cert or "NOT_SET",
        },
        "suggestion": diagnose_connection_error(e),  # 规则引擎初步诊断
    }

返回示例：

{
  "status": "failed",
  "error_type": "DatabaseConnectionError",
  "error_message": "SSL: CERTIFICATE_VERIFY_FAILED",
  "traceback_tail": ["psycopg2/ssl.py:224", "ssl.SSLError: [SSL] verify failed"],
  "connection_params": {
    "host": "prod-db.internal",
    "port": 5432,
    "ssl_enabled": true,
    "ssl_cert_path": "NOT_SET"
  },
  "suggestion": "SSL enabled but DB_SSL_CERT_PATH not configured"
}

这个信号的信息量：错误原因（SSL 证书验证失败）、失败发生的代码层（psycopg2/ssl.py）、当前配置状态（ssl_cert_path 未设置）、规则引擎的初步定位——每一项都在缩小假设空间。

执行轨迹：

第 1 轮：Agent 看到 ssl_cert_path: "NOT_SET" 和 suggestion: "SSL enabled but DB_SSL_CERT_PATH not configured"，直接定位问题。查询环境变量文档，找到正确路径 /etc/ssl/certs/prod-db.crt，设置 DB_SSL_CERT_PATH。
第 2 轮：新的失败信号：error_message: "Certificate expired: 2024-01-15"，ssl_cert_path: "/etc/ssl/certs/prod-db.crt"。信号再次精确——证书存在但已过期。Agent 找到当前有效证书路径，更新配置。
第 3 轮：status: "success"， $\mathcal{G}$ 满足，Stop Hook 触发终止。

每一轮失败都将搜索空间精确收窄——第 1 轮排除了所有非 SSL 因素，第 2 轮排除了证书路径问题只留下证书有效性问题。这是 §5.4 的核心命题在工程中的直接体现：失败是解空间的收窄，前提是信号足够精确。用 §5.5 的语言：设计 B 的每个失败信号将下一步操作的概率分布 $P(s' \mid s, o)$ 的高概率质量集中在正确方向上，使每次采样都大幅提升 $P(\text{正确修复} \mid \text{信号})$ ，从 $\approx 1/N$ 跃升到 $\approx 0.85$ 。

两种设计的量化对比

维度	设计 A（模糊反馈）	设计 B（精确反馈）
Hook 返回的字段数	2（status + error_type）	6（含 traceback、参数、诊断）
单次失败信号大小	~15 tokens	~180 tokens
轮次数	8+（超预算）	3
总 token 消耗	>15,000（失败）	~4,500
任务完成	否	是
每轮 $P(\text{正确修复} \mid \text{信号})$	≈ 1/N → 不收敛	≈ 0.85 → 两轮收敛

Hook 的额外 token 成本（每次 +165 tokens）在总账上是正收益：3 轮 × 180 tokens = 540 tokens 的信号成本，换来了少执行 5 轮 × ~1,800 tokens = 9,000 tokens 的推理成本。精确信号的单位信息密度远高于其自身的 token 代价。

反馈质量的三个判别维度

这两个案例将本章的三个核心概念转化为可操作的工程判别标准：

收敛性（§5.3）：失败信号是否在减少与目标的距离？设计 A 的信号在 8 轮内没有减少任何假设，误差没有衰减；设计 B 的每个信号精确排除一类假设，误差在两轮内衰减至零。早期预警：若连续两轮失败信号在内容上高度相似，反馈回路很可能正在发散。

信息性（§5.4）：失败携带的可操作信息量 = 它所减少的搜索空间大小。设计 A 的每次失败携带的信息量 ≈ 0 bit（已知失败，已知类型，N 个假设依然待排除）；设计 B 的第一次失败在一条信号内排除了 N-1 个假设，信息量 ≈ $\log_2 N$ bit。

概率质量（§5.5）： $P(\text{正确修复} \mid \text{失败信号})$ 是衡量反馈质量的精确指标。设计 A 中该概率保持在 $\approx 1/N$ ，随重试次数增加而无改善；设计 B 中该概率在每轮后跃升，体现了 §5.5 所描述的”每次采样都在高概率区间”的概率框架。Hook 的设计目标，可以被精确表述为：最大化 $P(\text{正确修复} \mid \text{失败信号})$ ——这是第十一章 Hook 工程的设计核心，将在那里展开为具体的传感器设计原则。

第五章 反馈系统：收敛、发散与控制论基础

第五章　反馈系统：收敛、发散与控制论基础