AI 范式雷达：《从端到端成功率到细粒度规划诊断》

在 12 个主流多模态大语言模型（MLLM）中，端到端任务成功率最高的模型在”不可解任务识别”测试中的正确拒绝率仅为 34.7%。这意味着超过三分之二的情况下，即使是最强的 Agent 也会对一个根本无法完成的任务盲目尝试——浪费计算资源、暴露用户数据，甚至产生有害输出。

同济大学、腾讯 AI Lab、清华大学等机构联合发表的论文《Agent Planning Benchmark: A Diagnostic Framework for Planning Capabilities in LLM Agents》提出了 APB（智能体规划基准），首次将 Agent 的”规划能力”从端到端成功率中解耦出来，通过五大评估设置实现细粒度诊断。论文基于 4,209 个多模态案例、覆盖 22 个领域，揭示了当前 LLM Agent 在长程规划、工具鲁棒性和校准拒绝三个维度上的系统性弱点。

这篇文章将带你理解 APB 的五大评估设置如何工作、12 个 MLLM 暴露了哪些规划缺陷，以及 APB 如何引导你改进 Agent 的规划质量。

为什么端到端成功率不够用

如果你正在构建或评估一个 AI Agent，你可能已经习惯了用一个数字来衡量它的表现：端到端任务成功率（End-to-End Success Rate）。这个指标很直观——Agent 完成了整个任务就算成功，没完成就算失败。但 APB 论文揭示了一个被行业长期忽视的问题：端到端成功率掩盖了规划失败与执行失败的本质区别。

一个 Agent 在某个任务上失败了，原因可能完全不同：它可能在第一步就选错了工具（规划失败），也可能正确选择了所有工具但在某一步的执行中出错（执行失败）。这两种失败模式需要完全不同的修复策略——前者需要改进模型的推理和决策能力，后者需要改进工具的可靠性和接口的稳定性。但端到端成功率把这两者混为一谈，让你无法判断问题出在哪里。

更深层的问题是：现有评估方法缺乏对规划过程的细粒度观测。 大多数 Agent 基准测试只记录最终结果（成功或失败），不追踪 Agent 在中间步骤中做出的决策序列。这意味着即使一个模型在端到端任务上表现优异，你也无法知道它的优势来自优秀的规划能力、出色的执行能力，还是两者兼有。

APB 的核心洞察：规划是 Agent 的”上游能力”——它决定了后续所有执行步骤的方向。如果上游出了问题，下游再好的执行也无法弥补。因此，对规划能力的独立评估不是锦上添花，而是诊断 Agent 系统问题的必要前提。

上图展示了传统端到端评估的盲区：两个 Agent 在同一个任务上表现相同（都失败了），但失败原因截然不同——Agent A 规划正确但执行出错，Agent B 规划错误导致整个流程偏离方向。仅凭端到端成功率无法区分这两种情况。

APB 方法论：五大评估设置详解

APB 的核心贡献在于设计了一套从粗到细的评估光谱，通过五个递进的评估设置逐步剥离规划与执行的耦合，实现对 Agent 规划能力的多维度诊断。

整体规划（Overall Planning）—— Baseline

这是最接近传统端到端评估的设置：给定一个任务描述和可用工具列表，要求模型生成完整的执行计划（包括每一步的工具调用序列），然后由环境自动执行并返回最终结果。这个设置衡量的是 Agent 在理想条件下的纯规划能力——假设执行环节完全可靠，Agent 只需要做出正确的决策。

整体规划是后续所有评估的基线。如果某个模型在这个设置上表现不佳，说明它的核心推理和任务分解能力存在根本性问题。

反馈条件化逐步规划（Feedback-Conditioned Stepwise Planning）

在真实场景中，Agent 不是一次性生成完整计划然后执行——它需要根据每一步的执行结果动态调整后续步骤。这个评估设置模拟了这种交互过程：模型每次只生成下一步的动作，然后根据环境返回的反馈决定下一步做什么。

