EdgeBench 论文阅读：Agent 如何从真实环境反馈里持续变好

论文 / 技术报告：EdgeBench: Unveiling Scaling Laws of Learning from Real-World Environments，ByteDance Seed。官方仓库是 ByteDance-Seed/EdgeBench，项目页是 edge-bench.org。

EdgeBench 做的事情可以概括成一句话：它不再只问 Agent 最后有没有做对，而是问 Agent 能不能在一个真实可执行环境里，靠反馈、试错和迭代逐渐变好。

这和很多传统 benchmark 的重心不一样。普通问答评测看的是一次回答；SWE-bench 看的是最终 patch 是否通过测试；tau-bench 关注状态化任务和多次运行稳定性。EdgeBench 更关心的是一条轨迹：

初始尝试 -> 本地运行 -> 看到错误 / 分数 / 失败样例 -> 修改策略 -> 再提交 -> 继续改进

所以它测的不是单点能力，而是 environment learning：模型部署之后，能不能从环境反馈中学习。

任务长什么样

EdgeBench 一共有 134 个真实任务，公开其中 51 个任务和完整评测框架。任务分成六类：

类别	数量	大致在测什么
Scientific Problems & ML	39	科学数据、实验建模、预测、反问题、机器学习
Systems & Software Engineering	36	真实代码库、大规模修改、性能优化、系统实现
Combinatorial Optimization	19	路由、调度、SMT、启发式搜索
Professional Knowledge Work	19	金融、教育、医疗、法律等专业交付物
Formal Math & Theorem Proving	13	Lean / Coq 里的形式化证明
Interactive Games & Simulators	8	NetHack、OpenTTD、文本冒险、策略游戏等

关键不只是任务数量，而是任务时间尺度。论文说每个任务都支持至少 12 小时的连续 Agent 运行；记录下来的人类专家工作量平均是 57.2 小时，最高到 320 小时。EdgeBench 故意避开那种“模型凭训练记忆或一次推理就能解决”的短题，而是把 Agent 放进更像真实工作现场的环境里。

它也刻意排除了主要难点在视觉理解上的 GUI 任务。这个取舍是有道理的：如果任务失败主要因为视觉 backbone 看错了界面，就很难分清楚是在测“环境中学习”，还是在测多模态感知能力。

但是，这些任务不是从真实世界随机抽样来的，而是按两个条件筛出来的：当前 Agent 不能很快做满分，并且任务流程要支持 continuous learning。这个筛选本身合理，因为论文就是想研究长时程学习；但它也意味着 EdgeBench 更像“专门构造出来能观察学习曲线的任务集”，不是一个无偏的真实工作分布。如果只在这种任务集上看到 log-sigmoid，不能直接外推到所有 Agent 工作流。

反馈怎么给

EdgeBench 的评测框架叫 SForge。它的核心设计是两个环境分离：

work container：Agent 能看到和操作的工作环境
judge container：隐藏测试、隐藏评分、私有 rubrics 所在的评测环境

Agent 在 work 环境里可以自由探索：读文档、改代码、跑本地测试、训练模型、看日志、做实验。这个部分像真实工作里的快速本地循环。

但最终成绩不靠 Agent 自己说了算。Agent 可以把当前产物提交给 judge，judge 用隐藏测试、隐藏 seed、专家 rubric 或私有数据给出反馈。这个部分像真实工作里的外部验收：线上指标、客户评审、隐藏测试集、同行审阅。

此外，反馈不是一个被动的自然环境，而是人工设计出来的评测接口。不同任务的 judge 可能返回隐藏测试分数、diagnostics、unseen-seed 结果、proof checker 状态、游戏分数或专家 rubric。Agent 学到多少，很大程度取决于任务设计者给了什么反馈、反馈多细、反馈能不能被反复查询。这个设计很接近真实工程里的验收循环，但它也让“环境学习能力”和“评测器可利用性”纠缠在一起。

这就形成了一个双层反馈回路：

本地反馈：快，次数多，Agent 自己驱动
隐藏 judge 反馈：慢，更权威，防止只对 visible tests 过拟合

最后分数也不是只取最后一次提交，而是记录整个运行期间的最好结果，并按 2h、4h、6h、8h、10h、12h 等时间点看性能如何变化。这个设计让 EdgeBench 能画出“学习曲线”，而不是只给一个最终排行榜。

不过， best-so-far 会改变问题含义。论文记录的是运行过程中出现过的最好产物，并且会用隐藏 judge 做 host-side auto-evaluation；这些自动评测结果不展示给 Agent，只用于画曲线。这样能更细地测量产物质量随时间变化，但它不是“Agent 当前状态是否可靠”的指标。真实部署里，如果系统最后把好结果覆盖掉、后续修改退化、或者需要在任意时刻交付，best-so-far 曲线会高估可用性。

