精读笔记

Problem Setting

论文标题：AppBench: Planning of Multiple APIs from Various APPs for Complex User Instruction（EMNLP 2024）。

这篇论文实际处理的是“LLM 作为 meta-planner 协调多个 App 内 API 完成复杂用户指令”的评测问题。重点不是单次 function calling，也不是工具选择准确率，而是一个更严格的可执行计划生成问题：模型必须同时决定调用哪些 App、哪些 API、以什么顺序调用、每个 API 的输入参数从哪里来、哪些返回值要被后续 API 消费。

真正困难点在于任务是组合式且结构化的。多 API 调用不是线性链条的简单延长，而是可能包含并行分支和顺序依赖的图结构。一个 API 的输入可能来自用户显式给定，也可能来自前序 API 的返回值；如果模型漏掉一个依赖、错用一个返回字段、或把 App 权限归属弄错，整个 plan 就不可执行。

以前方法卡在两个简化假设上：第一，把 API 调用看成局部 selection/filling 问题，而不是全局 execution graph construction；第二，把工具集合看成一个统一可调用空间，而不是有 App/source 边界的权限空间。AppBench 的关键矛盾就是：自然语言用户意图是压缩的、全局的，但执行需要展开成受权限约束的、局部可验证的结构化图。

Motivation

已有工具学习评测对真实复杂度的覆盖不够。APIBench、API-Bank、ToolBench 等路线主要衡量模型是否能在给定描述下选对 API 或完成较短工具链，参数通常较少，依赖关系也弱。这样会高估模型的工具使用能力，因为很多任务只需要 semantic matching：用户说订酒店，模型选 hotel API；用户说查天气，模型选 weather API。

作者真正抓住的缺口是：真实移动端或数字助手场景中，一个用户请求常常横跨多个 App，并且中间结果要在服务之间传递。例如先查车票，再基于目的地查住宿；先找餐厅，再用餐厅名预订；先查电影场次，再买票。这里的难点不是“知道有什么工具”，而是构造一个满足数据依赖和执行权限的计划。

因此这篇工作的动机更像是把工具学习 benchmark 从 API retrieval 推向 workflow planning。它缺的不是更多 API 数量，而是更真实的结构约束：多节点、多边、跨源、参数级依赖、以及权限隔离。

Core Idea

核心思想是把 API 使用评测重新建模为跨 App 的执行图生成，而不是 flat API selection。每个 API 调用是图节点，参数依赖是有向边，App/source 是节点所属的权限域。模型输出的不是“应该用哪个工具”，而是一个可执行 path / graph：包含 App 名、API 名、输入参数、返回参数，以及依赖关系。

这个建模方式的本质区别在于，它把工具使用能力拆成三个必须同时满足的层次：语义对齐，即用户意图到 API 的匹配；结构规划，即 API 间顺序和并行关系；变量绑定，即前序返回值到后续输入参数的引用。prior 多数只强测第一层，弱测第二层，几乎不系统测第三层。

直觉上这会更 scalable/generalizable，因为它不依赖某一个具体 App 或 API，而是抽象出真实工具生态中普遍存在的执行约束：服务边界、参数 schema、依赖传播、并行/串行组合。对 agent 研究来说，这比单工具 benchmark 更接近未来个人助手的核心能力。

Method

AppBench 的方法贡献主要在 benchmark construction，而不是模型算法。

第一，作者把任务型对话数据转化为单轮复杂用户指令。它解决的是现有真实用户需求通常分散在多轮交互中的问题。通过让 LLM 总结整个 dialogue，得到一个压缩后的复杂 instruction，benchmark 能模拟用户一次性给出复杂目标的场景。这里的核心变化是把 dialogue policy trace 转成 planning supervision。

第二，作者从原始对话中的系统 API 调用轨迹抽取 planning path。它解决的是人工标注跨 API 依赖成本高的问题。通过脚本解析 domain/service、API 名、输入输出参数和调用顺序，可以自动得到相对可执行的 gold plan。这个机制把任务型对话数据里的隐式 workflow 显式化。

