端到端与轨迹前缀回归任务
回归任务分哪两层？
- 端到端回归任务: 验证改动没有破坏完整工作流;
- 轨迹前缀（trajectory prefix）回归任务: 截取首个错误之前的状态，只验证那个决策边界是否被修好;
- 流程位置: 失败归因明确首错及其类别后，下一步就是把修复目标写成可重复执行的测试用例;
- 相关: 首错定位方法见 失败归因;
端到端回归任务的形态与局限是什么？
- 形态: 从初始状态和用户请求开始，让 Agent 完成整个任务，并检查最终状态、必要输出和安全条件;
- 优势: 最接近生产结果;
- 局限: 难以判断失败究竟发生在哪一步;
- 用途: 验证 Agent 在各个领域的能力符合预期;
- 例子: OSWorld、AndroidWorld、τ-bench 等标准评测集都是端到端回归任务;
轨迹前缀回归任务为什么更重要？
- 做法: 把已有的上下文、对话、工具返回和环境状态冻结下来，只要求 Agent 思考并执行下一步或下几步可观察动作;
- 优势: 成本更低，也能隔离单个策略或工具问题;
- 适用: 对于需要高可靠性的生产级 Agent，构建轨迹前缀回归任务集往往比端到端回归任务集更重要;
- 前提: 需要开发者耐心建立失败分类体系与失败归因系统，见 失败归因;
- 答案定义: 应定义为可接受动作集合而非唯一的动作或答案，可以要求 “先读仓库规则”“先询问用户”“拒绝危险操作”，同时列出禁止动作;
- 定位手段: 轨迹前缀二分——把轨迹截到第 k 步交给人接手，能救回来说明错误在 k 之后;
- 禁用手段: 不能用搜索报错关键字代替首错定位，静默失败要靠事实锚点比对或前缀二分;
各类失败应转成什么样的回归任务？
| 失败类别 | 回归任务设计 |
|---|---|
| 流程缺失 | 生成带有计划文档和测试验收条件的端到端回归任务 |
| 工具调用错误 | 把出错前缀截断并编辑成边界任务，测试能否修正格式、转义特殊字符或换用合适工具 |
| 执行异常 | 加入截断、超时和工具故障的恢复场景 |
| 完成度与逻辑错误 | 加入多目标清单、剩余任务提醒和 “尚未证明不可能” 的边界 |
| 需求理解与歧义 | 把有多种合理解释的任务冻结成前缀，把 “先澄清” 列入可接受动作 |
| 症状修复与验证造假 | 验收补上 “不得修改测试断言” 和 “完成声明必须附带真实执行过的命令输出” 两条硬约束 |
| 信息反馈错误 | 验收对答复内容本身设断言，而不只检查环境状态 |
同一上下文的不同表示会带来什么差异？
- 设置: 把已经提供给 Agent 的上下文（本例为用户记忆）、当前任务、trajectory prefix、工具返回和环境状态一起输入模型，要求模型只输出下一步可观察动作;
- 用例来源: 三类生产问题案例——用户纠正、点踩关联轨迹，以及事后规则/LLM 审计发现的错误;
- 边界覆盖: 论文风格与 X 帖子的作用域冲突、worktree/PR 习惯与仓库规则冲突、当前明确指令覆盖旧偏好、低置信度推断、高风险删除前确认、对外发布前预览;
- 三种表示: JSON Cards、Markdown 与 Python-like 三种语义等价的编码;
- 结果: 用 GPT 5.6 Sol 完成 11 个边界用例 × 3 种表示、共 33/33 个 API 单元且无 API 错误，三种表示总成绩碰巧都是 6/11，但失败位置并不完全相同;
- 细节: Markdown 通过了 “仓库规则未知时先检查” 的用例，却多失败了一个作用域冲突用例，JSON Cards 与 Python-like 的情况相反;
- 共同失败: 三种表示都没有通过论文风格过度泛化、过时偏好覆盖当前要求、以及高风险删除前确认三类用例;
- 结论: 改变上下文的表示方式并不会自动修复应用策略;
- 抽象结论: 获得一条信息和正确地将它用于当前决策是两种不同能力;
- 下游: 评估数据集是模型后训练与 Agent 自我进化的基础，见 仿真环境与后训练桥梁;