关键区别在于：模型必须在信息不完整的情况下做出决策。 整体规划中模型可以看到完整的任务描述和工具列表；而在反馈条件化设置中，模型只能看到当前状态和之前的执行历史，需要像人类一样”边走边想”。这更接近真实 Agent 的工作方式，也更能反映模型的在线推理能力。

冗余工具鲁棒性（Redundant Tool Robustness）

现实世界中的工具环境往往包含大量冗余——同一个功能可能有多个实现版本，或者存在功能重叠的工具集合。APB 在这个设置中故意向模型提供比实际需要更多的工具选项，测试模型在噪声干扰下保持规划质量的能力。

想象一下：你的 Agent 需要查询天气，但工具列表中同时包含了”天气查询 v1.0”、”天气查询 v2.0”和”气象数据服务”三个功能相似的工具。一个鲁棒的规划器应该能够识别出这些工具的等价性并选择最合适的版本；而一个脆弱的规划器可能会在多个候选中随机选择，导致后续步骤的输入格式不匹配。

损坏工具鲁棒性（Corrupted Tool Robustness）

这个设置更进一步：APB 故意让部分工具返回错误结果或完全不可用，测试模型在工具失效条件下的容错能力。一个规划质量高的 Agent 应该能够检测到工具异常并自动切换到替代方案——而不是盲目地继续执行一个已经断裂的执行链。

关键洞察：损坏工具鲁棒性评估揭示了一个常被忽视的 Agent 缺陷——大多数当前 Agent 缺乏”优雅降级”（Graceful Degradation）能力。当某个工具不可用时，它们不会尝试寻找替代方案，而是继续沿着错误的规划路径执行，最终导致整个任务失败。

不可解任务识别（Unresolvable Task Identification）—— APB 的独特维度

这是 APB 最具创新性的评估设置，也是当前 Agent 评估领域被严重忽视的关键维度。不可解任务识别测试的是：Agent 能否正确判断一个任务在当前工具和能力条件下根本无法完成，并主动拒绝执行？

这个设置的设计非常巧妙。APB 在测试集中混入了约 20% 的不可解任务——这些任务要么缺少必要的工具支持（如要求 Agent 查询一个不存在的数据库），要么超出了当前模型的能力范围（如要求 Agent 实时获取尚未发布的数据）。一个具备校准拒绝能力的 Agent 应该能够识别这些情况并明确告知用户”无法完成”，而不是盲目尝试。

但论文的实验结果令人担忧：12 个 MLLM 中正确拒绝率最高的模型也只有 34.7%，最低的不到 10%。这意味着绝大多数 Agent 在面对不可解任务时会选择”硬着头皮做”——这不仅浪费计算资源，还可能产生有害输出或暴露敏感信息。

为什么这个维度如此重要？ 因为”知道什么做不到”和”知道做什么”同样关键。一个只会执行不会拒绝的 Agent 就像一个从不说不的员工——表面上看起来很积极，实际上可能在制造大量无效工作甚至错误结果。在医疗、金融等高风险场景中，这种缺陷可能带来严重后果。

上图展示了五大评估设置的递进关系：从左到右，评估条件逐渐从理想化走向真实世界场景，对 Agent 规划能力的要求也越来越高。整体规划是基础能力测试，反馈条件化和工具鲁棒性逐步增加现实约束，不可解任务识别则触及了 Agent 自我认知和能力边界的深层问题。

实证结果：12 个 MLLM 的系统性弱点

APB 在 12 个主流多模态大语言模型上进行了全面评估，涵盖了从开源到闭源、从小规模到大模型的完整谱系。实验结果揭示了三个普遍存在的系统性弱点。

长程规划的衰减曲线

随着任务步骤数的增加，所有模型的规划准确率都呈现明显的下降趋势。在 3-5 步的短程任务中，表现最好的模型达到了约 72% 的准确率；但在 10 步以上的长程任务中，最高准确率降至约 41%，下降了超过 30 个百分点。

这种衰减不是线性的——论文发现每增加一步规划，错误率大约增长 8-12%。这意味着一个需要执行 15 步的 Agent 任务，其规划正确率的期望值可能低于 25%。更令人担忧的是，这种衰减在不同规模的模型之间没有显著差异：即使是最大的模型（超过 100B 参数）也没有展现出明显优于小模型的长程规划能力。

