概览
ETCLOVG 关注模型外面的 Harness：执行环境、工具、上下文、生命周期、可观测、验证和治理。本节换一个角度，看模型本身的能力从哪里来，以及这些能力会怎样改变 Harness 的设计。
这件事并不只是理论问题。Harness 里的许多组件，本质上都在弥补模型当前还不够稳定的地方：模型不擅长分解任务，就在外部加规划；工具调用容易出错，就加路由、校验和重试；失败后不会自己调整，就把反思、搜索和任务日志放进循环；偏好和规范不够稳定，就引入记忆、奖励或训练。
随着模型变强，这些补救手段会重新分工。有些脚手架会被训练进模型，变成默认能力；有些判断反而不能交给模型自觉完成，必须放到验证、观测和治理里。读这一节的重点不是“模型侧能不能替代 Harness”，而是判断：面对今天要部署的模型，某个责任应该交给模型、prompt，还是外部系统。
本节回答什么
本节不是论文清单，也不是训练教程。每篇都围绕一个工程问题：这种模型侧方法会怎样改变 Agent 系统的设计。
| 问题 | 对应页面 | 对 Harness 的影响 |
|---|---|---|
| 显式写出中间步骤，是否能提升多步推理？ | Chain-of-Thought | Prompt 可以承担一部分推理组织；生产系统通常更需要摘要和结果验证，而不是暴露完整推理轨迹。 |
| 推理如何接入外部世界？ | ReAct | thought / action / observation 循环成为工具型 Agent 的基本结构。 |
| 失败经验如何用于下一次尝试？ | Reflexion | 失败轨迹可以转成语言反馈，进入记忆、重试、任务日志和自我改进机制。 |
| 任务是否应该先计划、再执行？ | Plan-and-Solve | 显式规划帮助判断：计划该写在 prompt 里、放进 workflow，还是交给独立 planner。 |
| 单条路径不够时，能否探索多条路径？ | LATS | Agent 运行可以被设计成可评估、可回溯的搜索过程，需要规划、评估器和状态管理配合。 |
| 哪些行为可以通过训练变成默认能力？ | 训练与后训练 | 预训练提供基座能力；SFT、指令微调、工具增强训练、偏好优化和可验证奖励继续塑造模型默认行为。 |
阅读主线
可以按三步来读。
第一步是把一次推理组织好。Chain-of-Thought、Plan-and-Solve 和 ReAct 都不更新模型权重，而是改变一次调用里信息如何排列、任务如何拆开、行动如何根据观察继续推进。它们回答的是：不训练模型，只靠 prompt 和工具循环，可以释放多少能力。
第二步是失败后继续探索。Reflexion 和 LATS 不把一次生成当成终点，而是把轨迹、失败、评估和回溯纳入过程。到了这一层，方法已经很接近 Harness：系统要保存尝试记录，判断哪里失败，选择下一条路径，并决定什么时候停止。
第三步是把能力训练进模型。预训练和后训练会改变模型本身，让一些原本依赖提示词、工具示例、偏好比较或环境反馈的行为变成默认能力。但这不会让 Harness 消失。模型越能自主行动，外部系统越要负责权限边界、可观测性、验证和回滚。
与 Harness 的边界
模型侧方法回答“模型能学会什么”。Harness 回答“这些能力在真实系统里如何被限制、组合、检查和恢复”。
这条边界会随着模型变化而移动。
模型弱的时候，Harness 往往要承担更多脚手架：显式计划、严格流程、外部评估、更多重试。模型变强之后，有些脚手架可以删掉，但风险也会变大，因为模型能采取更多真实动作。此时 Harness 的重心会从“教模型怎么想”转向“限制它能做什么、证明它做对了、出错后能恢复”。
读这一节时，可以反复问四个问题：
- 这个能力，当前模型是否已经稳定具备？
- 如果还不稳定，应该用 prompt、workflow、评估器、记忆还是训练来补？
- 如果未来模型内化了这项能力，现有 Harness 里哪些脚手架可以删掉？
- 删掉脚手架之后，验证、审计和安全边界是否仍然需要保留？
这就是模型侧基础和 ETCLOVG 的关系：前者解释能力从哪里来，后者解释生产系统如何约束这些能力。Agent 系统真正的设计空间，就在两者之间。