当LLMs遇上顺序API调用：StateGen与StateEval如何破解测试难题？
Evaluating LLMs on Sequential API Call Through Automated Test Generation
arXiv:2507.09481
Evaluating LLMs on Sequential API Call Through Automated Test Generation
Yuheng Huang, Da Song, Zhenlan Ji, Shuai Wang, Lei Ma
Subjects: Software Engineering (cs.SE); Artificial Intelligence (cs.AI); Computation and Language (cs.CL)
研究背景：LLMs的"工具使用考试"缺了份靠谱的考卷
想象一下，你刚买了一台多功能料理机，说明书上写了20种功能，但你只会用其中3种------不是机器不好，而是没人告诉你怎么把这些功能按顺序组合起来做一顿大餐。大型语言模型（LLMs）现在就面临类似的问题：它们能调用外部API（相当于料理机的功能）来扩展能力，比如用翻译API做跨语言对话、用计算API解数学题，但要让它们把多个API按顺序串起来完成复杂任务（比如"先查天气API，再用日历API预约野餐，最后用消息API通知朋友"），就经常掉链子。
为什么会这样？因为之前评估LLMs的"考试卷"（基准测试）太简陋了：
- 大多是人工出的题，数量少、覆盖窄，像只考了"切菜"却想判断会不会"做满汉全席"；
- 批改方式粗糙，比如只看输出文字是不是和标准答案一模一样，不管实际功能对不对（比如调用API后没真正预约成功，却因为文字匹配给了满分）；
- 忽略了API之间的"隐藏关系"，比如前一个API的输出必须作为后一个的输入，就像打游戏时"拿到钥匙才能开宝箱"，但考题里没说清楚这种依赖。
于是，研究者们想：能不能自动出一套更难、更贴近真实场景的"考卷"，专门测试LLMs处理顺序API调用的能力？这就是这篇论文要解决的核心问题。
主要作者及单位信息
这篇论文由来自三所高校的研究者合作完成：
- Yuheng Huang、Lei Ma（东京大学，日本）
- Da Song、Lei Ma（阿尔伯塔大学，加拿大）
- Zhenlan Ji、Shuai Wang（香港科技大学，中国）
他们的研究聚焦于LLMs在工具调用领域的评估，试图填补现有测试体系的空白。
创新点：自动"出题"+ 精准"阅卷"，LLMs的专属"能力诊断仪"
这篇论文的最大亮点，是提出了两个核心工具：StateGen （自动出题系统）和StateEval（标准化考卷），它们的创新之处在于：
-
从"人工出题"到"机器自动生成"：StateGen能根据API文档，自动生成大量含顺序API调用的可执行程序，就像老师根据教材自动出不同难度的练习题，既高效又多样。
-
从"死记硬背"到"灵活应用"：生成的程序会被转换成自然语言指令（比如"用ElevenLabs的API把这段文字转成女声语音，再调用存储API保存结果"），测试LLMs是否真的理解指令，而不是死记硬背API用法。
-
从"只看表面"到"深究本质"：通过记录程序执行时的状态变化（比如变量值、API返回结果），精准判断LLMs生成的代码是否"真的能跑通"，而不是只看语法对不对。
研究方法：StateGen如何"出卷"？分四步走
StateGen的工作流程就像出一份复杂的考卷，拆解开来其实很清晰：
第一步：生成API调用"轨迹"（Trace Generation）
先确定API之间的"合法顺序"。比如调用"查天气API"后才能调用"预约野餐API"，不能反过来。StateGen用"状态机"建模这种依赖关系，再通过"能量采样"确保生成的顺序足够多样（比如有时先查温度，有时先查风力），避免重复出题。
第二步：生成完整程序（Program Generation）
在API调用轨迹的基础上，增加"控制流"（比如if-else分支）。比如"如果下雨就取消野餐，调用取消预约API；否则继续调用通知API"，让程序更贴近真实场景的复杂性。
第三步：翻译成自然语言指令（Instruction Translation）
让两个LLM"代理"合作：一个把程序翻译成人类能懂的指令（比如"根据天气情况决定是否取消野餐，并通知朋友"），另一个检查指令是否清晰、准确。如果不合格就反复修改，直到符合要求。
第四步：记录"标准答案"（Oracle Generation）
执行生成的程序，记录每一步的状态变化（比如变量值、数据库更新结果），作为评判LLMs输出的"标准答案"。比如调用通知API后，检查朋友是否真的收到消息。
实验：用StateEval给LLMs"考试"，结果如何？
研究者用StateGen生成了120道题，组成StateEval基准，覆盖三个场景：
- 会话服务（Session Service）：调用RESTful API管理用户会话；
- 张量操作（Tensor Operation）：用PyTorch API处理张量计算；
- 语音工具（ElevenLabs MCP）：调用文本转语音等API。
然后让5个主流LLM（开源的Qwen2.5-Coder、Llama-4-Scout；闭源的GPT-4.1、Gemini-2.5-Flash等）"考试"，结果很有意思：
-
闭源LLM表现更好，但仍有提升空间：GPT-4.1总分最高（56%正确率），但离满分还差很远；开源模型平均正确率不到30%。
-
场景差异明显：所有模型在张量操作上表现最好（GPT-4.1正确率78%），可能因为PyTorch是常用框架，训练数据多；在会话服务上表现最差，因为这类API的公开资料少。
-
错误集中在"执行"和"结果"：大部分错误不是语法错，而是程序能跑但结果不对（比如没正确更新数据库），或执行到一半崩溃（比如张量形状不匹配）。
主要贡献：给LLMs的"工具使用能力"画了张清晰的"体检表"
这篇论文的价值，就像给LLMs的"API调用能力"做了一次全面体检：
-
提供了自动化测试工具：StateGen能自动生成海量、多样的测试案例，解决了人工出题效率低、覆盖窄的问题。
-
建立了更难的"评估标准"：StateEval比现有基准更复杂（平均每道题含7个API调用，是其他基准的2倍以上），能更真实地反映LLMs在实际场景中的表现。
-
指出了LLMs的短板：测试发现，LLMs在处理API依赖关系、状态管理上容易出错，尤其是开源模型，为后续改进指明了方向。
一段话总结：
为评估大型语言模型（LLMs）在顺序API调用 中的能力，研究提出了StateGen 自动测试生成框架和StateEval 基准。StateGen通过状态机基于API文档生成含顺序API调用的可执行程序，并经LLM代理转换为自然语言指令；StateEval包含120个手动验证的测试案例，覆盖Session Service、Tensor Operation、ElevenLabs MCP三个场景。评估显示，闭源LLM（如GPT-4.1）表现优于开源LLM，在Tensor Operation任务上表现最佳（GPT-4.1达78%通过率），而Session Service任务所有模型表现较差，LLMs在处理API依赖和状态管理上仍有较大改进空间。
思维导图（mindmap）：
详细总结：
1. 研究背景与问题
现有LLMs通过集成外部API扩展了能力，但对其工具使用的测试和评估仍处于早期阶段。多数基准依赖手动收集的测试案例，难以自动检查语义正确性，且忽视了顺序API调用间的复杂交互。现有研究存在局限：依赖手动数据集、聚焦简单API调用场景、缺乏对复杂API编排的评估。因此，研究核心问题是：如何设计自动测试生成方法，系统评估LLMs理解顺序API调用和管理程序状态的能力。
2. StateGen框架设计
StateGen是用于评估LLMs顺序函数调用能力的自动测试生成框架，核心流程包括：
- Trace生成：基于状态机，通过自底向上策略生成有效API序列，结合能量采样和成对转换覆盖引导，确保多样性和有效性。
- 程序生成：注入控制流（如if-else分支），增强程序复杂度，最终输出包含初始化块、控制流和RESULT变量的可执行程序。
- 指令翻译：由生成器和评估器两个LLM代理协作，将程序转换为自然语言指令，确保清晰性和自然性。
- 场景与预言机生成：覆盖三个场景（Session Service、Tensor Operation、ElevenLabs MCP），通过本地执行记录状态转换作为评估基准。
3. StateEval基准构建
利用StateGen生成并手动验证120个测试案例，形成StateEval基准：
- 场景分布：Session Service、Tensor Operation、ElevenLabs MCP各40个案例。
- 关键特点：与现有基准相比，具有更长的指令和代码长度（指令717.08 tokens，代码442.11 tokens）、更多API调用（平均7.16次）、更高路径深度（2.00）和绑定计数（5.03），反映更强的API依赖复杂性。
4. 实验评估结果
| 研究问题 | 核心发现 |
|---|---|
| RQ1：StateGen有效性 | 优于无覆盖引导（StateGen-w/o-COV）和LLM-only方法，相邻转换覆盖率更高且收敛更快。 |
| RQ2：StateEval与现有基准对比 | 在指令长度、代码长度、API调用数等指标上复杂度更高，更能反映真实API使用挑战。 |
| RQ3：LLM在StateEval上的表现 | 闭源LLM表现更优（GPT-4.1达56%通过率），开源LLM差距大（Qwen2.5-Coder为25%）；Tensor Operation任务表现最佳（GPT-4.1达78%），Session Service最差。 |
| RQ4：LLM错误分析 | 主要错误为执行错误（如数据访问异常、张量形状不兼容）和结果错误（如状态更新失败），语法错误较少。 |
5. 结论与局限
- 贡献：提出StateGen自动测试框架和StateEval基准，揭示LLMs在顺序API调用中的能力与不足。
- 局限：新场景需手动建模API，分析范围有限；未来可自动解析API文档，扩展LLM评估范围。
关键问题：
-
StateGen框架的核心创新点是什么？
核心创新在于结合状态机建模、能量采样和控制流注入生成多样化顺序API调用程序，并通过多LLM代理协作将程序转换为自然语言指令，实现对LLMs顺序API调用能力的自动化评估，解决了现有手动测试案例的局限性。
-
StateEval基准与现有代码生成基准相比，在复杂度上有何优势？
相比HumanEval、BFCL等基准，StateEval具有更长的指令和代码长度、更多的API调用次数、更高的路径深度和绑定计数，能更有效地评估LLMs处理复杂API依赖和状态管理的能力，更贴近真实世界API使用场景。
-
不同类型LLM在StateEval上的表现差异及原因是什么？
闭源LLM（如GPT-4.1）表现显著优于开源LLM（如Qwen2.5-Coder），因训练数据中相关API资源更丰富；模型在Tensor Operation任务上表现最佳（依赖PyTorch等常见框架的大量数据），在Session Service上最差（资源稀缺且数据操作复杂），表明API熟悉度对性能影响显著。
总结：LLMs的"工具使用课"还得补
这篇论文的核心结论很明确：现有LLMs在处理顺序API调用时，还不够"聪明"。但研究者提供了两个关键工具------StateGen（自动出题）和StateEval（标准化考卷），让我们能更精准地发现LLMs的不足。
未来，随着这些工具的普及，LLMs可能会像学开车一样，从"只会单个操作"进步到"能流畅完成复杂流程"，真正成为我们处理复杂任务的得力助手。