外层 judge 也不是完全不可交互的黑箱。Agent 可以主动提交当前产物，拿到任务规定的分数、verdict 或诊断信息；系统还有 cooldown、队列和异步评测。这意味着提交策略本身会影响成绩：一个 Agent 可能因为更会安排提交、更会从 judge 信息里反推评分结构而得分更高。论文分析了 effective submission rate，也承认更多提交不自动等于更好结果；但这仍然说明 benchmark 测到的是“模型 + 工具 + 提交策略 + 反馈利用”的组合系统，不是纯模型能力。

论文最想说明什么

技术报告里最显眼的结论是：在约 38,000 小时的 Agent-环境交互数据上，整体性能随交互时间呈现非常稳定的 log-sigmoid 曲线，报告的平均拟合 (R^2 = 0.998)。

直观理解就是：Agent 刚开始会快速吃掉一批容易获得的反馈收益；中间进入持续改进阶段；后面逐渐接近当前系统能达到的上限。论文还进一步说，前沿 Agent 的环境学习速度大约每三个月翻倍一次。

但是，这几个数字很容易被带着走。论文其实承认单个任务轨迹可能有长平台、突然跳变和回退，log-sigmoid 主要是 134 个任务平均之后出现的结构。平均会抹平很多异质性；任务归一化、任务权重、任务难度中点是否对齐，都会影响 (R^2)。所以 (R^2 = 0.998) 更像是“这个任务集按这个协议聚合后非常平滑”，不等于每个任务、每类任务或每个 Agent 都服从同一条自然律。

论文也不是完全没做反驳实验。它有一个重要对照：在 17 个任务上比较连续 12 小时运行和 6 次独立 2 小时重启，连续经验更好。这能反驳“只是多抽几次样本所以 best score 上升”的简单质疑。但这个对照只覆盖一个模型和一个任务子集，不能直接证明所有模型、所有任务上的上升都来自真正的经验积累。更理想的实验会系统控制 judge 查询次数、提交间隔、反馈粒度、上下文长度、外部记忆和工具环境。

模型比较也会混入 agent harness。论文里 GPT 系列通过 Codex 运行，部分其他模型通过 Claude Code 运行；长时程过程中还涉及 workspace 文件、压缩、上下文窗口、进度记录、自动评测和外部工具。这样得到的分数更像“某个完整 Agent 系统”的分数，而不是裸模型的分数。尤其是论文还专门比较了 200k 和 1M context，说明上下文和外部状态管理本身就是实验变量。

不过，这些限制不让 EdgeBench 失去价值，只是会改变它的读法。它提出的评测视角是：Agent 能力不只是预训练时的静态能力，也包括部署后利用反馈的动态能力。文中的“学习”更适合理解成完整系统在测试时利用环境和工具改进产物，不要直接理解成底层模型形成了可迁移的新能力。

这对 Agent 主线很重要。ReAct 让我们看到 action / observation 闭环；SWE-bench 把代码 Agent 拉到真实 repo issue；tau-bench 强调状态化任务和 pass^k；Agent Reliability 则提醒我们要拆开 consistency、robustness、predictability、safety。EdgeBench 接上的问题是：

如果给 Agent 足够长的时间、真实工具、局部反馈和外部评分，
它到底是在随机试错，还是在稳定学习？

怎么读它

EdgeBench 不是一个新的 Agent runtime 范式，也不是说某个模型已经“会自主科研”了。它更像是把 Agent 评测从“终点分数”推进到“过程曲线”。

这个推进很关键。很多真实任务不是一次提交就结束：工程师会看测试失败，科学家会看实验结果，金融分析师会看客户反馈，游戏玩家会从一局局失败里改策略。如果 Agent 要进入这些场景，只看最后答案太粗了。我们需要知道它在过程中有没有保留经验、有没有修正策略、有没有被隐藏反馈校准、有没有越试越好。

不过，EdgeBench 的实验设计本身也在提醒我们：Agent evaluation 不能只问“分数涨没涨”，还要问“分数为什么涨”。收益来自模型推理，还是来自外部脚手架？来自本地调试，还是来自 judge 反馈？来自连续经验，还是来自提交筛选？来自通用能力，还是来自任务设计者给出的可爬坡评分结构？这些问题比排行榜名次和漂亮曲线更重要。

这篇适合放在 Agent 主线的 2026 年评测支线里，和 Agent Reliability 一起读。前者问“可靠性应该拆成哪些维度”，EdgeBench 则给了一个更工程化的切口：用长时程任务和真实反馈，把 Agent 的学习曲线实际测出来。