长程 Agent
长程 Agent 任务应该如何设计
长程任务要考察 Agent 能否在连续决策中保持目标与状态 任务时长只是资源约束 真正需要定义的是阶段之间的依赖关系以及最终结果如何验收
先说清楚时长指什么
Terminal-Bench 4 将 Agent 超时上限设为 8 小时 这是执行预算 并不表示每条任务都会运行 8 小时 对实际耗时的描述应附带 Agent 配置与资源条件
参考来源 · Terminal-Bench 4 · Resource calibration
| 时长口径 | 含义 |
|---|---|
| 超时预算 | 允许执行的时间上限 |
| 实际耗时 | 某次执行在指定条件下的实际用时 |
| 专家工作量 | 人工完成或审核任务所需的工作量 |
让阶段之间存在真实依赖
可以从服务迁移到新版数据格式这一目标倒推任务结构 数据结构决策会影响转换逻辑 验证样本和应用行为 这些依赖让多个步骤构成完整工作 而不是互不相关的练习集合
以下迁移流程为自拟设计示例 不代表 Efflora 的实测记录 每个阶段都应产出下一阶段确实需要且可以检查的结果
- 检查现有结构并明确迁移约定
- 实现转换并保持必要约束
- 验证转换记录并修复发现的不一致
- 在迁移后的状态上运行应用
让恢复过程可观察
说明允许在哪个位置中断以及中断后哪些状态会保留 检查点应标明已完成工作 待处理事项与环境版本 恢复时应让 Agent 检查现有产物 而不是悄悄换成新的干净任务
同时保留失败尝试与成功重试 如果重试重复写入或丢失已完成工作 仅看最终产物可能掩盖恢复缺陷 应比较中断前 恢复后和最终完成时的状态
分别确认任务难度与可交付范围
用依赖深度 信息不确定性 工具切换和恢复要求描述任务挑战 在把 Agent 失败解释为能力不足之前 先确认任务在给定环境中确实可完成
咨询长程数据时应明确要交付哪些阶段与产物 并分别约定执行轨迹 可运行环境和验收检查 仅使用某个 Benchmark 名称无法说明这些交付属性