第三，作者按 SS、SM、MS、MM 分类控制复杂度。它解决的是 benchmark 难度不可解释的问题。SS 测单 App 单 API，SM 测单 App 多 API，MS 测多 App 单 API，MM 测多 App 多 API。这个划分让性能下降可以被归因到 API 数量、App 数量和依赖结构的增加，而不是单纯样本随机性。

第四，引入 parallel scale 和 sequential scale 分析执行结构。它解决的是“多 API”这个概念过于粗糙的问题。并行组件数对应独立子任务数量，顺序组件大小对应依赖链深度。实验显示顺序依赖比并行组合更伤模型性能，这一点比总体成功率更有信息量。

层级 prompting 用于先选 App 再给对应 API 描述，本质上是上下文过滤和减少无关 schema 干扰。它不是方法创新，只是评测时让不同上下文长度模型能运行的工程处理。

Key Insight / Why It Works

这篇最有价值的 insight 是：当前 LLM 的 tool-use 瓶颈并不主要在“找不到工具”，而在“不能稳定维护参数级依赖图”。主实验和错误分析都指向同一点：随着任务从 SS 到 MM，APP/API F1 下降但还没有完全崩，真正崩的是 Succ，也就是端到端可执行性。这说明模型能大致识别相关服务，但无法保证所有参数、返回值和执行顺序一致。

方法之所以有效，是因为 benchmark construction 把 hidden failure mode 暴露出来了。传统工具 benchmark 中，模型即使只靠语义匹配也能获得不错分数；AppBench 的成功率要求全局一致，迫使模型处理变量绑定、依赖传播和 schema-level correctness。这是更强的 evaluation pressure。

最可能的核心贡献不是数据规模，也不是 prompt，而是评测目标的结构化：把 API calling 从 name-level correctness 拉到 execution-graph correctness。这个改变会显著降低“看起来会用工具”的虚假能力。

哪些部分可能只是辅助：层级 prompting 主要是 context management；GPT-4o flat prompting 更好说明强长上下文模型能直接处理更多 schema，但这更像 scaling/context capability，不是 AppBench 自身机制。fine-tuning 和 in-context learning 改善有限，也说明简单 data exposure 不足以解决依赖图规划。

需要直接指出的是，这里的 planning 仍然是 offline symbolic plan generation，不是真实环境中的 interactive planning。没有真实 API 执行、没有异常处理、没有状态更新，也没有用户确认。因此模型是否真正具备 deployment-grade agent planning，文中没有证明。它证明的是：在静态 schema 和 gold path 对齐条件下，当前 LLM 的结构化计划生成能力不足。

Relation To Prior Work

这篇工作最接近工具学习 benchmark 和 language agent evaluation 两条线：APIBench/API-Bank/ToolBench/UltraTool，以及 Chameleon/ReWOO/ToolLLM 一类工具规划框架。它不是提出新 agent 架构，而是补足评测维度。

和 APIBench/API-Bank 的本质差异是粒度不同。prior 更关注单 API 或对话 turn-level 的 API 调用正确性；AppBench 强调一个复杂 instruction 下多个 API 的全局协同。和 ToolBench 的差异不是“有没有多个工具”，而是是否系统刻画参数依赖和 App 权限边界。ToolBench 里很多任务仍可被看作工具序列选择，AppBench 则显式要求 dependency graph correctness。

和 UltraTool 等更全面工具使用 benchmark 相比，AppBench 的新增信息在于 App/source 维度和 permission isolation。这个点在真实系统中很重要：一个 meta assistant 并不一定能直接调用所有 API，而是要把调用路由给对应 App 或授权 agent。

