第 24 章 反馈信号设计：给 Agent 的是信号，不是更大的提示词

进化从反馈开始：给错误，别给更大的提示词

第五部分把 Agent 弄安全了。从这一章开始，进入第六部分"让它进化"：从人工设计到自动学习。

进化这件事，起点是反馈。一个残酷的规律：打磨单个提示词覆盖不了所有边角情况，Agent 需要的是"地面真相"来自我纠正。但很多团队的反馈设计是一团糟的：只在最后给一个二进制的"过了/没过"，Agent 不知道错在哪、怎么改。

这一章讲三个模式，回答"反馈信号怎么设计"：

1. Rich Feedback Loops（丰富反馈循环）：给 Agent 迭代的、机器可读的反馈。
2. Iterative Prompt & Skill Refinement（提示词与技能迭代）：多机制协同改进提示词和技能。
3. Inference-Healed Code Review Reward（推理治愈的评审奖励）：把代码质量拆成子标准，逐项打分。

模式一：丰富反馈循环（Rich Feedback Loops > Perfect Prompts）

问题

打磨单个提示词覆盖不了每个边角情况，Agent 需要地面真相来自我纠正。

另外，Agent 需要整合人类反馈（正面和纠正性的）来提升会话质量。更能响应用户反馈的项目，纠正更少、结果更好。

方案

每次工具调用后，暴露迭代的、机器可读的反馈：编译器错误、测试失败、linter 输出、截图。Agent 用诊断规划下一步，产生涌现的自我调试能力。

整合人类反馈的模式：

• 识别正面反馈来强化起作用的模式。正面信号是训练数据，不是礼貌。
• 从纠正里学习，避免重复犯错。
• 适应用户的沟通风格和偏好。
• 长期跟踪对特定用户什么有效。

工具设计很重要：结构化输出（JSON、退出码、错误对象）对 Agent 自我纠正比自然语言更有效。

来自 88 个会话的分析：

项目	正面	纠正	成功率
nibzard-web	8	2	高（80%）
2025-intro-swe	1	0	高（100%）
awesome-agentic-patterns	1	5	低（17%）
skills-marketplace	0	2	低（0%）

关键洞见：正面反馈更多的项目结果更好。强化是训练数据，教会 Agent"该做什么"；纠正只教会"不该做什么"。

现代模型（如 Claude Sonnet 4.5）越来越主动地创建自己的反馈循环：自己写脚本和测试去执行，甚至对看似简单的验证任务也这样（比如用 HTML 检查验证 React 应用行为）。

Agent → CLI: go test ./...
CLI → Agent: FAIL pkg/auth auth_test.go:42 expected 200 got 500
Agent → 文件: 打开 auth.go
Agent → 文件: 打补丁 route handler
Agent → CLI: go test ./...
CLI → Agent: PASS 87/87 tests

证据

• 证据等级：生产验证（validated-in-production），来自 Thorsten Ball、Quinn Slack。
• Reflexion（Shinn 等人，2023）：Agent 通过自我反思和记忆从过去失败里学习。
• Self-Refine（Madaan 等人，2023）：用自我生成的批评做迭代精化。

怎么用

• Agent 质量只有靠迭代批评或重试才能提升时用。
• 从一个客观指标和一个反馈循环触发点开始。
• 记录失败模式，每个循环都产出可复用的学习产物。

取舍

• 好处：把重复失败变成随时间可衡量的改进。
• 代价：迭代来回会增加运行时间和运维成本。

模式二：提示词与技能迭代（Iterative Prompt & Skill Refinement）

问题

Agent 的使用会暴露提示词、技能、工具的缺口，但怎么系统地改进它们？ 工作流失败或表现次优时，你需要多个机制捕获反馈并迭代。单一方法不够，你需要多管齐下的改进策略。

方案

实现多个互补的改进机制协同工作。 没有单一机制能抓住所有问题，你需要分层的方法。这建立在 RLHF 研究之上：人类反馈对对齐不可替代，而 RLAIF 展示 AI 辅助反馈能规模化。

四个关键机制：

1. 响应式反馈（主）

