第 11 章 前沿工程：Harness、Context、Skills 与 Agentic RL
Harness、Context Engineering、Skills、恢复与 Agentic RL
11.1 前沿地图：模型之外还有哪些杠杆
本章新增资料于 2026-09-26 核对。前沿工程不只关注更强的模型，还要回答：模型每步能看到什么、动作由谁执行、任务中断后如何恢复、完成由谁验收、失败怎样变成下一轮改进。
| 方向 | 改动对象 | 核心问题 | 本章入口 |
|---|---|---|---|
| Harness Engineering | 运行时与工作环境 | 怎样让行动可控、可恢复、可验收 | 11.2–11.4 |
| Context Engineering | 每步输入的信息 | 哪些证据现在需要，哪些留在外部 | 11.5；基础见第 6 章 |
| Agent Skills | 可复用的操作知识 | 如何按任务加载流程、脚本和参考资料 | 11.6 |
| 测试时搜索与验证 | 推理时计算分配 | 多次尝试何时比单次尝试划算 | 11.7 |
| Agentic RL | 模型策略参数 | 如何用环境反馈训练工具使用和决策 | 11.8 |
| Computer Use / 代码 Agent | 观察与动作空间 | 怎样在真实界面和仓库验证终态 | 11.9 |
贯穿案例：让 Agent 修复一个仓库问题。模型负责提出下一步；harness 提供工作目录、搜索/编辑/测试工具、预算与状态存储；context 层选取相关文件和失败日志；skill 提供某类问题的处理流程；验收器检查最终补丁。下面的结构与实验是教学设计，不是某个产品的完整实现。
具体产品如何实现这些机制，见 第 13 章：五家 Agent 技术拆解与对比。
11.2 Agent Harness 是什么，和框架有什么区别
Agent harness 是围绕模型组织观察、执行、状态和反馈的系统。 第 2 章的工具循环是它的起点。工程上还要处理取消、超时、权限、上下文、检查点和结果验证。这里的 harness 指 Agent 执行环境，不是同名的软件交付平台。
| 概念 | 负责什么 | 修仓库问题时的例子 |
|---|---|---|
| 模型 | 根据当前输入提出文本或动作 | 建议读取失败测试关联的文件 |
| 框架 / SDK | 提供消息、工具、编排、状态等开发抽象 | 帮你实现节点调度或工具结果回填 |
| Harness | 把模型接入可运行的任务系统 | 配置工具、权限、预算、恢复和验收 |
| MCP / A2A | 定义跨系统连接方式 | 接工具服务或远端 Agent |
| Eval harness | 控制评测环境、运行样例并评分 | 重置仓库、跑任务、执行隐藏测试 |
这些概念有重叠：SDK 可以实现部分 harness；自己写循环也能构成最小 harness。不能仅凭“用了某框架”判断恢复和验收已做好。生产 harness 执行任务，评测 harness 检查系统表现；二者应共享必要的环境配置，但评测答案和隐藏检查不能暴露给被测 Agent。
“模型不变，harness 改进后效果提高”需要实验支撑：固定模型版本、任务和预算，逐项改变工具接口、上下文、恢复或验证机制。否则无法区分收益来自哪一层。
11.3 Harness Engineering 的两种关注范围
这个术语尚没有单一、统一的行业边界。阅读时先辨认文章在讨论运行时，还是整个工程环境。
Anthropic 的长任务 harness 实践 [导读]侧重跨会话连续工作：先初始化环境，再逐步推进，借助功能清单、进度记录、版本历史和端到端测试交接状态。它展示的是一种 Web 开发方案，不能据此假设所有长任务都要设置两个 Agent。
OpenAI 的 Harness Engineering 实践 [导读]还强调让仓库知识、应用界面和观测数据对 Agent 可读，并通过工具和机械检查落实工程约束。它描述的是特定团队的工程实验，不是通用性能保证。
从这两种关注范围出发，可以给自己的项目做以下设计：
| 层 | 最小设计 | 常见失败 | 可观察的检查 |
|---|---|---|---|
| 任务契约 | 目标、范围、验收标准 | 改完一个文件就宣布全部完成 | 需求清单有未验收项时不能结束 |
| 上下文构造 | 约束、当前状态、证据引用 | 读旧日志后沿错误方向继续 | 文件版本与证据时间可追溯 |
| 动作执行 | schema、超时、沙箱、权限 | 参数合法但动作越权 | 在工具侧拒绝越界调用 |
| 状态持久化 | 进度、产物、待处理调用 | 重启后重复执行外部动作 | 读取调用记录并核对外部状态 |
| 反馈与终止 | 测试、检查器、预算 | 自评通过但功能不可用 | 验收器独立检查环境终态 |
| 工程环境 | 启动脚本、文档索引、日志入口 | Agent 猜命令、猜架构 | 新会话能定位并复现已知问题 |
面试追问：“把 prompt 写长一点不就行了？”答：prompt 能说明规则，但不能强制文件权限、杀掉超时进程、恢复事务或替代测试；需要把可执行约束落进运行时和环境。
11.4 长任务：Checkpoint、恢复与完成判定
上下文压缩保存的是模型接下来能读到的信息；checkpoint 保存的是可恢复的任务状态。二者都不能自动撤销外部系统已经发生的副作用。进度笔记是线索，真实文件、版本和外部状态才是恢复时应核对的对象。
下面是教学用检查点，字段不属于任何框架规范：
{
"task_id": "fix-parser-017",
"goal": "修复空输入解析，保持已有接口",
"status": "running",
"workspace_revision": "local-checkpoint-03",
"completed": ["复现空输入错误"],
"pending": ["修改解析器", "运行相关回归"],
"evidence": [{"path": "artifacts/repro.log", "revision": "local-checkpoint-03"}],
"inflight_actions": [],
"budget_used": {"model_calls": 6, "tool_calls": 9}
}
一次可恢复会话的流程：
- 恢复前核对：读目标、约束和检查点，检查实际工作区版本；过期证据标为待重验。
- 处理未决动作：工具超时不代表没有执行。查调用 ID、幂等键或外部状态，再决定是否重试。
- 增量推进：选择一个有明确验收的小步骤，执行后保存产物和证据。
- 持久化交接：原子写入检查点；记录失败尝试、待解决问题和下一步，避免只写“继续优化”。
- 判定终态：全部要求经验收后才标为完成；预算耗尽、等待外部条件和用户取消分别记录。
崩溃可能发生在“工具完成”与“记录落盘”之间，所以本地 checkpoint 不等于 exactly-once 执行保证。有副作用工具还需要幂等设计或恢复后的状态对账。
实验：在第 5、10、15 次工具调用后中断同一任务，再启动新会话。比较“只留聊天摘要”与“摘要 + 检查点 + 状态核对”的恢复成功率、重复动作数和恢复开销；两组保持相同总预算。另设用例：测试失败时模型仍输出完成，运行时应保留未验收状态。
11.5 Context Engineering：每一步构造工作上下文
Anthropic 的 Context Engineering 指南 [导读]讨论每轮如何管理指令、工具、历史与外部信息，并结合按需读取、压缩和外部笔记。第 6 章讲存储与压缩，本节把它放进 harness 的逐步执行过程。
修仓库时可按以下方式构造输入：
固定目标与约束 + 当前计划 + 最近失败反馈
+ 相关文件片段 + 必要工具定义 + 原始证据的路径
↓
模型决策
↓
新结果先分类，再决定回填原文 / 摘要 / 引用
| 做法 | 解决的问题 | 必须观察的代价 |
|---|---|---|
| 按需读取 / Agentic retrieval | 避免预加载整个仓库 | 更多探索调用；可能漏查关键文件 |
| 工具结果裁剪 | 避免一份日志挤掉目标 | 截断位置可能藏着真正错误 |
| Compaction | 让任务跨上下文继续 | 丢失约束、证据或未完成分支 |
| 外部笔记 | 保存决策与进度 | 笔记过期、把推断误写成事实 |
| 子任务隔离 | 避免相互无关的历史混杂 | 合并成本与遗漏证据 |
实验：固定模型和任务，比较全量加载、检索后加载、路径索引加按需读取。记录成功率、关键约束遗漏、输入 token、探索调用和总时延。减少 token 只有在任务表现保持或改善时才有价值。
11.6 Agent Skills：可复用流程如何进入 Harness
Agent Skills 原始介绍 [导读]把指令、脚本与资源组织成可按需发现和加载的目录。渐进式加载通常先暴露名称和描述，匹配任务后再读取正文与相关资源。
教学例子：把“解析器故障排查”封装成如下技能包，让 harness 负责发现和加载，而不是把所有领域流程常驻上下文。
parser-debug/
├── SKILL.md # 适用条件、排查顺序、验收要求
├── references/
│ └── edge-cases.md # 空输入、编码、边界条件
└── scripts/
└── reproduce.py # 可重复运行的复现脚本
| 类型 | 提供什么 | 在案例中的角色 |
|---|---|---|
| Tool | 一个可执行动作 | 运行某个测试或读取文件 |
| Skill | 一类任务的操作知识与资源 | 先复现，再定位，再做相关回归 |
| MCP | 能力的发现与调用协议 | 连接提供测试工具的服务 |
| Harness | 实际的调度与执行边界 | 加载流程，检查权限，执行并记录 |
Skill 可以指导如何使用工具，但读取一个技能包不等于获得新的权限，也不等于模型权重更新。执行其中脚本仍应经过现有工具边界。
实验：给 20 个混合任务，比较无 skill、全部 skill 常驻、按需加载。检查触发准确率、漏触发、流程遵循、任务成功率与上下文成本。描述过宽可能让不相关任务误触发；流程过细可能让 Agent 忽略当前环境反馈。
11.7 测试时计算：多尝试必须有可靠选择器
第 3 章的搜索把推理预算花在候选路径上；代码 Agent 也可在隔离工作区尝试多份补丁，再用测试或检查器选择。更多候选只增加发现好解的机会，最终收益还取决于选择器是否能识别好解。
应区分两个数：多次尝试中至少有一次通过的比例，以及系统实际选出的补丁通过独立验收的比例。前者高、后者低，说明瓶颈在选择或验证。公开测试可以作为反馈；评测的隐藏验收器应只在最终评分时使用。
同预算实验：单路最多 24 次调用，对比三路各最多 8 次调用，选择与验证也计入预算。报告实际成功率、候选覆盖、选择错误、墙钟时延和总费用；不要用无限重试后的最好结果对比一次运行。
11.8 Agentic RL：从运行反馈到策略训练
推理时反思修改当前上下文；Agentic RL 用环境反馈更新策略参数。教学抽象是：
模型策略 + Harness + 可重置环境 → 交互轨迹
↓
终态检查 / 奖励 / 信用分配
↓
策略更新 → 独立任务评测
Search-R1 [导读]研究通过强化学习学习多轮搜索与推理；Agent Lightning [导读]研究执行与训练解耦，以及如何将 Agent 轨迹用于训练。Agent Lightning v1.0 [导读]进一步讨论 harness 参与后训练时的接口与稳定性问题：交互循环由 harness 控制，训练侧处理模型请求和响应。具体实验结论需按各论文设置阅读。
| 难点 | 为什么影响训练 | 实验时检查什么 |
|---|---|---|
| 稀疏奖励 | 最后失败无法直接定位哪个动作有问题 | 失败归因与信用分配 |
| Reward hacking | 策略可能利用评分漏洞 | 隐藏验收与独立评测 |
| 环境重置 | 残留文件或状态改变任务难度 | 每条轨迹的初始状态一致 |
| 工具与上下文变化 | 训练时行为在部署时可能不可执行 | 训练/部署 harness 的版本与差异 |
| 数据隔离 | 重复任务可能被记住 | 按任务来源拆分训练、验证和测试 |
入门路线：先做一个可重置、可执行评分的工具环境，保存轨迹并分析失败，再考虑训练。没有稳定的验收器，先修奖励与环境；仅增加训练步数难以说明实际能力提高。
11.9 Computer Use、代码 Agent 与阅读方法
Computer Use 需要把界面观察转成动作，再观察确认状态；代码 Agent 需要搜索、编辑、运行和验证补丁。二者都能作为 harness 的实验场景。GUI 的坐标可能随窗口变化失效；代码测试通过也可能遗漏需求，所以应按任务定义验收。
现有研究入口包括 OSWorld [导读]、SWE-bench [导读]、多 Agent 计算机使用研究 [导读]、CoArena [导读]和 SWE-Bench Pro Verified [导读]。它们讨论的环境、用户反馈与数据质量各不相同，不能直接把分数当作同一种能力。
阅读工程文章或论文时问五个问题：
- 改的是模型、工具、上下文、harness，还是训练数据？
- 环境、动作和权限怎样定义，能否重置与复现？
- 模型、总预算、工具与验收标准是否相同？
- 成功由执行结果还是模型自评判定，失败案例是什么？
- 长任务是否测了中断、恢复和费用，是否存在训练/评测泄漏？
本章交付物：一张 harness 架构图、一份检查点协议、一组中断恢复结果、一张同模型同预算的消融表。能解释某次失败为何发生、改动怎样降低失败，比罗列前沿名词更有说服力。