看似新的地方中，自动从任务型对话抽取 workflow supervision 是已有数据再利用思路的重组；真正实质创新是把多 App、多 API、参数依赖、权限归属整合成一个统一评测目标，并用成功率暴露当前模型的结构化执行短板。

Dataset / Evaluation

数据覆盖了约十几个 App/domain，包括酒店、租车、餐厅、电影、火车、事件、航班、支付、音乐、天气等，任务类型上覆盖 SS/SM/MS/MM，能够测试从简单工具调用到跨 App 组合的复杂度梯度。它是多场景、多 API 的，但不是严格真实世界 benchmark：数据源来自任务型对话数据，App 是模拟 domain，API 也是 schema-level 抽象，不是真机 App 或真实后端服务。

评测指标设计基本支持论文 claim。APP F1/API F1 衡量粗粒度选择能力，Succ 衡量端到端可执行计划。Succ 严格但必要，因为真实 API workflow 中局部正确没有意义；只要依赖错了，任务就失败。依赖结构分析进一步支持“顺序依赖比并行组合更难”的判断。

不过 evaluation 也有明显 limitation。第一，gold plan 被视为唯一或近似唯一，但真实任务常有多个可行执行计划；结构级匹配可能低估合理替代路径。第二，API 返回值字段名和输入字段名来自同一数据构造流程，可能让任务更像 schema alignment，而不是真实结果驱动 planning。第三，没有真实执行验证，无法测试 runtime failure、side effect、权限认证、异步等待、用户确认等 deployment 关键问题。

因此 AppBench 能很好验证“当前 LLM 在静态跨 API 依赖计划上不可靠”，但不能完整验证“真实 App agent 是否可用”。

Limitation

第一，benchmark 成立依赖一个强前提：任务型对话中的系统 API 调用轨迹可以代表真实复杂用户指令的最优执行计划。但 dialogue trace 是为多轮交互设计的，压缩成单轮指令后，某些信息流和决策边界会被人为重组。文中未充分说明这种转换是否引入了分布偏移。

第二，所谓 App 权限隔离目前更多是命名和路由约束，而不是真实权限模型。真实系统中的授权、隐私、跨 App 数据共享、用户 consent、token scope、失败回滚都没有进入评测。permission isolation 的现实重要性很高，但在 benchmark 中实现得较浅。

第三，泛化能力仍不清楚。数据来自 SGD schema，API/domain 空间有限，模型可能依赖 schema pattern、字段名相似性和常见任务模板。核心能力可能主要来自数据覆盖和 schema familiarity，而不一定是抽象 planning 能力。benchmark leakage 或 implicit memorization 风险文中没有深入排查。

第四，评测把问题压成一次性 plan generation，缺少 test-time interaction。真实 agent 往往可以执行一步、观察结果、修正计划；AppBench 不允许这种反馈，因此它更像静态程序合成评测，而不是完整 agent evaluation。反过来，这也可能让失败率显得更高。

第五，fine-tuning 和 ICL 的增益来源不清。论文显示它们帮助有限，但没有系统区分是训练数据规模不足、模型架构不适合变量绑定、prompt 格式限制，还是评测过于严格。增益来源不清，也意味着后续方法设计仍缺少明确方向。

Takeaway

• 1. 工具学习评测下一步不应继续只扩大 API 数量，而应扩大结构复杂度：依赖图、权限域、状态变化、异常恢复比 API catalog size 更关键。
• 2. 当前 LLM 的短板不是不会“选工具”，而是不会稳定维护跨工具变量绑定和执行约束。
• 未来 agent 需要显式图表示、typed intermediate state、constraint checking 或 verifier，而不是只靠 prompt 让模型一次性生成 plan。
• 3. 顺序依赖比并行子任务更能暴露规划能力。

一句话总结

AppBench 是工具学习从单 API/function calling 走向跨 App 工作流规划评测的一步，真正贡献在于用参数依赖图和权限路由暴露了当前 LLM 作为 meta-planner 的结构化执行短板。