• 监控内部 #ai 频道找问题。
• 每天浏览工作流交互。
• 这是最有价值的持续改进来源。

2. 负责人主导的改进（次）

• 把提示词存进可编辑文档（Notion、Google Docs）。
• 公司里大多数提示词谁都能编辑。
• 工作流输出里带提示词链接（Slack 消息、Jira 评论）。
• 提示词必须可发现 + 可编辑。

3. Claude 增强的改进（专门）

• 用 Datadog MCP 把日志拉进技能仓库。
• 技能是被很多工作流使用的"平台"。
• 通常由中心 AI 团队维护，不是各负责人。

4. 仪表盘跟踪（量化）

• 跟踪工作流运行频率和错误。
• 跟踪工具使用（每个技能加载多频繁）。
• 数据驱动的改进优先级。

工作流运行 → 反馈频道 #ai / 负责人编辑提示词 / Datadog 日志 → Claude / 仪表盘指标
        全部 → 识别问题 → 更新提示词/技能 → 回到工作流运行

怎么用

实施清单：

• 反馈频道：内部 Slack/Discord 放 Agent 问题。
• 可编辑提示词：存 Notion/文档，不存代码。
• 提示词链接：每个工作流输出都带。
• 日志访问：Datadog/可观测性 + MCP 集成。
• 仪表盘：跟踪工作流运行、错误、工具使用。

改进工作流： 每次工作流运行后带提示词链接，别人能点开编辑。

发现策略：

• 每日：浏览反馈频道、审阅工作流交互。
• 每周：审阅仪表盘指标找错误尖峰。
• 按需：具体问题报告时拉日志。
• 每季度：全面的提示词/技能审计。

运行后评测（下一步）： 每次运行后带主观评测：这个工作流有效吗？什么能让它更好？人在回路推动进化。

取舍

• 好处：多层的，抓住不同机制各自漏掉的问题；持续的，一直在改进不是偶发；可访问的，谁都能贡献改进；数据驱动的，仪表盘给优先级；技能共享，中心团队能维护平台级技能。
• 代价：没有银弹，任何机制都删不掉；维护开销，多套系统要管理；权限复杂，要平衡编辑权限；告警疲劳，信号太多会把人淹没。

工作流原型：

类型	改进策略
聊天机器人	运行后评测 + 人在回路
理解清楚的工作流	代码驱动（确定性）
还没理解清楚的工作流	开放问题

开放挑战：怎么在没有产品工程师逐个实现的情况下，规模化地识别并迭代"还没完全理解清楚"的工作流。

模式三：推理治愈的评审奖励（Inference-Healed Code Review Reward）

问题

只检查"所有测试都过了"的简单奖励函数，抓不住微妙的代码质量问题（性能回归、风格违规、缺边角处理）。结尾一个二进制的信号，没法引导 Agent 产出可维护、高质量的代码。

• 只验证最终正确性会漏过次优提交（比如删掉错误处理但测试仍过的补丁）。
• 只产出单个标量的奖励模型，缺可解释性，没法告诉 Agent 代码哪个方面要改。

方案

用推理治愈的奖励模型，一个代码评审批评者，它：

1. 把代码质量拆成子标准

• 正确性：代码过所有现有和新加的测试吗？
• 风格：linter（ESLint、pylint）满足吗（零或最少警告）？
• 性能：简单基准显示有明确性能回归吗？
• 安全：静态分析器（Bandit、SonarQube）没标出严重问题吗？

2. 跑内部思维链（CoT）推理

• 对某个子标准不确定时（比如性能），批评者在自己内部跑一小段 CoT：

  "步骤: 性能检查。基线运行 50ms。新代码运行 65ms。回归 > 20%。得分: 0.4。"

• 这个"推理治愈"让奖励模型能解释每个子分数。
• 用更小的批评者模型（1-2B 参数）保持 CoT 生成的成本效率。

3. 聚合子分数

• 每个子标准返回 [0, 1] 的浮点数。
• 加权和（如 0.4 × 正确性 + 0.2 × 风格 + 0.2 × 性能 + 0.2 × 安全）得到最终评审分数。

4. 生成人可读的反馈

