本节是本站根据 阿里巴巴《AI Native 研发范式实践手册》 整理的补充，由杨正武撰写。前面的章节已经讨论验证机制和组织资产。这里补上一件容易漏掉的工作：怎样知道这些机制改善了交付，以及一次失败如何回到下一轮任务。
从会话追到需求的结果
“用了多少 Agent”“生成了多少行代码”能反映使用情况，无法直接证明交付提效。手册提出沿 Session → Commit → Change → Workitem 关联事实，再分三层观察：
| 层次 | 观察什么 | 避免的误判 |
|---|---|---|
| 工具和上下文使用 | 有效会话、代码采纳、Skill 与工具调用 | 把安装量或 Token 当作成果 |
| 工程质量 | 缺陷、回滚、变更失败、恢复时间 | 用更快的生成掩盖返工 |
| 价值交付 | 需求交付周期、发布频率、业务效果 | 把合并代码当作需求已生效 |
这条关联必须使用真实对象关系。一个仓库里同时有多条会话、多次提交和多个需求，按仓库名直接拼接会产生重复归因。任务、提交、变更和需求需要稳定 ID；无法建立关系的样本应标记为“未归因”，不要硬算进收益。做 AI 与非 AI 任务对比时，还要考虑需求复杂度、团队和时间段的差异。手册中的案例数字是各团队的阶段性报告，不等于受控实验结论。
把轨迹变成可复核的失败样本
传统 Trace 记录调用时间和错误，Agent 还需要一条能看见目标、计划、模型与工具调用、状态变化、验证结果的任务轨迹。手册把它称为 Trajectory，并建议和系统 Trace 关联。观察者因此能回答：任务失败是模型选错工具、环境缺依赖、权限被拒、验证标准不完整，还是交付后没有进入发布流程。
每次失败至少留下任务目标、运行版本、使用的上下文、关键工具调用、退出码或拒绝原因、验证证据和最终处理结果。敏感数据与凭据不进入通用轨迹。轨迹用于复盘和评测，也用于建立回归样本；仅记录“Agent 失败”无法帮助下一次执行。
改进应回写到正确的位置
演进章节讲的是 Harness 自身如何从异常中改进。阿里手册的案例给出了更具体的回写路径：线上失败轨迹可以进入能力补齐；缺少的知识进入有来源、责任人和版本的知识单元；工具找不到或调用不成功时，检查 Skill 的触发描述、参数与权限；环境搭不起来时，修项目运行定义和数据基线；证据不足时，补测试或门控检查项。
可以给每类异常指定一个落点：
- 意图不清，修 Spec 和验收条件。
- 工具选择错误，修 Skill、工具描述或能力路由。
- 环境不可复现，修运行定义、镜像或测试数据。
- 权限与风险边界不清，修委托策略和审批协议。
- 检查漏报，补回归样本和验证规则。
改完以后，用同一条失败样本复跑，并观察后续真实任务是否减少同类问题。Harness 的收益由交付链路、质量和复用效果共同证明。