Apple Reinforced Agent — 在 Tool Call 执行前拦截错误¶

核心思路：在 AI Agent 的 Tool Call 实际执行之前插入一个 Reviewer Agent，拦截并修正错误。不是事后恢复，而是事前拦截。实测推理模型作为 Reviewer 达到 3:1 收益风险比（修正 3 个错误，仅引入 1 个新错误）。

目录¶

• #问题：State Recovery 困境
• #架构：双 Agent 协作
• #三种协作模式
• #评估指标：Helpfulness vs Harmfulness
• #实验结果
• #关键发现
• #成本分析
• #适用场景与局限
• #与 Anthropic 方案的互补

问题：State Recovery 困境¶

传统 Agent 的致命缺陷¶

Agent 执行 Tool Call → 结果返回上下文 → 发现错了
                                    ↓
                        已经执行了，无法撤回
                        发了邮件？删了文件？转了账？
                                    ↓
                        需要 State Recovery（状态恢复）
                        多轮场景下成本指数级增长

核心问题¶

两种解决路径¶

路径 A：Anthropic（上下文管理）
  假设：Tool Call 失败是因为 LLM 处理的信息太多
  方案：减少上下文（Tool Search + Programmatic Calling）
  效果：更小的上下文 → 更低成本 → 更少歧义

路径 B：Apple Reinforced Agent（推理时反馈）
  假设：Agent 的第一次尝试经常出错
  方案：在执行前插入 Reviewer 拦截错误
  效果：事前修正 → 避免不可逆后果

✅ 两条路径不冲突，可以组合使用

架构：双 Agent 协作¶

传统 vs Reinforced Agent¶

传统 Agent Loop：
┌──────────┐     ┌──────────┐     ┌──────────┐
│ 用户请求  │ ──→ │ Agent    │ ──→ │ 执行工具  │ ──→ 返回结果
└──────────┘     │ 生成调用  │     │ (可能出错)│
                 └──────────┘     └──────────┘
                                        ↓
                                   发现错误，太晚了

Reinforced Agent Loop：
┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
│ 用户请求  │ ──→ │ Agent    │ ──→ │ Reviewer │ ──→ │ 执行工具  │
└──────────┘     │ 生成调用  │     │ 拦截检查  │     └──────────┘
                 └──────────┘     └──────────┘
                      ↑                 │
                      └── 拒绝 ←────────┘
                      (重新生成调用)

实例：天气查询¶

用户："纽约的天气是多少摄氏度？"

Step 1: Agent 生成 Tool Call
  → get_weather(city="New York", unit="fahrenheit")

Step 2: Reviewer 拦截检查
  → ❌ 拒绝："用户要求摄氏度，参数错误"

Step 3: Agent 重新生成
  → get_weather(city="New York", unit="celsius")

Step 4: Reviewer 再次检查
  → ✅ 通过，执行 Tool Call

关键设计原则¶

三种协作模式¶

模式对比¶

Progressive Feedback（渐进反馈）¶

Agent 生成调用 → Reviewer 审查
                    │
              ┌─────┴─────┐
              │ 拒绝       │ 通过
              ▼            ▼
         反馈给 Agent   执行调用
              │
              ▼
         Agent 重新生成
              │
              ▼
         Reviewer 再次审查
              │
         (循环直到通过或达到 N 轮上限)

• 最直接的版本
• Token 消耗最大（每轮都消耗）
• 实验中表现最好

Best-of-N Selection（N 选一）¶

Agent 生成 N 个候选（不同 temperature）
              │
              ▼
Reviewer 评估所有候选
              │
              ▼
         选出最好的一个 → 执行

Best-of-N Grading（N 个评分）¶

Agent 生成 N 个候选
              │
              ▼
Reviewer 对每个打分 (0.0 - 1.0) + 给出理由
              │
              ▼
         最高分 > 阈值 → 执行
         最高分 < 阈值 → 不执行

命名规范¶

4o-r2-5-mini-v3-gepa

 4o       = 基础模型 GPT-4o
 r2       = Progressive Feedback, 最多 2 轮
 5-mini   = Reviewer 模型 GPT-5 mini
 v3       = Prompt 版本
 gepa     = 使用 GEPA 自动优化 prompt

评估指标：Helpfulness vs Harmfulness¶

为什么需要新指标¶

传统评估只看准确率，但 Reviewer 有副作用——它可能把正确的改错。

指标定义¶

直觉理解¶

Helpfulness = "救了多少次"
Harmfulness = "帮了多少倒忙"
Ratio 3:1   = "每救 3 次，帮 1 次倒忙"

实验结果¶

BFCL（单轮，无状态）¶

最佳提升：无关检测 +5.5%（84.9% → 90.4%）

τ²-Bench（多轮，有状态）¶

最佳提升：平均 +7.1%（48.7% → 55.8%）

错误类型分析¶

关键发现¶

1. 过度怀疑是主要失败模式¶

Reviewer 会错误地标记正确的 Tool Call 为"不完整"（因为它期望看到执行结果，但审查发生在执行之前）。

解决方案：在 Prompt 中加入关键指导：

[CRITICAL] Tool-only responses are complete. Do not mark tool-only responses
as incomplete for lacking user-facing answers, follow-up explanations, or
final results. Tool calls are standalone steps. Focus on whether the actual
tool calls are correct.

效果：冗余审查循环从 23% 降至 8%

2. 推理模型 > 标准 LLM 作为 Reviewer¶

推理模型的 false positive 更低（不会把正确的改错）

3. Progressive Feedback > Best-of-N¶

• 无关检测高出 4-5%
• 多轮场景平均高出 3-8%
• Selection 在某些领域甚至低于基线

4. 跨域泛化需要适配¶

在 BFCL 上优化过的 prompt 直接用在 τ²-Bench 上会引入错误。单轮函数调用和多轮有状态 Agent 存在领域差异。

5. 重要局限：基线模型¶

论文中所有实验的基线 Agent 都是 GPT-4（非推理模型）。如果用推理模型作为基线，它可能从一开始就不会犯 Reviewer 所修正的那类错误。论文在 limitations 部分提到了这点，但低估了其影响。

成本分析¶

延迟开销¶

Token 成本¶

每个 Tool Call = 2 次 LLM 调用（Agent + Reviewer）
Agent 密集型场景（每 session 多次调用）→ 成本显著增加

三重成本¶

适用场景与局限¶

✅ 最佳适用场景¶

✅ 适合组合使用的场景¶

延迟加载工具（Anthropic Tool Search）
  + 批量调用打包进沙盒 Python 脚本（Programmatic Calling）
  + Reviewer 在执行前检查调用（Apple Reinforced Agent）

❌ 不适合的场景¶

Reviewer 的检测边界¶

能检测：
  ✅ 工具选择错误
  ✅ 参数值明显错误
  ✅ 不应该调用工具（scope recognition）

不能检测：
  ❌ 微妙的参数错误
  ❌ 超出 Reviewer 上下文/训练数据的问题
  ❌ 需要执行结果才能发现的错误

vs 其他方案¶

参考资料¶

• arXiv 论文 — Reinforced Agent: Inference-Time Feedback for Tool-Calling Agents
• Apple ML Research — 官方发布
• Berkeley Function Calling Leaderboard (BFCL) — 评估基准
• τ²-Bench — 多轮有状态评估基准
• GEPA: Genetic-Pareto Prompt Evolution — 自动优化 Prompt
• 论文综述 (TheMoonlight) — 深度解读

相关笔记¶

• CLAUDE.md 不是设定档 是会过期的 Cache
• Hermes Agent 隐藏功能 - Dashboard, Claude Code CLI, TUI Chat