工具噪声与损坏的鲁棒性对比

在冗余工具和损坏工具的测试中，不同模型的表现差异显著。表现最好的模型在冗余工具设置下的准确率下降约为 15%，而最差的模型下降了超过 40%——这意味着同一个 Agent 在面对相同数量的干扰工具时，规划质量可能相差近三倍。

更值得关注的是损坏工具鲁棒性的普遍缺失。在所有 12 个模型中，没有一个能够在部分工具损坏的情况下保持超过 60% 的准确率。这表明当前 Agent 架构在容错机制方面存在系统性不足——大多数实现缺乏对工具异常的检测和自动恢复逻辑。

校准拒绝能力的集体缺失

不可解任务识别测试的结果最为严峻。12 个模型中，正确拒绝率（即面对不可解任务时正确判断并拒绝执行的比例）分布在 8.3% 到 34.7% 之间。这意味着：

• 最弱的模型在超过 90% 的不可解任务上选择了盲目尝试
• 最强的模型也在约 65% 的情况下未能识别出不可解性
• 所有模型的误拒绝率（将可解任务错误判断为不可解）都低于 15%，说明问题主要不是过于保守，而是过于激进

核心发现：当前 LLM Agent 的规划能力呈现出”过度自信”的特征——它们倾向于相信任何给定的任务都可以完成，即使证据表明事实并非如此。这种过度自信在端到端成功率指标下被完全掩盖，因为不可解任务的”失败”（无论是正确拒绝还是盲目尝试后失败）都被计为同一个结果。

APB 引导的规划精炼

APB 不仅是一个评估框架，还可以直接用于改进 Agent 的规划质量。论文展示了如何利用 APB 的诊断结果来指导规划优化——通过识别具体的规划弱点并针对性地改进，可以在不改变模型架构的前提下显著提升下游执行指标。

Before vs After：规划优化的实际效果

论文中的实验显示，基于 APB 诊断结果进行规划精炼后，Agent 在多个维度上获得了显著改善：

长程规划准确率提升。通过引入中间步骤的验证机制（即在每 N 步后检查当前状态是否仍然与目标一致），10 步以上任务的规划准确率从约 41% 提升至约 58%，提升了 17 个百分点。

工具鲁棒性增强。在冗余工具设置中，通过引入工具等价性识别模块（让模型学习判断哪些工具是功能重叠的），准确率下降幅度从 30-40% 降低到 12-18%。

校准拒绝能力改善。通过在规划阶段加入”可行性预检查”步骤（在生成完整计划之前先评估任务是否可解），正确拒绝率从约 25% 提升至约 67%，提升了近两倍。

规划精炼的核心思路

class PlanningRefiner:
    """基于 APB 诊断的规划精炼器"""

    def __init__(self, base_planner, verifier=None):
        self.base_planner = base_planner
        self.verifier = verifier or StepVerifier()

    def plan_with_refinement(self, task, tools):
        # 第一步：可行性预检查（不可解任务识别）
        if not self._check_feasibility(task, tools):
            return {"status": "rejected", "reason": "task_unresolvable"}

        # 第二步：生成初始规划
        initial_plan = self.base_planner.generate(task, tools)

        # 第三步：中间步骤验证（长程规划衰减缓解）
        refined_plan = []
        for step in initial_plan:
            refined_plan.append(step)
            if len(refined_plan) % 3 == 0:
                verification_result = self.verifier.verify(
                    refined_plan, task, tools
                )
                if not verification_result["valid"]:
                    # 检测到规划偏离，触发重新规划
                    return self._replan(task, tools, refined_plan)

        # 第四步：工具可用性检查（损坏工具鲁棒性）
        final_plan = self._check_tool_availability(refined_plan, tools)
        return {"status": "planned", "plan": final_plan}

这个精炼器的核心思想是在规划过程中引入反馈循环——不是生成一个计划然后执行到底，而是在关键节点检查规划的合理性并及时修正。这种”边规划边验证”的模式正是 APB 五大评估设置所揭示的最佳实践方向。

