Harness 与长程任务：让 Agent 在数小时后仍然知道自己在做什么

1. Harness 的定义

Harness 是模型之外，让 Agent 稳定完成任务的工程外壳。它不是一个 Prompt，也不是一个框架品牌，而是一组能把不可靠模型放进可控环境的机制：任务调度、上下文控制、行动环境、Tool 安全、Loop 协作、验证评测、自进化和长程执行。

第一性原理是：模型负责提出候选行动，Harness 负责管理状态、约束副作用和证明结果。 模型越强，Harness 越应该把能力转化为可重复的行为，而不是减少工程控制。

长程任务不是短任务重复很多次。它会出现累积效应：

所以长程 Agent 的核心对象不是“更长的 Prompt”，而是目标版本、检查点、证据图和恢复包。

任务开始时建立 Contract：目标、范围、输入、禁止事项、验收条件、预算、截止时间和允许的外部副作用。用户后续追加要求时，不要简单追加聊天消息，而要产生新版本，标记哪些约束仍有效、哪些被替换、哪些需要重新验证。

goal_version = 3
invariants = [不能修改 API、必须通过测试]
completed = [分析完成、补丁已生成]
pending = [运行回归、更新文档]
evidence = [diff-17, test-run-42]

每次重规划都要检查是否违反旧约束。这样可以区分合理的目标更新和无意的目标漂移。

检查点不应只保存聊天记录，而应保存：任务合同、目标版本、已验证状态、未完成动作、工具幂等键、权限、预算、产物版本、Memory 引用、压缩摘要和最后事件序号。

模型切换时传递的是恢复包，不是原始上下文。恢复包要回答：现在目标是什么，哪些结论可信，哪些动作已提交，下一步允许做什么，为什么之前失败，如何验证接管后的结果。

恢复流程可以是：读取最新检查点 → 校验环境版本 → 查询外部副作用 → 重建 Context → 运行一致性检查 → 从安全边界继续。若检查点与工作区不一致，应停止并让用户选择回滚、重新扫描或人工合并。

验证器不只检查最终文本。Coding Agent 至少需要语法检查、类型检查、单元测试、集成测试、diff 审查和任务合同检查；Research Agent 还需要来源覆盖、证据一致性和引用可追溯。

完成判定应由多个信号组成：

completed = contract_satisfied
         && required_tests_pass
         && no_unresolved_high_risk_action
         && evidence_is_sufficient

模型说“完成”只是一个候选信号。验证失败时，根据失败类型选择修复、回滚、重新规划或请求人工，不要让模型无限循环。

上下文压缩按时机分为 PreTurn、MidTurn、PostTurn，按强度分为 L1、L2、L3。压缩前先冻结不可丢失字段，压缩后做契约回归。

高质量摘要不是“之前做了很多事”，而是结构化记录：目标版本、已验证事实、决策及理由、失败及根因、外部副作用、待办、证据引用和不确定性。摘要若无法支持下一步行动，就不是有效压缩。

Agent 成本是循环成本，不只是一次模型 Token。预算要拆为模型调用、工具调用、Sandbox 时间、网络请求、人工等待和存储。任务调度器需要根据优先级、deadline、租户配额和预计剩余工作分配资源。

当预算接近上限时，系统应优先保存检查点、完成低成本验证并给出可恢复的部分结果，而不是继续冒险执行。降级可以是切换模型、减少并行、缩小搜索范围或请求用户决策，但每种降级都要写入轨迹。

不要只看成功率。建议同时观察一次任务完成率、验证通过率、恢复成功率、重复副作用率、目标漂移率、平均人工介入次数、每个成功任务的 Token/工具/时间成本，以及失败归因分布。

长程评测应把任务随机中断、工具超时、上下文压缩、模型切换、Sandbox 重启和用户追加要求注入到轨迹中，检查系统能否从任何安全检查点恢复。

实现一个“自动修复并运行测试”的长程 Agent。先让它在第 3 步崩溃，再恢复；然后在第 4 步切换模型；最后让用户追加“不能改公共接口”。如果系统能够交付带 diff、测试结果、失败记录和恢复证据的结果，才算完成了长程任务练习。