字节 Seed 推出了 EdgeBench，一个面向“真实世界环境学习”的超长程 Agent 评测集。它不是让模型回答几道静态题，而是把 Agent 放进需要长期交互、持续试错和逐步适应的环境里。根据摘要，EdgeBench 覆盖 134 个真实且多样的任务，横跨六大能力领域，每个任务都允许 Agent 持续工作至少 12 小时；其中 51 个任务和完整评测框架已经开源。
这类基准的价值在于，它开始触碰当前 Agent 系统最难逃避的问题：模型会说、会规划，不等于能在一个变化的环境中稳定学习、修正策略并完成长任务。
为什么“12 小时任务”比一次性问答更难
很多 Agent demo 看起来顺滑，是因为任务边界很短：读一个文件、调用一次 API、修一个小 bug、生成一份报告。短任务里，模型主要依赖预训练知识、上下文窗口和工具调用格式。
EdgeBench 强调的“环境学习”更接近真实工作流：
- Agent 要反复观察环境反馈，而不是只读题目。
- 任务状态会随着操作改变，错误可能在几个小时后才显现。
- 成功依赖长期记忆、策略调整、工具使用和恢复能力。
- 评测不只看最终答案，还要看长程交互过程中的稳定性。
摘要里提到，基于这些长程环境交互运行结果，研究者发现 Agent 在“环境学习”过程中的整体表现遵循某种规律。这一点很关键：当任务足够长，评测就不再只是排行榜分数，而是能暴露 Agent 学习曲线、失误模式和瓶颈阶段。
EdgeBench 给开发者的信号
EdgeBench 的任务数和时长设计，说明 Agent 评测正在从“会不会做”转向“能不能持续做”。这对工程团队有直接影响。
如果你在做代码 Agent、办公 Agent、浏览器 Agent、数据分析 Agent 或运维 Agent，短基准只能验证局部能力。真正上线前，还需要回答这些问题：
- Agent 是否会在多轮失败后重复同样错误？
- 它能否把环境反馈沉淀成下一步策略？
- 长时间运行时，成本、日志、上下文和工具错误如何控制？
- 任务中断后是否能恢复，而不是从头再来？
- 评测是否记录了过程证据，而不是只保存一个最终分数？
EdgeBench 开源了 51 个任务及完整评测框架，适合研究者复现实验，也适合工程团队借鉴它的评测形态：任务要真实、链路要长、反馈要可记录、失败要可诊断。
可以这样实践：搭一个最小长程 Agent 评测骨架
下面不是 EdgeBench 的官方接口，而是一个可以改造的最小示例，用来模拟“环境学习”型评测。它把 Agent 放进一个简单环境中，要求它通过多轮动作逐步逼近目标，并记录每一步观察、动作和奖励。
你可以把 agent_policy 替换成自己的 LLM 调用、工具调用或浏览器操作逻辑。
# long_horizon_eval.py
# Python 3.10+
import json
import random
import time
from dataclasses import dataclass, asdict
from typing import Literal
Action = Literal["probe_left", "probe_right", "commit_left", "commit_right"]
@dataclass
class StepRecord:
step: int
observation: str
action: Action
reward: float
done: bool
class HiddenPreferenceEnv:
"""A tiny environment-learning task.
The agent does not know which side is correct. Probing gives noisy hints;
committing ends the episode with success or failure.
"""
def __init__(self, max_steps: int = 20, seed: int = 7):
self.rng = random.Random(seed)
self.target = self.rng.choice(["left", "right"])
self.max_steps = max_steps
self.steps = 0
def observe(self) -> str:
return f"step={self.steps}, budget_left={self.max_steps - self.steps}"
def step(self, action: Action):
self.steps += 1
done = False
reward = -0.01
if action.startswith("probe"):
side = action.split("_")[1]
# Noisy feedback: correct side is more likely to return a positive hint.
positive_rate = 0.75 if side == self.target else 0.25
hint = "positive" if self.rng.random() < positive_rate else "negative"
observation = f"probe_result side={side} hint={hint}"
else:
side = action.split("_")[1]
done = True
reward = 1.0 if side == self.target else -1.0
observation = f"final_result committed={side} success={side == self.target}"
if self.steps >= self.max_steps and not done:
done = True
reward = -0.5
observation = "timeout"
return observation, reward, done
def agent_policy(history: list[StepRecord]) -> Action:
"""Replace this with your LLM/Agent policy.
This toy policy probes both sides, counts positive hints, then commits.
"""
if len(history) < 8:
return "probe_left" if len(history) % 2 == 0 else "probe_right"
left_score = sum("side=left hint=positive" in r.observation for r in history)
right_score = sum("side=right hint=positive" in r.observation for r in history)
return "commit_left" if left_score >= right_score else "commit_right"
def run_eval(seed: int = 7):
env = HiddenPreferenceEnv(max_steps=20, seed=seed)
history: list[StepRecord] = []
for step in range(20):
observation = env.observe()
action = agent_policy(history)
next_observation, reward, done = env.step(action)
record = StepRecord(
step=step,
observation=f"{observation}; {next_observation}",
action=action,
reward=reward,
done=done,
)
history.append(record)
if done:
break
time.sleep(0.05)
result = {
"total_reward": sum(r.reward for r in history),
"steps": len(history),
"success": history[-1].reward > 0,
"trace": [asdict(r) for r in history],
}
print(json.dumps(result, ensure_ascii=False, indent=2))
if __name__ == "__main__":
run_eval()
运行：
python long_horizon_eval.py
改造时重点换三处：
- 把
HiddenPreferenceEnv换成真实环境，例如浏览器、代码仓库、数据库沙箱或运维演练环境。 - 把
agent_policy换成你的 Agent 主循环，包括 LLM prompt、工具调用和记忆模块。 - 把
StepRecord扩展为可审计日志，记录 prompt、tool call、stderr、耗时、token 和成本。
一个更接近生产评测的记录结构可以长这样：
{
"task_id": "repo-debug-042",
"run_id": "2025-01-15T10:00:00Z-model-a",
"step": 17,
"observation": "pytest failed in tests/test_parser.py::test_nested_case",
"agent_thought_summary": "Need inspect parser state transition",
"action": {
"tool": "shell",
"input": "pytest tests/test_parser.py -q"
},
"reward": -0.02,
"cost_usd": 0.031,
"duration_ms": 1840
}
注意这里的 agent_thought_summary 应该是可审计摘要，不一定要保存完整推理链。对企业环境来说，日志合规、密钥脱敏和数据隔离比“多存一点方便分析”更重要。
长程评测要看什么指标
如果借鉴 EdgeBench 的方向建设内部评测，不建议只看最终成功率。长任务里，成功率会掩盖过程质量。
更有用的指标包括：
time_to_first_useful_action：Agent 多快开始做有效探索。repeated_error_rate：是否反复执行已失败动作。recovery_rate：工具失败、环境变化或假设错误后能否恢复。checkpoint_quality：中断后恢复是否依赖清晰状态，而不是完整上下文。cost_per_success：成功一次需要多少 token、工具调用和墙钟时间。trace_auditability：失败后工程师能否从日志定位原因。
EdgeBench 这类超长程评测的难点也在这里：它更接近系统测试，而不是单模型测试。Agent 的表现会同时受到模型、工具、记忆、调度器、环境封装和评测器影响。分数下降不一定说明模型差，也可能是工具错误、状态污染或奖励设计不清楚。
采用建议：先用小闭环，再拉长任务
EdgeBench 已经把问题推向了更真实的方向，但团队落地时不必一开始就跑 12 小时任务。更稳妥的做法是分层推进：
- 先选 5 到 10 个真实任务，保证每个任务都有明确初始状态、成功条件和失败日志。
- 把 Agent 的每一步交互结构化记录下来，避免只保存最终输出。
- 从 15 分钟任务开始，逐步扩展到 1 小时、4 小时、12 小时。
- 对每次失败做归因：模型理解、工具能力、记忆缺失、环境不可控，还是评测标准模糊。
- 固定随机种子、环境镜像和依赖版本，减少“今天能过、明天不能过”的噪声。
EdgeBench 的开源部分给了社区一个重要参照：真实 Agent 能力不能只靠短题证明。环境会反击，时间会放大小错误，日志会暴露系统设计。能在长程任务里稳定学习和恢复的 Agent，才更接近能交付工作的 Agent。