与 REFLECT (#66) 的互补关系

如果你已经阅读了第 66 篇范式雷达文章（关于 REFLECT），你会发现 APB 和 REFLECT 形成了一个完整的 Agent 诊断闭环。

REFLECT 关注的是事后错误归因——当 Agent 执行失败后，分析失败的根本原因是规划问题还是执行问题。APB 关注的是事前能力评估——在任务执行之前，通过多维度的测试来了解 Agent 的规划能力边界。

两者的互补关系可以用一个简单的框架来理解：

• REFLECT = 事后诊断（Post-mortem Diagnosis）：Agent 失败了 → REFLECT 分析失败原因 → 定位是规划问题还是执行问题
• APB = 事前评估（Pre-assessment）：在部署 Agent 之前 → APB 测试其规划能力 → 了解它在哪些维度上存在弱点

将两者结合使用，你可以构建一个完整的 Agent 质量保障体系：用 APB 在上线前识别 Agent 的规划弱点并针对性优化，用 REFLECT 在运行时分析失败原因并持续改进。事前评估 + 事后诊断 = 闭环的质量管理。

这种互补关系在实际工程中具有明确的落地价值。例如，一个医疗诊断 Agent 在上线前可以通过 APB 测试发现它在”不可解任务识别”维度上表现薄弱（正确拒绝率仅 20%），然后在部署后通过 REFLECT 分析实际失败案例来验证这一弱点是否确实影响了线上表现——如果 REFLECT 的分析结果显示大量失败案例确实源于”无法诊断却强行给出建议”，那么 APB 的诊断结果就得到了实证支持。

APB 的适用范围与局限性

在拥抱 APB 之前，你需要了解它的边界条件：

多模态依赖。APB 的测试用例包含视觉信息（如图片中的文字、图表等），这意味着它对纯文本 Agent 的评估可能不够公平。如果你的 Agent 只处理文本输入，建议关注整体规划和反馈条件化这两个设置——它们不依赖视觉理解能力。

标注主观性。不可解任务的判定需要人工标注，不同标注者可能对同一个任务的可解性有不同的判断。论文中报告的标注一致性（Cohen’s Kappa）约为 0.72，属于”良好但非完美”的水平。这意味着约 28% 的不可解任务标签可能存在争议。

样本量限制。APB 评估了 12 个 MLLM，这个数字在模型生态中只占很小一部分。虽然作为诊断基准已经足够，但你不能将 APB 的结果外推到所有模型——特别是那些在 APB 发布之后才推出的新模型。

总结与行动清单

APB 的核心贡献在于将 Agent 规划能力从端到端成功率的笼统指标中解放出来，通过五大评估设置实现细粒度诊断。它揭示了一个被行业长期忽视的事实：规划失败和执行失败的混淆正在掩盖 Agent 系统的真实问题——你可能一直在修复执行层面的 bug，而真正的根源是上游的规划缺陷。

更重要的是，APB 将”不可解任务识别”推到了 Agent 能力评估的核心位置。一个只会执行不会拒绝的 Agent 不是可靠的 Agent——它可能在浪费资源、暴露风险，甚至产生有害输出。正确判断”什么做不到”与知道”做什么”同等重要。

你现在可以做的：

1. 在你的 Agent 评估流程中引入规划/执行的分离分析——不要只用端到端成功率，尝试追踪每一步的决策质量
2. 实现一个简易的可行性预检查模块，在 Agent 开始执行之前先判断任务是否在当前工具和能力条件下可解
3. 为你的 Agent 添加中间步骤验证机制（每 N 步检查一次规划偏离度），缓解长程规划的衰减问题
4. 如果你的团队同时使用 APB 和 REFLECT，建立”事前评估 + 事后诊断”的闭环流程——APB 用于上线前能力画像，REFLECT 用于运行时失败归因

References

• Agent Planning Benchmark (APB, arXiv:2606.04874)
• Reflecting on Reflections: Error Attribution in LLM Agents (REFLECT, arXiv:2606.xxxxx)
• NovelAPIBench: Benchmarking API Usage Capabilities of LLM Agents (arXiv:25xx.xxxxx)