这是一篇由原始材料转换而来的阅读页，保留了源文件的主要结构，并补充了可追溯的来源说明与链接。

Harness Engineering：让长任务 Agent 能“接力式”稳定推进

这份笔记基于 Anthropic Engineering 文章《Effective harnesses for long-running agents》（2026-03-08 阅读）： https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

目标：把“长时间运行（跨多个 context window / 多次会话）”的 agent 工作流做成工程化的 harness，让每一次会话都像“换班工程师”一样： - 上来先快速搞清楚当前状态 - 只做一小步、可验证的增量 - 结束时留下 可复盘、可恢复、可继续 的工件（artifacts）

1. 长任务 Agent 的核心问题

在多轮会话中，模型每次都会“失忆”。如果没有外部工件，典型会出现两类失败模式：

1) 一次性做太多（one-shot） - 试图在一次会话内完成整个系统 - context 用尽时项目停在“半成品 + 未记录”的状态 - 下一次会话只能靠猜，反复修基础设施，浪费时间

2) 过早宣布胜利（declare victory） - 看到仓库里已经有一些进展 - 没有严格的“完成定义”，就以为做完了

因此要把“记忆”外置，把“完成定义”结构化。

2. 两阶段 harness：Initializer + Coding（换班机制）

文章给了一个非常实用的结构：

2.1 Initializer（首次会话）

职责不是写功能，而是 搭环境与规则，生成后续会话必读工件： - init.sh：一键启动/健康检查/冒烟测试脚本（让后续会话不用猜怎么跑） - progress.*：进度日志（换班交接本） - feature_list.json：功能清单（结构化验收标准，默认全 false） - 初始化 git：把“环境骨架”作为第一笔可回滚的基线提交

2.2 Coding（后续每次会话）

每次只做 一个 可验证的增量： - 启动项目并做冒烟测试，先确保“当前是好的” - 从 feature_list.json 选择一个未通过的功能 - 实现 + 测试（最好包含端到端测试） - 只在验证后把 passes=false -> true - 写 progress 交接记录 - git commit 形成可恢复的里程碑

3. 三类关键工件（Artifacts）

3.1 Feature list（结构化验收）

用 JSON（而不是 Markdown）是一个工程细节：模型更不容易“顺手改写需求文本”。 推荐字段： - category - description - steps（端到端操作步骤） - passes（唯一允许修改的字段）

3.2 Progress log（交接本）

记录应当“可执行”，至少包含： - 本次实现了什么（指向 commit） - 运行过哪些命令（可复现） - 当前风险/已知问题 - 下一步建议（把决策与理由写出来）

3.3 init.sh（可重复的启动/验证入口）

每次会话先跑它： - 启动服务 - 做最小端到端验证 - 失败就先修复到绿色再做新功能

4. 你可以怎么用这套结构

本目录提供一个可直接复制到任意项目仓库的模板（见 AGENTS.md 和 templates/）。

建议用法： 1) 在你的 repo 根目录复制本目录的模板文件 2) 让 Initializer Agent 生成适配你项目的 init.sh / feature_list.json / progress 3) 后续每次会话严格按 AGENTS.md 的流程走

5. 目录结构

• AGENTS.md：给 agent（以及人类）看的“换班作业指导书”，包含 Codex CLI 用法
• templates/feature_list.json：功能清单模板
• templates/progress.md：进度日志模板
• templates/init.sh：init.sh 模板（需按项目改）