AppWorld — 多 App 世界里的交互式代码 agent
已复核 · 稳定内容AppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents 是一个评估交互式 coding agent 的环境和 benchmark。它构造了 9 个日常 App、457 个 API、约 100 个虚构用户，以及 750 个自然语言任务。
类比：普通 tool-use benchmark 像让你照菜单调用几个函数；AppWorld 更像给你一部装满 App 的手机和一群虚构用户，让你写代码跨购物、消息、日历、笔记等系统完成任务。
本卡只基于 arXiv v1 和论文静态阅读整理，没有安装 AppWorld Engine，也没有运行任务单测。所有结果保持 UNVERIFIED。
很多工具调用评测太简单：用户说一句话，模型按顺序调用几个 API，然后看参数是否正确。但真实数字任务往往是状态化、多 App、多用户、多步骤的。比如“给家里买晚饭并通知所有人”，可能要查联系人、查偏好、下单、写消息、处理库存和支付状态。
AppWorld 的问题是：能不能构造一个可控的数字世界，让 agent 必须通过代码和 API 交互完成真实日常任务，并用程序化测试判断结果？
它补上了 toolsandbox 与 webarena 之间的一块：不是网页点击，也不只是函数调用，而是用代码操作一组状态化 App。
- 它把 tool use 从单 API 序列推进到多 App 状态世界。
- 它要求 agent 生成有控制流的代码，而不是只填函数参数。
- 它用虚构用户和数字活动模拟真实生活状态。
- 它支持程序化 evaluation，比人工看轨迹更稳定。
- 它解释了为什么后续 agent RL / skill 论文喜欢用 AppWorld 做任务环境。
| 组件 | 作用 | 我怎么理解 |
|---|---|---|
| AppWorld Engine | 9 个 App + 457 APIs | 给 agent 一个可控数字世界 |
| fictitious users | 约 100 个虚构用户 | 让任务有联系人、偏好和历史状态 |
| natural tasks | 750 个任务 | 任务不只是函数调用题 |
| interactive code generation | agent 写代码并迭代执行 | 测规划、编程和环境反馈 |
| programmatic tests | 自动检查最终状态 | 减少只看轨迹的主观性 |
AppWorld 的关键词是 state。工具调用一旦有状态，顺序、条件判断、异常处理和最终验证都会变重要。
- 引言指出现有工具调用 benchmark 过于单步和无状态。
- Engine 章节说明 App、API、用户和数据世界如何构造。
- Benchmark 章节介绍 750 个任务和测试方式。
- Baseline 章节比较交互式 coding agent 的表现。
- 分析章节讨论任务复杂度、错误类型和执行反馈。
读这篇时要注意它把 agent 定义成“会写代码操作环境”的系统，而不是只会返回 tool call JSON 的模型。
手工 toy 复现
Section titled “手工 toy 复现”我用一个极小 AppWorld-like 任务手推：
任务：把 Alice 的 Spotify 歌单备份成 CSV，发给 Bob，然后注销 Alice 的音乐账号。
| 子任务 | 需要的 App / API | 难点 |
|---|---|---|
| 查 Alice 身份 | contacts / users | 名字到用户 ID |
| 读取歌单 | music API | 分页和权限 |
| 生成 CSV | 文件 / 代码 | 数据格式 |
| 发给 Bob | messaging / email | 联系人解析 |
| 注销账号 | account API | 顺序和确认 |
| 验证结果 | tests | 文件、消息、账号状态都要对 |
单轮 tool call 评测很难覆盖这个流程，因为每一步依赖上一步状态。AppWorld 的价值就在于把这种状态链变成可测任务。
读 AppWorld 结果时，我会重点看三件事：
- agent 是否能写出可执行代码，而不是只描述流程。
- agent 是否会读取环境反馈并修正代码。
- 最终测试覆盖的是单个 API 结果，还是跨 App 状态一致性。
如果一个 agent 能在简单 function calling benchmark 上高分，但在 AppWorld 上失败，通常说明它缺少状态建模、控制流和调试能力。
- 不要把 API 调用当成无状态动作：真实 App 会记住历史和副作用。
- 不要忽略用户模型：联系人、偏好、权限会改变任务含义。
- 不要只看单步准确率：多步任务里一步错会连锁污染。
- 不要让 agent 只写伪代码：AppWorld 测的是可执行代码和环境交互。
- 不要把虚构世界当真实业务：它可控但仍是模拟环境。
与当前工作的连接
Section titled “与当前工作的连接”今天就能用：设计 tool-use agent 时，要把“状态一致性”写进验收。比如发消息任务不能只看调用了 send，还要看收件人、内容和后续状态。
下个月可以用：如果做内部 agent eval，可以建一个小型 AppWorld：3 个假 App、20 个 API、若干虚构用户，再用测试检查最终状态。
不要照搬：公司真实 App 有权限、隐私和审计要求。模拟世界能训练思路，但不能直接连接真实账户做自由探索。
- 真正的工具调用难点是状态，而不是 JSON 格式。
- 交互式 coding agent 需要读反馈、改代码、再执行。
- AppWorld 是连接 function calling、coding agent 和数字任务自动化的重要 benchmark。
- 它和 toolsandbox 互补：ToolSandbox 偏对话式工具使用，AppWorld 偏多 App 代码执行。
- 原文：https://arxiv.org/abs/2407.18901
- 本卡使用版本：https://arxiv.org/abs/2407.18901v1
- toolsandbox：状态化、对话式工具使用 benchmark。
- toolllm-2023：工具学习和 ToolBench 方向。
- toolformer：工具使用能力训练的早期路线。
- terminal-bench：终端环境里的长程执行评测。