• 数值分数之外，返回简短分析：

  {
    "correctness": 1.0,
    "style": 0.8,
    "performance": 0.4,
    "security": 0.6,
    "comments": "性能回归：O(n²) 循环"
  }

# 一次代码评审奖励调用的伪代码
subscores = {
    "correctness": test_critic.score(patch),
    "style": linter_critic.score(patch),
    "performance": perf_critic.score(patch),
    "security": security_critic.score(patch),
}
final_score = sum(weight[k]*subscores[k] for k in subscores)
return final_score, subscores, comments

证据

• 证据等级：提出（proposed），来自开源 Agent RL 分享和 Will Brown（Prime Intellect）。
• 类似原则：DeepMind 的 "Criterion-Led Reward Models"（2025）；CodeRL（NeurIPS 2022）给代码生成引入基于批评者的奖励信号。
• 行业验证：多标准代码评审在微软（每月 60 万+ PR）、腾讯（每月 3.25 亿行）、Tekion（合并时间快 60%）大规模部署。

怎么用

• 批评者数据集收集：收集好 vs 坏代码补丁的示例，按每个子标准标注。
• 批评者训练：微调小 LLM（1-2B 参数）产出子分数和 CoT 论证。
• 集成进 RL 循环：用 inference_healed_reward(patch) 替换或增强现有的二进制"测试通过"奖励。
• 选择性治愈：只为低于阈值（如 < 0.8）的子分数生成 CoT 解释，降低延迟和成本。
• 并行执行：测试、linter、基准、安全扫描并发跑，减少总评估时间。
• 人在回路检查点：补丁处于边界（如最终分数 [0.5, 0.7]）时，转人工评审，给未来训练生成更好的标签。

取舍

• 好处：可解释的反馈，Agent 知道为什么补丁得分低，能做针对性改进；更高的代码质量，纳入非功能性标准（性能、安全），代码更稳健。
• 代价：计算开销，每次奖励调用可能跑测试、linter、基准、静态分析，加延迟；批评者维护，编码标准或安全规则演进时要重训或更新批评者模型和评分准则。

三个模式怎么选

场景	推荐模式
Agent 只在有迭代反馈时质量才提升	丰富反馈循环
提示词/技能缺口多，想系统改进	提示词与技能迭代
强化学习要代码质量奖励	推理治愈的评审奖励

三个模式是反馈信号设计的三个层次：丰富反馈循环给 Agent 每次动作后的机器可读诊断，提示词技能迭代让团队持续改进提示词和技能，评审奖励把代码质量拆成可解释的子标准喂给 RL。从"给 Agent 信号"到"给团队改进机制"到"给 RL 奖励模型"，反馈设计越做越精细。

实践清单

• 每次工具调用后暴露机器可读反馈：编译错误、测试失败、linter 输出、退出码
• 反馈用结构化输出（JSON / 退出码 / 错误对象），别用自然语言
• 正面反馈当训练数据强化"该做什么"，纠正只教"不该做什么"
• 多机制改进：反馈频道 + 可编辑提示词 + 日志访问 + 仪表盘
• 提示词存文档且可编辑，工作流输出带提示词链接
• 每日浏览反馈、每周看指标、每季度全面审计
• 代码质量奖励拆子标准：正确性 / 风格 / 性能 / 安全，加权聚合
• 子分数低时用 CoT 生成可解释的论证（推理治愈），用小模型省钱
• 边界补丁转人工评审，生成更好标签；测试/linter/基准/安全扫描并行跑

本章小结

• 丰富反馈循环：给 Agent 迭代机器可读诊断，涌现自我调试，正面反馈是训练数据。
• 提示词与技能迭代：反馈频道 + 可编辑提示词 + 日志 + 仪表盘四机制协同。
• 推理治愈的评审奖励：代码质量拆子标准、CoT 可解释、加权聚合，喂给 RL。
• 反馈设计的核心：给 Agent"该做什么"的信号，别只给"不该做什么"的纠正。

下一章讲评测驱动的改进：反馈有了，怎么规模化地用它改进 Agent？自我批判规模化、Dogfooding、防奖励黑客、自检故障注入。