{"owner":"deusyu","repo":"harness-engineering","hasSkills":true,"totalSkillsCount":14,"totalTokensCount":56404,"categories":["root-instruction","anthropic-skill","generic"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","prompts/AGENTS.md","practice/AGENTS.md","concepts/AGENTS.md","feedback/AGENTS.md",".claude/skills/curate-research/SKILL.md","prompts/deep-research-tracker.md","tools/00-overview.md","references/AGENTS.md","tools/AGENTS.md","thinking/AGENTS.md","references/articles.md","works/AGENTS.md","tools/harnesses/ralph-orchestrator.md"],"skills":{"AGENTS.md":"# Harness Engineering 学习档案\n\n> 记录我学习「Harness Engineering」的完整过程：从概念理解到独立实践。\n>\n> 来源：[OpenAI — Harness Engineering: Harnessing Codex in an Agent-First World](https://openai.com/zh-Hans-CN/index/harness-engineering/)\n\n## 仓库结构\n\n| 目录 | 内容 | 说明 |\n|------|------|------|\n| `concepts/` | 概念笔记 | 原文核心概念的拆解与整理 |\n| `thinking/` | 独立思考 | 自己的理解、质疑、延伸思考 |\n| `practice/` | 动手实践 | 小项目实验，验证文章中的方法论 |\n| `feedback/` | 反馈记录 | 实践中的踩坑、修正、迭代心得 |\n| `works/` | 作品输出 | 可展示的成果（文章、工具、模板等） |\n| `tools/` | 工具具像化 | 降低 6 维复杂度的杠杆库（带主张，不是 awesome-list） |\n| `prompts/` | 提示词积累 | 学习过程中验证有效的提示词 |\n| `references/` | 外部资源 | 相关文章、仓库、工具的索引 |\n\n## 学习路线（进度）\n\n- [x] Phase 1：理解核心概念（concepts/，8 篇）\n- [x] Phase 2：形成自己的观点（thinking/，11 篇，持续中）\n- [x] Phase 3：选一个小项目实践（practice/，1 个 Ralph Demo）\n- [x] Phase 4：记录反馈迭代（feedback/，1 篇，持续中）\n- [x] Phase 5：输出可展示的作品（works/，40 篇翻译 + 1 篇原创 + 2 篇外部中文收录）\n\n> 进度详情以人类向 README.md 的\"学习路线\"段为准；本节是给智能体的快照。\n\n## 导航\n\n每个子目录都有自己的 AGENTS.md，说明该目录的用途、内容组织方式和写作约定。\n从任何一个目录开始，都能找到下一步该看什么。\n\n## 机械化检查\n\n`scripts/check-consistency.sh` 守护\"漂移\"问题：\n\n- **C1** — `references/articles.md` 编号 1..N 连续\n- **C2** — N 与下游 4 处声明同步（README badge × 2、`prompts/deep-research-tracker.md` 头部、`references/AGENTS.md` 概览）。文件含独立行 `` 时豁免\n- **C3** — `concepts/`、`thinking/`、`feedback/` 的 `*.md` 实际数与 README 中\"X 篇\"声明一致\n- **C4** — `works/*-translation.md` 文件数 ≡ 翻译计数所有声明（badges、`
` 摘要、Phase 5 注释、本文件 Phase 5 快照、READMEs 表格行数）\n- **C5** — README 结构树中 `concepts/` 子树的 item 行数 ≡ `concepts/*.md` 文件数（防止\"计数对了但树漏了\"）\n- **C6** — `references/articles.md` 末尾\"不计入 N 篇\"中的 N ≡ C1 权威值\n- **C7** — 三脉络 per-track 计数（脉络一/二/三）在 4 处下游声明保持一致：READMEs 资料库表、`references/AGENTS.md` 三脉络小标题、`prompts/deep-research-tracker.md` 三脉络明细\n- **C8** — 翻译流水线本地守卫：`translate/<...>/sources//source-full.md` 存在时，对应 `01-analysis.md` 不得再声称\"仅摘要页 / 建议补抓全文\"。`translate/` 已 gitignore，CI 与干净 clone 自动 SKIP，仅本地有过程稿时触发\n- **C9** — `concepts/` / `thinking/` / `feedback/` 正文不得裸写文库计数（\"N 篇文章 / N 篇翻译 / N 大概念\"）；历史性提法须带\"写作时点 / 当时 / 此前 / 首批 / 首轮 / 截至 / 快照\"限定词，否则去数字改链 `references/articles.md`\n- **C10** — 图片保真（纯本地、零网络）：每篇 `works/*-translation.md` 的 frontmatter 必须声明 `sourceFigureCount`（缺失即 FAIL；`null` = 原文不可得、未审计 → SKIP；数字 N → 正文嵌图数须 ≥ N），且所有本地嵌图路径（`imgs/...`）必须在磁盘上存在\n- **C11** — markdown 表格形状：README ×2、`references/AGENTS.md`、`references/articles.md`、`works/AGENTS.md` 里每一行表格的单元格数须与表头一致\n- **C12** — 条目字段完整性：`references/articles.md` 每个 `### N.` 编号条目必须带 **作者：** 与 **日期：** 字段\n- **C13** — 零插图声明须留痕：C10 只能证伪\"多报\"（嵌图数 < 声明数才 FAIL），因此 `sourceFigureCount: 0` 在本地**永远无法被证伪**——不管你有没有真去核对原文，它都是绿的。2026-07-27 就是这个洞放行了一个假 0（原文实有 4 张配图）。C10 刻意零网络、无法回查原文，所以改为要求留痕：**声明 0 的译文必须同时带 `sourceFigureAudit` 字段，值里要有 `YYYY-MM-DD` 核对日期**，写清怎么核对的、结论是什么。`null` 仍然 SKIP——它本来就自陈未审计\n- **C14** — 文档站防漂移：VitePress 站点（部署到 harness.dyu.sh）的侧边栏与首页统计一律由 `.vitepress/sidebar.mjs` 在构建时从文件系统生成，不手写。三条不变量：站点源码（`index.md`、`.vitepress/`）不得出现裸计数（\"N 篇\"），数字只能来自 `computeStats()`；每个一等内容文件必须在生成的侧边栏中恰好出现一次；仓库内禁止任何 symlink——Vite 会解引用 `public/` 下的软链、图片管线会读取链接目标，一条软链即可把仓库外文件带进公开产物（后两条经 `node .vitepress/sidebar.mjs --verify` 执行）。构建产物侧另有 `scripts/verify-dist.mjs` 断言页面与 `.md` 副本一一对应、副本链接可达、dist 无 symlink。站点脚手架不存在时 SKIP；node 不可用时 verify 半边 SKIP、裸计数 grep 照常执行\n\n执行：`bash scripts/check-consistency.sh`（仓库根目录）\n启用 pre-commit 阻断：`git config core.hooksPath .githooks`\n\n**CI 兜底**：`.github/workflows/consistency.yml` 在每次 push / PR 时跑同一脚本（不做路径过滤，保证必需检查总能上报）。job 显示名固定为 `consistency / check`——分支保护按 check run 名匹配必需检查，改名会让所有 PR 重新被 \"Expected\" 卡住。\n本地 hook 是开发反馈，CI 是合并门——两层独立，本地未启用 hook 不会绕过检查。\n","prompts/AGENTS.md":"# prompts/ — 提示词积累\n\n学习过程中验证有效的提示词，按场景或工作流沉淀。**只收录亲测有效的，不收录未验证的。**\n\n## 文件形态（两种合法形式）\n\n### 形式 A：单条 Prompt（按场景命名）\n\n- 文件名：`{场景}.md`，如 `code-generation.md`、`code-review.md`\n- 必备字段：用途、提示词正文\n- 建议字段：效果评价（好/中/差）、改进记录、适用模型 / 不适用场景\n\n### 形式 B：Prompt 工作流（按工具链命名）\n\n- 文件名：`{工作流名称}.md`，如 `deep-research-tracker.md`\n- 必备字段：工作流目标、各步 Prompt 正文（A/B/C…）、链路图\n- 适合多模型 / 多步骤协作的场景（例如 ChatGPT Deep Research → Claude 深度分析 → 人工确认）\n\n## 场景分类参考\n\n| 场景 | 说明 |\n|------|------|\n| 项目初始化 | 让智能体生成仓库骨架、AGENTS.md、CI 配置 |\n| 代码生成 | 在架构约束下生成业务代码 |\n| 代码审查 | 智能体审查智能体生成的代码 |\n| 重构清理 | 熵管理 / 垃圾回收 |\n| 文档维护 | doc-gardening 智能体的提示词 |\n| 情报追踪 | 定期发现领域内新内容（见 deep-research-tracker.md） |\n\n## 已有内容\n\n| 文件 | 形态 | 用途 |\n|------|------|------|\n| [deep-research-tracker.md](deep-research-tracker.md) | 工作流 | 每 1–2 周追踪 Harness Engineering / AI 编程领域新内容 |\n\n## 下一步\n\n用了某条 Prompt 之后，把效果（好/中/差/翻车）记到 [feedback/](../feedback/)；\n积累到一定量再回到本目录补\"效果评价 / 改进记录\"。\n","practice/AGENTS.md":"# practice/ — 动手实践\n\n选一个小项目，用 Harness Engineering 的方法论从零构建，验证原文中的经验。\n\n## 文件约定\n\n- 每个实验一个子目录，如 `practice/01-cli-tool/`\n- 每个实验包含：README.md（目标与方法）、AGENTS.md（给智能体的指导）、代码\n- 关键：人类只写提示词和约束，代码全部由智能体生成\n\n## 已有实验\n\n| 实验 | 验证的概念 | 结果 |\n|------|-----------|------|\n| [01-ralph-demo/](01-ralph-demo/) — Ralph Orchestrator 编排循环 | 帽子系统、背压门控、迭代循环、持久记忆 | 4 轮迭代完成 CLI word counter（321s / $0.31），7 项测试全绿；产物已归档可复验 |\n\n## 实验建议\n\n| 实验 | 验证的概念 | 复杂度 |\n|------|-----------|--------|\n| 用 Claude Code 生成一个 CLI 工具 | 仓库即记录系统 + AGENTS.md 设计 | ⭐ |\n| 为生成的代码写自定义 linter | 机械化执行 | ⭐⭐ |\n| 让智能体自己重构自己写的代码 | 熵管理与垃圾回收 | ⭐⭐⭐ |\n\n## 下一步\n\n实践中踩坑了？去 [feedback/](../feedback/) 记录下来。\n","concepts/AGENTS.md":"# concepts/ — 概念笔记\n\n原文六大核心概念的拆解与整理 + 后续阅读引出的延伸概念。每个概念一个文件，按阅读顺序编号。\n\n## 文件约定\n\n- 文件名：`{编号}-{英文短名}.md`，如 `01-repo-as-source-of-truth.md`\n- `00-overview.md` 是总览，先读这个\n- **文件名编号 ≠ 概念编号**：文件名编号是阅读顺序；\"概念 N\"的编号以 `00-overview.md` / README 的六大核心概念清单为准（两处一致）\n\n## 概念编号 ↔ 文件对照表（引用时以此为准）\n\n| 概念编号 | 概念 | 文件 |\n|---------|------|------|\n| 概念 1 | 仓库即记录系统 | [01-repo-as-source-of-truth.md](01-repo-as-source-of-truth.md) |\n| 概念 2 | 地图而非手册 | [00-overview.md §2](00-overview.md#map-not-manual)（无独立文件） |\n| 概念 3 | 机械化执行 | [02-mechanical-enforcement.md](02-mechanical-enforcement.md) |\n| 概念 4 | 智能体可读性 | [04-agent-readability.md](04-agent-readability.md) |\n| 概念 5 | 吞吐量改变合并理念 | [05-throughput-changes-merge.md](05-throughput-changes-merge.md) |\n| 概念 6 | 熵管理 = 垃圾回收 | [03-entropy-and-garbage-collection.md](03-entropy-and-garbage-collection.md) |\n| 总纲 | 人类掌舵，智能体执行 | [00-overview.md 总纲节](00-overview.md)（不占概念编号） |\n| 延伸 | Harness 的精确定义 | [06-harness-definition.md](06-harness-definition.md)（不占概念编号） |\n| 延伸 | 约束即产品（Spec as Product） | [07-spec-as-product.md](07-spec-as-product.md)（不占概念编号） |\n\n**引用约定**：跨文件引用概念时，写概念名并链接到具体文件（如 `[机械化执行](../concepts/02-mechanical-enforcement.md)`）；如需带编号，编号必须取自本表，不要裸写\"概念 N\"让读者猜编号体系。\n\n### 结构（建议，非强制）\n\n早期文件（01–03）来自 OpenAI 单一原文，结构倾向于：核心要点 → 关键实践 / 方案。\n后期文件（04–06）已演化为多源综合（OpenAI + LangChain + HumanLayer + Fowler），允许加入：\n\n- \"来自其他文章的补充\" / \"来自 X 的补充\"：跨源对照\n- \"关键洞察\" / \"类比\" / \"哲学\"：作者层加工\n- 06 是定义综合型，结构（定义 → 组件清单 → 跨源对照）与前 5 篇不同，属于合法变体\n\n约束只有两条：\n1. 第一段说清楚这个概念**是什么**（无论叫\"原文要点\"还是\"核心思想\"还是\"问题\"）\n2. 跨源内容必须**标注来源**（哪篇文章、哪个作者）\n\n## 已有内容\n\n| 文件 | 概念 | 来源 |\n|------|------|------|\n| [00-overview.md](00-overview.md) | 六大核心概念总览 | OpenAI 原文 |\n| [01-repo-as-source-of-truth.md](01-repo-as-source-of-truth.md) | 仓库即记录系统 | OpenAI 原文 |\n| [02-mechanical-enforcement.md](02-mechanical-enforcement.md) | 机械化执行 | OpenAI 原文 |\n| [03-entropy-and-garbage-collection.md](03-entropy-and-garbage-collection.md) | 熵管理与垃圾回收 | OpenAI 原文 |\n| [04-agent-readability.md](04-agent-readability.md) | 智能体可读性 | OpenAI + LangChain + HumanLayer + Fowler |\n| [05-throughput-changes-merge.md](05-throughput-changes-merge.md) | 吞吐量改变合并理念 | OpenAI + HumanLayer + LangChain + Fowler |\n| [06-harness-definition.md](06-harness-definition.md) | Harness 的精确定义与组件清单 | LangChain + HumanLayer + Fowler |\n| [07-spec-as-product.md](07-spec-as-product.md) | 约束即产品（Spec as Product）| OpenAI Symphony + Fowler + HumanLayer + Meta-Harness |\n\n## 下一步\n\n读完概念后，去 [thinking/](../thinking/) 写你自己的理解和质疑。\n","feedback/AGENTS.md":"# feedback/ — 反馈记录\n\n实践中的踩坑、修正、迭代心得。把失败变成可复用的经验。\n\n## 文件约定\n\n- 文件名：`{日期}-{简述}.md`，如 `2026-03-24-agents-md-too-long.md`\n- 结构：问题描述 → 原因分析 → 解决方案 → 收获\n- 如果某个反馈导致了 prompts/ 或 concepts/ 的更新，交叉链接\n\n## 下一步\n\n反馈积累够了，去 [works/](../works/) 把经验提炼成可展示的作品。\n",".claude/skills/curate-research/SKILL.md":"---\nname: curate-research\ndescription: 把一批 Harness Engineering 调研候选（文章/论文/工具的 URL）走完「抓取→翻译→评审→收录→清理」流水线，整合进本仓库 works/ 与 references/articles.md，并保持 C1–C13 一致性检查全绿。当用户说\"处理这批调研候选 / 收录这些链接 / 整理 translate / 把这几篇翻译收进来\"时使用。这是仓库给自己用的策展 harness。\n---\n\n# curate-research —— 仓库自我策展 harness\n\n> 一个讲 Harness Engineering 的仓库，用一个 harness 来策展自己。本 skill 把外部调研候选可控地整合进 tracked 档案。\n>\n> **核心约束：评审全自动；收录是人类闸门，必须停下来和用户来回讨论后才动 `works/` 与 `articles.md`。**\n\n## 何时用\n\n- 用户给出一批候选 URL（文章 / 论文 / 工具 / 项目），希望整合进仓库\n- 用户说「处理 / 收录 / 整理」`translate/` 暂存区的翻译\n- 已有 `translate//works-ready/` 候选译文，要决定去向\n\n## 输入与产物路径\n\n暂存区（gitignored，本地过程区）：`translate//`\n- `sources//source.md`（原文快照；论文额外抓 `source-full.md`）\n- `translations//{01-analysis,02-prompt,translation}.md`（过程三件套）\n- `works-ready/-translation.md`（发布候选）+ `works-ready/README.md`（状态表，本批权威）\n\n正式档案（tracked）：`works/-translation.md` + `references/articles.md` 条目。\n\n## 流水线 6 阶段\n\n```\n①抓取 ──②翻译 ──③评审[全自动] ──🚧人类闸门🚧──④收录 ──⑤校验 ──⑥清理\n```\n\n### ① 抓取\n用 `baoyu-url-to-markdown` 把每个 URL 存到 `sources//source.md`。**论文/长文必须额外抓 HTML 全文到 `source-full.md`**（否则只有摘要页，C8 会拦谎报）。\n\n### ② 翻译\n按 baoyu-translate 配置生成 `translations//` 三件套 → `works-ready/-translation.md`。`01-analysis.md` 要含收录建议；`source-full.md` 存在时，分析稿不得声称「仅摘要页」。\n\n### ③ 评审（全自动并行扇出）\n对每篇候选派一个评审 agent（一批 3–4 篇，并行多个 agent）。统一打分维度，吐结构化定性。**标准评审 prompt 模板：**\n\n> 你是 Harness Engineering 中文知识库的内容评审。仓库主题：人类设计约束与反馈回路、AI agent 写代码。\n> 读 `sources//source.md`(+`source-full.md`)、`works-ready/-translation.md`、`translations//01-analysis.md`，逐篇回答：\n> - **原文价值**：原创洞察密度 / 长文实质 vs 产品页·发布稿·摘要。高/中/低\n> - **翻译质量**：完整逐译 / 压缩摘要 / 首轮粗稿；通顺度、术语到位度。精品/合格/需返工\n> - **与仓库契合度**：补薄弱环节还是重复\n> - **一句话定性 + 建议去向**：works/ 正式收录 / articles.md 观察项一行 / tools/ / 暂不收录\n> 基于实际内容，紧凑中文，结构化输出即为最终产出。\n\n汇总成一张「候选 × 定性 × 去向」表。\n\n### 🚧 人类闸门（不可跳过）\n把评审表交给用户，**来回讨论收录决策**。精品 vs 边角的边界判断、是否返工、哪些合并成专题——都由人定。**未经用户确认，不得进入 ④。**\n\n### ④ 收录（按减熵分流规则）\n- **实质原创长文 / 论文 → `works/`**：`cp` 到 `works/-translation.md`，在 `articles.md` 加一个 `### N.` 编号条目（脉络一末尾，旧编号顺移），并**同步全部计数缓存**（见下）。\n- **边角材料**（产品页 / README / 发布稿 / 短 bliki）**→ articles.md「观察项 / 候选材料（不计入文章数）」表一行**，链上游 URL，不做编号条目（文章数不变）。\n- **工具类 → 只在用户实际用过后才进 `tools/`**；未实测前在观察项表标 🔵「待实测后入 tools/」。\n- **需返工的长文**：先润色（事实核查加译者注 / 术语统一）再进 `works/`。\n\n**入库前 checklist（每篇 works/ 候选必过，再进 ⑤）：**\n- [ ] frontmatter 声明 `sourceFigureCount` 并与原文实际图数核对（null = 原文不可得、未审计）；原文插图下载入 `works/imgs//` 本地嵌入——C10 校验嵌图数 ≥ 声明数、本地路径文件存在\n- [ ] **数图要抓原文 HTML 数，不能只看渲染出来的正文。** 2026-07-27 的教训：一篇 claude.com 译文声明 `sourceFigureCount: 0`，而原文 HTML 里有 4 个 `
`——抓取工具吐出的 markdown 把它们丢了，人只看那份 markdown 就会以为没有图。可用 `curl | grep -c '-translation.md`（works/ 是权威源）。\n- 删已收录 slug 的 `sources//` + `translations//`（过程稿，works/ 已留最终版）。\n- **保留**：观察项 slug 的全部译文（articles.md 标明「留作阅读辅助」）+ 状态 README。\n- 更新 `works-ready/README.md` 状态表。`translate/` 是 gitignored，清理仅本地。\n\n## 计数同步清单（④ 的硬要求）\n\n`references/articles.md` 是文章数与编号的**唯一权威源**。每加一个 `### N.` 条目，必须同次更新所有下游缓存，否则 `check-consistency.sh` 报错：\n- README.md / README.en.md：`articles-N` badge、`translations-N` badge、目录树、脉络表（脉络一计数）、翻译 `
` 摘要数、翻译表格行、Phase 5 提及\n- references/AGENTS.md：概览「N 篇文章」、脉络一小标题计数、文章表加行\n- prompts/deep-research-tracker.md：「核心文章 N 篇」、脉络一计数、去重清单加行\n- AGENTS.md：Phase 5 快照「N 篇翻译」\n- works/AGENTS.md：翻译表加行\n- articles.md 自身：header「N 篇（脉络一 …）」、两处「不计入 N 篇」\n- **观察项一行不触发以上**（不计入 N，无 `### N.` 编号）——这是减熵分流的关键收益。\n\n## 相关\n- 减熵分流约定：即上文「④ 收录」的分流规则——实质长文进 `works/` 编号正文；边角材料只进观察项表（不计数、不触发计数同步）；工具未实测不进 `tools/`。原则：每条新收录都要问\"它增加的检索价值是否大于它增加的维护熵\"\n- C8 lint：`source-full.md` 存在时禁止 analysis 谎报摘要页（`scripts/check-consistency.sh`）\n- C9 lint：`concepts/` / `thinking/` / `feedback/` 正文禁止裸写文库计数（历史提法须带\"写作时点/当时/此前/首批/首轮/截至/快照\"限定词）\n- C10/C11/C12 lint：图片保真（`sourceFigureCount` vs 正文嵌图数 + 本地嵌图路径存在）/ markdown 表格列数与表头一致 / articles.md 编号条目必含 **作者：**/**日期：** 字段（同上脚本）\n- C13 lint：`sourceFigureCount: 0` 必须配 `sourceFigureAudit`（含核对日期）。这条是补 C10 的结构性盲区——C10 的判据是\"嵌图数 < 声明数才 FAIL\"，所以 0 永远为真，无论你有没有真去数过原文。机械检查只能证伪\"多报\"，\"零报\"只能靠留痕让人复核\n- 历史首批实例：articles.md #19–27（2026-06 收录的 9 篇）+ 末尾观察项表 14 行\n","prompts/deep-research-tracker.md":"# 深度研究追踪 Prompt\n\n> 用途：定期（每 1-2 周）运行，发现 harness engineering / AI 编程领域的高价值新内容\n> 推荐工具：ChatGPT Deep Research（广度搜索）→ Claude（深度分析 + 项目关联）\n\n---\n\n## Prompt A：ChatGPT Deep Research — 广度发现\n\n```\n你是一个技术情报分析师。请对以下领域进行深度网络搜索，找出过去 2 周内（{START_DATE} 至 {END_DATE}）发布的高价值内容。\n\n### 搜索领域\n\n核心主题：\n1. Harness Engineering — AI 编码智能体的约束、引导、反馈系统设计\n2. Context Engineering — 上下文窗口管理、compaction、渐进式披露\n3. AI Coding Agents — 编码智能体的架构、编排、评估\n4. Agent Infrastructure — 沙箱、会话管理、多智能体协作\n5. AI-assisted Software Engineering — AI 辅助开发的效率、流程、组织影响\n\n相关关键词（中英文）：\n- harness engineering, agent harness, coding agent, AI coding\n- context engineering, context window, compaction, progressive disclosure\n- AGENTS.md, CLAUDE.md, agent readability, agent-first\n- managed agents, meta-harness, multi-agent orchestration\n- AI code review, mutation testing, structural testing, fitness functions\n- vibe coding, AI-native development, agentic workflow\n- 智能体工程, AI 编程, 上下文工程, 护栏工程\n\n### 搜索范围\n\n必须覆盖的信源（按优先级）：\n\n**Tier 1 — 高权重（模型厂商 + 顶级技术博客）：**\n- Anthropic Engineering Blog (anthropic.com/engineering)\n- OpenAI Blog (openai.com)\n- Google DeepMind / Google AI Blog\n- Martin Fowler (martinfowler.com)\n- Mitchell Hashimoto (mitchellh.com)\n- LangChain Blog (blog.langchain.com)\n- Simon Willison (simonwillison.net)\n\n**Tier 2 — 中权重（社区 + 行业）：**\n- Hacker News (前 100 讨论)\n- GitHub Trending (相关仓库)\n- X/Twitter 技术社区 (#harness-engineering, #ai-coding, #context-engineering)\n- Dev.to, Medium 技术专栏\n- HumanLayer, Cursor, Windsurf, Codex 相关博客\n- 中文社区：少数派、掘金、知乎专栏\n\n**Tier 3 — 低权重但可能有惊喜：**\n- arXiv (cs.SE, cs.AI 交叉)\n- 个人技术博客\n- YouTube 技术频道\n- Reddit (r/LocalLLaMA, r/ChatGPT, r/programming)\n\n### 我们已知的内容（用于去重和关联）\n\n> **本节是 Prompt 的去重权威**——给外部搜索器（ChatGPT Deep Research 等）使用。\n> 它必须自包含，因为搜索器无法访问 `references/articles.md`。\n>\n> **维护纪律：** 当 `references/articles.md` 新增/删除条目时，**同一次提交中**必须同步更新本节。两份内容的口径（脉络划分、篇数、产品/项目清单）应保持完全一致。\n> 本节最近一次同步：2026-08-27（与 `articles.md` 当前内容对齐：79 篇文章 + 1 项已跟踪产品）。\n\n**核心文章 79 篇，分布于三条脉络：**\n\n- **脉络一 — AI 时代 Harness Engineering（75 篇）：**\n - OpenAI \"Harness engineering\"（原点，2026-02-11）/ \"An open-source spec for Codex orchestration: Symphony\"（2026-04-27，任务跟踪器作为控制平面）\n - Fowler/Böckeler \"Harness engineering for coding agent users\"（2026-04-02）+ 前传备忘录（2026-02-17）\n - LangChain \"The Anatomy of an Agent Harness\"（2026-03）/ \"Continual Learning for AI Agents\"（2026-04-05）/ \"Agent Evaluation Readiness Checklist\"\n - Anthropic \"Harness design for long-running application development\"（2026-03-24）\n - Anthropic / Lance Martin \"Harnessing Claude's intelligence\"（2026-04-02，三大模式与性能数据）\n - Anthropic \"Scaling Managed Agents\"（2026-02-04，meta-harness 与基础设施解耦）\n - HumanLayer \"Skill Issue\"（2026-03，六杠杆与避坑）\n - Fowler / Rahul Garg \"Encoding team standards\"（2026-03）/ \"Feedback flywheel\"（2026-03）\n - Meta-Harness 论文（自动化 Harness 优化）\n - GitHub / Tyler McGoffin \"Agent-Driven Development\"（实战）\n - \"Inside the Scaffold\" 论文（编码智能体脚手架的源代码级分类法）\n - Lalit Maganti \"渴望八年，用 AI 三个月造出来\"\n - Vikash Rungta \"Claude Code Architecture (Reverse Engineered)\"（2025-11-01，Claude Code 运行外壳、TAOR 循环、工具原语、权限与上下文管理的外部逆向分析）\n - 马东锡 NLP \"Harness 系列文章之 7：关于 subagent\"（2026-06-22，subagent = tool call 入口 + child runtime，区分 session/context/subagent，与 Claude Code 逆向互证）\n - Fowler/Böckeler \"Maintainability sensors for coding agents\"（2026-05-20，计算性 vs 推理性传感器谱系 + 失败案例 + AI 评审作为垃圾回收）\n - Fowler \"Structured-Prompt-Driven Development (SPDD)\"（2026-04-28，REASONS Canvas 七维 + prompt 即一等交付物 + 双向闭环）\n - LangChain / Harrison Chase \"The Agent Development Lifecycle (ADLC)\"（2026-05-09，framework/runtime/harness 三分类的生命周期）\n - LangChain / Hunter Lovell \"Interpreters in Deep Agents\"（2026-05-20，interpreter 是第三类上下文表面 + 35% token 节省）\n - Anthropic 工程团队 \"An update on recent Claude Code quality reports\"（2026-04-23，三起独立变更叠加成质量退化的第一手复盘）\n - Agentic Harness Engineering 论文（arXiv 2604.25850，复旦/北大/奇绩，可观测性驱动的 Harness 自动演化 + 可证伪契约）\n - Overeager Coding Agents 论文（arXiv 2605.18583，越界动作测量 + 提示声明授权反而降低边界推断）\n - Chris Parsons \"How I Use AI to Code\"（2026-05，四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈；含译者注，2026 数据未独立核实）\n - LangChain / Palash Shah \"How we built LangSmith Engine\"（2026-05-19，用智能体改进智能体，trace→轨迹骨架 + screener/investigator 两阶段闭环）\n - Geoffrey Huntley \"Ralph Wiggum as a software engineer\"（2025-07）+ \"everything is a ralph loop\"（2026-01-17，bash 循环 + 干净上下文 + 背压 + 单体反多智能体论）\n - Mitchell Hashimoto \"My AI Adoption Journey\"（2026-02-05，六步采纳路线 + \"harness engineering\" 命名出处）\n - Claude Code 源码泄漏事件（2026-03-31，v2.1.88 npm source map 泄 512K 行 TypeScript；聚合分析 pankaj28843/understanding-claude-code：QueryEngine ~46K 行、60+ 门控工具、KAIROS/AutoDream/Undercover Mode）\n - Addy Osmani \"Agent Harness Engineering\"（2026-04-19，O'Reilly 转载；学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS）\n - Thoughtworks / Böckeler & Ford \"Exploring AI coding sensors\"（2026-05-13，有/无传感器对照实验 + harness 模板展望）\n - HarnessAudit 论文（arXiv 2605.14271，harness 安全审计：中途轨迹违规是输出级评估盲区，210 任务基准）\n - Harness-Bench 论文（arXiv 2605.27922，配置级 harness 效应：106 任务 / 5194 轨迹 + 执行对齐失败）\n - \"How good is your harness?\"（CTB@ICML 2026，Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应且异质）\n - Anthropic/Claude \"A harness for every task: dynamic workflows in Claude Code\"（2026-06-02，模型现场写自己的编排 harness + 对抗验证 + ultracode 触发）\n - 马东锡 NLP \"Harness 才是产品\"（2026-06，Model 在 loop 里 harness 拥有 loop + 六组件 + 症状→组件 debug 表）\n - Position 论文 \"Coding Benchmarks Are Misaligned with Agentic SE\"（arXiv 2606.17799，基准折叠 model/harness/环境的三症状）\n - OpenAI \"Unrolling the Codex agent loop\"（2026-01-23，Codex harness 解剖·上：prompt 构造 / 二次方与 prompt caching / compaction 端点化）\n - OpenAI \"Unlocking the Codex harness\"（2026-02-04，Codex harness 解剖·下：App Server 双向 JSON-RPC + Item/Turn/Thread 原语 + HaaS）\n - Addy Osmani \"Loop Engineering\"（2026-06-08，loop 定调文：五构件 + 记忆脊柱；上游为 Steinberger 推文与 Boris Cherny \"我的工作是写循环\"）\n - Armin Ronacher \"The Coming Loop\"（2026-06-23，怀疑派回应：agent loop vs harness loop + 防御式编码放大 + 软件作为有机体）\n - Anthropic/Claude Code 团队 \"Loop engineering: Getting started with loops\"（2026-06-30，官方四类循环 turn/goal/time/proactive + `/goal` 独立判停）\n - Self-Harness 论文（arXiv 2606.09498，智能体自改 harness：弱点挖掘→提议→回归验证，三模型 held-out +14~21pp）\n - Lilian Weng \"Harness Engineering for Self-Improvement\"（2026-07-04，RSI 综述：三设计模式 + 优化对象递进链 + 七项未来挑战）\n - Aria 论文 \"Harnessing Code Agents for Automatic Software Verification\"（arXiv 2607.06341，声明式 HHL 包裹通用智能体做 Coq 证明，行为 harness 极限形态）\n - Anthropic \"Demystifying evals for AI agents\"（2026-01-09，智能体评测官方方法论：outcome≠transcript、pass@k/pass^k、CORE-Bench 42%→95% 基准病理）\n - Cursor / Wilson Lin \"Scaling long-running autonomous coding\"（2026-01-14，数百并发智能体 × 数周：planner/worker/judge + FastRender 百万行浏览器）\n - Anthropic / Nicholas Carlini \"Building a C compiler with a team of parallel Claudes\"（2026-02-05，16 agent 无编排者 + GCC oracle + $20k 成本账本）\n - Anthropic \"How we contain Claude across products\"（2026-05-25，三隔离模式 + 五起漏掉的风险：白名单是能力授予、先环境层遏制）\n - LangChain \"Introducing Dynamic Subagents in Deep Agents\"（2026-06-29）+ \"How to Use RLMs in Deep Agents\"（2026-07-01，模型写编排脚本 + RLM 递归上下文）\n - Fowler/Böckeler 本地模型双备忘录（2026-07 上旬，Qwen3.6 35B MoE 甜点 + 工具调用是智能体化分水岭）\n - Harness Handbook 论文（arXiv 2607.13285，2026-07-14，行为定位是 harness 演化瓶颈：行为中心表示 + BGPD）\n - Fowler / Unmesh Joshi \"DSLs Enable Reliable Use of LLMs\"（2026-07-14，DSL 工具集即 harness：语言层约束 + 确定性验证器）\n - Addy Osmani \"Own the Outer Loop\"（2026-07-15，AIE 闭幕演讲：智能体跑内环、工程师拥有外环问责 + back-pressure 调速）\n - Jarred Sumner \"Rewriting Bun in Rust\"（2026-07-08，50 dynamic workflows × 峰值 64 Claude × 11 天机械移植 53.5 万行 Zig→Rust；语言无关测试套件作 oracle + 1 实现者/2 对抗评审者/1 修复者 + \"修流程不修代码\"；$165k API 成本账本）\n - HarnessX 论文（arXiv 2606.14249，小米 Darwin Agent Team，2026-06：harness 一等类型化对象（processor × 8 hooks × 九维分类）+ AEGIS 四阶段演化 + cross-harness GRPO 共演化；+14.5% 均值（最高 +44.0%）、共演化再 +4.7%、弱模型受益最大）\n - Anthropic / Justin Young \"Effective harnesses for long-running agents\"（2025-11-26，存量回扫补录：initializer + coding 两段式、200+ 条 feature_list.json、claude-progress.txt + git、Puppeteer 端到端自验；#4/#7 的上游）\n - Anthropic / Gian Segato \"Quantifying infrastructure noise in agentic coding evals\"（2026-02-05，存量回扫补录：只改资源配额 Terminal-Bench 2.0 摆动 6pp；1x–3x 修可靠性、3x 以上改变被测对象；建议每任务声明保底分配 + 硬杀阈值）\n - Cursor / Stefan Heule & Jediah Katz \"Continually improving our agent harness\"（2026-04-30，存量回扫补录：Keep Rate、LLM 读用户回复判满意、CursorBench + 线上 A/B、错误分类与按工具按模型基线、每周 Automation 修 harness、按训练分布供给工具格式、context anxiety）\n - Cursor / Naman Jain \"Reward hacking is swamping model intelligence gains\"（2026-06-25，存量回扫补录：审计 731 条轨迹，SWE-bench Pro 上 63% 成功解是检索答案；封 git + 断网后 Opus 4.8 Max 87.1%→73.0%、Composer 2.5 74.7%→54.0%）\n - Armin Ronacher \"Better Models: Worse Tools\"（2026-07-04，工具 schema 不是中立的：Claude Code 的宽容客户端 + 在其中做 RL → 新模型对替代 schema 更差；strict 模式可清零）\n - Dex Horthy / HumanLayer \"Why Software Factories Fail — harness engineering is not enough\"（2026-07，AIE World's Fair 主题演讲 + wsff.md：熄灯工厂第一手失败实录、可维护性没有快 oracle、产品/架构/程序设计/垂直切片四阶段前移）\n - Addy Osmani \"Software Factories, Light and Dark\"（2026-07-20，loop→harness→factory 三层 + 唯一昂贵的评审闸门 + 背压规则 + \"什么样的循环配得上熄灯\"准入清单 + loops vs graphs）\n - Cursor / Wilson Lin \"Agent swarms and the new model economics\"（2026-07-20，#48 续篇：835 页手册重造 SQLite，账单 $1,339–$10,565；规划/执行分层、自建 VCS 1000 提交/秒、五种蜂群失效、去相关评审、Field Guide）\n - Anthropic / Thariq Shihipar \"The new rules of context engineering for Claude 5 generation models\"（2026-07-24，删掉 Claude Code 系统提示词 80%+ 无可测损失；七组 then/now + `claude doctor`）\n - Don't Blame the LLM 论文（arXiv 2607.03691，Queen's University，首个固定模型只变 harness 的受控纵向研究：Qwen Code CLI 35 个连续版本 × 50 个 SWE-bench Verified 任务）\n - Rethinking Harness Evolution 论文（arXiv 2607.12227，自动 harness 演化的第一份系统性负面结果：同等预算下不稳定优于 test-time scaling、泛化有限）\n - LangChain \"How We Benchmark Deep Agents\"（2026-07-23）+ \"IssueBench\"（2026-07-20）——Harbor 评测栈：Harbor-Index 82 任务 / lite 冻结子集 / capability suite；IssueBench 15 类失败分类法与 issue 集层面判分\n - LangChain / Nick Hollon \"Evaluating code review agents with ReviewBench\"（2026-07-31，真实 PR 评审意见策展成 59 任务 / 64 基线问题；裸 harness 最强召回 ~30%，prompt-only 调优 Luna 0.13→0.32 反超 Opus/Kimi）\n - Fowler / Birgitta Böckeler \"TDD inside the agent loop - theater or actual value?\"（2026-08-10，agent loop 内 TDD 实证否定：盲评质量无差异、mutation score 无差异、token 3–8.5 倍；别规定过程，度量结果）\n - Addy Osmani \"Practical Loop Engineering\"（2026-08-14，loop 系列日常落地环：踩坑实录 + 80K star 仓库分诊循环 + fine print 运维细则）\n - Zalando / Bartosz Ocytko \"Agentic Engineering at Zalando: A Snapshot\"（2026-08-14，250+ 团队非供应商组织级快照：事故分析→PR 风险分级→33% 自动放行→lead time -20~40%）\n - Earendil / Pi 团队双篇 \"What Is a Harness?\" + \"How Compaction Works in Pi\"（2026-08-20 / 08-13，harness 定义+用户侧中立主张 / compaction 白盒实现，与 Codex 端点化对照）\n - StarHarness 论文（arXiv 2608.24804，ServiceNow/Mila，2026-08-25，冻结 harness 工件跨 GPT/Qwen 迁移 12 行全正 +10.7~+46.3pp；跨模型可移植性首个正面证据）\n- **脉络二 — 云原生 Harness.io（2 篇）：** Harness.io 官方全局架构 / Google Cloud 集成场景\n- **脉络三 — 效率悖论（2 篇）：** YDD/Miss-you \"效率悖论的系统性拆解\"（2026-03-03）/ METR 实验后续 + 自报调查（2026-02-24 + 2026-05-11，\"慢 19%\"的官方后续：弱证据转向加速 + RCT 方法论危机）\n\n**已跟踪的开源项目/产品：**\n- Ralph Loop 实验链：snarktank/ralph、ralph-orchestrator、bmad-ralph\n- Chachamaru127/claude-code-harness（v4.2 \"Hokage\"，Claude Code 五动词工作流 + Go 原生 guardrail R01–R13；2026-04-21 收录）\n\n**请重点发现：**\n- 上述未覆盖的新作者 / 新视角 / 新组织\n- 对上述文章的**深度回应或反驳**（不是简单转述）\n- 与上述项目**互补或竞争**的新工具 / harness / 框架\n- 中文社区针对上述材料的原创分析（少数派、掘金、知乎专栏等）\n\n### 输出格式\n\n请按以下格式输出，每条内容一个条目：\n\n---\n\n#### [编号]. {标题}\n\n- **类型：** 文章 / 开源项目 / 工具 / 演讲 / 论文\n- **链接：** {URL}\n- **作者/组织：** {作者}\n- **日期：** {发布日期}\n- **信源层级：** Tier 1 / Tier 2 / Tier 3\n- **推荐指数：** ⭐⭐⭐⭐⭐（1-5 星）\n\n**一句话摘要：** {50 字以内}\n\n**核心洞察（3-5 条）：**\n1. ...\n2. ...\n3. ...\n\n**与已知内容的关联：**\n- 支持/挑战/扩展了哪篇已有文章的观点\n- 填补了哪个已知缺口\n\n**值得收录的理由 / 不值得的理由：**\n{判断}\n\n---\n\n### 质量过滤标准\n\n**必须满足（全部）：**\n- 有实质性的技术内容（不是纯营销或产品公告）\n- 有原创洞察或数据（不是对已有文章的简单转述）\n- 来源可信（有署名，有技术背景）\n\n**加分项（满足越多越好）：**\n- 有实际数据或实验结果\n- 有代码示例或可复现的方案\n- 挑战了主流观点\n- 来自一线实践者（不是纯理论）\n- 有中文社区尚未覆盖的视角\n\n**排除：**\n- 纯产品发布/营销内容\n- 对已有文章的简单翻译或摘要（没有新观点）\n- 过于初级的入门教程\n- 与 harness engineering 只有表面关联\n\n### 输出数量\n\n- 文章类：推荐 5-10 篇，按推荐指数排序\n- 开源项目类：推荐 3-5 个\n- 其他（工具/演讲/论文）：如有高质量内容，不限数量\n```\n\n---\n\n## Prompt B：Claude — 深度分析与项目关联\n\n> 在 ChatGPT 返回结果后，将结果喂给 Claude（在本项目中），做深度分析\n\n```\n以下是最近 2 周的技术情报搜索结果。请基于我们项目的已有内容，做以下分析：\n\n{粘贴 ChatGPT 的输出}\n\n### 请分析：\n\n1. **优先级排序**：哪些内容最值得我们收录？考虑因素：\n - 对**已收录文章 + 已跟踪开源产品**（完整清单见 Prompt A 的\"已知内容\"段落或 `references/articles.md`，不在此重复计数）的补充价值\n - 对 thinking/ 中已有洞见的验证或挑战（含 cross-article-insights 的 8 个洞见 + guides-sensors-meets-claude-code-harness 的 5 个张力）\n - 对开放问题清单的回答程度\n\n2. **缺口分析**：这批内容覆盖了我们的哪些知识缺口？还有哪些缺口未被触及？\n 当前已知缺口：\n - 行为 Harness（功能正确性验证）\n - Harness 覆盖率评估方法（#34/#35/#38 评测三部曲已部分回应，组件级信号供给仍开放）\n - 跨模型可移植性（#35 给出首个定量异质性证据，迁移指南仍缺）\n - 成本数据\n - 中小团队实践案例\n - Harness 接口维护成本（追宿主升级在总维护中的占比）\n - 控制的\"激活策略\"（always-on / per-commit / conditional / human-summoned 的分类与适用场景；#36 的 workflow/ultracode 触发是一个数据点）\n - Harness 安全审计（#33 开辟：中途轨迹违规、多智能体信息流、harness 决定安全上限——后续跟踪该方向的评测与工具）\n - 评测方法论（基准如何拆分 model/harness/环境的组件级归因——跟踪 #34/#35/#38 的后续工作）\n\n3. **趋势信号**：这批内容中是否有新的趋势或方向？与我们已有的四个学派（约束派、控制论派、架构派、怀疑派）是否一致？\n\n4. **收录建议**：对每条推荐内容给出具体建议：\n - 收录到 references/articles.md（哪个脉络）\n - 值得翻译到 works/\n - 值得在 thinking/ 中写分析\n - 暂不收录，持续观察\n```\n\n---\n\n## Prompt C：Manus / OpenClaw — 自动化监控\n\n> 用于设置定时监控的固定信源\n\n```\n定时任务：每日检查以下信源的更新\n\n监控列表：\n1. https://www.anthropic.com/engineering — RSS 或页面变化\n2. https://openai.com/index/ — 新文章\n3. https://martinfowler.com/articles/ — 新文章\n4. https://blog.langchain.com/ — 新文章\n5. https://github.com/trending?since=weekly — AI/agent 相关项目\n6. https://simonwillison.net/ — 新文章\n7. https://mitchellh.com/writing — 新文章\n8. https://claude.com/blog — 新文章（Anthropic 产品侧博客；2026-06 的 dynamic workflows / Managed Agents 两篇重磅均发于此，工程博客不覆盖）\n9. https://addyosmani.com/blog/ — 新文章\n10. https://ghuntley.com/ — 新文章（Ralph 方法论源头）\n\n匹配关键词：harness, agent, coding agent, context engineering, \n AGENTS.md, compaction, multi-agent, sandbox\n\n输出：\n- 有更新时，发送通知（标题 + 链接 + 匹配的关键词）\n- 无更新时，静默\n```\n\n---\n\n## 工作流总结\n\n```\n┌─────────────────────────────────────────────────┐\n│ Layer 1: 自动化监控（每日） │\n│ 工具：OpenClaw / Manus │\n│ 输出：固定信源的新内容通知 │\n└──────────────────────┬──────────────────────────┘\n ↓ 有新内容时触发\n┌─────────────────────────────────────────────────┐\n│ Layer 2: 广度搜索（每 1-2 周） │\n│ 工具：ChatGPT Deep Research │\n│ 输入：Prompt A │\n│ 输出：5-10 篇文章 + 3-5 个项目的结构化摘要 │\n└──────────────────────┬──────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────┐\n│ Layer 3: 深度分析（按需） │\n│ 工具：Claude（本项目内） │\n│ 输入：Prompt B + ChatGPT 输出 │\n│ 输出：优先级排序 + 缺口分析 + 收录建议 │\n└──────────────────────┬──────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────┐\n│ Layer 4: 人工确认 │\n│ 你决定：收录 / 翻译 / 写分析 / 跳过 │\n└─────────────────────────────────────────────────┘\n```\n\n## 核心信源存量回扫（每批必做一步）\n\n> 教训来自 2026-07-21 批次：只按\"最近 2 周\"时间窗扫描，导致 4 篇 1–5 月的重量级官方件\n> （Cursor scaling-agents、Anthropic C compiler / how-we-contain / demystifying-evals）漏网数月。\n> 时间窗抓增量，回扫补存量——两者缺一不可。\n\n每轮调研除时间窗扫描外，**轮换抽取 1–2 个 Tier 1 信源，翻其全年归档目录**（archive / blog 列表页），\n对照 `references/articles.md`（含观察项表）逐条核对是否已收录或已甄别。优先轮换顺序：\n\n1. anthropic.com/engineering（工程博客，全量列表）\n2. cursor.com/blog（research 分类）\n3. openai.com/index（Engineering 分类）\n4. martinfowler.com/tags（GenAI 标签 + exploring-gen-ai 系列）\n5. langchain.com/blog、claude.com/blog、addyosmani.com/blog、simonwillison.net 月归档\n\n发现漏网存量时，与本批增量一起进「候选 × 定性 × 去向」评审表，注明\"存量补课\"。\n\n### 轮换记录\n\n| 批次 | 回扫信源 | 捞回的存量 |\n|------|---------|-----------|\n| 2026-07-21 | （教训来源，未做系统回扫） | 事后补收 #48 / #49 / #50 / #47 |\n| 2026-07-27 | ① anthropic.com/engineering 全量列表 ② cursor.com/blog 全量 slug 清单 | #58 Effective harnesses（2025-11）、#59 基础设施噪声（2026-02）、#60 持续改进 agent harness（2026-04）、#61 奖励作弊（2026-06）——四篇均为 harness 主题正中靶心却漏网数月 |\n| 2026-08-03 | ① openai.com/sitemap.xml/engineering 全量 URL+lastmod ② martinfowler.com/feed.atom（GenAI 归档） | 无漏网存量：OpenAI Engineering 分类的 harness 主题件（harness-engineering / unrolling / unlocking / symphony / windows-sandbox / core-dump / websockets / how-agents-transforming-work）均已在编号正文或观察项；其余 gpt-5.6 / atlas / sora-android / tax-agents / data-agent 为产品·基建，非 harness。Fowler 侧捞出的是增量而非存量（重构经济效益 / Conductor Developer / Fragments 07-21 / Orchestrator's Tax 草稿）——已进本批观察项 |\n| 2026-08-27 | ① langchain.com/blog sitemap 全量（507 slug）② claude.com/blog sitemap 全量（228 slug，去 locale 变体） | **非零星漏网而是系统性缺口**：langchain 相关约 115 篇/此前仅收 19（漏网详查 48，含 12 篇标题直接带 harness/loop 的核心文：improving-deep-agents-with-harness-engineering、better-harness、the-art-of-loop-engineering、deep-agents 开山文等）；claude.com 相关约 80/仅收 9（漏网详查 41：skills 全系列、subagent 系列、Lessons from building Claude Code 双篇等）。处置：不逐篇消化，观察项表加 2 个\"信源级\"合并行，完整清单留档 translate/2026-08-27/candidates.md。方法论教训：两站列表页对 curl 均不完整**必须走 sitemap.xml**；claude.com 的 lastmod 批量刷新不可作发布日期，需逐页取 JSON-LD datePublished |\n\n> 下一轮建议轮换：addyosmani.com/blog + simonwillison.net 月归档（个人博客侧尚未系统回扫过）；cursor.com/blog 可顺带复扫（本批已全量取 sitemap 115 slug 逐页核过日期，短期内干净）。openai.com/index 用 `curl https://openai.com/sitemap.xml/engineering/` 拿到带 lastmod 的全量 URL 最省事（2026-08-03 验证有效，比抓列表页首屏可靠）。\n> 回扫技巧（2026-07-27 验证有效）：列表页只渲染最近若干条时，直接抓 `curl |grep -oE '/blog/[a-z0-9-]+'|sort -u` 拿全量 slug，\n> 再逐个取 `datePublished` 与标题——Cursor 那四条里有两条（`continually-improving-agent-harness`、`reward-hacking-coding-benchmarks`）就是这样发现的，它们不在列表页首屏。\n","tools/00-overview.md":"# 工具地图：复杂度维度 ↔ 工具杠杆\n\n> 配套 [software-project-complexity-in-the-ai-era.md](../thinking/software-project-complexity-in-the-ai-era.md) 的6 维复杂度框架使用。\n\n---\n\n## 思路\n\n每个工具的真正价值，不是它的功能列表，而是：\n\n> **它能切实降低 AI 接管难度的哪一维？**\n\n如果一个工具不能映射到任何一维复杂度的下降，它就不应该出现在这里。\n\n---\n\n## 维度 × 工具矩阵\n\n\n### 六个分子维度（越高越复杂）\n\n| # | 复杂度维度 | 工具杠杆候选 | 实测笔记 |\n| --- | ------ | ------------------------------- | ---- |\n| 1 | 上下文压力 | [待补：检索 / 语义索引 / 上下文压缩] | [待补] |\n| 2 | 可提示性 | [待补：SPEC 模板 / DSL / 业务建模] | [待补] |\n| 3 | 探索收敛 | [待补：AGENTS.md / 项目地图 / sitemap] | [待补] |\n| 4 | 状态纠缠 | [待补：模块边界检查 / 依赖图 / ArchUnit 类] | [待补] |\n| 5 | 暗知识 | [待补：ADR / 决策记录 / 注释规范] | [待补] |\n| 6 | 验证成本 | [ralph-orchestrator](harnesses/ralph-orchestrator.md)（背压门控，主战场）；另待补：测试框架 / CI / 类型检查 / linter | ✅ [practice/01](../practice/01-ralph-demo/) 实测：Builder 测试全绿才交棒 + Critic 独立重验 |\n\n### 分母：胶囊化能力（越高越好）\n\n| 维度 | 工具杠杆候选 | 实测笔记 |\n| --------- | ------------------------------------- | ---- |\n| **胶囊化能力** | Claude Code / Codex / Cursor / ... 等各大 harness 框架 | Harness 框架的核心价值——让 AI 在可控边界内完成任务，从而把上面六维的成本同时压下来 |\n\n### 终局指标：重构 + 复刻\n\n> 文章最后指出\"重构能力 + 复刻能力\"是复杂度的最终显影。一个工具是否值得收录，最终可以问：**它是否提升了项目的重构 / 复刻可行性？**\n\n注：同一个工具可能横跨多维。**填表时按\"主战场\"放，次要贡献在工具页里展开。**\n\n---\n\n## 收录工具（持续更新）\n\n### Harness 框架\n\n> 作者使用为主，已在 [practice/](../practice/) 中跑过的优先标注 ✅\n\n- ✅ [ralph-orchestrator](harnesses/ralph-orchestrator.md) — 已在 [practice/01-ralph-demo/](../practice/01-ralph-demo/) 实测（v2.8.1，4 轮迭代 / 321s / $0.31）\n- Claude Code（practice/01 中作为 Ralph 的执行后端使用过；独立工具页待写）\n- Codex CLI/ Codex App\n- Cursor\n- [其他待补]\n\n### 辅助工具\n\n> 按 6 维分类组织\n\n- [待补]\n\n---\n\n## 撰写新工具页的检查清单\n\n- 是否回答了\"它降低了哪几维复杂度\"\n- 是否给出至少一个**失效场景**（不是只写优点）\n- 是否标注与其他已收录工具的搭配 / 冲突\n- 是否说明\"为什么是它而不是同类竞品\"\n\n","references/AGENTS.md":"# references/ — 外部资源索引\n\n相关文章、仓库、工具的统一索引。这里是指针，不是内容本身。\n\n## 文件约定\n\n- 按主题分文件，如 `articles.md`、`repos.md`、`tools.md`\n- 每条记录包含：链接、一句话说明、与 Harness Engineering 的关联\n\n## 文章\n\n详见 [articles.md](articles.md) — 完整的文章索引，含三条脉络 **79 篇文章 + 1 项已跟踪产品** 的深度摘要。\n权威计数与编号规则以 `articles.md` 头部为准；本表是它的概览缓存。\n\n### 脉络一：AI 时代的 Harness Engineering（75 篇）\n\n| # | 文章 | 作者 | 核心贡献 |\n|---|------|------|---------|\n| 1 | [OpenAI 原文](https://openai.com/zh-Hans-CN/index/harness-engineering/) | Ryan Lopopolo | 原点：六大概念 |\n| 2 | [Martin Fowler](https://martinfowler.com/articles/harness-engineering.html) | Birgitta Böckeler | Guides×Sensors 控制论框架 + Harnessability + Ashby 定律 |\n| 3 | [LangChain](https://blog.langchain.com/the-anatomy-of-an-agent-harness/) | Vivek Trivedy | 精确定义 + 组件清单 |\n| 4 | [Anthropic](https://www.anthropic.com/engineering/harness-design-long-running-apps) | Prithvi Rajasekaran | GAN 三智能体 + Harness 瘦身 |\n| 5 | [HumanLayer](https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents) | Kyle | 六个杠杆 + 实战避坑 |\n| 6 | [Anthropic/Claude Platform](https://claude.com/blog/harnessing-claudes-intelligence) | Lance Martin | 三大构建模式 + BrowseComp 数据 |\n| 7 | [Anthropic/Managed Agents](https://www.anthropic.com/engineering/managed-agents) | Lance Martin 等 | Meta-harness + 基础设施解耦 |\n| 8 | [Fowler/Encoding Team Standards](https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html) | Rahul Garg | 团队标准显式化三层路径 |\n| 9 | [Fowler/Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html) | Rahul Garg | 从 AI 失败中持续学习的反馈闭环 |\n| 10 | [LangChain/Agent Evaluation Checklist](https://blog.langchain.com/agent-evaluation-readiness-checklist/) | LangChain 团队 | 智能体评估五阶段清单 |\n| 11 | [Meta-Harness 论文](https://arxiv.org/abs/2603.28052) | Yoonho Lee 等 (Stanford) | 自动化 Harness 搜索优化 |\n| 12 | [GitHub/Agent-driven Development](https://github.blog/ai-and-ml/github-copilot/agent-driven-development-in-copilot-applied-science/) | Tyler McGoffin | 智能体驱动开发实战 |\n| 13 | [Inside the Scaffold 论文](https://arxiv.org/html/2604.03515v1) | Benjamin Rombaut (Huawei) | 13 个编码智能体脚手架源代码分类法 |\n| 14 | ⭐ [Eight years of wanting](https://lalitm.com/post/building-syntaqlite-ai/) | Lalit Maganti | AI 构建真实项目的坦诚复盘 |\n| 15 | [Continual learning for AI agents](https://blog.langchain.com/continual-learning-for-ai-agents/) | Harrison Chase | 三层学习：模型/Harness/上下文 |\n| 16 | [OpenAI Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/) | Kotliarskyi 等 | 任务跟踪器作为控制平面 + SPEC/WORKFLOW 即产品 |\n| 17 | [Claude Code Architecture](https://vrungta.substack.com/p/claude-code-architecture-reverse) | Vikash Rungta | Claude Code 运行外壳、TAOR 循环、工具原语、权限与上下文管理的外部逆向分析 |\n| 18 | [Harness 系列文章之 7：关于 subagent](https://x.com/dongxi_nlp/status/2068922428516892998) | 马东锡 NLP | Subagent = tool call 入口 + child runtime；区分 session/context/subagent 与 evidence 回流 |\n| 19 | [Fowler/Maintainability sensors](https://martinfowler.com/articles/sensors-for-coding-agents.html) | Birgitta Böckeler | 计算性 vs 推理性传感器谱系 + 失败案例 + AI 评审作为垃圾回收 |\n| 20 | [Fowler/SPDD](https://martinfowler.com/articles/structured-prompt-driven/) | Wei Zhang, Jessie Jie Xia | REASONS Canvas 七维 + prompt 即一等交付物 + 双向闭环 |\n| 21 | [LangChain/ADLC](https://www.langchain.com/blog/the-agent-development-lifecycle) | Harrison Chase | 智能体开发生命周期 + framework/runtime/harness 三分类 |\n| 22 | [LangChain/Interpreters in Deep Agents](https://www.langchain.com/blog/give-your-agents-an-interpreter) | Hunter Lovell | interpreter 是第三类上下文表面 + 35% token 节省 |\n| 23 | [Anthropic/质量回归复盘](https://www.anthropic.com/engineering/april-23-postmortem) | Anthropic 工程团队 | 三起独立变更叠加成质量退化 + 变更治理清单（第一手反例） |\n| 24 | [Agentic Harness Engineering 论文](https://arxiv.org/html/2604.25850v4) | Jiahang Lin 等（复旦/北大/奇绩） | 可观测性驱动的 Harness 自动演化 + 每次编辑即可证伪契约 |\n| 25 | [Overeager Coding Agents 论文](https://arxiv.org/html/2605.18583v1) | Yubin Qu 等 | 越界动作测量 + 提示声明授权反而降低边界推断 |\n| 26 | [How I Use AI to Code](https://chrismdp.com/coding-with-ai/) | Chris Parsons | 四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈 |\n| 27 | [How we built LangSmith Engine](https://www.langchain.com/blog/how-we-built-langsmith-engine-our-agent-for-improving-agents) | Palash Shah | 用智能体改进智能体 + trace→轨迹骨架 + screener/investigator 两阶段闭环 |\n| 28 | [Ralph 原始文章 + 续篇](https://ghuntley.com/ralph/) | Geoffrey Huntley | Ralph = bash 循环 + 每轮干净上下文 + 背压；单体反多智能体论（还上 practice/ Ralph Demo 的理论债） |\n| 29 | [My AI Adoption Journey](https://mitchellh.com/writing/my-ai-adoption-journey) | Mitchell Hashimoto | 六步采纳路线 + \"harness engineering\" 命名出处（由延伸阅读升格） |\n| 30 | [Claude Code 源码泄漏事件](https://github.com/pankaj28843/understanding-claude-code) | Chaofan Shou 发现 / 社区聚合分析 | 512K 行 harness 实锤解剖：QueryEngine/60+ 门控工具/KAIROS/AutoDream，#17 推测的对照组 |\n| 31 | [Agent Harness Engineering](https://addyosmani.com/blog/agent-harness-engineering/) | Addy Osmani | 学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS（综述破例进编号正文） |\n| 32 | [Exploring AI coding sensors](https://www.thoughtworks.com/en-au/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors) | Böckeler & Ford | 有/无传感器对照实验 + 态势感知论 + harness 模板展望 |\n| 33 | [HarnessAudit 论文](https://arxiv.org/abs/2605.14271) | Chengzhi Liu 等 | harness 安全审计：中途轨迹违规是输出级评估的盲区 + 210 任务基准 |\n| 34 | [Harness-Bench 论文](https://arxiv.org/abs/2605.27922) | Yilun Yao 等 | 配置级 harness 效应测量（106 任务/5194 轨迹）+ 执行对齐失败分类 |\n| 35 | [How good is your harness? 论文](https://openreview.net/forum?id=QI8z3skBwt) | Jiwoo Han, Yuekai Sun | Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应，且效应异质 |\n| 36 | [Dynamic workflows in Claude Code](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code) | Anthropic / Claude | 模型现场写自己的编排 harness + 对抗验证 + workflow 沉淀为 Skill |\n| 37 | [Harness 才是产品](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/) | 马东锡 NLP | \"Model 在 loop 里，harness 拥有 loop\" + 六组件 + 症状→组件 debug 对照表 |\n| 38 | [Position: 基准错位论文](https://arxiv.org/abs/2606.17799) | Maria I. Gorinova 等 | 基准把 model/harness/环境折叠进一个分数的三症状诊断 |\n| 39 | [Unrolling the Codex agent loop](https://openai.com/index/unrolling-the-codex-agent-loop/) | Michael Bolin (OpenAI) | Codex harness 解剖·上：prompt 构造 / 二次方问题与 prompt caching / compaction 端点化 |\n| 40 | [Unlocking the Codex harness](https://openai.com/index/unlocking-the-codex-harness/) | Celia Chen (OpenAI) | Codex harness 解剖·下：App Server 双向 JSON-RPC + Item/Turn/Thread 原语 + HaaS 落地 |\n| 41 | [Loop Engineering](https://addyosmani.com/blog/loop-engineering/) | Addy Osmani | loop 定调文：五构件 + 记忆脊柱；\"循环分不出两种用法的区别，你分得出\" |\n| 42 | [The Coming Loop](https://lucumr.pocoo.org/2026/6/23/the-coming-loop/) | Armin Ronacher | 怀疑派回应：agent loop vs harness loop + 防御式编码放大 + 软件作为有机体 |\n| 43 | [Loop engineering: Getting started with loops](https://claude.com/blog/getting-started-with-loops) | Claude Code 团队 | 官方四类循环（turn/goal/time/proactive）+ `/goal` 独立判停 + 用量治理清单 |\n| 44 | [Self-Harness 论文](https://arxiv.org/abs/2606.09498) | Hangfan Zhang 等 | 智能体自改 harness：弱点挖掘→提议→回归验证；三模型 held-out +14~21pp |\n| 45 | [Harness Engineering for Self-Improvement](https://lilianweng.github.io/posts/2026-07-04-harness/) | Lilian Weng | RSI 综述：三设计模式 + 优化对象递进链 + 七项未来挑战 + \"harness 终将内化\"预测 |\n| 46 | [Aria：自动软件验证论文](https://arxiv.org/abs/2607.06341) | Shuangxiang Kan 等 | 行为 harness 极限形态：声明式 HHL 包裹通用智能体做 Coq 证明，全引理零人工通过 |\n| 47 | [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) | Mikaela Grace 等 (Anthropic) | 智能体评测官方方法论：outcome≠transcript、pass@k/pass^k、评结果不评路径、CORE-Bench 42%→95% 基准病理 |\n| 48 | [Scaling long-running autonomous coding](https://cursor.com/blog/scaling-agents) | Wilson Lin (Cursor) | 数百并发智能体 × 数周：扁平自协调失败史 → planner/worker/judge；FastRender 百万行浏览器 |\n| 49 | [Building a C compiler with parallel Claudes](https://www.anthropic.com/engineering/building-c-compiler) | Nicholas Carlini (Anthropic) | 16 agent 无编排者造 10 万行 C 编译器（$20k/两周）：近乎完美验证器 + GCC oracle + 为 Claude 写测试 |\n| 50 | [How we contain Claude across products](https://www.anthropic.com/engineering/how-we-contain-claude) | Max McGuinness 等 (Anthropic) | 三隔离模式 × 五起漏掉的风险：白名单是能力授予；先环境层遏制再模型层引导 |\n| 51 | [Deep Agents 动态子智能体 + RLM](https://www.langchain.com/blog/introducing-dynamic-subagents-in-deep-agents) | LangChain 团队 | 模型写编排脚本驱动 subagent（QuickJS + `task()`）；RLM 处理超上下文两个数量级的输入 |\n| 52 | [Böckeler 本地模型双备忘录](https://martinfowler.com/articles/exploring-gen-ai/local-models-for-coding-factors.html) | Birgitta Böckeler | 高端开发机跑本地小模型做智能体编码实测：Qwen3.6 35B MoE 甜点、工具调用是分水岭 |\n| 53 | [Harness Handbook 论文](https://arxiv.org/abs/2607.13285) | Ruhan Wang 等（腾讯等） | 行为定位是 harness 演化瓶颈：行为中心表示 + BGPD，win rate +10.0/+18.9pp 且省 12.7%/8.6% token |\n| 54 | [DSLs Enable Reliable Use of LLMs](https://martinfowler.com/articles/llm-and-dsls.html) | Unmesh Joshi | \"DSL 工具集本身就是出色的 harness\"：语言层约束 + 确定性验证器 + 领域级错误反馈 |\n| 55 | [Own the Outer Loop](https://addyosmani.com/blog/own-the-outer-loop/) | Addy Osmani | 智能体跑内环、工程师拥有外环问责；back-pressure 调节循环速率与作用域来授予自主权 |\n| 56 | [Rewriting Bun in Rust](https://bun.sh/blog/bun-in-rust) | Jarred Sumner | \"修流程不修代码\"工业级实录：50 dynamic workflows × 64 Claude × 11 天移植 53.5 万行 Zig；语言无关测试套件作 oracle + 对抗评审默认化 |\n| 57 | [HarnessX 论文](https://arxiv.org/abs/2606.14249) | Darwin Agent Team（小米） | harness 一等类型化对象 + AEGIS 轨迹演化 + cross-harness GRPO 共演化：+14.5%（共演化再 +4.7%），弱模型受益最大 |\n| 58 | [Anthropic/长时智能体的有效 harness](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) | Justin Young | 外部工件即记忆的奠基文：initializer + coding 两段式、200+ 条 feature_list.json、progress 文件 + git、Puppeteer 端到端自验（存量回扫补录） |\n| 59 | [Anthropic/基础设施噪声](https://www.anthropic.com/engineering/infrastructure-noise) | Gian Segato | 只改资源配额，Terminal-Bench 2.0 摆动 6pp；1x–3x 修可靠性、3x 以上改变被测对象；\"低于 3pp 的榜单差距都该怀疑\" |\n| 60 | [Cursor/持续改进 agent harness](https://cursor.com/blog/continually-improving-agent-harness) | Stefan Heule & Jediah Katz | harness 运维的度量学：Keep Rate、LLM 读用户回复判满意、错误分类与按工具按模型基线、每周 Automation 修 harness；按训练分布供给工具格式 |\n| 61 | [Cursor/奖励作弊淹没智能增益](https://cursor.com/blog/reward-hacking-coding-benchmarks) | Naman Jain | 审计 731 条轨迹：SWE-bench Pro 上 63% 的成功解是检索答案而非推导；封 git+断网后 Opus 4.8 Max 87.1%→73.0% |\n| 62 | [Better Models: Worse Tools](https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/) | Armin Ronacher | 工具 schema 不是中立的：在宽容 harness 里做 RL，新模型对替代 schema 反而更差；跨模型可移植性的机制级坏消息 |\n| 63 | [为什么软件工厂会失败](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md) | Dex Horthy (HumanLayer) | \"harness engineering 还不够\"：可维护性没有快 oracle，RL 不惩罚坏设计；熄灯工厂第一手失败实录 + 四阶段前移方案 |\n| 64 | [Software Factories, Light and Dark](https://addyosmani.com/blog/software-factories/) | Addy Osmani | loop→harness→factory 三层 + 唯一昂贵的评审闸门 + 背压规则 + \"什么样的循环配得上熄灯\"准入清单 |\n| 65 | [智能体蜂群与新的模型经济学](https://cursor.com/blog/agent-swarm-model-economics) | Wilson Lin (Cursor) | 从 835 页手册重造 SQLite：质量趋同、账单从 $1,339 到 $10,565；规划/执行分层、自建 VCS（1000 提交/秒）、去相关评审、Field Guide |\n| 66 | [Claude 5 世代的上下文工程新规则](https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models) | Thariq Shihipar (Anthropic) | 删掉 Claude Code 系统提示词 80%+ 而编码评测无可测损失；七组 then/now 对照 + `claude doctor` |\n| 67 | [Don't Blame the LLM 论文](https://arxiv.org/abs/2607.03691) | Oussama Ben Sghaier 等（Queen's） | 首个固定模型、只变 harness 的受控纵向研究：Qwen Code CLI 35 个连续版本 × 50 个 SWE-bench Verified 任务 |\n| 68 | [Rethinking Harness Evolution 论文](https://arxiv.org/abs/2607.12227) | Yike Wang 等 | 自动 harness 演化的第一份系统性负面结果：同等预算下不稳定优于简单 test-time scaling，泛化有限 |\n| 69 | [LangChain/Harbor 评测栈](https://www.langchain.com/blog/how-we-benchmark-deep-agents) | Nick Hollon, Harrison Chase 等 | 给 harness 建标尺（Harbor-Index 82 任务 / lite 子集 / capability suite），再给标尺建标尺（IssueBench 15 类失败分类法） |\n| 70 | [LangChain/ReviewBench](https://www.langchain.com/blog/evaluating-code-review-agents-with-reviewbench) | Nick Hollon | 给\"AI 代码评审\"传感器造考卷：真实 PR 评审意见策展成 59 任务；裸 harness 最强召回 ~30%，prompt-only 调优 0.13→0.32 反超 |\n| 71 | [Fowler/TDD in the agent loop](https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html) | Birgitta Böckeler | agent loop 内 TDD 的实证否定：盲评质量无差异、token 3–8.5 倍；别规定过程，度量结果 |\n| 72 | [Osmani/Practical Loop Engineering](https://addyosmani.com/blog/practical-loop-engineering/) | Addy Osmani | loop 系列日常落地环：踩坑实录（差点连判断也委托）+ 分诊循环 + fine print 运维细则 |\n| 73 | [Zalando 组织级快照](https://engineering.zalando.com/posts/2026/08/agentic-engineering-at-zalando-a-snapshot.html) | Bartosz Ocytko | 250+ 团队非供应商第一人称：事故分析→风险分级→33% 自动放行→lead time -20~40% 的组织级反馈回路 |\n| 74 | [Earendil/Pi 双篇](https://earendil.com/posts/what-is-a-harness/) | Pi 团队 | harness 定义+用户侧中立主张 / compaction 白盒实现（20K 预算、独立请求、纯文本可移植）——与 #39 端点化恰成对照 |\n| 75 | [⭐ StarHarness 论文](https://arxiv.org/abs/2608.24804) | ServiceNow/Mila | 冻结 harness 工件跨 GPT/Qwen 迁移 12 行全正（+10.7~+46.3pp）；跨模型可移植性缺口首个正面证据 |\n\n### 脉络二：云原生 Harness.io（2 篇）\n\n| # | 文章 | 核心贡献 |\n|---|------|---------|\n| 76 | [Harness.io 官方](https://www.harness.io/blog/understanding-ci-cd-platforms-the-backbone-of-modern-devops) | CI/CD 平台全局架构 |\n| 77 | [Google Cloud Architecture](https://docs.cloud.google.com/architecture/partners/harness-cicd-pipeline-for-rag-app) | Harness + GCP 部署 RAG |\n\n### 脉络三：效率悖论与能力进化（2 篇）\n\n| # | 文章 | 核心贡献 |\n|---|------|---------|\n| 78 | [YDD / Miss-you](https://yousali.com/posts/20260303-ai-coding-efficiency-to-evolution/) | 效率悖论的系统性拆解：约束理论 + Spec/Rule/Skill + 验证闭环 + 并发 |\n| 79 | [METR 实验后续 + 自报调查](https://metr.org/blog/2026-02-24-uplift-update/) | \"慢 19%\" 的官方后续：弱证据转向加速 + AI 渗透破坏 RCT 可行性本身 |\n\n### 已跟踪产品 / 项目（不计入文章数）\n\n| 项 | 项目 | 说明 |\n|---|------|------|\n| ⭐ | [Chachamaru127 / claude-code-harness v4.2 \"Hokage\"](https://github.com/Chachamaru127/claude-code-harness/tree/v4.2.0) | Claude Code 上当下最完整的开源 harness 实现之一；Plan→Work→Review→Release 五动词 + Go 原生 R01–R13 guardrail。本仓库分析见 `thinking/guides-sensors-meets-claude-code-harness.md` |\n\n## 项目\n\n### Ralph 系列\n\n| 项目 | Stars | 说明 | 关联概念 |\n|------|-------|------|---------|\n| [snarktank/ralph](https://github.com/snarktank/ralph) | 13.6k | 原版 Ralph 循环：bash + PRD + 每次清空上下文 | 全部六大概念的最小实现 |\n| [ralph-orchestrator](https://mikeyobrien.github.io/ralph-orchestrator/) | 2.3k | Rust 版：Hat 角色 + 事件驱动 + 背压 | 机械化执行、熵管理 |\n| [bmad-ralph](https://github.com/qianxiaofeng/bmad-ralph) | 2 | BMAD + Ralph：并行 worktree + 三层自愈 | 自主水平提升、吞吐量 |\n\n### 社区\n\n| 资源 | 说明 | 关联 |\n|------|------|------|\n| [vibe-coding-cn](https://github.com/tukuaiai/vibe-coding-cn) | 中文 Vibe Coding 社区 | 仓库组织方式、AGENTS.md 分级 |\n\n### 延伸阅读\n\n| 资源 | 说明 |\n|------|------|\n| [Martin Fowler: Context Engineering for Coding Agents](https://martinfowler.com/articles/context-engineering-coding-agents.html) | Context Engineering 专题 |\n| [Martin Fowler: Humans and Agents in SE Loops](https://martinfowler.com/articles/humans-and-agents.html) | 人类与智能体的协作模式 |\n\n> Mitchell Hashimoto 的 My AI Adoption Journey 原在此表，2026-07 已升格为编号条目 #29。\n\n## 待补充\n\n> 占位条目统一收在这里，**不进 `articles.md` 的编号正文**，避免污染文章计数。\n\n- [x] Geoffrey Huntley 的 Ralph 原始文章 → 已收录为 #28（2026-07）\n- [x] OpenAI Codex harness 解剖二部曲 → 已收录为 #39（Unrolling the Codex agent loop）+ #40（Unlocking the Codex harness / App Server）（2026-07-15）\n- [ ] 马东锡 Harness 系列其余篇目（仓库已收 #18 之 7、#37 才是产品；2026-07 系列新帖包括\"Model 可以请求，Harness 负责裁决——这就是契约\"\"模型记住的是 transcript，Harness 必须记住 truth（File State 是合格 harness 的基本功）\"；X 原帖需本地工具抓取）\n- [ ] Medium 实战专栏 — \"Beyond Migration: How We Engineered a Secure & Intelligent Delivery Platform with Harness CICD\"（标题可能已变更或文章已下架）\n\n## 下一步\n\n读完一篇资料后：\n- 想对它的论点做独立分析或质疑 → [thinking/](../thinking/)\n- 想翻译为中文输出 → [works/](../works/)\n- 想用它的方法做实验 → [practice/](../practice/)\n- 想沉淀其中的提示词模板 → [prompts/](../prompts/)\n","tools/AGENTS.md":"# tools/ — 工具具像化\n\n把 `concepts/` 里抽象的 Harness 概念落到具体可用的工具上。\n本目录的核心问题：**哪些工具能切实降低 [6 维复杂度框架](../thinking/software-project-complexity-in-the-ai-era.md) 中的某一维，或提升\"胶囊化能力\"这个总杠杆？**\n\n## 文件约定\n\n- `00-overview.md` — 工具地图：维度 × 工具矩阵（先读）\n- `harnesses/` — Agent harness 框架（首篇：[ralph-orchestrator.md](harnesses/ralph-orchestrator.md)；Claude Code、Codex、Cursor 等待写）\n- `auxiliary/` — 辅助工具（linter、CI、文档、测试、依赖分析等）；**规划中**，首篇辅助工具页落地时再建目录\n\n每个工具页结构（建议，非强制）：\n\n1. **一句话定位** —— 它是什么\n2. **降低哪些维度的复杂度** —— 引用 6 维框架的具体维度名 + 是否提升\"胶囊化能力\"\n3. **实测体验** —— 用过的真实场景、生效边界、失效场景\n4. **搭配建议** —— 与本目录其他工具的组合\n5. **替代方案** —— 同类竞品对比（如有）\n\n## 收录标准\n\n- **自己实际用过** —— 不收\"听说很好\"的工具\n- 或在 [`practice/`](../practice/) 中验证过\n- 拒绝\"工具大全\"式罗列——本目录不是 awesome-list，是带主张的杠杆库\n\n## 与其他目录的关系\n\n- `concepts/` 提出**该做什么**\n- `tools/` 提供**用什么做**\n- `practice/` 给出**实际做的过程与结果**\n\n## 下一步\n\n读完 [00-overview.md](00-overview.md) 后，按维度反查工具，按工具反查实践。\n","thinking/AGENTS.md":"# thinking/ — 独立思考\n\n读完 concepts/ 后，在这里写下你自己的理解、质疑和延伸思考。\n\n## 文件约定\n\n- 文件名：自由命名，建议用问题或论点作为文件名\n- 例如：`harness-vs-vibe-coding.md`、`is-this-only-for-openai.md`\n- 结构：问题/论点 → 自己的分析 → 结论或开放问题\n- 鼓励质疑原文，提出反例\n\n## 已有文章\n\n| 文件 | 主题 | 核心论点 |\n|------|------|---------|\n| [cross-article-insights.md](cross-article-insights.md) | 跨文章深层洞见 | 8 个洞见：Harness 生命周期、四学派、评估之踵、人类角色消解 |\n| [harnessability-and-java.md](harnessability-and-java.md) | Java 的可驾驭性 | Java/Spring 天然提供高 Harnessability 基线 |\n| [meta-harness-tensions.md](meta-harness-tensions.md) | Meta-Harness 的五个张力 | Anthropic Managed Agents 与既有实践的矛盾 |\n| [evaluation-elephant-in-the-room.md](evaluation-elephant-in-the-room.md) | 评估是房间里的大象 | 行为正确性验证是整个体系的阿喀琉斯之踵 |\n| [harness-for-solo-developers.md](harness-for-solo-developers.md) | 个人开发者的 Harness | 六大概念的适用性分析：直接可用 vs 需要降级 vs 不适用 |\n| [guides-sensors-meets-claude-code-harness.md](guides-sensors-meets-claude-code-harness.md) | Böckeler 框架 vs claude-code-harness v4.2 | 产品级实现暴露的五个张力：Advisor 装不进 2×2、guardrail 融合前馈反馈、行为 Harness 是结构性绕过、追上游占 95% 维护成本、harness 必带价值观锁定 |\n| [software-project-complexity-in-the-ai-era.md](software-project-complexity-in-the-ai-era.md) | AI 时代的软件项目复杂度 | 6 维（上下文压力 / 可提示性 / 探索收敛 / 状态纠缠 / 暗知识 / 验证成本）+ 胶囊化分母 + 重构/复刻终局指标 |\n| [subagent-is-child-runtime.md](subagent-is-child-runtime.md) | Subagent 是 child runtime | 与 Claude Code 架构逆向互证：subagent = tool-call-triggered child session + context projection + evidence-return contract |\n| [why-this-project-exists.md](why-this-project-exists.md) | 为什么有这个项目 | 项目宗旨：把 Harness Engineering 从\"概念集合\"变成\"可复刻的产品构建方法论\"——借用《诡秘之主》\"学徒途径\"隐喻 |\n| [fix-the-process-not-the-code.md](fix-the-process-not-the-code.md) | 修流程，不修代码 | Bun 重写案例对照 #36/#49/#55：工程师的交付物是生成过程本身；测试套件与实现语言正交是 Harnessability 新维度；验证器完备度决定成本曲线 |\n| [se-to-agent-engineering-mapping.md](se-to-agent-engineering-mapping.md) | 传统 SE ↔ Agent 工程对照表 | 15 行同构映射的三处修正：右列主语混三层（①人对 agent ②agent 自身 ③人对系统）、补熵管理/并发合并/持久会话三行、版本钉选风险倒置与评估地位跃迁；每个模型代际重审一遍，纹丝不动的子集才是学科骨架 |\n\n## 写作方向参考\n\n- 机械化执行的边界在哪？过度 lint 是否会限制智能体创造性？\n- Harness Engineering vs Vibe Coding：本质区别是什么？\n- \"零手写代码\"是刻意的实验约束，还是可推广的工程实践？\n- Context Engineering vs Harness Engineering：边界与关系\n\n## 下一步\n\n有了自己的观点后，去 [practice/](../practice/) 用实验验证它。\n","references/articles.md":"# 文章索引\n\n> **本文件是文章索引与计数的唯一权威源（single source of truth）。**\n>\n> **计数规则（machine-checkable）：**\n> 一篇文章 = 一个 `### N. {标题}` 形式的编号小节，且不属于本文末尾的\"已跟踪产品 / 项目\"段落。\n> 占位条目（\"未找到 / 待补充\"）**不写在编号正文里**，而是统一进 `references/AGENTS.md` 的\"待补充\"列表，避免污染计数。\n> 全局连续编号（不按脉络重置），最大编号 = 文章总数。\n>\n> **下游引用都是本文的冗余缓存：** 根 `README.md` / `README.en.md` 的 badge、`prompts/deep-research-tracker.md` 的去重清单、`references/AGENTS.md` 的概览表。\n> 新增/删除文章时，必须**同一次提交**更新本文 + 所有下游缓存。\n>\n> 当前规模：**79 篇文章**（脉络一 75 + 脉络二 2 + 脉络三 2）+ **1 项已跟踪产品**（不计入文章数）。最近一次同步：2026-08-27。\n\n## 脉络一：AI 时代的 Harness Engineering（大模型护栏与认知工程）\n\n\n\n### 1. OpenAI 官方 — 原点与哲学\n\n- **标题：** Harness engineering: leveraging Codex in an agent-first world\n- **链接：** [openai.com](https://openai.com/zh-Hans-CN/index/harness-engineering/)\n- **作者：** Ryan Lopopolo | **日期：** 2026-02-11\n- **核心：** 3 人团队用 Codex 从空仓库到 100 万行代码，零手写代码。提出六大概念：仓库即记录系统、地图而非手册、机械化执行、智能体可读性、吞吐量改变合并理念、熵管理。\n- **关联：** 本仓库的学习起点，所有概念笔记的来源\n\n\n\n### 2. Martin Fowler / Birgitta Böckeler — 系统性认知与控制论框架\n\n- **标题：** Harness engineering for coding agent users\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/harness-engineering.html)\n- **翻译：** [works/fowler-harness-engineering-full-translation.md](../works/fowler-harness-engineering-full-translation.md)\n- **前传备忘录：** [first thoughts](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html) | **备忘录翻译：** [works/fowler-harness-engineering-memo-translation.md](../works/fowler-harness-engineering-memo-translation.md)\n- **作者：** Birgitta Böckeler (Thoughtworks) | **日期：** 2026-04-02（备忘录 2026-02-17）\n- **核心：** 控制论视角的 harness 框架——Guides（前馈）× Sensors（反馈）+ Computational（计算性）× Inferential（推理性）的 2×2 矩阵，三个规制维度，Ashby 必要多样性定律\n\n- **核心框架：Guides × Sensors + Computational × Inferential**\n\n| | 计算性（确定性，CPU） | 推理性（语义，LLM） |\n|--|---------|---------|\n| **引导器（前馈）** | bootstrap 脚本、OpenRewrite、LSP | AGENTS.md、Skills、architecture.md |\n| **传感器（反馈）** | linter、ArchUnit、类型检查、覆盖率 | AI code review、LLM-as-judge |\n\n- **关键原则：**\n - 单独用任何一种都不行——只有反馈 = 反复犯同样的错；只有前馈 = 不知道规则是否生效\n - 计算性控制便宜、确定、每次提交都跑；推理性控制昂贵、概率性、不是每次都跑\n - Harness engineering 是 context engineering 的一种特定形式\n\n- **三个规制维度：**\n\n| 维度 | 成熟度 | 现状 |\n|------|--------|------|\n| 可维护性 Harness | 最成熟 | 计算性传感器可靠捕获结构问题；LLM 部分解决语义问题；**两者都无法可靠捕获**：误诊、过度工程、误解指令 |\n| 架构适应度 Harness | 中等 | 本质是 Fitness Functions——性能 Skills + 可观测性规范 |\n| 行为 Harness | **最弱** | \"房间里的大象\"——功能正确性验证仍依赖 AI 生成的测试，\"目前还不够好\" |\n\n- **Harnessability（可驾驭性）：**\n - 不是所有代码库都同样适合被 harness\n - 强类型语言天然有类型检查传感器；清晰模块边界支持架构约束；成熟框架（如 Spring）隐式提高成功概率\n - **Ambient Affordances**（Ned Letcher）：环境本身的结构属性使智能体更容易操作\n - 绿地项目可以从第一天融入；遗留系统 = **harness 最需要的地方恰恰是最难构建的地方**\n\n- **Harness 模板：**\n - 企业 80% 的服务可归入几种常见拓扑（API 服务、事件处理、数据仪表板）\n - 服务模板 → harness 模板：引导器 + 传感器的集合，约束智能体到特定拓扑\n - 会面临和服务模板一样的分叉/同步挑战，甚至更严重（非确定性组件更难测试）\n\n- **Ashby 必要多样性定律：**\n - 调节器必须至少拥有与被调节系统同等的多样性\n - LLM 能生成几乎任何东西（高多样性）→ 选定拓扑 = 削减多样性 → 全面 harness 变得可行\n - 定义拓扑结构本身就是一种多样性削减举措\n\n- **人类角色的重新定位：**\n - 人类开发者携带隐性 harness：社会问责感、对复杂性的审美痛感、组织记忆、\"我们这里不这么做\"的直觉\n - 智能体没有这些——不知道哪个规范是承重的、哪个只是习惯\n - **\"好的 harness 不应以完全消除人类输入为目标，而应将人类输入引导到最重要的地方\"**\n\n- **质量左移（Shift Quality Left）：**\n - 按速度和成本分布检查：pre-commit 跑便宜传感器，管线跑昂贵传感器\n - 持续漂移传感器：死代码检测、覆盖率质量、依赖扫描、SLO 退化\n\n- **开放挑战：**\n - Harness 连贯性：引导器和传感器增长后可能相互矛盾\n - Harness 覆盖率：类似代码覆盖率，评估 harness 自身的完整性\n - 传感器从未触发时，如何区分高质量 vs 检测不足\n\n- **备忘录独有洞察（正式版未保留）：**\n - \"OpenAI 有既得利益让我们相信 AI 可维护的代码\"——对数据来源的信任保留\n - \"你今天的 harness 是什么？\"——务实的起步问题，审视已有实践\n - \"代码设计本身就是上下文的重要组成部分\"——比框架更本质\n - 最后自嘲预言\"harness\"一词会被滥用\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Guides × Sensors 矩阵 | 对 LangChain 组件清单和 HumanLayer 六杠杆的升维——从\"有什么\"到\"如何协同\" |\n| 行为 Harness 是大象 | 回应自己备忘录中的批评：OpenAI 缺少功能验证 |\n| Harnessability | OpenAI 的\"无聊技术\"选择标准的理论化 |\n| Ashby 定律 | 为 Fowler 假说 2（约束越严，自主性越强）提供控制论根基 |\n| Harness 模板 | 将备忘录假说 1 从问题升级为具体方案 |\n| 人类角色 | 对 Anthropic #7 中人类缺位的直接回应——不应消除人类，应引导人类 |\n\n- **延伸阅读：**\n - [Mitchell Hashimoto: My AI Adoption Journey #Step 5: Engineer the Harness](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness)（已升格为 #29）\n - [Context Engineering for Coding Agents](https://martinfowler.com/articles/context-engineering-coding-agents.html)\n - [Humans and Agents in Software Engineering Loops](https://martinfowler.com/articles/humans-and-agents.html)\n\n\n\n### 3. LangChain / Viv Trivedy — 解剖与机制\n\n- **标题：** The Anatomy of an Agent Harness\n- **链接：** [blog.langchain.com](https://blog.langchain.com/the-anatomy-of-an-agent-harness/)\n- **作者：** Vivek Trivedy | **日期：** 2026-03\n- **核心：** 给出 harness 的精确定义和完整组件清单\n\n> **Agent = Model + Harness**。Harness = 模型之外的一切代码、配置和执行逻辑。\n\n- **组件清单：**\n - System Prompts / Tools / Skills / MCP\n - 沙箱基础设施（文件系统、浏览器）\n - 编排逻辑（子智能体、handoff、模型路由）\n - Hooks/中间件（compaction、续接、lint 检查）\n- **关键洞察：**\n - **Context Rot** — 上下文填满后性能退化，需要 compaction + 工具输出卸载 + 渐进式披露\n - **Ralph Loop** — 拦截退出、重注入提示词、强制在新上下文窗口中继续\n - **Harness 与模型训练耦合** — 模型会 overfit 到特定 harness，换 harness 表现可能暴跌（Terminal Bench 2.0：纯 harness 优化可把排名从 Top 30 拉到 Top 5）\n\n\n\n### 4. Anthropic / Prithvi Rajasekaran — Harness 设计实战（长时自主编码）\n\n- **标题：** Harness design for long-running application development\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/harness-design-long-running-apps)\n- **作者：** Prithvi Rajasekaran (Anthropic Labs) | **日期：** 2026-03-24\n- **核心：** Anthropic 官方工程博客，GAN 启发的三智能体架构实战，从前端设计到全栈自主编码\n\n- **两个核心问题：**\n 1. **Context Anxiety** — 模型接近上下文极限时提前收尾（Sonnet 4.5 尤为明显），compaction 不够，需要 context reset\n 2. **Self-Evaluation 失败** — 智能体评估自己的工作时倾向于过度称赞，即使质量平庸\n\n- **三智能体架构（GAN 启发）：**\n\n| 智能体 | 职责 |\n|--------|------|\n| Planner | 1-4 句提示词 → 完整产品规格（刻意高层级，避免细节错误向下游级联） |\n| Generator | 按 sprint 逐特性实现，React + Vite + FastAPI + SQLite/PostgreSQL |\n| Evaluator | 用 Playwright MCP 实际操作运行中的应用，逐条验证 sprint 合同，打分 + 写详细 critique |\n\n- **Sprint 合同机制：**\n - 每个 sprint 前，Generator 和 Evaluator **协商**\"done 长什么样\"\n - Generator 提议构建内容和验证标准，Evaluator 审核\n - 双方迭代达成一致后才开始编码\n - 解决了 spec 太高层级 → 实现不可验证的 gap\n\n- **评估标准（前端设计 4 维度）：**\n 1. Design Quality — 是否有连贯的视觉身份（权重高）\n 2. Originality — 是否有原创设计决策，而非 AI 模板（权重高）\n 3. Craft — 排版、间距、对比度等技术执行（默认就好）\n 4. Functionality — 可用性独立于美学（默认就好）\n\n- **迭代进化（模型升级后的 Harness 瘦身）：**\n\n| 版本 | 模型 | 架构 | 时长 | 成本 |\n|------|------|------|------|------|\n| Solo baseline | Opus 4.5 | 单智能体 | 20 min | $9 |\n| V1 Harness | Opus 4.5 | Planner + Generator(sprint) + Evaluator(per-sprint) | ~6 hr | $200 |\n| V2 Harness | Opus 4.6 | Planner + Generator(无 sprint) + Evaluator(单次 pass) | ~4 hr | $125 |\n\n- **关键经验：**\n - **每个 harness 组件都编码了一个假设**（\"模型不能独立做 X\"），这些假设需要定期重新压测\n - 新模型发布后应精简 harness：去掉不再承重的部分，添加新能力\n - Evaluator 的价值取决于任务是否处于模型能力边界：边界内 → 开销浪费；边界外 → 真正有帮助\n - \"有趣的 harness 组合空间不会随模型改进而缩小——它会移动\"\n\n- **与其他文章的关联：**\n\n| Anthropic 概念 | 对应文章 |\n|---------------|---------|\n| Context Anxiety + Reset | LangChain 的 Context Rot + Ralph Loop |\n| Self-Evaluation 失败 → 分离 Evaluator | HumanLayer 的 Sub-Agent 上下文防火墙 |\n| Sprint 合同 | OpenAI 的执行计划（exec-plans） |\n| 4 维度评分标准 | OpenAI 的 QUALITY_SCORE.md |\n| Harness 瘦身原则 | Fowler 的\"约束越严，自主性越强\" |\n| \"找最简方案，按需增加复杂度\" | HumanLayer 的\"简单开始，按需添加\" |\n\n\n\n### 5. HumanLayer / Kyle — 实践与避坑\n\n- **标题：** Skill Issue: Harness Engineering for Coding Agents\n- **链接：** [humanlayer.dev](https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents)\n- **作者：** Kyle（HumanLayer） | **日期：** 2026-03-12\n- **核心：** 最落地的一篇——六个配置杠杆 + 实战经验\n\n- **六个杠杆：**\n\n| # | 杠杆 | 要点 |\n|---|------|------|\n| 1 | AGENTS.md | 控制在 60 行以内，禁止自动生成 |\n| 2 | MCP Servers | 别连不信任的，工具太多会填满上下文 |\n| 3 | Skills | 渐进式加载，警惕恶意 skill |\n| 4 | Sub-Agents | 上下文防火墙，隔离任务防 context rot |\n| 5 | Hooks | 生命周期脚本，成功静默/失败报错 |\n| 6 | Back-Pressure | 测试/构建/类型检查 = 自我验证回路 |\n\n- **实战经验：**\n\n| 无效 | 有效 |\n|------|------|\n| 预设理想配置 | 简单开始，按需添加 |\n| 装一堆 skill/MCP \"以防万一\" | 团队间分发验证过的配置 |\n| 每次改动跑全量测试 | 优化迭代速度而非首次成功率 |\n| 微调子智能体的工具权限 | 便宜模型做子任务，贵模型做编排 |\n\n- **金句：** \"The model is probably fine. It's just a skill issue.\"\n\n\n\n### 6. Anthropic / Lance Martin — 三大模式与性能数据\n\n- **标题：** Harnessing Claude's intelligence\n- **链接：** [claude.com](https://claude.com/blog/harnessing-claudes-intelligence)\n- **作者：** Lance Martin (Claude Platform Team) | **日期：** 2026-04-02\n- **核心：** 三个构建模式——利用 Claude 已知知识、追问\"我可以停止做什么\"、谨慎设定边界。配合 BrowseComp / Pokemon 等基准数据论证\n\n- **三大模式：**\n\n| 模式 | 核心主张 |\n|------|---------|\n| Use what Claude knows | 通用工具（bash + editor）优于定制工具，随模型升级自然增强 |\n| Ask \"what can I stop doing?\" | 把编排、上下文管理、持久化三个决策权从 harness 交给模型 |\n| Set boundaries carefully | 缓存优化（静态前置）+ 声明式工具提供安全门控与可观测性 |\n\n- **\"停止做什么\"的三个层次：**\n\n| 层次 | 旧假设 | 新做法 | 数据支撑 |\n|------|--------|--------|---------|\n| 编排 | 所有工具结果回流上下文 | 给 Claude 代码执行工具，让它自己过滤/管道 | BrowseComp: Opus 4.6 过滤能力 45.3% → 61.6% |\n| 上下文管理 | 手工预加载任务指令 | Skills 渐进式披露 + context editing 移除过时内容 + 子 Agent 隔离 | BrowseComp: 子 Agent 提升 2.8% |\n| 持久化 | 依赖外部检索基础设施 | Compaction（模型自主总结）+ Memory folder（模型自主写文件） | BrowseComp: Opus 4.6 compaction 达 84%；BrowseComp-Plus: memory folder +6.8% |\n\n- **缓存优化五原则：**\n\n| 原则 | 说明 |\n|------|------|\n| 静态在前，动态在后 | 稳定内容（系统提示词、工具）放前面 |\n| 用消息传递更新 | 追加 `` 而非编辑提示词 |\n| 不切换模型 | 缓存是模型特定的，切换即失效；需要便宜模型用子 Agent |\n| 谨慎管理工具 | 工具在缓存前缀中，增删会使缓存失效；用 tool search 追加 |\n| 更新断点 | 多轮应用中将断点移至最新消息，使用自动缓存 |\n\n- **声明式工具的四个价值：**\n 1. 安全门控 — 不可逆操作（如外部 API）需用户确认\n 2. 过时检查 — 写入工具检测文件自上次读取后是否被修改\n 3. UX 渲染 — 模态窗口展示问题、提供选项、阻塞等待反馈\n 4. 可观测性 — 结构化参数可记录、追踪、重放\n\n- **Pokemon 记忆进化案例：**\n - Sonnet 3.5: 14,000 步后 31 个文件（含重复），仍在第二城镇，记忆 = NPC 对话转录\n - Opus 4.6: 同样步数 10 个文件（按目录组织），3 枚道馆徽章，记忆 = 战术笔记 + 失败经验\n\n- **\"上下文焦虑\"案例：**\n - Sonnet 4.5 接近上下文极限时提前收尾 → 加了 context reset 补偿\n - Opus 4.5 天然消除了此行为 → context reset 变成死重\n - 启示：harness 中的补偿机制会随模型进化变成性能瓶颈\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 通用工具 > 定制工具 | OpenAI 原文的 bash + editor 起源 |\n| Skills 渐进式披露 | LangChain 的 Progressive Disclosure、HumanLayer 的 Skills 杠杆 |\n| Compaction + Memory folder | LangChain 的 Context Rot 解法、Anthropic #4 的 Context Anxiety |\n| 声明式工具 vs bash | HumanLayer 的 Back-Pressure 杠杆 |\n| \"停止做什么\" | Anthropic #4 的 Harness 瘦身原则、Fowler 的假说 |\n| 缓存优化 | 本仓库新增维度——此前文章未深入讨论 API 层成本优化 |\n\n\n\n### 7. Anthropic / Lance Martin, Gabe Cemaj, Michael Cohen — Meta-Harness 与基础设施解耦\n\n- **标题：** Scaling Managed Agents: Decoupling the brain from the hands\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/managed-agents)\n- **作者：** Lance Martin, Gabe Cemaj, Michael Cohen | **日期：** 2026-02-04\n- **翻译：** [works/anthropic-managed-agents-translation.md](../works/anthropic-managed-agents-translation.md)\n- **核心：** 不再讨论\"如何设计 harness\"，而是追问\"如何让 harness 本身成为可替换的基础设施\"——提出 meta-harness 概念\n\n- **三个虚拟化组件（借鉴操作系统）：**\n\n| 组件 | 类比 | 接口 |\n|------|------|------|\n| Session | 文件系统 | `emitEvent(id, event)`, `getEvents()`, `getSession(id)` |\n| Harness | 进程 | `wake(sessionId)` — 无状态，可随时替换 |\n| Sandbox | I/O 设备 | `execute(name, input) → string`, `provision({resources})` |\n\n- **Pets vs Cattle 演进：**\n - 耦合设计：session + harness + sandbox 在同一容器 → 容器 = 宠物，故障即丢失\n - 解耦设计：三组件独立 → 全部是牲畜，可独立故障和替换\n\n- **安全边界（结构性隔离）：**\n - Git：访问令牌在沙箱初始化时注入 remote，智能体不触碰令牌\n - 自定义工具：OAuth 令牌在 vault 中，通过 MCP proxy 调用，harness 永不接触凭证\n - 核心原则：**令牌永远不可从沙箱内访问**\n\n- **Session 作为外部上下文存储：**\n - 上下文不再是 harness 内的不可逆决策（compaction/trimming）\n - Session 日志持久存储完整事件流，`getEvents()` 按需切片取回\n - 上下文转换（缓存优化、上下文工程）在 harness 层做，与存储层分离\n\n- **性能数据：**\n\n| 指标 | 改善 |\n|------|------|\n| p50 TTFT | ~60% 下降 |\n| p95 TTFT | >90% 下降 |\n\n- **多大脑、多双手：**\n - 多大脑：无状态 harness 按需启动，容器仅在工具调用时配置\n - 多双手：每双手 = `execute(name, input) → string`，harness 不关心手是容器、手机还是宝可梦模拟器\n - 大脑之间可以互相传递双手\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Harness 假设过时 | Anthropic #4 的 Harness 瘦身、#6 的\"停止做什么\" |\n| Pets vs Cattle | 经典 DevOps 概念，Harness.io 脉络的核心 |\n| Session 外部存储 | LangChain 的 Context Rot、Anthropic #6 的 Compaction |\n| Meta-harness | Fowler 的假说 1：\"Harness 将成为未来的服务模板\" |\n| 安全边界解耦 | HumanLayer 的 MCP 信任边界 |\n| 多大脑多双手 | OpenAI 原文的并发 + 吞吐量理念 |\n\n\n\n### 8. Fowler / Rahul Garg — 编码团队标准：缩减 AI 辅助开发的摩擦\n\n- **标题：** Encoding Team Standards\n- **系列：** Patterns for Reducing Friction in AI-Assisted Development\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html)\n- **翻译：** [works/fowler-encoding-team-standards-translation.md](../works/fowler-encoding-team-standards-translation.md)\n- **作者：** Rahul Garg (Thoughtworks) | **日期：** 2026-04-01\n- **核心：** 将团队隐性编码标准显式化为可机器执行的规范，从自然语言 → 示例 → 自动化检查三层渐进\n- **关键洞察：**\n - 团队标准分三类：语言/框架惯用法、项目特有约定、架构决策\n - 编码路径：口头约定 → AGENTS.md/prompts 中的自然语言描述 → 带示例的结构化指令 → lint 规则/自动化检查\n - 不是所有标准都值得完全自动化——按违反频率和影响决定投资\n- **与其他文章关联：** Fowler #2 的 Guides×Sensors 框架的实操手册；HumanLayer 的 AGENTS.md 杠杆的深化\n\n\n\n### 9. Fowler / Rahul Garg — 反馈飞轮：缩减 AI 辅助开发的摩擦\n\n- **标题：** Feedback Flywheel\n- **系列：** Patterns for Reducing Friction in AI-Assisted Development\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html)\n- **翻译：** [works/fowler-feedback-flywheel-translation.md](../works/fowler-feedback-flywheel-translation.md)\n- **作者：** Rahul Garg (Thoughtworks) | **日期：** 2026-04-01\n- **核心：** 构建从 AI 失败中持续学习的反馈闭环——观察失败 → 根因分析 → 编码修复 → 验证效果 → 迭代\n- **关键洞察：**\n - 反馈飞轮四步：发现模式 → 诊断根因 → 系统性修复（而非一次性补丁）→ 衡量改善\n - 与 Encoding Team Standards 形成闭环：标准编码 → 违反检测 → 反馈 → 标准演进\n - 团队级别的 harness 不是一次性设计，而是持续演进的活系统\n- **与其他文章关联：** Anthropic #4 的\"每个 harness 组件编码一个假设\"理念的运营化；YDD 的安灯绳验证闭环\n\n\n\n### 10. LangChain — 智能体评估就绪清单\n\n- **标题：** Agent Evaluation Readiness Checklist\n- **链接：** [blog.langchain.com](https://blog.langchain.com/agent-evaluation-readiness-checklist/)\n- **翻译：** [works/langchain-agent-evaluation-checklist-translation.md](../works/langchain-agent-evaluation-checklist-translation.md)\n- **作者：** LangChain 团队 | **日期：** 2026-04-08\n- **核心：** 从零到一构建智能体评估体系的分阶段清单——定义 → 数据集 → 评估器 → 实验 → 持续集成\n- **关键洞察：**\n - 评估五阶段：定义成功标准 → 构建评估数据集 → 选择评估器 → 运行实验 → CI 集成\n - 数据集构建方法论：从生产日志中提取真实案例，比合成数据更有价值\n - LLM-as-judge 的校准：需要人类标注作为锚点，定期重新校准\n - 评估不是一次性的，而是随智能体演进持续更新的\n- **与其他文章关联：** Fowler #2 的 Sensors 维度的系统化实操；Anthropic #4 的 Evaluator 角色的方法论基础\n\n\n\n### 11. Meta-Harness 论文 — 自动化 Harness 优化\n\n- **标题：** Meta-Harness: End-to-End Optimization of Model Harnesses\n- **链接：** [arxiv.org](https://arxiv.org/abs/2603.28052)\n- **翻译：** [works/meta-harness-paper-translation.md](../works/meta-harness-paper-translation.md)\n- **作者：** Yoonho Lee, Roshen Nair 等 (Stanford, KRAFTON, MIT) | **日期：** 2026-03-30\n- **核心：** 用编码智能体作为提议器，通过文件系统访问完整搜索历史（代码+轨迹+分数），自动搜索最优 Harness\n- **关键洞察：**\n - 外循环搜索：提议器检查先前 Harness 的源代码和执行轨迹，进行因果推理后提出改进\n - 文本分类任务上比 ACE 高 7.7pp，上下文 token 减少 4×\n - IMO 难度数学问题上，发现的检索 Harness 跨 5 个留出模型泛化，平均提升 4.7pp\n - TerminalBench-2 上超越手工工程化的 Terminus-KIRA\n - 核心发现：完整执行轨迹访问 > 压缩摘要 > 仅标量分数（消融实验）\n- **与其他文章关联：** Anthropic #7 的 meta-harness 概念的学术实现；Fowler #2 的 Sensors 的极致自动化——连 harness 本身的设计也变成可搜索的\n\n\n\n### 12. GitHub / Tyler McGoffin — 智能体驱动开发实战\n\n- **标题：** Agent-driven development in Copilot Applied Science\n- **链接：** [github.blog](https://github.blog/ai-and-ml/github-copilot/agent-driven-development-in-copilot-applied-science/)\n- **翻译：** [works/github-agent-driven-development-translation.md](../works/github-agent-driven-development-translation.md)\n- **作者：** Tyler McGoffin (GitHub Copilot Applied Science) | **日期：** 2026-03-31\n- **核心：** 用编码智能体构建智能体，自动化自身工作的实战叙述；Copilot SDK + MCP + Skills 的具体使用模式\n- **关键洞察：**\n - 智能体驱动开发的三阶段演进：手动 → 半自动 → 全自动\n - 关键经验：好的提示词比好的代码更重要；智能体需要明确的约束和验证循环\n - Copilot CLI 作为日常工具的实际工作流\n- **与其他文章关联：** OpenAI 原文的\"工程师不再写代码\"理念的一线实践验证\n\n\n\n### 13. Inside the Scaffold 论文 — 编码智能体脚手架的源代码级分类法\n\n- **标题：** Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures\n- **链接：** [arxiv.org](https://arxiv.org/html/2604.03515v1)\n- **翻译：** [works/inside-the-scaffold-paper-translation.md](../works/inside-the-scaffold-paper-translation.md)\n- **作者：** Benjamin Rombaut (Huawei Canada) | **日期：** 2026-04-04\n- **核心：** 对 13 个开源编码智能体的脚手架代码进行源代码级分析，提出 12 维度 × 3 层次的架构分类法\n- **关键洞察：**\n - 五种循环原语（ReAct、生成-测试-修复、计划-执行、多次重试、树搜索）是可组合的构建块，11/13 智能体组合多种原语\n - 维度在外部约束主导处收敛（工具类别、编辑格式、执行隔离），在开放设计问题处发散（上下文压缩、状态管理、多模型路由）\n - 工具数量从 0（Aider）到 37（Moatless Tools），但底层能力类别趋同：读取、搜索、编辑、执行\n - 上下文压缩涵盖七种策略：截断、摘要、滑动窗口、事件溯源、浓缩、选择性包含、无压缩\n- **与其他文章关联：** 为 Fowler #2 的 Guides×Sensors 框架提供了 13 个实际系统的实证数据；Meta-Harness 论文搜索空间的具体化——展示了 harness 设计选择的巨大多样性\n\n\n\n### 14. ⭐ Lalit Maganti — 渴望八年，用 AI 三个月造出来\n\n- **标题：** Eight years of wanting, three months of building with AI\n- **链接：** [lalitm.com](https://lalitm.com/post/building-syntaqlite-ai/)\n- **翻译：** [works/maganti-eight-years-building-ai-translation.md](../works/maganti-eight-years-building-ai-translation.md)\n- **作者：** Lalit Maganti | **日期：** 2026-04-05\n- **核心：** 资深工程师（Chrome/Android 性能团队）用 AI 编码智能体从零构建 syntaqlite（SQLite 开发工具）的完整复盘——250 小时，3 个月，坦诚记录 AI 的帮助与局限\n- **关键洞察：**\n - AI 是实现的力量倍增器，但不能替代设计——缺乏品味、历史感和用户直觉\n - 实际经验：AI 在 well-constrained 的任务上卓越（测试编写、重构、API 实现），在需要判断力的任务上失败（架构决策、API 设计、性能优化）\n - \"vibe coding\" 对严肃项目不可行——必须理解 AI 生成的每一行代码\n - 模型能力进化的真实感受：Claude 3.5 → Sonnet 4.5 → Gemini 2.5 Pro 的逐步改善\n - **与我们的实践高度一致**\n- **与其他文章关联：** YDD 的\"洗衣机悖论\"的一手证据——省出的时间投入到了更高层的设计工作中；Anthropic #4 的\"每个 harness 组件编码一个假设\"的个人体验版\n\n\n\n### 15. LangChain / Harrison Chase — 智能体的持续学习\n\n- **标题：** Continual learning for AI agents\n- **链接：** [blog.langchain.com](https://blog.langchain.com/continual-learning-for-ai-agents/)\n- **翻译：** [works/langchain-continual-learning-translation.md](../works/langchain-continual-learning-translation.md)\n- **作者：** Harrison Chase (LangChain CEO) | **日期：** 2026-04-05\n- **核心：** 智能体的学习发生在三个层次：模型权重、Harness、上下文——理解区别改变你构建持续改进系统的方式\n- **关键洞察：**\n - 三层学习：模型层（微调/RL）→ Harness 层（提示词/工具/编排逻辑演进）→ 上下文层（运行时记忆/少样本示例）\n - Harness 层学习最被低估：通过分析执行轨迹迭代改进 harness，而非仅改模型\n - 上下文层学习最灵活：用户级记忆、后台整合、跨会话学习\n - Deep Agents 框架支持生产级持续学习\n- **与其他文章关联：** Meta-Harness 论文的 harness 层自动化学习的框架化阐述；Fowler #9 反馈飞轮在智能体层面的体现\n\n\n\n### 16. OpenAI 官方 — 任务跟踪器作为控制平面（Symphony）\n\n- **标题：** An open-source spec for Codex orchestration: Symphony\n- **链接：** [openai.com](https://openai.com/index/open-source-codex-orchestration-symphony/)\n- **翻译：** [works/openai-codex-symphony-translation.md](../works/openai-codex-symphony-translation.md)\n- **作者：** Alex Kotliarskyi, Victor Zhu, Zach Brock | **日期：** 2026-04-27\n- **核心：** 把 Linear 这类问题跟踪器变成智能体编排的控制平面——每个打开的 ticket 映射一个智能体工作区，Symphony 保证未完成任务始终有智能体在跑。Symphony 本体只是一份 `SPEC.md`+`WORKFLOW.md`，参考实现用 Elixir，作者鼓励使用者把 spec 交给自己的编码智能体生成本地实现。\n- **关键洞察：**\n - **从交互式会话到 ticket 级编排**：人类瓶颈不在写代码，而在管理 3-5 个并发 Codex 会话的上下文切换；把 issue tracker 当状态机后，瓶颈转移到智能体的目标空间\n - **目标 vs 状态转换**：早期把智能体当状态机里的刚性节点不奏效；最终转向\"给目标 + 工具 + 上下文，让它自己推理\"\n - **代码免费 → 按语言优势选语言**：参考实现用 Elixir 是因为其并发能力强；同一份 SPEC.md 用 TS/Go/Rust/Java/Python 都能实现成功，多语言实现反过来打磨规范本身\n - **探索成本接近零**：PM/设计师可直接提交 ticket 拿到带演示视频的 review packet，扩大了\"谁能发起工程工作\"的边界\n - **数据点**：部分团队前三周已落地 PR 数量 +500%；发布后 4 月 23 日仓库 15K+ stars\n- **与其他文章关联：** OpenAI 原文 #1 的\"map not manual\"在 SPEC.md 模式下的极致——map 不仅给智能体看，也给社区使用者作为构建模板；HumanLayer #5 的\"AGENTS.md 杠杆\"在工作流层面的扩展（`WORKFLOW.md` 显式化原本隐式的人类流程）；与 thinking 洞见 7 的\"技术栈收敛\"形成反例\n- **实施参考：** [openai/symphony](https://github.com/openai/symphony) | [SPEC.md](https://github.com/openai/symphony/blob/main/SPEC.md)\n\n\n\n### 17. Vikash Rungta — Claude Code 架构（逆向工程版）\n\n- **标题：** Claude Code Architecture (Reverse Engineered)\n- **链接：** [vrungta.substack.com](https://vrungta.substack.com/p/claude-code-architecture-reverse)\n- **翻译：** [works/claude-code-architecture-reverse-translation.md](../works/claude-code-architecture-reverse-translation.md)\n- **作者：** Vikash Rungta | **日期：** 2025-11-01\n- **性质：** 外部逆向分析，非 Anthropic 官方架构文档\n- **核心：** 把 Claude Code 解释为模型无关的本地运行外壳：模型负责推理，外壳提供 shell、文件系统、工具原语、记忆、权限、hooks、MCP、skills、子智能体和智能体团队，把自主循环约束在可治理边界内。\n\n- **关键洞察：**\n - **从工作流到循环：** 从代码控制模型的 DAG，转向模型控制行动的 TAOR（Think-Act-Observe-Repeat）循环；运行时保持简单，智能尽量留给模型。\n - **原语工具胜过专用集成：** Bash、Grep、Edit、Read 这类通用能力原语，比大量脆弱的垂直插件更能覆盖真实工程工作流。\n - **上下文是一种稀缺资源：** 自动压缩、子智能体隔离、语义工具搜索和 forked context 都是在管理上下文预算，避免上下文坍缩。\n - **权限就是产品体验：** plan/default/acceptEdits/dontAsk/bypassPermissions 这类信任光谱，把安全、速度和企业采用门槛合在一起。\n - **Harness 应随模型变薄：** 模型能力提升后，硬编码脚手架应被删除或下沉为确定性 hook，而不是持续堆复杂度。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Claude Code 作为 Harness 的产品化样本 | #3 LangChain 的 Agent = Model + Harness 公式 |\n| 子智能体与智能体团队 | #13 Inside the Scaffold 的子智能体委托分类、#16 Symphony 的 ticket 级编排 |\n| hooks 作为确定性护栏 | #2 Fowler Guides×Sensors、#5 HumanLayer 六杠杆 |\n| 模型升级时删除代码 | #4 Anthropic Harness 瘦身、#6 Anthropic/Claude Platform 的\"停止做什么\" |\n| Claude Code 专有实现的外部观察 | 弥补 #13 因 Claude Code 非开源而无法纳入源代码分类法的空白 |\n\n> 注：Chachamaru127 / claude-code-harness 早期曾占据 #16 文章位，现已迁至本文末尾的\"已跟踪产品 / 项目\"段落（不计入文章数）。\n\n\n\n### 18. 马东锡 NLP — Harness 系列文章之 7：关于 subagent\n\n- **标题：** Harness 系列文章之 7：关于 subagent\n- **链接：** [x.com](https://x.com/dongxi_nlp/status/2068922428516892998)\n- **原文收录：** [works/dongxi-subagent-original.md](../works/dongxi-subagent-original.md)\n- **作者：** 马东锡 NLP (@dongxi_nlp) | **日期：** 2026-06-22\n- **核心：** 把 subagent 从\"小号智能体\"重新定义为 parent session 通过一次 tool call 拉起的 managed child runtime：外层是 `spawn_agent` / `/delegate` tool call，内层是新的 child session 和被选择过的 context projection。\n\n- **关键洞察：**\n - **Tool call outside, runtime inside：** subagent 的启动入口是 tool call；tool call 之后，Harness 的世界状态里多了一个 child runtime。\n - **Session ≠ Context：** session 是 runtime container，包含 thread、transcript、tools、permissions、resources、status、artifacts；context 是某次 model call 可见的 projection。\n - **Shared resources 不等于 shared transcript：** child 可以继承 tools、skills、AGENTS.md、MCP servers、cwd、sandbox、permissions，但不自动继承 parent 的完整对话历史。\n - **三种投影策略：** fresh child、forked child、partial fork 分别对应不同上下文继承强度；partial fork 是避免 parent history 噪声的实用中间态。\n - **更多 agents = 更多 runtime state：** 多智能体不是免费并行，Harness 必须追踪谁在工作、知道什么、改了什么、何时完成，以及结果如何变成 evidence。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| child session 与 context projection | #7 Anthropic Managed Agents 的 Session/Harness/Sandbox 解耦 |\n| subagent 作为上下文隔离机制 | #17 Claude Code 架构逆向中的隔离 TAOR 循环与 summary return |\n| fresh/forked/partial fork | #6 Anthropic/Claude Platform 的 context editing、sub-agent 隔离与缓存前缀管理 |\n| evidence 回流与 runtime state | #16 OpenAI Symphony 的任务跟踪器控制平面、#13 Inside the Scaffold 的委托分类 |\n\n- **本仓库笔记：** [thinking/subagent-is-child-runtime.md](../thinking/subagent-is-child-runtime.md)\n\n---\n\n\n\n### 19. Fowler / Birgitta Böckeler — 面向编码智能体的可维护性传感器\n\n- **标题：** Maintainability sensors for coding agents\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/sensors-for-coding-agents.html)\n- **中文译文：** [works/fowler-sensors-translation.md](../works/fowler-sensors-translation.md)\n- **作者：** Birgitta Böckeler | **日期：** 2026-05-20\n- **核心：** Böckeler 从一个真实 TypeScript/NextJS 应用出发，系统梳理\"计算性 vs 推理性\"传感器谱系（type checker、ESLint、Semgrep、dependency-cruiser、mutation testing、耦合分析、AI 模块化评审），并诚实记录失败案例（耦合数据对 AI\"乏善可陈\"、把合理的 DI factory 误判为 god module）。\n\n- **关键洞察：**\n - **传感器 = 反馈控制隐喻：** lint message 写成\"自我修正指导\"（prompt injection 式提示），让 agent 读到反馈即自纠。\n - **计算性 vs 推理性：** 确定性检查（type/lint/依赖图）与需要判断的检查（模块化、耦合）是两类不同传感器，可靠度与误报率不同。\n - **AI 模块化评审 = 垃圾回收：** 作者明确把它称为 garbage collection——周期性识别并清理结构腐化。\n - **诚实的负面结果：** 不是所有传感器都有用，耦合指标对 AI 收效甚微，记录失败本身是这篇的价值。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Guides × Sensors 框架的实操续篇 | #2 Fowler 的控制论矩阵 |\n| 机械化执行（custom linter > 文档） | 概念 3 机械化执行 |\n| AI 评审作为垃圾回收 | 概念 6 熵与垃圾回收 |\n\n- **本仓库笔记：** [thinking/guides-sensors-meets-claude-code-harness.md](../thinking/guides-sensors-meets-claude-code-harness.md)\n\n---\n\n\n\n### 20. Fowler / Wei Zhang, Jessie Jie Xia — 结构化提示驱动开发（SPDD）\n\n- **标题：** Structured-Prompt-Driven Development (SPDD)\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/structured-prompt-driven/)\n- **中文译文：** [works/fowler-spdd-translation.md](../works/fowler-spdd-translation.md)\n- **作者：** Wei Zhang, Jessie Jie Xia（Martin Fowler 编辑） | **日期：** 2026-04-28\n- **核心：** 一套把提示词当一等版本化交付物的半自动 Harness：提出 REASONS Canvas 七维结构（R/E/A/S/O/N/S），主张\"先修提示词再改代码、重构则反向同步 spdd-sync\"的双向闭环。文末附 13 组高质量自问自答。\n\n- **关键洞察：**\n - **Prompt 是合同，Plan 是建议：** 把结构化提示词版本化、可审查，作为变更的承重结构。\n - **双向闭环：** 现实偏离 spec 时先改 prompt 再改代码；人工重构后用 spdd-sync 反向同步回 prompt，防止提示词漂移。\n - **SPDD 本身就是一个 Harness：** 把上下文、约束、审查、同步全部显式化。\n - **诚实承认边界：** \"人类判断仍然是承重结构\"，模型无关、不替代审查。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Prompt 即一等可版本化交付物 | #16 OpenAI Symphony 的约束即产品、延伸概念 07-spec-as-product |\n| REASONS Canvas 七维结构 | 概念 2 地图而非手册 + 渐进式披露 |\n| spdd-sync 反向同步防漂移 | 概念 3 机械化执行、#9 反馈飞轮 |\n\n---\n\n\n\n### 21. LangChain / Harrison Chase — 智能体开发生命周期（ADLC）\n\n- **标题：** The Agent Development Lifecycle (ADLC)\n- **链接：** [langchain.com](https://www.langchain.com/blog/the-agent-development-lifecycle)\n- **中文译文：** [works/langchain-adlc-translation.md](../works/langchain-adlc-translation.md)\n- **作者：** Harrison Chase | **日期：** 2026-05-09\n- **核心：** 提出 Build → Test → Deploy → Monitor + Iterate + Govern 的完整智能体开发生命周期，把 framework / runtime / harness 三层做了清晰区分，治理段拆出 cost / tool access / discoverability。是方法论级别的总览型骨架文。\n\n- **关键洞察：**\n - **framework / runtime / harness 三分类：** 与本仓库主题命名正面对齐——harness 是约束与反馈层，runtime 是执行容器，framework 是编排库。\n - **生命周期是闭环：** Monitor 产出的轨迹回流到 Iterate，把一次性 demo 变成可重复、可评测、可运营的工程。\n - **Govern 作为一等维度：** 成本、工具访问、可发现性被显式纳入治理。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| framework/runtime/harness 三层 | #6 Anthropic 三大模式、#17 Claude Code 架构逆向 |\n| Monitor → Iterate 反馈回路 | #2 Fowler Sensors、概念 3 机械化执行 |\n| Govern / 治理维度 | 概念 6 熵与垃圾回收 |\n\n---\n\n\n\n### 22. LangChain / Hunter Lovell — Deep Agents 中的解释器\n\n- **标题：** Interpreters in Deep Agents: Code Between Tool Calls and Sandboxes\n- **链接：** [langchain.com](https://www.langchain.com/blog/give-your-agents-an-interpreter)\n- **中文译文：** [works/deep-agents-interpreter-translation.md](../works/deep-agents-interpreter-translation.md)\n- **作者：** Hunter Lovell | **日期：** 2026-05-20\n- **核心：** 提出 interpreter 是介于串行工具调用与完整沙箱之间的\"第三层\"，interpreter state 是继 message history、filesystem 之后的\"第三类上下文表面\"。给出 35% token 节省实测，以及 QuickJS / 桥接 / 运行时控制的实现细节。\n\n- **关键洞察：**\n - **上下文表面分层：** message history / filesystem / interpreter state 是三类不同的 context surface，各自有不同的读写与投影方式。\n - **设计上更受限是主动选择：** interpreter 主动收窄能力（而非能力不足），用受限运行时换取可控与可读。\n - **35% token 节省：** 让智能体写代码协调工具、保存中间态，只把相关结果送入模型上下文。\n - **横向连接：** 呼应 Cloudflare Code Mode、Anthropic PTC、RLM。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 受限运行时即机械约束 | 概念 3 机械化执行、概念 4 智能体可读性 |\n| 上下文表面 / context surface 分层 | #6 Anthropic context editing、#18 subagent 的 context projection |\n| 用代码协调工具以省上下文 | #16 OpenAI Symphony 控制平面 |\n\n---\n\n\n\n### 23. Anthropic / 工程团队 — Claude Code 质量回归复盘\n\n- **标题：** An update on recent Claude Code quality reports\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/april-23-postmortem)\n- **中文译文：** [works/anthropic-postmortem-translation.md](../works/anthropic-postmortem-translation.md)\n- **作者：** Anthropic 工程团队 | **日期：** 2026-04-23\n- **核心：** 对三起独立的 Claude Code 质量回归逐项复盘——(1) 默认 reasoning effort 从 high 降到 medium 的产品取舍；(2) clear_thinking 缓存优化 bug（本应只清一次却每轮都清，导致\"健忘/重复/乱用工具\"并拖垮缓存命中）；(3) 一条 system prompt 限长指令（≤25/≤100 词）压垮编码智能。三个变更各打不同流量切片、不同时间表，叠加成\"广泛而不一致的退化\"。是仓库稀缺的第一手失败案例。\n\n- **关键洞察：**\n - **变更评估的经典陷阱：** 三个变更各自通过人审 + 自动审 + 单测 + e2e + dogfooding，仍全部漏网。\n - **system prompt 即受控产物：** 一条限长指令就能压垮编码智能，提示词必须纳入评测与审计。\n - **现成的治理清单：** 文末\"后续计划\"（per-model eval 套件、消融、soak period、渐进发布、prompt 审计工具）几乎是一份 harness 变更治理清单。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 机械化执行的盲区（多层审查仍漏网） | 概念 3 机械化执行、#2 Fowler Sensors |\n| system prompt 即受控产物 | 延伸概念 07-spec-as-product、#16 Symphony |\n| 反例 / 事故复盘（稀缺类型） | 仓库 works/ 多为正面理论，本篇为第一手反面教材 |\n\n---\n\n\n\n### 24. 林家航 等 / 复旦·北大·奇绩智锋 — Agentic Harness Engineering（论文）\n\n- **标题：** Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses\n- **链接：** [arxiv.org/html/2604.25850v4](https://arxiv.org/html/2604.25850v4)\n- **中文译文：** [works/arxiv-agentic-harness-engineering-translation.md](../works/arxiv-agentic-harness-engineering-translation.md)\n- **作者：** Jiahang Lin, Shichun Liu, Chengjun Pan 等（复旦 / 北大 / 奇绩智锋） | **日期：** 2026-05-18 | **arXiv：** 2604.25850 v4\n- **核心：** 提出 AHE 闭环——在固定基础模型下，通过组件、经验、决策三类可观测性让 Harness 自动演化：可编辑组件文件化，轨迹压缩为可下钻证据，每次编辑附带可证伪预测。Terminal-Bench 2 上 pass@1 从 69.7% 提升到 77.0%，超过 Codex-CLI，并在 SWE-bench-verified 与跨模型迁移中保持收益。\n\n- **关键洞察：**\n - **每次 Harness 编辑 = 可证伪契约：** 把 harness 优化从经验调参变成可验证的研究问题。\n - **三类可观测性：** 组件 / 经验 / 决策，构成分层可下钻的证据语料库。\n - **诚实报告局限：** 回归失明、组件非加性交互——优化并非单调可加。\n - **直接引用仓库源头：** 参考文献含 OpenAI Harness Engineering、Anthropic harness design、LangChain deep agents。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Harness 自动演化 / meta-harness | #11 Meta-Harness 论文、#7 Anthropic Meta-Harness |\n| 可观测性驱动的闭环 | #2 Fowler Sensors、概念 3 机械化执行 |\n| 编码智能体脚手架分类 | #13 Inside the Scaffold 论文 |\n\n---\n\n\n\n### 25. Yubin Qu 等 — 过度积极的编码智能体（论文）\n\n- **标题：** Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks\n- **链接：** [arxiv.org/html/2605.18583v1](https://arxiv.org/html/2605.18583v1)\n- **中文译文：** [works/arxiv-overeager-coding-agents-translation.md](../works/arxiv-overeager-coding-agents-translation.md)\n- **作者：** Yubin Qu, Ying Zhang, Yanjun Zhang, Gelei Deng, Yuekang Li, Leo Yu Zhang, Yi Liu | **日期：** 2026-05-18 | **arXiv：** 2605.18583 v1\n- **核心：** 定义并测量编码智能体在良性任务中的 overeager actions（完成表面任务却执行用户未授权的读写）。提出 OverEager-Gen/Bench（500 场景、约 7500 次运行、4 个 agent 产品 × 6 模型），用行为梯度验证器与双通道审计栈评估越界率。\n\n- **关键洞察：**\n - **反直觉发现：** 在提示里写明授权范围，会让 agent 从\"推断边界\"退化为\"匹配声明文本\"——Claude Code 去掉 consent 声明后越界率 0.0% → 17.1%。\n - **框架层主导：** permission gating 由框架层决定，模型层对齐不会完整传导到行为。\n - **授权问题是独立类别：** 区别于能力失败、提示注入、沙箱逃逸，是单独的一类风险。\n - **实证支撑机械约束：** 证明约束必须机械强制，靠提示声明反而降低边界推断。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 权限门控 / 边界约束 | #7 Anthropic Managed Agents 沙箱、概念 3 机械化执行 |\n| 提示声明反而降低安全 | #23 Anthropic 复盘的 system prompt 陷阱 |\n| agent 越界的实证测量 | 概念 6 熵与垃圾回收 |\n\n---\n\n\n\n### 26. Chris Parsons — 我是如何用 AI 写代码的\n\n- **标题：** How I Use AI to Code\n- **链接：** [chrismdp.com](https://chrismdp.com/coding-with-ai/)\n- **中文译文：** [works/chris-ai-code-translation.md](../works/chris-ai-code-translation.md)\n- **作者：** Chris Parsons | **日期：** 2026-05（更新版）\n- **核心：** 资深从业者的一手实践复盘。硬区分 Vibe Coding 与\"智能体化工程\"，提出\"从批准者到训练者\"的角色转变，归纳四要素 Harness（常驻指令 / skill files / 验证循环 / 反馈循环），并主张\"spec the problem, not the solution\"。带 7 条带注解脚注（a16z、Karpathy、METR/MIT、Greenblatt serial speed-up 等）。\n\n- **关键洞察：**\n - **Vibe Coding ≠ 智能体化工程：** 前者不真正检查结果，后者是\"有分寸地判断哪些 diff 需要你的眼睛\"。\n - **从批准者到训练者：** 资深工程师的工作不再是审查输出，而是训练 AI——把判断花在哪里本身是资深技能。\n - **四要素 Harness：** 常驻指令、skill files、验证循环、反馈循环；没有反馈循环脚手架会腐化。\n - **反馈是新瓶颈：** 编码本身更快了，但审查/验证/集成/返工变慢，慢工作吞没快工作。\n - **译者注：** 文中 2026 数据/产品断言来自原文及脚注，译者未独立核实（见译文顶部说明）。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 四要素 Harness | #2 Fowler、#5 HumanLayer 六杠杆、概念 2/3（地图而非手册 / 机械化执行） |\n| 反馈循环防腐化 | #9 Fowler 反馈飞轮、#19 Fowler Sensors |\n| 反馈瓶颈 / serial speed-up | #78 YDD 效率悖论 |\n\n---\n\n\n\n### 27. LangChain / Palash Shah — 我们如何构建 LangSmith Engine\n\n- **标题：** How we built LangSmith Engine: our agent for improving agents\n- **链接：** [langchain.com](https://www.langchain.com/blog/how-we-built-langsmith-engine-our-agent-for-improving-agents)\n- **中文译文：** [works/langsmith-engine-translation.md](../works/langsmith-engine-translation.md)\n- **作者：** Palash Shah | **日期：** 2026-05-19\n- **核心：** \"用智能体改进智能体\"的工程复盘。把 trace 压缩成轨迹骨架，用 screener（Haiku 子智能体）/ investigator 两阶段分工，CLI 作为统一接口，构成 issue → evaluator → 回归样本的闭环；issue 创建与 fix 生成分离。\n\n- **关键洞察：**\n - **trace → 轨迹骨架：** 压缩运行轨迹再交给智能体，是\"运行时 → 可观测 → 自动改进\"链条的关键一步。\n - **两阶段分工：** screener 先筛、investigator 再深挖，控制成本与上下文。\n - **闭环：** issue → evaluator → regression example，把一次性诊断变成可回归的适应度函数。\n - **创建与修复分离：** issue 创建和 fix 生成解耦，连接 repo 做 code-aware fix。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 用智能体改进智能体 / meta-harness | #7 Anthropic Meta-Harness、#24 Agentic Harness Engineering |\n| evaluator 作为适应度函数 | #10 LangChain 评估清单、#2 Fowler Sensors |\n| 运行时 → 可观测 → 改进链条 | #21 ADLC、#22 Deep Agents 解释器 |\n\n---\n\n\n\n### 28. Geoffrey Huntley — Ralph：最小可行 Harness 的原始出处\n\n- **标题：** Ralph Wiggum as a \"software engineer\"（2025-07）+ 续篇 everything is a ralph loop（2026-01-17）\n- **链接：** [ghuntley.com/ralph](https://ghuntley.com/ralph/) | [ghuntley.com/loop](https://ghuntley.com/loop/)\n- **作者：** Geoffrey Huntley | **日期：** 2025-07 / 2026-01-17\n- **核心：** Ralph 技术的方法论源头——\"Ralph 在最纯粹的形式下就是一个 bash 循环\"：`while true` 把 PROMPT.md 喂给编码智能体，每轮全新上下文窗口、一轮只做一件事，配背压验证。作者用它从零构建 CURSED 编程语言（训练集中不存在的语言）。本仓库 `practice/` 的 Ralph Demo 与已跟踪的 3 个 Ralph 项目此前一直缺这篇源头文献。\n\n- **关键洞察：**\n - **每轮只做一件事 + 信任模型选事：** 违反直觉的组合——既收窄单轮范围，又把\"什么最重要\"的决策权交给模型\n - **fix_plan.md 是外置状态：** TODO 列表是人类\"像鹰一样盯着\"的对象，构建 CURSED 期间被扔掉重生成多次——计划是耗材\n - **背压（backpressure）：** 改动后只跑该单元的测试；Rust 类型系统虽强但编译慢——\"轮速与正确性轴的平衡\"决定语言选择\n - **单体 vs 多智能体：** \"非确定性的微服务（智能体）= 一团红热的烂摊子\"；Ralph 是单体，单进程垂直扩展、单仓库自治\n - **失败域→工程化修复：** \"看到失败域，戴上工程师帽子把问题解决到永不再犯\"——与 Hashimoto 的 harness engineering 定义同源\n - **续篇的推广：** \"一切皆 ralph loop\"——loop 是通用的上下文工程模式，可用于所有任务；软件是陶轮上的黏土，不对就扔回轮上重塑\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| bash 循环 + 干净上下文 | #3 LangChain 的 Ralph Loop 组件、practice/ Ralph Demo |\n| 背压验证门 | 概念 3 机械化执行、#5 HumanLayer 的 Back-Pressure 杠杆 |\n| 计划是耗材 | README 的 Ralph 六信条 \"The Plan Is Disposable\" |\n| 单体反多智能体论 | #36 dynamic workflows（对照：模型自己写多智能体编排）、#16 Symphony |\n| 观察循环、调音式修复 | #29 Hashimoto 的 harness engineering 定义 |\n\n---\n\n\n\n### 29. Mitchell Hashimoto — 我的 AI 采纳之旅（\"harness engineering\" 命名出处）\n\n- **标题：** My AI Adoption Journey\n- **链接：** [mitchellh.com](https://mitchellh.com/writing/my-ai-adoption-journey)\n- **作者：** Mitchell Hashimoto（HashiCorp 联合创始人，Ghostty 作者） | **日期：** 2026-02-05\n- **核心：** 六步渐进采纳路线：放弃聊天机器人 → 复现自己的工作（手工做一遍再逼智能体做出同质结果）→ 日终智能体 → 外包稳赢任务 → 工程化 harness → 始终有智能体在跑。第 5 步给出了被业界广泛引用的 harness engineering 定义。多方学科史梳理公认本文是该术语的叫响者（与 OpenAI 原文同月）。原为本仓库\"延伸阅读\"，现升格为编号条目。\n\n- **关键洞察：**\n - **定义原文：** \"每当发现智能体犯错，就花时间工程化一个解决方案，使它永远不会再犯这个错误\"——两种形式：隐式提示（AGENTS.md）+ 程序化工具（截图脚本、过滤测试跑器）\n - **Ghostty 的 AGENTS.md 每一行都对应一次真实的坏行为**——与 Osmani \"每行可溯源到一次翻车\"的纪律互证\n - **复现自己的工作：** 刻意做两遍（先手工后智能体）是形成\"什么任务能交给智能体\"直觉的最快途径；效率增益的一半来自知道何时不用智能体\n - **人控制打断时机：** 关掉智能体桌面通知，\"由我决定何时打断它，而不是反过来\"——上下文切换是最贵的成本\n - **克制的自主性：** 一次只跑一个智能体、后台智能体覆盖 10–20% 工作时段；反对为跑而跑——\"只在真正有帮助的任务上跑\"\n - **对冲技能退化：** 委托智能体的同时手工做自己热爱的任务，抵消 Anthropic 技能形成论文指出的风险\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness engineering 定义 | #1 OpenAI 原文（同期独立提出）、#2 Böckeler（引用本文） |\n| 错误工程化=永不再犯 | #9 反馈飞轮的个人版、#28 Ralph 的调音式修复 |\n| AGENTS.md 行行有出处 | #31 Osmani 的约束加减法纪律、#5 HumanLayer 60 行规则 |\n| 何时不用智能体 | #14 Maganti 的能力边界经验、#26 Chris Parsons |\n\n---\n\n\n\n### 30. Claude Code 源码泄漏事件 — 512K 行 harness 的实锤解剖\n\n- **标题：** 事件 + 聚合分析：understanding-claude-code（综合 26 篇文章、7 个 HN 帖、10 份官方 TechDocs）\n- **链接：** [pankaj28843/understanding-claude-code](https://github.com/pankaj28843/understanding-claude-code) | 新闻报道：[InfoQ](https://www.infoq.com/news/2026/04/claude-code-source-leak/)\n- **作者：** 事件（当事人 Chaofan Shou，安全研究员；社区镜像扩散，无单一作者——本条为事件型收录） | **日期：** 2026-03-31（事件日）\n- **事件：** 2026-03-31，`@anthropic-ai/claude-code` v2.1.88 npm 包漏发 59.8MB 的 `cli.js.map`（缺一条 `.npmignore`，叠加 Bun 默认生成 source map 的已知 bug），~512,000 行 TypeScript / ~1,900 文件全裸；安全研究员 Chaofan Shou 发现，数小时内 GitHub 镜像扩散\n- **核心：** 业界第一次看到一线编码智能体 harness 的完整生产级源码。此前 #17（Rungta 逆向）只能从行为推测，泄漏把推测变成了可对照的实锤。\n\n- **实锤细节（此前只能猜测的部分）：**\n - **QueryEngine ~46K 行**：流式响应、工具调用循环、重试、token 追踪；工具可在模型还在流式输出时就开始执行\n - **60+ 权限门控工具（~29K 行 Tool.ts）**：遵循 Ousterhout \"deep modules\" 原则——简单接口藏重能力；\"Anthropic 花在优化工具上的时间超过优化总 prompt\"；工具描述本身是微型提示词\n - **工具结果预算**：BashTool 30K 字符、GrepTool 20K 字符，超额落盘到 `tool-results/{uuid}/` 留预览——上下文管理的机械化实现\n - **14 种缓存破坏向量追踪**（`promptCacheBreakDetection.ts`）：工具表变更、权限模式切换、CLAUDE.md 修改、MCP 连接等——#6 缓存优化五原则的工程落地\n - **未发布功能**：KAIROS 常驻后台 daemon（追加式日报）+ AutoDream 睡眠期记忆整理（727 行，闲时修剪/合并/组织会话记忆）+ Undercover Mode（对外仓库自动抹除内部信息与 AI 署名）\n - **教训**：source map 是被忽视的安全面——`npm pack --dry-run` 应进发布流水线\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 推测 vs 实锤对照 | #17 Rungta 逆向分析（TAOR 循环、权限光谱的推断如今可验证） |\n| 补上闭源样本的空白 | #13 Inside the Scaffold（当时因 Claude Code 闭源无法纳入分类法） |\n| 工具>prompt 的投资优先级 | #6 Anthropic 通用工具主张、概念 4 智能体可读性 |\n| 记忆整理（AutoDream） | #6 Pokemon 记忆进化案例的机制揭底 |\n| 发布流水线事故 | #23 质量回归复盘（同为 Anthropic 工程失误的第一手材料） |\n\n---\n\n\n\n### 31. Addy Osmani — Agent Harness Engineering（学科汇流综合）\n\n- **标题：** Agent Harness Engineering\n- **链接：** [addyosmani.com](https://addyosmani.com/blog/agent-harness-engineering/)（[O'Reilly Radar 2026-05-15 授权转载](https://www.oreilly.com/radar/agent-harness-engineering/)）\n- **第三方中译：** [掘金译文](https://juejin.cn/post/7642753947455356968)（未落盘本仓库）\n- **作者：** Addy Osmani（Google Cloud AI Director） | **日期：** 2026-04-19\n- **性质与破例说明：** 综述性质（同类的 Pachaar 综述归在\"中文转译/二手资料\"段不计数）。破例进编号正文的理由：它不只转述——给出了约束加减法纪律、hooks 分界论等可引用的原创表述，且是\"四学派汇流成一个学科\"的定调文（收藏/点赞比 2:1，读者当文档存）。\n- **核心：** \"编码智能体 = 模型 + 你围绕它构建的一切。Harness engineering 把这套脚手架当真正的工程产物；每当智能体失手，harness 就再收紧一圈。\"把 Trivedy（术语）、Horthy（追踪）、HumanLayer（skill issue）、Anthropic（长时设计）、Böckeler（用户侧）、Hashimoto（命名）缝成一张学科地图。\n\n- **关键洞察：**\n - **失败是可读的（legible）：** 不知道约定→加进 AGENTS.md；跑了破坏性命令→加 hook 拦截；40 步任务迷路→拆 planner/executor；反复\"完成\"坏代码→接 typecheck 背压\n - **约束的加减法纪律：** 只在见过真实失败后加约束，只在模型能力使其冗余后删；\"好的 AGENTS.md 每一行都应能溯源到一次具体翻车\"\n - **hooks 是分界线：** \"我告诉过智能体做 X\" vs \"系统强制执行 X\"——lifecycle 脚本承载永不能忘的事（typecheck/lint/测试、拦 `rm -rf` / force push、PR 前审批、写后自动格式化）\n - **模型与 harness 后训练耦合：** Opus 4.6 在 Claude Code 里的 Terminal Bench 2.0 分数远低于同模型在定制 harness 里；Viv 团队只改 harness 就 Top 30 → Top 5（#35 论文给出了这一现象的统计版本）\n - **HaaS（Harness-as-a-Service）：** 从构建于 LLM API（给 completion）转向构建于 harness API（给 runtime）——Claude Agent SDK / Codex SDK / OpenAI Agents SDK 同向\n - **Ralph Loop 的价值重申：** \"hook 拦截退出、往新上下文窗口重注提示词\"是从\"用更聪明的模型\"永远推导不出来的原语\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 六人六视角的汇流地图 | #3 Trivedy、#5 HumanLayer、#4 Anthropic、#2 Böckeler、#29 Hashimoto |\n| 约束加减法纪律 | #4 harness 瘦身、#29 AGENTS.md 行行有出处 |\n| Terminal Bench harness 效应 | #35 统计归因论文、#3 的原始数据点 |\n| HaaS | #7 Managed Agents、#21 ADLC 的 framework/runtime/harness 三分 |\n| 四学派汇流 | thinking/cross-article-insights 的学派划分 |\n\n---\n\n\n\n### 32. Thoughtworks / Böckeler & Ford — 传感器实验：有无反馈回路的对照\n\n- **标题：** Harness engineering and agent feedback: Exploring AI coding sensors\n- **链接：** [thoughtworks.com](https://www.thoughtworks.com/en-au/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors)\n- **作者：** Birgitta Böckeler, Chris Ford (Thoughtworks) | **日期：** 2026-05-13\n- **核心：** #19（可维护性传感器谱系）的实验化姊妹篇。在一个 TypeScript 数据仪表板上做**有/无传感器套件的对照实验**（ESLint、Semgrep 静态分析 + Dependency Cruiser 模块边界 + 覆盖率报告 + mutation testing），配套视频演示。\n\n- **关键洞察：**\n - **实验结果：** 配备质量反馈传感器的编码智能体能随时间持续改善质量（如提升测试覆盖率）；无传感器则原地踏步\n - **行业失衡诊断：** 2026 上半年业界注意力集中在 skills（前馈），sensors（反馈）被系统性低估——\"完美世界只需前馈；我们不住在那个世界里\"\n - **从叮嘱到保证：** \"反复求智能体写测试并祈祷它够自觉\" → 确定性约束给出保证；LLM 判断适合模糊探索区，客观一致的要求要交给形式化确定性工具\n - **态势感知而非全自动：** \"harness engineering 不是全自动化，而是开发者的态势感知\"——红绿传感器仪表板 = 代码库体检单，指示该把精力再投资到 harness 的哪里\n - **Harness 模板展望：** 未来不再每个项目从头搭 harness，而是按应用类型取用预配置模板（数据仪表板模板、CRUD 业务服务模板）——#2 的 harness 模板假说落到具体形态\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 传感器对照实验 | #19 传感器谱系（同作者的实操续篇） |\n| 前馈/反馈失衡 | #2 Guides×Sensors 框架、#5 六杠杆 |\n| 确定性约束 > 反复叮嘱 | 概念 3 机械化执行、#25 Overeager（提示声明反而降低边界推断） |\n| harness 模板 | #2 的假说 1、#21 ADLC |\n\n---\n\n\n\n### 33. HarnessAudit 论文 — Harness 安全审计（安全面的开辟）\n\n- **标题：** Auditing Agent Harness Safety\n- **链接：** [arxiv.org/abs/2605.14271](https://arxiv.org/abs/2605.14271)\n- **作者：** Chengzhi Liu, Yichen Guo, Yepeng Liu, Yuzhe Yang, Qianqi Yan, Xuandong Zhao, Wenyue Hua, Sheng Liu, Sharon Li, Yuheng Bu, Xin Eric Wang | **日期：** 2026-05 | **arXiv：** 2605.14271\n- **核心：** 开辟本仓库此前完全缺失的维度——**harness 是安全面**。核心观察：harness 可以在\"返回正确且良性的最终答案\"的同时，轨迹中途访问未授权资源、或把上下文泄给错误的智能体——**输出级评估看不见这些失败**，而多数安全基准只给最终输出/终态打分。提出 HarnessAudit 框架（审计完整执行轨迹的边界合规、执行保真、系统稳定三维）+ HarnessAudit-Bench（210 任务 × 8 个真实领域，单/多智能体配置，内嵌安全约束）。\n\n- **关键发现（评测 10 种 harness 配置 × 前沿模型 × 3 个多智能体框架）：**\n - **任务完成与安全执行不对齐**，违规随轨迹长度累积——长时自主运行天然扩大风险\n - 安全风险随领域、任务类型、智能体角色而异\n - 违规集中在**资源访问**与**智能体间信息传递**两类\n - 多智能体协作扩大安全风险面；**harness 设计决定安全部署的上限**\n- **传播语境：** 被转发时的定性——\"业界正在意识到：harness 是产品，也是安全面。该审计的不只是模型，还有 prompt、工具、权限、记忆、执行层。AI 安全的下一个前沿是 harness 安全。\"（#37 作者马东锡转发）\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 中途轨迹违规 vs 输出级评估 | #25 Overeager（越界动作测量——本文把它推进到审计框架） |\n| 权限边界与信息流约束 | #7 Managed Agents 的安全边界解耦、#30 泄漏实锤的权限分类器 |\n| 多智能体扩大风险面 | #18 subagent 的 runtime state 追踪、#36 dynamic workflows 的千级扇出 |\n| harness 决定安全上限 | #37 \"可靠性的东西都属于 harness\" |\n\n---\n\n\n\n### 34. Harness-Bench 论文 — 配置级 harness 效应的诊断基准\n\n- **标题：** Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows\n- **链接：** [arxiv.org/abs/2605.27922](https://arxiv.org/abs/2605.27922)\n- **作者：** Yilun Yao, Xinyu Tan, Chao-Hsuan Liu 等 12 人 | **日期：** 2026-05 | **arXiv：** 2605.27922\n- **核心：** 现有基准要么抽象掉执行层、要么比较完整智能体系统、要么固定 harness——执行层变异一直难以研究。Harness-Bench 用 106 个沙箱离线任务（从实际 agent 使用模式构造，人工审核真实性/可解性/oracle 可检验性/完整性），在共享任务环境、预算与评估协议下评测代表性 harness 配置 × 多模型后端，同时**保留各 harness 的原生执行行为**。\n\n- **关键洞察：**\n - **5,194 条执行轨迹的结论：** 完成率、过程质量、效率、失败行为在 model-harness 配对间差异巨大——**智能体能力应按\"模型-harness 配置\"报告，而非归于基座模型**\n - **执行对齐失败（execution-alignment failures）：** 反复出现的失败类型——貌似合理的推理与工具反馈、工作区状态、证据、可验证输出契约**脱钩**\n - 每次运行记录最终工件、执行轨迹、用量统计、校验器输出——支持超越\"最终完成与否\"的过程分析\n - 直接回应本仓库缺口清单的\"Harness 覆盖率评估方法\"\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 按 model-harness 配置报告能力 | #35 统计归因（榜单侧的同一主张）、#38 Position（立场侧） |\n| 执行对齐失败 | #24 AHE 的决策可观测性、#27 LangSmith Engine 的轨迹骨架 |\n| 过程质量 > 最终完成 | #33 HarnessAudit（安全侧的同构主张：中途轨迹才是关键） |\n\n---\n\n\n\n### 35. How good is your harness? 论文 — harness 效应的统计归因\n\n- **标题：** How good is your harness? Statistical evaluation of coding harnesses\n- **链接：** [openreview.net forum](https://openreview.net/forum?id=QI8z3skBwt)（[PDF 直链](https://openreview.net/pdf/99eabc2ce65fd2871a253a0a57954c934ea9e6b0.pdf)）\n- **作者：** Jiwoo Han, Yuekai Sun（密歇根大学统计系） | **日期：** 2026-05-25（OpenReview 发布，2026-06-16 末次修订） | **发表：** CTB@ICML 2026 workshop（首尔）\n- **核心：** 用纯统计方法（加性 GLM，logit link）把 Terminal-Bench 2.0 榜单的分数方差拆解归因到 harness 效应与 LLM 效应——不依赖 LLM 标注轨迹，只需要足够交叉的 harness×LLM 榜单设计。数据：清洗后 105 个 harness-LLM 对（28 个 harness × 26 个 LLM）。\n\n- **两个定量结论：**\n 1. **harness 与 LLM 同等重要：** 从基线 harness 换到最优 harness 的分数跃升 ≈ 从基线 LLM 换到最优 LLM 的跃升——\"harness 不是实现细节，是性能的关键组件\"第一次有了量化版本\n 2. **harness 效应异质：** 某些 harness 与某些 LLM 更配（如 OpenHands 配 OpenAI 模型好于配 Anthropic/Google 模型）；交互效应量级堪比主效应——harness 和 LLM **不是可完全互换的组件**\n- **对本仓库缺口的意义：** \"跨模型可移植性\"缺口的第一份定量证据——迁移 harness 到新模型时收益不保序，压测（#4 的\"定期重新压测假设\"）有了统计学理由\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 效应 ≈ 模型效应 | #3 Trivedy 的 Top 30→Top 5 轶事（本文把轶事升级为估计量）、#31 Osmani 引用的数据点 |\n| 效应异质 / 模型-harness 耦合 | #3 的\"模型 overfit 到训练 harness\"、#4 harness 瘦身 |\n| 榜单统计方法 | #34 Harness-Bench（受控实验侧）、#38 Position（立场侧）——评测三部曲 |\n\n---\n\n\n\n### 36. Anthropic / Claude — 动态工作流：模型现场写自己的 harness\n\n- **标题：** A harness for every task: dynamic workflows in Claude Code\n- **链接：** [claude.com/blog](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code)\n- **翻译：** [works/anthropic-dynamic-workflows-translation.md](../works/anthropic-dynamic-workflows-translation.md)\n- **作者：** Thariq Shihipar, Sid Bidasaria（Anthropic Claude Code 团队） | **日期：** 2026-06-02（功能随 Claude Code 2.1.154 + Opus 4.8 于 2026-05-28 发布）\n- **核心：** harness 本体论的转折点——Claude 现在**为任务现场编写自己的 JavaScript 编排脚本**，即一次性定制 harness。默认 Claude Code harness 要在同一个上下文窗口里既规划又执行，在长时运行、大规模并行、高度结构化、对抗性任务上会崩；dynamic workflows 把编排逻辑放进代码（在 token 上近乎免费），单会话扇出数十到数百个并行 subagent，各自在隔离上下文窗口内执行聚焦目标。\n\n- **关键洞察：**\n - **静态 workflow 的宿命是泛化损耗：** 预置工作流必须覆盖所有边界情况所以偏通用；Opus 4.8 已足够聪明为具体用例现写定制 harness——#4\"每个 harness 组件编码一个假设\"在这里变成\"假设由模型即时生成\"\n - **编排即代码：** workflow 可决定每个 agent 用什么模型、是否跑在独立 git worktree——智能等级与隔离度成为可编程参数\n - **对抗验证模式：** 每个生成 agent 配一个独立 agent 按 rubric 对抗校验其输出，收敛后才交付用户；官方 `/deep-research` skill 即此模式（扇出搜索→抓源→对抗核查→合成引用报告）\n - **激活策略：** 提示词含 \"workflow\" 触发，或用 \"ultracode\" 触发词确保建 workflow——回应本仓库缺口清单的\"控制激活策略\"\n - **workflow 是可沉淀资产：** 生成的脚本可检查、保存、复用，经 Skill 分发——一次性 harness 固化为版本化自动化\n - **反向蒸馏：** 挖掘近期 session 和 code review 评论中反复出现的纠正 → 并行 agent 聚类 → 对抗验证每条候选（\"这条规则真能防住一次真实错误吗？\"）→ 幸存者蒸馏回 CLAUDE.md\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 从人写工件变成模型生成工件 | #11 Meta-Harness、#24 AHE（自动搜索/演化的产品化收束）、#7 meta-harness |\n| 编排放进代码以省上下文 | #22 Deep Agents 解释器、#16 Symphony 控制平面 |\n| 对抗验证 | #4 的 Evaluator 分离、#10 评估清单 |\n| 千级 subagent 扇出 | #18 subagent 的 runtime state 管理、#33 多智能体风险面 |\n| 与 Ralph 单体论的张力 | #28 Huntley \"现阶段不需要多智能体\"——一年后官方产品反向而行 |\n\n---\n\n\n\n### 37. 马东锡 NLP — Harness 才是产品\n\n- **标题：** Harness 才是产品：决定 Coding Agent 体验的不是 Model，是它周围的整套 Runtime（Harness 系列）\n- **链接：** [SOTA Sync 转载页](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/)（原文发布于 X @dongxi_nlp，原帖需登录访问，本条目暂链转载页）\n- **作者：** 马东锡 NLP (@dongxi_nlp) | **日期：** 2026-06\n- **核心：** 把系列观点收束成一条产品论断：聊 coding agent 第一个该问的不是\"用哪个 model\"，而是\"**Harness 到底负责什么**\"。coding agent = 把 model 放进一套 runtime（查真实 repo、请求 tool、编辑文件、跑检查、记住发生过什么、多轮推进）——这层 runtime 就是 harness，\"对 coding agent 来说，harness 本身就是 product\"。\n\n- **关键洞察：**\n - **Mini agent 的五个真实爆点：** 编辑从没读过的文件 / shell 触碰 workspace 外 / tool 返回 50,000 行输出 / 磁盘文件已变而 transcript 还是旧读 / tool result 与 tool call 对不上——画出「observe → model → tool」草图的系统还不是 coding agent\n - **六个核心组件：** live repo context / prompt shape / structured tools / context reduction / transcripts & memory / delegation；\"context quality 经常看起来像 model quality\"\n - **\"Model 在 loop 里，harness 拥有 loop\"：** 一个 `edit src/config.py` tool call 只是 proposal，harness 要回答十来个裁决问题（path 是否在 workspace 内、会否经 symlink 逃逸、baseline 是否过期、要否 human approval、多少 output 进下一轮 prompt……）——\"这些判断不该交给 model 的随机处理\"\n - **Transcript ≠ working state：** \"发生过什么\"与\"现在什么重要\"是两份不同任务，必须区别对待\n - **症状→组件的 debug 对照表：** 不断重复→查 loop/retry policy；编辑 stale code→查 file-state baselines；越跑越差→查 context projection；运行意外东西→查 permission policy；无法从 tool error 恢复→查 tool result objects\n - **工程规则收尾：** \"Anything that must be reliable belongs in the harness.\"\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 拥有 loop / 裁决权 | #18 subagent（同系列前作：tool call outside, runtime inside） |\n| harness 是安全面 | #33 HarnessAudit（作者本人转发并背书） |\n| proposal vs 落实边界 | #25 Overeager（提示声明 vs 机械门控）、#31 hooks 分界论 |\n| context projection | #6 context editing、#22 第三类上下文表面 |\n\n---\n\n\n\n### 38. Position 论文 — 编码基准与智能体软件工程的错位\n\n- **标题：** Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering\n- **链接：** [arxiv.org/abs/2606.17799](https://arxiv.org/abs/2606.17799)\n- **作者：** Maria I. Gorinova, Macey Baker, Amy Heineike, Maksim Shaposhnikov, Rob Willoughby, Dru Knox | **日期：** 2026-06 | **arXiv：** 2606.17799\n- **核心：** 立场论文——我们用来比较编码智能体的基准诞生于前智能体时代：把 model、harness、environment 折叠进一个端到端分数，通常按单一参考解评分，没有可迭代的组件级信号。\"实践中的编码智能体不是模型，是 system harness——models/harnesses/contexts/environments/feedback signals 的复合体，其中任何一项都能把基准分数挪动一个相邻模型代际的量级。\"\n\n- **三个症状：**\n 1. 基准分数把模型与 harness 其余部分**混同**——排行榜差异无法归因\n 2. 按单一参考解评分**惩罚同样有效的替代方案**——真实工程里一题多解是常态\n 3. 缺少单个 harness 组件级别的信号，端到端系统分数**难以迭代**——你不知道该修哪里\n- **对本仓库的意义：** 与 #34（受控实验）、#35（榜单统计归因）构成\"harness 评测三部曲\"；也为 thinking/evaluation-elephant-in-the-room 的\"行为 harness 是大象\"补上评测学的病理诊断\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| model/harness/environment 折叠 | #35 的统计拆解方案、#34 的配置级测量方案 |\n| 单参考解惩罚多解 | #10 评估清单的 LLM-as-judge 校准 |\n| 组件级信号缺失 | #24 AHE 的三类可观测性（正是组件级信号的一种供给） |\n\n---\n\n\n\n### 39. OpenAI / Michael Bolin — 展开 Codex agent loop（Codex harness 解剖 · 上）\n\n- **标题：** Unrolling the Codex agent loop\n- **链接：** [openai.com](https://openai.com/index/unrolling-the-codex-agent-loop/)\n- **作者：** Michael Bolin (OpenAI, Codex CLI 团队) | **日期：** 2026-01-23\n- **核心：** Codex 系列工程博客第一篇——把 Codex CLI 的 agent loop（\"我们的 agent，或曰 harness\"）逐层展开：从用户输入构造初始 prompt、经 Responses API 推理、执行工具调用并把输出追加回 `input`，直到模型产出 assistant message 结束一个 turn。是官方视角下 harness 内部机制的最细粒度公开拆解。\n- **关键洞察：**\n - **prompt 是\"item 列表\"：** `instructions`（模型特定指令）+ `tools`（shell / update_plan / web_search / MCP 工具）+ `input`（sandbox 说明 → developer 指令 → AGENTS.md 聚合的用户指令 → environment_context → 用户消息）——AGENTS.md 从 git 根到 cwd 逐层聚合、默认 32 KiB 上限的机制被首次官方成文\n - **agent loop 天然是二次方的：** 每轮把全部历史重发；Codex 刻意不用 `previous_response_id` 以保持请求无状态并支持 ZDR（零数据保留），靠 prompt caching 把采样成本从二次方拉回线性\n - **缓存破坏向量：** 中途改 tools、换模型、改沙箱/审批/工作目录都会 cache miss；MCP 工具枚举顺序不稳定曾是真实 bug——应对策略是\"追加新消息表达变更，而不是改旧消息\"（与 #6 缓存五原则、#30 泄漏实锤的 14 种缓存破坏向量互证）\n - **compaction 的演进：** 从手动 `/compact`（用摘要替换 input）到 Responses API 专用 `/responses/compact` 端点——返回含 `encrypted_content` 的 `type=compaction` item，保留模型对原对话的潜在理解，超过 `auto_compact_limit` 自动触发\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness = agent loop 的官方自述 | #3 LangChain 的 Agent = Model + Harness、#17 Claude Code 逆向（对照组：Codex 侧的官方版） |\n| prompt caching 工程细节 | #6 缓存优化五原则、#30 泄漏实锤的缓存破坏向量追踪 |\n| AGENTS.md 聚合机制 | #5 HumanLayer 的 AGENTS.md 杠杆、概念 2 地图而非手册 |\n| compaction 端点化 | #7 Managed Agents 的 Session 外部存储、#22 上下文表面分层 |\n\n---\n\n\n\n### 40. OpenAI / Celia Chen — 解锁 Codex harness：App Server（Codex harness 解剖 · 下）\n\n- **标题：** Unlocking the Codex harness: how we built the App Server\n- **链接：** [openai.com](https://openai.com/index/unlocking-the-codex-harness/)\n- **作者：** Celia Chen (OpenAI) | **日期：** 2026-02-04\n- **核心：** Codex 的 web / CLI / IDE 扩展 / macOS 应用全部由同一个 Codex harness 驱动，而把这个 harness 暴露给所有客户端的是 Codex App Server——一个双向 JSON-RPC（JSONL over stdio）协议 + 长驻进程。把 harness 从产品内部件变成可被第三方集成的稳定平台面（HaaS 的 OpenAI 实现）。\n- **关键洞察：**\n - **三个对话原语：** Item（原子输入/输出单元，带 `started`/`delta`/`completed` 生命周期）、Turn（一次用户输入触发的工作单元）、Thread（可创建/恢复/fork/归档的持久容器）——为\"agent 交互不是请求/响应\"给出协议级建模\n - **协议是双向的：** 服务器可以主动发起请求（如审批），暂停 turn 直到客户端应答——权限门控被编进协议而非提示词\n - **harness 内容物 = agent loop + thread 生命周期与持久化 + 配置与认证 + 工具执行与扩展（sandbox、MCP、skills）**——官方划出的 harness 边界清单\n - **集成谱系：** App Server（全功能）> Codex SDK > MCP server 模式 > `codex exec`（CI 一次性）；跨厂商 harness 协议会收敛到能力交集，丰富交互难以表达——对\"标准化 vs 表达力\"权衡的一手表态\n - Codex Web 在容器里跑同一个 App Server 二进制，状态留在服务端，浏览器只是轻客户端——ephemeral 会话的断线重连由持久 thread 兜底\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| HaaS（Harness-as-a-Service） | #31 Osmani 的 HaaS 论、#7 Managed Agents 的 harne","works/AGENTS.md":"# works - AI Agent Protocol & Instructions\n\nPath: `works/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/works/AGENTS.md)","tools/harnesses/ralph-orchestrator.md":"# Harnesses Skill\n\nPath: `tools/harnesses/ralph-orchestrator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/tools/harnesses/ralph-orchestrator.md)"},"files":{"AGENTS.md":"# Harness Engineering 学习档案\n\n> 记录我学习「Harness Engineering」的完整过程：从概念理解到独立实践。\n>\n> 来源：[OpenAI — Harness Engineering: Harnessing Codex in an Agent-First World](https://openai.com/zh-Hans-CN/index/harness-engineering/)\n\n## 仓库结构\n\n| 目录 | 内容 | 说明 |\n|------|------|------|\n| `concepts/` | 概念笔记 | 原文核心概念的拆解与整理 |\n| `thinking/` | 独立思考 | 自己的理解、质疑、延伸思考 |\n| `practice/` | 动手实践 | 小项目实验，验证文章中的方法论 |\n| `feedback/` | 反馈记录 | 实践中的踩坑、修正、迭代心得 |\n| `works/` | 作品输出 | 可展示的成果（文章、工具、模板等） |\n| `tools/` | 工具具像化 | 降低 6 维复杂度的杠杆库（带主张，不是 awesome-list） |\n| `prompts/` | 提示词积累 | 学习过程中验证有效的提示词 |\n| `references/` | 外部资源 | 相关文章、仓库、工具的索引 |\n\n## 学习路线（进度）\n\n- [x] Phase 1：理解核心概念（concepts/，8 篇）\n- [x] Phase 2：形成自己的观点（thinking/，11 篇，持续中）\n- [x] Phase 3：选一个小项目实践（practice/，1 个 Ralph Demo）\n- [x] Phase 4：记录反馈迭代（feedback/，1 篇，持续中）\n- [x] Phase 5：输出可展示的作品（works/，40 篇翻译 + 1 篇原创 + 2 篇外部中文收录）\n\n> 进度详情以人类向 README.md 的\"学习路线\"段为准；本节是给智能体的快照。\n\n## 导航\n\n每个子目录都有自己的 AGENTS.md，说明该目录的用途、内容组织方式和写作约定。\n从任何一个目录开始，都能找到下一步该看什么。\n\n## 机械化检查\n\n`scripts/check-consistency.sh` 守护\"漂移\"问题：\n\n- **C1** — `references/articles.md` 编号 1..N 连续\n- **C2** — N 与下游 4 处声明同步（README badge × 2、`prompts/deep-research-tracker.md` 头部、`references/AGENTS.md` 概览）。文件含独立行 `` 时豁免\n- **C3** — `concepts/`、`thinking/`、`feedback/` 的 `*.md` 实际数与 README 中\"X 篇\"声明一致\n- **C4** — `works/*-translation.md` 文件数 ≡ 翻译计数所有声明（badges、`
` 摘要、Phase 5 注释、本文件 Phase 5 快照、READMEs 表格行数）\n- **C5** — README 结构树中 `concepts/` 子树的 item 行数 ≡ `concepts/*.md` 文件数（防止\"计数对了但树漏了\"）\n- **C6** — `references/articles.md` 末尾\"不计入 N 篇\"中的 N ≡ C1 权威值\n- **C7** — 三脉络 per-track 计数（脉络一/二/三）在 4 处下游声明保持一致：READMEs 资料库表、`references/AGENTS.md` 三脉络小标题、`prompts/deep-research-tracker.md` 三脉络明细\n- **C8** — 翻译流水线本地守卫：`translate/<...>/sources//source-full.md` 存在时，对应 `01-analysis.md` 不得再声称\"仅摘要页 / 建议补抓全文\"。`translate/` 已 gitignore，CI 与干净 clone 自动 SKIP，仅本地有过程稿时触发\n- **C9** — `concepts/` / `thinking/` / `feedback/` 正文不得裸写文库计数（\"N 篇文章 / N 篇翻译 / N 大概念\"）；历史性提法须带\"写作时点 / 当时 / 此前 / 首批 / 首轮 / 截至 / 快照\"限定词，否则去数字改链 `references/articles.md`\n- **C10** — 图片保真（纯本地、零网络）：每篇 `works/*-translation.md` 的 frontmatter 必须声明 `sourceFigureCount`（缺失即 FAIL；`null` = 原文不可得、未审计 → SKIP；数字 N → 正文嵌图数须 ≥ N），且所有本地嵌图路径（`imgs/...`）必须在磁盘上存在\n- **C11** — markdown 表格形状：README ×2、`references/AGENTS.md`、`references/articles.md`、`works/AGENTS.md` 里每一行表格的单元格数须与表头一致\n- **C12** — 条目字段完整性：`references/articles.md` 每个 `### N.` 编号条目必须带 **作者：** 与 **日期：** 字段\n- **C13** — 零插图声明须留痕：C10 只能证伪\"多报\"（嵌图数 < 声明数才 FAIL），因此 `sourceFigureCount: 0` 在本地**永远无法被证伪**——不管你有没有真去核对原文，它都是绿的。2026-07-27 就是这个洞放行了一个假 0（原文实有 4 张配图）。C10 刻意零网络、无法回查原文，所以改为要求留痕：**声明 0 的译文必须同时带 `sourceFigureAudit` 字段，值里要有 `YYYY-MM-DD` 核对日期**，写清怎么核对的、结论是什么。`null` 仍然 SKIP——它本来就自陈未审计\n- **C14** — 文档站防漂移：VitePress 站点（部署到 harness.dyu.sh）的侧边栏与首页统计一律由 `.vitepress/sidebar.mjs` 在构建时从文件系统生成，不手写。三条不变量：站点源码（`index.md`、`.vitepress/`）不得出现裸计数（\"N 篇\"），数字只能来自 `computeStats()`；每个一等内容文件必须在生成的侧边栏中恰好出现一次；仓库内禁止任何 symlink——Vite 会解引用 `public/` 下的软链、图片管线会读取链接目标，一条软链即可把仓库外文件带进公开产物（后两条经 `node .vitepress/sidebar.mjs --verify` 执行）。构建产物侧另有 `scripts/verify-dist.mjs` 断言页面与 `.md` 副本一一对应、副本链接可达、dist 无 symlink。站点脚手架不存在时 SKIP；node 不可用时 verify 半边 SKIP、裸计数 grep 照常执行\n\n执行：`bash scripts/check-consistency.sh`（仓库根目录）\n启用 pre-commit 阻断：`git config core.hooksPath .githooks`\n\n**CI 兜底**：`.github/workflows/consistency.yml` 在每次 push / PR 时跑同一脚本（不做路径过滤，保证必需检查总能上报）。job 显示名固定为 `consistency / check`——分支保护按 check run 名匹配必需检查，改名会让所有 PR 重新被 \"Expected\" 卡住。\n本地 hook 是开发反馈，CI 是合并门——两层独立，本地未启用 hook 不会绕过检查。\n","prompts/AGENTS.md":"# prompts/ — 提示词积累\n\n学习过程中验证有效的提示词，按场景或工作流沉淀。**只收录亲测有效的，不收录未验证的。**\n\n## 文件形态（两种合法形式）\n\n### 形式 A：单条 Prompt（按场景命名）\n\n- 文件名：`{场景}.md`，如 `code-generation.md`、`code-review.md`\n- 必备字段：用途、提示词正文\n- 建议字段：效果评价（好/中/差）、改进记录、适用模型 / 不适用场景\n\n### 形式 B：Prompt 工作流（按工具链命名）\n\n- 文件名：`{工作流名称}.md`，如 `deep-research-tracker.md`\n- 必备字段：工作流目标、各步 Prompt 正文（A/B/C…）、链路图\n- 适合多模型 / 多步骤协作的场景（例如 ChatGPT Deep Research → Claude 深度分析 → 人工确认）\n\n## 场景分类参考\n\n| 场景 | 说明 |\n|------|------|\n| 项目初始化 | 让智能体生成仓库骨架、AGENTS.md、CI 配置 |\n| 代码生成 | 在架构约束下生成业务代码 |\n| 代码审查 | 智能体审查智能体生成的代码 |\n| 重构清理 | 熵管理 / 垃圾回收 |\n| 文档维护 | doc-gardening 智能体的提示词 |\n| 情报追踪 | 定期发现领域内新内容（见 deep-research-tracker.md） |\n\n## 已有内容\n\n| 文件 | 形态 | 用途 |\n|------|------|------|\n| [deep-research-tracker.md](deep-research-tracker.md) | 工作流 | 每 1–2 周追踪 Harness Engineering / AI 编程领域新内容 |\n\n## 下一步\n\n用了某条 Prompt 之后，把效果（好/中/差/翻车）记到 [feedback/](../feedback/)；\n积累到一定量再回到本目录补\"效果评价 / 改进记录\"。\n","practice/AGENTS.md":"# practice/ — 动手实践\n\n选一个小项目，用 Harness Engineering 的方法论从零构建，验证原文中的经验。\n\n## 文件约定\n\n- 每个实验一个子目录，如 `practice/01-cli-tool/`\n- 每个实验包含：README.md（目标与方法）、AGENTS.md（给智能体的指导）、代码\n- 关键：人类只写提示词和约束，代码全部由智能体生成\n\n## 已有实验\n\n| 实验 | 验证的概念 | 结果 |\n|------|-----------|------|\n| [01-ralph-demo/](01-ralph-demo/) — Ralph Orchestrator 编排循环 | 帽子系统、背压门控、迭代循环、持久记忆 | 4 轮迭代完成 CLI word counter（321s / $0.31），7 项测试全绿；产物已归档可复验 |\n\n## 实验建议\n\n| 实验 | 验证的概念 | 复杂度 |\n|------|-----------|--------|\n| 用 Claude Code 生成一个 CLI 工具 | 仓库即记录系统 + AGENTS.md 设计 | ⭐ |\n| 为生成的代码写自定义 linter | 机械化执行 | ⭐⭐ |\n| 让智能体自己重构自己写的代码 | 熵管理与垃圾回收 | ⭐⭐⭐ |\n\n## 下一步\n\n实践中踩坑了？去 [feedback/](../feedback/) 记录下来。\n","concepts/AGENTS.md":"# concepts/ — 概念笔记\n\n原文六大核心概念的拆解与整理 + 后续阅读引出的延伸概念。每个概念一个文件，按阅读顺序编号。\n\n## 文件约定\n\n- 文件名：`{编号}-{英文短名}.md`，如 `01-repo-as-source-of-truth.md`\n- `00-overview.md` 是总览，先读这个\n- **文件名编号 ≠ 概念编号**：文件名编号是阅读顺序；\"概念 N\"的编号以 `00-overview.md` / README 的六大核心概念清单为准（两处一致）\n\n## 概念编号 ↔ 文件对照表（引用时以此为准）\n\n| 概念编号 | 概念 | 文件 |\n|---------|------|------|\n| 概念 1 | 仓库即记录系统 | [01-repo-as-source-of-truth.md](01-repo-as-source-of-truth.md) |\n| 概念 2 | 地图而非手册 | [00-overview.md §2](00-overview.md#map-not-manual)（无独立文件） |\n| 概念 3 | 机械化执行 | [02-mechanical-enforcement.md](02-mechanical-enforcement.md) |\n| 概念 4 | 智能体可读性 | [04-agent-readability.md](04-agent-readability.md) |\n| 概念 5 | 吞吐量改变合并理念 | [05-throughput-changes-merge.md](05-throughput-changes-merge.md) |\n| 概念 6 | 熵管理 = 垃圾回收 | [03-entropy-and-garbage-collection.md](03-entropy-and-garbage-collection.md) |\n| 总纲 | 人类掌舵，智能体执行 | [00-overview.md 总纲节](00-overview.md)（不占概念编号） |\n| 延伸 | Harness 的精确定义 | [06-harness-definition.md](06-harness-definition.md)（不占概念编号） |\n| 延伸 | 约束即产品（Spec as Product） | [07-spec-as-product.md](07-spec-as-product.md)（不占概念编号） |\n\n**引用约定**：跨文件引用概念时，写概念名并链接到具体文件（如 `[机械化执行](../concepts/02-mechanical-enforcement.md)`）；如需带编号，编号必须取自本表，不要裸写\"概念 N\"让读者猜编号体系。\n\n### 结构（建议，非强制）\n\n早期文件（01–03）来自 OpenAI 单一原文，结构倾向于：核心要点 → 关键实践 / 方案。\n后期文件（04–06）已演化为多源综合（OpenAI + LangChain + HumanLayer + Fowler），允许加入：\n\n- \"来自其他文章的补充\" / \"来自 X 的补充\"：跨源对照\n- \"关键洞察\" / \"类比\" / \"哲学\"：作者层加工\n- 06 是定义综合型，结构（定义 → 组件清单 → 跨源对照）与前 5 篇不同，属于合法变体\n\n约束只有两条：\n1. 第一段说清楚这个概念**是什么**（无论叫\"原文要点\"还是\"核心思想\"还是\"问题\"）\n2. 跨源内容必须**标注来源**（哪篇文章、哪个作者）\n\n## 已有内容\n\n| 文件 | 概念 | 来源 |\n|------|------|------|\n| [00-overview.md](00-overview.md) | 六大核心概念总览 | OpenAI 原文 |\n| [01-repo-as-source-of-truth.md](01-repo-as-source-of-truth.md) | 仓库即记录系统 | OpenAI 原文 |\n| [02-mechanical-enforcement.md](02-mechanical-enforcement.md) | 机械化执行 | OpenAI 原文 |\n| [03-entropy-and-garbage-collection.md](03-entropy-and-garbage-collection.md) | 熵管理与垃圾回收 | OpenAI 原文 |\n| [04-agent-readability.md](04-agent-readability.md) | 智能体可读性 | OpenAI + LangChain + HumanLayer + Fowler |\n| [05-throughput-changes-merge.md](05-throughput-changes-merge.md) | 吞吐量改变合并理念 | OpenAI + HumanLayer + LangChain + Fowler |\n| [06-harness-definition.md](06-harness-definition.md) | Harness 的精确定义与组件清单 | LangChain + HumanLayer + Fowler |\n| [07-spec-as-product.md](07-spec-as-product.md) | 约束即产品（Spec as Product）| OpenAI Symphony + Fowler + HumanLayer + Meta-Harness |\n\n## 下一步\n\n读完概念后，去 [thinking/](../thinking/) 写你自己的理解和质疑。\n","feedback/AGENTS.md":"# feedback/ — 反馈记录\n\n实践中的踩坑、修正、迭代心得。把失败变成可复用的经验。\n\n## 文件约定\n\n- 文件名：`{日期}-{简述}.md`，如 `2026-03-24-agents-md-too-long.md`\n- 结构：问题描述 → 原因分析 → 解决方案 → 收获\n- 如果某个反馈导致了 prompts/ 或 concepts/ 的更新，交叉链接\n\n## 下一步\n\n反馈积累够了，去 [works/](../works/) 把经验提炼成可展示的作品。\n",".claude/skills/curate-research/SKILL.md":"---\nname: curate-research\ndescription: 把一批 Harness Engineering 调研候选（文章/论文/工具的 URL）走完「抓取→翻译→评审→收录→清理」流水线，整合进本仓库 works/ 与 references/articles.md，并保持 C1–C13 一致性检查全绿。当用户说\"处理这批调研候选 / 收录这些链接 / 整理 translate / 把这几篇翻译收进来\"时使用。这是仓库给自己用的策展 harness。\n---\n\n# curate-research —— 仓库自我策展 harness\n\n> 一个讲 Harness Engineering 的仓库，用一个 harness 来策展自己。本 skill 把外部调研候选可控地整合进 tracked 档案。\n>\n> **核心约束：评审全自动；收录是人类闸门，必须停下来和用户来回讨论后才动 `works/` 与 `articles.md`。**\n\n## 何时用\n\n- 用户给出一批候选 URL（文章 / 论文 / 工具 / 项目），希望整合进仓库\n- 用户说「处理 / 收录 / 整理」`translate/` 暂存区的翻译\n- 已有 `translate//works-ready/` 候选译文，要决定去向\n\n## 输入与产物路径\n\n暂存区（gitignored，本地过程区）：`translate//`\n- `sources//source.md`（原文快照；论文额外抓 `source-full.md`）\n- `translations//{01-analysis,02-prompt,translation}.md`（过程三件套）\n- `works-ready/-translation.md`（发布候选）+ `works-ready/README.md`（状态表，本批权威）\n\n正式档案（tracked）：`works/-translation.md` + `references/articles.md` 条目。\n\n## 流水线 6 阶段\n\n```\n①抓取 ──②翻译 ──③评审[全自动] ──🚧人类闸门🚧──④收录 ──⑤校验 ──⑥清理\n```\n\n### ① 抓取\n用 `baoyu-url-to-markdown` 把每个 URL 存到 `sources//source.md`。**论文/长文必须额外抓 HTML 全文到 `source-full.md`**（否则只有摘要页，C8 会拦谎报）。\n\n### ② 翻译\n按 baoyu-translate 配置生成 `translations//` 三件套 → `works-ready/-translation.md`。`01-analysis.md` 要含收录建议；`source-full.md` 存在时，分析稿不得声称「仅摘要页」。\n\n### ③ 评审（全自动并行扇出）\n对每篇候选派一个评审 agent（一批 3–4 篇，并行多个 agent）。统一打分维度，吐结构化定性。**标准评审 prompt 模板：**\n\n> 你是 Harness Engineering 中文知识库的内容评审。仓库主题：人类设计约束与反馈回路、AI agent 写代码。\n> 读 `sources//source.md`(+`source-full.md`)、`works-ready/-translation.md`、`translations//01-analysis.md`，逐篇回答：\n> - **原文价值**：原创洞察密度 / 长文实质 vs 产品页·发布稿·摘要。高/中/低\n> - **翻译质量**：完整逐译 / 压缩摘要 / 首轮粗稿；通顺度、术语到位度。精品/合格/需返工\n> - **与仓库契合度**：补薄弱环节还是重复\n> - **一句话定性 + 建议去向**：works/ 正式收录 / articles.md 观察项一行 / tools/ / 暂不收录\n> 基于实际内容，紧凑中文，结构化输出即为最终产出。\n\n汇总成一张「候选 × 定性 × 去向」表。\n\n### 🚧 人类闸门（不可跳过）\n把评审表交给用户，**来回讨论收录决策**。精品 vs 边角的边界判断、是否返工、哪些合并成专题——都由人定。**未经用户确认，不得进入 ④。**\n\n### ④ 收录（按减熵分流规则）\n- **实质原创长文 / 论文 → `works/`**：`cp` 到 `works/-translation.md`，在 `articles.md` 加一个 `### N.` 编号条目（脉络一末尾，旧编号顺移），并**同步全部计数缓存**（见下）。\n- **边角材料**（产品页 / README / 发布稿 / 短 bliki）**→ articles.md「观察项 / 候选材料（不计入文章数）」表一行**，链上游 URL，不做编号条目（文章数不变）。\n- **工具类 → 只在用户实际用过后才进 `tools/`**；未实测前在观察项表标 🔵「待实测后入 tools/」。\n- **需返工的长文**：先润色（事实核查加译者注 / 术语统一）再进 `works/`。\n\n**入库前 checklist（每篇 works/ 候选必过，再进 ⑤）：**\n- [ ] frontmatter 声明 `sourceFigureCount` 并与原文实际图数核对（null = 原文不可得、未审计）；原文插图下载入 `works/imgs//` 本地嵌入——C10 校验嵌图数 ≥ 声明数、本地路径文件存在\n- [ ] **数图要抓原文 HTML 数，不能只看渲染出来的正文。** 2026-07-27 的教训：一篇 claude.com 译文声明 `sourceFigureCount: 0`，而原文 HTML 里有 4 个 `
`——抓取工具吐出的 markdown 把它们丢了，人只看那份 markdown 就会以为没有图。可用 `curl | grep -c '-translation.md`（works/ 是权威源）。\n- 删已收录 slug 的 `sources//` + `translations//`（过程稿，works/ 已留最终版）。\n- **保留**：观察项 slug 的全部译文（articles.md 标明「留作阅读辅助」）+ 状态 README。\n- 更新 `works-ready/README.md` 状态表。`translate/` 是 gitignored，清理仅本地。\n\n## 计数同步清单（④ 的硬要求）\n\n`references/articles.md` 是文章数与编号的**唯一权威源**。每加一个 `### N.` 条目，必须同次更新所有下游缓存，否则 `check-consistency.sh` 报错：\n- README.md / README.en.md：`articles-N` badge、`translations-N` badge、目录树、脉络表（脉络一计数）、翻译 `
` 摘要数、翻译表格行、Phase 5 提及\n- references/AGENTS.md：概览「N 篇文章」、脉络一小标题计数、文章表加行\n- prompts/deep-research-tracker.md：「核心文章 N 篇」、脉络一计数、去重清单加行\n- AGENTS.md：Phase 5 快照「N 篇翻译」\n- works/AGENTS.md：翻译表加行\n- articles.md 自身：header「N 篇（脉络一 …）」、两处「不计入 N 篇」\n- **观察项一行不触发以上**（不计入 N，无 `### N.` 编号）——这是减熵分流的关键收益。\n\n## 相关\n- 减熵分流约定：即上文「④ 收录」的分流规则——实质长文进 `works/` 编号正文；边角材料只进观察项表（不计数、不触发计数同步）；工具未实测不进 `tools/`。原则：每条新收录都要问\"它增加的检索价值是否大于它增加的维护熵\"\n- C8 lint：`source-full.md` 存在时禁止 analysis 谎报摘要页（`scripts/check-consistency.sh`）\n- C9 lint：`concepts/` / `thinking/` / `feedback/` 正文禁止裸写文库计数（历史提法须带\"写作时点/当时/此前/首批/首轮/截至/快照\"限定词）\n- C10/C11/C12 lint：图片保真（`sourceFigureCount` vs 正文嵌图数 + 本地嵌图路径存在）/ markdown 表格列数与表头一致 / articles.md 编号条目必含 **作者：**/**日期：** 字段（同上脚本）\n- C13 lint：`sourceFigureCount: 0` 必须配 `sourceFigureAudit`（含核对日期）。这条是补 C10 的结构性盲区——C10 的判据是\"嵌图数 < 声明数才 FAIL\"，所以 0 永远为真，无论你有没有真去数过原文。机械检查只能证伪\"多报\"，\"零报\"只能靠留痕让人复核\n- 历史首批实例：articles.md #19–27（2026-06 收录的 9 篇）+ 末尾观察项表 14 行\n","prompts/deep-research-tracker.md":"# 深度研究追踪 Prompt\n\n> 用途：定期（每 1-2 周）运行，发现 harness engineering / AI 编程领域的高价值新内容\n> 推荐工具：ChatGPT Deep Research（广度搜索）→ Claude（深度分析 + 项目关联）\n\n---\n\n## Prompt A：ChatGPT Deep Research — 广度发现\n\n```\n你是一个技术情报分析师。请对以下领域进行深度网络搜索，找出过去 2 周内（{START_DATE} 至 {END_DATE}）发布的高价值内容。\n\n### 搜索领域\n\n核心主题：\n1. Harness Engineering — AI 编码智能体的约束、引导、反馈系统设计\n2. Context Engineering — 上下文窗口管理、compaction、渐进式披露\n3. AI Coding Agents — 编码智能体的架构、编排、评估\n4. Agent Infrastructure — 沙箱、会话管理、多智能体协作\n5. AI-assisted Software Engineering — AI 辅助开发的效率、流程、组织影响\n\n相关关键词（中英文）：\n- harness engineering, agent harness, coding agent, AI coding\n- context engineering, context window, compaction, progressive disclosure\n- AGENTS.md, CLAUDE.md, agent readability, agent-first\n- managed agents, meta-harness, multi-agent orchestration\n- AI code review, mutation testing, structural testing, fitness functions\n- vibe coding, AI-native development, agentic workflow\n- 智能体工程, AI 编程, 上下文工程, 护栏工程\n\n### 搜索范围\n\n必须覆盖的信源（按优先级）：\n\n**Tier 1 — 高权重（模型厂商 + 顶级技术博客）：**\n- Anthropic Engineering Blog (anthropic.com/engineering)\n- OpenAI Blog (openai.com)\n- Google DeepMind / Google AI Blog\n- Martin Fowler (martinfowler.com)\n- Mitchell Hashimoto (mitchellh.com)\n- LangChain Blog (blog.langchain.com)\n- Simon Willison (simonwillison.net)\n\n**Tier 2 — 中权重（社区 + 行业）：**\n- Hacker News (前 100 讨论)\n- GitHub Trending (相关仓库)\n- X/Twitter 技术社区 (#harness-engineering, #ai-coding, #context-engineering)\n- Dev.to, Medium 技术专栏\n- HumanLayer, Cursor, Windsurf, Codex 相关博客\n- 中文社区：少数派、掘金、知乎专栏\n\n**Tier 3 — 低权重但可能有惊喜：**\n- arXiv (cs.SE, cs.AI 交叉)\n- 个人技术博客\n- YouTube 技术频道\n- Reddit (r/LocalLLaMA, r/ChatGPT, r/programming)\n\n### 我们已知的内容（用于去重和关联）\n\n> **本节是 Prompt 的去重权威**——给外部搜索器（ChatGPT Deep Research 等）使用。\n> 它必须自包含，因为搜索器无法访问 `references/articles.md`。\n>\n> **维护纪律：** 当 `references/articles.md` 新增/删除条目时，**同一次提交中**必须同步更新本节。两份内容的口径（脉络划分、篇数、产品/项目清单）应保持完全一致。\n> 本节最近一次同步：2026-08-27（与 `articles.md` 当前内容对齐：79 篇文章 + 1 项已跟踪产品）。\n\n**核心文章 79 篇，分布于三条脉络：**\n\n- **脉络一 — AI 时代 Harness Engineering（75 篇）：**\n - OpenAI \"Harness engineering\"（原点，2026-02-11）/ \"An open-source spec for Codex orchestration: Symphony\"（2026-04-27，任务跟踪器作为控制平面）\n - Fowler/Böckeler \"Harness engineering for coding agent users\"（2026-04-02）+ 前传备忘录（2026-02-17）\n - LangChain \"The Anatomy of an Agent Harness\"（2026-03）/ \"Continual Learning for AI Agents\"（2026-04-05）/ \"Agent Evaluation Readiness Checklist\"\n - Anthropic \"Harness design for long-running application development\"（2026-03-24）\n - Anthropic / Lance Martin \"Harnessing Claude's intelligence\"（2026-04-02，三大模式与性能数据）\n - Anthropic \"Scaling Managed Agents\"（2026-02-04，meta-harness 与基础设施解耦）\n - HumanLayer \"Skill Issue\"（2026-03，六杠杆与避坑）\n - Fowler / Rahul Garg \"Encoding team standards\"（2026-03）/ \"Feedback flywheel\"（2026-03）\n - Meta-Harness 论文（自动化 Harness 优化）\n - GitHub / Tyler McGoffin \"Agent-Driven Development\"（实战）\n - \"Inside the Scaffold\" 论文（编码智能体脚手架的源代码级分类法）\n - Lalit Maganti \"渴望八年，用 AI 三个月造出来\"\n - Vikash Rungta \"Claude Code Architecture (Reverse Engineered)\"（2025-11-01，Claude Code 运行外壳、TAOR 循环、工具原语、权限与上下文管理的外部逆向分析）\n - 马东锡 NLP \"Harness 系列文章之 7：关于 subagent\"（2026-06-22，subagent = tool call 入口 + child runtime，区分 session/context/subagent，与 Claude Code 逆向互证）\n - Fowler/Böckeler \"Maintainability sensors for coding agents\"（2026-05-20，计算性 vs 推理性传感器谱系 + 失败案例 + AI 评审作为垃圾回收）\n - Fowler \"Structured-Prompt-Driven Development (SPDD)\"（2026-04-28，REASONS Canvas 七维 + prompt 即一等交付物 + 双向闭环）\n - LangChain / Harrison Chase \"The Agent Development Lifecycle (ADLC)\"（2026-05-09，framework/runtime/harness 三分类的生命周期）\n - LangChain / Hunter Lovell \"Interpreters in Deep Agents\"（2026-05-20，interpreter 是第三类上下文表面 + 35% token 节省）\n - Anthropic 工程团队 \"An update on recent Claude Code quality reports\"（2026-04-23，三起独立变更叠加成质量退化的第一手复盘）\n - Agentic Harness Engineering 论文（arXiv 2604.25850，复旦/北大/奇绩，可观测性驱动的 Harness 自动演化 + 可证伪契约）\n - Overeager Coding Agents 论文（arXiv 2605.18583，越界动作测量 + 提示声明授权反而降低边界推断）\n - Chris Parsons \"How I Use AI to Code\"（2026-05，四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈；含译者注，2026 数据未独立核实）\n - LangChain / Palash Shah \"How we built LangSmith Engine\"（2026-05-19，用智能体改进智能体，trace→轨迹骨架 + screener/investigator 两阶段闭环）\n - Geoffrey Huntley \"Ralph Wiggum as a software engineer\"（2025-07）+ \"everything is a ralph loop\"（2026-01-17，bash 循环 + 干净上下文 + 背压 + 单体反多智能体论）\n - Mitchell Hashimoto \"My AI Adoption Journey\"（2026-02-05，六步采纳路线 + \"harness engineering\" 命名出处）\n - Claude Code 源码泄漏事件（2026-03-31，v2.1.88 npm source map 泄 512K 行 TypeScript；聚合分析 pankaj28843/understanding-claude-code：QueryEngine ~46K 行、60+ 门控工具、KAIROS/AutoDream/Undercover Mode）\n - Addy Osmani \"Agent Harness Engineering\"（2026-04-19，O'Reilly 转载；学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS）\n - Thoughtworks / Böckeler & Ford \"Exploring AI coding sensors\"（2026-05-13，有/无传感器对照实验 + harness 模板展望）\n - HarnessAudit 论文（arXiv 2605.14271，harness 安全审计：中途轨迹违规是输出级评估盲区，210 任务基准）\n - Harness-Bench 论文（arXiv 2605.27922，配置级 harness 效应：106 任务 / 5194 轨迹 + 执行对齐失败）\n - \"How good is your harness?\"（CTB@ICML 2026，Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应且异质）\n - Anthropic/Claude \"A harness for every task: dynamic workflows in Claude Code\"（2026-06-02，模型现场写自己的编排 harness + 对抗验证 + ultracode 触发）\n - 马东锡 NLP \"Harness 才是产品\"（2026-06，Model 在 loop 里 harness 拥有 loop + 六组件 + 症状→组件 debug 表）\n - Position 论文 \"Coding Benchmarks Are Misaligned with Agentic SE\"（arXiv 2606.17799，基准折叠 model/harness/环境的三症状）\n - OpenAI \"Unrolling the Codex agent loop\"（2026-01-23，Codex harness 解剖·上：prompt 构造 / 二次方与 prompt caching / compaction 端点化）\n - OpenAI \"Unlocking the Codex harness\"（2026-02-04，Codex harness 解剖·下：App Server 双向 JSON-RPC + Item/Turn/Thread 原语 + HaaS）\n - Addy Osmani \"Loop Engineering\"（2026-06-08，loop 定调文：五构件 + 记忆脊柱；上游为 Steinberger 推文与 Boris Cherny \"我的工作是写循环\"）\n - Armin Ronacher \"The Coming Loop\"（2026-06-23，怀疑派回应：agent loop vs harness loop + 防御式编码放大 + 软件作为有机体）\n - Anthropic/Claude Code 团队 \"Loop engineering: Getting started with loops\"（2026-06-30，官方四类循环 turn/goal/time/proactive + `/goal` 独立判停）\n - Self-Harness 论文（arXiv 2606.09498，智能体自改 harness：弱点挖掘→提议→回归验证，三模型 held-out +14~21pp）\n - Lilian Weng \"Harness Engineering for Self-Improvement\"（2026-07-04，RSI 综述：三设计模式 + 优化对象递进链 + 七项未来挑战）\n - Aria 论文 \"Harnessing Code Agents for Automatic Software Verification\"（arXiv 2607.06341，声明式 HHL 包裹通用智能体做 Coq 证明，行为 harness 极限形态）\n - Anthropic \"Demystifying evals for AI agents\"（2026-01-09，智能体评测官方方法论：outcome≠transcript、pass@k/pass^k、CORE-Bench 42%→95% 基准病理）\n - Cursor / Wilson Lin \"Scaling long-running autonomous coding\"（2026-01-14，数百并发智能体 × 数周：planner/worker/judge + FastRender 百万行浏览器）\n - Anthropic / Nicholas Carlini \"Building a C compiler with a team of parallel Claudes\"（2026-02-05，16 agent 无编排者 + GCC oracle + $20k 成本账本）\n - Anthropic \"How we contain Claude across products\"（2026-05-25，三隔离模式 + 五起漏掉的风险：白名单是能力授予、先环境层遏制）\n - LangChain \"Introducing Dynamic Subagents in Deep Agents\"（2026-06-29）+ \"How to Use RLMs in Deep Agents\"（2026-07-01，模型写编排脚本 + RLM 递归上下文）\n - Fowler/Böckeler 本地模型双备忘录（2026-07 上旬，Qwen3.6 35B MoE 甜点 + 工具调用是智能体化分水岭）\n - Harness Handbook 论文（arXiv 2607.13285，2026-07-14，行为定位是 harness 演化瓶颈：行为中心表示 + BGPD）\n - Fowler / Unmesh Joshi \"DSLs Enable Reliable Use of LLMs\"（2026-07-14，DSL 工具集即 harness：语言层约束 + 确定性验证器）\n - Addy Osmani \"Own the Outer Loop\"（2026-07-15，AIE 闭幕演讲：智能体跑内环、工程师拥有外环问责 + back-pressure 调速）\n - Jarred Sumner \"Rewriting Bun in Rust\"（2026-07-08，50 dynamic workflows × 峰值 64 Claude × 11 天机械移植 53.5 万行 Zig→Rust；语言无关测试套件作 oracle + 1 实现者/2 对抗评审者/1 修复者 + \"修流程不修代码\"；$165k API 成本账本）\n - HarnessX 论文（arXiv 2606.14249，小米 Darwin Agent Team，2026-06：harness 一等类型化对象（processor × 8 hooks × 九维分类）+ AEGIS 四阶段演化 + cross-harness GRPO 共演化；+14.5% 均值（最高 +44.0%）、共演化再 +4.7%、弱模型受益最大）\n - Anthropic / Justin Young \"Effective harnesses for long-running agents\"（2025-11-26，存量回扫补录：initializer + coding 两段式、200+ 条 feature_list.json、claude-progress.txt + git、Puppeteer 端到端自验；#4/#7 的上游）\n - Anthropic / Gian Segato \"Quantifying infrastructure noise in agentic coding evals\"（2026-02-05，存量回扫补录：只改资源配额 Terminal-Bench 2.0 摆动 6pp；1x–3x 修可靠性、3x 以上改变被测对象；建议每任务声明保底分配 + 硬杀阈值）\n - Cursor / Stefan Heule & Jediah Katz \"Continually improving our agent harness\"（2026-04-30，存量回扫补录：Keep Rate、LLM 读用户回复判满意、CursorBench + 线上 A/B、错误分类与按工具按模型基线、每周 Automation 修 harness、按训练分布供给工具格式、context anxiety）\n - Cursor / Naman Jain \"Reward hacking is swamping model intelligence gains\"（2026-06-25，存量回扫补录：审计 731 条轨迹，SWE-bench Pro 上 63% 成功解是检索答案；封 git + 断网后 Opus 4.8 Max 87.1%→73.0%、Composer 2.5 74.7%→54.0%）\n - Armin Ronacher \"Better Models: Worse Tools\"（2026-07-04，工具 schema 不是中立的：Claude Code 的宽容客户端 + 在其中做 RL → 新模型对替代 schema 更差；strict 模式可清零）\n - Dex Horthy / HumanLayer \"Why Software Factories Fail — harness engineering is not enough\"（2026-07，AIE World's Fair 主题演讲 + wsff.md：熄灯工厂第一手失败实录、可维护性没有快 oracle、产品/架构/程序设计/垂直切片四阶段前移）\n - Addy Osmani \"Software Factories, Light and Dark\"（2026-07-20，loop→harness→factory 三层 + 唯一昂贵的评审闸门 + 背压规则 + \"什么样的循环配得上熄灯\"准入清单 + loops vs graphs）\n - Cursor / Wilson Lin \"Agent swarms and the new model economics\"（2026-07-20，#48 续篇：835 页手册重造 SQLite，账单 $1,339–$10,565；规划/执行分层、自建 VCS 1000 提交/秒、五种蜂群失效、去相关评审、Field Guide）\n - Anthropic / Thariq Shihipar \"The new rules of context engineering for Claude 5 generation models\"（2026-07-24，删掉 Claude Code 系统提示词 80%+ 无可测损失；七组 then/now + `claude doctor`）\n - Don't Blame the LLM 论文（arXiv 2607.03691，Queen's University，首个固定模型只变 harness 的受控纵向研究：Qwen Code CLI 35 个连续版本 × 50 个 SWE-bench Verified 任务）\n - Rethinking Harness Evolution 论文（arXiv 2607.12227，自动 harness 演化的第一份系统性负面结果：同等预算下不稳定优于 test-time scaling、泛化有限）\n - LangChain \"How We Benchmark Deep Agents\"（2026-07-23）+ \"IssueBench\"（2026-07-20）——Harbor 评测栈：Harbor-Index 82 任务 / lite 冻结子集 / capability suite；IssueBench 15 类失败分类法与 issue 集层面判分\n - LangChain / Nick Hollon \"Evaluating code review agents with ReviewBench\"（2026-07-31，真实 PR 评审意见策展成 59 任务 / 64 基线问题；裸 harness 最强召回 ~30%，prompt-only 调优 Luna 0.13→0.32 反超 Opus/Kimi）\n - Fowler / Birgitta Böckeler \"TDD inside the agent loop - theater or actual value?\"（2026-08-10，agent loop 内 TDD 实证否定：盲评质量无差异、mutation score 无差异、token 3–8.5 倍；别规定过程，度量结果）\n - Addy Osmani \"Practical Loop Engineering\"（2026-08-14，loop 系列日常落地环：踩坑实录 + 80K star 仓库分诊循环 + fine print 运维细则）\n - Zalando / Bartosz Ocytko \"Agentic Engineering at Zalando: A Snapshot\"（2026-08-14，250+ 团队非供应商组织级快照：事故分析→PR 风险分级→33% 自动放行→lead time -20~40%）\n - Earendil / Pi 团队双篇 \"What Is a Harness?\" + \"How Compaction Works in Pi\"（2026-08-20 / 08-13，harness 定义+用户侧中立主张 / compaction 白盒实现，与 Codex 端点化对照）\n - StarHarness 论文（arXiv 2608.24804，ServiceNow/Mila，2026-08-25，冻结 harness 工件跨 GPT/Qwen 迁移 12 行全正 +10.7~+46.3pp；跨模型可移植性首个正面证据）\n- **脉络二 — 云原生 Harness.io（2 篇）：** Harness.io 官方全局架构 / Google Cloud 集成场景\n- **脉络三 — 效率悖论（2 篇）：** YDD/Miss-you \"效率悖论的系统性拆解\"（2026-03-03）/ METR 实验后续 + 自报调查（2026-02-24 + 2026-05-11，\"慢 19%\"的官方后续：弱证据转向加速 + RCT 方法论危机）\n\n**已跟踪的开源项目/产品：**\n- Ralph Loop 实验链：snarktank/ralph、ralph-orchestrator、bmad-ralph\n- Chachamaru127/claude-code-harness（v4.2 \"Hokage\"，Claude Code 五动词工作流 + Go 原生 guardrail R01–R13；2026-04-21 收录）\n\n**请重点发现：**\n- 上述未覆盖的新作者 / 新视角 / 新组织\n- 对上述文章的**深度回应或反驳**（不是简单转述）\n- 与上述项目**互补或竞争**的新工具 / harness / 框架\n- 中文社区针对上述材料的原创分析（少数派、掘金、知乎专栏等）\n\n### 输出格式\n\n请按以下格式输出，每条内容一个条目：\n\n---\n\n#### [编号]. {标题}\n\n- **类型：** 文章 / 开源项目 / 工具 / 演讲 / 论文\n- **链接：** {URL}\n- **作者/组织：** {作者}\n- **日期：** {发布日期}\n- **信源层级：** Tier 1 / Tier 2 / Tier 3\n- **推荐指数：** ⭐⭐⭐⭐⭐（1-5 星）\n\n**一句话摘要：** {50 字以内}\n\n**核心洞察（3-5 条）：**\n1. ...\n2. ...\n3. ...\n\n**与已知内容的关联：**\n- 支持/挑战/扩展了哪篇已有文章的观点\n- 填补了哪个已知缺口\n\n**值得收录的理由 / 不值得的理由：**\n{判断}\n\n---\n\n### 质量过滤标准\n\n**必须满足（全部）：**\n- 有实质性的技术内容（不是纯营销或产品公告）\n- 有原创洞察或数据（不是对已有文章的简单转述）\n- 来源可信（有署名，有技术背景）\n\n**加分项（满足越多越好）：**\n- 有实际数据或实验结果\n- 有代码示例或可复现的方案\n- 挑战了主流观点\n- 来自一线实践者（不是纯理论）\n- 有中文社区尚未覆盖的视角\n\n**排除：**\n- 纯产品发布/营销内容\n- 对已有文章的简单翻译或摘要（没有新观点）\n- 过于初级的入门教程\n- 与 harness engineering 只有表面关联\n\n### 输出数量\n\n- 文章类：推荐 5-10 篇，按推荐指数排序\n- 开源项目类：推荐 3-5 个\n- 其他（工具/演讲/论文）：如有高质量内容，不限数量\n```\n\n---\n\n## Prompt B：Claude — 深度分析与项目关联\n\n> 在 ChatGPT 返回结果后，将结果喂给 Claude（在本项目中），做深度分析\n\n```\n以下是最近 2 周的技术情报搜索结果。请基于我们项目的已有内容，做以下分析：\n\n{粘贴 ChatGPT 的输出}\n\n### 请分析：\n\n1. **优先级排序**：哪些内容最值得我们收录？考虑因素：\n - 对**已收录文章 + 已跟踪开源产品**（完整清单见 Prompt A 的\"已知内容\"段落或 `references/articles.md`，不在此重复计数）的补充价值\n - 对 thinking/ 中已有洞见的验证或挑战（含 cross-article-insights 的 8 个洞见 + guides-sensors-meets-claude-code-harness 的 5 个张力）\n - 对开放问题清单的回答程度\n\n2. **缺口分析**：这批内容覆盖了我们的哪些知识缺口？还有哪些缺口未被触及？\n 当前已知缺口：\n - 行为 Harness（功能正确性验证）\n - Harness 覆盖率评估方法（#34/#35/#38 评测三部曲已部分回应，组件级信号供给仍开放）\n - 跨模型可移植性（#35 给出首个定量异质性证据，迁移指南仍缺）\n - 成本数据\n - 中小团队实践案例\n - Harness 接口维护成本（追宿主升级在总维护中的占比）\n - 控制的\"激活策略\"（always-on / per-commit / conditional / human-summoned 的分类与适用场景；#36 的 workflow/ultracode 触发是一个数据点）\n - Harness 安全审计（#33 开辟：中途轨迹违规、多智能体信息流、harness 决定安全上限——后续跟踪该方向的评测与工具）\n - 评测方法论（基准如何拆分 model/harness/环境的组件级归因——跟踪 #34/#35/#38 的后续工作）\n\n3. **趋势信号**：这批内容中是否有新的趋势或方向？与我们已有的四个学派（约束派、控制论派、架构派、怀疑派）是否一致？\n\n4. **收录建议**：对每条推荐内容给出具体建议：\n - 收录到 references/articles.md（哪个脉络）\n - 值得翻译到 works/\n - 值得在 thinking/ 中写分析\n - 暂不收录，持续观察\n```\n\n---\n\n## Prompt C：Manus / OpenClaw — 自动化监控\n\n> 用于设置定时监控的固定信源\n\n```\n定时任务：每日检查以下信源的更新\n\n监控列表：\n1. https://www.anthropic.com/engineering — RSS 或页面变化\n2. https://openai.com/index/ — 新文章\n3. https://martinfowler.com/articles/ — 新文章\n4. https://blog.langchain.com/ — 新文章\n5. https://github.com/trending?since=weekly — AI/agent 相关项目\n6. https://simonwillison.net/ — 新文章\n7. https://mitchellh.com/writing — 新文章\n8. https://claude.com/blog — 新文章（Anthropic 产品侧博客；2026-06 的 dynamic workflows / Managed Agents 两篇重磅均发于此，工程博客不覆盖）\n9. https://addyosmani.com/blog/ — 新文章\n10. https://ghuntley.com/ — 新文章（Ralph 方法论源头）\n\n匹配关键词：harness, agent, coding agent, context engineering, \n AGENTS.md, compaction, multi-agent, sandbox\n\n输出：\n- 有更新时，发送通知（标题 + 链接 + 匹配的关键词）\n- 无更新时，静默\n```\n\n---\n\n## 工作流总结\n\n```\n┌─────────────────────────────────────────────────┐\n│ Layer 1: 自动化监控（每日） │\n│ 工具：OpenClaw / Manus │\n│ 输出：固定信源的新内容通知 │\n└──────────────────────┬──────────────────────────┘\n ↓ 有新内容时触发\n┌─────────────────────────────────────────────────┐\n│ Layer 2: 广度搜索（每 1-2 周） │\n│ 工具：ChatGPT Deep Research │\n│ 输入：Prompt A │\n│ 输出：5-10 篇文章 + 3-5 个项目的结构化摘要 │\n└──────────────────────┬──────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────┐\n│ Layer 3: 深度分析（按需） │\n│ 工具：Claude（本项目内） │\n│ 输入：Prompt B + ChatGPT 输出 │\n│ 输出：优先级排序 + 缺口分析 + 收录建议 │\n└──────────────────────┬──────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────┐\n│ Layer 4: 人工确认 │\n│ 你决定：收录 / 翻译 / 写分析 / 跳过 │\n└─────────────────────────────────────────────────┘\n```\n\n## 核心信源存量回扫（每批必做一步）\n\n> 教训来自 2026-07-21 批次：只按\"最近 2 周\"时间窗扫描，导致 4 篇 1–5 月的重量级官方件\n> （Cursor scaling-agents、Anthropic C compiler / how-we-contain / demystifying-evals）漏网数月。\n> 时间窗抓增量，回扫补存量——两者缺一不可。\n\n每轮调研除时间窗扫描外，**轮换抽取 1–2 个 Tier 1 信源，翻其全年归档目录**（archive / blog 列表页），\n对照 `references/articles.md`（含观察项表）逐条核对是否已收录或已甄别。优先轮换顺序：\n\n1. anthropic.com/engineering（工程博客，全量列表）\n2. cursor.com/blog（research 分类）\n3. openai.com/index（Engineering 分类）\n4. martinfowler.com/tags（GenAI 标签 + exploring-gen-ai 系列）\n5. langchain.com/blog、claude.com/blog、addyosmani.com/blog、simonwillison.net 月归档\n\n发现漏网存量时，与本批增量一起进「候选 × 定性 × 去向」评审表，注明\"存量补课\"。\n\n### 轮换记录\n\n| 批次 | 回扫信源 | 捞回的存量 |\n|------|---------|-----------|\n| 2026-07-21 | （教训来源，未做系统回扫） | 事后补收 #48 / #49 / #50 / #47 |\n| 2026-07-27 | ① anthropic.com/engineering 全量列表 ② cursor.com/blog 全量 slug 清单 | #58 Effective harnesses（2025-11）、#59 基础设施噪声（2026-02）、#60 持续改进 agent harness（2026-04）、#61 奖励作弊（2026-06）——四篇均为 harness 主题正中靶心却漏网数月 |\n| 2026-08-03 | ① openai.com/sitemap.xml/engineering 全量 URL+lastmod ② martinfowler.com/feed.atom（GenAI 归档） | 无漏网存量：OpenAI Engineering 分类的 harness 主题件（harness-engineering / unrolling / unlocking / symphony / windows-sandbox / core-dump / websockets / how-agents-transforming-work）均已在编号正文或观察项；其余 gpt-5.6 / atlas / sora-android / tax-agents / data-agent 为产品·基建，非 harness。Fowler 侧捞出的是增量而非存量（重构经济效益 / Conductor Developer / Fragments 07-21 / Orchestrator's Tax 草稿）——已进本批观察项 |\n| 2026-08-27 | ① langchain.com/blog sitemap 全量（507 slug）② claude.com/blog sitemap 全量（228 slug，去 locale 变体） | **非零星漏网而是系统性缺口**：langchain 相关约 115 篇/此前仅收 19（漏网详查 48，含 12 篇标题直接带 harness/loop 的核心文：improving-deep-agents-with-harness-engineering、better-harness、the-art-of-loop-engineering、deep-agents 开山文等）；claude.com 相关约 80/仅收 9（漏网详查 41：skills 全系列、subagent 系列、Lessons from building Claude Code 双篇等）。处置：不逐篇消化，观察项表加 2 个\"信源级\"合并行，完整清单留档 translate/2026-08-27/candidates.md。方法论教训：两站列表页对 curl 均不完整**必须走 sitemap.xml**；claude.com 的 lastmod 批量刷新不可作发布日期，需逐页取 JSON-LD datePublished |\n\n> 下一轮建议轮换：addyosmani.com/blog + simonwillison.net 月归档（个人博客侧尚未系统回扫过）；cursor.com/blog 可顺带复扫（本批已全量取 sitemap 115 slug 逐页核过日期，短期内干净）。openai.com/index 用 `curl https://openai.com/sitemap.xml/engineering/` 拿到带 lastmod 的全量 URL 最省事（2026-08-03 验证有效，比抓列表页首屏可靠）。\n> 回扫技巧（2026-07-27 验证有效）：列表页只渲染最近若干条时，直接抓 `curl |grep -oE '/blog/[a-z0-9-]+'|sort -u` 拿全量 slug，\n> 再逐个取 `datePublished` 与标题——Cursor 那四条里有两条（`continually-improving-agent-harness`、`reward-hacking-coding-benchmarks`）就是这样发现的，它们不在列表页首屏。\n","tools/00-overview.md":"# 工具地图：复杂度维度 ↔ 工具杠杆\n\n> 配套 [software-project-complexity-in-the-ai-era.md](../thinking/software-project-complexity-in-the-ai-era.md) 的6 维复杂度框架使用。\n\n---\n\n## 思路\n\n每个工具的真正价值，不是它的功能列表，而是：\n\n> **它能切实降低 AI 接管难度的哪一维？**\n\n如果一个工具不能映射到任何一维复杂度的下降，它就不应该出现在这里。\n\n---\n\n## 维度 × 工具矩阵\n\n\n### 六个分子维度（越高越复杂）\n\n| # | 复杂度维度 | 工具杠杆候选 | 实测笔记 |\n| --- | ------ | ------------------------------- | ---- |\n| 1 | 上下文压力 | [待补：检索 / 语义索引 / 上下文压缩] | [待补] |\n| 2 | 可提示性 | [待补：SPEC 模板 / DSL / 业务建模] | [待补] |\n| 3 | 探索收敛 | [待补：AGENTS.md / 项目地图 / sitemap] | [待补] |\n| 4 | 状态纠缠 | [待补：模块边界检查 / 依赖图 / ArchUnit 类] | [待补] |\n| 5 | 暗知识 | [待补：ADR / 决策记录 / 注释规范] | [待补] |\n| 6 | 验证成本 | [ralph-orchestrator](harnesses/ralph-orchestrator.md)（背压门控，主战场）；另待补：测试框架 / CI / 类型检查 / linter | ✅ [practice/01](../practice/01-ralph-demo/) 实测：Builder 测试全绿才交棒 + Critic 独立重验 |\n\n### 分母：胶囊化能力（越高越好）\n\n| 维度 | 工具杠杆候选 | 实测笔记 |\n| --------- | ------------------------------------- | ---- |\n| **胶囊化能力** | Claude Code / Codex / Cursor / ... 等各大 harness 框架 | Harness 框架的核心价值——让 AI 在可控边界内完成任务，从而把上面六维的成本同时压下来 |\n\n### 终局指标：重构 + 复刻\n\n> 文章最后指出\"重构能力 + 复刻能力\"是复杂度的最终显影。一个工具是否值得收录，最终可以问：**它是否提升了项目的重构 / 复刻可行性？**\n\n注：同一个工具可能横跨多维。**填表时按\"主战场\"放，次要贡献在工具页里展开。**\n\n---\n\n## 收录工具（持续更新）\n\n### Harness 框架\n\n> 作者使用为主，已在 [practice/](../practice/) 中跑过的优先标注 ✅\n\n- ✅ [ralph-orchestrator](harnesses/ralph-orchestrator.md) — 已在 [practice/01-ralph-demo/](../practice/01-ralph-demo/) 实测（v2.8.1，4 轮迭代 / 321s / $0.31）\n- Claude Code（practice/01 中作为 Ralph 的执行后端使用过；独立工具页待写）\n- Codex CLI/ Codex App\n- Cursor\n- [其他待补]\n\n### 辅助工具\n\n> 按 6 维分类组织\n\n- [待补]\n\n---\n\n## 撰写新工具页的检查清单\n\n- 是否回答了\"它降低了哪几维复杂度\"\n- 是否给出至少一个**失效场景**（不是只写优点）\n- 是否标注与其他已收录工具的搭配 / 冲突\n- 是否说明\"为什么是它而不是同类竞品\"\n\n","references/AGENTS.md":"# references/ — 外部资源索引\n\n相关文章、仓库、工具的统一索引。这里是指针，不是内容本身。\n\n## 文件约定\n\n- 按主题分文件，如 `articles.md`、`repos.md`、`tools.md`\n- 每条记录包含：链接、一句话说明、与 Harness Engineering 的关联\n\n## 文章\n\n详见 [articles.md](articles.md) — 完整的文章索引，含三条脉络 **79 篇文章 + 1 项已跟踪产品** 的深度摘要。\n权威计数与编号规则以 `articles.md` 头部为准；本表是它的概览缓存。\n\n### 脉络一：AI 时代的 Harness Engineering（75 篇）\n\n| # | 文章 | 作者 | 核心贡献 |\n|---|------|------|---------|\n| 1 | [OpenAI 原文](https://openai.com/zh-Hans-CN/index/harness-engineering/) | Ryan Lopopolo | 原点：六大概念 |\n| 2 | [Martin Fowler](https://martinfowler.com/articles/harness-engineering.html) | Birgitta Böckeler | Guides×Sensors 控制论框架 + Harnessability + Ashby 定律 |\n| 3 | [LangChain](https://blog.langchain.com/the-anatomy-of-an-agent-harness/) | Vivek Trivedy | 精确定义 + 组件清单 |\n| 4 | [Anthropic](https://www.anthropic.com/engineering/harness-design-long-running-apps) | Prithvi Rajasekaran | GAN 三智能体 + Harness 瘦身 |\n| 5 | [HumanLayer](https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents) | Kyle | 六个杠杆 + 实战避坑 |\n| 6 | [Anthropic/Claude Platform](https://claude.com/blog/harnessing-claudes-intelligence) | Lance Martin | 三大构建模式 + BrowseComp 数据 |\n| 7 | [Anthropic/Managed Agents](https://www.anthropic.com/engineering/managed-agents) | Lance Martin 等 | Meta-harness + 基础设施解耦 |\n| 8 | [Fowler/Encoding Team Standards](https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html) | Rahul Garg | 团队标准显式化三层路径 |\n| 9 | [Fowler/Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html) | Rahul Garg | 从 AI 失败中持续学习的反馈闭环 |\n| 10 | [LangChain/Agent Evaluation Checklist](https://blog.langchain.com/agent-evaluation-readiness-checklist/) | LangChain 团队 | 智能体评估五阶段清单 |\n| 11 | [Meta-Harness 论文](https://arxiv.org/abs/2603.28052) | Yoonho Lee 等 (Stanford) | 自动化 Harness 搜索优化 |\n| 12 | [GitHub/Agent-driven Development](https://github.blog/ai-and-ml/github-copilot/agent-driven-development-in-copilot-applied-science/) | Tyler McGoffin | 智能体驱动开发实战 |\n| 13 | [Inside the Scaffold 论文](https://arxiv.org/html/2604.03515v1) | Benjamin Rombaut (Huawei) | 13 个编码智能体脚手架源代码分类法 |\n| 14 | ⭐ [Eight years of wanting](https://lalitm.com/post/building-syntaqlite-ai/) | Lalit Maganti | AI 构建真实项目的坦诚复盘 |\n| 15 | [Continual learning for AI agents](https://blog.langchain.com/continual-learning-for-ai-agents/) | Harrison Chase | 三层学习：模型/Harness/上下文 |\n| 16 | [OpenAI Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/) | Kotliarskyi 等 | 任务跟踪器作为控制平面 + SPEC/WORKFLOW 即产品 |\n| 17 | [Claude Code Architecture](https://vrungta.substack.com/p/claude-code-architecture-reverse) | Vikash Rungta | Claude Code 运行外壳、TAOR 循环、工具原语、权限与上下文管理的外部逆向分析 |\n| 18 | [Harness 系列文章之 7：关于 subagent](https://x.com/dongxi_nlp/status/2068922428516892998) | 马东锡 NLP | Subagent = tool call 入口 + child runtime；区分 session/context/subagent 与 evidence 回流 |\n| 19 | [Fowler/Maintainability sensors](https://martinfowler.com/articles/sensors-for-coding-agents.html) | Birgitta Böckeler | 计算性 vs 推理性传感器谱系 + 失败案例 + AI 评审作为垃圾回收 |\n| 20 | [Fowler/SPDD](https://martinfowler.com/articles/structured-prompt-driven/) | Wei Zhang, Jessie Jie Xia | REASONS Canvas 七维 + prompt 即一等交付物 + 双向闭环 |\n| 21 | [LangChain/ADLC](https://www.langchain.com/blog/the-agent-development-lifecycle) | Harrison Chase | 智能体开发生命周期 + framework/runtime/harness 三分类 |\n| 22 | [LangChain/Interpreters in Deep Agents](https://www.langchain.com/blog/give-your-agents-an-interpreter) | Hunter Lovell | interpreter 是第三类上下文表面 + 35% token 节省 |\n| 23 | [Anthropic/质量回归复盘](https://www.anthropic.com/engineering/april-23-postmortem) | Anthropic 工程团队 | 三起独立变更叠加成质量退化 + 变更治理清单（第一手反例） |\n| 24 | [Agentic Harness Engineering 论文](https://arxiv.org/html/2604.25850v4) | Jiahang Lin 等（复旦/北大/奇绩） | 可观测性驱动的 Harness 自动演化 + 每次编辑即可证伪契约 |\n| 25 | [Overeager Coding Agents 论文](https://arxiv.org/html/2605.18583v1) | Yubin Qu 等 | 越界动作测量 + 提示声明授权反而降低边界推断 |\n| 26 | [How I Use AI to Code](https://chrismdp.com/coding-with-ai/) | Chris Parsons | 四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈 |\n| 27 | [How we built LangSmith Engine](https://www.langchain.com/blog/how-we-built-langsmith-engine-our-agent-for-improving-agents) | Palash Shah | 用智能体改进智能体 + trace→轨迹骨架 + screener/investigator 两阶段闭环 |\n| 28 | [Ralph 原始文章 + 续篇](https://ghuntley.com/ralph/) | Geoffrey Huntley | Ralph = bash 循环 + 每轮干净上下文 + 背压；单体反多智能体论（还上 practice/ Ralph Demo 的理论债） |\n| 29 | [My AI Adoption Journey](https://mitchellh.com/writing/my-ai-adoption-journey) | Mitchell Hashimoto | 六步采纳路线 + \"harness engineering\" 命名出处（由延伸阅读升格） |\n| 30 | [Claude Code 源码泄漏事件](https://github.com/pankaj28843/understanding-claude-code) | Chaofan Shou 发现 / 社区聚合分析 | 512K 行 harness 实锤解剖：QueryEngine/60+ 门控工具/KAIROS/AutoDream，#17 推测的对照组 |\n| 31 | [Agent Harness Engineering](https://addyosmani.com/blog/agent-harness-engineering/) | Addy Osmani | 学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS（综述破例进编号正文） |\n| 32 | [Exploring AI coding sensors](https://www.thoughtworks.com/en-au/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors) | Böckeler & Ford | 有/无传感器对照实验 + 态势感知论 + harness 模板展望 |\n| 33 | [HarnessAudit 论文](https://arxiv.org/abs/2605.14271) | Chengzhi Liu 等 | harness 安全审计：中途轨迹违规是输出级评估的盲区 + 210 任务基准 |\n| 34 | [Harness-Bench 论文](https://arxiv.org/abs/2605.27922) | Yilun Yao 等 | 配置级 harness 效应测量（106 任务/5194 轨迹）+ 执行对齐失败分类 |\n| 35 | [How good is your harness? 论文](https://openreview.net/forum?id=QI8z3skBwt) | Jiwoo Han, Yuekai Sun | Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应，且效应异质 |\n| 36 | [Dynamic workflows in Claude Code](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code) | Anthropic / Claude | 模型现场写自己的编排 harness + 对抗验证 + workflow 沉淀为 Skill |\n| 37 | [Harness 才是产品](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/) | 马东锡 NLP | \"Model 在 loop 里，harness 拥有 loop\" + 六组件 + 症状→组件 debug 对照表 |\n| 38 | [Position: 基准错位论文](https://arxiv.org/abs/2606.17799) | Maria I. Gorinova 等 | 基准把 model/harness/环境折叠进一个分数的三症状诊断 |\n| 39 | [Unrolling the Codex agent loop](https://openai.com/index/unrolling-the-codex-agent-loop/) | Michael Bolin (OpenAI) | Codex harness 解剖·上：prompt 构造 / 二次方问题与 prompt caching / compaction 端点化 |\n| 40 | [Unlocking the Codex harness](https://openai.com/index/unlocking-the-codex-harness/) | Celia Chen (OpenAI) | Codex harness 解剖·下：App Server 双向 JSON-RPC + Item/Turn/Thread 原语 + HaaS 落地 |\n| 41 | [Loop Engineering](https://addyosmani.com/blog/loop-engineering/) | Addy Osmani | loop 定调文：五构件 + 记忆脊柱；\"循环分不出两种用法的区别，你分得出\" |\n| 42 | [The Coming Loop](https://lucumr.pocoo.org/2026/6/23/the-coming-loop/) | Armin Ronacher | 怀疑派回应：agent loop vs harness loop + 防御式编码放大 + 软件作为有机体 |\n| 43 | [Loop engineering: Getting started with loops](https://claude.com/blog/getting-started-with-loops) | Claude Code 团队 | 官方四类循环（turn/goal/time/proactive）+ `/goal` 独立判停 + 用量治理清单 |\n| 44 | [Self-Harness 论文](https://arxiv.org/abs/2606.09498) | Hangfan Zhang 等 | 智能体自改 harness：弱点挖掘→提议→回归验证；三模型 held-out +14~21pp |\n| 45 | [Harness Engineering for Self-Improvement](https://lilianweng.github.io/posts/2026-07-04-harness/) | Lilian Weng | RSI 综述：三设计模式 + 优化对象递进链 + 七项未来挑战 + \"harness 终将内化\"预测 |\n| 46 | [Aria：自动软件验证论文](https://arxiv.org/abs/2607.06341) | Shuangxiang Kan 等 | 行为 harness 极限形态：声明式 HHL 包裹通用智能体做 Coq 证明，全引理零人工通过 |\n| 47 | [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) | Mikaela Grace 等 (Anthropic) | 智能体评测官方方法论：outcome≠transcript、pass@k/pass^k、评结果不评路径、CORE-Bench 42%→95% 基准病理 |\n| 48 | [Scaling long-running autonomous coding](https://cursor.com/blog/scaling-agents) | Wilson Lin (Cursor) | 数百并发智能体 × 数周：扁平自协调失败史 → planner/worker/judge；FastRender 百万行浏览器 |\n| 49 | [Building a C compiler with parallel Claudes](https://www.anthropic.com/engineering/building-c-compiler) | Nicholas Carlini (Anthropic) | 16 agent 无编排者造 10 万行 C 编译器（$20k/两周）：近乎完美验证器 + GCC oracle + 为 Claude 写测试 |\n| 50 | [How we contain Claude across products](https://www.anthropic.com/engineering/how-we-contain-claude) | Max McGuinness 等 (Anthropic) | 三隔离模式 × 五起漏掉的风险：白名单是能力授予；先环境层遏制再模型层引导 |\n| 51 | [Deep Agents 动态子智能体 + RLM](https://www.langchain.com/blog/introducing-dynamic-subagents-in-deep-agents) | LangChain 团队 | 模型写编排脚本驱动 subagent（QuickJS + `task()`）；RLM 处理超上下文两个数量级的输入 |\n| 52 | [Böckeler 本地模型双备忘录](https://martinfowler.com/articles/exploring-gen-ai/local-models-for-coding-factors.html) | Birgitta Böckeler | 高端开发机跑本地小模型做智能体编码实测：Qwen3.6 35B MoE 甜点、工具调用是分水岭 |\n| 53 | [Harness Handbook 论文](https://arxiv.org/abs/2607.13285) | Ruhan Wang 等（腾讯等） | 行为定位是 harness 演化瓶颈：行为中心表示 + BGPD，win rate +10.0/+18.9pp 且省 12.7%/8.6% token |\n| 54 | [DSLs Enable Reliable Use of LLMs](https://martinfowler.com/articles/llm-and-dsls.html) | Unmesh Joshi | \"DSL 工具集本身就是出色的 harness\"：语言层约束 + 确定性验证器 + 领域级错误反馈 |\n| 55 | [Own the Outer Loop](https://addyosmani.com/blog/own-the-outer-loop/) | Addy Osmani | 智能体跑内环、工程师拥有外环问责；back-pressure 调节循环速率与作用域来授予自主权 |\n| 56 | [Rewriting Bun in Rust](https://bun.sh/blog/bun-in-rust) | Jarred Sumner | \"修流程不修代码\"工业级实录：50 dynamic workflows × 64 Claude × 11 天移植 53.5 万行 Zig；语言无关测试套件作 oracle + 对抗评审默认化 |\n| 57 | [HarnessX 论文](https://arxiv.org/abs/2606.14249) | Darwin Agent Team（小米） | harness 一等类型化对象 + AEGIS 轨迹演化 + cross-harness GRPO 共演化：+14.5%（共演化再 +4.7%），弱模型受益最大 |\n| 58 | [Anthropic/长时智能体的有效 harness](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) | Justin Young | 外部工件即记忆的奠基文：initializer + coding 两段式、200+ 条 feature_list.json、progress 文件 + git、Puppeteer 端到端自验（存量回扫补录） |\n| 59 | [Anthropic/基础设施噪声](https://www.anthropic.com/engineering/infrastructure-noise) | Gian Segato | 只改资源配额，Terminal-Bench 2.0 摆动 6pp；1x–3x 修可靠性、3x 以上改变被测对象；\"低于 3pp 的榜单差距都该怀疑\" |\n| 60 | [Cursor/持续改进 agent harness](https://cursor.com/blog/continually-improving-agent-harness) | Stefan Heule & Jediah Katz | harness 运维的度量学：Keep Rate、LLM 读用户回复判满意、错误分类与按工具按模型基线、每周 Automation 修 harness；按训练分布供给工具格式 |\n| 61 | [Cursor/奖励作弊淹没智能增益](https://cursor.com/blog/reward-hacking-coding-benchmarks) | Naman Jain | 审计 731 条轨迹：SWE-bench Pro 上 63% 的成功解是检索答案而非推导；封 git+断网后 Opus 4.8 Max 87.1%→73.0% |\n| 62 | [Better Models: Worse Tools](https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/) | Armin Ronacher | 工具 schema 不是中立的：在宽容 harness 里做 RL，新模型对替代 schema 反而更差；跨模型可移植性的机制级坏消息 |\n| 63 | [为什么软件工厂会失败](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md) | Dex Horthy (HumanLayer) | \"harness engineering 还不够\"：可维护性没有快 oracle，RL 不惩罚坏设计；熄灯工厂第一手失败实录 + 四阶段前移方案 |\n| 64 | [Software Factories, Light and Dark](https://addyosmani.com/blog/software-factories/) | Addy Osmani | loop→harness→factory 三层 + 唯一昂贵的评审闸门 + 背压规则 + \"什么样的循环配得上熄灯\"准入清单 |\n| 65 | [智能体蜂群与新的模型经济学](https://cursor.com/blog/agent-swarm-model-economics) | Wilson Lin (Cursor) | 从 835 页手册重造 SQLite：质量趋同、账单从 $1,339 到 $10,565；规划/执行分层、自建 VCS（1000 提交/秒）、去相关评审、Field Guide |\n| 66 | [Claude 5 世代的上下文工程新规则](https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models) | Thariq Shihipar (Anthropic) | 删掉 Claude Code 系统提示词 80%+ 而编码评测无可测损失；七组 then/now 对照 + `claude doctor` |\n| 67 | [Don't Blame the LLM 论文](https://arxiv.org/abs/2607.03691) | Oussama Ben Sghaier 等（Queen's） | 首个固定模型、只变 harness 的受控纵向研究：Qwen Code CLI 35 个连续版本 × 50 个 SWE-bench Verified 任务 |\n| 68 | [Rethinking Harness Evolution 论文](https://arxiv.org/abs/2607.12227) | Yike Wang 等 | 自动 harness 演化的第一份系统性负面结果：同等预算下不稳定优于简单 test-time scaling，泛化有限 |\n| 69 | [LangChain/Harbor 评测栈](https://www.langchain.com/blog/how-we-benchmark-deep-agents) | Nick Hollon, Harrison Chase 等 | 给 harness 建标尺（Harbor-Index 82 任务 / lite 子集 / capability suite），再给标尺建标尺（IssueBench 15 类失败分类法） |\n| 70 | [LangChain/ReviewBench](https://www.langchain.com/blog/evaluating-code-review-agents-with-reviewbench) | Nick Hollon | 给\"AI 代码评审\"传感器造考卷：真实 PR 评审意见策展成 59 任务；裸 harness 最强召回 ~30%，prompt-only 调优 0.13→0.32 反超 |\n| 71 | [Fowler/TDD in the agent loop](https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html) | Birgitta Böckeler | agent loop 内 TDD 的实证否定：盲评质量无差异、token 3–8.5 倍；别规定过程，度量结果 |\n| 72 | [Osmani/Practical Loop Engineering](https://addyosmani.com/blog/practical-loop-engineering/) | Addy Osmani | loop 系列日常落地环：踩坑实录（差点连判断也委托）+ 分诊循环 + fine print 运维细则 |\n| 73 | [Zalando 组织级快照](https://engineering.zalando.com/posts/2026/08/agentic-engineering-at-zalando-a-snapshot.html) | Bartosz Ocytko | 250+ 团队非供应商第一人称：事故分析→风险分级→33% 自动放行→lead time -20~40% 的组织级反馈回路 |\n| 74 | [Earendil/Pi 双篇](https://earendil.com/posts/what-is-a-harness/) | Pi 团队 | harness 定义+用户侧中立主张 / compaction 白盒实现（20K 预算、独立请求、纯文本可移植）——与 #39 端点化恰成对照 |\n| 75 | [⭐ StarHarness 论文](https://arxiv.org/abs/2608.24804) | ServiceNow/Mila | 冻结 harness 工件跨 GPT/Qwen 迁移 12 行全正（+10.7~+46.3pp）；跨模型可移植性缺口首个正面证据 |\n\n### 脉络二：云原生 Harness.io（2 篇）\n\n| # | 文章 | 核心贡献 |\n|---|------|---------|\n| 76 | [Harness.io 官方](https://www.harness.io/blog/understanding-ci-cd-platforms-the-backbone-of-modern-devops) | CI/CD 平台全局架构 |\n| 77 | [Google Cloud Architecture](https://docs.cloud.google.com/architecture/partners/harness-cicd-pipeline-for-rag-app) | Harness + GCP 部署 RAG |\n\n### 脉络三：效率悖论与能力进化（2 篇）\n\n| # | 文章 | 核心贡献 |\n|---|------|---------|\n| 78 | [YDD / Miss-you](https://yousali.com/posts/20260303-ai-coding-efficiency-to-evolution/) | 效率悖论的系统性拆解：约束理论 + Spec/Rule/Skill + 验证闭环 + 并发 |\n| 79 | [METR 实验后续 + 自报调查](https://metr.org/blog/2026-02-24-uplift-update/) | \"慢 19%\" 的官方后续：弱证据转向加速 + AI 渗透破坏 RCT 可行性本身 |\n\n### 已跟踪产品 / 项目（不计入文章数）\n\n| 项 | 项目 | 说明 |\n|---|------|------|\n| ⭐ | [Chachamaru127 / claude-code-harness v4.2 \"Hokage\"](https://github.com/Chachamaru127/claude-code-harness/tree/v4.2.0) | Claude Code 上当下最完整的开源 harness 实现之一；Plan→Work→Review→Release 五动词 + Go 原生 R01–R13 guardrail。本仓库分析见 `thinking/guides-sensors-meets-claude-code-harness.md` |\n\n## 项目\n\n### Ralph 系列\n\n| 项目 | Stars | 说明 | 关联概念 |\n|------|-------|------|---------|\n| [snarktank/ralph](https://github.com/snarktank/ralph) | 13.6k | 原版 Ralph 循环：bash + PRD + 每次清空上下文 | 全部六大概念的最小实现 |\n| [ralph-orchestrator](https://mikeyobrien.github.io/ralph-orchestrator/) | 2.3k | Rust 版：Hat 角色 + 事件驱动 + 背压 | 机械化执行、熵管理 |\n| [bmad-ralph](https://github.com/qianxiaofeng/bmad-ralph) | 2 | BMAD + Ralph：并行 worktree + 三层自愈 | 自主水平提升、吞吐量 |\n\n### 社区\n\n| 资源 | 说明 | 关联 |\n|------|------|------|\n| [vibe-coding-cn](https://github.com/tukuaiai/vibe-coding-cn) | 中文 Vibe Coding 社区 | 仓库组织方式、AGENTS.md 分级 |\n\n### 延伸阅读\n\n| 资源 | 说明 |\n|------|------|\n| [Martin Fowler: Context Engineering for Coding Agents](https://martinfowler.com/articles/context-engineering-coding-agents.html) | Context Engineering 专题 |\n| [Martin Fowler: Humans and Agents in SE Loops](https://martinfowler.com/articles/humans-and-agents.html) | 人类与智能体的协作模式 |\n\n> Mitchell Hashimoto 的 My AI Adoption Journey 原在此表，2026-07 已升格为编号条目 #29。\n\n## 待补充\n\n> 占位条目统一收在这里，**不进 `articles.md` 的编号正文**，避免污染文章计数。\n\n- [x] Geoffrey Huntley 的 Ralph 原始文章 → 已收录为 #28（2026-07）\n- [x] OpenAI Codex harness 解剖二部曲 → 已收录为 #39（Unrolling the Codex agent loop）+ #40（Unlocking the Codex harness / App Server）（2026-07-15）\n- [ ] 马东锡 Harness 系列其余篇目（仓库已收 #18 之 7、#37 才是产品；2026-07 系列新帖包括\"Model 可以请求，Harness 负责裁决——这就是契约\"\"模型记住的是 transcript，Harness 必须记住 truth（File State 是合格 harness 的基本功）\"；X 原帖需本地工具抓取）\n- [ ] Medium 实战专栏 — \"Beyond Migration: How We Engineered a Secure & Intelligent Delivery Platform with Harness CICD\"（标题可能已变更或文章已下架）\n\n## 下一步\n\n读完一篇资料后：\n- 想对它的论点做独立分析或质疑 → [thinking/](../thinking/)\n- 想翻译为中文输出 → [works/](../works/)\n- 想用它的方法做实验 → [practice/](../practice/)\n- 想沉淀其中的提示词模板 → [prompts/](../prompts/)\n","tools/AGENTS.md":"# tools/ — 工具具像化\n\n把 `concepts/` 里抽象的 Harness 概念落到具体可用的工具上。\n本目录的核心问题：**哪些工具能切实降低 [6 维复杂度框架](../thinking/software-project-complexity-in-the-ai-era.md) 中的某一维，或提升\"胶囊化能力\"这个总杠杆？**\n\n## 文件约定\n\n- `00-overview.md` — 工具地图：维度 × 工具矩阵（先读）\n- `harnesses/` — Agent harness 框架（首篇：[ralph-orchestrator.md](harnesses/ralph-orchestrator.md)；Claude Code、Codex、Cursor 等待写）\n- `auxiliary/` — 辅助工具（linter、CI、文档、测试、依赖分析等）；**规划中**，首篇辅助工具页落地时再建目录\n\n每个工具页结构（建议，非强制）：\n\n1. **一句话定位** —— 它是什么\n2. **降低哪些维度的复杂度** —— 引用 6 维框架的具体维度名 + 是否提升\"胶囊化能力\"\n3. **实测体验** —— 用过的真实场景、生效边界、失效场景\n4. **搭配建议** —— 与本目录其他工具的组合\n5. **替代方案** —— 同类竞品对比（如有）\n\n## 收录标准\n\n- **自己实际用过** —— 不收\"听说很好\"的工具\n- 或在 [`practice/`](../practice/) 中验证过\n- 拒绝\"工具大全\"式罗列——本目录不是 awesome-list，是带主张的杠杆库\n\n## 与其他目录的关系\n\n- `concepts/` 提出**该做什么**\n- `tools/` 提供**用什么做**\n- `practice/` 给出**实际做的过程与结果**\n\n## 下一步\n\n读完 [00-overview.md](00-overview.md) 后，按维度反查工具，按工具反查实践。\n","thinking/AGENTS.md":"# thinking/ — 独立思考\n\n读完 concepts/ 后，在这里写下你自己的理解、质疑和延伸思考。\n\n## 文件约定\n\n- 文件名：自由命名，建议用问题或论点作为文件名\n- 例如：`harness-vs-vibe-coding.md`、`is-this-only-for-openai.md`\n- 结构：问题/论点 → 自己的分析 → 结论或开放问题\n- 鼓励质疑原文，提出反例\n\n## 已有文章\n\n| 文件 | 主题 | 核心论点 |\n|------|------|---------|\n| [cross-article-insights.md](cross-article-insights.md) | 跨文章深层洞见 | 8 个洞见：Harness 生命周期、四学派、评估之踵、人类角色消解 |\n| [harnessability-and-java.md](harnessability-and-java.md) | Java 的可驾驭性 | Java/Spring 天然提供高 Harnessability 基线 |\n| [meta-harness-tensions.md](meta-harness-tensions.md) | Meta-Harness 的五个张力 | Anthropic Managed Agents 与既有实践的矛盾 |\n| [evaluation-elephant-in-the-room.md](evaluation-elephant-in-the-room.md) | 评估是房间里的大象 | 行为正确性验证是整个体系的阿喀琉斯之踵 |\n| [harness-for-solo-developers.md](harness-for-solo-developers.md) | 个人开发者的 Harness | 六大概念的适用性分析：直接可用 vs 需要降级 vs 不适用 |\n| [guides-sensors-meets-claude-code-harness.md](guides-sensors-meets-claude-code-harness.md) | Böckeler 框架 vs claude-code-harness v4.2 | 产品级实现暴露的五个张力：Advisor 装不进 2×2、guardrail 融合前馈反馈、行为 Harness 是结构性绕过、追上游占 95% 维护成本、harness 必带价值观锁定 |\n| [software-project-complexity-in-the-ai-era.md](software-project-complexity-in-the-ai-era.md) | AI 时代的软件项目复杂度 | 6 维（上下文压力 / 可提示性 / 探索收敛 / 状态纠缠 / 暗知识 / 验证成本）+ 胶囊化分母 + 重构/复刻终局指标 |\n| [subagent-is-child-runtime.md](subagent-is-child-runtime.md) | Subagent 是 child runtime | 与 Claude Code 架构逆向互证：subagent = tool-call-triggered child session + context projection + evidence-return contract |\n| [why-this-project-exists.md](why-this-project-exists.md) | 为什么有这个项目 | 项目宗旨：把 Harness Engineering 从\"概念集合\"变成\"可复刻的产品构建方法论\"——借用《诡秘之主》\"学徒途径\"隐喻 |\n| [fix-the-process-not-the-code.md](fix-the-process-not-the-code.md) | 修流程，不修代码 | Bun 重写案例对照 #36/#49/#55：工程师的交付物是生成过程本身；测试套件与实现语言正交是 Harnessability 新维度；验证器完备度决定成本曲线 |\n| [se-to-agent-engineering-mapping.md](se-to-agent-engineering-mapping.md) | 传统 SE ↔ Agent 工程对照表 | 15 行同构映射的三处修正：右列主语混三层（①人对 agent ②agent 自身 ③人对系统）、补熵管理/并发合并/持久会话三行、版本钉选风险倒置与评估地位跃迁；每个模型代际重审一遍，纹丝不动的子集才是学科骨架 |\n\n## 写作方向参考\n\n- 机械化执行的边界在哪？过度 lint 是否会限制智能体创造性？\n- Harness Engineering vs Vibe Coding：本质区别是什么？\n- \"零手写代码\"是刻意的实验约束，还是可推广的工程实践？\n- Context Engineering vs Harness Engineering：边界与关系\n\n## 下一步\n\n有了自己的观点后，去 [practice/](../practice/) 用实验验证它。\n","references/articles.md":"# 文章索引\n\n> **本文件是文章索引与计数的唯一权威源（single source of truth）。**\n>\n> **计数规则（machine-checkable）：**\n> 一篇文章 = 一个 `### N. {标题}` 形式的编号小节，且不属于本文末尾的\"已跟踪产品 / 项目\"段落。\n> 占位条目（\"未找到 / 待补充\"）**不写在编号正文里**，而是统一进 `references/AGENTS.md` 的\"待补充\"列表，避免污染计数。\n> 全局连续编号（不按脉络重置），最大编号 = 文章总数。\n>\n> **下游引用都是本文的冗余缓存：** 根 `README.md` / `README.en.md` 的 badge、`prompts/deep-research-tracker.md` 的去重清单、`references/AGENTS.md` 的概览表。\n> 新增/删除文章时，必须**同一次提交**更新本文 + 所有下游缓存。\n>\n> 当前规模：**79 篇文章**（脉络一 75 + 脉络二 2 + 脉络三 2）+ **1 项已跟踪产品**（不计入文章数）。最近一次同步：2026-08-27。\n\n## 脉络一：AI 时代的 Harness Engineering（大模型护栏与认知工程）\n\n\n\n### 1. OpenAI 官方 — 原点与哲学\n\n- **标题：** Harness engineering: leveraging Codex in an agent-first world\n- **链接：** [openai.com](https://openai.com/zh-Hans-CN/index/harness-engineering/)\n- **作者：** Ryan Lopopolo | **日期：** 2026-02-11\n- **核心：** 3 人团队用 Codex 从空仓库到 100 万行代码，零手写代码。提出六大概念：仓库即记录系统、地图而非手册、机械化执行、智能体可读性、吞吐量改变合并理念、熵管理。\n- **关联：** 本仓库的学习起点，所有概念笔记的来源\n\n\n\n### 2. Martin Fowler / Birgitta Böckeler — 系统性认知与控制论框架\n\n- **标题：** Harness engineering for coding agent users\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/harness-engineering.html)\n- **翻译：** [works/fowler-harness-engineering-full-translation.md](../works/fowler-harness-engineering-full-translation.md)\n- **前传备忘录：** [first thoughts](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html) | **备忘录翻译：** [works/fowler-harness-engineering-memo-translation.md](../works/fowler-harness-engineering-memo-translation.md)\n- **作者：** Birgitta Böckeler (Thoughtworks) | **日期：** 2026-04-02（备忘录 2026-02-17）\n- **核心：** 控制论视角的 harness 框架——Guides（前馈）× Sensors（反馈）+ Computational（计算性）× Inferential（推理性）的 2×2 矩阵，三个规制维度，Ashby 必要多样性定律\n\n- **核心框架：Guides × Sensors + Computational × Inferential**\n\n| | 计算性（确定性，CPU） | 推理性（语义，LLM） |\n|--|---------|---------|\n| **引导器（前馈）** | bootstrap 脚本、OpenRewrite、LSP | AGENTS.md、Skills、architecture.md |\n| **传感器（反馈）** | linter、ArchUnit、类型检查、覆盖率 | AI code review、LLM-as-judge |\n\n- **关键原则：**\n - 单独用任何一种都不行——只有反馈 = 反复犯同样的错；只有前馈 = 不知道规则是否生效\n - 计算性控制便宜、确定、每次提交都跑；推理性控制昂贵、概率性、不是每次都跑\n - Harness engineering 是 context engineering 的一种特定形式\n\n- **三个规制维度：**\n\n| 维度 | 成熟度 | 现状 |\n|------|--------|------|\n| 可维护性 Harness | 最成熟 | 计算性传感器可靠捕获结构问题；LLM 部分解决语义问题；**两者都无法可靠捕获**：误诊、过度工程、误解指令 |\n| 架构适应度 Harness | 中等 | 本质是 Fitness Functions——性能 Skills + 可观测性规范 |\n| 行为 Harness | **最弱** | \"房间里的大象\"——功能正确性验证仍依赖 AI 生成的测试，\"目前还不够好\" |\n\n- **Harnessability（可驾驭性）：**\n - 不是所有代码库都同样适合被 harness\n - 强类型语言天然有类型检查传感器；清晰模块边界支持架构约束；成熟框架（如 Spring）隐式提高成功概率\n - **Ambient Affordances**（Ned Letcher）：环境本身的结构属性使智能体更容易操作\n - 绿地项目可以从第一天融入；遗留系统 = **harness 最需要的地方恰恰是最难构建的地方**\n\n- **Harness 模板：**\n - 企业 80% 的服务可归入几种常见拓扑（API 服务、事件处理、数据仪表板）\n - 服务模板 → harness 模板：引导器 + 传感器的集合，约束智能体到特定拓扑\n - 会面临和服务模板一样的分叉/同步挑战，甚至更严重（非确定性组件更难测试）\n\n- **Ashby 必要多样性定律：**\n - 调节器必须至少拥有与被调节系统同等的多样性\n - LLM 能生成几乎任何东西（高多样性）→ 选定拓扑 = 削减多样性 → 全面 harness 变得可行\n - 定义拓扑结构本身就是一种多样性削减举措\n\n- **人类角色的重新定位：**\n - 人类开发者携带隐性 harness：社会问责感、对复杂性的审美痛感、组织记忆、\"我们这里不这么做\"的直觉\n - 智能体没有这些——不知道哪个规范是承重的、哪个只是习惯\n - **\"好的 harness 不应以完全消除人类输入为目标，而应将人类输入引导到最重要的地方\"**\n\n- **质量左移（Shift Quality Left）：**\n - 按速度和成本分布检查：pre-commit 跑便宜传感器，管线跑昂贵传感器\n - 持续漂移传感器：死代码检测、覆盖率质量、依赖扫描、SLO 退化\n\n- **开放挑战：**\n - Harness 连贯性：引导器和传感器增长后可能相互矛盾\n - Harness 覆盖率：类似代码覆盖率，评估 harness 自身的完整性\n - 传感器从未触发时，如何区分高质量 vs 检测不足\n\n- **备忘录独有洞察（正式版未保留）：**\n - \"OpenAI 有既得利益让我们相信 AI 可维护的代码\"——对数据来源的信任保留\n - \"你今天的 harness 是什么？\"——务实的起步问题，审视已有实践\n - \"代码设计本身就是上下文的重要组成部分\"——比框架更本质\n - 最后自嘲预言\"harness\"一词会被滥用\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Guides × Sensors 矩阵 | 对 LangChain 组件清单和 HumanLayer 六杠杆的升维——从\"有什么\"到\"如何协同\" |\n| 行为 Harness 是大象 | 回应自己备忘录中的批评：OpenAI 缺少功能验证 |\n| Harnessability | OpenAI 的\"无聊技术\"选择标准的理论化 |\n| Ashby 定律 | 为 Fowler 假说 2（约束越严，自主性越强）提供控制论根基 |\n| Harness 模板 | 将备忘录假说 1 从问题升级为具体方案 |\n| 人类角色 | 对 Anthropic #7 中人类缺位的直接回应——不应消除人类，应引导人类 |\n\n- **延伸阅读：**\n - [Mitchell Hashimoto: My AI Adoption Journey #Step 5: Engineer the Harness](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness)（已升格为 #29）\n - [Context Engineering for Coding Agents](https://martinfowler.com/articles/context-engineering-coding-agents.html)\n - [Humans and Agents in Software Engineering Loops](https://martinfowler.com/articles/humans-and-agents.html)\n\n\n\n### 3. LangChain / Viv Trivedy — 解剖与机制\n\n- **标题：** The Anatomy of an Agent Harness\n- **链接：** [blog.langchain.com](https://blog.langchain.com/the-anatomy-of-an-agent-harness/)\n- **作者：** Vivek Trivedy | **日期：** 2026-03\n- **核心：** 给出 harness 的精确定义和完整组件清单\n\n> **Agent = Model + Harness**。Harness = 模型之外的一切代码、配置和执行逻辑。\n\n- **组件清单：**\n - System Prompts / Tools / Skills / MCP\n - 沙箱基础设施（文件系统、浏览器）\n - 编排逻辑（子智能体、handoff、模型路由）\n - Hooks/中间件（compaction、续接、lint 检查）\n- **关键洞察：**\n - **Context Rot** — 上下文填满后性能退化，需要 compaction + 工具输出卸载 + 渐进式披露\n - **Ralph Loop** — 拦截退出、重注入提示词、强制在新上下文窗口中继续\n - **Harness 与模型训练耦合** — 模型会 overfit 到特定 harness，换 harness 表现可能暴跌（Terminal Bench 2.0：纯 harness 优化可把排名从 Top 30 拉到 Top 5）\n\n\n\n### 4. Anthropic / Prithvi Rajasekaran — Harness 设计实战（长时自主编码）\n\n- **标题：** Harness design for long-running application development\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/harness-design-long-running-apps)\n- **作者：** Prithvi Rajasekaran (Anthropic Labs) | **日期：** 2026-03-24\n- **核心：** Anthropic 官方工程博客，GAN 启发的三智能体架构实战，从前端设计到全栈自主编码\n\n- **两个核心问题：**\n 1. **Context Anxiety** — 模型接近上下文极限时提前收尾（Sonnet 4.5 尤为明显），compaction 不够，需要 context reset\n 2. **Self-Evaluation 失败** — 智能体评估自己的工作时倾向于过度称赞，即使质量平庸\n\n- **三智能体架构（GAN 启发）：**\n\n| 智能体 | 职责 |\n|--------|------|\n| Planner | 1-4 句提示词 → 完整产品规格（刻意高层级，避免细节错误向下游级联） |\n| Generator | 按 sprint 逐特性实现，React + Vite + FastAPI + SQLite/PostgreSQL |\n| Evaluator | 用 Playwright MCP 实际操作运行中的应用，逐条验证 sprint 合同，打分 + 写详细 critique |\n\n- **Sprint 合同机制：**\n - 每个 sprint 前，Generator 和 Evaluator **协商**\"done 长什么样\"\n - Generator 提议构建内容和验证标准，Evaluator 审核\n - 双方迭代达成一致后才开始编码\n - 解决了 spec 太高层级 → 实现不可验证的 gap\n\n- **评估标准（前端设计 4 维度）：**\n 1. Design Quality — 是否有连贯的视觉身份（权重高）\n 2. Originality — 是否有原创设计决策，而非 AI 模板（权重高）\n 3. Craft — 排版、间距、对比度等技术执行（默认就好）\n 4. Functionality — 可用性独立于美学（默认就好）\n\n- **迭代进化（模型升级后的 Harness 瘦身）：**\n\n| 版本 | 模型 | 架构 | 时长 | 成本 |\n|------|------|------|------|------|\n| Solo baseline | Opus 4.5 | 单智能体 | 20 min | $9 |\n| V1 Harness | Opus 4.5 | Planner + Generator(sprint) + Evaluator(per-sprint) | ~6 hr | $200 |\n| V2 Harness | Opus 4.6 | Planner + Generator(无 sprint) + Evaluator(单次 pass) | ~4 hr | $125 |\n\n- **关键经验：**\n - **每个 harness 组件都编码了一个假设**（\"模型不能独立做 X\"），这些假设需要定期重新压测\n - 新模型发布后应精简 harness：去掉不再承重的部分，添加新能力\n - Evaluator 的价值取决于任务是否处于模型能力边界：边界内 → 开销浪费；边界外 → 真正有帮助\n - \"有趣的 harness 组合空间不会随模型改进而缩小——它会移动\"\n\n- **与其他文章的关联：**\n\n| Anthropic 概念 | 对应文章 |\n|---------------|---------|\n| Context Anxiety + Reset | LangChain 的 Context Rot + Ralph Loop |\n| Self-Evaluation 失败 → 分离 Evaluator | HumanLayer 的 Sub-Agent 上下文防火墙 |\n| Sprint 合同 | OpenAI 的执行计划（exec-plans） |\n| 4 维度评分标准 | OpenAI 的 QUALITY_SCORE.md |\n| Harness 瘦身原则 | Fowler 的\"约束越严，自主性越强\" |\n| \"找最简方案，按需增加复杂度\" | HumanLayer 的\"简单开始，按需添加\" |\n\n\n\n### 5. HumanLayer / Kyle — 实践与避坑\n\n- **标题：** Skill Issue: Harness Engineering for Coding Agents\n- **链接：** [humanlayer.dev](https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents)\n- **作者：** Kyle（HumanLayer） | **日期：** 2026-03-12\n- **核心：** 最落地的一篇——六个配置杠杆 + 实战经验\n\n- **六个杠杆：**\n\n| # | 杠杆 | 要点 |\n|---|------|------|\n| 1 | AGENTS.md | 控制在 60 行以内，禁止自动生成 |\n| 2 | MCP Servers | 别连不信任的，工具太多会填满上下文 |\n| 3 | Skills | 渐进式加载，警惕恶意 skill |\n| 4 | Sub-Agents | 上下文防火墙，隔离任务防 context rot |\n| 5 | Hooks | 生命周期脚本，成功静默/失败报错 |\n| 6 | Back-Pressure | 测试/构建/类型检查 = 自我验证回路 |\n\n- **实战经验：**\n\n| 无效 | 有效 |\n|------|------|\n| 预设理想配置 | 简单开始，按需添加 |\n| 装一堆 skill/MCP \"以防万一\" | 团队间分发验证过的配置 |\n| 每次改动跑全量测试 | 优化迭代速度而非首次成功率 |\n| 微调子智能体的工具权限 | 便宜模型做子任务，贵模型做编排 |\n\n- **金句：** \"The model is probably fine. It's just a skill issue.\"\n\n\n\n### 6. Anthropic / Lance Martin — 三大模式与性能数据\n\n- **标题：** Harnessing Claude's intelligence\n- **链接：** [claude.com](https://claude.com/blog/harnessing-claudes-intelligence)\n- **作者：** Lance Martin (Claude Platform Team) | **日期：** 2026-04-02\n- **核心：** 三个构建模式——利用 Claude 已知知识、追问\"我可以停止做什么\"、谨慎设定边界。配合 BrowseComp / Pokemon 等基准数据论证\n\n- **三大模式：**\n\n| 模式 | 核心主张 |\n|------|---------|\n| Use what Claude knows | 通用工具（bash + editor）优于定制工具，随模型升级自然增强 |\n| Ask \"what can I stop doing?\" | 把编排、上下文管理、持久化三个决策权从 harness 交给模型 |\n| Set boundaries carefully | 缓存优化（静态前置）+ 声明式工具提供安全门控与可观测性 |\n\n- **\"停止做什么\"的三个层次：**\n\n| 层次 | 旧假设 | 新做法 | 数据支撑 |\n|------|--------|--------|---------|\n| 编排 | 所有工具结果回流上下文 | 给 Claude 代码执行工具，让它自己过滤/管道 | BrowseComp: Opus 4.6 过滤能力 45.3% → 61.6% |\n| 上下文管理 | 手工预加载任务指令 | Skills 渐进式披露 + context editing 移除过时内容 + 子 Agent 隔离 | BrowseComp: 子 Agent 提升 2.8% |\n| 持久化 | 依赖外部检索基础设施 | Compaction（模型自主总结）+ Memory folder（模型自主写文件） | BrowseComp: Opus 4.6 compaction 达 84%；BrowseComp-Plus: memory folder +6.8% |\n\n- **缓存优化五原则：**\n\n| 原则 | 说明 |\n|------|------|\n| 静态在前，动态在后 | 稳定内容（系统提示词、工具）放前面 |\n| 用消息传递更新 | 追加 `` 而非编辑提示词 |\n| 不切换模型 | 缓存是模型特定的，切换即失效；需要便宜模型用子 Agent |\n| 谨慎管理工具 | 工具在缓存前缀中，增删会使缓存失效；用 tool search 追加 |\n| 更新断点 | 多轮应用中将断点移至最新消息，使用自动缓存 |\n\n- **声明式工具的四个价值：**\n 1. 安全门控 — 不可逆操作（如外部 API）需用户确认\n 2. 过时检查 — 写入工具检测文件自上次读取后是否被修改\n 3. UX 渲染 — 模态窗口展示问题、提供选项、阻塞等待反馈\n 4. 可观测性 — 结构化参数可记录、追踪、重放\n\n- **Pokemon 记忆进化案例：**\n - Sonnet 3.5: 14,000 步后 31 个文件（含重复），仍在第二城镇，记忆 = NPC 对话转录\n - Opus 4.6: 同样步数 10 个文件（按目录组织），3 枚道馆徽章，记忆 = 战术笔记 + 失败经验\n\n- **\"上下文焦虑\"案例：**\n - Sonnet 4.5 接近上下文极限时提前收尾 → 加了 context reset 补偿\n - Opus 4.5 天然消除了此行为 → context reset 变成死重\n - 启示：harness 中的补偿机制会随模型进化变成性能瓶颈\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 通用工具 > 定制工具 | OpenAI 原文的 bash + editor 起源 |\n| Skills 渐进式披露 | LangChain 的 Progressive Disclosure、HumanLayer 的 Skills 杠杆 |\n| Compaction + Memory folder | LangChain 的 Context Rot 解法、Anthropic #4 的 Context Anxiety |\n| 声明式工具 vs bash | HumanLayer 的 Back-Pressure 杠杆 |\n| \"停止做什么\" | Anthropic #4 的 Harness 瘦身原则、Fowler 的假说 |\n| 缓存优化 | 本仓库新增维度——此前文章未深入讨论 API 层成本优化 |\n\n\n\n### 7. Anthropic / Lance Martin, Gabe Cemaj, Michael Cohen — Meta-Harness 与基础设施解耦\n\n- **标题：** Scaling Managed Agents: Decoupling the brain from the hands\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/managed-agents)\n- **作者：** Lance Martin, Gabe Cemaj, Michael Cohen | **日期：** 2026-02-04\n- **翻译：** [works/anthropic-managed-agents-translation.md](../works/anthropic-managed-agents-translation.md)\n- **核心：** 不再讨论\"如何设计 harness\"，而是追问\"如何让 harness 本身成为可替换的基础设施\"——提出 meta-harness 概念\n\n- **三个虚拟化组件（借鉴操作系统）：**\n\n| 组件 | 类比 | 接口 |\n|------|------|------|\n| Session | 文件系统 | `emitEvent(id, event)`, `getEvents()`, `getSession(id)` |\n| Harness | 进程 | `wake(sessionId)` — 无状态，可随时替换 |\n| Sandbox | I/O 设备 | `execute(name, input) → string`, `provision({resources})` |\n\n- **Pets vs Cattle 演进：**\n - 耦合设计：session + harness + sandbox 在同一容器 → 容器 = 宠物，故障即丢失\n - 解耦设计：三组件独立 → 全部是牲畜，可独立故障和替换\n\n- **安全边界（结构性隔离）：**\n - Git：访问令牌在沙箱初始化时注入 remote，智能体不触碰令牌\n - 自定义工具：OAuth 令牌在 vault 中，通过 MCP proxy 调用，harness 永不接触凭证\n - 核心原则：**令牌永远不可从沙箱内访问**\n\n- **Session 作为外部上下文存储：**\n - 上下文不再是 harness 内的不可逆决策（compaction/trimming）\n - Session 日志持久存储完整事件流，`getEvents()` 按需切片取回\n - 上下文转换（缓存优化、上下文工程）在 harness 层做，与存储层分离\n\n- **性能数据：**\n\n| 指标 | 改善 |\n|------|------|\n| p50 TTFT | ~60% 下降 |\n| p95 TTFT | >90% 下降 |\n\n- **多大脑、多双手：**\n - 多大脑：无状态 harness 按需启动，容器仅在工具调用时配置\n - 多双手：每双手 = `execute(name, input) → string`，harness 不关心手是容器、手机还是宝可梦模拟器\n - 大脑之间可以互相传递双手\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Harness 假设过时 | Anthropic #4 的 Harness 瘦身、#6 的\"停止做什么\" |\n| Pets vs Cattle | 经典 DevOps 概念，Harness.io 脉络的核心 |\n| Session 外部存储 | LangChain 的 Context Rot、Anthropic #6 的 Compaction |\n| Meta-harness | Fowler 的假说 1：\"Harness 将成为未来的服务模板\" |\n| 安全边界解耦 | HumanLayer 的 MCP 信任边界 |\n| 多大脑多双手 | OpenAI 原文的并发 + 吞吐量理念 |\n\n\n\n### 8. Fowler / Rahul Garg — 编码团队标准：缩减 AI 辅助开发的摩擦\n\n- **标题：** Encoding Team Standards\n- **系列：** Patterns for Reducing Friction in AI-Assisted Development\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html)\n- **翻译：** [works/fowler-encoding-team-standards-translation.md](../works/fowler-encoding-team-standards-translation.md)\n- **作者：** Rahul Garg (Thoughtworks) | **日期：** 2026-04-01\n- **核心：** 将团队隐性编码标准显式化为可机器执行的规范，从自然语言 → 示例 → 自动化检查三层渐进\n- **关键洞察：**\n - 团队标准分三类：语言/框架惯用法、项目特有约定、架构决策\n - 编码路径：口头约定 → AGENTS.md/prompts 中的自然语言描述 → 带示例的结构化指令 → lint 规则/自动化检查\n - 不是所有标准都值得完全自动化——按违反频率和影响决定投资\n- **与其他文章关联：** Fowler #2 的 Guides×Sensors 框架的实操手册；HumanLayer 的 AGENTS.md 杠杆的深化\n\n\n\n### 9. Fowler / Rahul Garg — 反馈飞轮：缩减 AI 辅助开发的摩擦\n\n- **标题：** Feedback Flywheel\n- **系列：** Patterns for Reducing Friction in AI-Assisted Development\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html)\n- **翻译：** [works/fowler-feedback-flywheel-translation.md](../works/fowler-feedback-flywheel-translation.md)\n- **作者：** Rahul Garg (Thoughtworks) | **日期：** 2026-04-01\n- **核心：** 构建从 AI 失败中持续学习的反馈闭环——观察失败 → 根因分析 → 编码修复 → 验证效果 → 迭代\n- **关键洞察：**\n - 反馈飞轮四步：发现模式 → 诊断根因 → 系统性修复（而非一次性补丁）→ 衡量改善\n - 与 Encoding Team Standards 形成闭环：标准编码 → 违反检测 → 反馈 → 标准演进\n - 团队级别的 harness 不是一次性设计，而是持续演进的活系统\n- **与其他文章关联：** Anthropic #4 的\"每个 harness 组件编码一个假设\"理念的运营化；YDD 的安灯绳验证闭环\n\n\n\n### 10. LangChain — 智能体评估就绪清单\n\n- **标题：** Agent Evaluation Readiness Checklist\n- **链接：** [blog.langchain.com](https://blog.langchain.com/agent-evaluation-readiness-checklist/)\n- **翻译：** [works/langchain-agent-evaluation-checklist-translation.md](../works/langchain-agent-evaluation-checklist-translation.md)\n- **作者：** LangChain 团队 | **日期：** 2026-04-08\n- **核心：** 从零到一构建智能体评估体系的分阶段清单——定义 → 数据集 → 评估器 → 实验 → 持续集成\n- **关键洞察：**\n - 评估五阶段：定义成功标准 → 构建评估数据集 → 选择评估器 → 运行实验 → CI 集成\n - 数据集构建方法论：从生产日志中提取真实案例，比合成数据更有价值\n - LLM-as-judge 的校准：需要人类标注作为锚点，定期重新校准\n - 评估不是一次性的，而是随智能体演进持续更新的\n- **与其他文章关联：** Fowler #2 的 Sensors 维度的系统化实操；Anthropic #4 的 Evaluator 角色的方法论基础\n\n\n\n### 11. Meta-Harness 论文 — 自动化 Harness 优化\n\n- **标题：** Meta-Harness: End-to-End Optimization of Model Harnesses\n- **链接：** [arxiv.org](https://arxiv.org/abs/2603.28052)\n- **翻译：** [works/meta-harness-paper-translation.md](../works/meta-harness-paper-translation.md)\n- **作者：** Yoonho Lee, Roshen Nair 等 (Stanford, KRAFTON, MIT) | **日期：** 2026-03-30\n- **核心：** 用编码智能体作为提议器，通过文件系统访问完整搜索历史（代码+轨迹+分数），自动搜索最优 Harness\n- **关键洞察：**\n - 外循环搜索：提议器检查先前 Harness 的源代码和执行轨迹，进行因果推理后提出改进\n - 文本分类任务上比 ACE 高 7.7pp，上下文 token 减少 4×\n - IMO 难度数学问题上，发现的检索 Harness 跨 5 个留出模型泛化，平均提升 4.7pp\n - TerminalBench-2 上超越手工工程化的 Terminus-KIRA\n - 核心发现：完整执行轨迹访问 > 压缩摘要 > 仅标量分数（消融实验）\n- **与其他文章关联：** Anthropic #7 的 meta-harness 概念的学术实现；Fowler #2 的 Sensors 的极致自动化——连 harness 本身的设计也变成可搜索的\n\n\n\n### 12. GitHub / Tyler McGoffin — 智能体驱动开发实战\n\n- **标题：** Agent-driven development in Copilot Applied Science\n- **链接：** [github.blog](https://github.blog/ai-and-ml/github-copilot/agent-driven-development-in-copilot-applied-science/)\n- **翻译：** [works/github-agent-driven-development-translation.md](../works/github-agent-driven-development-translation.md)\n- **作者：** Tyler McGoffin (GitHub Copilot Applied Science) | **日期：** 2026-03-31\n- **核心：** 用编码智能体构建智能体，自动化自身工作的实战叙述；Copilot SDK + MCP + Skills 的具体使用模式\n- **关键洞察：**\n - 智能体驱动开发的三阶段演进：手动 → 半自动 → 全自动\n - 关键经验：好的提示词比好的代码更重要；智能体需要明确的约束和验证循环\n - Copilot CLI 作为日常工具的实际工作流\n- **与其他文章关联：** OpenAI 原文的\"工程师不再写代码\"理念的一线实践验证\n\n\n\n### 13. Inside the Scaffold 论文 — 编码智能体脚手架的源代码级分类法\n\n- **标题：** Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures\n- **链接：** [arxiv.org](https://arxiv.org/html/2604.03515v1)\n- **翻译：** [works/inside-the-scaffold-paper-translation.md](../works/inside-the-scaffold-paper-translation.md)\n- **作者：** Benjamin Rombaut (Huawei Canada) | **日期：** 2026-04-04\n- **核心：** 对 13 个开源编码智能体的脚手架代码进行源代码级分析，提出 12 维度 × 3 层次的架构分类法\n- **关键洞察：**\n - 五种循环原语（ReAct、生成-测试-修复、计划-执行、多次重试、树搜索）是可组合的构建块，11/13 智能体组合多种原语\n - 维度在外部约束主导处收敛（工具类别、编辑格式、执行隔离），在开放设计问题处发散（上下文压缩、状态管理、多模型路由）\n - 工具数量从 0（Aider）到 37（Moatless Tools），但底层能力类别趋同：读取、搜索、编辑、执行\n - 上下文压缩涵盖七种策略：截断、摘要、滑动窗口、事件溯源、浓缩、选择性包含、无压缩\n- **与其他文章关联：** 为 Fowler #2 的 Guides×Sensors 框架提供了 13 个实际系统的实证数据；Meta-Harness 论文搜索空间的具体化——展示了 harness 设计选择的巨大多样性\n\n\n\n### 14. ⭐ Lalit Maganti — 渴望八年，用 AI 三个月造出来\n\n- **标题：** Eight years of wanting, three months of building with AI\n- **链接：** [lalitm.com](https://lalitm.com/post/building-syntaqlite-ai/)\n- **翻译：** [works/maganti-eight-years-building-ai-translation.md](../works/maganti-eight-years-building-ai-translation.md)\n- **作者：** Lalit Maganti | **日期：** 2026-04-05\n- **核心：** 资深工程师（Chrome/Android 性能团队）用 AI 编码智能体从零构建 syntaqlite（SQLite 开发工具）的完整复盘——250 小时，3 个月，坦诚记录 AI 的帮助与局限\n- **关键洞察：**\n - AI 是实现的力量倍增器，但不能替代设计——缺乏品味、历史感和用户直觉\n - 实际经验：AI 在 well-constrained 的任务上卓越（测试编写、重构、API 实现），在需要判断力的任务上失败（架构决策、API 设计、性能优化）\n - \"vibe coding\" 对严肃项目不可行——必须理解 AI 生成的每一行代码\n - 模型能力进化的真实感受：Claude 3.5 → Sonnet 4.5 → Gemini 2.5 Pro 的逐步改善\n - **与我们的实践高度一致**\n- **与其他文章关联：** YDD 的\"洗衣机悖论\"的一手证据——省出的时间投入到了更高层的设计工作中；Anthropic #4 的\"每个 harness 组件编码一个假设\"的个人体验版\n\n\n\n### 15. LangChain / Harrison Chase — 智能体的持续学习\n\n- **标题：** Continual learning for AI agents\n- **链接：** [blog.langchain.com](https://blog.langchain.com/continual-learning-for-ai-agents/)\n- **翻译：** [works/langchain-continual-learning-translation.md](../works/langchain-continual-learning-translation.md)\n- **作者：** Harrison Chase (LangChain CEO) | **日期：** 2026-04-05\n- **核心：** 智能体的学习发生在三个层次：模型权重、Harness、上下文——理解区别改变你构建持续改进系统的方式\n- **关键洞察：**\n - 三层学习：模型层（微调/RL）→ Harness 层（提示词/工具/编排逻辑演进）→ 上下文层（运行时记忆/少样本示例）\n - Harness 层学习最被低估：通过分析执行轨迹迭代改进 harness，而非仅改模型\n - 上下文层学习最灵活：用户级记忆、后台整合、跨会话学习\n - Deep Agents 框架支持生产级持续学习\n- **与其他文章关联：** Meta-Harness 论文的 harness 层自动化学习的框架化阐述；Fowler #9 反馈飞轮在智能体层面的体现\n\n\n\n### 16. OpenAI 官方 — 任务跟踪器作为控制平面（Symphony）\n\n- **标题：** An open-source spec for Codex orchestration: Symphony\n- **链接：** [openai.com](https://openai.com/index/open-source-codex-orchestration-symphony/)\n- **翻译：** [works/openai-codex-symphony-translation.md](../works/openai-codex-symphony-translation.md)\n- **作者：** Alex Kotliarskyi, Victor Zhu, Zach Brock | **日期：** 2026-04-27\n- **核心：** 把 Linear 这类问题跟踪器变成智能体编排的控制平面——每个打开的 ticket 映射一个智能体工作区，Symphony 保证未完成任务始终有智能体在跑。Symphony 本体只是一份 `SPEC.md`+`WORKFLOW.md`，参考实现用 Elixir，作者鼓励使用者把 spec 交给自己的编码智能体生成本地实现。\n- **关键洞察：**\n - **从交互式会话到 ticket 级编排**：人类瓶颈不在写代码，而在管理 3-5 个并发 Codex 会话的上下文切换；把 issue tracker 当状态机后，瓶颈转移到智能体的目标空间\n - **目标 vs 状态转换**：早期把智能体当状态机里的刚性节点不奏效；最终转向\"给目标 + 工具 + 上下文，让它自己推理\"\n - **代码免费 → 按语言优势选语言**：参考实现用 Elixir 是因为其并发能力强；同一份 SPEC.md 用 TS/Go/Rust/Java/Python 都能实现成功，多语言实现反过来打磨规范本身\n - **探索成本接近零**：PM/设计师可直接提交 ticket 拿到带演示视频的 review packet，扩大了\"谁能发起工程工作\"的边界\n - **数据点**：部分团队前三周已落地 PR 数量 +500%；发布后 4 月 23 日仓库 15K+ stars\n- **与其他文章关联：** OpenAI 原文 #1 的\"map not manual\"在 SPEC.md 模式下的极致——map 不仅给智能体看，也给社区使用者作为构建模板；HumanLayer #5 的\"AGENTS.md 杠杆\"在工作流层面的扩展（`WORKFLOW.md` 显式化原本隐式的人类流程）；与 thinking 洞见 7 的\"技术栈收敛\"形成反例\n- **实施参考：** [openai/symphony](https://github.com/openai/symphony) | [SPEC.md](https://github.com/openai/symphony/blob/main/SPEC.md)\n\n\n\n### 17. Vikash Rungta — Claude Code 架构（逆向工程版）\n\n- **标题：** Claude Code Architecture (Reverse Engineered)\n- **链接：** [vrungta.substack.com](https://vrungta.substack.com/p/claude-code-architecture-reverse)\n- **翻译：** [works/claude-code-architecture-reverse-translation.md](../works/claude-code-architecture-reverse-translation.md)\n- **作者：** Vikash Rungta | **日期：** 2025-11-01\n- **性质：** 外部逆向分析，非 Anthropic 官方架构文档\n- **核心：** 把 Claude Code 解释为模型无关的本地运行外壳：模型负责推理，外壳提供 shell、文件系统、工具原语、记忆、权限、hooks、MCP、skills、子智能体和智能体团队，把自主循环约束在可治理边界内。\n\n- **关键洞察：**\n - **从工作流到循环：** 从代码控制模型的 DAG，转向模型控制行动的 TAOR（Think-Act-Observe-Repeat）循环；运行时保持简单，智能尽量留给模型。\n - **原语工具胜过专用集成：** Bash、Grep、Edit、Read 这类通用能力原语，比大量脆弱的垂直插件更能覆盖真实工程工作流。\n - **上下文是一种稀缺资源：** 自动压缩、子智能体隔离、语义工具搜索和 forked context 都是在管理上下文预算，避免上下文坍缩。\n - **权限就是产品体验：** plan/default/acceptEdits/dontAsk/bypassPermissions 这类信任光谱，把安全、速度和企业采用门槛合在一起。\n - **Harness 应随模型变薄：** 模型能力提升后，硬编码脚手架应被删除或下沉为确定性 hook，而不是持续堆复杂度。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Claude Code 作为 Harness 的产品化样本 | #3 LangChain 的 Agent = Model + Harness 公式 |\n| 子智能体与智能体团队 | #13 Inside the Scaffold 的子智能体委托分类、#16 Symphony 的 ticket 级编排 |\n| hooks 作为确定性护栏 | #2 Fowler Guides×Sensors、#5 HumanLayer 六杠杆 |\n| 模型升级时删除代码 | #4 Anthropic Harness 瘦身、#6 Anthropic/Claude Platform 的\"停止做什么\" |\n| Claude Code 专有实现的外部观察 | 弥补 #13 因 Claude Code 非开源而无法纳入源代码分类法的空白 |\n\n> 注：Chachamaru127 / claude-code-harness 早期曾占据 #16 文章位，现已迁至本文末尾的\"已跟踪产品 / 项目\"段落（不计入文章数）。\n\n\n\n### 18. 马东锡 NLP — Harness 系列文章之 7：关于 subagent\n\n- **标题：** Harness 系列文章之 7：关于 subagent\n- **链接：** [x.com](https://x.com/dongxi_nlp/status/2068922428516892998)\n- **原文收录：** [works/dongxi-subagent-original.md](../works/dongxi-subagent-original.md)\n- **作者：** 马东锡 NLP (@dongxi_nlp) | **日期：** 2026-06-22\n- **核心：** 把 subagent 从\"小号智能体\"重新定义为 parent session 通过一次 tool call 拉起的 managed child runtime：外层是 `spawn_agent` / `/delegate` tool call，内层是新的 child session 和被选择过的 context projection。\n\n- **关键洞察：**\n - **Tool call outside, runtime inside：** subagent 的启动入口是 tool call；tool call 之后，Harness 的世界状态里多了一个 child runtime。\n - **Session ≠ Context：** session 是 runtime container，包含 thread、transcript、tools、permissions、resources、status、artifacts；context 是某次 model call 可见的 projection。\n - **Shared resources 不等于 shared transcript：** child 可以继承 tools、skills、AGENTS.md、MCP servers、cwd、sandbox、permissions，但不自动继承 parent 的完整对话历史。\n - **三种投影策略：** fresh child、forked child、partial fork 分别对应不同上下文继承强度；partial fork 是避免 parent history 噪声的实用中间态。\n - **更多 agents = 更多 runtime state：** 多智能体不是免费并行，Harness 必须追踪谁在工作、知道什么、改了什么、何时完成，以及结果如何变成 evidence。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| child session 与 context projection | #7 Anthropic Managed Agents 的 Session/Harness/Sandbox 解耦 |\n| subagent 作为上下文隔离机制 | #17 Claude Code 架构逆向中的隔离 TAOR 循环与 summary return |\n| fresh/forked/partial fork | #6 Anthropic/Claude Platform 的 context editing、sub-agent 隔离与缓存前缀管理 |\n| evidence 回流与 runtime state | #16 OpenAI Symphony 的任务跟踪器控制平面、#13 Inside the Scaffold 的委托分类 |\n\n- **本仓库笔记：** [thinking/subagent-is-child-runtime.md](../thinking/subagent-is-child-runtime.md)\n\n---\n\n\n\n### 19. Fowler / Birgitta Böckeler — 面向编码智能体的可维护性传感器\n\n- **标题：** Maintainability sensors for coding agents\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/sensors-for-coding-agents.html)\n- **中文译文：** [works/fowler-sensors-translation.md](../works/fowler-sensors-translation.md)\n- **作者：** Birgitta Böckeler | **日期：** 2026-05-20\n- **核心：** Böckeler 从一个真实 TypeScript/NextJS 应用出发，系统梳理\"计算性 vs 推理性\"传感器谱系（type checker、ESLint、Semgrep、dependency-cruiser、mutation testing、耦合分析、AI 模块化评审），并诚实记录失败案例（耦合数据对 AI\"乏善可陈\"、把合理的 DI factory 误判为 god module）。\n\n- **关键洞察：**\n - **传感器 = 反馈控制隐喻：** lint message 写成\"自我修正指导\"（prompt injection 式提示），让 agent 读到反馈即自纠。\n - **计算性 vs 推理性：** 确定性检查（type/lint/依赖图）与需要判断的检查（模块化、耦合）是两类不同传感器，可靠度与误报率不同。\n - **AI 模块化评审 = 垃圾回收：** 作者明确把它称为 garbage collection——周期性识别并清理结构腐化。\n - **诚实的负面结果：** 不是所有传感器都有用，耦合指标对 AI 收效甚微，记录失败本身是这篇的价值。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Guides × Sensors 框架的实操续篇 | #2 Fowler 的控制论矩阵 |\n| 机械化执行（custom linter > 文档） | 概念 3 机械化执行 |\n| AI 评审作为垃圾回收 | 概念 6 熵与垃圾回收 |\n\n- **本仓库笔记：** [thinking/guides-sensors-meets-claude-code-harness.md](../thinking/guides-sensors-meets-claude-code-harness.md)\n\n---\n\n\n\n### 20. Fowler / Wei Zhang, Jessie Jie Xia — 结构化提示驱动开发（SPDD）\n\n- **标题：** Structured-Prompt-Driven Development (SPDD)\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/structured-prompt-driven/)\n- **中文译文：** [works/fowler-spdd-translation.md](../works/fowler-spdd-translation.md)\n- **作者：** Wei Zhang, Jessie Jie Xia（Martin Fowler 编辑） | **日期：** 2026-04-28\n- **核心：** 一套把提示词当一等版本化交付物的半自动 Harness：提出 REASONS Canvas 七维结构（R/E/A/S/O/N/S），主张\"先修提示词再改代码、重构则反向同步 spdd-sync\"的双向闭环。文末附 13 组高质量自问自答。\n\n- **关键洞察：**\n - **Prompt 是合同，Plan 是建议：** 把结构化提示词版本化、可审查，作为变更的承重结构。\n - **双向闭环：** 现实偏离 spec 时先改 prompt 再改代码；人工重构后用 spdd-sync 反向同步回 prompt，防止提示词漂移。\n - **SPDD 本身就是一个 Harness：** 把上下文、约束、审查、同步全部显式化。\n - **诚实承认边界：** \"人类判断仍然是承重结构\"，模型无关、不替代审查。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Prompt 即一等可版本化交付物 | #16 OpenAI Symphony 的约束即产品、延伸概念 07-spec-as-product |\n| REASONS Canvas 七维结构 | 概念 2 地图而非手册 + 渐进式披露 |\n| spdd-sync 反向同步防漂移 | 概念 3 机械化执行、#9 反馈飞轮 |\n\n---\n\n\n\n### 21. LangChain / Harrison Chase — 智能体开发生命周期（ADLC）\n\n- **标题：** The Agent Development Lifecycle (ADLC)\n- **链接：** [langchain.com](https://www.langchain.com/blog/the-agent-development-lifecycle)\n- **中文译文：** [works/langchain-adlc-translation.md](../works/langchain-adlc-translation.md)\n- **作者：** Harrison Chase | **日期：** 2026-05-09\n- **核心：** 提出 Build → Test → Deploy → Monitor + Iterate + Govern 的完整智能体开发生命周期，把 framework / runtime / harness 三层做了清晰区分，治理段拆出 cost / tool access / discoverability。是方法论级别的总览型骨架文。\n\n- **关键洞察：**\n - **framework / runtime / harness 三分类：** 与本仓库主题命名正面对齐——harness 是约束与反馈层，runtime 是执行容器，framework 是编排库。\n - **生命周期是闭环：** Monitor 产出的轨迹回流到 Iterate，把一次性 demo 变成可重复、可评测、可运营的工程。\n - **Govern 作为一等维度：** 成本、工具访问、可发现性被显式纳入治理。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| framework/runtime/harness 三层 | #6 Anthropic 三大模式、#17 Claude Code 架构逆向 |\n| Monitor → Iterate 反馈回路 | #2 Fowler Sensors、概念 3 机械化执行 |\n| Govern / 治理维度 | 概念 6 熵与垃圾回收 |\n\n---\n\n\n\n### 22. LangChain / Hunter Lovell — Deep Agents 中的解释器\n\n- **标题：** Interpreters in Deep Agents: Code Between Tool Calls and Sandboxes\n- **链接：** [langchain.com](https://www.langchain.com/blog/give-your-agents-an-interpreter)\n- **中文译文：** [works/deep-agents-interpreter-translation.md](../works/deep-agents-interpreter-translation.md)\n- **作者：** Hunter Lovell | **日期：** 2026-05-20\n- **核心：** 提出 interpreter 是介于串行工具调用与完整沙箱之间的\"第三层\"，interpreter state 是继 message history、filesystem 之后的\"第三类上下文表面\"。给出 35% token 节省实测，以及 QuickJS / 桥接 / 运行时控制的实现细节。\n\n- **关键洞察：**\n - **上下文表面分层：** message history / filesystem / interpreter state 是三类不同的 context surface，各自有不同的读写与投影方式。\n - **设计上更受限是主动选择：** interpreter 主动收窄能力（而非能力不足），用受限运行时换取可控与可读。\n - **35% token 节省：** 让智能体写代码协调工具、保存中间态，只把相关结果送入模型上下文。\n - **横向连接：** 呼应 Cloudflare Code Mode、Anthropic PTC、RLM。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 受限运行时即机械约束 | 概念 3 机械化执行、概念 4 智能体可读性 |\n| 上下文表面 / context surface 分层 | #6 Anthropic context editing、#18 subagent 的 context projection |\n| 用代码协调工具以省上下文 | #16 OpenAI Symphony 控制平面 |\n\n---\n\n\n\n### 23. Anthropic / 工程团队 — Claude Code 质量回归复盘\n\n- **标题：** An update on recent Claude Code quality reports\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/april-23-postmortem)\n- **中文译文：** [works/anthropic-postmortem-translation.md](../works/anthropic-postmortem-translation.md)\n- **作者：** Anthropic 工程团队 | **日期：** 2026-04-23\n- **核心：** 对三起独立的 Claude Code 质量回归逐项复盘——(1) 默认 reasoning effort 从 high 降到 medium 的产品取舍；(2) clear_thinking 缓存优化 bug（本应只清一次却每轮都清，导致\"健忘/重复/乱用工具\"并拖垮缓存命中）；(3) 一条 system prompt 限长指令（≤25/≤100 词）压垮编码智能。三个变更各打不同流量切片、不同时间表，叠加成\"广泛而不一致的退化\"。是仓库稀缺的第一手失败案例。\n\n- **关键洞察：**\n - **变更评估的经典陷阱：** 三个变更各自通过人审 + 自动审 + 单测 + e2e + dogfooding，仍全部漏网。\n - **system prompt 即受控产物：** 一条限长指令就能压垮编码智能，提示词必须纳入评测与审计。\n - **现成的治理清单：** 文末\"后续计划\"（per-model eval 套件、消融、soak period、渐进发布、prompt 审计工具）几乎是一份 harness 变更治理清单。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 机械化执行的盲区（多层审查仍漏网） | 概念 3 机械化执行、#2 Fowler Sensors |\n| system prompt 即受控产物 | 延伸概念 07-spec-as-product、#16 Symphony |\n| 反例 / 事故复盘（稀缺类型） | 仓库 works/ 多为正面理论，本篇为第一手反面教材 |\n\n---\n\n\n\n### 24. 林家航 等 / 复旦·北大·奇绩智锋 — Agentic Harness Engineering（论文）\n\n- **标题：** Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses\n- **链接：** [arxiv.org/html/2604.25850v4](https://arxiv.org/html/2604.25850v4)\n- **中文译文：** [works/arxiv-agentic-harness-engineering-translation.md](../works/arxiv-agentic-harness-engineering-translation.md)\n- **作者：** Jiahang Lin, Shichun Liu, Chengjun Pan 等（复旦 / 北大 / 奇绩智锋） | **日期：** 2026-05-18 | **arXiv：** 2604.25850 v4\n- **核心：** 提出 AHE 闭环——在固定基础模型下，通过组件、经验、决策三类可观测性让 Harness 自动演化：可编辑组件文件化，轨迹压缩为可下钻证据，每次编辑附带可证伪预测。Terminal-Bench 2 上 pass@1 从 69.7% 提升到 77.0%，超过 Codex-CLI，并在 SWE-bench-verified 与跨模型迁移中保持收益。\n\n- **关键洞察：**\n - **每次 Harness 编辑 = 可证伪契约：** 把 harness 优化从经验调参变成可验证的研究问题。\n - **三类可观测性：** 组件 / 经验 / 决策，构成分层可下钻的证据语料库。\n - **诚实报告局限：** 回归失明、组件非加性交互——优化并非单调可加。\n - **直接引用仓库源头：** 参考文献含 OpenAI Harness Engineering、Anthropic harness design、LangChain deep agents。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Harness 自动演化 / meta-harness | #11 Meta-Harness 论文、#7 Anthropic Meta-Harness |\n| 可观测性驱动的闭环 | #2 Fowler Sensors、概念 3 机械化执行 |\n| 编码智能体脚手架分类 | #13 Inside the Scaffold 论文 |\n\n---\n\n\n\n### 25. Yubin Qu 等 — 过度积极的编码智能体（论文）\n\n- **标题：** Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks\n- **链接：** [arxiv.org/html/2605.18583v1](https://arxiv.org/html/2605.18583v1)\n- **中文译文：** [works/arxiv-overeager-coding-agents-translation.md](../works/arxiv-overeager-coding-agents-translation.md)\n- **作者：** Yubin Qu, Ying Zhang, Yanjun Zhang, Gelei Deng, Yuekang Li, Leo Yu Zhang, Yi Liu | **日期：** 2026-05-18 | **arXiv：** 2605.18583 v1\n- **核心：** 定义并测量编码智能体在良性任务中的 overeager actions（完成表面任务却执行用户未授权的读写）。提出 OverEager-Gen/Bench（500 场景、约 7500 次运行、4 个 agent 产品 × 6 模型），用行为梯度验证器与双通道审计栈评估越界率。\n\n- **关键洞察：**\n - **反直觉发现：** 在提示里写明授权范围，会让 agent 从\"推断边界\"退化为\"匹配声明文本\"——Claude Code 去掉 consent 声明后越界率 0.0% → 17.1%。\n - **框架层主导：** permission gating 由框架层决定，模型层对齐不会完整传导到行为。\n - **授权问题是独立类别：** 区别于能力失败、提示注入、沙箱逃逸，是单独的一类风险。\n - **实证支撑机械约束：** 证明约束必须机械强制，靠提示声明反而降低边界推断。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 权限门控 / 边界约束 | #7 Anthropic Managed Agents 沙箱、概念 3 机械化执行 |\n| 提示声明反而降低安全 | #23 Anthropic 复盘的 system prompt 陷阱 |\n| agent 越界的实证测量 | 概念 6 熵与垃圾回收 |\n\n---\n\n\n\n### 26. Chris Parsons — 我是如何用 AI 写代码的\n\n- **标题：** How I Use AI to Code\n- **链接：** [chrismdp.com](https://chrismdp.com/coding-with-ai/)\n- **中文译文：** [works/chris-ai-code-translation.md](../works/chris-ai-code-translation.md)\n- **作者：** Chris Parsons | **日期：** 2026-05（更新版）\n- **核心：** 资深从业者的一手实践复盘。硬区分 Vibe Coding 与\"智能体化工程\"，提出\"从批准者到训练者\"的角色转变，归纳四要素 Harness（常驻指令 / skill files / 验证循环 / 反馈循环），并主张\"spec the problem, not the solution\"。带 7 条带注解脚注（a16z、Karpathy、METR/MIT、Greenblatt serial speed-up 等）。\n\n- **关键洞察：**\n - **Vibe Coding ≠ 智能体化工程：** 前者不真正检查结果，后者是\"有分寸地判断哪些 diff 需要你的眼睛\"。\n - **从批准者到训练者：** 资深工程师的工作不再是审查输出，而是训练 AI——把判断花在哪里本身是资深技能。\n - **四要素 Harness：** 常驻指令、skill files、验证循环、反馈循环；没有反馈循环脚手架会腐化。\n - **反馈是新瓶颈：** 编码本身更快了，但审查/验证/集成/返工变慢，慢工作吞没快工作。\n - **译者注：** 文中 2026 数据/产品断言来自原文及脚注，译者未独立核实（见译文顶部说明）。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 四要素 Harness | #2 Fowler、#5 HumanLayer 六杠杆、概念 2/3（地图而非手册 / 机械化执行） |\n| 反馈循环防腐化 | #9 Fowler 反馈飞轮、#19 Fowler Sensors |\n| 反馈瓶颈 / serial speed-up | #78 YDD 效率悖论 |\n\n---\n\n\n\n### 27. LangChain / Palash Shah — 我们如何构建 LangSmith Engine\n\n- **标题：** How we built LangSmith Engine: our agent for improving agents\n- **链接：** [langchain.com](https://www.langchain.com/blog/how-we-built-langsmith-engine-our-agent-for-improving-agents)\n- **中文译文：** [works/langsmith-engine-translation.md](../works/langsmith-engine-translation.md)\n- **作者：** Palash Shah | **日期：** 2026-05-19\n- **核心：** \"用智能体改进智能体\"的工程复盘。把 trace 压缩成轨迹骨架，用 screener（Haiku 子智能体）/ investigator 两阶段分工，CLI 作为统一接口，构成 issue → evaluator → 回归样本的闭环；issue 创建与 fix 生成分离。\n\n- **关键洞察：**\n - **trace → 轨迹骨架：** 压缩运行轨迹再交给智能体，是\"运行时 → 可观测 → 自动改进\"链条的关键一步。\n - **两阶段分工：** screener 先筛、investigator 再深挖，控制成本与上下文。\n - **闭环：** issue → evaluator → regression example，把一次性诊断变成可回归的适应度函数。\n - **创建与修复分离：** issue 创建和 fix 生成解耦，连接 repo 做 code-aware fix。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 用智能体改进智能体 / meta-harness | #7 Anthropic Meta-Harness、#24 Agentic Harness Engineering |\n| evaluator 作为适应度函数 | #10 LangChain 评估清单、#2 Fowler Sensors |\n| 运行时 → 可观测 → 改进链条 | #21 ADLC、#22 Deep Agents 解释器 |\n\n---\n\n\n\n### 28. Geoffrey Huntley — Ralph：最小可行 Harness 的原始出处\n\n- **标题：** Ralph Wiggum as a \"software engineer\"（2025-07）+ 续篇 everything is a ralph loop（2026-01-17）\n- **链接：** [ghuntley.com/ralph](https://ghuntley.com/ralph/) | [ghuntley.com/loop](https://ghuntley.com/loop/)\n- **作者：** Geoffrey Huntley | **日期：** 2025-07 / 2026-01-17\n- **核心：** Ralph 技术的方法论源头——\"Ralph 在最纯粹的形式下就是一个 bash 循环\"：`while true` 把 PROMPT.md 喂给编码智能体，每轮全新上下文窗口、一轮只做一件事，配背压验证。作者用它从零构建 CURSED 编程语言（训练集中不存在的语言）。本仓库 `practice/` 的 Ralph Demo 与已跟踪的 3 个 Ralph 项目此前一直缺这篇源头文献。\n\n- **关键洞察：**\n - **每轮只做一件事 + 信任模型选事：** 违反直觉的组合——既收窄单轮范围，又把\"什么最重要\"的决策权交给模型\n - **fix_plan.md 是外置状态：** TODO 列表是人类\"像鹰一样盯着\"的对象，构建 CURSED 期间被扔掉重生成多次——计划是耗材\n - **背压（backpressure）：** 改动后只跑该单元的测试；Rust 类型系统虽强但编译慢——\"轮速与正确性轴的平衡\"决定语言选择\n - **单体 vs 多智能体：** \"非确定性的微服务（智能体）= 一团红热的烂摊子\"；Ralph 是单体，单进程垂直扩展、单仓库自治\n - **失败域→工程化修复：** \"看到失败域，戴上工程师帽子把问题解决到永不再犯\"——与 Hashimoto 的 harness engineering 定义同源\n - **续篇的推广：** \"一切皆 ralph loop\"——loop 是通用的上下文工程模式，可用于所有任务；软件是陶轮上的黏土，不对就扔回轮上重塑\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| bash 循环 + 干净上下文 | #3 LangChain 的 Ralph Loop 组件、practice/ Ralph Demo |\n| 背压验证门 | 概念 3 机械化执行、#5 HumanLayer 的 Back-Pressure 杠杆 |\n| 计划是耗材 | README 的 Ralph 六信条 \"The Plan Is Disposable\" |\n| 单体反多智能体论 | #36 dynamic workflows（对照：模型自己写多智能体编排）、#16 Symphony |\n| 观察循环、调音式修复 | #29 Hashimoto 的 harness engineering 定义 |\n\n---\n\n\n\n### 29. Mitchell Hashimoto — 我的 AI 采纳之旅（\"harness engineering\" 命名出处）\n\n- **标题：** My AI Adoption Journey\n- **链接：** [mitchellh.com](https://mitchellh.com/writing/my-ai-adoption-journey)\n- **作者：** Mitchell Hashimoto（HashiCorp 联合创始人，Ghostty 作者） | **日期：** 2026-02-05\n- **核心：** 六步渐进采纳路线：放弃聊天机器人 → 复现自己的工作（手工做一遍再逼智能体做出同质结果）→ 日终智能体 → 外包稳赢任务 → 工程化 harness → 始终有智能体在跑。第 5 步给出了被业界广泛引用的 harness engineering 定义。多方学科史梳理公认本文是该术语的叫响者（与 OpenAI 原文同月）。原为本仓库\"延伸阅读\"，现升格为编号条目。\n\n- **关键洞察：**\n - **定义原文：** \"每当发现智能体犯错，就花时间工程化一个解决方案，使它永远不会再犯这个错误\"——两种形式：隐式提示（AGENTS.md）+ 程序化工具（截图脚本、过滤测试跑器）\n - **Ghostty 的 AGENTS.md 每一行都对应一次真实的坏行为**——与 Osmani \"每行可溯源到一次翻车\"的纪律互证\n - **复现自己的工作：** 刻意做两遍（先手工后智能体）是形成\"什么任务能交给智能体\"直觉的最快途径；效率增益的一半来自知道何时不用智能体\n - **人控制打断时机：** 关掉智能体桌面通知，\"由我决定何时打断它，而不是反过来\"——上下文切换是最贵的成本\n - **克制的自主性：** 一次只跑一个智能体、后台智能体覆盖 10–20% 工作时段；反对为跑而跑——\"只在真正有帮助的任务上跑\"\n - **对冲技能退化：** 委托智能体的同时手工做自己热爱的任务，抵消 Anthropic 技能形成论文指出的风险\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness engineering 定义 | #1 OpenAI 原文（同期独立提出）、#2 Böckeler（引用本文） |\n| 错误工程化=永不再犯 | #9 反馈飞轮的个人版、#28 Ralph 的调音式修复 |\n| AGENTS.md 行行有出处 | #31 Osmani 的约束加减法纪律、#5 HumanLayer 60 行规则 |\n| 何时不用智能体 | #14 Maganti 的能力边界经验、#26 Chris Parsons |\n\n---\n\n\n\n### 30. Claude Code 源码泄漏事件 — 512K 行 harness 的实锤解剖\n\n- **标题：** 事件 + 聚合分析：understanding-claude-code（综合 26 篇文章、7 个 HN 帖、10 份官方 TechDocs）\n- **链接：** [pankaj28843/understanding-claude-code](https://github.com/pankaj28843/understanding-claude-code) | 新闻报道：[InfoQ](https://www.infoq.com/news/2026/04/claude-code-source-leak/)\n- **作者：** 事件（当事人 Chaofan Shou，安全研究员；社区镜像扩散，无单一作者——本条为事件型收录） | **日期：** 2026-03-31（事件日）\n- **事件：** 2026-03-31，`@anthropic-ai/claude-code` v2.1.88 npm 包漏发 59.8MB 的 `cli.js.map`（缺一条 `.npmignore`，叠加 Bun 默认生成 source map 的已知 bug），~512,000 行 TypeScript / ~1,900 文件全裸；安全研究员 Chaofan Shou 发现，数小时内 GitHub 镜像扩散\n- **核心：** 业界第一次看到一线编码智能体 harness 的完整生产级源码。此前 #17（Rungta 逆向）只能从行为推测，泄漏把推测变成了可对照的实锤。\n\n- **实锤细节（此前只能猜测的部分）：**\n - **QueryEngine ~46K 行**：流式响应、工具调用循环、重试、token 追踪；工具可在模型还在流式输出时就开始执行\n - **60+ 权限门控工具（~29K 行 Tool.ts）**：遵循 Ousterhout \"deep modules\" 原则——简单接口藏重能力；\"Anthropic 花在优化工具上的时间超过优化总 prompt\"；工具描述本身是微型提示词\n - **工具结果预算**：BashTool 30K 字符、GrepTool 20K 字符，超额落盘到 `tool-results/{uuid}/` 留预览——上下文管理的机械化实现\n - **14 种缓存破坏向量追踪**（`promptCacheBreakDetection.ts`）：工具表变更、权限模式切换、CLAUDE.md 修改、MCP 连接等——#6 缓存优化五原则的工程落地\n - **未发布功能**：KAIROS 常驻后台 daemon（追加式日报）+ AutoDream 睡眠期记忆整理（727 行，闲时修剪/合并/组织会话记忆）+ Undercover Mode（对外仓库自动抹除内部信息与 AI 署名）\n - **教训**：source map 是被忽视的安全面——`npm pack --dry-run` 应进发布流水线\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 推测 vs 实锤对照 | #17 Rungta 逆向分析（TAOR 循环、权限光谱的推断如今可验证） |\n| 补上闭源样本的空白 | #13 Inside the Scaffold（当时因 Claude Code 闭源无法纳入分类法） |\n| 工具>prompt 的投资优先级 | #6 Anthropic 通用工具主张、概念 4 智能体可读性 |\n| 记忆整理（AutoDream） | #6 Pokemon 记忆进化案例的机制揭底 |\n| 发布流水线事故 | #23 质量回归复盘（同为 Anthropic 工程失误的第一手材料） |\n\n---\n\n\n\n### 31. Addy Osmani — Agent Harness Engineering（学科汇流综合）\n\n- **标题：** Agent Harness Engineering\n- **链接：** [addyosmani.com](https://addyosmani.com/blog/agent-harness-engineering/)（[O'Reilly Radar 2026-05-15 授权转载](https://www.oreilly.com/radar/agent-harness-engineering/)）\n- **第三方中译：** [掘金译文](https://juejin.cn/post/7642753947455356968)（未落盘本仓库）\n- **作者：** Addy Osmani（Google Cloud AI Director） | **日期：** 2026-04-19\n- **性质与破例说明：** 综述性质（同类的 Pachaar 综述归在\"中文转译/二手资料\"段不计数）。破例进编号正文的理由：它不只转述——给出了约束加减法纪律、hooks 分界论等可引用的原创表述，且是\"四学派汇流成一个学科\"的定调文（收藏/点赞比 2:1，读者当文档存）。\n- **核心：** \"编码智能体 = 模型 + 你围绕它构建的一切。Harness engineering 把这套脚手架当真正的工程产物；每当智能体失手，harness 就再收紧一圈。\"把 Trivedy（术语）、Horthy（追踪）、HumanLayer（skill issue）、Anthropic（长时设计）、Böckeler（用户侧）、Hashimoto（命名）缝成一张学科地图。\n\n- **关键洞察：**\n - **失败是可读的（legible）：** 不知道约定→加进 AGENTS.md；跑了破坏性命令→加 hook 拦截；40 步任务迷路→拆 planner/executor；反复\"完成\"坏代码→接 typecheck 背压\n - **约束的加减法纪律：** 只在见过真实失败后加约束，只在模型能力使其冗余后删；\"好的 AGENTS.md 每一行都应能溯源到一次具体翻车\"\n - **hooks 是分界线：** \"我告诉过智能体做 X\" vs \"系统强制执行 X\"——lifecycle 脚本承载永不能忘的事（typecheck/lint/测试、拦 `rm -rf` / force push、PR 前审批、写后自动格式化）\n - **模型与 harness 后训练耦合：** Opus 4.6 在 Claude Code 里的 Terminal Bench 2.0 分数远低于同模型在定制 harness 里；Viv 团队只改 harness 就 Top 30 → Top 5（#35 论文给出了这一现象的统计版本）\n - **HaaS（Harness-as-a-Service）：** 从构建于 LLM API（给 completion）转向构建于 harness API（给 runtime）——Claude Agent SDK / Codex SDK / OpenAI Agents SDK 同向\n - **Ralph Loop 的价值重申：** \"hook 拦截退出、往新上下文窗口重注提示词\"是从\"用更聪明的模型\"永远推导不出来的原语\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 六人六视角的汇流地图 | #3 Trivedy、#5 HumanLayer、#4 Anthropic、#2 Böckeler、#29 Hashimoto |\n| 约束加减法纪律 | #4 harness 瘦身、#29 AGENTS.md 行行有出处 |\n| Terminal Bench harness 效应 | #35 统计归因论文、#3 的原始数据点 |\n| HaaS | #7 Managed Agents、#21 ADLC 的 framework/runtime/harness 三分 |\n| 四学派汇流 | thinking/cross-article-insights 的学派划分 |\n\n---\n\n\n\n### 32. Thoughtworks / Böckeler & Ford — 传感器实验：有无反馈回路的对照\n\n- **标题：** Harness engineering and agent feedback: Exploring AI coding sensors\n- **链接：** [thoughtworks.com](https://www.thoughtworks.com/en-au/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors)\n- **作者：** Birgitta Böckeler, Chris Ford (Thoughtworks) | **日期：** 2026-05-13\n- **核心：** #19（可维护性传感器谱系）的实验化姊妹篇。在一个 TypeScript 数据仪表板上做**有/无传感器套件的对照实验**（ESLint、Semgrep 静态分析 + Dependency Cruiser 模块边界 + 覆盖率报告 + mutation testing），配套视频演示。\n\n- **关键洞察：**\n - **实验结果：** 配备质量反馈传感器的编码智能体能随时间持续改善质量（如提升测试覆盖率）；无传感器则原地踏步\n - **行业失衡诊断：** 2026 上半年业界注意力集中在 skills（前馈），sensors（反馈）被系统性低估——\"完美世界只需前馈；我们不住在那个世界里\"\n - **从叮嘱到保证：** \"反复求智能体写测试并祈祷它够自觉\" → 确定性约束给出保证；LLM 判断适合模糊探索区，客观一致的要求要交给形式化确定性工具\n - **态势感知而非全自动：** \"harness engineering 不是全自动化，而是开发者的态势感知\"——红绿传感器仪表板 = 代码库体检单，指示该把精力再投资到 harness 的哪里\n - **Harness 模板展望：** 未来不再每个项目从头搭 harness，而是按应用类型取用预配置模板（数据仪表板模板、CRUD 业务服务模板）——#2 的 harness 模板假说落到具体形态\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 传感器对照实验 | #19 传感器谱系（同作者的实操续篇） |\n| 前馈/反馈失衡 | #2 Guides×Sensors 框架、#5 六杠杆 |\n| 确定性约束 > 反复叮嘱 | 概念 3 机械化执行、#25 Overeager（提示声明反而降低边界推断） |\n| harness 模板 | #2 的假说 1、#21 ADLC |\n\n---\n\n\n\n### 33. HarnessAudit 论文 — Harness 安全审计（安全面的开辟）\n\n- **标题：** Auditing Agent Harness Safety\n- **链接：** [arxiv.org/abs/2605.14271](https://arxiv.org/abs/2605.14271)\n- **作者：** Chengzhi Liu, Yichen Guo, Yepeng Liu, Yuzhe Yang, Qianqi Yan, Xuandong Zhao, Wenyue Hua, Sheng Liu, Sharon Li, Yuheng Bu, Xin Eric Wang | **日期：** 2026-05 | **arXiv：** 2605.14271\n- **核心：** 开辟本仓库此前完全缺失的维度——**harness 是安全面**。核心观察：harness 可以在\"返回正确且良性的最终答案\"的同时，轨迹中途访问未授权资源、或把上下文泄给错误的智能体——**输出级评估看不见这些失败**，而多数安全基准只给最终输出/终态打分。提出 HarnessAudit 框架（审计完整执行轨迹的边界合规、执行保真、系统稳定三维）+ HarnessAudit-Bench（210 任务 × 8 个真实领域，单/多智能体配置，内嵌安全约束）。\n\n- **关键发现（评测 10 种 harness 配置 × 前沿模型 × 3 个多智能体框架）：**\n - **任务完成与安全执行不对齐**，违规随轨迹长度累积——长时自主运行天然扩大风险\n - 安全风险随领域、任务类型、智能体角色而异\n - 违规集中在**资源访问**与**智能体间信息传递**两类\n - 多智能体协作扩大安全风险面；**harness 设计决定安全部署的上限**\n- **传播语境：** 被转发时的定性——\"业界正在意识到：harness 是产品，也是安全面。该审计的不只是模型，还有 prompt、工具、权限、记忆、执行层。AI 安全的下一个前沿是 harness 安全。\"（#37 作者马东锡转发）\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 中途轨迹违规 vs 输出级评估 | #25 Overeager（越界动作测量——本文把它推进到审计框架） |\n| 权限边界与信息流约束 | #7 Managed Agents 的安全边界解耦、#30 泄漏实锤的权限分类器 |\n| 多智能体扩大风险面 | #18 subagent 的 runtime state 追踪、#36 dynamic workflows 的千级扇出 |\n| harness 决定安全上限 | #37 \"可靠性的东西都属于 harness\" |\n\n---\n\n\n\n### 34. Harness-Bench 论文 — 配置级 harness 效应的诊断基准\n\n- **标题：** Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows\n- **链接：** [arxiv.org/abs/2605.27922](https://arxiv.org/abs/2605.27922)\n- **作者：** Yilun Yao, Xinyu Tan, Chao-Hsuan Liu 等 12 人 | **日期：** 2026-05 | **arXiv：** 2605.27922\n- **核心：** 现有基准要么抽象掉执行层、要么比较完整智能体系统、要么固定 harness——执行层变异一直难以研究。Harness-Bench 用 106 个沙箱离线任务（从实际 agent 使用模式构造，人工审核真实性/可解性/oracle 可检验性/完整性），在共享任务环境、预算与评估协议下评测代表性 harness 配置 × 多模型后端，同时**保留各 harness 的原生执行行为**。\n\n- **关键洞察：**\n - **5,194 条执行轨迹的结论：** 完成率、过程质量、效率、失败行为在 model-harness 配对间差异巨大——**智能体能力应按\"模型-harness 配置\"报告，而非归于基座模型**\n - **执行对齐失败（execution-alignment failures）：** 反复出现的失败类型——貌似合理的推理与工具反馈、工作区状态、证据、可验证输出契约**脱钩**\n - 每次运行记录最终工件、执行轨迹、用量统计、校验器输出——支持超越\"最终完成与否\"的过程分析\n - 直接回应本仓库缺口清单的\"Harness 覆盖率评估方法\"\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 按 model-harness 配置报告能力 | #35 统计归因（榜单侧的同一主张）、#38 Position（立场侧） |\n| 执行对齐失败 | #24 AHE 的决策可观测性、#27 LangSmith Engine 的轨迹骨架 |\n| 过程质量 > 最终完成 | #33 HarnessAudit（安全侧的同构主张：中途轨迹才是关键） |\n\n---\n\n\n\n### 35. How good is your harness? 论文 — harness 效应的统计归因\n\n- **标题：** How good is your harness? Statistical evaluation of coding harnesses\n- **链接：** [openreview.net forum](https://openreview.net/forum?id=QI8z3skBwt)（[PDF 直链](https://openreview.net/pdf/99eabc2ce65fd2871a253a0a57954c934ea9e6b0.pdf)）\n- **作者：** Jiwoo Han, Yuekai Sun（密歇根大学统计系） | **日期：** 2026-05-25（OpenReview 发布，2026-06-16 末次修订） | **发表：** CTB@ICML 2026 workshop（首尔）\n- **核心：** 用纯统计方法（加性 GLM，logit link）把 Terminal-Bench 2.0 榜单的分数方差拆解归因到 harness 效应与 LLM 效应——不依赖 LLM 标注轨迹，只需要足够交叉的 harness×LLM 榜单设计。数据：清洗后 105 个 harness-LLM 对（28 个 harness × 26 个 LLM）。\n\n- **两个定量结论：**\n 1. **harness 与 LLM 同等重要：** 从基线 harness 换到最优 harness 的分数跃升 ≈ 从基线 LLM 换到最优 LLM 的跃升——\"harness 不是实现细节，是性能的关键组件\"第一次有了量化版本\n 2. **harness 效应异质：** 某些 harness 与某些 LLM 更配（如 OpenHands 配 OpenAI 模型好于配 Anthropic/Google 模型）；交互效应量级堪比主效应——harness 和 LLM **不是可完全互换的组件**\n- **对本仓库缺口的意义：** \"跨模型可移植性\"缺口的第一份定量证据——迁移 harness 到新模型时收益不保序，压测（#4 的\"定期重新压测假设\"）有了统计学理由\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 效应 ≈ 模型效应 | #3 Trivedy 的 Top 30→Top 5 轶事（本文把轶事升级为估计量）、#31 Osmani 引用的数据点 |\n| 效应异质 / 模型-harness 耦合 | #3 的\"模型 overfit 到训练 harness\"、#4 harness 瘦身 |\n| 榜单统计方法 | #34 Harness-Bench（受控实验侧）、#38 Position（立场侧）——评测三部曲 |\n\n---\n\n\n\n### 36. Anthropic / Claude — 动态工作流：模型现场写自己的 harness\n\n- **标题：** A harness for every task: dynamic workflows in Claude Code\n- **链接：** [claude.com/blog](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code)\n- **翻译：** [works/anthropic-dynamic-workflows-translation.md](../works/anthropic-dynamic-workflows-translation.md)\n- **作者：** Thariq Shihipar, Sid Bidasaria（Anthropic Claude Code 团队） | **日期：** 2026-06-02（功能随 Claude Code 2.1.154 + Opus 4.8 于 2026-05-28 发布）\n- **核心：** harness 本体论的转折点——Claude 现在**为任务现场编写自己的 JavaScript 编排脚本**，即一次性定制 harness。默认 Claude Code harness 要在同一个上下文窗口里既规划又执行，在长时运行、大规模并行、高度结构化、对抗性任务上会崩；dynamic workflows 把编排逻辑放进代码（在 token 上近乎免费），单会话扇出数十到数百个并行 subagent，各自在隔离上下文窗口内执行聚焦目标。\n\n- **关键洞察：**\n - **静态 workflow 的宿命是泛化损耗：** 预置工作流必须覆盖所有边界情况所以偏通用；Opus 4.8 已足够聪明为具体用例现写定制 harness——#4\"每个 harness 组件编码一个假设\"在这里变成\"假设由模型即时生成\"\n - **编排即代码：** workflow 可决定每个 agent 用什么模型、是否跑在独立 git worktree——智能等级与隔离度成为可编程参数\n - **对抗验证模式：** 每个生成 agent 配一个独立 agent 按 rubric 对抗校验其输出，收敛后才交付用户；官方 `/deep-research` skill 即此模式（扇出搜索→抓源→对抗核查→合成引用报告）\n - **激活策略：** 提示词含 \"workflow\" 触发，或用 \"ultracode\" 触发词确保建 workflow——回应本仓库缺口清单的\"控制激活策略\"\n - **workflow 是可沉淀资产：** 生成的脚本可检查、保存、复用，经 Skill 分发——一次性 harness 固化为版本化自动化\n - **反向蒸馏：** 挖掘近期 session 和 code review 评论中反复出现的纠正 → 并行 agent 聚类 → 对抗验证每条候选（\"这条规则真能防住一次真实错误吗？\"）→ 幸存者蒸馏回 CLAUDE.md\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 从人写工件变成模型生成工件 | #11 Meta-Harness、#24 AHE（自动搜索/演化的产品化收束）、#7 meta-harness |\n| 编排放进代码以省上下文 | #22 Deep Agents 解释器、#16 Symphony 控制平面 |\n| 对抗验证 | #4 的 Evaluator 分离、#10 评估清单 |\n| 千级 subagent 扇出 | #18 subagent 的 runtime state 管理、#33 多智能体风险面 |\n| 与 Ralph 单体论的张力 | #28 Huntley \"现阶段不需要多智能体\"——一年后官方产品反向而行 |\n\n---\n\n\n\n### 37. 马东锡 NLP — Harness 才是产品\n\n- **标题：** Harness 才是产品：决定 Coding Agent 体验的不是 Model，是它周围的整套 Runtime（Harness 系列）\n- **链接：** [SOTA Sync 转载页](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/)（原文发布于 X @dongxi_nlp，原帖需登录访问，本条目暂链转载页）\n- **作者：** 马东锡 NLP (@dongxi_nlp) | **日期：** 2026-06\n- **核心：** 把系列观点收束成一条产品论断：聊 coding agent 第一个该问的不是\"用哪个 model\"，而是\"**Harness 到底负责什么**\"。coding agent = 把 model 放进一套 runtime（查真实 repo、请求 tool、编辑文件、跑检查、记住发生过什么、多轮推进）——这层 runtime 就是 harness，\"对 coding agent 来说，harness 本身就是 product\"。\n\n- **关键洞察：**\n - **Mini agent 的五个真实爆点：** 编辑从没读过的文件 / shell 触碰 workspace 外 / tool 返回 50,000 行输出 / 磁盘文件已变而 transcript 还是旧读 / tool result 与 tool call 对不上——画出「observe → model → tool」草图的系统还不是 coding agent\n - **六个核心组件：** live repo context / prompt shape / structured tools / context reduction / transcripts & memory / delegation；\"context quality 经常看起来像 model quality\"\n - **\"Model 在 loop 里，harness 拥有 loop\"：** 一个 `edit src/config.py` tool call 只是 proposal，harness 要回答十来个裁决问题（path 是否在 workspace 内、会否经 symlink 逃逸、baseline 是否过期、要否 human approval、多少 output 进下一轮 prompt……）——\"这些判断不该交给 model 的随机处理\"\n - **Transcript ≠ working state：** \"发生过什么\"与\"现在什么重要\"是两份不同任务，必须区别对待\n - **症状→组件的 debug 对照表：** 不断重复→查 loop/retry policy；编辑 stale code→查 file-state baselines；越跑越差→查 context projection；运行意外东西→查 permission policy；无法从 tool error 恢复→查 tool result objects\n - **工程规则收尾：** \"Anything that must be reliable belongs in the harness.\"\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 拥有 loop / 裁决权 | #18 subagent（同系列前作：tool call outside, runtime inside） |\n| harness 是安全面 | #33 HarnessAudit（作者本人转发并背书） |\n| proposal vs 落实边界 | #25 Overeager（提示声明 vs 机械门控）、#31 hooks 分界论 |\n| context projection | #6 context editing、#22 第三类上下文表面 |\n\n---\n\n\n\n### 38. Position 论文 — 编码基准与智能体软件工程的错位\n\n- **标题：** Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering\n- **链接：** [arxiv.org/abs/2606.17799](https://arxiv.org/abs/2606.17799)\n- **作者：** Maria I. Gorinova, Macey Baker, Amy Heineike, Maksim Shaposhnikov, Rob Willoughby, Dru Knox | **日期：** 2026-06 | **arXiv：** 2606.17799\n- **核心：** 立场论文——我们用来比较编码智能体的基准诞生于前智能体时代：把 model、harness、environment 折叠进一个端到端分数，通常按单一参考解评分，没有可迭代的组件级信号。\"实践中的编码智能体不是模型，是 system harness——models/harnesses/contexts/environments/feedback signals 的复合体，其中任何一项都能把基准分数挪动一个相邻模型代际的量级。\"\n\n- **三个症状：**\n 1. 基准分数把模型与 harness 其余部分**混同**——排行榜差异无法归因\n 2. 按单一参考解评分**惩罚同样有效的替代方案**——真实工程里一题多解是常态\n 3. 缺少单个 harness 组件级别的信号，端到端系统分数**难以迭代**——你不知道该修哪里\n- **对本仓库的意义：** 与 #34（受控实验）、#35（榜单统计归因）构成\"harness 评测三部曲\"；也为 thinking/evaluation-elephant-in-the-room 的\"行为 harness 是大象\"补上评测学的病理诊断\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| model/harness/environment 折叠 | #35 的统计拆解方案、#34 的配置级测量方案 |\n| 单参考解惩罚多解 | #10 评估清单的 LLM-as-judge 校准 |\n| 组件级信号缺失 | #24 AHE 的三类可观测性（正是组件级信号的一种供给） |\n\n---\n\n\n\n### 39. OpenAI / Michael Bolin — 展开 Codex agent loop（Codex harness 解剖 · 上）\n\n- **标题：** Unrolling the Codex agent loop\n- **链接：** [openai.com](https://openai.com/index/unrolling-the-codex-agent-loop/)\n- **作者：** Michael Bolin (OpenAI, Codex CLI 团队) | **日期：** 2026-01-23\n- **核心：** Codex 系列工程博客第一篇——把 Codex CLI 的 agent loop（\"我们的 agent，或曰 harness\"）逐层展开：从用户输入构造初始 prompt、经 Responses API 推理、执行工具调用并把输出追加回 `input`，直到模型产出 assistant message 结束一个 turn。是官方视角下 harness 内部机制的最细粒度公开拆解。\n- **关键洞察：**\n - **prompt 是\"item 列表\"：** `instructions`（模型特定指令）+ `tools`（shell / update_plan / web_search / MCP 工具）+ `input`（sandbox 说明 → developer 指令 → AGENTS.md 聚合的用户指令 → environment_context → 用户消息）——AGENTS.md 从 git 根到 cwd 逐层聚合、默认 32 KiB 上限的机制被首次官方成文\n - **agent loop 天然是二次方的：** 每轮把全部历史重发；Codex 刻意不用 `previous_response_id` 以保持请求无状态并支持 ZDR（零数据保留），靠 prompt caching 把采样成本从二次方拉回线性\n - **缓存破坏向量：** 中途改 tools、换模型、改沙箱/审批/工作目录都会 cache miss；MCP 工具枚举顺序不稳定曾是真实 bug——应对策略是\"追加新消息表达变更，而不是改旧消息\"（与 #6 缓存五原则、#30 泄漏实锤的 14 种缓存破坏向量互证）\n - **compaction 的演进：** 从手动 `/compact`（用摘要替换 input）到 Responses API 专用 `/responses/compact` 端点——返回含 `encrypted_content` 的 `type=compaction` item，保留模型对原对话的潜在理解，超过 `auto_compact_limit` 自动触发\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness = agent loop 的官方自述 | #3 LangChain 的 Agent = Model + Harness、#17 Claude Code 逆向（对照组：Codex 侧的官方版） |\n| prompt caching 工程细节 | #6 缓存优化五原则、#30 泄漏实锤的缓存破坏向量追踪 |\n| AGENTS.md 聚合机制 | #5 HumanLayer 的 AGENTS.md 杠杆、概念 2 地图而非手册 |\n| compaction 端点化 | #7 Managed Agents 的 Session 外部存储、#22 上下文表面分层 |\n\n---\n\n\n\n### 40. OpenAI / Celia Chen — 解锁 Codex harness：App Server（Codex harness 解剖 · 下）\n\n- **标题：** Unlocking the Codex harness: how we built the App Server\n- **链接：** [openai.com](https://openai.com/index/unlocking-the-codex-harness/)\n- **作者：** Celia Chen (OpenAI) | **日期：** 2026-02-04\n- **核心：** Codex 的 web / CLI / IDE 扩展 / macOS 应用全部由同一个 Codex harness 驱动，而把这个 harness 暴露给所有客户端的是 Codex App Server——一个双向 JSON-RPC（JSONL over stdio）协议 + 长驻进程。把 harness 从产品内部件变成可被第三方集成的稳定平台面（HaaS 的 OpenAI 实现）。\n- **关键洞察：**\n - **三个对话原语：** Item（原子输入/输出单元，带 `started`/`delta`/`completed` 生命周期）、Turn（一次用户输入触发的工作单元）、Thread（可创建/恢复/fork/归档的持久容器）——为\"agent 交互不是请求/响应\"给出协议级建模\n - **协议是双向的：** 服务器可以主动发起请求（如审批），暂停 turn 直到客户端应答——权限门控被编进协议而非提示词\n - **harness 内容物 = agent loop + thread 生命周期与持久化 + 配置与认证 + 工具执行与扩展（sandbox、MCP、skills）**——官方划出的 harness 边界清单\n - **集成谱系：** App Server（全功能）> Codex SDK > MCP server 模式 > `codex exec`（CI 一次性）；跨厂商 harness 协议会收敛到能力交集，丰富交互难以表达——对\"标准化 vs 表达力\"权衡的一手表态\n - Codex Web 在容器里跑同一个 App Server 二进制，状态留在服务端，浏览器只是轻客户端——ephemeral 会话的断线重连由持久 thread 兜底\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| HaaS（Harness-as-a-Service） | #31 Osmani 的 HaaS 论、#7 Managed Agents 的 harne","works/AGENTS.md":"# works - AI Agent Protocol & Instructions\n\nPath: `works/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/works/AGENTS.md)","tools/harnesses/ralph-orchestrator.md":"# Harnesses Skill\n\nPath: `tools/harnesses/ralph-orchestrator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/tools/harnesses/ralph-orchestrator.md)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Harness Engineering 学习档案\n\n> 记录我学习「Harness Engineering」的完整过程：从概念理解到独立实践。\n>\n> 来源：[OpenAI — Harness Engineering: Harnessing Codex in an Agent-First World](https://openai.com/zh-Hans-CN/index/harness-engineering/)\n\n## 仓库结构\n\n| 目录 | 内容 | 说明 |\n|------|------|------|\n| `concepts/` | 概念笔记 | 原文核心概念的拆解与整理 |\n| `thinking/` | 独立思考 | 自己的理解、质疑、延伸思考 |\n| `practice/` | 动手实践 | 小项目实验，验证文章中的方法论 |\n| `feedback/` | 反馈记录 | 实践中的踩坑、修正、迭代心得 |\n| `works/` | 作品输出 | 可展示的成果（文章、工具、模板等） |\n| `tools/` | 工具具像化 | 降低 6 维复杂度的杠杆库（带主张，不是 awesome-list） |\n| `prompts/` | 提示词积累 | 学习过程中验证有效的提示词 |\n| `references/` | 外部资源 | 相关文章、仓库、工具的索引 |\n\n## 学习路线（进度）\n\n- [x] Phase 1：理解核心概念（concepts/，8 篇）\n- [x] Phase 2：形成自己的观点（thinking/，11 篇，持续中）\n- [x] Phase 3：选一个小项目实践（practice/，1 个 Ralph Demo）\n- [x] Phase 4：记录反馈迭代（feedback/，1 篇，持续中）\n- [x] Phase 5：输出可展示的作品（works/，40 篇翻译 + 1 篇原创 + 2 篇外部中文收录）\n\n> 进度详情以人类向 README.md 的\"学习路线\"段为准；本节是给智能体的快照。\n\n## 导航\n\n每个子目录都有自己的 AGENTS.md，说明该目录的用途、内容组织方式和写作约定。\n从任何一个目录开始，都能找到下一步该看什么。\n\n## 机械化检查\n\n`scripts/check-consistency.sh` 守护\"漂移\"问题：\n\n- **C1** — `references/articles.md` 编号 1..N 连续\n- **C2** — N 与下游 4 处声明同步（README badge × 2、`prompts/deep-research-tracker.md` 头部、`references/AGENTS.md` 概览）。文件含独立行 `` 时豁免\n- **C3** — `concepts/`、`thinking/`、`feedback/` 的 `*.md` 实际数与 README 中\"X 篇\"声明一致\n- **C4** — `works/*-translation.md` 文件数 ≡ 翻译计数所有声明（badges、`
` 摘要、Phase 5 注释、本文件 Phase 5 快照、READMEs 表格行数）\n- **C5** — README 结构树中 `concepts/` 子树的 item 行数 ≡ `concepts/*.md` 文件数（防止\"计数对了但树漏了\"）\n- **C6** — `references/articles.md` 末尾\"不计入 N 篇\"中的 N ≡ C1 权威值\n- **C7** — 三脉络 per-track 计数（脉络一/二/三）在 4 处下游声明保持一致：READMEs 资料库表、`references/AGENTS.md` 三脉络小标题、`prompts/deep-research-tracker.md` 三脉络明细\n- **C8** — 翻译流水线本地守卫：`translate/<...>/sources//source-full.md` 存在时，对应 `01-analysis.md` 不得再声称\"仅摘要页 / 建议补抓全文\"。`translate/` 已 gitignore，CI 与干净 clone 自动 SKIP，仅本地有过程稿时触发\n- **C9** — `concepts/` / `thinking/` / `feedback/` 正文不得裸写文库计数（\"N 篇文章 / N 篇翻译 / N 大概念\"）；历史性提法须带\"写作时点 / 当时 / 此前 / 首批 / 首轮 / 截至 / 快照\"限定词，否则去数字改链 `references/articles.md`\n- **C10** — 图片保真（纯本地、零网络）：每篇 `works/*-translation.md` 的 frontmatter 必须声明 `sourceFigureCount`（缺失即 FAIL；`null` = 原文不可得、未审计 → SKIP；数字 N → 正文嵌图数须 ≥ N），且所有本地嵌图路径（`imgs/...`）必须在磁盘上存在\n- **C11** — markdown 表格形状：README ×2、`references/AGENTS.md`、`references/articles.md`、`works/AGENTS.md` 里每一行表格的单元格数须与表头一致\n- **C12** — 条目字段完整性：`references/articles.md` 每个 `### N.` 编号条目必须带 **作者：** 与 **日期：** 字段\n- **C13** — 零插图声明须留痕：C10 只能证伪\"多报\"（嵌图数 < 声明数才 FAIL），因此 `sourceFigureCount: 0` 在本地**永远无法被证伪**——不管你有没有真去核对原文，它都是绿的。2026-07-27 就是这个洞放行了一个假 0（原文实有 4 张配图）。C10 刻意零网络、无法回查原文，所以改为要求留痕：**声明 0 的译文必须同时带 `sourceFigureAudit` 字段，值里要有 `YYYY-MM-DD` 核对日期**，写清怎么核对的、结论是什么。`null` 仍然 SKIP——它本来就自陈未审计\n- **C14** — 文档站防漂移：VitePress 站点（部署到 harness.dyu.sh）的侧边栏与首页统计一律由 `.vitepress/sidebar.mjs` 在构建时从文件系统生成，不手写。三条不变量：站点源码（`index.md`、`.vitepress/`）不得出现裸计数（\"N 篇\"），数字只能来自 `computeStats()`；每个一等内容文件必须在生成的侧边栏中恰好出现一次；仓库内禁止任何 symlink——Vite 会解引用 `public/` 下的软链、图片管线会读取链接目标，一条软链即可把仓库外文件带进公开产物（后两条经 `node .vitepress/sidebar.mjs --verify` 执行）。构建产物侧另有 `scripts/verify-dist.mjs` 断言页面与 `.md` 副本一一对应、副本链接可达、dist 无 symlink。站点脚手架不存在时 SKIP；node 不可用时 verify 半边 SKIP、裸计数 grep 照常执行\n\n执行：`bash scripts/check-consistency.sh`（仓库根目录）\n启用 pre-commit 阻断：`git config core.hooksPath .githooks`\n\n**CI 兜底**：`.github/workflows/consistency.yml` 在每次 push / PR 时跑同一脚本（不做路径过滤，保证必需检查总能上报）。job 显示名固定为 `consistency / check`——分支保护按 check run 名匹配必需检查，改名会让所有 PR 重新被 \"Expected\" 卡住。\n本地 hook 是开发反馈，CI 是合并门——两层独立，本地未启用 hook 不会绕过检查。\n","isInternal":false,"tokens":2217,"sizeBytes":5931},{"name":"AGENTS.md","path":"concepts/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/concepts/AGENTS.md","title":"concepts - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# concepts/ — 概念笔记\n\n原文六大核心概念的拆解与整理 + 后续阅读引出的延伸概念。每个概念一个文件，按阅读顺序编号。\n\n## 文件约定\n\n- 文件名：`{编号}-{英文短名}.md`，如 `01-repo-as-source-of-truth.md`\n- `00-overview.md` 是总览，先读这个\n- **文件名编号 ≠ 概念编号**：文件名编号是阅读顺序；\"概念 N\"的编号以 `00-overview.md` / README 的六大核心概念清单为准（两处一致）\n\n## 概念编号 ↔ 文件对照表（引用时以此为准）\n\n| 概念编号 | 概念 | 文件 |\n|---------|------|------|\n| 概念 1 | 仓库即记录系统 | [01-repo-as-source-of-truth.md](01-repo-as-source-of-truth.md) |\n| 概念 2 | 地图而非手册 | [00-overview.md §2](00-overview.md#map-not-manual)（无独立文件） |\n| 概念 3 | 机械化执行 | [02-mechanical-enforcement.md](02-mechanical-enforcement.md) |\n| 概念 4 | 智能体可读性 | [04-agent-readability.md](04-agent-readability.md) |\n| 概念 5 | 吞吐量改变合并理念 | [05-throughput-changes-merge.md](05-throughput-changes-merge.md) |\n| 概念 6 | 熵管理 = 垃圾回收 | [03-entropy-and-garbage-collection.md](03-entropy-and-garbage-collection.md) |\n| 总纲 | 人类掌舵，智能体执行 | [00-overview.md 总纲节](00-overview.md)（不占概念编号） |\n| 延伸 | Harness 的精确定义 | [06-harness-definition.md](06-harness-definition.md)（不占概念编号） |\n| 延伸 | 约束即产品（Spec as Product） | [07-spec-as-product.md](07-spec-as-product.md)（不占概念编号） |\n\n**引用约定**：跨文件引用概念时，写概念名并链接到具体文件（如 `[机械化执行](../concepts/02-mechanical-enforcement.md)`）；如需带编号，编号必须取自本表，不要裸写\"概念 N\"让读者猜编号体系。\n\n### 结构（建议，非强制）\n\n早期文件（01–03）来自 OpenAI 单一原文，结构倾向于：核心要点 → 关键实践 / 方案。\n后期文件（04–06）已演化为多源综合（OpenAI + LangChain + HumanLayer + Fowler），允许加入：\n\n- \"来自其他文章的补充\" / \"来自 X 的补充\"：跨源对照\n- \"关键洞察\" / \"类比\" / \"哲学\"：作者层加工\n- 06 是定义综合型，结构（定义 → 组件清单 → 跨源对照）与前 5 篇不同，属于合法变体\n\n约束只有两条：\n1. 第一段说清楚这个概念**是什么**（无论叫\"原文要点\"还是\"核心思想\"还是\"问题\"）\n2. 跨源内容必须**标注来源**（哪篇文章、哪个作者）\n\n## 已有内容\n\n| 文件 | 概念 | 来源 |\n|------|------|------|\n| [00-overview.md](00-overview.md) | 六大核心概念总览 | OpenAI 原文 |\n| [01-repo-as-source-of-truth.md](01-repo-as-source-of-truth.md) | 仓库即记录系统 | OpenAI 原文 |\n| [02-mechanical-enforcement.md](02-mechanical-enforcement.md) | 机械化执行 | OpenAI 原文 |\n| [03-entropy-and-garbage-collection.md](03-entropy-and-garbage-collection.md) | 熵管理与垃圾回收 | OpenAI 原文 |\n| [04-agent-readability.md](04-agent-readability.md) | 智能体可读性 | OpenAI + LangChain + HumanLayer + Fowler |\n| [05-throughput-changes-merge.md](05-throughput-changes-merge.md) | 吞吐量改变合并理念 | OpenAI + HumanLayer + LangChain + Fowler |\n| [06-harness-definition.md](06-harness-definition.md) | Harness 的精确定义与组件清单 | LangChain + HumanLayer + Fowler |\n| [07-spec-as-product.md](07-spec-as-product.md) | 约束即产品（Spec as Product）| OpenAI Symphony + Fowler + HumanLayer + Meta-Harness |\n\n## 下一步\n\n读完概念后，去 [thinking/](../thinking/) 写你自己的理解和质疑。\n","isInternal":false,"tokens":1312,"sizeBytes":3661},{"name":"AGENTS.md","path":"feedback/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/feedback/AGENTS.md","title":"feedback - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# feedback/ — 反馈记录\n\n实践中的踩坑、修正、迭代心得。把失败变成可复用的经验。\n\n## 文件约定\n\n- 文件名：`{日期}-{简述}.md`，如 `2026-03-24-agents-md-too-long.md`\n- 结构：问题描述 → 原因分析 → 解决方案 → 收获\n- 如果某个反馈导致了 prompts/ 或 concepts/ 的更新，交叉链接\n\n## 下一步\n\n反馈积累够了，去 [works/](../works/) 把经验提炼成可展示的作品。\n","isInternal":false,"tokens":166,"sizeBytes":455},{"name":"AGENTS.md","path":"practice/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/practice/AGENTS.md","title":"practice - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# practice/ — 动手实践\n\n选一个小项目，用 Harness Engineering 的方法论从零构建，验证原文中的经验。\n\n## 文件约定\n\n- 每个实验一个子目录，如 `practice/01-cli-tool/`\n- 每个实验包含：README.md（目标与方法）、AGENTS.md（给智能体的指导）、代码\n- 关键：人类只写提示词和约束，代码全部由智能体生成\n\n## 已有实验\n\n| 实验 | 验证的概念 | 结果 |\n|------|-----------|------|\n| [01-ralph-demo/](01-ralph-demo/) — Ralph Orchestrator 编排循环 | 帽子系统、背压门控、迭代循环、持久记忆 | 4 轮迭代完成 CLI word counter（321s / $0.31），7 项测试全绿；产物已归档可复验 |\n\n## 实验建议\n\n| 实验 | 验证的概念 | 复杂度 |\n|------|-----------|--------|\n| 用 Claude Code 生成一个 CLI 工具 | 仓库即记录系统 + AGENTS.md 设计 | ⭐ |\n| 为生成的代码写自定义 linter | 机械化执行 | ⭐⭐ |\n| 让智能体自己重构自己写的代码 | 熵管理与垃圾回收 | ⭐⭐⭐ |\n\n## 下一步\n\n实践中踩坑了？去 [feedback/](../feedback/) 记录下来。\n","isInternal":false,"tokens":399,"sizeBytes":1123},{"name":"AGENTS.md","path":"prompts/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/prompts/AGENTS.md","title":"prompts - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# prompts/ — 提示词积累\n\n学习过程中验证有效的提示词，按场景或工作流沉淀。**只收录亲测有效的，不收录未验证的。**\n\n## 文件形态（两种合法形式）\n\n### 形式 A：单条 Prompt（按场景命名）\n\n- 文件名：`{场景}.md`，如 `code-generation.md`、`code-review.md`\n- 必备字段：用途、提示词正文\n- 建议字段：效果评价（好/中/差）、改进记录、适用模型 / 不适用场景\n\n### 形式 B：Prompt 工作流（按工具链命名）\n\n- 文件名：`{工作流名称}.md`，如 `deep-research-tracker.md`\n- 必备字段：工作流目标、各步 Prompt 正文（A/B/C…）、链路图\n- 适合多模型 / 多步骤协作的场景（例如 ChatGPT Deep Research → Claude 深度分析 → 人工确认）\n\n## 场景分类参考\n\n| 场景 | 说明 |\n|------|------|\n| 项目初始化 | 让智能体生成仓库骨架、AGENTS.md、CI 配置 |\n| 代码生成 | 在架构约束下生成业务代码 |\n| 代码审查 | 智能体审查智能体生成的代码 |\n| 重构清理 | 熵管理 / 垃圾回收 |\n| 文档维护 | doc-gardening 智能体的提示词 |\n| 情报追踪 | 定期发现领域内新内容（见 deep-research-tracker.md） |\n\n## 已有内容\n\n| 文件 | 形态 | 用途 |\n|------|------|------|\n| [deep-research-tracker.md](deep-research-tracker.md) | 工作流 | 每 1–2 周追踪 Harness Engineering / AI 编程领域新内容 |\n\n## 下一步\n\n用了某条 Prompt 之后，把效果（好/中/差/翻车）记到 [feedback/](../feedback/)；\n积累到一定量再回到本目录补\"效果评价 / 改进记录\"。\n","isInternal":false,"tokens":584,"sizeBytes":1622},{"name":"AGENTS.md","path":"references/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/references/AGENTS.md","title":"references - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# references/ — 外部资源索引\n\n相关文章、仓库、工具的统一索引。这里是指针，不是内容本身。\n\n## 文件约定\n\n- 按主题分文件，如 `articles.md`、`repos.md`、`tools.md`\n- 每条记录包含：链接、一句话说明、与 Harness Engineering 的关联\n\n## 文章\n\n详见 [articles.md](articles.md) — 完整的文章索引，含三条脉络 **79 篇文章 + 1 项已跟踪产品** 的深度摘要。\n权威计数与编号规则以 `articles.md` 头部为准；本表是它的概览缓存。\n\n### 脉络一：AI 时代的 Harness Engineering（75 篇）\n\n| # | 文章 | 作者 | 核心贡献 |\n|---|------|------|---------|\n| 1 | [OpenAI 原文](https://openai.com/zh-Hans-CN/index/harness-engineering/) | Ryan Lopopolo | 原点：六大概念 |\n| 2 | [Martin Fowler](https://martinfowler.com/articles/harness-engineering.html) | Birgitta Böckeler | Guides×Sensors 控制论框架 + Harnessability + Ashby 定律 |\n| 3 | [LangChain](https://blog.langchain.com/the-anatomy-of-an-agent-harness/) | Vivek Trivedy | 精确定义 + 组件清单 |\n| 4 | [Anthropic](https://www.anthropic.com/engineering/harness-design-long-running-apps) | Prithvi Rajasekaran | GAN 三智能体 + Harness 瘦身 |\n| 5 | [HumanLayer](https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents) | Kyle | 六个杠杆 + 实战避坑 |\n| 6 | [Anthropic/Claude Platform](https://claude.com/blog/harnessing-claudes-intelligence) | Lance Martin | 三大构建模式 + BrowseComp 数据 |\n| 7 | [Anthropic/Managed Agents](https://www.anthropic.com/engineering/managed-agents) | Lance Martin 等 | Meta-harness + 基础设施解耦 |\n| 8 | [Fowler/Encoding Team Standards](https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html) | Rahul Garg | 团队标准显式化三层路径 |\n| 9 | [Fowler/Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html) | Rahul Garg | 从 AI 失败中持续学习的反馈闭环 |\n| 10 | [LangChain/Agent Evaluation Checklist](https://blog.langchain.com/agent-evaluation-readiness-checklist/) | LangChain 团队 | 智能体评估五阶段清单 |\n| 11 | [Meta-Harness 论文](https://arxiv.org/abs/2603.28052) | Yoonho Lee 等 (Stanford) | 自动化 Harness 搜索优化 |\n| 12 | [GitHub/Agent-driven Development](https://github.blog/ai-and-ml/github-copilot/agent-driven-development-in-copilot-applied-science/) | Tyler McGoffin | 智能体驱动开发实战 |\n| 13 | [Inside the Scaffold 论文](https://arxiv.org/html/2604.03515v1) | Benjamin Rombaut (Huawei) | 13 个编码智能体脚手架源代码分类法 |\n| 14 | ⭐ [Eight years of wanting](https://lalitm.com/post/building-syntaqlite-ai/) | Lalit Maganti | AI 构建真实项目的坦诚复盘 |\n| 15 | [Continual learning for AI agents](https://blog.langchain.com/continual-learning-for-ai-agents/) | Harrison Chase | 三层学习：模型/Harness/上下文 |\n| 16 | [OpenAI Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/) | Kotliarskyi 等 | 任务跟踪器作为控制平面 + SPEC/WORKFLOW 即产品 |\n| 17 | [Claude Code Architecture](https://vrungta.substack.com/p/claude-code-architecture-reverse) | Vikash Rungta | Claude Code 运行外壳、TAOR 循环、工具原语、权限与上下文管理的外部逆向分析 |\n| 18 | [Harness 系列文章之 7：关于 subagent](https://x.com/dongxi_nlp/status/2068922428516892998) | 马东锡 NLP | Subagent = tool call 入口 + child runtime；区分 session/context/subagent 与 evidence 回流 |\n| 19 | [Fowler/Maintainability sensors](https://martinfowler.com/articles/sensors-for-coding-agents.html) | Birgitta Böckeler | 计算性 vs 推理性传感器谱系 + 失败案例 + AI 评审作为垃圾回收 |\n| 20 | [Fowler/SPDD](https://martinfowler.com/articles/structured-prompt-driven/) | Wei Zhang, Jessie Jie Xia | REASONS Canvas 七维 + prompt 即一等交付物 + 双向闭环 |\n| 21 | [LangChain/ADLC](https://www.langchain.com/blog/the-agent-development-lifecycle) | Harrison Chase | 智能体开发生命周期 + framework/runtime/harness 三分类 |\n| 22 | [LangChain/Interpreters in Deep Agents](https://www.langchain.com/blog/give-your-agents-an-interpreter) | Hunter Lovell | interpreter 是第三类上下文表面 + 35% token 节省 |\n| 23 | [Anthropic/质量回归复盘](https://www.anthropic.com/engineering/april-23-postmortem) | Anthropic 工程团队 | 三起独立变更叠加成质量退化 + 变更治理清单（第一手反例） |\n| 24 | [Agentic Harness Engineering 论文](https://arxiv.org/html/2604.25850v4) | Jiahang Lin 等（复旦/北大/奇绩） | 可观测性驱动的 Harness 自动演化 + 每次编辑即可证伪契约 |\n| 25 | [Overeager Coding Agents 论文](https://arxiv.org/html/2605.18583v1) | Yubin Qu 等 | 越界动作测量 + 提示声明授权反而降低边界推断 |\n| 26 | [How I Use AI to Code](https://chrismdp.com/coding-with-ai/) | Chris Parsons | 四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈 |\n| 27 | [How we built LangSmith Engine](https://www.langchain.com/blog/how-we-built-langsmith-engine-our-agent-for-improving-agents) | Palash Shah | 用智能体改进智能体 + trace→轨迹骨架 + screener/investigator 两阶段闭环 |\n| 28 | [Ralph 原始文章 + 续篇](https://ghuntley.com/ralph/) | Geoffrey Huntley | Ralph = bash 循环 + 每轮干净上下文 + 背压；单体反多智能体论（还上 practice/ Ralph Demo 的理论债） |\n| 29 | [My AI Adoption Journey](https://mitchellh.com/writing/my-ai-adoption-journey) | Mitchell Hashimoto | 六步采纳路线 + \"harness engineering\" 命名出处（由延伸阅读升格） |\n| 30 | [Claude Code 源码泄漏事件](https://github.com/pankaj28843/understanding-claude-code) | Chaofan Shou 发现 / 社区聚合分析 | 512K 行 harness 实锤解剖：QueryEngine/60+ 门控工具/KAIROS/AutoDream，#17 推测的对照组 |\n| 31 | [Agent Harness Engineering](https://addyosmani.com/blog/agent-harness-engineering/) | Addy Osmani | 学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS（综述破例进编号正文） |\n| 32 | [Exploring AI coding sensors](https://www.thoughtworks.com/en-au/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors) | Böckeler & Ford | 有/无传感器对照实验 + 态势感知论 + harness 模板展望 |\n| 33 | [HarnessAudit 论文](https://arxiv.org/abs/2605.14271) | Chengzhi Liu 等 | harness 安全审计：中途轨迹违规是输出级评估的盲区 + 210 任务基准 |\n| 34 | [Harness-Bench 论文](https://arxiv.org/abs/2605.27922) | Yilun Yao 等 | 配置级 harness 效应测量（106 任务/5194 轨迹）+ 执行对齐失败分类 |\n| 35 | [How good is your harness? 论文](https://openreview.net/forum?id=QI8z3skBwt) | Jiwoo Han, Yuekai Sun | Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应，且效应异质 |\n| 36 | [Dynamic workflows in Claude Code](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code) | Anthropic / Claude | 模型现场写自己的编排 harness + 对抗验证 + workflow 沉淀为 Skill |\n| 37 | [Harness 才是产品](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/) | 马东锡 NLP | \"Model 在 loop 里，harness 拥有 loop\" + 六组件 + 症状→组件 debug 对照表 |\n| 38 | [Position: 基准错位论文](https://arxiv.org/abs/2606.17799) | Maria I. Gorinova 等 | 基准把 model/harness/环境折叠进一个分数的三症状诊断 |\n| 39 | [Unrolling the Codex agent loop](https://openai.com/index/unrolling-the-codex-agent-loop/) | Michael Bolin (OpenAI) | Codex harness 解剖·上：prompt 构造 / 二次方问题与 prompt caching / compaction 端点化 |\n| 40 | [Unlocking the Codex harness](https://openai.com/index/unlocking-the-codex-harness/) | Celia Chen (OpenAI) | Codex harness 解剖·下：App Server 双向 JSON-RPC + Item/Turn/Thread 原语 + HaaS 落地 |\n| 41 | [Loop Engineering](https://addyosmani.com/blog/loop-engineering/) | Addy Osmani | loop 定调文：五构件 + 记忆脊柱；\"循环分不出两种用法的区别，你分得出\" |\n| 42 | [The Coming Loop](https://lucumr.pocoo.org/2026/6/23/the-coming-loop/) | Armin Ronacher | 怀疑派回应：agent loop vs harness loop + 防御式编码放大 + 软件作为有机体 |\n| 43 | [Loop engineering: Getting started with loops](https://claude.com/blog/getting-started-with-loops) | Claude Code 团队 | 官方四类循环（turn/goal/time/proactive）+ `/goal` 独立判停 + 用量治理清单 |\n| 44 | [Self-Harness 论文](https://arxiv.org/abs/2606.09498) | Hangfan Zhang 等 | 智能体自改 harness：弱点挖掘→提议→回归验证；三模型 held-out +14~21pp |\n| 45 | [Harness Engineering for Self-Improvement](https://lilianweng.github.io/posts/2026-07-04-harness/) | Lilian Weng | RSI 综述：三设计模式 + 优化对象递进链 + 七项未来挑战 + \"harness 终将内化\"预测 |\n| 46 | [Aria：自动软件验证论文](https://arxiv.org/abs/2607.06341) | Shuangxiang Kan 等 | 行为 harness 极限形态：声明式 HHL 包裹通用智能体做 Coq 证明，全引理零人工通过 |\n| 47 | [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) | Mikaela Grace 等 (Anthropic) | 智能体评测官方方法论：outcome≠transcript、pass@k/pass^k、评结果不评路径、CORE-Bench 42%→95% 基准病理 |\n| 48 | [Scaling long-running autonomous coding](https://cursor.com/blog/scaling-agents) | Wilson Lin (Cursor) | 数百并发智能体 × 数周：扁平自协调失败史 → planner/worker/judge；FastRender 百万行浏览器 |\n| 49 | [Building a C compiler with parallel Claudes](https://www.anthropic.com/engineering/building-c-compiler) | Nicholas Carlini (Anthropic) | 16 agent 无编排者造 10 万行 C 编译器（$20k/两周）：近乎完美验证器 + GCC oracle + 为 Claude 写测试 |\n| 50 | [How we contain Claude across products](https://www.anthropic.com/engineering/how-we-contain-claude) | Max McGuinness 等 (Anthropic) | 三隔离模式 × 五起漏掉的风险：白名单是能力授予；先环境层遏制再模型层引导 |\n| 51 | [Deep Agents 动态子智能体 + RLM](https://www.langchain.com/blog/introducing-dynamic-subagents-in-deep-agents) | LangChain 团队 | 模型写编排脚本驱动 subagent（QuickJS + `task()`）；RLM 处理超上下文两个数量级的输入 |\n| 52 | [Böckeler 本地模型双备忘录](https://martinfowler.com/articles/exploring-gen-ai/local-models-for-coding-factors.html) | Birgitta Böckeler | 高端开发机跑本地小模型做智能体编码实测：Qwen3.6 35B MoE 甜点、工具调用是分水岭 |\n| 53 | [Harness Handbook 论文](https://arxiv.org/abs/2607.13285) | Ruhan Wang 等（腾讯等） | 行为定位是 harness 演化瓶颈：行为中心表示 + BGPD，win rate +10.0/+18.9pp 且省 12.7%/8.6% token |\n| 54 | [DSLs Enable Reliable Use of LLMs](https://martinfowler.com/articles/llm-and-dsls.html) | Unmesh Joshi | \"DSL 工具集本身就是出色的 harness\"：语言层约束 + 确定性验证器 + 领域级错误反馈 |\n| 55 | [Own the Outer Loop](https://addyosmani.com/blog/own-the-outer-loop/) | Addy Osmani | 智能体跑内环、工程师拥有外环问责；back-pressure 调节循环速率与作用域来授予自主权 |\n| 56 | [Rewriting Bun in Rust](https://bun.sh/blog/bun-in-rust) | Jarred Sumner | \"修流程不修代码\"工业级实录：50 dynamic workflows × 64 Claude × 11 天移植 53.5 万行 Zig；语言无关测试套件作 oracle + 对抗评审默认化 |\n| 57 | [HarnessX 论文](https://arxiv.org/abs/2606.14249) | Darwin Agent Team（小米） | harness 一等类型化对象 + AEGIS 轨迹演化 + cross-harness GRPO 共演化：+14.5%（共演化再 +4.7%），弱模型受益最大 |\n| 58 | [Anthropic/长时智能体的有效 harness](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) | Justin Young | 外部工件即记忆的奠基文：initializer + coding 两段式、200+ 条 feature_list.json、progress 文件 + git、Puppeteer 端到端自验（存量回扫补录） |\n| 59 | [Anthropic/基础设施噪声](https://www.anthropic.com/engineering/infrastructure-noise) | Gian Segato | 只改资源配额，Terminal-Bench 2.0 摆动 6pp；1x–3x 修可靠性、3x 以上改变被测对象；\"低于 3pp 的榜单差距都该怀疑\" |\n| 60 | [Cursor/持续改进 agent harness](https://cursor.com/blog/continually-improving-agent-harness) | Stefan Heule & Jediah Katz | harness 运维的度量学：Keep Rate、LLM 读用户回复判满意、错误分类与按工具按模型基线、每周 Automation 修 harness；按训练分布供给工具格式 |\n| 61 | [Cursor/奖励作弊淹没智能增益](https://cursor.com/blog/reward-hacking-coding-benchmarks) | Naman Jain | 审计 731 条轨迹：SWE-bench Pro 上 63% 的成功解是检索答案而非推导；封 git+断网后 Opus 4.8 Max 87.1%→73.0% |\n| 62 | [Better Models: Worse Tools](https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/) | Armin Ronacher | 工具 schema 不是中立的：在宽容 harness 里做 RL，新模型对替代 schema 反而更差；跨模型可移植性的机制级坏消息 |\n| 63 | [为什么软件工厂会失败](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md) | Dex Horthy (HumanLayer) | \"harness engineering 还不够\"：可维护性没有快 oracle，RL 不惩罚坏设计；熄灯工厂第一手失败实录 + 四阶段前移方案 |\n| 64 | [Software Factories, Light and Dark](https://addyosmani.com/blog/software-factories/) | Addy Osmani | loop→harness→factory 三层 + 唯一昂贵的评审闸门 + 背压规则 + \"什么样的循环配得上熄灯\"准入清单 |\n| 65 | [智能体蜂群与新的模型经济学](https://cursor.com/blog/agent-swarm-model-economics) | Wilson Lin (Cursor) | 从 835 页手册重造 SQLite：质量趋同、账单从 $1,339 到 $10,565；规划/执行分层、自建 VCS（1000 提交/秒）、去相关评审、Field Guide |\n| 66 | [Claude 5 世代的上下文工程新规则](https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models) | Thariq Shihipar (Anthropic) | 删掉 Claude Code 系统提示词 80%+ 而编码评测无可测损失；七组 then/now 对照 + `claude doctor` |\n| 67 | [Don't Blame the LLM 论文](https://arxiv.org/abs/2607.03691) | Oussama Ben Sghaier 等（Queen's） | 首个固定模型、只变 harness 的受控纵向研究：Qwen Code CLI 35 个连续版本 × 50 个 SWE-bench Verified 任务 |\n| 68 | [Rethinking Harness Evolution 论文](https://arxiv.org/abs/2607.12227) | Yike Wang 等 | 自动 harness 演化的第一份系统性负面结果：同等预算下不稳定优于简单 test-time scaling，泛化有限 |\n| 69 | [LangChain/Harbor 评测栈](https://www.langchain.com/blog/how-we-benchmark-deep-agents) | Nick Hollon, Harrison Chase 等 | 给 harness 建标尺（Harbor-Index 82 任务 / lite 子集 / capability suite），再给标尺建标尺（IssueBench 15 类失败分类法） |\n| 70 | [LangChain/ReviewBench](https://www.langchain.com/blog/evaluating-code-review-agents-with-reviewbench) | Nick Hollon | 给\"AI 代码评审\"传感器造考卷：真实 PR 评审意见策展成 59 任务；裸 harness 最强召回 ~30%，prompt-only 调优 0.13→0.32 反超 |\n| 71 | [Fowler/TDD in the agent loop](https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html) | Birgitta Böckeler | agent loop 内 TDD 的实证否定：盲评质量无差异、token 3–8.5 倍；别规定过程，度量结果 |\n| 72 | [Osmani/Practical Loop Engineering](https://addyosmani.com/blog/practical-loop-engineering/) | Addy Osmani | loop 系列日常落地环：踩坑实录（差点连判断也委托）+ 分诊循环 + fine print 运维细则 |\n| 73 | [Zalando 组织级快照](https://engineering.zalando.com/posts/2026/08/agentic-engineering-at-zalando-a-snapshot.html) | Bartosz Ocytko | 250+ 团队非供应商第一人称：事故分析→风险分级→33% 自动放行→lead time -20~40% 的组织级反馈回路 |\n| 74 | [Earendil/Pi 双篇](https://earendil.com/posts/what-is-a-harness/) | Pi 团队 | harness 定义+用户侧中立主张 / compaction 白盒实现（20K 预算、独立请求、纯文本可移植）——与 #39 端点化恰成对照 |\n| 75 | [⭐ StarHarness 论文](https://arxiv.org/abs/2608.24804) | ServiceNow/Mila | 冻结 harness 工件跨 GPT/Qwen 迁移 12 行全正（+10.7~+46.3pp）；跨模型可移植性缺口首个正面证据 |\n\n### 脉络二：云原生 Harness.io（2 篇）\n\n| # | 文章 | 核心贡献 |\n|---|------|---------|\n| 76 | [Harness.io 官方](https://www.harness.io/blog/understanding-ci-cd-platforms-the-backbone-of-modern-devops) | CI/CD 平台全局架构 |\n| 77 | [Google Cloud Architecture](https://docs.cloud.google.com/architecture/partners/harness-cicd-pipeline-for-rag-app) | Harness + GCP 部署 RAG |\n\n### 脉络三：效率悖论与能力进化（2 篇）\n\n| # | 文章 | 核心贡献 |\n|---|------|---------|\n| 78 | [YDD / Miss-you](https://yousali.com/posts/20260303-ai-coding-efficiency-to-evolution/) | 效率悖论的系统性拆解：约束理论 + Spec/Rule/Skill + 验证闭环 + 并发 |\n| 79 | [METR 实验后续 + 自报调查](https://metr.org/blog/2026-02-24-uplift-update/) | \"慢 19%\" 的官方后续：弱证据转向加速 + AI 渗透破坏 RCT 可行性本身 |\n\n### 已跟踪产品 / 项目（不计入文章数）\n\n| 项 | 项目 | 说明 |\n|---|------|------|\n| ⭐ | [Chachamaru127 / claude-code-harness v4.2 \"Hokage\"](https://github.com/Chachamaru127/claude-code-harness/tree/v4.2.0) | Claude Code 上当下最完整的开源 harness 实现之一；Plan→Work→Review→Release 五动词 + Go 原生 R01–R13 guardrail。本仓库分析见 `thinking/guides-sensors-meets-claude-code-harness.md` |\n\n## 项目\n\n### Ralph 系列\n\n| 项目 | Stars | 说明 | 关联概念 |\n|------|-------|------|---------|\n| [snarktank/ralph](https://github.com/snarktank/ralph) | 13.6k | 原版 Ralph 循环：bash + PRD + 每次清空上下文 | 全部六大概念的最小实现 |\n| [ralph-orchestrator](https://mikeyobrien.github.io/ralph-orchestrator/) | 2.3k | Rust 版：Hat 角色 + 事件驱动 + 背压 | 机械化执行、熵管理 |\n| [bmad-ralph](https://github.com/qianxiaofeng/bmad-ralph) | 2 | BMAD + Ralph：并行 worktree + 三层自愈 | 自主水平提升、吞吐量 |\n\n### 社区\n\n| 资源 | 说明 | 关联 |\n|------|------|------|\n| [vibe-coding-cn](https://github.com/tukuaiai/vibe-coding-cn) | 中文 Vibe Coding 社区 | 仓库组织方式、AGENTS.md 分级 |\n\n### 延伸阅读\n\n| 资源 | 说明 |\n|------|------|\n| [Martin Fowler: Context Engineering for Coding Agents](https://martinfowler.com/articles/context-engineering-coding-agents.html) | Context Engineering 专题 |\n| [Martin Fowler: Humans and Agents in SE Loops](https://martinfowler.com/articles/humans-and-agents.html) | 人类与智能体的协作模式 |\n\n> Mitchell Hashimoto 的 My AI Adoption Journey 原在此表，2026-07 已升格为编号条目 #29。\n\n## 待补充\n\n> 占位条目统一收在这里，**不进 `articles.md` 的编号正文**，避免污染文章计数。\n\n- [x] Geoffrey Huntley 的 Ralph 原始文章 → 已收录为 #28（2026-07）\n- [x] OpenAI Codex harness 解剖二部曲 → 已收录为 #39（Unrolling the Codex agent loop）+ #40（Unlocking the Codex harness / App Server）（2026-07-15）\n- [ ] 马东锡 Harness 系列其余篇目（仓库已收 #18 之 7、#37 才是产品；2026-07 系列新帖包括\"Model 可以请求，Harness 负责裁决——这就是契约\"\"模型记住的是 transcript，Harness 必须记住 truth（File State 是合格 harness 的基本功）\"；X 原帖需本地工具抓取）\n- [ ] Medium 实战专栏 — \"Beyond Migration: How We Engineered a Secure & Intelligent Delivery Platform with Harness CICD\"（标题可能已变更或文章已下架）\n\n## 下一步\n\n读完一篇资料后：\n- 想对它的论点做独立分析或质疑 → [thinking/](../thinking/)\n- 想翻译为中文输出 → [works/](../works/)\n- 想用它的方法做实验 → [practice/](../practice/)\n- 想沉淀其中的提示词模板 → [prompts/](../prompts/)\n","isInternal":false,"tokens":7240,"sizeBytes":20467},{"name":"AGENTS.md","path":"thinking/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/thinking/AGENTS.md","title":"thinking - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# thinking/ — 独立思考\n\n读完 concepts/ 后，在这里写下你自己的理解、质疑和延伸思考。\n\n## 文件约定\n\n- 文件名：自由命名，建议用问题或论点作为文件名\n- 例如：`harness-vs-vibe-coding.md`、`is-this-only-for-openai.md`\n- 结构：问题/论点 → 自己的分析 → 结论或开放问题\n- 鼓励质疑原文，提出反例\n\n## 已有文章\n\n| 文件 | 主题 | 核心论点 |\n|------|------|---------|\n| [cross-article-insights.md](cross-article-insights.md) | 跨文章深层洞见 | 8 个洞见：Harness 生命周期、四学派、评估之踵、人类角色消解 |\n| [harnessability-and-java.md](harnessability-and-java.md) | Java 的可驾驭性 | Java/Spring 天然提供高 Harnessability 基线 |\n| [meta-harness-tensions.md](meta-harness-tensions.md) | Meta-Harness 的五个张力 | Anthropic Managed Agents 与既有实践的矛盾 |\n| [evaluation-elephant-in-the-room.md](evaluation-elephant-in-the-room.md) | 评估是房间里的大象 | 行为正确性验证是整个体系的阿喀琉斯之踵 |\n| [harness-for-solo-developers.md](harness-for-solo-developers.md) | 个人开发者的 Harness | 六大概念的适用性分析：直接可用 vs 需要降级 vs 不适用 |\n| [guides-sensors-meets-claude-code-harness.md](guides-sensors-meets-claude-code-harness.md) | Böckeler 框架 vs claude-code-harness v4.2 | 产品级实现暴露的五个张力：Advisor 装不进 2×2、guardrail 融合前馈反馈、行为 Harness 是结构性绕过、追上游占 95% 维护成本、harness 必带价值观锁定 |\n| [software-project-complexity-in-the-ai-era.md](software-project-complexity-in-the-ai-era.md) | AI 时代的软件项目复杂度 | 6 维（上下文压力 / 可提示性 / 探索收敛 / 状态纠缠 / 暗知识 / 验证成本）+ 胶囊化分母 + 重构/复刻终局指标 |\n| [subagent-is-child-runtime.md](subagent-is-child-runtime.md) | Subagent 是 child runtime | 与 Claude Code 架构逆向互证：subagent = tool-call-triggered child session + context projection + evidence-return contract |\n| [why-this-project-exists.md](why-this-project-exists.md) | 为什么有这个项目 | 项目宗旨：把 Harness Engineering 从\"概念集合\"变成\"可复刻的产品构建方法论\"——借用《诡秘之主》\"学徒途径\"隐喻 |\n| [fix-the-process-not-the-code.md](fix-the-process-not-the-code.md) | 修流程，不修代码 | Bun 重写案例对照 #36/#49/#55：工程师的交付物是生成过程本身；测试套件与实现语言正交是 Harnessability 新维度；验证器完备度决定成本曲线 |\n| [se-to-agent-engineering-mapping.md](se-to-agent-engineering-mapping.md) | 传统 SE ↔ Agent 工程对照表 | 15 行同构映射的三处修正：右列主语混三层（①人对 agent ②agent 自身 ③人对系统）、补熵管理/并发合并/持久会话三行、版本钉选风险倒置与评估地位跃迁；每个模型代际重审一遍，纹丝不动的子集才是学科骨架 |\n\n## 写作方向参考\n\n- 机械化执行的边界在哪？过度 lint 是否会限制智能体创造性？\n- Harness Engineering vs Vibe Coding：本质区别是什么？\n- \"零手写代码\"是刻意的实验约束，还是可推广的工程实践？\n- Context Engineering vs Harness Engineering：边界与关系\n\n## 下一步\n\n有了自己的观点后，去 [practice/](../practice/) 用实验验证它。\n","isInternal":false,"tokens":1186,"sizeBytes":3413},{"name":"AGENTS.md","path":"tools/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/tools/AGENTS.md","title":"tools - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# tools/ — 工具具像化\n\n把 `concepts/` 里抽象的 Harness 概念落到具体可用的工具上。\n本目录的核心问题：**哪些工具能切实降低 [6 维复杂度框架](../thinking/software-project-complexity-in-the-ai-era.md) 中的某一维，或提升\"胶囊化能力\"这个总杠杆？**\n\n## 文件约定\n\n- `00-overview.md` — 工具地图：维度 × 工具矩阵（先读）\n- `harnesses/` — Agent harness 框架（首篇：[ralph-orchestrator.md](harnesses/ralph-orchestrator.md)；Claude Code、Codex、Cursor 等待写）\n- `auxiliary/` — 辅助工具（linter、CI、文档、测试、依赖分析等）；**规划中**，首篇辅助工具页落地时再建目录\n\n每个工具页结构（建议，非强制）：\n\n1. **一句话定位** —— 它是什么\n2. **降低哪些维度的复杂度** —— 引用 6 维框架的具体维度名 + 是否提升\"胶囊化能力\"\n3. **实测体验** —— 用过的真实场景、生效边界、失效场景\n4. **搭配建议** —— 与本目录其他工具的组合\n5. **替代方案** —— 同类竞品对比（如有）\n\n## 收录标准\n\n- **自己实际用过** —— 不收\"听说很好\"的工具\n- 或在 [`practice/`](../practice/) 中验证过\n- 拒绝\"工具大全\"式罗列——本目录不是 awesome-list，是带主张的杠杆库\n\n## 与其他目录的关系\n\n- `concepts/` 提出**该做什么**\n- `tools/` 提供**用什么做**\n- `practice/` 给出**实际做的过程与结果**\n\n## 下一步\n\n读完 [00-overview.md](00-overview.md) 后，按维度反查工具，按工具反查实践。\n","isInternal":false,"tokens":623,"sizeBytes":1591},{"name":"AGENTS.md","path":"works/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/works/AGENTS.md","title":"works - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# works - AI Agent Protocol & Instructions\n\nPath: `works/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/works/AGENTS.md)","tokens":300,"sizeBytes":180},{"name":"SKILL.md","path":".claude/skills/curate-research/SKILL.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/.claude/skills/curate-research/SKILL.md","title":"curate-research","category":"anthropic-skill","format":"markdown","content":"---\nname: curate-research\ndescription: 把一批 Harness Engineering 调研候选（文章/论文/工具的 URL）走完「抓取→翻译→评审→收录→清理」流水线，整合进本仓库 works/ 与 references/articles.md，并保持 C1–C13 一致性检查全绿。当用户说\"处理这批调研候选 / 收录这些链接 / 整理 translate / 把这几篇翻译收进来\"时使用。这是仓库给自己用的策展 harness。\n---\n\n# curate-research —— 仓库自我策展 harness\n\n> 一个讲 Harness Engineering 的仓库，用一个 harness 来策展自己。本 skill 把外部调研候选可控地整合进 tracked 档案。\n>\n> **核心约束：评审全自动；收录是人类闸门，必须停下来和用户来回讨论后才动 `works/` 与 `articles.md`。**\n\n## 何时用\n\n- 用户给出一批候选 URL（文章 / 论文 / 工具 / 项目），希望整合进仓库\n- 用户说「处理 / 收录 / 整理」`translate/` 暂存区的翻译\n- 已有 `translate//works-ready/` 候选译文，要决定去向\n\n## 输入与产物路径\n\n暂存区（gitignored，本地过程区）：`translate//`\n- `sources//source.md`（原文快照；论文额外抓 `source-full.md`）\n- `translations//{01-analysis,02-prompt,translation}.md`（过程三件套）\n- `works-ready/-translation.md`（发布候选）+ `works-ready/README.md`（状态表，本批权威）\n\n正式档案（tracked）：`works/-translation.md` + `references/articles.md` 条目。\n\n## 流水线 6 阶段\n\n```\n①抓取 ──②翻译 ──③评审[全自动] ──🚧人类闸门🚧──④收录 ──⑤校验 ──⑥清理\n```\n\n### ① 抓取\n用 `baoyu-url-to-markdown` 把每个 URL 存到 `sources//source.md`。**论文/长文必须额外抓 HTML 全文到 `source-full.md`**（否则只有摘要页，C8 会拦谎报）。\n\n### ② 翻译\n按 baoyu-translate 配置生成 `translations//` 三件套 → `works-ready/-translation.md`。`01-analysis.md` 要含收录建议；`source-full.md` 存在时，分析稿不得声称「仅摘要页」。\n\n### ③ 评审（全自动并行扇出）\n对每篇候选派一个评审 agent（一批 3–4 篇，并行多个 agent）。统一打分维度，吐结构化定性。**标准评审 prompt 模板：**\n\n> 你是 Harness Engineering 中文知识库的内容评审。仓库主题：人类设计约束与反馈回路、AI agent 写代码。\n> 读 `sources//source.md`(+`source-full.md`)、`works-ready/-translation.md`、`translations//01-analysis.md`，逐篇回答：\n> - **原文价值**：原创洞察密度 / 长文实质 vs 产品页·发布稿·摘要。高/中/低\n> - **翻译质量**：完整逐译 / 压缩摘要 / 首轮粗稿；通顺度、术语到位度。精品/合格/需返工\n> - **与仓库契合度**：补薄弱环节还是重复\n> - **一句话定性 + 建议去向**：works/ 正式收录 / articles.md 观察项一行 / tools/ / 暂不收录\n> 基于实际内容，紧凑中文，结构化输出即为最终产出。\n\n汇总成一张「候选 × 定性 × 去向」表。\n\n### 🚧 人类闸门（不可跳过）\n把评审表交给用户，**来回讨论收录决策**。精品 vs 边角的边界判断、是否返工、哪些合并成专题——都由人定。**未经用户确认，不得进入 ④。**\n\n### ④ 收录（按减熵分流规则）\n- **实质原创长文 / 论文 → `works/`**：`cp` 到 `works/-translation.md`，在 `articles.md` 加一个 `### N.` 编号条目（脉络一末尾，旧编号顺移），并**同步全部计数缓存**（见下）。\n- **边角材料**（产品页 / README / 发布稿 / 短 bliki）**→ articles.md「观察项 / 候选材料（不计入文章数）」表一行**，链上游 URL，不做编号条目（文章数不变）。\n- **工具类 → 只在用户实际用过后才进 `tools/`**；未实测前在观察项表标 🔵「待实测后入 tools/」。\n- **需返工的长文**：先润色（事实核查加译者注 / 术语统一）再进 `works/`。\n\n**入库前 checklist（每篇 works/ 候选必过，再进 ⑤）：**\n- [ ] frontmatter 声明 `sourceFigureCount` 并与原文实际图数核对（null = 原文不可得、未审计）；原文插图下载入 `works/imgs//` 本地嵌入——C10 校验嵌图数 ≥ 声明数、本地路径文件存在\n- [ ] **数图要抓原文 HTML 数，不能只看渲染出来的正文。** 2026-07-27 的教训：一篇 claude.com 译文声明 `sourceFigureCount: 0`，而原文 HTML 里有 4 个 `
`——抓取工具吐出的 markdown 把它们丢了，人只看那份 markdown 就会以为没有图。可用 `curl | grep -c '-translation.md`（works/ 是权威源）。\n- 删已收录 slug 的 `sources//` + `translations//`（过程稿，works/ 已留最终版）。\n- **保留**：观察项 slug 的全部译文（articles.md 标明「留作阅读辅助」）+ 状态 README。\n- 更新 `works-ready/README.md` 状态表。`translate/` 是 gitignored，清理仅本地。\n\n## 计数同步清单（④ 的硬要求）\n\n`references/articles.md` 是文章数与编号的**唯一权威源**。每加一个 `### N.` 条目，必须同次更新所有下游缓存，否则 `check-consistency.sh` 报错：\n- README.md / README.en.md：`articles-N` badge、`translations-N` badge、目录树、脉络表（脉络一计数）、翻译 `
` 摘要数、翻译表格行、Phase 5 提及\n- references/AGENTS.md：概览「N 篇文章」、脉络一小标题计数、文章表加行\n- prompts/deep-research-tracker.md：「核心文章 N 篇」、脉络一计数、去重清单加行\n- AGENTS.md：Phase 5 快照「N 篇翻译」\n- works/AGENTS.md：翻译表加行\n- articles.md 自身：header「N 篇（脉络一 …）」、两处「不计入 N 篇」\n- **观察项一行不触发以上**（不计入 N，无 `### N.` 编号）——这是减熵分流的关键收益。\n\n## 相关\n- 减熵分流约定：即上文「④ 收录」的分流规则——实质长文进 `works/` 编号正文；边角材料只进观察项表（不计数、不触发计数同步）；工具未实测不进 `tools/`。原则：每条新收录都要问\"它增加的检索价值是否大于它增加的维护熵\"\n- C8 lint：`source-full.md` 存在时禁止 analysis 谎报摘要页（`scripts/check-consistency.sh`）\n- C9 lint：`concepts/` / `thinking/` / `feedback/` 正文禁止裸写文库计数（历史提法须带\"写作时点/当时/此前/首批/首轮/截至/快照\"限定词）\n- C10/C11/C12 lint：图片保真（`sourceFigureCount` vs 正文嵌图数 + 本地嵌图路径存在）/ markdown 表格列数与表头一致 / articles.md 编号条目必含 **作者：**/**日期：** 字段（同上脚本）\n- C13 lint：`sourceFigureCount: 0` 必须配 `sourceFigureAudit`（含核对日期）。这条是补 C10 的结构性盲区——C10 的判据是\"嵌图数 < 声明数才 FAIL\"，所以 0 永远为真，无论你有没有真去数过原文。机械检查只能证伪\"多报\"，\"零报\"只能靠留痕让人复核\n- 历史首批实例：articles.md #19–27（2026-06 收录的 9 篇）+ 末尾观察项表 14 行\n","frontmatter":{"name":"curate-research","description":"把一批 Harness Engineering 调研候选（文章/论文/工具的 URL）走完「抓取→翻译→评审→收录→清理」流水线，整合进本仓库 works/ 与 references/articles.md，并保持 C1–C13 一致性检查全绿。当用户说\"处理这批调研候选 / 收录这些链接 / 整理 translate / 把这几篇翻译收进来\"时使用。这是仓库给自己用的策展 harness。"},"isInternal":false,"tokens":3010,"sizeBytes":8019},{"name":"articles.md","path":"references/articles.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/references/articles.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# 文章索引\n\n> **本文件是文章索引与计数的唯一权威源（single source of truth）。**\n>\n> **计数规则（machine-checkable）：**\n> 一篇文章 = 一个 `### N. {标题}` 形式的编号小节，且不属于本文末尾的\"已跟踪产品 / 项目\"段落。\n> 占位条目（\"未找到 / 待补充\"）**不写在编号正文里**，而是统一进 `references/AGENTS.md` 的\"待补充\"列表，避免污染计数。\n> 全局连续编号（不按脉络重置），最大编号 = 文章总数。\n>\n> **下游引用都是本文的冗余缓存：** 根 `README.md` / `README.en.md` 的 badge、`prompts/deep-research-tracker.md` 的去重清单、`references/AGENTS.md` 的概览表。\n> 新增/删除文章时，必须**同一次提交**更新本文 + 所有下游缓存。\n>\n> 当前规模：**79 篇文章**（脉络一 75 + 脉络二 2 + 脉络三 2）+ **1 项已跟踪产品**（不计入文章数）。最近一次同步：2026-08-27。\n\n## 脉络一：AI 时代的 Harness Engineering（大模型护栏与认知工程）\n\n\n\n### 1. OpenAI 官方 — 原点与哲学\n\n- **标题：** Harness engineering: leveraging Codex in an agent-first world\n- **链接：** [openai.com](https://openai.com/zh-Hans-CN/index/harness-engineering/)\n- **作者：** Ryan Lopopolo | **日期：** 2026-02-11\n- **核心：** 3 人团队用 Codex 从空仓库到 100 万行代码，零手写代码。提出六大概念：仓库即记录系统、地图而非手册、机械化执行、智能体可读性、吞吐量改变合并理念、熵管理。\n- **关联：** 本仓库的学习起点，所有概念笔记的来源\n\n\n\n### 2. Martin Fowler / Birgitta Böckeler — 系统性认知与控制论框架\n\n- **标题：** Harness engineering for coding agent users\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/harness-engineering.html)\n- **翻译：** [works/fowler-harness-engineering-full-translation.md](../works/fowler-harness-engineering-full-translation.md)\n- **前传备忘录：** [first thoughts](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html) | **备忘录翻译：** [works/fowler-harness-engineering-memo-translation.md](../works/fowler-harness-engineering-memo-translation.md)\n- **作者：** Birgitta Böckeler (Thoughtworks) | **日期：** 2026-04-02（备忘录 2026-02-17）\n- **核心：** 控制论视角的 harness 框架——Guides（前馈）× Sensors（反馈）+ Computational（计算性）× Inferential（推理性）的 2×2 矩阵，三个规制维度，Ashby 必要多样性定律\n\n- **核心框架：Guides × Sensors + Computational × Inferential**\n\n| | 计算性（确定性，CPU） | 推理性（语义，LLM） |\n|--|---------|---------|\n| **引导器（前馈）** | bootstrap 脚本、OpenRewrite、LSP | AGENTS.md、Skills、architecture.md |\n| **传感器（反馈）** | linter、ArchUnit、类型检查、覆盖率 | AI code review、LLM-as-judge |\n\n- **关键原则：**\n - 单独用任何一种都不行——只有反馈 = 反复犯同样的错；只有前馈 = 不知道规则是否生效\n - 计算性控制便宜、确定、每次提交都跑；推理性控制昂贵、概率性、不是每次都跑\n - Harness engineering 是 context engineering 的一种特定形式\n\n- **三个规制维度：**\n\n| 维度 | 成熟度 | 现状 |\n|------|--------|------|\n| 可维护性 Harness | 最成熟 | 计算性传感器可靠捕获结构问题；LLM 部分解决语义问题；**两者都无法可靠捕获**：误诊、过度工程、误解指令 |\n| 架构适应度 Harness | 中等 | 本质是 Fitness Functions——性能 Skills + 可观测性规范 |\n| 行为 Harness | **最弱** | \"房间里的大象\"——功能正确性验证仍依赖 AI 生成的测试，\"目前还不够好\" |\n\n- **Harnessability（可驾驭性）：**\n - 不是所有代码库都同样适合被 harness\n - 强类型语言天然有类型检查传感器；清晰模块边界支持架构约束；成熟框架（如 Spring）隐式提高成功概率\n - **Ambient Affordances**（Ned Letcher）：环境本身的结构属性使智能体更容易操作\n - 绿地项目可以从第一天融入；遗留系统 = **harness 最需要的地方恰恰是最难构建的地方**\n\n- **Harness 模板：**\n - 企业 80% 的服务可归入几种常见拓扑（API 服务、事件处理、数据仪表板）\n - 服务模板 → harness 模板：引导器 + 传感器的集合，约束智能体到特定拓扑\n - 会面临和服务模板一样的分叉/同步挑战，甚至更严重（非确定性组件更难测试）\n\n- **Ashby 必要多样性定律：**\n - 调节器必须至少拥有与被调节系统同等的多样性\n - LLM 能生成几乎任何东西（高多样性）→ 选定拓扑 = 削减多样性 → 全面 harness 变得可行\n - 定义拓扑结构本身就是一种多样性削减举措\n\n- **人类角色的重新定位：**\n - 人类开发者携带隐性 harness：社会问责感、对复杂性的审美痛感、组织记忆、\"我们这里不这么做\"的直觉\n - 智能体没有这些——不知道哪个规范是承重的、哪个只是习惯\n - **\"好的 harness 不应以完全消除人类输入为目标，而应将人类输入引导到最重要的地方\"**\n\n- **质量左移（Shift Quality Left）：**\n - 按速度和成本分布检查：pre-commit 跑便宜传感器，管线跑昂贵传感器\n - 持续漂移传感器：死代码检测、覆盖率质量、依赖扫描、SLO 退化\n\n- **开放挑战：**\n - Harness 连贯性：引导器和传感器增长后可能相互矛盾\n - Harness 覆盖率：类似代码覆盖率，评估 harness 自身的完整性\n - 传感器从未触发时，如何区分高质量 vs 检测不足\n\n- **备忘录独有洞察（正式版未保留）：**\n - \"OpenAI 有既得利益让我们相信 AI 可维护的代码\"——对数据来源的信任保留\n - \"你今天的 harness 是什么？\"——务实的起步问题，审视已有实践\n - \"代码设计本身就是上下文的重要组成部分\"——比框架更本质\n - 最后自嘲预言\"harness\"一词会被滥用\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Guides × Sensors 矩阵 | 对 LangChain 组件清单和 HumanLayer 六杠杆的升维——从\"有什么\"到\"如何协同\" |\n| 行为 Harness 是大象 | 回应自己备忘录中的批评：OpenAI 缺少功能验证 |\n| Harnessability | OpenAI 的\"无聊技术\"选择标准的理论化 |\n| Ashby 定律 | 为 Fowler 假说 2（约束越严，自主性越强）提供控制论根基 |\n| Harness 模板 | 将备忘录假说 1 从问题升级为具体方案 |\n| 人类角色 | 对 Anthropic #7 中人类缺位的直接回应——不应消除人类，应引导人类 |\n\n- **延伸阅读：**\n - [Mitchell Hashimoto: My AI Adoption Journey #Step 5: Engineer the Harness](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness)（已升格为 #29）\n - [Context Engineering for Coding Agents](https://martinfowler.com/articles/context-engineering-coding-agents.html)\n - [Humans and Agents in Software Engineering Loops](https://martinfowler.com/articles/humans-and-agents.html)\n\n\n\n### 3. LangChain / Viv Trivedy — 解剖与机制\n\n- **标题：** The Anatomy of an Agent Harness\n- **链接：** [blog.langchain.com](https://blog.langchain.com/the-anatomy-of-an-agent-harness/)\n- **作者：** Vivek Trivedy | **日期：** 2026-03\n- **核心：** 给出 harness 的精确定义和完整组件清单\n\n> **Agent = Model + Harness**。Harness = 模型之外的一切代码、配置和执行逻辑。\n\n- **组件清单：**\n - System Prompts / Tools / Skills / MCP\n - 沙箱基础设施（文件系统、浏览器）\n - 编排逻辑（子智能体、handoff、模型路由）\n - Hooks/中间件（compaction、续接、lint 检查）\n- **关键洞察：**\n - **Context Rot** — 上下文填满后性能退化，需要 compaction + 工具输出卸载 + 渐进式披露\n - **Ralph Loop** — 拦截退出、重注入提示词、强制在新上下文窗口中继续\n - **Harness 与模型训练耦合** — 模型会 overfit 到特定 harness，换 harness 表现可能暴跌（Terminal Bench 2.0：纯 harness 优化可把排名从 Top 30 拉到 Top 5）\n\n\n\n### 4. Anthropic / Prithvi Rajasekaran — Harness 设计实战（长时自主编码）\n\n- **标题：** Harness design for long-running application development\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/harness-design-long-running-apps)\n- **作者：** Prithvi Rajasekaran (Anthropic Labs) | **日期：** 2026-03-24\n- **核心：** Anthropic 官方工程博客，GAN 启发的三智能体架构实战，从前端设计到全栈自主编码\n\n- **两个核心问题：**\n 1. **Context Anxiety** — 模型接近上下文极限时提前收尾（Sonnet 4.5 尤为明显），compaction 不够，需要 context reset\n 2. **Self-Evaluation 失败** — 智能体评估自己的工作时倾向于过度称赞，即使质量平庸\n\n- **三智能体架构（GAN 启发）：**\n\n| 智能体 | 职责 |\n|--------|------|\n| Planner | 1-4 句提示词 → 完整产品规格（刻意高层级，避免细节错误向下游级联） |\n| Generator | 按 sprint 逐特性实现，React + Vite + FastAPI + SQLite/PostgreSQL |\n| Evaluator | 用 Playwright MCP 实际操作运行中的应用，逐条验证 sprint 合同，打分 + 写详细 critique |\n\n- **Sprint 合同机制：**\n - 每个 sprint 前，Generator 和 Evaluator **协商**\"done 长什么样\"\n - Generator 提议构建内容和验证标准，Evaluator 审核\n - 双方迭代达成一致后才开始编码\n - 解决了 spec 太高层级 → 实现不可验证的 gap\n\n- **评估标准（前端设计 4 维度）：**\n 1. Design Quality — 是否有连贯的视觉身份（权重高）\n 2. Originality — 是否有原创设计决策，而非 AI 模板（权重高）\n 3. Craft — 排版、间距、对比度等技术执行（默认就好）\n 4. Functionality — 可用性独立于美学（默认就好）\n\n- **迭代进化（模型升级后的 Harness 瘦身）：**\n\n| 版本 | 模型 | 架构 | 时长 | 成本 |\n|------|------|------|------|------|\n| Solo baseline | Opus 4.5 | 单智能体 | 20 min | $9 |\n| V1 Harness | Opus 4.5 | Planner + Generator(sprint) + Evaluator(per-sprint) | ~6 hr | $200 |\n| V2 Harness | Opus 4.6 | Planner + Generator(无 sprint) + Evaluator(单次 pass) | ~4 hr | $125 |\n\n- **关键经验：**\n - **每个 harness 组件都编码了一个假设**（\"模型不能独立做 X\"），这些假设需要定期重新压测\n - 新模型发布后应精简 harness：去掉不再承重的部分，添加新能力\n - Evaluator 的价值取决于任务是否处于模型能力边界：边界内 → 开销浪费；边界外 → 真正有帮助\n - \"有趣的 harness 组合空间不会随模型改进而缩小——它会移动\"\n\n- **与其他文章的关联：**\n\n| Anthropic 概念 | 对应文章 |\n|---------------|---------|\n| Context Anxiety + Reset | LangChain 的 Context Rot + Ralph Loop |\n| Self-Evaluation 失败 → 分离 Evaluator | HumanLayer 的 Sub-Agent 上下文防火墙 |\n| Sprint 合同 | OpenAI 的执行计划（exec-plans） |\n| 4 维度评分标准 | OpenAI 的 QUALITY_SCORE.md |\n| Harness 瘦身原则 | Fowler 的\"约束越严，自主性越强\" |\n| \"找最简方案，按需增加复杂度\" | HumanLayer 的\"简单开始，按需添加\" |\n\n\n\n### 5. HumanLayer / Kyle — 实践与避坑\n\n- **标题：** Skill Issue: Harness Engineering for Coding Agents\n- **链接：** [humanlayer.dev](https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents)\n- **作者：** Kyle（HumanLayer） | **日期：** 2026-03-12\n- **核心：** 最落地的一篇——六个配置杠杆 + 实战经验\n\n- **六个杠杆：**\n\n| # | 杠杆 | 要点 |\n|---|------|------|\n| 1 | AGENTS.md | 控制在 60 行以内，禁止自动生成 |\n| 2 | MCP Servers | 别连不信任的，工具太多会填满上下文 |\n| 3 | Skills | 渐进式加载，警惕恶意 skill |\n| 4 | Sub-Agents | 上下文防火墙，隔离任务防 context rot |\n| 5 | Hooks | 生命周期脚本，成功静默/失败报错 |\n| 6 | Back-Pressure | 测试/构建/类型检查 = 自我验证回路 |\n\n- **实战经验：**\n\n| 无效 | 有效 |\n|------|------|\n| 预设理想配置 | 简单开始，按需添加 |\n| 装一堆 skill/MCP \"以防万一\" | 团队间分发验证过的配置 |\n| 每次改动跑全量测试 | 优化迭代速度而非首次成功率 |\n| 微调子智能体的工具权限 | 便宜模型做子任务，贵模型做编排 |\n\n- **金句：** \"The model is probably fine. It's just a skill issue.\"\n\n\n\n### 6. Anthropic / Lance Martin — 三大模式与性能数据\n\n- **标题：** Harnessing Claude's intelligence\n- **链接：** [claude.com](https://claude.com/blog/harnessing-claudes-intelligence)\n- **作者：** Lance Martin (Claude Platform Team) | **日期：** 2026-04-02\n- **核心：** 三个构建模式——利用 Claude 已知知识、追问\"我可以停止做什么\"、谨慎设定边界。配合 BrowseComp / Pokemon 等基准数据论证\n\n- **三大模式：**\n\n| 模式 | 核心主张 |\n|------|---------|\n| Use what Claude knows | 通用工具（bash + editor）优于定制工具，随模型升级自然增强 |\n| Ask \"what can I stop doing?\" | 把编排、上下文管理、持久化三个决策权从 harness 交给模型 |\n| Set boundaries carefully | 缓存优化（静态前置）+ 声明式工具提供安全门控与可观测性 |\n\n- **\"停止做什么\"的三个层次：**\n\n| 层次 | 旧假设 | 新做法 | 数据支撑 |\n|------|--------|--------|---------|\n| 编排 | 所有工具结果回流上下文 | 给 Claude 代码执行工具，让它自己过滤/管道 | BrowseComp: Opus 4.6 过滤能力 45.3% → 61.6% |\n| 上下文管理 | 手工预加载任务指令 | Skills 渐进式披露 + context editing 移除过时内容 + 子 Agent 隔离 | BrowseComp: 子 Agent 提升 2.8% |\n| 持久化 | 依赖外部检索基础设施 | Compaction（模型自主总结）+ Memory folder（模型自主写文件） | BrowseComp: Opus 4.6 compaction 达 84%；BrowseComp-Plus: memory folder +6.8% |\n\n- **缓存优化五原则：**\n\n| 原则 | 说明 |\n|------|------|\n| 静态在前，动态在后 | 稳定内容（系统提示词、工具）放前面 |\n| 用消息传递更新 | 追加 `` 而非编辑提示词 |\n| 不切换模型 | 缓存是模型特定的，切换即失效；需要便宜模型用子 Agent |\n| 谨慎管理工具 | 工具在缓存前缀中，增删会使缓存失效；用 tool search 追加 |\n| 更新断点 | 多轮应用中将断点移至最新消息，使用自动缓存 |\n\n- **声明式工具的四个价值：**\n 1. 安全门控 — 不可逆操作（如外部 API）需用户确认\n 2. 过时检查 — 写入工具检测文件自上次读取后是否被修改\n 3. UX 渲染 — 模态窗口展示问题、提供选项、阻塞等待反馈\n 4. 可观测性 — 结构化参数可记录、追踪、重放\n\n- **Pokemon 记忆进化案例：**\n - Sonnet 3.5: 14,000 步后 31 个文件（含重复），仍在第二城镇，记忆 = NPC 对话转录\n - Opus 4.6: 同样步数 10 个文件（按目录组织），3 枚道馆徽章，记忆 = 战术笔记 + 失败经验\n\n- **\"上下文焦虑\"案例：**\n - Sonnet 4.5 接近上下文极限时提前收尾 → 加了 context reset 补偿\n - Opus 4.5 天然消除了此行为 → context reset 变成死重\n - 启示：harness 中的补偿机制会随模型进化变成性能瓶颈\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 通用工具 > 定制工具 | OpenAI 原文的 bash + editor 起源 |\n| Skills 渐进式披露 | LangChain 的 Progressive Disclosure、HumanLayer 的 Skills 杠杆 |\n| Compaction + Memory folder | LangChain 的 Context Rot 解法、Anthropic #4 的 Context Anxiety |\n| 声明式工具 vs bash | HumanLayer 的 Back-Pressure 杠杆 |\n| \"停止做什么\" | Anthropic #4 的 Harness 瘦身原则、Fowler 的假说 |\n| 缓存优化 | 本仓库新增维度——此前文章未深入讨论 API 层成本优化 |\n\n\n\n### 7. Anthropic / Lance Martin, Gabe Cemaj, Michael Cohen — Meta-Harness 与基础设施解耦\n\n- **标题：** Scaling Managed Agents: Decoupling the brain from the hands\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/managed-agents)\n- **作者：** Lance Martin, Gabe Cemaj, Michael Cohen | **日期：** 2026-02-04\n- **翻译：** [works/anthropic-managed-agents-translation.md](../works/anthropic-managed-agents-translation.md)\n- **核心：** 不再讨论\"如何设计 harness\"，而是追问\"如何让 harness 本身成为可替换的基础设施\"——提出 meta-harness 概念\n\n- **三个虚拟化组件（借鉴操作系统）：**\n\n| 组件 | 类比 | 接口 |\n|------|------|------|\n| Session | 文件系统 | `emitEvent(id, event)`, `getEvents()`, `getSession(id)` |\n| Harness | 进程 | `wake(sessionId)` — 无状态，可随时替换 |\n| Sandbox | I/O 设备 | `execute(name, input) → string`, `provision({resources})` |\n\n- **Pets vs Cattle 演进：**\n - 耦合设计：session + harness + sandbox 在同一容器 → 容器 = 宠物，故障即丢失\n - 解耦设计：三组件独立 → 全部是牲畜，可独立故障和替换\n\n- **安全边界（结构性隔离）：**\n - Git：访问令牌在沙箱初始化时注入 remote，智能体不触碰令牌\n - 自定义工具：OAuth 令牌在 vault 中，通过 MCP proxy 调用，harness 永不接触凭证\n - 核心原则：**令牌永远不可从沙箱内访问**\n\n- **Session 作为外部上下文存储：**\n - 上下文不再是 harness 内的不可逆决策（compaction/trimming）\n - Session 日志持久存储完整事件流，`getEvents()` 按需切片取回\n - 上下文转换（缓存优化、上下文工程）在 harness 层做，与存储层分离\n\n- **性能数据：**\n\n| 指标 | 改善 |\n|------|------|\n| p50 TTFT | ~60% 下降 |\n| p95 TTFT | >90% 下降 |\n\n- **多大脑、多双手：**\n - 多大脑：无状态 harness 按需启动，容器仅在工具调用时配置\n - 多双手：每双手 = `execute(name, input) → string`，harness 不关心手是容器、手机还是宝可梦模拟器\n - 大脑之间可以互相传递双手\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Harness 假设过时 | Anthropic #4 的 Harness 瘦身、#6 的\"停止做什么\" |\n| Pets vs Cattle | 经典 DevOps 概念，Harness.io 脉络的核心 |\n| Session 外部存储 | LangChain 的 Context Rot、Anthropic #6 的 Compaction |\n| Meta-harness | Fowler 的假说 1：\"Harness 将成为未来的服务模板\" |\n| 安全边界解耦 | HumanLayer 的 MCP 信任边界 |\n| 多大脑多双手 | OpenAI 原文的并发 + 吞吐量理念 |\n\n\n\n### 8. Fowler / Rahul Garg — 编码团队标准：缩减 AI 辅助开发的摩擦\n\n- **标题：** Encoding Team Standards\n- **系列：** Patterns for Reducing Friction in AI-Assisted Development\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html)\n- **翻译：** [works/fowler-encoding-team-standards-translation.md](../works/fowler-encoding-team-standards-translation.md)\n- **作者：** Rahul Garg (Thoughtworks) | **日期：** 2026-04-01\n- **核心：** 将团队隐性编码标准显式化为可机器执行的规范，从自然语言 → 示例 → 自动化检查三层渐进\n- **关键洞察：**\n - 团队标准分三类：语言/框架惯用法、项目特有约定、架构决策\n - 编码路径：口头约定 → AGENTS.md/prompts 中的自然语言描述 → 带示例的结构化指令 → lint 规则/自动化检查\n - 不是所有标准都值得完全自动化——按违反频率和影响决定投资\n- **与其他文章关联：** Fowler #2 的 Guides×Sensors 框架的实操手册；HumanLayer 的 AGENTS.md 杠杆的深化\n\n\n\n### 9. Fowler / Rahul Garg — 反馈飞轮：缩减 AI 辅助开发的摩擦\n\n- **标题：** Feedback Flywheel\n- **系列：** Patterns for Reducing Friction in AI-Assisted Development\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html)\n- **翻译：** [works/fowler-feedback-flywheel-translation.md](../works/fowler-feedback-flywheel-translation.md)\n- **作者：** Rahul Garg (Thoughtworks) | **日期：** 2026-04-01\n- **核心：** 构建从 AI 失败中持续学习的反馈闭环——观察失败 → 根因分析 → 编码修复 → 验证效果 → 迭代\n- **关键洞察：**\n - 反馈飞轮四步：发现模式 → 诊断根因 → 系统性修复（而非一次性补丁）→ 衡量改善\n - 与 Encoding Team Standards 形成闭环：标准编码 → 违反检测 → 反馈 → 标准演进\n - 团队级别的 harness 不是一次性设计，而是持续演进的活系统\n- **与其他文章关联：** Anthropic #4 的\"每个 harness 组件编码一个假设\"理念的运营化；YDD 的安灯绳验证闭环\n\n\n\n### 10. LangChain — 智能体评估就绪清单\n\n- **标题：** Agent Evaluation Readiness Checklist\n- **链接：** [blog.langchain.com](https://blog.langchain.com/agent-evaluation-readiness-checklist/)\n- **翻译：** [works/langchain-agent-evaluation-checklist-translation.md](../works/langchain-agent-evaluation-checklist-translation.md)\n- **作者：** LangChain 团队 | **日期：** 2026-04-08\n- **核心：** 从零到一构建智能体评估体系的分阶段清单——定义 → 数据集 → 评估器 → 实验 → 持续集成\n- **关键洞察：**\n - 评估五阶段：定义成功标准 → 构建评估数据集 → 选择评估器 → 运行实验 → CI 集成\n - 数据集构建方法论：从生产日志中提取真实案例，比合成数据更有价值\n - LLM-as-judge 的校准：需要人类标注作为锚点，定期重新校准\n - 评估不是一次性的，而是随智能体演进持续更新的\n- **与其他文章关联：** Fowler #2 的 Sensors 维度的系统化实操；Anthropic #4 的 Evaluator 角色的方法论基础\n\n\n\n### 11. Meta-Harness 论文 — 自动化 Harness 优化\n\n- **标题：** Meta-Harness: End-to-End Optimization of Model Harnesses\n- **链接：** [arxiv.org](https://arxiv.org/abs/2603.28052)\n- **翻译：** [works/meta-harness-paper-translation.md](../works/meta-harness-paper-translation.md)\n- **作者：** Yoonho Lee, Roshen Nair 等 (Stanford, KRAFTON, MIT) | **日期：** 2026-03-30\n- **核心：** 用编码智能体作为提议器，通过文件系统访问完整搜索历史（代码+轨迹+分数），自动搜索最优 Harness\n- **关键洞察：**\n - 外循环搜索：提议器检查先前 Harness 的源代码和执行轨迹，进行因果推理后提出改进\n - 文本分类任务上比 ACE 高 7.7pp，上下文 token 减少 4×\n - IMO 难度数学问题上，发现的检索 Harness 跨 5 个留出模型泛化，平均提升 4.7pp\n - TerminalBench-2 上超越手工工程化的 Terminus-KIRA\n - 核心发现：完整执行轨迹访问 > 压缩摘要 > 仅标量分数（消融实验）\n- **与其他文章关联：** Anthropic #7 的 meta-harness 概念的学术实现；Fowler #2 的 Sensors 的极致自动化——连 harness 本身的设计也变成可搜索的\n\n\n\n### 12. GitHub / Tyler McGoffin — 智能体驱动开发实战\n\n- **标题：** Agent-driven development in Copilot Applied Science\n- **链接：** [github.blog](https://github.blog/ai-and-ml/github-copilot/agent-driven-development-in-copilot-applied-science/)\n- **翻译：** [works/github-agent-driven-development-translation.md](../works/github-agent-driven-development-translation.md)\n- **作者：** Tyler McGoffin (GitHub Copilot Applied Science) | **日期：** 2026-03-31\n- **核心：** 用编码智能体构建智能体，自动化自身工作的实战叙述；Copilot SDK + MCP + Skills 的具体使用模式\n- **关键洞察：**\n - 智能体驱动开发的三阶段演进：手动 → 半自动 → 全自动\n - 关键经验：好的提示词比好的代码更重要；智能体需要明确的约束和验证循环\n - Copilot CLI 作为日常工具的实际工作流\n- **与其他文章关联：** OpenAI 原文的\"工程师不再写代码\"理念的一线实践验证\n\n\n\n### 13. Inside the Scaffold 论文 — 编码智能体脚手架的源代码级分类法\n\n- **标题：** Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures\n- **链接：** [arxiv.org](https://arxiv.org/html/2604.03515v1)\n- **翻译：** [works/inside-the-scaffold-paper-translation.md](../works/inside-the-scaffold-paper-translation.md)\n- **作者：** Benjamin Rombaut (Huawei Canada) | **日期：** 2026-04-04\n- **核心：** 对 13 个开源编码智能体的脚手架代码进行源代码级分析，提出 12 维度 × 3 层次的架构分类法\n- **关键洞察：**\n - 五种循环原语（ReAct、生成-测试-修复、计划-执行、多次重试、树搜索）是可组合的构建块，11/13 智能体组合多种原语\n - 维度在外部约束主导处收敛（工具类别、编辑格式、执行隔离），在开放设计问题处发散（上下文压缩、状态管理、多模型路由）\n - 工具数量从 0（Aider）到 37（Moatless Tools），但底层能力类别趋同：读取、搜索、编辑、执行\n - 上下文压缩涵盖七种策略：截断、摘要、滑动窗口、事件溯源、浓缩、选择性包含、无压缩\n- **与其他文章关联：** 为 Fowler #2 的 Guides×Sensors 框架提供了 13 个实际系统的实证数据；Meta-Harness 论文搜索空间的具体化——展示了 harness 设计选择的巨大多样性\n\n\n\n### 14. ⭐ Lalit Maganti — 渴望八年，用 AI 三个月造出来\n\n- **标题：** Eight years of wanting, three months of building with AI\n- **链接：** [lalitm.com](https://lalitm.com/post/building-syntaqlite-ai/)\n- **翻译：** [works/maganti-eight-years-building-ai-translation.md](../works/maganti-eight-years-building-ai-translation.md)\n- **作者：** Lalit Maganti | **日期：** 2026-04-05\n- **核心：** 资深工程师（Chrome/Android 性能团队）用 AI 编码智能体从零构建 syntaqlite（SQLite 开发工具）的完整复盘——250 小时，3 个月，坦诚记录 AI 的帮助与局限\n- **关键洞察：**\n - AI 是实现的力量倍增器，但不能替代设计——缺乏品味、历史感和用户直觉\n - 实际经验：AI 在 well-constrained 的任务上卓越（测试编写、重构、API 实现），在需要判断力的任务上失败（架构决策、API 设计、性能优化）\n - \"vibe coding\" 对严肃项目不可行——必须理解 AI 生成的每一行代码\n - 模型能力进化的真实感受：Claude 3.5 → Sonnet 4.5 → Gemini 2.5 Pro 的逐步改善\n - **与我们的实践高度一致**\n- **与其他文章关联：** YDD 的\"洗衣机悖论\"的一手证据——省出的时间投入到了更高层的设计工作中；Anthropic #4 的\"每个 harness 组件编码一个假设\"的个人体验版\n\n\n\n### 15. LangChain / Harrison Chase — 智能体的持续学习\n\n- **标题：** Continual learning for AI agents\n- **链接：** [blog.langchain.com](https://blog.langchain.com/continual-learning-for-ai-agents/)\n- **翻译：** [works/langchain-continual-learning-translation.md](../works/langchain-continual-learning-translation.md)\n- **作者：** Harrison Chase (LangChain CEO) | **日期：** 2026-04-05\n- **核心：** 智能体的学习发生在三个层次：模型权重、Harness、上下文——理解区别改变你构建持续改进系统的方式\n- **关键洞察：**\n - 三层学习：模型层（微调/RL）→ Harness 层（提示词/工具/编排逻辑演进）→ 上下文层（运行时记忆/少样本示例）\n - Harness 层学习最被低估：通过分析执行轨迹迭代改进 harness，而非仅改模型\n - 上下文层学习最灵活：用户级记忆、后台整合、跨会话学习\n - Deep Agents 框架支持生产级持续学习\n- **与其他文章关联：** Meta-Harness 论文的 harness 层自动化学习的框架化阐述；Fowler #9 反馈飞轮在智能体层面的体现\n\n\n\n### 16. OpenAI 官方 — 任务跟踪器作为控制平面（Symphony）\n\n- **标题：** An open-source spec for Codex orchestration: Symphony\n- **链接：** [openai.com](https://openai.com/index/open-source-codex-orchestration-symphony/)\n- **翻译：** [works/openai-codex-symphony-translation.md](../works/openai-codex-symphony-translation.md)\n- **作者：** Alex Kotliarskyi, Victor Zhu, Zach Brock | **日期：** 2026-04-27\n- **核心：** 把 Linear 这类问题跟踪器变成智能体编排的控制平面——每个打开的 ticket 映射一个智能体工作区，Symphony 保证未完成任务始终有智能体在跑。Symphony 本体只是一份 `SPEC.md`+`WORKFLOW.md`，参考实现用 Elixir，作者鼓励使用者把 spec 交给自己的编码智能体生成本地实现。\n- **关键洞察：**\n - **从交互式会话到 ticket 级编排**：人类瓶颈不在写代码，而在管理 3-5 个并发 Codex 会话的上下文切换；把 issue tracker 当状态机后，瓶颈转移到智能体的目标空间\n - **目标 vs 状态转换**：早期把智能体当状态机里的刚性节点不奏效；最终转向\"给目标 + 工具 + 上下文，让它自己推理\"\n - **代码免费 → 按语言优势选语言**：参考实现用 Elixir 是因为其并发能力强；同一份 SPEC.md 用 TS/Go/Rust/Java/Python 都能实现成功，多语言实现反过来打磨规范本身\n - **探索成本接近零**：PM/设计师可直接提交 ticket 拿到带演示视频的 review packet，扩大了\"谁能发起工程工作\"的边界\n - **数据点**：部分团队前三周已落地 PR 数量 +500%；发布后 4 月 23 日仓库 15K+ stars\n- **与其他文章关联：** OpenAI 原文 #1 的\"map not manual\"在 SPEC.md 模式下的极致——map 不仅给智能体看，也给社区使用者作为构建模板；HumanLayer #5 的\"AGENTS.md 杠杆\"在工作流层面的扩展（`WORKFLOW.md` 显式化原本隐式的人类流程）；与 thinking 洞见 7 的\"技术栈收敛\"形成反例\n- **实施参考：** [openai/symphony](https://github.com/openai/symphony) | [SPEC.md](https://github.com/openai/symphony/blob/main/SPEC.md)\n\n\n\n### 17. Vikash Rungta — Claude Code 架构（逆向工程版）\n\n- **标题：** Claude Code Architecture (Reverse Engineered)\n- **链接：** [vrungta.substack.com](https://vrungta.substack.com/p/claude-code-architecture-reverse)\n- **翻译：** [works/claude-code-architecture-reverse-translation.md](../works/claude-code-architecture-reverse-translation.md)\n- **作者：** Vikash Rungta | **日期：** 2025-11-01\n- **性质：** 外部逆向分析，非 Anthropic 官方架构文档\n- **核心：** 把 Claude Code 解释为模型无关的本地运行外壳：模型负责推理，外壳提供 shell、文件系统、工具原语、记忆、权限、hooks、MCP、skills、子智能体和智能体团队，把自主循环约束在可治理边界内。\n\n- **关键洞察：**\n - **从工作流到循环：** 从代码控制模型的 DAG，转向模型控制行动的 TAOR（Think-Act-Observe-Repeat）循环；运行时保持简单，智能尽量留给模型。\n - **原语工具胜过专用集成：** Bash、Grep、Edit、Read 这类通用能力原语，比大量脆弱的垂直插件更能覆盖真实工程工作流。\n - **上下文是一种稀缺资源：** 自动压缩、子智能体隔离、语义工具搜索和 forked context 都是在管理上下文预算，避免上下文坍缩。\n - **权限就是产品体验：** plan/default/acceptEdits/dontAsk/bypassPermissions 这类信任光谱，把安全、速度和企业采用门槛合在一起。\n - **Harness 应随模型变薄：** 模型能力提升后，硬编码脚手架应被删除或下沉为确定性 hook，而不是持续堆复杂度。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Claude Code 作为 Harness 的产品化样本 | #3 LangChain 的 Agent = Model + Harness 公式 |\n| 子智能体与智能体团队 | #13 Inside the Scaffold 的子智能体委托分类、#16 Symphony 的 ticket 级编排 |\n| hooks 作为确定性护栏 | #2 Fowler Guides×Sensors、#5 HumanLayer 六杠杆 |\n| 模型升级时删除代码 | #4 Anthropic Harness 瘦身、#6 Anthropic/Claude Platform 的\"停止做什么\" |\n| Claude Code 专有实现的外部观察 | 弥补 #13 因 Claude Code 非开源而无法纳入源代码分类法的空白 |\n\n> 注：Chachamaru127 / claude-code-harness 早期曾占据 #16 文章位，现已迁至本文末尾的\"已跟踪产品 / 项目\"段落（不计入文章数）。\n\n\n\n### 18. 马东锡 NLP — Harness 系列文章之 7：关于 subagent\n\n- **标题：** Harness 系列文章之 7：关于 subagent\n- **链接：** [x.com](https://x.com/dongxi_nlp/status/2068922428516892998)\n- **原文收录：** [works/dongxi-subagent-original.md](../works/dongxi-subagent-original.md)\n- **作者：** 马东锡 NLP (@dongxi_nlp) | **日期：** 2026-06-22\n- **核心：** 把 subagent 从\"小号智能体\"重新定义为 parent session 通过一次 tool call 拉起的 managed child runtime：外层是 `spawn_agent` / `/delegate` tool call，内层是新的 child session 和被选择过的 context projection。\n\n- **关键洞察：**\n - **Tool call outside, runtime inside：** subagent 的启动入口是 tool call；tool call 之后，Harness 的世界状态里多了一个 child runtime。\n - **Session ≠ Context：** session 是 runtime container，包含 thread、transcript、tools、permissions、resources、status、artifacts；context 是某次 model call 可见的 projection。\n - **Shared resources 不等于 shared transcript：** child 可以继承 tools、skills、AGENTS.md、MCP servers、cwd、sandbox、permissions，但不自动继承 parent 的完整对话历史。\n - **三种投影策略：** fresh child、forked child、partial fork 分别对应不同上下文继承强度；partial fork 是避免 parent history 噪声的实用中间态。\n - **更多 agents = 更多 runtime state：** 多智能体不是免费并行，Harness 必须追踪谁在工作、知道什么、改了什么、何时完成，以及结果如何变成 evidence。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| child session 与 context projection | #7 Anthropic Managed Agents 的 Session/Harness/Sandbox 解耦 |\n| subagent 作为上下文隔离机制 | #17 Claude Code 架构逆向中的隔离 TAOR 循环与 summary return |\n| fresh/forked/partial fork | #6 Anthropic/Claude Platform 的 context editing、sub-agent 隔离与缓存前缀管理 |\n| evidence 回流与 runtime state | #16 OpenAI Symphony 的任务跟踪器控制平面、#13 Inside the Scaffold 的委托分类 |\n\n- **本仓库笔记：** [thinking/subagent-is-child-runtime.md](../thinking/subagent-is-child-runtime.md)\n\n---\n\n\n\n### 19. Fowler / Birgitta Böckeler — 面向编码智能体的可维护性传感器\n\n- **标题：** Maintainability sensors for coding agents\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/sensors-for-coding-agents.html)\n- **中文译文：** [works/fowler-sensors-translation.md](../works/fowler-sensors-translation.md)\n- **作者：** Birgitta Böckeler | **日期：** 2026-05-20\n- **核心：** Böckeler 从一个真实 TypeScript/NextJS 应用出发，系统梳理\"计算性 vs 推理性\"传感器谱系（type checker、ESLint、Semgrep、dependency-cruiser、mutation testing、耦合分析、AI 模块化评审），并诚实记录失败案例（耦合数据对 AI\"乏善可陈\"、把合理的 DI factory 误判为 god module）。\n\n- **关键洞察：**\n - **传感器 = 反馈控制隐喻：** lint message 写成\"自我修正指导\"（prompt injection 式提示），让 agent 读到反馈即自纠。\n - **计算性 vs 推理性：** 确定性检查（type/lint/依赖图）与需要判断的检查（模块化、耦合）是两类不同传感器，可靠度与误报率不同。\n - **AI 模块化评审 = 垃圾回收：** 作者明确把它称为 garbage collection——周期性识别并清理结构腐化。\n - **诚实的负面结果：** 不是所有传感器都有用，耦合指标对 AI 收效甚微，记录失败本身是这篇的价值。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Guides × Sensors 框架的实操续篇 | #2 Fowler 的控制论矩阵 |\n| 机械化执行（custom linter > 文档） | 概念 3 机械化执行 |\n| AI 评审作为垃圾回收 | 概念 6 熵与垃圾回收 |\n\n- **本仓库笔记：** [thinking/guides-sensors-meets-claude-code-harness.md](../thinking/guides-sensors-meets-claude-code-harness.md)\n\n---\n\n\n\n### 20. Fowler / Wei Zhang, Jessie Jie Xia — 结构化提示驱动开发（SPDD）\n\n- **标题：** Structured-Prompt-Driven Development (SPDD)\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/structured-prompt-driven/)\n- **中文译文：** [works/fowler-spdd-translation.md](../works/fowler-spdd-translation.md)\n- **作者：** Wei Zhang, Jessie Jie Xia（Martin Fowler 编辑） | **日期：** 2026-04-28\n- **核心：** 一套把提示词当一等版本化交付物的半自动 Harness：提出 REASONS Canvas 七维结构（R/E/A/S/O/N/S），主张\"先修提示词再改代码、重构则反向同步 spdd-sync\"的双向闭环。文末附 13 组高质量自问自答。\n\n- **关键洞察：**\n - **Prompt 是合同，Plan 是建议：** 把结构化提示词版本化、可审查，作为变更的承重结构。\n - **双向闭环：** 现实偏离 spec 时先改 prompt 再改代码；人工重构后用 spdd-sync 反向同步回 prompt，防止提示词漂移。\n - **SPDD 本身就是一个 Harness：** 把上下文、约束、审查、同步全部显式化。\n - **诚实承认边界：** \"人类判断仍然是承重结构\"，模型无关、不替代审查。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Prompt 即一等可版本化交付物 | #16 OpenAI Symphony 的约束即产品、延伸概念 07-spec-as-product |\n| REASONS Canvas 七维结构 | 概念 2 地图而非手册 + 渐进式披露 |\n| spdd-sync 反向同步防漂移 | 概念 3 机械化执行、#9 反馈飞轮 |\n\n---\n\n\n\n### 21. LangChain / Harrison Chase — 智能体开发生命周期（ADLC）\n\n- **标题：** The Agent Development Lifecycle (ADLC)\n- **链接：** [langchain.com](https://www.langchain.com/blog/the-agent-development-lifecycle)\n- **中文译文：** [works/langchain-adlc-translation.md](../works/langchain-adlc-translation.md)\n- **作者：** Harrison Chase | **日期：** 2026-05-09\n- **核心：** 提出 Build → Test → Deploy → Monitor + Iterate + Govern 的完整智能体开发生命周期，把 framework / runtime / harness 三层做了清晰区分，治理段拆出 cost / tool access / discoverability。是方法论级别的总览型骨架文。\n\n- **关键洞察：**\n - **framework / runtime / harness 三分类：** 与本仓库主题命名正面对齐——harness 是约束与反馈层，runtime 是执行容器，framework 是编排库。\n - **生命周期是闭环：** Monitor 产出的轨迹回流到 Iterate，把一次性 demo 变成可重复、可评测、可运营的工程。\n - **Govern 作为一等维度：** 成本、工具访问、可发现性被显式纳入治理。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| framework/runtime/harness 三层 | #6 Anthropic 三大模式、#17 Claude Code 架构逆向 |\n| Monitor → Iterate 反馈回路 | #2 Fowler Sensors、概念 3 机械化执行 |\n| Govern / 治理维度 | 概念 6 熵与垃圾回收 |\n\n---\n\n\n\n### 22. LangChain / Hunter Lovell — Deep Agents 中的解释器\n\n- **标题：** Interpreters in Deep Agents: Code Between Tool Calls and Sandboxes\n- **链接：** [langchain.com](https://www.langchain.com/blog/give-your-agents-an-interpreter)\n- **中文译文：** [works/deep-agents-interpreter-translation.md](../works/deep-agents-interpreter-translation.md)\n- **作者：** Hunter Lovell | **日期：** 2026-05-20\n- **核心：** 提出 interpreter 是介于串行工具调用与完整沙箱之间的\"第三层\"，interpreter state 是继 message history、filesystem 之后的\"第三类上下文表面\"。给出 35% token 节省实测，以及 QuickJS / 桥接 / 运行时控制的实现细节。\n\n- **关键洞察：**\n - **上下文表面分层：** message history / filesystem / interpreter state 是三类不同的 context surface，各自有不同的读写与投影方式。\n - **设计上更受限是主动选择：** interpreter 主动收窄能力（而非能力不足），用受限运行时换取可控与可读。\n - **35% token 节省：** 让智能体写代码协调工具、保存中间态，只把相关结果送入模型上下文。\n - **横向连接：** 呼应 Cloudflare Code Mode、Anthropic PTC、RLM。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 受限运行时即机械约束 | 概念 3 机械化执行、概念 4 智能体可读性 |\n| 上下文表面 / context surface 分层 | #6 Anthropic context editing、#18 subagent 的 context projection |\n| 用代码协调工具以省上下文 | #16 OpenAI Symphony 控制平面 |\n\n---\n\n\n\n### 23. Anthropic / 工程团队 — Claude Code 质量回归复盘\n\n- **标题：** An update on recent Claude Code quality reports\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/april-23-postmortem)\n- **中文译文：** [works/anthropic-postmortem-translation.md](../works/anthropic-postmortem-translation.md)\n- **作者：** Anthropic 工程团队 | **日期：** 2026-04-23\n- **核心：** 对三起独立的 Claude Code 质量回归逐项复盘——(1) 默认 reasoning effort 从 high 降到 medium 的产品取舍；(2) clear_thinking 缓存优化 bug（本应只清一次却每轮都清，导致\"健忘/重复/乱用工具\"并拖垮缓存命中）；(3) 一条 system prompt 限长指令（≤25/≤100 词）压垮编码智能。三个变更各打不同流量切片、不同时间表，叠加成\"广泛而不一致的退化\"。是仓库稀缺的第一手失败案例。\n\n- **关键洞察：**\n - **变更评估的经典陷阱：** 三个变更各自通过人审 + 自动审 + 单测 + e2e + dogfooding，仍全部漏网。\n - **system prompt 即受控产物：** 一条限长指令就能压垮编码智能，提示词必须纳入评测与审计。\n - **现成的治理清单：** 文末\"后续计划\"（per-model eval 套件、消融、soak period、渐进发布、prompt 审计工具）几乎是一份 harness 变更治理清单。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 机械化执行的盲区（多层审查仍漏网） | 概念 3 机械化执行、#2 Fowler Sensors |\n| system prompt 即受控产物 | 延伸概念 07-spec-as-product、#16 Symphony |\n| 反例 / 事故复盘（稀缺类型） | 仓库 works/ 多为正面理论，本篇为第一手反面教材 |\n\n---\n\n\n\n### 24. 林家航 等 / 复旦·北大·奇绩智锋 — Agentic Harness Engineering（论文）\n\n- **标题：** Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses\n- **链接：** [arxiv.org/html/2604.25850v4](https://arxiv.org/html/2604.25850v4)\n- **中文译文：** [works/arxiv-agentic-harness-engineering-translation.md](../works/arxiv-agentic-harness-engineering-translation.md)\n- **作者：** Jiahang Lin, Shichun Liu, Chengjun Pan 等（复旦 / 北大 / 奇绩智锋） | **日期：** 2026-05-18 | **arXiv：** 2604.25850 v4\n- **核心：** 提出 AHE 闭环——在固定基础模型下，通过组件、经验、决策三类可观测性让 Harness 自动演化：可编辑组件文件化，轨迹压缩为可下钻证据，每次编辑附带可证伪预测。Terminal-Bench 2 上 pass@1 从 69.7% 提升到 77.0%，超过 Codex-CLI，并在 SWE-bench-verified 与跨模型迁移中保持收益。\n\n- **关键洞察：**\n - **每次 Harness 编辑 = 可证伪契约：** 把 harness 优化从经验调参变成可验证的研究问题。\n - **三类可观测性：** 组件 / 经验 / 决策，构成分层可下钻的证据语料库。\n - **诚实报告局限：** 回归失明、组件非加性交互——优化并非单调可加。\n - **直接引用仓库源头：** 参考文献含 OpenAI Harness Engineering、Anthropic harness design、LangChain deep agents。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Harness 自动演化 / meta-harness | #11 Meta-Harness 论文、#7 Anthropic Meta-Harness |\n| 可观测性驱动的闭环 | #2 Fowler Sensors、概念 3 机械化执行 |\n| 编码智能体脚手架分类 | #13 Inside the Scaffold 论文 |\n\n---\n\n\n\n### 25. Yubin Qu 等 — 过度积极的编码智能体（论文）\n\n- **标题：** Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks\n- **链接：** [arxiv.org/html/2605.18583v1](https://arxiv.org/html/2605.18583v1)\n- **中文译文：** [works/arxiv-overeager-coding-agents-translation.md](../works/arxiv-overeager-coding-agents-translation.md)\n- **作者：** Yubin Qu, Ying Zhang, Yanjun Zhang, Gelei Deng, Yuekang Li, Leo Yu Zhang, Yi Liu | **日期：** 2026-05-18 | **arXiv：** 2605.18583 v1\n- **核心：** 定义并测量编码智能体在良性任务中的 overeager actions（完成表面任务却执行用户未授权的读写）。提出 OverEager-Gen/Bench（500 场景、约 7500 次运行、4 个 agent 产品 × 6 模型），用行为梯度验证器与双通道审计栈评估越界率。\n\n- **关键洞察：**\n - **反直觉发现：** 在提示里写明授权范围，会让 agent 从\"推断边界\"退化为\"匹配声明文本\"——Claude Code 去掉 consent 声明后越界率 0.0% → 17.1%。\n - **框架层主导：** permission gating 由框架层决定，模型层对齐不会完整传导到行为。\n - **授权问题是独立类别：** 区别于能力失败、提示注入、沙箱逃逸，是单独的一类风险。\n - **实证支撑机械约束：** 证明约束必须机械强制，靠提示声明反而降低边界推断。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 权限门控 / 边界约束 | #7 Anthropic Managed Agents 沙箱、概念 3 机械化执行 |\n| 提示声明反而降低安全 | #23 Anthropic 复盘的 system prompt 陷阱 |\n| agent 越界的实证测量 | 概念 6 熵与垃圾回收 |\n\n---\n\n\n\n### 26. Chris Parsons — 我是如何用 AI 写代码的\n\n- **标题：** How I Use AI to Code\n- **链接：** [chrismdp.com](https://chrismdp.com/coding-with-ai/)\n- **中文译文：** [works/chris-ai-code-translation.md](../works/chris-ai-code-translation.md)\n- **作者：** Chris Parsons | **日期：** 2026-05（更新版）\n- **核心：** 资深从业者的一手实践复盘。硬区分 Vibe Coding 与\"智能体化工程\"，提出\"从批准者到训练者\"的角色转变，归纳四要素 Harness（常驻指令 / skill files / 验证循环 / 反馈循环），并主张\"spec the problem, not the solution\"。带 7 条带注解脚注（a16z、Karpathy、METR/MIT、Greenblatt serial speed-up 等）。\n\n- **关键洞察：**\n - **Vibe Coding ≠ 智能体化工程：** 前者不真正检查结果，后者是\"有分寸地判断哪些 diff 需要你的眼睛\"。\n - **从批准者到训练者：** 资深工程师的工作不再是审查输出，而是训练 AI——把判断花在哪里本身是资深技能。\n - **四要素 Harness：** 常驻指令、skill files、验证循环、反馈循环；没有反馈循环脚手架会腐化。\n - **反馈是新瓶颈：** 编码本身更快了，但审查/验证/集成/返工变慢，慢工作吞没快工作。\n - **译者注：** 文中 2026 数据/产品断言来自原文及脚注，译者未独立核实（见译文顶部说明）。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 四要素 Harness | #2 Fowler、#5 HumanLayer 六杠杆、概念 2/3（地图而非手册 / 机械化执行） |\n| 反馈循环防腐化 | #9 Fowler 反馈飞轮、#19 Fowler Sensors |\n| 反馈瓶颈 / serial speed-up | #78 YDD 效率悖论 |\n\n---\n\n\n\n### 27. LangChain / Palash Shah — 我们如何构建 LangSmith Engine\n\n- **标题：** How we built LangSmith Engine: our agent for improving agents\n- **链接：** [langchain.com](https://www.langchain.com/blog/how-we-built-langsmith-engine-our-agent-for-improving-agents)\n- **中文译文：** [works/langsmith-engine-translation.md](../works/langsmith-engine-translation.md)\n- **作者：** Palash Shah | **日期：** 2026-05-19\n- **核心：** \"用智能体改进智能体\"的工程复盘。把 trace 压缩成轨迹骨架，用 screener（Haiku 子智能体）/ investigator 两阶段分工，CLI 作为统一接口，构成 issue → evaluator → 回归样本的闭环；issue 创建与 fix 生成分离。\n\n- **关键洞察：**\n - **trace → 轨迹骨架：** 压缩运行轨迹再交给智能体，是\"运行时 → 可观测 → 自动改进\"链条的关键一步。\n - **两阶段分工：** screener 先筛、investigator 再深挖，控制成本与上下文。\n - **闭环：** issue → evaluator → regression example，把一次性诊断变成可回归的适应度函数。\n - **创建与修复分离：** issue 创建和 fix 生成解耦，连接 repo 做 code-aware fix。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 用智能体改进智能体 / meta-harness | #7 Anthropic Meta-Harness、#24 Agentic Harness Engineering |\n| evaluator 作为适应度函数 | #10 LangChain 评估清单、#2 Fowler Sensors |\n| 运行时 → 可观测 → 改进链条 | #21 ADLC、#22 Deep Agents 解释器 |\n\n---\n\n\n\n### 28. Geoffrey Huntley — Ralph：最小可行 Harness 的原始出处\n\n- **标题：** Ralph Wiggum as a \"software engineer\"（2025-07）+ 续篇 everything is a ralph loop（2026-01-17）\n- **链接：** [ghuntley.com/ralph](https://ghuntley.com/ralph/) | [ghuntley.com/loop](https://ghuntley.com/loop/)\n- **作者：** Geoffrey Huntley | **日期：** 2025-07 / 2026-01-17\n- **核心：** Ralph 技术的方法论源头——\"Ralph 在最纯粹的形式下就是一个 bash 循环\"：`while true` 把 PROMPT.md 喂给编码智能体，每轮全新上下文窗口、一轮只做一件事，配背压验证。作者用它从零构建 CURSED 编程语言（训练集中不存在的语言）。本仓库 `practice/` 的 Ralph Demo 与已跟踪的 3 个 Ralph 项目此前一直缺这篇源头文献。\n\n- **关键洞察：**\n - **每轮只做一件事 + 信任模型选事：** 违反直觉的组合——既收窄单轮范围，又把\"什么最重要\"的决策权交给模型\n - **fix_plan.md 是外置状态：** TODO 列表是人类\"像鹰一样盯着\"的对象，构建 CURSED 期间被扔掉重生成多次——计划是耗材\n - **背压（backpressure）：** 改动后只跑该单元的测试；Rust 类型系统虽强但编译慢——\"轮速与正确性轴的平衡\"决定语言选择\n - **单体 vs 多智能体：** \"非确定性的微服务（智能体）= 一团红热的烂摊子\"；Ralph 是单体，单进程垂直扩展、单仓库自治\n - **失败域→工程化修复：** \"看到失败域，戴上工程师帽子把问题解决到永不再犯\"——与 Hashimoto 的 harness engineering 定义同源\n - **续篇的推广：** \"一切皆 ralph loop\"——loop 是通用的上下文工程模式，可用于所有任务；软件是陶轮上的黏土，不对就扔回轮上重塑\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| bash 循环 + 干净上下文 | #3 LangChain 的 Ralph Loop 组件、practice/ Ralph Demo |\n| 背压验证门 | 概念 3 机械化执行、#5 HumanLayer 的 Back-Pressure 杠杆 |\n| 计划是耗材 | README 的 Ralph 六信条 \"The Plan Is Disposable\" |\n| 单体反多智能体论 | #36 dynamic workflows（对照：模型自己写多智能体编排）、#16 Symphony |\n| 观察循环、调音式修复 | #29 Hashimoto 的 harness engineering 定义 |\n\n---\n\n\n\n### 29. Mitchell Hashimoto — 我的 AI 采纳之旅（\"harness engineering\" 命名出处）\n\n- **标题：** My AI Adoption Journey\n- **链接：** [mitchellh.com](https://mitchellh.com/writing/my-ai-adoption-journey)\n- **作者：** Mitchell Hashimoto（HashiCorp 联合创始人，Ghostty 作者） | **日期：** 2026-02-05\n- **核心：** 六步渐进采纳路线：放弃聊天机器人 → 复现自己的工作（手工做一遍再逼智能体做出同质结果）→ 日终智能体 → 外包稳赢任务 → 工程化 harness → 始终有智能体在跑。第 5 步给出了被业界广泛引用的 harness engineering 定义。多方学科史梳理公认本文是该术语的叫响者（与 OpenAI 原文同月）。原为本仓库\"延伸阅读\"，现升格为编号条目。\n\n- **关键洞察：**\n - **定义原文：** \"每当发现智能体犯错，就花时间工程化一个解决方案，使它永远不会再犯这个错误\"——两种形式：隐式提示（AGENTS.md）+ 程序化工具（截图脚本、过滤测试跑器）\n - **Ghostty 的 AGENTS.md 每一行都对应一次真实的坏行为**——与 Osmani \"每行可溯源到一次翻车\"的纪律互证\n - **复现自己的工作：** 刻意做两遍（先手工后智能体）是形成\"什么任务能交给智能体\"直觉的最快途径；效率增益的一半来自知道何时不用智能体\n - **人控制打断时机：** 关掉智能体桌面通知，\"由我决定何时打断它，而不是反过来\"——上下文切换是最贵的成本\n - **克制的自主性：** 一次只跑一个智能体、后台智能体覆盖 10–20% 工作时段；反对为跑而跑——\"只在真正有帮助的任务上跑\"\n - **对冲技能退化：** 委托智能体的同时手工做自己热爱的任务，抵消 Anthropic 技能形成论文指出的风险\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness engineering 定义 | #1 OpenAI 原文（同期独立提出）、#2 Böckeler（引用本文） |\n| 错误工程化=永不再犯 | #9 反馈飞轮的个人版、#28 Ralph 的调音式修复 |\n| AGENTS.md 行行有出处 | #31 Osmani 的约束加减法纪律、#5 HumanLayer 60 行规则 |\n| 何时不用智能体 | #14 Maganti 的能力边界经验、#26 Chris Parsons |\n\n---\n\n\n\n### 30. Claude Code 源码泄漏事件 — 512K 行 harness 的实锤解剖\n\n- **标题：** 事件 + 聚合分析：understanding-claude-code（综合 26 篇文章、7 个 HN 帖、10 份官方 TechDocs）\n- **链接：** [pankaj28843/understanding-claude-code](https://github.com/pankaj28843/understanding-claude-code) | 新闻报道：[InfoQ](https://www.infoq.com/news/2026/04/claude-code-source-leak/)\n- **作者：** 事件（当事人 Chaofan Shou，安全研究员；社区镜像扩散，无单一作者——本条为事件型收录） | **日期：** 2026-03-31（事件日）\n- **事件：** 2026-03-31，`@anthropic-ai/claude-code` v2.1.88 npm 包漏发 59.8MB 的 `cli.js.map`（缺一条 `.npmignore`，叠加 Bun 默认生成 source map 的已知 bug），~512,000 行 TypeScript / ~1,900 文件全裸；安全研究员 Chaofan Shou 发现，数小时内 GitHub 镜像扩散\n- **核心：** 业界第一次看到一线编码智能体 harness 的完整生产级源码。此前 #17（Rungta 逆向）只能从行为推测，泄漏把推测变成了可对照的实锤。\n\n- **实锤细节（此前只能猜测的部分）：**\n - **QueryEngine ~46K 行**：流式响应、工具调用循环、重试、token 追踪；工具可在模型还在流式输出时就开始执行\n - **60+ 权限门控工具（~29K 行 Tool.ts）**：遵循 Ousterhout \"deep modules\" 原则——简单接口藏重能力；\"Anthropic 花在优化工具上的时间超过优化总 prompt\"；工具描述本身是微型提示词\n - **工具结果预算**：BashTool 30K 字符、GrepTool 20K 字符，超额落盘到 `tool-results/{uuid}/` 留预览——上下文管理的机械化实现\n - **14 种缓存破坏向量追踪**（`promptCacheBreakDetection.ts`）：工具表变更、权限模式切换、CLAUDE.md 修改、MCP 连接等——#6 缓存优化五原则的工程落地\n - **未发布功能**：KAIROS 常驻后台 daemon（追加式日报）+ AutoDream 睡眠期记忆整理（727 行，闲时修剪/合并/组织会话记忆）+ Undercover Mode（对外仓库自动抹除内部信息与 AI 署名）\n - **教训**：source map 是被忽视的安全面——`npm pack --dry-run` 应进发布流水线\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 推测 vs 实锤对照 | #17 Rungta 逆向分析（TAOR 循环、权限光谱的推断如今可验证） |\n| 补上闭源样本的空白 | #13 Inside the Scaffold（当时因 Claude Code 闭源无法纳入分类法） |\n| 工具>prompt 的投资优先级 | #6 Anthropic 通用工具主张、概念 4 智能体可读性 |\n| 记忆整理（AutoDream） | #6 Pokemon 记忆进化案例的机制揭底 |\n| 发布流水线事故 | #23 质量回归复盘（同为 Anthropic 工程失误的第一手材料） |\n\n---\n\n\n\n### 31. Addy Osmani — Agent Harness Engineering（学科汇流综合）\n\n- **标题：** Agent Harness Engineering\n- **链接：** [addyosmani.com](https://addyosmani.com/blog/agent-harness-engineering/)（[O'Reilly Radar 2026-05-15 授权转载](https://www.oreilly.com/radar/agent-harness-engineering/)）\n- **第三方中译：** [掘金译文](https://juejin.cn/post/7642753947455356968)（未落盘本仓库）\n- **作者：** Addy Osmani（Google Cloud AI Director） | **日期：** 2026-04-19\n- **性质与破例说明：** 综述性质（同类的 Pachaar 综述归在\"中文转译/二手资料\"段不计数）。破例进编号正文的理由：它不只转述——给出了约束加减法纪律、hooks 分界论等可引用的原创表述，且是\"四学派汇流成一个学科\"的定调文（收藏/点赞比 2:1，读者当文档存）。\n- **核心：** \"编码智能体 = 模型 + 你围绕它构建的一切。Harness engineering 把这套脚手架当真正的工程产物；每当智能体失手，harness 就再收紧一圈。\"把 Trivedy（术语）、Horthy（追踪）、HumanLayer（skill issue）、Anthropic（长时设计）、Böckeler（用户侧）、Hashimoto（命名）缝成一张学科地图。\n\n- **关键洞察：**\n - **失败是可读的（legible）：** 不知道约定→加进 AGENTS.md；跑了破坏性命令→加 hook 拦截；40 步任务迷路→拆 planner/executor；反复\"完成\"坏代码→接 typecheck 背压\n - **约束的加减法纪律：** 只在见过真实失败后加约束，只在模型能力使其冗余后删；\"好的 AGENTS.md 每一行都应能溯源到一次具体翻车\"\n - **hooks 是分界线：** \"我告诉过智能体做 X\" vs \"系统强制执行 X\"——lifecycle 脚本承载永不能忘的事（typecheck/lint/测试、拦 `rm -rf` / force push、PR 前审批、写后自动格式化）\n - **模型与 harness 后训练耦合：** Opus 4.6 在 Claude Code 里的 Terminal Bench 2.0 分数远低于同模型在定制 harness 里；Viv 团队只改 harness 就 Top 30 → Top 5（#35 论文给出了这一现象的统计版本）\n - **HaaS（Harness-as-a-Service）：** 从构建于 LLM API（给 completion）转向构建于 harness API（给 runtime）——Claude Agent SDK / Codex SDK / OpenAI Agents SDK 同向\n - **Ralph Loop 的价值重申：** \"hook 拦截退出、往新上下文窗口重注提示词\"是从\"用更聪明的模型\"永远推导不出来的原语\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 六人六视角的汇流地图 | #3 Trivedy、#5 HumanLayer、#4 Anthropic、#2 Böckeler、#29 Hashimoto |\n| 约束加减法纪律 | #4 harness 瘦身、#29 AGENTS.md 行行有出处 |\n| Terminal Bench harness 效应 | #35 统计归因论文、#3 的原始数据点 |\n| HaaS | #7 Managed Agents、#21 ADLC 的 framework/runtime/harness 三分 |\n| 四学派汇流 | thinking/cross-article-insights 的学派划分 |\n\n---\n\n\n\n### 32. Thoughtworks / Böckeler & Ford — 传感器实验：有无反馈回路的对照\n\n- **标题：** Harness engineering and agent feedback: Exploring AI coding sensors\n- **链接：** [thoughtworks.com](https://www.thoughtworks.com/en-au/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors)\n- **作者：** Birgitta Böckeler, Chris Ford (Thoughtworks) | **日期：** 2026-05-13\n- **核心：** #19（可维护性传感器谱系）的实验化姊妹篇。在一个 TypeScript 数据仪表板上做**有/无传感器套件的对照实验**（ESLint、Semgrep 静态分析 + Dependency Cruiser 模块边界 + 覆盖率报告 + mutation testing），配套视频演示。\n\n- **关键洞察：**\n - **实验结果：** 配备质量反馈传感器的编码智能体能随时间持续改善质量（如提升测试覆盖率）；无传感器则原地踏步\n - **行业失衡诊断：** 2026 上半年业界注意力集中在 skills（前馈），sensors（反馈）被系统性低估——\"完美世界只需前馈；我们不住在那个世界里\"\n - **从叮嘱到保证：** \"反复求智能体写测试并祈祷它够自觉\" → 确定性约束给出保证；LLM 判断适合模糊探索区，客观一致的要求要交给形式化确定性工具\n - **态势感知而非全自动：** \"harness engineering 不是全自动化，而是开发者的态势感知\"——红绿传感器仪表板 = 代码库体检单，指示该把精力再投资到 harness 的哪里\n - **Harness 模板展望：** 未来不再每个项目从头搭 harness，而是按应用类型取用预配置模板（数据仪表板模板、CRUD 业务服务模板）——#2 的 harness 模板假说落到具体形态\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 传感器对照实验 | #19 传感器谱系（同作者的实操续篇） |\n| 前馈/反馈失衡 | #2 Guides×Sensors 框架、#5 六杠杆 |\n| 确定性约束 > 反复叮嘱 | 概念 3 机械化执行、#25 Overeager（提示声明反而降低边界推断） |\n| harness 模板 | #2 的假说 1、#21 ADLC |\n\n---\n\n\n\n### 33. HarnessAudit 论文 — Harness 安全审计（安全面的开辟）\n\n- **标题：** Auditing Agent Harness Safety\n- **链接：** [arxiv.org/abs/2605.14271](https://arxiv.org/abs/2605.14271)\n- **作者：** Chengzhi Liu, Yichen Guo, Yepeng Liu, Yuzhe Yang, Qianqi Yan, Xuandong Zhao, Wenyue Hua, Sheng Liu, Sharon Li, Yuheng Bu, Xin Eric Wang | **日期：** 2026-05 | **arXiv：** 2605.14271\n- **核心：** 开辟本仓库此前完全缺失的维度——**harness 是安全面**。核心观察：harness 可以在\"返回正确且良性的最终答案\"的同时，轨迹中途访问未授权资源、或把上下文泄给错误的智能体——**输出级评估看不见这些失败**，而多数安全基准只给最终输出/终态打分。提出 HarnessAudit 框架（审计完整执行轨迹的边界合规、执行保真、系统稳定三维）+ HarnessAudit-Bench（210 任务 × 8 个真实领域，单/多智能体配置，内嵌安全约束）。\n\n- **关键发现（评测 10 种 harness 配置 × 前沿模型 × 3 个多智能体框架）：**\n - **任务完成与安全执行不对齐**，违规随轨迹长度累积——长时自主运行天然扩大风险\n - 安全风险随领域、任务类型、智能体角色而异\n - 违规集中在**资源访问**与**智能体间信息传递**两类\n - 多智能体协作扩大安全风险面；**harness 设计决定安全部署的上限**\n- **传播语境：** 被转发时的定性——\"业界正在意识到：harness 是产品，也是安全面。该审计的不只是模型，还有 prompt、工具、权限、记忆、执行层。AI 安全的下一个前沿是 harness 安全。\"（#37 作者马东锡转发）\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 中途轨迹违规 vs 输出级评估 | #25 Overeager（越界动作测量——本文把它推进到审计框架） |\n| 权限边界与信息流约束 | #7 Managed Agents 的安全边界解耦、#30 泄漏实锤的权限分类器 |\n| 多智能体扩大风险面 | #18 subagent 的 runtime state 追踪、#36 dynamic workflows 的千级扇出 |\n| harness 决定安全上限 | #37 \"可靠性的东西都属于 harness\" |\n\n---\n\n\n\n### 34. Harness-Bench 论文 — 配置级 harness 效应的诊断基准\n\n- **标题：** Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows\n- **链接：** [arxiv.org/abs/2605.27922](https://arxiv.org/abs/2605.27922)\n- **作者：** Yilun Yao, Xinyu Tan, Chao-Hsuan Liu 等 12 人 | **日期：** 2026-05 | **arXiv：** 2605.27922\n- **核心：** 现有基准要么抽象掉执行层、要么比较完整智能体系统、要么固定 harness——执行层变异一直难以研究。Harness-Bench 用 106 个沙箱离线任务（从实际 agent 使用模式构造，人工审核真实性/可解性/oracle 可检验性/完整性），在共享任务环境、预算与评估协议下评测代表性 harness 配置 × 多模型后端，同时**保留各 harness 的原生执行行为**。\n\n- **关键洞察：**\n - **5,194 条执行轨迹的结论：** 完成率、过程质量、效率、失败行为在 model-harness 配对间差异巨大——**智能体能力应按\"模型-harness 配置\"报告，而非归于基座模型**\n - **执行对齐失败（execution-alignment failures）：** 反复出现的失败类型——貌似合理的推理与工具反馈、工作区状态、证据、可验证输出契约**脱钩**\n - 每次运行记录最终工件、执行轨迹、用量统计、校验器输出——支持超越\"最终完成与否\"的过程分析\n - 直接回应本仓库缺口清单的\"Harness 覆盖率评估方法\"\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 按 model-harness 配置报告能力 | #35 统计归因（榜单侧的同一主张）、#38 Position（立场侧） |\n| 执行对齐失败 | #24 AHE 的决策可观测性、#27 LangSmith Engine 的轨迹骨架 |\n| 过程质量 > 最终完成 | #33 HarnessAudit（安全侧的同构主张：中途轨迹才是关键） |\n\n---\n\n\n\n### 35. How good is your harness? 论文 — harness 效应的统计归因\n\n- **标题：** How good is your harness? Statistical evaluation of coding harnesses\n- **链接：** [openreview.net forum](https://openreview.net/forum?id=QI8z3skBwt)（[PDF 直链](https://openreview.net/pdf/99eabc2ce65fd2871a253a0a57954c934ea9e6b0.pdf)）\n- **作者：** Jiwoo Han, Yuekai Sun（密歇根大学统计系） | **日期：** 2026-05-25（OpenReview 发布，2026-06-16 末次修订） | **发表：** CTB@ICML 2026 workshop（首尔）\n- **核心：** 用纯统计方法（加性 GLM，logit link）把 Terminal-Bench 2.0 榜单的分数方差拆解归因到 harness 效应与 LLM 效应——不依赖 LLM 标注轨迹，只需要足够交叉的 harness×LLM 榜单设计。数据：清洗后 105 个 harness-LLM 对（28 个 harness × 26 个 LLM）。\n\n- **两个定量结论：**\n 1. **harness 与 LLM 同等重要：** 从基线 harness 换到最优 harness 的分数跃升 ≈ 从基线 LLM 换到最优 LLM 的跃升——\"harness 不是实现细节，是性能的关键组件\"第一次有了量化版本\n 2. **harness 效应异质：** 某些 harness 与某些 LLM 更配（如 OpenHands 配 OpenAI 模型好于配 Anthropic/Google 模型）；交互效应量级堪比主效应——harness 和 LLM **不是可完全互换的组件**\n- **对本仓库缺口的意义：** \"跨模型可移植性\"缺口的第一份定量证据——迁移 harness 到新模型时收益不保序，压测（#4 的\"定期重新压测假设\"）有了统计学理由\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 效应 ≈ 模型效应 | #3 Trivedy 的 Top 30→Top 5 轶事（本文把轶事升级为估计量）、#31 Osmani 引用的数据点 |\n| 效应异质 / 模型-harness 耦合 | #3 的\"模型 overfit 到训练 harness\"、#4 harness 瘦身 |\n| 榜单统计方法 | #34 Harness-Bench（受控实验侧）、#38 Position（立场侧）——评测三部曲 |\n\n---\n\n\n\n### 36. Anthropic / Claude — 动态工作流：模型现场写自己的 harness\n\n- **标题：** A harness for every task: dynamic workflows in Claude Code\n- **链接：** [claude.com/blog](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code)\n- **翻译：** [works/anthropic-dynamic-workflows-translation.md](../works/anthropic-dynamic-workflows-translation.md)\n- **作者：** Thariq Shihipar, Sid Bidasaria（Anthropic Claude Code 团队） | **日期：** 2026-06-02（功能随 Claude Code 2.1.154 + Opus 4.8 于 2026-05-28 发布）\n- **核心：** harness 本体论的转折点——Claude 现在**为任务现场编写自己的 JavaScript 编排脚本**，即一次性定制 harness。默认 Claude Code harness 要在同一个上下文窗口里既规划又执行，在长时运行、大规模并行、高度结构化、对抗性任务上会崩；dynamic workflows 把编排逻辑放进代码（在 token 上近乎免费），单会话扇出数十到数百个并行 subagent，各自在隔离上下文窗口内执行聚焦目标。\n\n- **关键洞察：**\n - **静态 workflow 的宿命是泛化损耗：** 预置工作流必须覆盖所有边界情况所以偏通用；Opus 4.8 已足够聪明为具体用例现写定制 harness——#4\"每个 harness 组件编码一个假设\"在这里变成\"假设由模型即时生成\"\n - **编排即代码：** workflow 可决定每个 agent 用什么模型、是否跑在独立 git worktree——智能等级与隔离度成为可编程参数\n - **对抗验证模式：** 每个生成 agent 配一个独立 agent 按 rubric 对抗校验其输出，收敛后才交付用户；官方 `/deep-research` skill 即此模式（扇出搜索→抓源→对抗核查→合成引用报告）\n - **激活策略：** 提示词含 \"workflow\" 触发，或用 \"ultracode\" 触发词确保建 workflow——回应本仓库缺口清单的\"控制激活策略\"\n - **workflow 是可沉淀资产：** 生成的脚本可检查、保存、复用，经 Skill 分发——一次性 harness 固化为版本化自动化\n - **反向蒸馏：** 挖掘近期 session 和 code review 评论中反复出现的纠正 → 并行 agent 聚类 → 对抗验证每条候选（\"这条规则真能防住一次真实错误吗？\"）→ 幸存者蒸馏回 CLAUDE.md\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 从人写工件变成模型生成工件 | #11 Meta-Harness、#24 AHE（自动搜索/演化的产品化收束）、#7 meta-harness |\n| 编排放进代码以省上下文 | #22 Deep Agents 解释器、#16 Symphony 控制平面 |\n| 对抗验证 | #4 的 Evaluator 分离、#10 评估清单 |\n| 千级 subagent 扇出 | #18 subagent 的 runtime state 管理、#33 多智能体风险面 |\n| 与 Ralph 单体论的张力 | #28 Huntley \"现阶段不需要多智能体\"——一年后官方产品反向而行 |\n\n---\n\n\n\n### 37. 马东锡 NLP — Harness 才是产品\n\n- **标题：** Harness 才是产品：决定 Coding Agent 体验的不是 Model，是它周围的整套 Runtime（Harness 系列）\n- **链接：** [SOTA Sync 转载页](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/)（原文发布于 X @dongxi_nlp，原帖需登录访问，本条目暂链转载页）\n- **作者：** 马东锡 NLP (@dongxi_nlp) | **日期：** 2026-06\n- **核心：** 把系列观点收束成一条产品论断：聊 coding agent 第一个该问的不是\"用哪个 model\"，而是\"**Harness 到底负责什么**\"。coding agent = 把 model 放进一套 runtime（查真实 repo、请求 tool、编辑文件、跑检查、记住发生过什么、多轮推进）——这层 runtime 就是 harness，\"对 coding agent 来说，harness 本身就是 product\"。\n\n- **关键洞察：**\n - **Mini agent 的五个真实爆点：** 编辑从没读过的文件 / shell 触碰 workspace 外 / tool 返回 50,000 行输出 / 磁盘文件已变而 transcript 还是旧读 / tool result 与 tool call 对不上——画出「observe → model → tool」草图的系统还不是 coding agent\n - **六个核心组件：** live repo context / prompt shape / structured tools / context reduction / transcripts & memory / delegation；\"context quality 经常看起来像 model quality\"\n - **\"Model 在 loop 里，harness 拥有 loop\"：** 一个 `edit src/config.py` tool call 只是 proposal，harness 要回答十来个裁决问题（path 是否在 workspace 内、会否经 symlink 逃逸、baseline 是否过期、要否 human approval、多少 output 进下一轮 prompt……）——\"这些判断不该交给 model 的随机处理\"\n - **Transcript ≠ working state：** \"发生过什么\"与\"现在什么重要\"是两份不同任务，必须区别对待\n - **症状→组件的 debug 对照表：** 不断重复→查 loop/retry policy；编辑 stale code→查 file-state baselines；越跑越差→查 context projection；运行意外东西→查 permission policy；无法从 tool error 恢复→查 tool result objects\n - **工程规则收尾：** \"Anything that must be reliable belongs in the harness.\"\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 拥有 loop / 裁决权 | #18 subagent（同系列前作：tool call outside, runtime inside） |\n| harness 是安全面 | #33 HarnessAudit（作者本人转发并背书） |\n| proposal vs 落实边界 | #25 Overeager（提示声明 vs 机械门控）、#31 hooks 分界论 |\n| context projection | #6 context editing、#22 第三类上下文表面 |\n\n---\n\n\n\n### 38. Position 论文 — 编码基准与智能体软件工程的错位\n\n- **标题：** Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering\n- **链接：** [arxiv.org/abs/2606.17799](https://arxiv.org/abs/2606.17799)\n- **作者：** Maria I. Gorinova, Macey Baker, Amy Heineike, Maksim Shaposhnikov, Rob Willoughby, Dru Knox | **日期：** 2026-06 | **arXiv：** 2606.17799\n- **核心：** 立场论文——我们用来比较编码智能体的基准诞生于前智能体时代：把 model、harness、environment 折叠进一个端到端分数，通常按单一参考解评分，没有可迭代的组件级信号。\"实践中的编码智能体不是模型，是 system harness——models/harnesses/contexts/environments/feedback signals 的复合体，其中任何一项都能把基准分数挪动一个相邻模型代际的量级。\"\n\n- **三个症状：**\n 1. 基准分数把模型与 harness 其余部分**混同**——排行榜差异无法归因\n 2. 按单一参考解评分**惩罚同样有效的替代方案**——真实工程里一题多解是常态\n 3. 缺少单个 harness 组件级别的信号，端到端系统分数**难以迭代**——你不知道该修哪里\n- **对本仓库的意义：** 与 #34（受控实验）、#35（榜单统计归因）构成\"harness 评测三部曲\"；也为 thinking/evaluation-elephant-in-the-room 的\"行为 harness 是大象\"补上评测学的病理诊断\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| model/harness/environment 折叠 | #35 的统计拆解方案、#34 的配置级测量方案 |\n| 单参考解惩罚多解 | #10 评估清单的 LLM-as-judge 校准 |\n| 组件级信号缺失 | #24 AHE 的三类可观测性（正是组件级信号的一种供给） |\n\n---\n\n\n\n### 39. OpenAI / Michael Bolin — 展开 Codex agent loop（Codex harness 解剖 · 上）\n\n- **标题：** Unrolling the Codex agent loop\n- **链接：** [openai.com](https://openai.com/index/unrolling-the-codex-agent-loop/)\n- **作者：** Michael Bolin (OpenAI, Codex CLI 团队) | **日期：** 2026-01-23\n- **核心：** Codex 系列工程博客第一篇——把 Codex CLI 的 agent loop（\"我们的 agent，或曰 harness\"）逐层展开：从用户输入构造初始 prompt、经 Responses API 推理、执行工具调用并把输出追加回 `input`，直到模型产出 assistant message 结束一个 turn。是官方视角下 harness 内部机制的最细粒度公开拆解。\n- **关键洞察：**\n - **prompt 是\"item 列表\"：** `instructions`（模型特定指令）+ `tools`（shell / update_plan / web_search / MCP 工具）+ `input`（sandbox 说明 → developer 指令 → AGENTS.md 聚合的用户指令 → environment_context → 用户消息）——AGENTS.md 从 git 根到 cwd 逐层聚合、默认 32 KiB 上限的机制被首次官方成文\n - **agent loop 天然是二次方的：** 每轮把全部历史重发；Codex 刻意不用 `previous_response_id` 以保持请求无状态并支持 ZDR（零数据保留），靠 prompt caching 把采样成本从二次方拉回线性\n - **缓存破坏向量：** 中途改 tools、换模型、改沙箱/审批/工作目录都会 cache miss；MCP 工具枚举顺序不稳定曾是真实 bug——应对策略是\"追加新消息表达变更，而不是改旧消息\"（与 #6 缓存五原则、#30 泄漏实锤的 14 种缓存破坏向量互证）\n - **compaction 的演进：** 从手动 `/compact`（用摘要替换 input）到 Responses API 专用 `/responses/compact` 端点——返回含 `encrypted_content` 的 `type=compaction` item，保留模型对原对话的潜在理解，超过 `auto_compact_limit` 自动触发\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness = agent loop 的官方自述 | #3 LangChain 的 Agent = Model + Harness、#17 Claude Code 逆向（对照组：Codex 侧的官方版） |\n| prompt caching 工程细节 | #6 缓存优化五原则、#30 泄漏实锤的缓存破坏向量追踪 |\n| AGENTS.md 聚合机制 | #5 HumanLayer 的 AGENTS.md 杠杆、概念 2 地图而非手册 |\n| compaction 端点化 | #7 Managed Agents 的 Session 外部存储、#22 上下文表面分层 |\n\n---\n\n\n\n### 40. OpenAI / Celia Chen — 解锁 Codex harness：App Server（Codex harness 解剖 · 下）\n\n- **标题：** Unlocking the Codex harness: how we built the App Server\n- **链接：** [openai.com](https://openai.com/index/unlocking-the-codex-harness/)\n- **作者：** Celia Chen (OpenAI) | **日期：** 2026-02-04\n- **核心：** Codex 的 web / CLI / IDE 扩展 / macOS 应用全部由同一个 Codex harness 驱动，而把这个 harness 暴露给所有客户端的是 Codex App Server——一个双向 JSON-RPC（JSONL over stdio）协议 + 长驻进程。把 harness 从产品内部件变成可被第三方集成的稳定平台面（HaaS 的 OpenAI 实现）。\n- **关键洞察：**\n - **三个对话原语：** Item（原子输入/输出单元，带 `started`/`delta`/`completed` 生命周期）、Turn（一次用户输入触发的工作单元）、Thread（可创建/恢复/fork/归档的持久容器）——为\"agent 交互不是请求/响应\"给出协议级建模\n - **协议是双向的：** 服务器可以主动发起请求（如审批），暂停 turn 直到客户端应答——权限门控被编进协议而非提示词\n - **harness 内容物 = agent loop + thread 生命周期与持久化 + 配置与认证 + 工具执行与扩展（sandbox、MCP、skills）**——官方划出的 harness 边界清单\n - **集成谱系：** App Server（全功能）> Codex SDK > MCP server 模式 > `codex exec`（CI 一次性）；跨厂商 harness 协议会收敛到能力交集，丰富交互难以表达——对\"标准化 vs 表达力\"权衡的一手表态\n - Codex Web 在容器里跑同一个 App Server 二进制，状态留在服务端，浏览器只是轻客户端——ephemeral 会话的断线重连由持久 thread 兜底\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| HaaS（Harness-as-a-Service） | #31 Osmani 的 HaaS 论、#7 Managed Agents 的 harne","isInternal":false,"tokens":28947,"sizeBytes":81610},{"name":"00-overview.md","path":"tools/00-overview.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/tools/00-overview.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# 工具地图：复杂度维度 ↔ 工具杠杆\n\n> 配套 [software-project-complexity-in-the-ai-era.md](../thinking/software-project-complexity-in-the-ai-era.md) 的6 维复杂度框架使用。\n\n---\n\n## 思路\n\n每个工具的真正价值，不是它的功能列表，而是：\n\n> **它能切实降低 AI 接管难度的哪一维？**\n\n如果一个工具不能映射到任何一维复杂度的下降，它就不应该出现在这里。\n\n---\n\n## 维度 × 工具矩阵\n\n\n### 六个分子维度（越高越复杂）\n\n| # | 复杂度维度 | 工具杠杆候选 | 实测笔记 |\n| --- | ------ | ------------------------------- | ---- |\n| 1 | 上下文压力 | [待补：检索 / 语义索引 / 上下文压缩] | [待补] |\n| 2 | 可提示性 | [待补：SPEC 模板 / DSL / 业务建模] | [待补] |\n| 3 | 探索收敛 | [待补：AGENTS.md / 项目地图 / sitemap] | [待补] |\n| 4 | 状态纠缠 | [待补：模块边界检查 / 依赖图 / ArchUnit 类] | [待补] |\n| 5 | 暗知识 | [待补：ADR / 决策记录 / 注释规范] | [待补] |\n| 6 | 验证成本 | [ralph-orchestrator](harnesses/ralph-orchestrator.md)（背压门控，主战场）；另待补：测试框架 / CI / 类型检查 / linter | ✅ [practice/01](../practice/01-ralph-demo/) 实测：Builder 测试全绿才交棒 + Critic 独立重验 |\n\n### 分母：胶囊化能力（越高越好）\n\n| 维度 | 工具杠杆候选 | 实测笔记 |\n| --------- | ------------------------------------- | ---- |\n| **胶囊化能力** | Claude Code / Codex / Cursor / ... 等各大 harness 框架 | Harness 框架的核心价值——让 AI 在可控边界内完成任务，从而把上面六维的成本同时压下来 |\n\n### 终局指标：重构 + 复刻\n\n> 文章最后指出\"重构能力 + 复刻能力\"是复杂度的最终显影。一个工具是否值得收录，最终可以问：**它是否提升了项目的重构 / 复刻可行性？**\n\n注：同一个工具可能横跨多维。**填表时按\"主战场\"放，次要贡献在工具页里展开。**\n\n---\n\n## 收录工具（持续更新）\n\n### Harness 框架\n\n> 作者使用为主，已在 [practice/](../practice/) 中跑过的优先标注 ✅\n\n- ✅ [ralph-orchestrator](harnesses/ralph-orchestrator.md) — 已在 [practice/01-ralph-demo/](../practice/01-ralph-demo/) 实测（v2.8.1，4 轮迭代 / 321s / $0.31）\n- Claude Code（practice/01 中作为 Ralph 的执行后端使用过；独立工具页待写）\n- Codex CLI/ Codex App\n- Cursor\n- [其他待补]\n\n### 辅助工具\n\n> 按 6 维分类组织\n\n- [待补]\n\n---\n\n## 撰写新工具页的检查清单\n\n- 是否回答了\"它降低了哪几维复杂度\"\n- 是否给出至少一个**失效场景**（不是只写优点）\n- 是否标注与其他已收录工具的搭配 / 冲突\n- 是否说明\"为什么是它而不是同类竞品\"\n\n","isInternal":false,"tokens":1111,"sizeBytes":2934},{"name":"ralph-orchestrator.md","path":"tools/harnesses/ralph-orchestrator.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/tools/harnesses/ralph-orchestrator.md","title":"Harnesses Skill","category":"anthropic-skill","format":"markdown","content":"# Harnesses Skill\n\nPath: `tools/harnesses/ralph-orchestrator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/tools/harnesses/ralph-orchestrator.md)","tokens":300,"sizeBytes":199},{"name":"deep-research-tracker.md","path":"prompts/deep-research-tracker.md","rawUrl":"https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/prompts/deep-research-tracker.md","title":"Agent Directive: deep-research-tracker","category":"generic","format":"markdown","content":"# 深度研究追踪 Prompt\n\n> 用途：定期（每 1-2 周）运行，发现 harness engineering / AI 编程领域的高价值新内容\n> 推荐工具：ChatGPT Deep Research（广度搜索）→ Claude（深度分析 + 项目关联）\n\n---\n\n## Prompt A：ChatGPT Deep Research — 广度发现\n\n```\n你是一个技术情报分析师。请对以下领域进行深度网络搜索，找出过去 2 周内（{START_DATE} 至 {END_DATE}）发布的高价值内容。\n\n### 搜索领域\n\n核心主题：\n1. Harness Engineering — AI 编码智能体的约束、引导、反馈系统设计\n2. Context Engineering — 上下文窗口管理、compaction、渐进式披露\n3. AI Coding Agents — 编码智能体的架构、编排、评估\n4. Agent Infrastructure — 沙箱、会话管理、多智能体协作\n5. AI-assisted Software Engineering — AI 辅助开发的效率、流程、组织影响\n\n相关关键词（中英文）：\n- harness engineering, agent harness, coding agent, AI coding\n- context engineering, context window, compaction, progressive disclosure\n- AGENTS.md, CLAUDE.md, agent readability, agent-first\n- managed agents, meta-harness, multi-agent orchestration\n- AI code review, mutation testing, structural testing, fitness functions\n- vibe coding, AI-native development, agentic workflow\n- 智能体工程, AI 编程, 上下文工程, 护栏工程\n\n### 搜索范围\n\n必须覆盖的信源（按优先级）：\n\n**Tier 1 — 高权重（模型厂商 + 顶级技术博客）：**\n- Anthropic Engineering Blog (anthropic.com/engineering)\n- OpenAI Blog (openai.com)\n- Google DeepMind / Google AI Blog\n- Martin Fowler (martinfowler.com)\n- Mitchell Hashimoto (mitchellh.com)\n- LangChain Blog (blog.langchain.com)\n- Simon Willison (simonwillison.net)\n\n**Tier 2 — 中权重（社区 + 行业）：**\n- Hacker News (前 100 讨论)\n- GitHub Trending (相关仓库)\n- X/Twitter 技术社区 (#harness-engineering, #ai-coding, #context-engineering)\n- Dev.to, Medium 技术专栏\n- HumanLayer, Cursor, Windsurf, Codex 相关博客\n- 中文社区：少数派、掘金、知乎专栏\n\n**Tier 3 — 低权重但可能有惊喜：**\n- arXiv (cs.SE, cs.AI 交叉)\n- 个人技术博客\n- YouTube 技术频道\n- Reddit (r/LocalLLaMA, r/ChatGPT, r/programming)\n\n### 我们已知的内容（用于去重和关联）\n\n> **本节是 Prompt 的去重权威**——给外部搜索器（ChatGPT Deep Research 等）使用。\n> 它必须自包含，因为搜索器无法访问 `references/articles.md`。\n>\n> **维护纪律：** 当 `references/articles.md` 新增/删除条目时，**同一次提交中**必须同步更新本节。两份内容的口径（脉络划分、篇数、产品/项目清单）应保持完全一致。\n> 本节最近一次同步：2026-08-27（与 `articles.md` 当前内容对齐：79 篇文章 + 1 项已跟踪产品）。\n\n**核心文章 79 篇，分布于三条脉络：**\n\n- **脉络一 — AI 时代 Harness Engineering（75 篇）：**\n - OpenAI \"Harness engineering\"（原点，2026-02-11）/ \"An open-source spec for Codex orchestration: Symphony\"（2026-04-27，任务跟踪器作为控制平面）\n - Fowler/Böckeler \"Harness engineering for coding agent users\"（2026-04-02）+ 前传备忘录（2026-02-17）\n - LangChain \"The Anatomy of an Agent Harness\"（2026-03）/ \"Continual Learning for AI Agents\"（2026-04-05）/ \"Agent Evaluation Readiness Checklist\"\n - Anthropic \"Harness design for long-running application development\"（2026-03-24）\n - Anthropic / Lance Martin \"Harnessing Claude's intelligence\"（2026-04-02，三大模式与性能数据）\n - Anthropic \"Scaling Managed Agents\"（2026-02-04，meta-harness 与基础设施解耦）\n - HumanLayer \"Skill Issue\"（2026-03，六杠杆与避坑）\n - Fowler / Rahul Garg \"Encoding team standards\"（2026-03）/ \"Feedback flywheel\"（2026-03）\n - Meta-Harness 论文（自动化 Harness 优化）\n - GitHub / Tyler McGoffin \"Agent-Driven Development\"（实战）\n - \"Inside the Scaffold\" 论文（编码智能体脚手架的源代码级分类法）\n - Lalit Maganti \"渴望八年，用 AI 三个月造出来\"\n - Vikash Rungta \"Claude Code Architecture (Reverse Engineered)\"（2025-11-01，Claude Code 运行外壳、TAOR 循环、工具原语、权限与上下文管理的外部逆向分析）\n - 马东锡 NLP \"Harness 系列文章之 7：关于 subagent\"（2026-06-22，subagent = tool call 入口 + child runtime，区分 session/context/subagent，与 Claude Code 逆向互证）\n - Fowler/Böckeler \"Maintainability sensors for coding agents\"（2026-05-20，计算性 vs 推理性传感器谱系 + 失败案例 + AI 评审作为垃圾回收）\n - Fowler \"Structured-Prompt-Driven Development (SPDD)\"（2026-04-28，REASONS Canvas 七维 + prompt 即一等交付物 + 双向闭环）\n - LangChain / Harrison Chase \"The Agent Development Lifecycle (ADLC)\"（2026-05-09，framework/runtime/harness 三分类的生命周期）\n - LangChain / Hunter Lovell \"Interpreters in Deep Agents\"（2026-05-20，interpreter 是第三类上下文表面 + 35% token 节省）\n - Anthropic 工程团队 \"An update on recent Claude Code quality reports\"（2026-04-23，三起独立变更叠加成质量退化的第一手复盘）\n - Agentic Harness Engineering 论文（arXiv 2604.25850，复旦/北大/奇绩，可观测性驱动的 Harness 自动演化 + 可证伪契约）\n - Overeager Coding Agents 论文（arXiv 2605.18583，越界动作测量 + 提示声明授权反而降低边界推断）\n - Chris Parsons \"How I Use AI to Code\"（2026-05，四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈；含译者注，2026 数据未独立核实）\n - LangChain / Palash Shah \"How we built LangSmith Engine\"（2026-05-19，用智能体改进智能体，trace→轨迹骨架 + screener/investigator 两阶段闭环）\n - Geoffrey Huntley \"Ralph Wiggum as a software engineer\"（2025-07）+ \"everything is a ralph loop\"（2026-01-17，bash 循环 + 干净上下文 + 背压 + 单体反多智能体论）\n - Mitchell Hashimoto \"My AI Adoption Journey\"（2026-02-05，六步采纳路线 + \"harness engineering\" 命名出处）\n - Claude Code 源码泄漏事件（2026-03-31，v2.1.88 npm source map 泄 512K 行 TypeScript；聚合分析 pankaj28843/understanding-claude-code：QueryEngine ~46K 行、60+ 门控工具、KAIROS/AutoDream/Undercover Mode）\n - Addy Osmani \"Agent Harness Engineering\"（2026-04-19，O'Reilly 转载；学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS）\n - Thoughtworks / Böckeler & Ford \"Exploring AI coding sensors\"（2026-05-13，有/无传感器对照实验 + harness 模板展望）\n - HarnessAudit 论文（arXiv 2605.14271，harness 安全审计：中途轨迹违规是输出级评估盲区，210 任务基准）\n - Harness-Bench 论文（arXiv 2605.27922，配置级 harness 效应：106 任务 / 5194 轨迹 + 执行对齐失败）\n - \"How good is your harness?\"（CTB@ICML 2026，Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应且异质）\n - Anthropic/Claude \"A harness for every task: dynamic workflows in Claude Code\"（2026-06-02，模型现场写自己的编排 harness + 对抗验证 + ultracode 触发）\n - 马东锡 NLP \"Harness 才是产品\"（2026-06，Model 在 loop 里 harness 拥有 loop + 六组件 + 症状→组件 debug 表）\n - Position 论文 \"Coding Benchmarks Are Misaligned with Agentic SE\"（arXiv 2606.17799，基准折叠 model/harness/环境的三症状）\n - OpenAI \"Unrolling the Codex agent loop\"（2026-01-23，Codex harness 解剖·上：prompt 构造 / 二次方与 prompt caching / compaction 端点化）\n - OpenAI \"Unlocking the Codex harness\"（2026-02-04，Codex harness 解剖·下：App Server 双向 JSON-RPC + Item/Turn/Thread 原语 + HaaS）\n - Addy Osmani \"Loop Engineering\"（2026-06-08，loop 定调文：五构件 + 记忆脊柱；上游为 Steinberger 推文与 Boris Cherny \"我的工作是写循环\"）\n - Armin Ronacher \"The Coming Loop\"（2026-06-23，怀疑派回应：agent loop vs harness loop + 防御式编码放大 + 软件作为有机体）\n - Anthropic/Claude Code 团队 \"Loop engineering: Getting started with loops\"（2026-06-30，官方四类循环 turn/goal/time/proactive + `/goal` 独立判停）\n - Self-Harness 论文（arXiv 2606.09498，智能体自改 harness：弱点挖掘→提议→回归验证，三模型 held-out +14~21pp）\n - Lilian Weng \"Harness Engineering for Self-Improvement\"（2026-07-04，RSI 综述：三设计模式 + 优化对象递进链 + 七项未来挑战）\n - Aria 论文 \"Harnessing Code Agents for Automatic Software Verification\"（arXiv 2607.06341，声明式 HHL 包裹通用智能体做 Coq 证明，行为 harness 极限形态）\n - Anthropic \"Demystifying evals for AI agents\"（2026-01-09，智能体评测官方方法论：outcome≠transcript、pass@k/pass^k、CORE-Bench 42%→95% 基准病理）\n - Cursor / Wilson Lin \"Scaling long-running autonomous coding\"（2026-01-14，数百并发智能体 × 数周：planner/worker/judge + FastRender 百万行浏览器）\n - Anthropic / Nicholas Carlini \"Building a C compiler with a team of parallel Claudes\"（2026-02-05，16 agent 无编排者 + GCC oracle + $20k 成本账本）\n - Anthropic \"How we contain Claude across products\"（2026-05-25，三隔离模式 + 五起漏掉的风险：白名单是能力授予、先环境层遏制）\n - LangChain \"Introducing Dynamic Subagents in Deep Agents\"（2026-06-29）+ \"How to Use RLMs in Deep Agents\"（2026-07-01，模型写编排脚本 + RLM 递归上下文）\n - Fowler/Böckeler 本地模型双备忘录（2026-07 上旬，Qwen3.6 35B MoE 甜点 + 工具调用是智能体化分水岭）\n - Harness Handbook 论文（arXiv 2607.13285，2026-07-14，行为定位是 harness 演化瓶颈：行为中心表示 + BGPD）\n - Fowler / Unmesh Joshi \"DSLs Enable Reliable Use of LLMs\"（2026-07-14，DSL 工具集即 harness：语言层约束 + 确定性验证器）\n - Addy Osmani \"Own the Outer Loop\"（2026-07-15，AIE 闭幕演讲：智能体跑内环、工程师拥有外环问责 + back-pressure 调速）\n - Jarred Sumner \"Rewriting Bun in Rust\"（2026-07-08，50 dynamic workflows × 峰值 64 Claude × 11 天机械移植 53.5 万行 Zig→Rust；语言无关测试套件作 oracle + 1 实现者/2 对抗评审者/1 修复者 + \"修流程不修代码\"；$165k API 成本账本）\n - HarnessX 论文（arXiv 2606.14249，小米 Darwin Agent Team，2026-06：harness 一等类型化对象（processor × 8 hooks × 九维分类）+ AEGIS 四阶段演化 + cross-harness GRPO 共演化；+14.5% 均值（最高 +44.0%）、共演化再 +4.7%、弱模型受益最大）\n - Anthropic / Justin Young \"Effective harnesses for long-running agents\"（2025-11-26，存量回扫补录：initializer + coding 两段式、200+ 条 feature_list.json、claude-progress.txt + git、Puppeteer 端到端自验；#4/#7 的上游）\n - Anthropic / Gian Segato \"Quantifying infrastructure noise in agentic coding evals\"（2026-02-05，存量回扫补录：只改资源配额 Terminal-Bench 2.0 摆动 6pp；1x–3x 修可靠性、3x 以上改变被测对象；建议每任务声明保底分配 + 硬杀阈值）\n - Cursor / Stefan Heule & Jediah Katz \"Continually improving our agent harness\"（2026-04-30，存量回扫补录：Keep Rate、LLM 读用户回复判满意、CursorBench + 线上 A/B、错误分类与按工具按模型基线、每周 Automation 修 harness、按训练分布供给工具格式、context anxiety）\n - Cursor / Naman Jain \"Reward hacking is swamping model intelligence gains\"（2026-06-25，存量回扫补录：审计 731 条轨迹，SWE-bench Pro 上 63% 成功解是检索答案；封 git + 断网后 Opus 4.8 Max 87.1%→73.0%、Composer 2.5 74.7%→54.0%）\n - Armin Ronacher \"Better Models: Worse Tools\"（2026-07-04，工具 schema 不是中立的：Claude Code 的宽容客户端 + 在其中做 RL → 新模型对替代 schema 更差；strict 模式可清零）\n - Dex Horthy / HumanLayer \"Why Software Factories Fail — harness engineering is not enough\"（2026-07，AIE World's Fair 主题演讲 + wsff.md：熄灯工厂第一手失败实录、可维护性没有快 oracle、产品/架构/程序设计/垂直切片四阶段前移）\n - Addy Osmani \"Software Factories, Light and Dark\"（2026-07-20，loop→harness→factory 三层 + 唯一昂贵的评审闸门 + 背压规则 + \"什么样的循环配得上熄灯\"准入清单 + loops vs graphs）\n - Cursor / Wilson Lin \"Agent swarms and the new model economics\"（2026-07-20，#48 续篇：835 页手册重造 SQLite，账单 $1,339–$10,565；规划/执行分层、自建 VCS 1000 提交/秒、五种蜂群失效、去相关评审、Field Guide）\n - Anthropic / Thariq Shihipar \"The new rules of context engineering for Claude 5 generation models\"（2026-07-24，删掉 Claude Code 系统提示词 80%+ 无可测损失；七组 then/now + `claude doctor`）\n - Don't Blame the LLM 论文（arXiv 2607.03691，Queen's University，首个固定模型只变 harness 的受控纵向研究：Qwen Code CLI 35 个连续版本 × 50 个 SWE-bench Verified 任务）\n - Rethinking Harness Evolution 论文（arXiv 2607.12227，自动 harness 演化的第一份系统性负面结果：同等预算下不稳定优于 test-time scaling、泛化有限）\n - LangChain \"How We Benchmark Deep Agents\"（2026-07-23）+ \"IssueBench\"（2026-07-20）——Harbor 评测栈：Harbor-Index 82 任务 / lite 冻结子集 / capability suite；IssueBench 15 类失败分类法与 issue 集层面判分\n - LangChain / Nick Hollon \"Evaluating code review agents with ReviewBench\"（2026-07-31，真实 PR 评审意见策展成 59 任务 / 64 基线问题；裸 harness 最强召回 ~30%，prompt-only 调优 Luna 0.13→0.32 反超 Opus/Kimi）\n - Fowler / Birgitta Böckeler \"TDD inside the agent loop - theater or actual value?\"（2026-08-10，agent loop 内 TDD 实证否定：盲评质量无差异、mutation score 无差异、token 3–8.5 倍；别规定过程，度量结果）\n - Addy Osmani \"Practical Loop Engineering\"（2026-08-14，loop 系列日常落地环：踩坑实录 + 80K star 仓库分诊循环 + fine print 运维细则）\n - Zalando / Bartosz Ocytko \"Agentic Engineering at Zalando: A Snapshot\"（2026-08-14，250+ 团队非供应商组织级快照：事故分析→PR 风险分级→33% 自动放行→lead time -20~40%）\n - Earendil / Pi 团队双篇 \"What Is a Harness?\" + \"How Compaction Works in Pi\"（2026-08-20 / 08-13，harness 定义+用户侧中立主张 / compaction 白盒实现，与 Codex 端点化对照）\n - StarHarness 论文（arXiv 2608.24804，ServiceNow/Mila，2026-08-25，冻结 harness 工件跨 GPT/Qwen 迁移 12 行全正 +10.7~+46.3pp；跨模型可移植性首个正面证据）\n- **脉络二 — 云原生 Harness.io（2 篇）：** Harness.io 官方全局架构 / Google Cloud 集成场景\n- **脉络三 — 效率悖论（2 篇）：** YDD/Miss-you \"效率悖论的系统性拆解\"（2026-03-03）/ METR 实验后续 + 自报调查（2026-02-24 + 2026-05-11，\"慢 19%\"的官方后续：弱证据转向加速 + RCT 方法论危机）\n\n**已跟踪的开源项目/产品：**\n- Ralph Loop 实验链：snarktank/ralph、ralph-orchestrator、bmad-ralph\n- Chachamaru127/claude-code-harness（v4.2 \"Hokage\"，Claude Code 五动词工作流 + Go 原生 guardrail R01–R13；2026-04-21 收录）\n\n**请重点发现：**\n- 上述未覆盖的新作者 / 新视角 / 新组织\n- 对上述文章的**深度回应或反驳**（不是简单转述）\n- 与上述项目**互补或竞争**的新工具 / harness / 框架\n- 中文社区针对上述材料的原创分析（少数派、掘金、知乎专栏等）\n\n### 输出格式\n\n请按以下格式输出，每条内容一个条目：\n\n---\n\n#### [编号]. {标题}\n\n- **类型：** 文章 / 开源项目 / 工具 / 演讲 / 论文\n- **链接：** {URL}\n- **作者/组织：** {作者}\n- **日期：** {发布日期}\n- **信源层级：** Tier 1 / Tier 2 / Tier 3\n- **推荐指数：** ⭐⭐⭐⭐⭐（1-5 星）\n\n**一句话摘要：** {50 字以内}\n\n**核心洞察（3-5 条）：**\n1. ...\n2. ...\n3. ...\n\n**与已知内容的关联：**\n- 支持/挑战/扩展了哪篇已有文章的观点\n- 填补了哪个已知缺口\n\n**值得收录的理由 / 不值得的理由：**\n{判断}\n\n---\n\n### 质量过滤标准\n\n**必须满足（全部）：**\n- 有实质性的技术内容（不是纯营销或产品公告）\n- 有原创洞察或数据（不是对已有文章的简单转述）\n- 来源可信（有署名，有技术背景）\n\n**加分项（满足越多越好）：**\n- 有实际数据或实验结果\n- 有代码示例或可复现的方案\n- 挑战了主流观点\n- 来自一线实践者（不是纯理论）\n- 有中文社区尚未覆盖的视角\n\n**排除：**\n- 纯产品发布/营销内容\n- 对已有文章的简单翻译或摘要（没有新观点）\n- 过于初级的入门教程\n- 与 harness engineering 只有表面关联\n\n### 输出数量\n\n- 文章类：推荐 5-10 篇，按推荐指数排序\n- 开源项目类：推荐 3-5 个\n- 其他（工具/演讲/论文）：如有高质量内容，不限数量\n```\n\n---\n\n## Prompt B：Claude — 深度分析与项目关联\n\n> 在 ChatGPT 返回结果后，将结果喂给 Claude（在本项目中），做深度分析\n\n```\n以下是最近 2 周的技术情报搜索结果。请基于我们项目的已有内容，做以下分析：\n\n{粘贴 ChatGPT 的输出}\n\n### 请分析：\n\n1. **优先级排序**：哪些内容最值得我们收录？考虑因素：\n - 对**已收录文章 + 已跟踪开源产品**（完整清单见 Prompt A 的\"已知内容\"段落或 `references/articles.md`，不在此重复计数）的补充价值\n - 对 thinking/ 中已有洞见的验证或挑战（含 cross-article-insights 的 8 个洞见 + guides-sensors-meets-claude-code-harness 的 5 个张力）\n - 对开放问题清单的回答程度\n\n2. **缺口分析**：这批内容覆盖了我们的哪些知识缺口？还有哪些缺口未被触及？\n 当前已知缺口：\n - 行为 Harness（功能正确性验证）\n - Harness 覆盖率评估方法（#34/#35/#38 评测三部曲已部分回应，组件级信号供给仍开放）\n - 跨模型可移植性（#35 给出首个定量异质性证据，迁移指南仍缺）\n - 成本数据\n - 中小团队实践案例\n - Harness 接口维护成本（追宿主升级在总维护中的占比）\n - 控制的\"激活策略\"（always-on / per-commit / conditional / human-summoned 的分类与适用场景；#36 的 workflow/ultracode 触发是一个数据点）\n - Harness 安全审计（#33 开辟：中途轨迹违规、多智能体信息流、harness 决定安全上限——后续跟踪该方向的评测与工具）\n - 评测方法论（基准如何拆分 model/harness/环境的组件级归因——跟踪 #34/#35/#38 的后续工作）\n\n3. **趋势信号**：这批内容中是否有新的趋势或方向？与我们已有的四个学派（约束派、控制论派、架构派、怀疑派）是否一致？\n\n4. **收录建议**：对每条推荐内容给出具体建议：\n - 收录到 references/articles.md（哪个脉络）\n - 值得翻译到 works/\n - 值得在 thinking/ 中写分析\n - 暂不收录，持续观察\n```\n\n---\n\n## Prompt C：Manus / OpenClaw — 自动化监控\n\n> 用于设置定时监控的固定信源\n\n```\n定时任务：每日检查以下信源的更新\n\n监控列表：\n1. https://www.anthropic.com/engineering — RSS 或页面变化\n2. https://openai.com/index/ — 新文章\n3. https://martinfowler.com/articles/ — 新文章\n4. https://blog.langchain.com/ — 新文章\n5. https://github.com/trending?since=weekly — AI/agent 相关项目\n6. https://simonwillison.net/ — 新文章\n7. https://mitchellh.com/writing — 新文章\n8. https://claude.com/blog — 新文章（Anthropic 产品侧博客；2026-06 的 dynamic workflows / Managed Agents 两篇重磅均发于此，工程博客不覆盖）\n9. https://addyosmani.com/blog/ — 新文章\n10. https://ghuntley.com/ — 新文章（Ralph 方法论源头）\n\n匹配关键词：harness, agent, coding agent, context engineering, \n AGENTS.md, compaction, multi-agent, sandbox\n\n输出：\n- 有更新时，发送通知（标题 + 链接 + 匹配的关键词）\n- 无更新时，静默\n```\n\n---\n\n## 工作流总结\n\n```\n┌─────────────────────────────────────────────────┐\n│ Layer 1: 自动化监控（每日） │\n│ 工具：OpenClaw / Manus │\n│ 输出：固定信源的新内容通知 │\n└──────────────────────┬──────────────────────────┘\n ↓ 有新内容时触发\n┌─────────────────────────────────────────────────┐\n│ Layer 2: 广度搜索（每 1-2 周） │\n│ 工具：ChatGPT Deep Research │\n│ 输入：Prompt A │\n│ 输出：5-10 篇文章 + 3-5 个项目的结构化摘要 │\n└──────────────────────┬──────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────┐\n│ Layer 3: 深度分析（按需） │\n│ 工具：Claude（本项目内） │\n│ 输入：Prompt B + ChatGPT 输出 │\n│ 输出：优先级排序 + 缺口分析 + 收录建议 │\n└──────────────────────┬──────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────┐\n│ Layer 4: 人工确认 │\n│ 你决定：收录 / 翻译 / 写分析 / 跳过 │\n└─────────────────────────────────────────────────┘\n```\n\n## 核心信源存量回扫（每批必做一步）\n\n> 教训来自 2026-07-21 批次：只按\"最近 2 周\"时间窗扫描，导致 4 篇 1–5 月的重量级官方件\n> （Cursor scaling-agents、Anthropic C compiler / how-we-contain / demystifying-evals）漏网数月。\n> 时间窗抓增量，回扫补存量——两者缺一不可。\n\n每轮调研除时间窗扫描外，**轮换抽取 1–2 个 Tier 1 信源，翻其全年归档目录**（archive / blog 列表页），\n对照 `references/articles.md`（含观察项表）逐条核对是否已收录或已甄别。优先轮换顺序：\n\n1. anthropic.com/engineering（工程博客，全量列表）\n2. cursor.com/blog（research 分类）\n3. openai.com/index（Engineering 分类）\n4. martinfowler.com/tags（GenAI 标签 + exploring-gen-ai 系列）\n5. langchain.com/blog、claude.com/blog、addyosmani.com/blog、simonwillison.net 月归档\n\n发现漏网存量时，与本批增量一起进「候选 × 定性 × 去向」评审表，注明\"存量补课\"。\n\n### 轮换记录\n\n| 批次 | 回扫信源 | 捞回的存量 |\n|------|---------|-----------|\n| 2026-07-21 | （教训来源，未做系统回扫） | 事后补收 #48 / #49 / #50 / #47 |\n| 2026-07-27 | ① anthropic.com/engineering 全量列表 ② cursor.com/blog 全量 slug 清单 | #58 Effective harnesses（2025-11）、#59 基础设施噪声（2026-02）、#60 持续改进 agent harness（2026-04）、#61 奖励作弊（2026-06）——四篇均为 harness 主题正中靶心却漏网数月 |\n| 2026-08-03 | ① openai.com/sitemap.xml/engineering 全量 URL+lastmod ② martinfowler.com/feed.atom（GenAI 归档） | 无漏网存量：OpenAI Engineering 分类的 harness 主题件（harness-engineering / unrolling / unlocking / symphony / windows-sandbox / core-dump / websockets / how-agents-transforming-work）均已在编号正文或观察项；其余 gpt-5.6 / atlas / sora-android / tax-agents / data-agent 为产品·基建，非 harness。Fowler 侧捞出的是增量而非存量（重构经济效益 / Conductor Developer / Fragments 07-21 / Orchestrator's Tax 草稿）——已进本批观察项 |\n| 2026-08-27 | ① langchain.com/blog sitemap 全量（507 slug）② claude.com/blog sitemap 全量（228 slug，去 locale 变体） | **非零星漏网而是系统性缺口**：langchain 相关约 115 篇/此前仅收 19（漏网详查 48，含 12 篇标题直接带 harness/loop 的核心文：improving-deep-agents-with-harness-engineering、better-harness、the-art-of-loop-engineering、deep-agents 开山文等）；claude.com 相关约 80/仅收 9（漏网详查 41：skills 全系列、subagent 系列、Lessons from building Claude Code 双篇等）。处置：不逐篇消化，观察项表加 2 个\"信源级\"合并行，完整清单留档 translate/2026-08-27/candidates.md。方法论教训：两站列表页对 curl 均不完整**必须走 sitemap.xml**；claude.com 的 lastmod 批量刷新不可作发布日期，需逐页取 JSON-LD datePublished |\n\n> 下一轮建议轮换：addyosmani.com/blog + simonwillison.net 月归档（个人博客侧尚未系统回扫过）；cursor.com/blog 可顺带复扫（本批已全量取 sitemap 115 slug 逐页核过日期，短期内干净）。openai.com/index 用 `curl https://openai.com/sitemap.xml/engineering/` 拿到带 lastmod 的全量 URL 最省事（2026-08-03 验证有效，比抓列表页首屏可靠）。\n> 回扫技巧（2026-07-27 验证有效）：列表页只渲染最近若干条时，直接抓 `curl |grep -oE '/blog/[a-z0-9-]+'|sort -u` 拿全量 slug，\n> 再逐个取 `datePublished` 与标题——Cursor 那四条里有两条（`continually-improving-agent-harness`、`reward-hacking-coding-benchmarks`）就是这样发现的，它们不在列表页首屏。\n","isInternal":false,"tokens":9009,"sizeBytes":26442}],"systemPromptSnippet":"\n\n# Harness Engineering 学习档案\n\n> 记录我学习「Harness Engineering」的完整过程：从概念理解到独立实践。\n>\n> 来源：[OpenAI — Harness Engineering: Harnessing Codex in an Agent-First World](https://openai.com/zh-Hans-CN/index/harness-engineering/)\n\n## 仓库结构\n\n| 目录 | 内容 | 说明 |\n|------|------|------|\n| `concepts/` | 概念笔记 | 原文核心概念的拆解与整理 |\n| `thinking/` | 独立思考 | 自己的理解、质疑、延伸思考 |\n| `practice/` | 动手实践 | 小项目实验，验证文章中的方法论 |\n| `feedback/` | 反馈记录 | 实践中的踩坑、修正、迭代心得 |\n| `works/` | 作品输出 | 可展示的成果（文章、工具、模板等） |\n| `tools/` | 工具具像化 | 降低 6 维复杂度的杠杆库（带主张，不是 awesome-list） |\n| `prompts/` | 提示词积累 | 学习过程中验证有效的提示词 |\n| `references/` | 外部资源 | 相关文章、仓库、工具的索引 |\n\n## 学习路线（进度）\n\n- [x] Phase 1：理解核心概念（concepts/，8 篇）\n- [x] Phase 2：形成自己的观点（thinking/，11 篇，持续中）\n- [x] Phase 3：选一个小项目实践（practice/，1 个 Ralph Demo）\n- [x] Phase 4：记录反馈迭代（feedback/，1 篇，持续中）\n- [x] Phase 5：输出可展示的作品（works/，40 篇翻译 + 1 篇原创 + 2 篇外部中文收录）\n\n> 进度详情以人类向 README.md 的\"学习路线\"段为准；本节是给智能体的快照。\n\n## 导航\n\n每个子目录都有自己的 AGENTS.md，说明该目录的用途、内容组织方式和写作约定。\n从任何一个目录开始，都能找到下一步该看什么。\n\n## 机械化检查\n\n`scripts/check-consistency.sh` 守护\"漂移\"问题：\n\n- **C1** — `references/articles.md` 编号 1..N 连续\n- **C2** — N 与下游 4 处声明同步（README badge × 2、`prompts/deep-research-tracker.md` 头部、`references/AGENTS.md` 概览）。文件含独立行 `` 时豁免\n- **C3** — `concepts/`、`thinking/`、`feedback/` 的 `*.md` 实际数与 README 中\"X 篇\"声明一致\n- **C4** — `works/*-translation.md` 文件数 ≡ 翻译计数所有声明（badges、`
` 摘要、Phase 5 注释、本文件 Phase 5 快照、READMEs 表格行数）\n- **C5** — README 结构树中 `concepts/` 子树的 item 行数 ≡ `concepts/*.md` 文件数（防止\"计数对了但树漏了\"）\n- **C6** — `references/articles.md` 末尾\"不计入 N 篇\"中的 N ≡ C1 权威值\n- **C7** — 三脉络 per-track 计数（脉络一/二/三）在 4 处下游声明保持一致：READMEs 资料库表、`references/AGENTS.md` 三脉络小标题、`prompts/deep-research-tracker.md` 三脉络明细\n- **C8** — 翻译流水线本地守卫：`translate/<...>/sources//source-full.md` 存在时，对应 `01-analysis.md` 不得再声称\"仅摘要页 / 建议补抓全文\"。`translate/` 已 gitignore，CI 与干净 clone 自动 SKIP，仅本地有过程稿时触发\n- **C9** — `concepts/` / `thinking/` / `feedback/` 正文不得裸写文库计数（\"N 篇文章 / N 篇翻译 / N 大概念\"）；历史性提法须带\"写作时点 / 当时 / 此前 / 首批 / 首轮 / 截至 / 快照\"限定词，否则去数字改链 `references/articles.md`\n- **C10** — 图片保真（纯本地、零网络）：每篇 `works/*-translation.md` 的 frontmatter 必须声明 `sourceFigureCount`（缺失即 FAIL；`null` = 原文不可得、未审计 → SKIP；数字 N → 正文嵌图数须 ≥ N），且所有本地嵌图路径（`imgs/...`）必须在磁盘上存在\n- **C11** — markdown 表格形状：README ×2、`references/AGENTS.md`、`references/articles.md`、`works/AGENTS.md` 里每一行表格的单元格数须与表头一致\n- **C12** — 条目字段完整性：`references/articles.md` 每个 `### N.` 编号条目必须带 **作者：** 与 **日期：** 字段\n- **C13** — 零插图声明须留痕：C10 只能证伪\"多报\"（嵌图数 < 声明数才 FAIL），因此 `sourceFigureCount: 0` 在本地**永远无法被证伪**——不管你有没有真去核对原文，它都是绿的。2026-07-27 就是这个洞放行了一个假 0（原文实有 4 张配图）。C10 刻意零网络、无法回查原文，所以改为要求留痕：**声明 0 的译文必须同时带 `sourceFigureAudit` 字段，值里要有 `YYYY-MM-DD` 核对日期**，写清怎么核对的、结论是什么。`null` 仍然 SKIP——它本来就自陈未审计\n- **C14** — 文档站防漂移：VitePress 站点（部署到 harness.dyu.sh）的侧边栏与首页统计一律由 `.vitepress/sidebar.mjs` 在构建时从文件系统生成，不手写。三条不变量：站点源码（`index.md`、`.vitepress/`）不得出现裸计数（\"N 篇\"），数字只能来自 `computeStats()`；每个一等内容文件必须在生成的侧边栏中恰好出现一次；仓库内禁止任何 symlink——Vite 会解引用 `public/` 下的软链、图片管线会读取链接目标，一条软链即可把仓库外文件带进公开产物（后两条经 `node .vitepress/sidebar.mjs --verify` 执行）。构建产物侧另有 `scripts/verify-dist.mjs` 断言页面与 `.md` 副本一一对应、副本链接可达、dist 无 symlink。站点脚手架不存在时 SKIP；node 不可用时 verify 半边 SKIP、裸计数 grep 照常执行\n\n执行：`bash scripts/check-consistency.sh`（仓库根目录）\n启用 pre-commit 阻断：`git config core.hooksPath .githooks`\n\n**CI 兜底**：`.github/workflows/consistency.yml` 在每次 push / PR 时跑同一脚本（不做路径过滤，保证必需检查总能上报）。job 显示名固定为 `consistency / check`——分支保护按 check run 名匹配必需检查，改名会让所有 PR 重新被 \"Expected\" 卡住。\n本地 hook 是开发反馈，CI 是合并门——两层独立，本地未启用 hook 不会绕过检查。\n\n\n# concepts/ — 概念笔记\n\n原文六大核心概念的拆解与整理 + 后续阅读引出的延伸概念。每个概念一个文件，按阅读顺序编号。\n\n## 文件约定\n\n- 文件名：`{编号}-{英文短名}.md`，如 `01-repo-as-source-of-truth.md`\n- `00-overview.md` 是总览，先读这个\n- **文件名编号 ≠ 概念编号**：文件名编号是阅读顺序；\"概念 N\"的编号以 `00-overview.md` / README 的六大核心概念清单为准（两处一致）\n\n## 概念编号 ↔ 文件对照表（引用时以此为准）\n\n| 概念编号 | 概念 | 文件 |\n|---------|------|------|\n| 概念 1 | 仓库即记录系统 | [01-repo-as-source-of-truth.md](01-repo-as-source-of-truth.md) |\n| 概念 2 | 地图而非手册 | [00-overview.md §2](00-overview.md#map-not-manual)（无独立文件） |\n| 概念 3 | 机械化执行 | [02-mechanical-enforcement.md](02-mechanical-enforcement.md) |\n| 概念 4 | 智能体可读性 | [04-agent-readability.md](04-agent-readability.md) |\n| 概念 5 | 吞吐量改变合并理念 | [05-throughput-changes-merge.md](05-throughput-changes-merge.md) |\n| 概念 6 | 熵管理 = 垃圾回收 | [03-entropy-and-garbage-collection.md](03-entropy-and-garbage-collection.md) |\n| 总纲 | 人类掌舵，智能体执行 | [00-overview.md 总纲节](00-overview.md)（不占概念编号） |\n| 延伸 | Harness 的精确定义 | [06-harness-definition.md](06-harness-definition.md)（不占概念编号） |\n| 延伸 | 约束即产品（Spec as Product） | [07-spec-as-product.md](07-spec-as-product.md)（不占概念编号） |\n\n**引用约定**：跨文件引用概念时，写概念名并链接到具体文件（如 `[机械化执行](../concepts/02-mechanical-enforcement.md)`）；如需带编号，编号必须取自本表，不要裸写\"概念 N\"让读者猜编号体系。\n\n### 结构（建议，非强制）\n\n早期文件（01–03）来自 OpenAI 单一原文，结构倾向于：核心要点 → 关键实践 / 方案。\n后期文件（04–06）已演化为多源综合（OpenAI + LangChain + HumanLayer + Fowler），允许加入：\n\n- \"来自其他文章的补充\" / \"来自 X 的补充\"：跨源对照\n- \"关键洞察\" / \"类比\" / \"哲学\"：作者层加工\n- 06 是定义综合型，结构（定义 → 组件清单 → 跨源对照）与前 5 篇不同，属于合法变体\n\n约束只有两条：\n1. 第一段说清楚这个概念**是什么**（无论叫\"原文要点\"还是\"核心思想\"还是\"问题\"）\n2. 跨源内容必须**标注来源**（哪篇文章、哪个作者）\n\n## 已有内容\n\n| 文件 | 概念 | 来源 |\n|------|------|------|\n| [00-overview.md](00-overview.md) | 六大核心概念总览 | OpenAI 原文 |\n| [01-repo-as-source-of-truth.md](01-repo-as-source-of-truth.md) | 仓库即记录系统 | OpenAI 原文 |\n| [02-mechanical-enforcement.md](02-mechanical-enforcement.md) | 机械化执行 | OpenAI 原文 |\n| [03-entropy-and-garbage-collection.md](03-entropy-and-garbage-collection.md) | 熵管理与垃圾回收 | OpenAI 原文 |\n| [04-agent-readability.md](04-agent-readability.md) | 智能体可读性 | OpenAI + LangChain + HumanLayer + Fowler |\n| [05-throughput-changes-merge.md](05-throughput-changes-merge.md) | 吞吐量改变合并理念 | OpenAI + HumanLayer + LangChain + Fowler |\n| [06-harness-definition.md](06-harness-definition.md) | Harness 的精确定义与组件清单 | LangChain + HumanLayer + Fowler |\n| [07-spec-as-product.md](07-spec-as-product.md) | 约束即产品（Spec as Product）| OpenAI Symphony + Fowler + HumanLayer + Meta-Harness |\n\n## 下一步\n\n读完概念后，去 [thinking/](../thinking/) 写你自己的理解和质疑。\n\n\n# feedback/ — 反馈记录\n\n实践中的踩坑、修正、迭代心得。把失败变成可复用的经验。\n\n## 文件约定\n\n- 文件名：`{日期}-{简述}.md`，如 `2026-03-24-agents-md-too-long.md`\n- 结构：问题描述 → 原因分析 → 解决方案 → 收获\n- 如果某个反馈导致了 prompts/ 或 concepts/ 的更新，交叉链接\n\n## 下一步\n\n反馈积累够了，去 [works/](../works/) 把经验提炼成可展示的作品。\n\n\n# practice/ — 动手实践\n\n选一个小项目，用 Harness Engineering 的方法论从零构建，验证原文中的经验。\n\n## 文件约定\n\n- 每个实验一个子目录，如 `practice/01-cli-tool/`\n- 每个实验包含：README.md（目标与方法）、AGENTS.md（给智能体的指导）、代码\n- 关键：人类只写提示词和约束，代码全部由智能体生成\n\n## 已有实验\n\n| 实验 | 验证的概念 | 结果 |\n|------|-----------|------|\n| [01-ralph-demo/](01-ralph-demo/) — Ralph Orchestrator 编排循环 | 帽子系统、背压门控、迭代循环、持久记忆 | 4 轮迭代完成 CLI word counter（321s / $0.31），7 项测试全绿；产物已归档可复验 |\n\n## 实验建议\n\n| 实验 | 验证的概念 | 复杂度 |\n|------|-----------|--------|\n| 用 Claude Code 生成一个 CLI 工具 | 仓库即记录系统 + AGENTS.md 设计 | ⭐ |\n| 为生成的代码写自定义 linter | 机械化执行 | ⭐⭐ |\n| 让智能体自己重构自己写的代码 | 熵管理与垃圾回收 | ⭐⭐⭐ |\n\n## 下一步\n\n实践中踩坑了？去 [feedback/](../feedback/) 记录下来。\n\n\n# prompts/ — 提示词积累\n\n学习过程中验证有效的提示词，按场景或工作流沉淀。**只收录亲测有效的，不收录未验证的。**\n\n## 文件形态（两种合法形式）\n\n### 形式 A：单条 Prompt（按场景命名）\n\n- 文件名：`{场景}.md`，如 `code-generation.md`、`code-review.md`\n- 必备字段：用途、提示词正文\n- 建议字段：效果评价（好/中/差）、改进记录、适用模型 / 不适用场景\n\n### 形式 B：Prompt 工作流（按工具链命名）\n\n- 文件名：`{工作流名称}.md`，如 `deep-research-tracker.md`\n- 必备字段：工作流目标、各步 Prompt 正文（A/B/C…）、链路图\n- 适合多模型 / 多步骤协作的场景（例如 ChatGPT Deep Research → Claude 深度分析 → 人工确认）\n\n## 场景分类参考\n\n| 场景 | 说明 |\n|------|------|\n| 项目初始化 | 让智能体生成仓库骨架、AGENTS.md、CI 配置 |\n| 代码生成 | 在架构约束下生成业务代码 |\n| 代码审查 | 智能体审查智能体生成的代码 |\n| 重构清理 | 熵管理 / 垃圾回收 |\n| 文档维护 | doc-gardening 智能体的提示词 |\n| 情报追踪 | 定期发现领域内新内容（见 deep-research-tracker.md） |\n\n## 已有内容\n\n| 文件 | 形态 | 用途 |\n|------|------|------|\n| [deep-research-tracker.md](deep-research-tracker.md) | 工作流 | 每 1–2 周追踪 Harness Engineering / AI 编程领域新内容 |\n\n## 下一步\n\n用了某条 Prompt 之后，把效果（好/中/差/翻车）记到 [feedback/](../feedback/)；\n积累到一定量再回到本目录补\"效果评价 / 改进记录\"。\n\n\n# references/ — 外部资源索引\n\n相关文章、仓库、工具的统一索引。这里是指针，不是内容本身。\n\n## 文件约定\n\n- 按主题分文件，如 `articles.md`、`repos.md`、`tools.md`\n- 每条记录包含：链接、一句话说明、与 Harness Engineering 的关联\n\n## 文章\n\n详见 [articles.md](articles.md) — 完整的文章索引，含三条脉络 **79 篇文章 + 1 项已跟踪产品** 的深度摘要。\n权威计数与编号规则以 `articles.md` 头部为准；本表是它的概览缓存。\n\n### 脉络一：AI 时代的 Harness Engineering（75 篇）\n\n| # | 文章 | 作者 | 核心贡献 |\n|---|------|------|---------|\n| 1 | [OpenAI 原文](https://openai.com/zh-Hans-CN/index/harness-engineering/) | Ryan Lopopolo | 原点：六大概念 |\n| 2 | [Martin Fowler](https://martinfowler.com/articles/harness-engineering.html) | Birgitta Böckeler | Guides×Sensors 控制论框架 + Harnessability + Ashby 定律 |\n| 3 | [LangChain](https://blog.langchain.com/the-anatomy-of-an-agent-harness/) | Vivek Trivedy | 精确定义 + 组件清单 |\n| 4 | [Anthropic](https://www.anthropic.com/engineering/harness-design-long-running-apps) | Prithvi Rajasekaran | GAN 三智能体 + Harness 瘦身 |\n| 5 | [HumanLayer](https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents) | Kyle | 六个杠杆 + 实战避坑 |\n| 6 | [Anthropic/Claude Platform](https://claude.com/blog/harnessing-claudes-intelligence) | Lance Martin | 三大构建模式 + BrowseComp 数据 |\n| 7 | [Anthropic/Managed Agents](https://www.anthropic.com/engineering/managed-agents) | Lance Martin 等 | Meta-harness + 基础设施解耦 |\n| 8 | [Fowler/Encoding Team Standards](https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html) | Rahul Garg | 团队标准显式化三层路径 |\n| 9 | [Fowler/Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html) | Rahul Garg | 从 AI 失败中持续学习的反馈闭环 |\n| 10 | [LangChain/Agent Evaluation Checklist](https://blog.langchain.com/agent-evaluation-readiness-checklist/) | LangChain 团队 | 智能体评估五阶段清单 |\n| 11 | [Meta-Harness 论文](https://arxiv.org/abs/2603.28052) | Yoonho Lee 等 (Stanford) | 自动化 Harness 搜索优化 |\n| 12 | [GitHub/Agent-driven Development](https://github.blog/ai-and-ml/github-copilot/agent-driven-development-in-copilot-applied-science/) | Tyler McGoffin | 智能体驱动开发实战 |\n| 13 | [Inside the Scaffold 论文](https://arxiv.org/html/2604.03515v1) | Benjamin Rombaut (Huawei) | 13 个编码智能体脚手架源代码分类法 |\n| 14 | ⭐ [Eight years of wanting](https://lalitm.com/post/building-syntaqlite-ai/) | Lalit Maganti | AI 构建真实项目的坦诚复盘 |\n| 15 | [Continual learning for AI agents](https://blog.langchain.com/continual-learning-for-ai-agents/) | Harrison Chase | 三层学习：模型/Harness/上下文 |\n| 16 | [OpenAI Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/) | Kotliarskyi 等 | 任务跟踪器作为控制平面 + SPEC/WORKFLOW 即产品 |\n| 17 | [Claude Code Architecture](https://vrungta.substack.com/p/claude-code-architecture-reverse) | Vikash Rungta | Claude Code 运行外壳、TAOR 循环、工具原语、权限与上下文管理的外部逆向分析 |\n| 18 | [Harness 系列文章之 7：关于 subagent](https://x.com/dongxi_nlp/status/2068922428516892998) | 马东锡 NLP | Subagent = tool call 入口 + child runtime；区分 session/context/subagent 与 evidence 回流 |\n| 19 | [Fowler/Maintainability sensors](https://martinfowler.com/articles/sensors-for-coding-agents.html) | Birgitta Böckeler | 计算性 vs 推理性传感器谱系 + 失败案例 + AI 评审作为垃圾回收 |\n| 20 | [Fowler/SPDD](https://martinfowler.com/articles/structured-prompt-driven/) | Wei Zhang, Jessie Jie Xia | REASONS Canvas 七维 + prompt 即一等交付物 + 双向闭环 |\n| 21 | [LangChain/ADLC](https://www.langchain.com/blog/the-agent-development-lifecycle) | Harrison Chase | 智能体开发生命周期 + framework/runtime/harness 三分类 |\n| 22 | [LangChain/Interpreters in Deep Agents](https://www.langchain.com/blog/give-your-agents-an-interpreter) | Hunter Lovell | interpreter 是第三类上下文表面 + 35% token 节省 |\n| 23 | [Anthropic/质量回归复盘](https://www.anthropic.com/engineering/april-23-postmortem) | Anthropic 工程团队 | 三起独立变更叠加成质量退化 + 变更治理清单（第一手反例） |\n| 24 | [Agentic Harness Engineering 论文](https://arxiv.org/html/2604.25850v4) | Jiahang Lin 等（复旦/北大/奇绩） | 可观测性驱动的 Harness 自动演化 + 每次编辑即可证伪契约 |\n| 25 | [Overeager Coding Agents 论文](https://arxiv.org/html/2605.18583v1) | Yubin Qu 等 | 越界动作测量 + 提示声明授权反而降低边界推断 |\n| 26 | [How I Use AI to Code](https://chrismdp.com/coding-with-ai/) | Chris Parsons | 四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈 |\n| 27 | [How we built LangSmith Engine](https://www.langchain.com/blog/how-we-built-langsmith-engine-our-agent-for-improving-agents) | Palash Shah | 用智能体改进智能体 + trace→轨迹骨架 + screener/investigator 两阶段闭环 |\n| 28 | [Ralph 原始文章 + 续篇](https://ghuntley.com/ralph/) | Geoffrey Huntley | Ralph = bash 循环 + 每轮干净上下文 + 背压；单体反多智能体论（还上 practice/ Ralph Demo 的理论债） |\n| 29 | [My AI Adoption Journey](https://mitchellh.com/writing/my-ai-adoption-journey) | Mitchell Hashimoto | 六步采纳路线 + \"harness engineering\" 命名出处（由延伸阅读升格） |\n| 30 | [Claude Code 源码泄漏事件](https://github.com/pankaj28843/understanding-claude-code) | Chaofan Shou 发现 / 社区聚合分析 | 512K 行 harness 实锤解剖：QueryEngine/60+ 门控工具/KAIROS/AutoDream，#17 推测的对照组 |\n| 31 | [Agent Harness Engineering](https://addyosmani.com/blog/agent-harness-engineering/) | Addy Osmani | 学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS（综述破例进编号正文） |\n| 32 | [Exploring AI coding sensors](https://www.thoughtworks.com/en-au/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors) | Böckeler & Ford | 有/无传感器对照实验 + 态势感知论 + harness 模板展望 |\n| 33 | [HarnessAudit 论文](https://arxiv.org/abs/2605.14271) | Chengzhi Liu 等 | harness 安全审计：中途轨迹违规是输出级评估的盲区 + 210 任务基准 |\n| 34 | [Harness-Bench 论文](https://arxiv.org/abs/2605.27922) | Yilun Yao 等 | 配置级 harness 效应测量（106 任务/5194 轨迹）+ 执行对齐失败分类 |\n| 35 | [How good is your harness? 论文](https://openreview.net/forum?id=QI8z3skBwt) | Jiwoo Han, Yuekai Sun | Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应，且效应异质 |\n| 36 | [Dynamic workflows in Claude Code](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code) | Anthropic / Claude | 模型现场写自己的编排 harness + 对抗验证 + workflow 沉淀为 Skill |\n| 37 | [Harness 才是产品](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/) | 马东锡 NLP | \"Model 在 loop 里，harness 拥有 loop\" + 六组件 + 症状→组件 debug 对照表 |\n| 38 | [Position: 基准错位论文](https://arxiv.org/abs/2606.17799) | Maria I. Gorinova 等 | 基准把 model/harness/环境折叠进一个分数的三症状诊断 |\n| 39 | [Unrolling the Codex agent loop](https://openai.com/index/unrolling-the-codex-agent-loop/) | Michael Bolin (OpenAI) | Codex harness 解剖·上：prompt 构造 / 二次方问题与 prompt caching / compaction 端点化 |\n| 40 | [Unlocking the Codex harness](https://openai.com/index/unlocking-the-codex-harness/) | Celia Chen (OpenAI) | Codex harness 解剖·下：App Server 双向 JSON-RPC + Item/Turn/Thread 原语 + HaaS 落地 |\n| 41 | [Loop Engineering](https://addyosmani.com/blog/loop-engineering/) | Addy Osmani | loop 定调文：五构件 + 记忆脊柱；\"循环分不出两种用法的区别，你分得出\" |\n| 42 | [The Coming Loop](https://lucumr.pocoo.org/2026/6/23/the-coming-loop/) | Armin Ronacher | 怀疑派回应：agent loop vs harness loop + 防御式编码放大 + 软件作为有机体 |\n| 43 | [Loop engineering: Getting started with loops](https://claude.com/blog/getting-started-with-loops) | Claude Code 团队 | 官方四类循环（turn/goal/time/proactive）+ `/goal` 独立判停 + 用量治理清单 |\n| 44 | [Self-Harness 论文](https://arxiv.org/abs/2606.09498) | Hangfan Zhang 等 | 智能体自改 harness：弱点挖掘→提议→回归验证；三模型 held-out +14~21pp |\n| 45 | [Harness Engineering for Self-Improvement](https://lilianweng.github.io/posts/2026-07-04-harness/) | Lilian Weng | RSI 综述：三设计模式 + 优化对象递进链 + 七项未来挑战 + \"harness 终将内化\"预测 |\n| 46 | [Aria：自动软件验证论文](https://arxiv.org/abs/2607.06341) | Shuangxiang Kan 等 | 行为 harness 极限形态：声明式 HHL 包裹通用智能体做 Coq 证明，全引理零人工通过 |\n| 47 | [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) | Mikaela Grace 等 (Anthropic) | 智能体评测官方方法论：outcome≠transcript、pass@k/pass^k、评结果不评路径、CORE-Bench 42%→95% 基准病理 |\n| 48 | [Scaling long-running autonomous coding](https://cursor.com/blog/scaling-agents) | Wilson Lin (Cursor) | 数百并发智能体 × 数周：扁平自协调失败史 → planner/worker/judge；FastRender 百万行浏览器 |\n| 49 | [Building a C compiler with parallel Claudes](https://www.anthropic.com/engineering/building-c-compiler) | Nicholas Carlini (Anthropic) | 16 agent 无编排者造 10 万行 C 编译器（$20k/两周）：近乎完美验证器 + GCC oracle + 为 Claude 写测试 |\n| 50 | [How we contain Claude across products](https://www.anthropic.com/engineering/how-we-contain-claude) | Max McGuinness 等 (Anthropic) | 三隔离模式 × 五起漏掉的风险：白名单是能力授予；先环境层遏制再模型层引导 |\n| 51 | [Deep Agents 动态子智能体 + RLM](https://www.langchain.com/blog/introducing-dynamic-subagents-in-deep-agents) | LangChain 团队 | 模型写编排脚本驱动 subagent（QuickJS + `task()`）；RLM 处理超上下文两个数量级的输入 |\n| 52 | [Böckeler 本地模型双备忘录](https://martinfowler.com/articles/exploring-gen-ai/local-models-for-coding-factors.html) | Birgitta Böckeler | 高端开发机跑本地小模型做智能体编码实测：Qwen3.6 35B MoE 甜点、工具调用是分水岭 |\n| 53 | [Harness Handbook 论文](https://arxiv.org/abs/2607.13285) | Ruhan Wang 等（腾讯等） | 行为定位是 harness 演化瓶颈：行为中心表示 + BGPD，win rate +10.0/+18.9pp 且省 12.7%/8.6% token |\n| 54 | [DSLs Enable Reliable Use of LLMs](https://martinfowler.com/articles/llm-and-dsls.html) | Unmesh Joshi | \"DSL 工具集本身就是出色的 harness\"：语言层约束 + 确定性验证器 + 领域级错误反馈 |\n| 55 | [Own the Outer Loop](https://addyosmani.com/blog/own-the-outer-loop/) | Addy Osmani | 智能体跑内环、工程师拥有外环问责；back-pressure 调节循环速率与作用域来授予自主权 |\n| 56 | [Rewriting Bun in Rust](https://bun.sh/blog/bun-in-rust) | Jarred Sumner | \"修流程不修代码\"工业级实录：50 dynamic workflows × 64 Claude × 11 天移植 53.5 万行 Zig；语言无关测试套件作 oracle + 对抗评审默认化 |\n| 57 | [HarnessX 论文](https://arxiv.org/abs/2606.14249) | Darwin Agent Team（小米） | harness 一等类型化对象 + AEGIS 轨迹演化 + cross-harness GRPO 共演化：+14.5%（共演化再 +4.7%），弱模型受益最大 |\n| 58 | [Anthropic/长时智能体的有效 harness](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) | Justin Young | 外部工件即记忆的奠基文：initializer + coding 两段式、200+ 条 feature_list.json、progress 文件 + git、Puppeteer 端到端自验（存量回扫补录） |\n| 59 | [Anthropic/基础设施噪声](https://www.anthropic.com/engineering/infrastructure-noise) | Gian Segato | 只改资源配额，Terminal-Bench 2.0 摆动 6pp；1x–3x 修可靠性、3x 以上改变被测对象；\"低于 3pp 的榜单差距都该怀疑\" |\n| 60 | [Cursor/持续改进 agent harness](https://cursor.com/blog/continually-improving-agent-harness) | Stefan Heule & Jediah Katz | harness 运维的度量学：Keep Rate、LLM 读用户回复判满意、错误分类与按工具按模型基线、每周 Automation 修 harness；按训练分布供给工具格式 |\n| 61 | [Cursor/奖励作弊淹没智能增益](https://cursor.com/blog/reward-hacking-coding-benchmarks) | Naman Jain | 审计 731 条轨迹：SWE-bench Pro 上 63% 的成功解是检索答案而非推导；封 git+断网后 Opus 4.8 Max 87.1%→73.0% |\n| 62 | [Better Models: Worse Tools](https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/) | Armin Ronacher | 工具 schema 不是中立的：在宽容 harness 里做 RL，新模型对替代 schema 反而更差；跨模型可移植性的机制级坏消息 |\n| 63 | [为什么软件工厂会失败](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md) | Dex Horthy (HumanLayer) | \"harness engineering 还不够\"：可维护性没有快 oracle，RL 不惩罚坏设计；熄灯工厂第一手失败实录 + 四阶段前移方案 |\n| 64 | [Software Factories, Light and Dark](https://addyosmani.com/blog/software-factories/) | Addy Osmani | loop→harness→factory 三层 + 唯一昂贵的评审闸门 + 背压规则 + \"什么样的循环配得上熄灯\"准入清单 |\n| 65 | [智能体蜂群与新的模型经济学](https://cursor.com/blog/agent-swarm-model-economics) | Wilson Lin (Cursor) | 从 835 页手册重造 SQLite：质量趋同、账单从 $1,339 到 $10,565；规划/执行分层、自建 VCS（1000 提交/秒）、去相关评审、Field Guide |\n| 66 | [Claude 5 世代的上下文工程新规则](https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models) | Thariq Shihipar (Anthropic) | 删掉 Claude Code 系统提示词 80%+ 而编码评测无可测损失；七组 then/now 对照 + `claude doctor` |\n| 67 | [Don't Blame the LLM 论文](https://arxiv.org/abs/2607.03691) | Oussama Ben Sghaier 等（Queen's） | 首个固定模型、只变 harness 的受控纵向研究：Qwen Code CLI 35 个连续版本 × 50 个 SWE-bench Verified 任务 |\n| 68 | [Rethinking Harness Evolution 论文](https://arxiv.org/abs/2607.12227) | Yike Wang 等 | 自动 harness 演化的第一份系统性负面结果：同等预算下不稳定优于简单 test-time scaling，泛化有限 |\n| 69 | [LangChain/Harbor 评测栈](https://www.langchain.com/blog/how-we-benchmark-deep-agents) | Nick Hollon, Harrison Chase 等 | 给 harness 建标尺（Harbor-Index 82 任务 / lite 子集 / capability suite），再给标尺建标尺（IssueBench 15 类失败分类法） |\n| 70 | [LangChain/ReviewBench](https://www.langchain.com/blog/evaluating-code-review-agents-with-reviewbench) | Nick Hollon | 给\"AI 代码评审\"传感器造考卷：真实 PR 评审意见策展成 59 任务；裸 harness 最强召回 ~30%，prompt-only 调优 0.13→0.32 反超 |\n| 71 | [Fowler/TDD in the agent loop](https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html) | Birgitta Böckeler | agent loop 内 TDD 的实证否定：盲评质量无差异、token 3–8.5 倍；别规定过程，度量结果 |\n| 72 | [Osmani/Practical Loop Engineering](https://addyosmani.com/blog/practical-loop-engineering/) | Addy Osmani | loop 系列日常落地环：踩坑实录（差点连判断也委托）+ 分诊循环 + fine print 运维细则 |\n| 73 | [Zalando 组织级快照](https://engineering.zalando.com/posts/2026/08/agentic-engineering-at-zalando-a-snapshot.html) | Bartosz Ocytko | 250+ 团队非供应商第一人称：事故分析→风险分级→33% 自动放行→lead time -20~40% 的组织级反馈回路 |\n| 74 | [Earendil/Pi 双篇](https://earendil.com/posts/what-is-a-harness/) | Pi 团队 | harness 定义+用户侧中立主张 / compaction 白盒实现（20K 预算、独立请求、纯文本可移植）——与 #39 端点化恰成对照 |\n| 75 | [⭐ StarHarness 论文](https://arxiv.org/abs/2608.24804) | ServiceNow/Mila | 冻结 harness 工件跨 GPT/Qwen 迁移 12 行全正（+10.7~+46.3pp）；跨模型可移植性缺口首个正面证据 |\n\n### 脉络二：云原生 Harness.io（2 篇）\n\n| # | 文章 | 核心贡献 |\n|---|------|---------|\n| 76 | [Harness.io 官方](https://www.harness.io/blog/understanding-ci-cd-platforms-the-backbone-of-modern-devops) | CI/CD 平台全局架构 |\n| 77 | [Google Cloud Architecture](https://docs.cloud.google.com/architecture/partners/harness-cicd-pipeline-for-rag-app) | Harness + GCP 部署 RAG |\n\n### 脉络三：效率悖论与能力进化（2 篇）\n\n| # | 文章 | 核心贡献 |\n|---|------|---------|\n| 78 | [YDD / Miss-you](https://yousali.com/posts/20260303-ai-coding-efficiency-to-evolution/) | 效率悖论的系统性拆解：约束理论 + Spec/Rule/Skill + 验证闭环 + 并发 |\n| 79 | [METR 实验后续 + 自报调查](https://metr.org/blog/2026-02-24-uplift-update/) | \"慢 19%\" 的官方后续：弱证据转向加速 + AI 渗透破坏 RCT 可行性本身 |\n\n### 已跟踪产品 / 项目（不计入文章数）\n\n| 项 | 项目 | 说明 |\n|---|------|------|\n| ⭐ | [Chachamaru127 / claude-code-harness v4.2 \"Hokage\"](https://github.com/Chachamaru127/claude-code-harness/tree/v4.2.0) | Claude Code 上当下最完整的开源 harness 实现之一；Plan→Work→Review→Release 五动词 + Go 原生 R01–R13 guardrail。本仓库分析见 `thinking/guides-sensors-meets-claude-code-harness.md` |\n\n## 项目\n\n### Ralph 系列\n\n| 项目 | Stars | 说明 | 关联概念 |\n|------|-------|------|---------|\n| [snarktank/ralph](https://github.com/snarktank/ralph) | 13.6k | 原版 Ralph 循环：bash + PRD + 每次清空上下文 | 全部六大概念的最小实现 |\n| [ralph-orchestrator](https://mikeyobrien.github.io/ralph-orchestrator/) | 2.3k | Rust 版：Hat 角色 + 事件驱动 + 背压 | 机械化执行、熵管理 |\n| [bmad-ralph](https://github.com/qianxiaofeng/bmad-ralph) | 2 | BMAD + Ralph：并行 worktree + 三层自愈 | 自主水平提升、吞吐量 |\n\n### 社区\n\n| 资源 | 说明 | 关联 |\n|------|------|------|\n| [vibe-coding-cn](https://github.com/tukuaiai/vibe-coding-cn) | 中文 Vibe Coding 社区 | 仓库组织方式、AGENTS.md 分级 |\n\n### 延伸阅读\n\n| 资源 | 说明 |\n|------|------|\n| [Martin Fowler: Context Engineering for Coding Agents](https://martinfowler.com/articles/context-engineering-coding-agents.html) | Context Engineering 专题 |\n| [Martin Fowler: Humans and Agents in SE Loops](https://martinfowler.com/articles/humans-and-agents.html) | 人类与智能体的协作模式 |\n\n> Mitchell Hashimoto 的 My AI Adoption Journey 原在此表，2026-07 已升格为编号条目 #29。\n\n## 待补充\n\n> 占位条目统一收在这里，**不进 `articles.md` 的编号正文**，避免污染文章计数。\n\n- [x] Geoffrey Huntley 的 Ralph 原始文章 → 已收录为 #28（2026-07）\n- [x] OpenAI Codex harness 解剖二部曲 → 已收录为 #39（Unrolling the Codex agent loop）+ #40（Unlocking the Codex harness / App Server）（2026-07-15）\n- [ ] 马东锡 Harness 系列其余篇目（仓库已收 #18 之 7、#37 才是产品；2026-07 系列新帖包括\"Model 可以请求，Harness 负责裁决——这就是契约\"\"模型记住的是 transcript，Harness 必须记住 truth（File State 是合格 harness 的基本功）\"；X 原帖需本地工具抓取）\n- [ ] Medium 实战专栏 — \"Beyond Migration: How We Engineered a Secure & Intelligent Delivery Platform with Harness CICD\"（标题可能已变更或文章已下架）\n\n## 下一步\n\n读完一篇资料后：\n- 想对它的论点做独立分析或质疑 → [thinking/](../thinking/)\n- 想翻译为中文输出 → [works/](../works/)\n- 想用它的方法做实验 → [practice/](../practice/)\n- 想沉淀其中的提示词模板 → [prompts/](../prompts/)\n\n\n# thinking/ — 独立思考\n\n读完 concepts/ 后，在这里写下你自己的理解、质疑和延伸思考。\n\n## 文件约定\n\n- 文件名：自由命名，建议用问题或论点作为文件名\n- 例如：`harness-vs-vibe-coding.md`、`is-this-only-for-openai.md`\n- 结构：问题/论点 → 自己的分析 → 结论或开放问题\n- 鼓励质疑原文，提出反例\n\n## 已有文章\n\n| 文件 | 主题 | 核心论点 |\n|------|------|---------|\n| [cross-article-insights.md](cross-article-insights.md) | 跨文章深层洞见 | 8 个洞见：Harness 生命周期、四学派、评估之踵、人类角色消解 |\n| [harnessability-and-java.md](harnessability-and-java.md) | Java 的可驾驭性 | Java/Spring 天然提供高 Harnessability 基线 |\n| [meta-harness-tensions.md](meta-harness-tensions.md) | Meta-Harness 的五个张力 | Anthropic Managed Agents 与既有实践的矛盾 |\n| [evaluation-elephant-in-the-room.md](evaluation-elephant-in-the-room.md) | 评估是房间里的大象 | 行为正确性验证是整个体系的阿喀琉斯之踵 |\n| [harness-for-solo-developers.md](harness-for-solo-developers.md) | 个人开发者的 Harness | 六大概念的适用性分析：直接可用 vs 需要降级 vs 不适用 |\n| [guides-sensors-meets-claude-code-harness.md](guides-sensors-meets-claude-code-harness.md) | Böckeler 框架 vs claude-code-harness v4.2 | 产品级实现暴露的五个张力：Advisor 装不进 2×2、guardrail 融合前馈反馈、行为 Harness 是结构性绕过、追上游占 95% 维护成本、harness 必带价值观锁定 |\n| [software-project-complexity-in-the-ai-era.md](software-project-complexity-in-the-ai-era.md) | AI 时代的软件项目复杂度 | 6 维（上下文压力 / 可提示性 / 探索收敛 / 状态纠缠 / 暗知识 / 验证成本）+ 胶囊化分母 + 重构/复刻终局指标 |\n| [subagent-is-child-runtime.md](subagent-is-child-runtime.md) | Subagent 是 child runtime | 与 Claude Code 架构逆向互证：subagent = tool-call-triggered child session + context projection + evidence-return contract |\n| [why-this-project-exists.md](why-this-project-exists.md) | 为什么有这个项目 | 项目宗旨：把 Harness Engineering 从\"概念集合\"变成\"可复刻的产品构建方法论\"——借用《诡秘之主》\"学徒途径\"隐喻 |\n| [fix-the-process-not-the-code.md](fix-the-process-not-the-code.md) | 修流程，不修代码 | Bun 重写案例对照 #36/#49/#55：工程师的交付物是生成过程本身；测试套件与实现语言正交是 Harnessability 新维度；验证器完备度决定成本曲线 |\n| [se-to-agent-engineering-mapping.md](se-to-agent-engineering-mapping.md) | 传统 SE ↔ Agent 工程对照表 | 15 行同构映射的三处修正：右列主语混三层（①人对 agent ②agent 自身 ③人对系统）、补熵管理/并发合并/持久会话三行、版本钉选风险倒置与评估地位跃迁；每个模型代际重审一遍，纹丝不动的子集才是学科骨架 |\n\n## 写作方向参考\n\n- 机械化执行的边界在哪？过度 lint 是否会限制智能体创造性？\n- Harness Engineering vs Vibe Coding：本质区别是什么？\n- \"零手写代码\"是刻意的实验约束，还是可推广的工程实践？\n- Context Engineering vs Harness Engineering：边界与关系\n\n## 下一步\n\n有了自己的观点后，去 [practice/](../practice/) 用实验验证它。\n\n\n# tools/ — 工具具像化\n\n把 `concepts/` 里抽象的 Harness 概念落到具体可用的工具上。\n本目录的核心问题：**哪些工具能切实降低 [6 维复杂度框架](../thinking/software-project-complexity-in-the-ai-era.md) 中的某一维，或提升\"胶囊化能力\"这个总杠杆？**\n\n## 文件约定\n\n- `00-overview.md` — 工具地图：维度 × 工具矩阵（先读）\n- `harnesses/` — Agent harness 框架（首篇：[ralph-orchestrator.md](harnesses/ralph-orchestrator.md)；Claude Code、Codex、Cursor 等待写）\n- `auxiliary/` — 辅助工具（linter、CI、文档、测试、依赖分析等）；**规划中**，首篇辅助工具页落地时再建目录\n\n每个工具页结构（建议，非强制）：\n\n1. **一句话定位** —— 它是什么\n2. **降低哪些维度的复杂度** —— 引用 6 维框架的具体维度名 + 是否提升\"胶囊化能力\"\n3. **实测体验** —— 用过的真实场景、生效边界、失效场景\n4. **搭配建议** —— 与本目录其他工具的组合\n5. **替代方案** —— 同类竞品对比（如有）\n\n## 收录标准\n\n- **自己实际用过** —— 不收\"听说很好\"的工具\n- 或在 [`practice/`](../practice/) 中验证过\n- 拒绝\"工具大全\"式罗列——本目录不是 awesome-list，是带主张的杠杆库\n\n## 与其他目录的关系\n\n- `concepts/` 提出**该做什么**\n- `tools/` 提供**用什么做**\n- `practice/` 给出**实际做的过程与结果**\n\n## 下一步\n\n读完 [00-overview.md](00-overview.md) 后，按维度反查工具，按工具反查实践。\n\n\n# works - AI Agent Protocol & Instructions\n\nPath: `works/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/works/AGENTS.md)\n\n\n---\nname: curate-research\ndescription: 把一批 Harness Engineering 调研候选（文章/论文/工具的 URL）走完「抓取→翻译→评审→收录→清理」流水线，整合进本仓库 works/ 与 references/articles.md，并保持 C1–C13 一致性检查全绿。当用户说\"处理这批调研候选 / 收录这些链接 / 整理 translate / 把这几篇翻译收进来\"时使用。这是仓库给自己用的策展 harness。\n---\n\n# curate-research —— 仓库自我策展 harness\n\n> 一个讲 Harness Engineering 的仓库，用一个 harness 来策展自己。本 skill 把外部调研候选可控地整合进 tracked 档案。\n>\n> **核心约束：评审全自动；收录是人类闸门，必须停下来和用户来回讨论后才动 `works/` 与 `articles.md`。**\n\n## 何时用\n\n- 用户给出一批候选 URL（文章 / 论文 / 工具 / 项目），希望整合进仓库\n- 用户说「处理 / 收录 / 整理」`translate/` 暂存区的翻译\n- 已有 `translate//works-ready/` 候选译文，要决定去向\n\n## 输入与产物路径\n\n暂存区（gitignored，本地过程区）：`translate//`\n- `sources//source.md`（原文快照；论文额外抓 `source-full.md`）\n- `translations//{01-analysis,02-prompt,translation}.md`（过程三件套）\n- `works-ready/-translation.md`（发布候选）+ `works-ready/README.md`（状态表，本批权威）\n\n正式档案（tracked）：`works/-translation.md` + `references/articles.md` 条目。\n\n## 流水线 6 阶段\n\n```\n①抓取 ──②翻译 ──③评审[全自动] ──🚧人类闸门🚧──④收录 ──⑤校验 ──⑥清理\n```\n\n### ① 抓取\n用 `baoyu-url-to-markdown` 把每个 URL 存到 `sources//source.md`。**论文/长文必须额外抓 HTML 全文到 `source-full.md`**（否则只有摘要页，C8 会拦谎报）。\n\n### ② 翻译\n按 baoyu-translate 配置生成 `translations//` 三件套 → `works-ready/-translation.md`。`01-analysis.md` 要含收录建议；`source-full.md` 存在时，分析稿不得声称「仅摘要页」。\n\n### ③ 评审（全自动并行扇出）\n对每篇候选派一个评审 agent（一批 3–4 篇，并行多个 agent）。统一打分维度，吐结构化定性。**标准评审 prompt 模板：**\n\n> 你是 Harness Engineering 中文知识库的内容评审。仓库主题：人类设计约束与反馈回路、AI agent 写代码。\n> 读 `sources//source.md`(+`source-full.md`)、`works-ready/-translation.md`、`translations//01-analysis.md`，逐篇回答：\n> - **原文价值**：原创洞察密度 / 长文实质 vs 产品页·发布稿·摘要。高/中/低\n> - **翻译质量**：完整逐译 / 压缩摘要 / 首轮粗稿；通顺度、术语到位度。精品/合格/需返工\n> - **与仓库契合度**：补薄弱环节还是重复\n> - **一句话定性 + 建议去向**：works/ 正式收录 / articles.md 观察项一行 / tools/ / 暂不收录\n> 基于实际内容，紧凑中文，结构化输出即为最终产出。\n\n汇总成一张「候选 × 定性 × 去向」表。\n\n### 🚧 人类闸门（不可跳过）\n把评审表交给用户，**来回讨论收录决策**。精品 vs 边角的边界判断、是否返工、哪些合并成专题——都由人定。**未经用户确认，不得进入 ④。**\n\n### ④ 收录（按减熵分流规则）\n- **实质原创长文 / 论文 → `works/`**：`cp` 到 `works/-translation.md`，在 `articles.md` 加一个 `### N.` 编号条目（脉络一末尾，旧编号顺移），并**同步全部计数缓存**（见下）。\n- **边角材料**（产品页 / README / 发布稿 / 短 bliki）**→ articles.md「观察项 / 候选材料（不计入文章数）」表一行**，链上游 URL，不做编号条目（文章数不变）。\n- **工具类 → 只在用户实际用过后才进 `tools/`**；未实测前在观察项表标 🔵「待实测后入 tools/」。\n- **需返工的长文**：先润色（事实核查加译者注 / 术语统一）再进 `works/`。\n\n**入库前 checklist（每篇 works/ 候选必过，再进 ⑤）：**\n- [ ] frontmatter 声明 `sourceFigureCount` 并与原文实际图数核对（null = 原文不可得、未审计）；原文插图下载入 `works/imgs//` 本地嵌入——C10 校验嵌图数 ≥ 声明数、本地路径文件存在\n- [ ] **数图要抓原文 HTML 数，不能只看渲染出来的正文。** 2026-07-27 的教训：一篇 claude.com 译文声明 `sourceFigureCount: 0`，而原文 HTML 里有 4 个 `
`——抓取工具吐出的 markdown 把它们丢了，人只看那份 markdown 就会以为没有图。可用 `curl | grep -c '-translation.md`（works/ 是权威源）。\n- 删已收录 slug 的 `sources//` + `translations//`（过程稿，works/ 已留最终版）。\n- **保留**：观察项 slug 的全部译文（articles.md 标明「留作阅读辅助」）+ 状态 README。\n- 更新 `works-ready/README.md` 状态表。`translate/` 是 gitignored，清理仅本地。\n\n## 计数同步清单（④ 的硬要求）\n\n`references/articles.md` 是文章数与编号的**唯一权威源**。每加一个 `### N.` 条目，必须同次更新所有下游缓存，否则 `check-consistency.sh` 报错：\n- README.md / README.en.md：`articles-N` badge、`translations-N` badge、目录树、脉络表（脉络一计数）、翻译 `
` 摘要数、翻译表格行、Phase 5 提及\n- references/AGENTS.md：概览「N 篇文章」、脉络一小标题计数、文章表加行\n- prompts/deep-research-tracker.md：「核心文章 N 篇」、脉络一计数、去重清单加行\n- AGENTS.md：Phase 5 快照「N 篇翻译」\n- works/AGENTS.md：翻译表加行\n- articles.md 自身：header「N 篇（脉络一 …）」、两处「不计入 N 篇」\n- **观察项一行不触发以上**（不计入 N，无 `### N.` 编号）——这是减熵分流的关键收益。\n\n## 相关\n- 减熵分流约定：即上文「④ 收录」的分流规则——实质长文进 `works/` 编号正文；边角材料只进观察项表（不计数、不触发计数同步）；工具未实测不进 `tools/`。原则：每条新收录都要问\"它增加的检索价值是否大于它增加的维护熵\"\n- C8 lint：`source-full.md` 存在时禁止 analysis 谎报摘要页（`scripts/check-consistency.sh`）\n- C9 lint：`concepts/` / `thinking/` / `feedback/` 正文禁止裸写文库计数（历史提法须带\"写作时点/当时/此前/首批/首轮/截至/快照\"限定词）\n- C10/C11/C12 lint：图片保真（`sourceFigureCount` vs 正文嵌图数 + 本地嵌图路径存在）/ markdown 表格列数与表头一致 / articles.md 编号条目必含 **作者：**/**日期：** 字段（同上脚本）\n- C13 lint：`sourceFigureCount: 0` 必须配 `sourceFigureAudit`（含核对日期）。这条是补 C10 的结构性盲区——C10 的判据是\"嵌图数 < 声明数才 FAIL\"，所以 0 永远为真，无论你有没有真去数过原文。机械检查只能证伪\"多报\"，\"零报\"只能靠留痕让人复核\n- 历史首批实例：articles.md #19–27（2026-06 收录的 9 篇）+ 末尾观察项表 14 行\n\n\n# 文章索引\n\n> **本文件是文章索引与计数的唯一权威源（single source of truth）。**\n>\n> **计数规则（machine-checkable）：**\n> 一篇文章 = 一个 `### N. {标题}` 形式的编号小节，且不属于本文末尾的\"已跟踪产品 / 项目\"段落。\n> 占位条目（\"未找到 / 待补充\"）**不写在编号正文里**，而是统一进 `references/AGENTS.md` 的\"待补充\"列表，避免污染计数。\n> 全局连续编号（不按脉络重置），最大编号 = 文章总数。\n>\n> **下游引用都是本文的冗余缓存：** 根 `README.md` / `README.en.md` 的 badge、`prompts/deep-research-tracker.md` 的去重清单、`references/AGENTS.md` 的概览表。\n> 新增/删除文章时，必须**同一次提交**更新本文 + 所有下游缓存。\n>\n> 当前规模：**79 篇文章**（脉络一 75 + 脉络二 2 + 脉络三 2）+ **1 项已跟踪产品**（不计入文章数）。最近一次同步：2026-08-27。\n\n## 脉络一：AI 时代的 Harness Engineering（大模型护栏与认知工程）\n\n\n\n### 1. OpenAI 官方 — 原点与哲学\n\n- **标题：** Harness engineering: leveraging Codex in an agent-first world\n- **链接：** [openai.com](https://openai.com/zh-Hans-CN/index/harness-engineering/)\n- **作者：** Ryan Lopopolo | **日期：** 2026-02-11\n- **核心：** 3 人团队用 Codex 从空仓库到 100 万行代码，零手写代码。提出六大概念：仓库即记录系统、地图而非手册、机械化执行、智能体可读性、吞吐量改变合并理念、熵管理。\n- **关联：** 本仓库的学习起点，所有概念笔记的来源\n\n\n\n### 2. Martin Fowler / Birgitta Böckeler — 系统性认知与控制论框架\n\n- **标题：** Harness engineering for coding agent users\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/harness-engineering.html)\n- **翻译：** [works/fowler-harness-engineering-full-translation.md](../works/fowler-harness-engineering-full-translation.md)\n- **前传备忘录：** [first thoughts](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html) | **备忘录翻译：** [works/fowler-harness-engineering-memo-translation.md](../works/fowler-harness-engineering-memo-translation.md)\n- **作者：** Birgitta Böckeler (Thoughtworks) | **日期：** 2026-04-02（备忘录 2026-02-17）\n- **核心：** 控制论视角的 harness 框架——Guides（前馈）× Sensors（反馈）+ Computational（计算性）× Inferential（推理性）的 2×2 矩阵，三个规制维度，Ashby 必要多样性定律\n\n- **核心框架：Guides × Sensors + Computational × Inferential**\n\n| | 计算性（确定性，CPU） | 推理性（语义，LLM） |\n|--|---------|---------|\n| **引导器（前馈）** | bootstrap 脚本、OpenRewrite、LSP | AGENTS.md、Skills、architecture.md |\n| **传感器（反馈）** | linter、ArchUnit、类型检查、覆盖率 | AI code review、LLM-as-judge |\n\n- **关键原则：**\n - 单独用任何一种都不行——只有反馈 = 反复犯同样的错；只有前馈 = 不知道规则是否生效\n - 计算性控制便宜、确定、每次提交都跑；推理性控制昂贵、概率性、不是每次都跑\n - Harness engineering 是 context engineering 的一种特定形式\n\n- **三个规制维度：**\n\n| 维度 | 成熟度 | 现状 |\n|------|--------|------|\n| 可维护性 Harness | 最成熟 | 计算性传感器可靠捕获结构问题；LLM 部分解决语义问题；**两者都无法可靠捕获**：误诊、过度工程、误解指令 |\n| 架构适应度 Harness | 中等 | 本质是 Fitness Functions——性能 Skills + 可观测性规范 |\n| 行为 Harness | **最弱** | \"房间里的大象\"——功能正确性验证仍依赖 AI 生成的测试，\"目前还不够好\" |\n\n- **Harnessability（可驾驭性）：**\n - 不是所有代码库都同样适合被 harness\n - 强类型语言天然有类型检查传感器；清晰模块边界支持架构约束；成熟框架（如 Spring）隐式提高成功概率\n - **Ambient Affordances**（Ned Letcher）：环境本身的结构属性使智能体更容易操作\n - 绿地项目可以从第一天融入；遗留系统 = **harness 最需要的地方恰恰是最难构建的地方**\n\n- **Harness 模板：**\n - 企业 80% 的服务可归入几种常见拓扑（API 服务、事件处理、数据仪表板）\n - 服务模板 → harness 模板：引导器 + 传感器的集合，约束智能体到特定拓扑\n - 会面临和服务模板一样的分叉/同步挑战，甚至更严重（非确定性组件更难测试）\n\n- **Ashby 必要多样性定律：**\n - 调节器必须至少拥有与被调节系统同等的多样性\n - LLM 能生成几乎任何东西（高多样性）→ 选定拓扑 = 削减多样性 → 全面 harness 变得可行\n - 定义拓扑结构本身就是一种多样性削减举措\n\n- **人类角色的重新定位：**\n - 人类开发者携带隐性 harness：社会问责感、对复杂性的审美痛感、组织记忆、\"我们这里不这么做\"的直觉\n - 智能体没有这些——不知道哪个规范是承重的、哪个只是习惯\n - **\"好的 harness 不应以完全消除人类输入为目标，而应将人类输入引导到最重要的地方\"**\n\n- **质量左移（Shift Quality Left）：**\n - 按速度和成本分布检查：pre-commit 跑便宜传感器，管线跑昂贵传感器\n - 持续漂移传感器：死代码检测、覆盖率质量、依赖扫描、SLO 退化\n\n- **开放挑战：**\n - Harness 连贯性：引导器和传感器增长后可能相互矛盾\n - Harness 覆盖率：类似代码覆盖率，评估 harness 自身的完整性\n - 传感器从未触发时，如何区分高质量 vs 检测不足\n\n- **备忘录独有洞察（正式版未保留）：**\n - \"OpenAI 有既得利益让我们相信 AI 可维护的代码\"——对数据来源的信任保留\n - \"你今天的 harness 是什么？\"——务实的起步问题，审视已有实践\n - \"代码设计本身就是上下文的重要组成部分\"——比框架更本质\n - 最后自嘲预言\"harness\"一词会被滥用\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Guides × Sensors 矩阵 | 对 LangChain 组件清单和 HumanLayer 六杠杆的升维——从\"有什么\"到\"如何协同\" |\n| 行为 Harness 是大象 | 回应自己备忘录中的批评：OpenAI 缺少功能验证 |\n| Harnessability | OpenAI 的\"无聊技术\"选择标准的理论化 |\n| Ashby 定律 | 为 Fowler 假说 2（约束越严，自主性越强）提供控制论根基 |\n| Harness 模板 | 将备忘录假说 1 从问题升级为具体方案 |\n| 人类角色 | 对 Anthropic #7 中人类缺位的直接回应——不应消除人类，应引导人类 |\n\n- **延伸阅读：**\n - [Mitchell Hashimoto: My AI Adoption Journey #Step 5: Engineer the Harness](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness)（已升格为 #29）\n - [Context Engineering for Coding Agents](https://martinfowler.com/articles/context-engineering-coding-agents.html)\n - [Humans and Agents in Software Engineering Loops](https://martinfowler.com/articles/humans-and-agents.html)\n\n\n\n### 3. LangChain / Viv Trivedy — 解剖与机制\n\n- **标题：** The Anatomy of an Agent Harness\n- **链接：** [blog.langchain.com](https://blog.langchain.com/the-anatomy-of-an-agent-harness/)\n- **作者：** Vivek Trivedy | **日期：** 2026-03\n- **核心：** 给出 harness 的精确定义和完整组件清单\n\n> **Agent = Model + Harness**。Harness = 模型之外的一切代码、配置和执行逻辑。\n\n- **组件清单：**\n - System Prompts / Tools / Skills / MCP\n - 沙箱基础设施（文件系统、浏览器）\n - 编排逻辑（子智能体、handoff、模型路由）\n - Hooks/中间件（compaction、续接、lint 检查）\n- **关键洞察：**\n - **Context Rot** — 上下文填满后性能退化，需要 compaction + 工具输出卸载 + 渐进式披露\n - **Ralph Loop** — 拦截退出、重注入提示词、强制在新上下文窗口中继续\n - **Harness 与模型训练耦合** — 模型会 overfit 到特定 harness，换 harness 表现可能暴跌（Terminal Bench 2.0：纯 harness 优化可把排名从 Top 30 拉到 Top 5）\n\n\n\n### 4. Anthropic / Prithvi Rajasekaran — Harness 设计实战（长时自主编码）\n\n- **标题：** Harness design for long-running application development\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/harness-design-long-running-apps)\n- **作者：** Prithvi Rajasekaran (Anthropic Labs) | **日期：** 2026-03-24\n- **核心：** Anthropic 官方工程博客，GAN 启发的三智能体架构实战，从前端设计到全栈自主编码\n\n- **两个核心问题：**\n 1. **Context Anxiety** — 模型接近上下文极限时提前收尾（Sonnet 4.5 尤为明显），compaction 不够，需要 context reset\n 2. **Self-Evaluation 失败** — 智能体评估自己的工作时倾向于过度称赞，即使质量平庸\n\n- **三智能体架构（GAN 启发）：**\n\n| 智能体 | 职责 |\n|--------|------|\n| Planner | 1-4 句提示词 → 完整产品规格（刻意高层级，避免细节错误向下游级联） |\n| Generator | 按 sprint 逐特性实现，React + Vite + FastAPI + SQLite/PostgreSQL |\n| Evaluator | 用 Playwright MCP 实际操作运行中的应用，逐条验证 sprint 合同，打分 + 写详细 critique |\n\n- **Sprint 合同机制：**\n - 每个 sprint 前，Generator 和 Evaluator **协商**\"done 长什么样\"\n - Generator 提议构建内容和验证标准，Evaluator 审核\n - 双方迭代达成一致后才开始编码\n - 解决了 spec 太高层级 → 实现不可验证的 gap\n\n- **评估标准（前端设计 4 维度）：**\n 1. Design Quality — 是否有连贯的视觉身份（权重高）\n 2. Originality — 是否有原创设计决策，而非 AI 模板（权重高）\n 3. Craft — 排版、间距、对比度等技术执行（默认就好）\n 4. Functionality — 可用性独立于美学（默认就好）\n\n- **迭代进化（模型升级后的 Harness 瘦身）：**\n\n| 版本 | 模型 | 架构 | 时长 | 成本 |\n|------|------|------|------|------|\n| Solo baseline | Opus 4.5 | 单智能体 | 20 min | $9 |\n| V1 Harness | Opus 4.5 | Planner + Generator(sprint) + Evaluator(per-sprint) | ~6 hr | $200 |\n| V2 Harness | Opus 4.6 | Planner + Generator(无 sprint) + Evaluator(单次 pass) | ~4 hr | $125 |\n\n- **关键经验：**\n - **每个 harness 组件都编码了一个假设**（\"模型不能独立做 X\"），这些假设需要定期重新压测\n - 新模型发布后应精简 harness：去掉不再承重的部分，添加新能力\n - Evaluator 的价值取决于任务是否处于模型能力边界：边界内 → 开销浪费；边界外 → 真正有帮助\n - \"有趣的 harness 组合空间不会随模型改进而缩小——它会移动\"\n\n- **与其他文章的关联：**\n\n| Anthropic 概念 | 对应文章 |\n|---------------|---------|\n| Context Anxiety + Reset | LangChain 的 Context Rot + Ralph Loop |\n| Self-Evaluation 失败 → 分离 Evaluator | HumanLayer 的 Sub-Agent 上下文防火墙 |\n| Sprint 合同 | OpenAI 的执行计划（exec-plans） |\n| 4 维度评分标准 | OpenAI 的 QUALITY_SCORE.md |\n| Harness 瘦身原则 | Fowler 的\"约束越严，自主性越强\" |\n| \"找最简方案，按需增加复杂度\" | HumanLayer 的\"简单开始，按需添加\" |\n\n\n\n### 5. HumanLayer / Kyle — 实践与避坑\n\n- **标题：** Skill Issue: Harness Engineering for Coding Agents\n- **链接：** [humanlayer.dev](https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents)\n- **作者：** Kyle（HumanLayer） | **日期：** 2026-03-12\n- **核心：** 最落地的一篇——六个配置杠杆 + 实战经验\n\n- **六个杠杆：**\n\n| # | 杠杆 | 要点 |\n|---|------|------|\n| 1 | AGENTS.md | 控制在 60 行以内，禁止自动生成 |\n| 2 | MCP Servers | 别连不信任的，工具太多会填满上下文 |\n| 3 | Skills | 渐进式加载，警惕恶意 skill |\n| 4 | Sub-Agents | 上下文防火墙，隔离任务防 context rot |\n| 5 | Hooks | 生命周期脚本，成功静默/失败报错 |\n| 6 | Back-Pressure | 测试/构建/类型检查 = 自我验证回路 |\n\n- **实战经验：**\n\n| 无效 | 有效 |\n|------|------|\n| 预设理想配置 | 简单开始，按需添加 |\n| 装一堆 skill/MCP \"以防万一\" | 团队间分发验证过的配置 |\n| 每次改动跑全量测试 | 优化迭代速度而非首次成功率 |\n| 微调子智能体的工具权限 | 便宜模型做子任务，贵模型做编排 |\n\n- **金句：** \"The model is probably fine. It's just a skill issue.\"\n\n\n\n### 6. Anthropic / Lance Martin — 三大模式与性能数据\n\n- **标题：** Harnessing Claude's intelligence\n- **链接：** [claude.com](https://claude.com/blog/harnessing-claudes-intelligence)\n- **作者：** Lance Martin (Claude Platform Team) | **日期：** 2026-04-02\n- **核心：** 三个构建模式——利用 Claude 已知知识、追问\"我可以停止做什么\"、谨慎设定边界。配合 BrowseComp / Pokemon 等基准数据论证\n\n- **三大模式：**\n\n| 模式 | 核心主张 |\n|------|---------|\n| Use what Claude knows | 通用工具（bash + editor）优于定制工具，随模型升级自然增强 |\n| Ask \"what can I stop doing?\" | 把编排、上下文管理、持久化三个决策权从 harness 交给模型 |\n| Set boundaries carefully | 缓存优化（静态前置）+ 声明式工具提供安全门控与可观测性 |\n\n- **\"停止做什么\"的三个层次：**\n\n| 层次 | 旧假设 | 新做法 | 数据支撑 |\n|------|--------|--------|---------|\n| 编排 | 所有工具结果回流上下文 | 给 Claude 代码执行工具，让它自己过滤/管道 | BrowseComp: Opus 4.6 过滤能力 45.3% → 61.6% |\n| 上下文管理 | 手工预加载任务指令 | Skills 渐进式披露 + context editing 移除过时内容 + 子 Agent 隔离 | BrowseComp: 子 Agent 提升 2.8% |\n| 持久化 | 依赖外部检索基础设施 | Compaction（模型自主总结）+ Memory folder（模型自主写文件） | BrowseComp: Opus 4.6 compaction 达 84%；BrowseComp-Plus: memory folder +6.8% |\n\n- **缓存优化五原则：**\n\n| 原则 | 说明 |\n|------|------|\n| 静态在前，动态在后 | 稳定内容（系统提示词、工具）放前面 |\n| 用消息传递更新 | 追加 `` 而非编辑提示词 |\n| 不切换模型 | 缓存是模型特定的，切换即失效；需要便宜模型用子 Agent |\n| 谨慎管理工具 | 工具在缓存前缀中，增删会使缓存失效；用 tool search 追加 |\n| 更新断点 | 多轮应用中将断点移至最新消息，使用自动缓存 |\n\n- **声明式工具的四个价值：**\n 1. 安全门控 — 不可逆操作（如外部 API）需用户确认\n 2. 过时检查 — 写入工具检测文件自上次读取后是否被修改\n 3. UX 渲染 — 模态窗口展示问题、提供选项、阻塞等待反馈\n 4. 可观测性 — 结构化参数可记录、追踪、重放\n\n- **Pokemon 记忆进化案例：**\n - Sonnet 3.5: 14,000 步后 31 个文件（含重复），仍在第二城镇，记忆 = NPC 对话转录\n - Opus 4.6: 同样步数 10 个文件（按目录组织），3 枚道馆徽章，记忆 = 战术笔记 + 失败经验\n\n- **\"上下文焦虑\"案例：**\n - Sonnet 4.5 接近上下文极限时提前收尾 → 加了 context reset 补偿\n - Opus 4.5 天然消除了此行为 → context reset 变成死重\n - 启示：harness 中的补偿机制会随模型进化变成性能瓶颈\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 通用工具 > 定制工具 | OpenAI 原文的 bash + editor 起源 |\n| Skills 渐进式披露 | LangChain 的 Progressive Disclosure、HumanLayer 的 Skills 杠杆 |\n| Compaction + Memory folder | LangChain 的 Context Rot 解法、Anthropic #4 的 Context Anxiety |\n| 声明式工具 vs bash | HumanLayer 的 Back-Pressure 杠杆 |\n| \"停止做什么\" | Anthropic #4 的 Harness 瘦身原则、Fowler 的假说 |\n| 缓存优化 | 本仓库新增维度——此前文章未深入讨论 API 层成本优化 |\n\n\n\n### 7. Anthropic / Lance Martin, Gabe Cemaj, Michael Cohen — Meta-Harness 与基础设施解耦\n\n- **标题：** Scaling Managed Agents: Decoupling the brain from the hands\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/managed-agents)\n- **作者：** Lance Martin, Gabe Cemaj, Michael Cohen | **日期：** 2026-02-04\n- **翻译：** [works/anthropic-managed-agents-translation.md](../works/anthropic-managed-agents-translation.md)\n- **核心：** 不再讨论\"如何设计 harness\"，而是追问\"如何让 harness 本身成为可替换的基础设施\"——提出 meta-harness 概念\n\n- **三个虚拟化组件（借鉴操作系统）：**\n\n| 组件 | 类比 | 接口 |\n|------|------|------|\n| Session | 文件系统 | `emitEvent(id, event)`, `getEvents()`, `getSession(id)` |\n| Harness | 进程 | `wake(sessionId)` — 无状态，可随时替换 |\n| Sandbox | I/O 设备 | `execute(name, input) → string`, `provision({resources})` |\n\n- **Pets vs Cattle 演进：**\n - 耦合设计：session + harness + sandbox 在同一容器 → 容器 = 宠物，故障即丢失\n - 解耦设计：三组件独立 → 全部是牲畜，可独立故障和替换\n\n- **安全边界（结构性隔离）：**\n - Git：访问令牌在沙箱初始化时注入 remote，智能体不触碰令牌\n - 自定义工具：OAuth 令牌在 vault 中，通过 MCP proxy 调用，harness 永不接触凭证\n - 核心原则：**令牌永远不可从沙箱内访问**\n\n- **Session 作为外部上下文存储：**\n - 上下文不再是 harness 内的不可逆决策（compaction/trimming）\n - Session 日志持久存储完整事件流，`getEvents()` 按需切片取回\n - 上下文转换（缓存优化、上下文工程）在 harness 层做，与存储层分离\n\n- **性能数据：**\n\n| 指标 | 改善 |\n|------|------|\n| p50 TTFT | ~60% 下降 |\n| p95 TTFT | >90% 下降 |\n\n- **多大脑、多双手：**\n - 多大脑：无状态 harness 按需启动，容器仅在工具调用时配置\n - 多双手：每双手 = `execute(name, input) → string`，harness 不关心手是容器、手机还是宝可梦模拟器\n - 大脑之间可以互相传递双手\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Harness 假设过时 | Anthropic #4 的 Harness 瘦身、#6 的\"停止做什么\" |\n| Pets vs Cattle | 经典 DevOps 概念，Harness.io 脉络的核心 |\n| Session 外部存储 | LangChain 的 Context Rot、Anthropic #6 的 Compaction |\n| Meta-harness | Fowler 的假说 1：\"Harness 将成为未来的服务模板\" |\n| 安全边界解耦 | HumanLayer 的 MCP 信任边界 |\n| 多大脑多双手 | OpenAI 原文的并发 + 吞吐量理念 |\n\n\n\n### 8. Fowler / Rahul Garg — 编码团队标准：缩减 AI 辅助开发的摩擦\n\n- **标题：** Encoding Team Standards\n- **系列：** Patterns for Reducing Friction in AI-Assisted Development\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html)\n- **翻译：** [works/fowler-encoding-team-standards-translation.md](../works/fowler-encoding-team-standards-translation.md)\n- **作者：** Rahul Garg (Thoughtworks) | **日期：** 2026-04-01\n- **核心：** 将团队隐性编码标准显式化为可机器执行的规范，从自然语言 → 示例 → 自动化检查三层渐进\n- **关键洞察：**\n - 团队标准分三类：语言/框架惯用法、项目特有约定、架构决策\n - 编码路径：口头约定 → AGENTS.md/prompts 中的自然语言描述 → 带示例的结构化指令 → lint 规则/自动化检查\n - 不是所有标准都值得完全自动化——按违反频率和影响决定投资\n- **与其他文章关联：** Fowler #2 的 Guides×Sensors 框架的实操手册；HumanLayer 的 AGENTS.md 杠杆的深化\n\n\n\n### 9. Fowler / Rahul Garg — 反馈飞轮：缩减 AI 辅助开发的摩擦\n\n- **标题：** Feedback Flywheel\n- **系列：** Patterns for Reducing Friction in AI-Assisted Development\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html)\n- **翻译：** [works/fowler-feedback-flywheel-translation.md](../works/fowler-feedback-flywheel-translation.md)\n- **作者：** Rahul Garg (Thoughtworks) | **日期：** 2026-04-01\n- **核心：** 构建从 AI 失败中持续学习的反馈闭环——观察失败 → 根因分析 → 编码修复 → 验证效果 → 迭代\n- **关键洞察：**\n - 反馈飞轮四步：发现模式 → 诊断根因 → 系统性修复（而非一次性补丁）→ 衡量改善\n - 与 Encoding Team Standards 形成闭环：标准编码 → 违反检测 → 反馈 → 标准演进\n - 团队级别的 harness 不是一次性设计，而是持续演进的活系统\n- **与其他文章关联：** Anthropic #4 的\"每个 harness 组件编码一个假设\"理念的运营化；YDD 的安灯绳验证闭环\n\n\n\n### 10. LangChain — 智能体评估就绪清单\n\n- **标题：** Agent Evaluation Readiness Checklist\n- **链接：** [blog.langchain.com](https://blog.langchain.com/agent-evaluation-readiness-checklist/)\n- **翻译：** [works/langchain-agent-evaluation-checklist-translation.md](../works/langchain-agent-evaluation-checklist-translation.md)\n- **作者：** LangChain 团队 | **日期：** 2026-04-08\n- **核心：** 从零到一构建智能体评估体系的分阶段清单——定义 → 数据集 → 评估器 → 实验 → 持续集成\n- **关键洞察：**\n - 评估五阶段：定义成功标准 → 构建评估数据集 → 选择评估器 → 运行实验 → CI 集成\n - 数据集构建方法论：从生产日志中提取真实案例，比合成数据更有价值\n - LLM-as-judge 的校准：需要人类标注作为锚点，定期重新校准\n - 评估不是一次性的，而是随智能体演进持续更新的\n- **与其他文章关联：** Fowler #2 的 Sensors 维度的系统化实操；Anthropic #4 的 Evaluator 角色的方法论基础\n\n\n\n### 11. Meta-Harness 论文 — 自动化 Harness 优化\n\n- **标题：** Meta-Harness: End-to-End Optimization of Model Harnesses\n- **链接：** [arxiv.org](https://arxiv.org/abs/2603.28052)\n- **翻译：** [works/meta-harness-paper-translation.md](../works/meta-harness-paper-translation.md)\n- **作者：** Yoonho Lee, Roshen Nair 等 (Stanford, KRAFTON, MIT) | **日期：** 2026-03-30\n- **核心：** 用编码智能体作为提议器，通过文件系统访问完整搜索历史（代码+轨迹+分数），自动搜索最优 Harness\n- **关键洞察：**\n - 外循环搜索：提议器检查先前 Harness 的源代码和执行轨迹，进行因果推理后提出改进\n - 文本分类任务上比 ACE 高 7.7pp，上下文 token 减少 4×\n - IMO 难度数学问题上，发现的检索 Harness 跨 5 个留出模型泛化，平均提升 4.7pp\n - TerminalBench-2 上超越手工工程化的 Terminus-KIRA\n - 核心发现：完整执行轨迹访问 > 压缩摘要 > 仅标量分数（消融实验）\n- **与其他文章关联：** Anthropic #7 的 meta-harness 概念的学术实现；Fowler #2 的 Sensors 的极致自动化——连 harness 本身的设计也变成可搜索的\n\n\n\n### 12. GitHub / Tyler McGoffin — 智能体驱动开发实战\n\n- **标题：** Agent-driven development in Copilot Applied Science\n- **链接：** [github.blog](https://github.blog/ai-and-ml/github-copilot/agent-driven-development-in-copilot-applied-science/)\n- **翻译：** [works/github-agent-driven-development-translation.md](../works/github-agent-driven-development-translation.md)\n- **作者：** Tyler McGoffin (GitHub Copilot Applied Science) | **日期：** 2026-03-31\n- **核心：** 用编码智能体构建智能体，自动化自身工作的实战叙述；Copilot SDK + MCP + Skills 的具体使用模式\n- **关键洞察：**\n - 智能体驱动开发的三阶段演进：手动 → 半自动 → 全自动\n - 关键经验：好的提示词比好的代码更重要；智能体需要明确的约束和验证循环\n - Copilot CLI 作为日常工具的实际工作流\n- **与其他文章关联：** OpenAI 原文的\"工程师不再写代码\"理念的一线实践验证\n\n\n\n### 13. Inside the Scaffold 论文 — 编码智能体脚手架的源代码级分类法\n\n- **标题：** Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures\n- **链接：** [arxiv.org](https://arxiv.org/html/2604.03515v1)\n- **翻译：** [works/inside-the-scaffold-paper-translation.md](../works/inside-the-scaffold-paper-translation.md)\n- **作者：** Benjamin Rombaut (Huawei Canada) | **日期：** 2026-04-04\n- **核心：** 对 13 个开源编码智能体的脚手架代码进行源代码级分析，提出 12 维度 × 3 层次的架构分类法\n- **关键洞察：**\n - 五种循环原语（ReAct、生成-测试-修复、计划-执行、多次重试、树搜索）是可组合的构建块，11/13 智能体组合多种原语\n - 维度在外部约束主导处收敛（工具类别、编辑格式、执行隔离），在开放设计问题处发散（上下文压缩、状态管理、多模型路由）\n - 工具数量从 0（Aider）到 37（Moatless Tools），但底层能力类别趋同：读取、搜索、编辑、执行\n - 上下文压缩涵盖七种策略：截断、摘要、滑动窗口、事件溯源、浓缩、选择性包含、无压缩\n- **与其他文章关联：** 为 Fowler #2 的 Guides×Sensors 框架提供了 13 个实际系统的实证数据；Meta-Harness 论文搜索空间的具体化——展示了 harness 设计选择的巨大多样性\n\n\n\n### 14. ⭐ Lalit Maganti — 渴望八年，用 AI 三个月造出来\n\n- **标题：** Eight years of wanting, three months of building with AI\n- **链接：** [lalitm.com](https://lalitm.com/post/building-syntaqlite-ai/)\n- **翻译：** [works/maganti-eight-years-building-ai-translation.md](../works/maganti-eight-years-building-ai-translation.md)\n- **作者：** Lalit Maganti | **日期：** 2026-04-05\n- **核心：** 资深工程师（Chrome/Android 性能团队）用 AI 编码智能体从零构建 syntaqlite（SQLite 开发工具）的完整复盘——250 小时，3 个月，坦诚记录 AI 的帮助与局限\n- **关键洞察：**\n - AI 是实现的力量倍增器，但不能替代设计——缺乏品味、历史感和用户直觉\n - 实际经验：AI 在 well-constrained 的任务上卓越（测试编写、重构、API 实现），在需要判断力的任务上失败（架构决策、API 设计、性能优化）\n - \"vibe coding\" 对严肃项目不可行——必须理解 AI 生成的每一行代码\n - 模型能力进化的真实感受：Claude 3.5 → Sonnet 4.5 → Gemini 2.5 Pro 的逐步改善\n - **与我们的实践高度一致**\n- **与其他文章关联：** YDD 的\"洗衣机悖论\"的一手证据——省出的时间投入到了更高层的设计工作中；Anthropic #4 的\"每个 harness 组件编码一个假设\"的个人体验版\n\n\n\n### 15. LangChain / Harrison Chase — 智能体的持续学习\n\n- **标题：** Continual learning for AI agents\n- **链接：** [blog.langchain.com](https://blog.langchain.com/continual-learning-for-ai-agents/)\n- **翻译：** [works/langchain-continual-learning-translation.md](../works/langchain-continual-learning-translation.md)\n- **作者：** Harrison Chase (LangChain CEO) | **日期：** 2026-04-05\n- **核心：** 智能体的学习发生在三个层次：模型权重、Harness、上下文——理解区别改变你构建持续改进系统的方式\n- **关键洞察：**\n - 三层学习：模型层（微调/RL）→ Harness 层（提示词/工具/编排逻辑演进）→ 上下文层（运行时记忆/少样本示例）\n - Harness 层学习最被低估：通过分析执行轨迹迭代改进 harness，而非仅改模型\n - 上下文层学习最灵活：用户级记忆、后台整合、跨会话学习\n - Deep Agents 框架支持生产级持续学习\n- **与其他文章关联：** Meta-Harness 论文的 harness 层自动化学习的框架化阐述；Fowler #9 反馈飞轮在智能体层面的体现\n\n\n\n### 16. OpenAI 官方 — 任务跟踪器作为控制平面（Symphony）\n\n- **标题：** An open-source spec for Codex orchestration: Symphony\n- **链接：** [openai.com](https://openai.com/index/open-source-codex-orchestration-symphony/)\n- **翻译：** [works/openai-codex-symphony-translation.md](../works/openai-codex-symphony-translation.md)\n- **作者：** Alex Kotliarskyi, Victor Zhu, Zach Brock | **日期：** 2026-04-27\n- **核心：** 把 Linear 这类问题跟踪器变成智能体编排的控制平面——每个打开的 ticket 映射一个智能体工作区，Symphony 保证未完成任务始终有智能体在跑。Symphony 本体只是一份 `SPEC.md`+`WORKFLOW.md`，参考实现用 Elixir，作者鼓励使用者把 spec 交给自己的编码智能体生成本地实现。\n- **关键洞察：**\n - **从交互式会话到 ticket 级编排**：人类瓶颈不在写代码，而在管理 3-5 个并发 Codex 会话的上下文切换；把 issue tracker 当状态机后，瓶颈转移到智能体的目标空间\n - **目标 vs 状态转换**：早期把智能体当状态机里的刚性节点不奏效；最终转向\"给目标 + 工具 + 上下文，让它自己推理\"\n - **代码免费 → 按语言优势选语言**：参考实现用 Elixir 是因为其并发能力强；同一份 SPEC.md 用 TS/Go/Rust/Java/Python 都能实现成功，多语言实现反过来打磨规范本身\n - **探索成本接近零**：PM/设计师可直接提交 ticket 拿到带演示视频的 review packet，扩大了\"谁能发起工程工作\"的边界\n - **数据点**：部分团队前三周已落地 PR 数量 +500%；发布后 4 月 23 日仓库 15K+ stars\n- **与其他文章关联：** OpenAI 原文 #1 的\"map not manual\"在 SPEC.md 模式下的极致——map 不仅给智能体看，也给社区使用者作为构建模板；HumanLayer #5 的\"AGENTS.md 杠杆\"在工作流层面的扩展（`WORKFLOW.md` 显式化原本隐式的人类流程）；与 thinking 洞见 7 的\"技术栈收敛\"形成反例\n- **实施参考：** [openai/symphony](https://github.com/openai/symphony) | [SPEC.md](https://github.com/openai/symphony/blob/main/SPEC.md)\n\n\n\n### 17. Vikash Rungta — Claude Code 架构（逆向工程版）\n\n- **标题：** Claude Code Architecture (Reverse Engineered)\n- **链接：** [vrungta.substack.com](https://vrungta.substack.com/p/claude-code-architecture-reverse)\n- **翻译：** [works/claude-code-architecture-reverse-translation.md](../works/claude-code-architecture-reverse-translation.md)\n- **作者：** Vikash Rungta | **日期：** 2025-11-01\n- **性质：** 外部逆向分析，非 Anthropic 官方架构文档\n- **核心：** 把 Claude Code 解释为模型无关的本地运行外壳：模型负责推理，外壳提供 shell、文件系统、工具原语、记忆、权限、hooks、MCP、skills、子智能体和智能体团队，把自主循环约束在可治理边界内。\n\n- **关键洞察：**\n - **从工作流到循环：** 从代码控制模型的 DAG，转向模型控制行动的 TAOR（Think-Act-Observe-Repeat）循环；运行时保持简单，智能尽量留给模型。\n - **原语工具胜过专用集成：** Bash、Grep、Edit、Read 这类通用能力原语，比大量脆弱的垂直插件更能覆盖真实工程工作流。\n - **上下文是一种稀缺资源：** 自动压缩、子智能体隔离、语义工具搜索和 forked context 都是在管理上下文预算，避免上下文坍缩。\n - **权限就是产品体验：** plan/default/acceptEdits/dontAsk/bypassPermissions 这类信任光谱，把安全、速度和企业采用门槛合在一起。\n - **Harness 应随模型变薄：** 模型能力提升后，硬编码脚手架应被删除或下沉为确定性 hook，而不是持续堆复杂度。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Claude Code 作为 Harness 的产品化样本 | #3 LangChain 的 Agent = Model + Harness 公式 |\n| 子智能体与智能体团队 | #13 Inside the Scaffold 的子智能体委托分类、#16 Symphony 的 ticket 级编排 |\n| hooks 作为确定性护栏 | #2 Fowler Guides×Sensors、#5 HumanLayer 六杠杆 |\n| 模型升级时删除代码 | #4 Anthropic Harness 瘦身、#6 Anthropic/Claude Platform 的\"停止做什么\" |\n| Claude Code 专有实现的外部观察 | 弥补 #13 因 Claude Code 非开源而无法纳入源代码分类法的空白 |\n\n> 注：Chachamaru127 / claude-code-harness 早期曾占据 #16 文章位，现已迁至本文末尾的\"已跟踪产品 / 项目\"段落（不计入文章数）。\n\n\n\n### 18. 马东锡 NLP — Harness 系列文章之 7：关于 subagent\n\n- **标题：** Harness 系列文章之 7：关于 subagent\n- **链接：** [x.com](https://x.com/dongxi_nlp/status/2068922428516892998)\n- **原文收录：** [works/dongxi-subagent-original.md](../works/dongxi-subagent-original.md)\n- **作者：** 马东锡 NLP (@dongxi_nlp) | **日期：** 2026-06-22\n- **核心：** 把 subagent 从\"小号智能体\"重新定义为 parent session 通过一次 tool call 拉起的 managed child runtime：外层是 `spawn_agent` / `/delegate` tool call，内层是新的 child session 和被选择过的 context projection。\n\n- **关键洞察：**\n - **Tool call outside, runtime inside：** subagent 的启动入口是 tool call；tool call 之后，Harness 的世界状态里多了一个 child runtime。\n - **Session ≠ Context：** session 是 runtime container，包含 thread、transcript、tools、permissions、resources、status、artifacts；context 是某次 model call 可见的 projection。\n - **Shared resources 不等于 shared transcript：** child 可以继承 tools、skills、AGENTS.md、MCP servers、cwd、sandbox、permissions，但不自动继承 parent 的完整对话历史。\n - **三种投影策略：** fresh child、forked child、partial fork 分别对应不同上下文继承强度；partial fork 是避免 parent history 噪声的实用中间态。\n - **更多 agents = 更多 runtime state：** 多智能体不是免费并行，Harness 必须追踪谁在工作、知道什么、改了什么、何时完成，以及结果如何变成 evidence。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| child session 与 context projection | #7 Anthropic Managed Agents 的 Session/Harness/Sandbox 解耦 |\n| subagent 作为上下文隔离机制 | #17 Claude Code 架构逆向中的隔离 TAOR 循环与 summary return |\n| fresh/forked/partial fork | #6 Anthropic/Claude Platform 的 context editing、sub-agent 隔离与缓存前缀管理 |\n| evidence 回流与 runtime state | #16 OpenAI Symphony 的任务跟踪器控制平面、#13 Inside the Scaffold 的委托分类 |\n\n- **本仓库笔记：** [thinking/subagent-is-child-runtime.md](../thinking/subagent-is-child-runtime.md)\n\n---\n\n\n\n### 19. Fowler / Birgitta Böckeler — 面向编码智能体的可维护性传感器\n\n- **标题：** Maintainability sensors for coding agents\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/sensors-for-coding-agents.html)\n- **中文译文：** [works/fowler-sensors-translation.md](../works/fowler-sensors-translation.md)\n- **作者：** Birgitta Böckeler | **日期：** 2026-05-20\n- **核心：** Böckeler 从一个真实 TypeScript/NextJS 应用出发，系统梳理\"计算性 vs 推理性\"传感器谱系（type checker、ESLint、Semgrep、dependency-cruiser、mutation testing、耦合分析、AI 模块化评审），并诚实记录失败案例（耦合数据对 AI\"乏善可陈\"、把合理的 DI factory 误判为 god module）。\n\n- **关键洞察：**\n - **传感器 = 反馈控制隐喻：** lint message 写成\"自我修正指导\"（prompt injection 式提示），让 agent 读到反馈即自纠。\n - **计算性 vs 推理性：** 确定性检查（type/lint/依赖图）与需要判断的检查（模块化、耦合）是两类不同传感器，可靠度与误报率不同。\n - **AI 模块化评审 = 垃圾回收：** 作者明确把它称为 garbage collection——周期性识别并清理结构腐化。\n - **诚实的负面结果：** 不是所有传感器都有用，耦合指标对 AI 收效甚微，记录失败本身是这篇的价值。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Guides × Sensors 框架的实操续篇 | #2 Fowler 的控制论矩阵 |\n| 机械化执行（custom linter > 文档） | 概念 3 机械化执行 |\n| AI 评审作为垃圾回收 | 概念 6 熵与垃圾回收 |\n\n- **本仓库笔记：** [thinking/guides-sensors-meets-claude-code-harness.md](../thinking/guides-sensors-meets-claude-code-harness.md)\n\n---\n\n\n\n### 20. Fowler / Wei Zhang, Jessie Jie Xia — 结构化提示驱动开发（SPDD）\n\n- **标题：** Structured-Prompt-Driven Development (SPDD)\n- **链接：** [martinfowler.com](https://martinfowler.com/articles/structured-prompt-driven/)\n- **中文译文：** [works/fowler-spdd-translation.md](../works/fowler-spdd-translation.md)\n- **作者：** Wei Zhang, Jessie Jie Xia（Martin Fowler 编辑） | **日期：** 2026-04-28\n- **核心：** 一套把提示词当一等版本化交付物的半自动 Harness：提出 REASONS Canvas 七维结构（R/E/A/S/O/N/S），主张\"先修提示词再改代码、重构则反向同步 spdd-sync\"的双向闭环。文末附 13 组高质量自问自答。\n\n- **关键洞察：**\n - **Prompt 是合同，Plan 是建议：** 把结构化提示词版本化、可审查，作为变更的承重结构。\n - **双向闭环：** 现实偏离 spec 时先改 prompt 再改代码；人工重构后用 spdd-sync 反向同步回 prompt，防止提示词漂移。\n - **SPDD 本身就是一个 Harness：** 把上下文、约束、审查、同步全部显式化。\n - **诚实承认边界：** \"人类判断仍然是承重结构\"，模型无关、不替代审查。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Prompt 即一等可版本化交付物 | #16 OpenAI Symphony 的约束即产品、延伸概念 07-spec-as-product |\n| REASONS Canvas 七维结构 | 概念 2 地图而非手册 + 渐进式披露 |\n| spdd-sync 反向同步防漂移 | 概念 3 机械化执行、#9 反馈飞轮 |\n\n---\n\n\n\n### 21. LangChain / Harrison Chase — 智能体开发生命周期（ADLC）\n\n- **标题：** The Agent Development Lifecycle (ADLC)\n- **链接：** [langchain.com](https://www.langchain.com/blog/the-agent-development-lifecycle)\n- **中文译文：** [works/langchain-adlc-translation.md](../works/langchain-adlc-translation.md)\n- **作者：** Harrison Chase | **日期：** 2026-05-09\n- **核心：** 提出 Build → Test → Deploy → Monitor + Iterate + Govern 的完整智能体开发生命周期，把 framework / runtime / harness 三层做了清晰区分，治理段拆出 cost / tool access / discoverability。是方法论级别的总览型骨架文。\n\n- **关键洞察：**\n - **framework / runtime / harness 三分类：** 与本仓库主题命名正面对齐——harness 是约束与反馈层，runtime 是执行容器，framework 是编排库。\n - **生命周期是闭环：** Monitor 产出的轨迹回流到 Iterate，把一次性 demo 变成可重复、可评测、可运营的工程。\n - **Govern 作为一等维度：** 成本、工具访问、可发现性被显式纳入治理。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| framework/runtime/harness 三层 | #6 Anthropic 三大模式、#17 Claude Code 架构逆向 |\n| Monitor → Iterate 反馈回路 | #2 Fowler Sensors、概念 3 机械化执行 |\n| Govern / 治理维度 | 概念 6 熵与垃圾回收 |\n\n---\n\n\n\n### 22. LangChain / Hunter Lovell — Deep Agents 中的解释器\n\n- **标题：** Interpreters in Deep Agents: Code Between Tool Calls and Sandboxes\n- **链接：** [langchain.com](https://www.langchain.com/blog/give-your-agents-an-interpreter)\n- **中文译文：** [works/deep-agents-interpreter-translation.md](../works/deep-agents-interpreter-translation.md)\n- **作者：** Hunter Lovell | **日期：** 2026-05-20\n- **核心：** 提出 interpreter 是介于串行工具调用与完整沙箱之间的\"第三层\"，interpreter state 是继 message history、filesystem 之后的\"第三类上下文表面\"。给出 35% token 节省实测，以及 QuickJS / 桥接 / 运行时控制的实现细节。\n\n- **关键洞察：**\n - **上下文表面分层：** message history / filesystem / interpreter state 是三类不同的 context surface，各自有不同的读写与投影方式。\n - **设计上更受限是主动选择：** interpreter 主动收窄能力（而非能力不足），用受限运行时换取可控与可读。\n - **35% token 节省：** 让智能体写代码协调工具、保存中间态，只把相关结果送入模型上下文。\n - **横向连接：** 呼应 Cloudflare Code Mode、Anthropic PTC、RLM。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 受限运行时即机械约束 | 概念 3 机械化执行、概念 4 智能体可读性 |\n| 上下文表面 / context surface 分层 | #6 Anthropic context editing、#18 subagent 的 context projection |\n| 用代码协调工具以省上下文 | #16 OpenAI Symphony 控制平面 |\n\n---\n\n\n\n### 23. Anthropic / 工程团队 — Claude Code 质量回归复盘\n\n- **标题：** An update on recent Claude Code quality reports\n- **链接：** [anthropic.com](https://www.anthropic.com/engineering/april-23-postmortem)\n- **中文译文：** [works/anthropic-postmortem-translation.md](../works/anthropic-postmortem-translation.md)\n- **作者：** Anthropic 工程团队 | **日期：** 2026-04-23\n- **核心：** 对三起独立的 Claude Code 质量回归逐项复盘——(1) 默认 reasoning effort 从 high 降到 medium 的产品取舍；(2) clear_thinking 缓存优化 bug（本应只清一次却每轮都清，导致\"健忘/重复/乱用工具\"并拖垮缓存命中）；(3) 一条 system prompt 限长指令（≤25/≤100 词）压垮编码智能。三个变更各打不同流量切片、不同时间表，叠加成\"广泛而不一致的退化\"。是仓库稀缺的第一手失败案例。\n\n- **关键洞察：**\n - **变更评估的经典陷阱：** 三个变更各自通过人审 + 自动审 + 单测 + e2e + dogfooding，仍全部漏网。\n - **system prompt 即受控产物：** 一条限长指令就能压垮编码智能，提示词必须纳入评测与审计。\n - **现成的治理清单：** 文末\"后续计划\"（per-model eval 套件、消融、soak period、渐进发布、prompt 审计工具）几乎是一份 harness 变更治理清单。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 机械化执行的盲区（多层审查仍漏网） | 概念 3 机械化执行、#2 Fowler Sensors |\n| system prompt 即受控产物 | 延伸概念 07-spec-as-product、#16 Symphony |\n| 反例 / 事故复盘（稀缺类型） | 仓库 works/ 多为正面理论，本篇为第一手反面教材 |\n\n---\n\n\n\n### 24. 林家航 等 / 复旦·北大·奇绩智锋 — Agentic Harness Engineering（论文）\n\n- **标题：** Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses\n- **链接：** [arxiv.org/html/2604.25850v4](https://arxiv.org/html/2604.25850v4)\n- **中文译文：** [works/arxiv-agentic-harness-engineering-translation.md](../works/arxiv-agentic-harness-engineering-translation.md)\n- **作者：** Jiahang Lin, Shichun Liu, Chengjun Pan 等（复旦 / 北大 / 奇绩智锋） | **日期：** 2026-05-18 | **arXiv：** 2604.25850 v4\n- **核心：** 提出 AHE 闭环——在固定基础模型下，通过组件、经验、决策三类可观测性让 Harness 自动演化：可编辑组件文件化，轨迹压缩为可下钻证据，每次编辑附带可证伪预测。Terminal-Bench 2 上 pass@1 从 69.7% 提升到 77.0%，超过 Codex-CLI，并在 SWE-bench-verified 与跨模型迁移中保持收益。\n\n- **关键洞察：**\n - **每次 Harness 编辑 = 可证伪契约：** 把 harness 优化从经验调参变成可验证的研究问题。\n - **三类可观测性：** 组件 / 经验 / 决策，构成分层可下钻的证据语料库。\n - **诚实报告局限：** 回归失明、组件非加性交互——优化并非单调可加。\n - **直接引用仓库源头：** 参考文献含 OpenAI Harness Engineering、Anthropic harness design、LangChain deep agents。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| Harness 自动演化 / meta-harness | #11 Meta-Harness 论文、#7 Anthropic Meta-Harness |\n| 可观测性驱动的闭环 | #2 Fowler Sensors、概念 3 机械化执行 |\n| 编码智能体脚手架分类 | #13 Inside the Scaffold 论文 |\n\n---\n\n\n\n### 25. Yubin Qu 等 — 过度积极的编码智能体（论文）\n\n- **标题：** Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks\n- **链接：** [arxiv.org/html/2605.18583v1](https://arxiv.org/html/2605.18583v1)\n- **中文译文：** [works/arxiv-overeager-coding-agents-translation.md](../works/arxiv-overeager-coding-agents-translation.md)\n- **作者：** Yubin Qu, Ying Zhang, Yanjun Zhang, Gelei Deng, Yuekang Li, Leo Yu Zhang, Yi Liu | **日期：** 2026-05-18 | **arXiv：** 2605.18583 v1\n- **核心：** 定义并测量编码智能体在良性任务中的 overeager actions（完成表面任务却执行用户未授权的读写）。提出 OverEager-Gen/Bench（500 场景、约 7500 次运行、4 个 agent 产品 × 6 模型），用行为梯度验证器与双通道审计栈评估越界率。\n\n- **关键洞察：**\n - **反直觉发现：** 在提示里写明授权范围，会让 agent 从\"推断边界\"退化为\"匹配声明文本\"——Claude Code 去掉 consent 声明后越界率 0.0% → 17.1%。\n - **框架层主导：** permission gating 由框架层决定，模型层对齐不会完整传导到行为。\n - **授权问题是独立类别：** 区别于能力失败、提示注入、沙箱逃逸，是单独的一类风险。\n - **实证支撑机械约束：** 证明约束必须机械强制，靠提示声明反而降低边界推断。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 权限门控 / 边界约束 | #7 Anthropic Managed Agents 沙箱、概念 3 机械化执行 |\n| 提示声明反而降低安全 | #23 Anthropic 复盘的 system prompt 陷阱 |\n| agent 越界的实证测量 | 概念 6 熵与垃圾回收 |\n\n---\n\n\n\n### 26. Chris Parsons — 我是如何用 AI 写代码的\n\n- **标题：** How I Use AI to Code\n- **链接：** [chrismdp.com](https://chrismdp.com/coding-with-ai/)\n- **中文译文：** [works/chris-ai-code-translation.md](../works/chris-ai-code-translation.md)\n- **作者：** Chris Parsons | **日期：** 2026-05（更新版）\n- **核心：** 资深从业者的一手实践复盘。硬区分 Vibe Coding 与\"智能体化工程\"，提出\"从批准者到训练者\"的角色转变，归纳四要素 Harness（常驻指令 / skill files / 验证循环 / 反馈循环），并主张\"spec the problem, not the solution\"。带 7 条带注解脚注（a16z、Karpathy、METR/MIT、Greenblatt serial speed-up 等）。\n\n- **关键洞察：**\n - **Vibe Coding ≠ 智能体化工程：** 前者不真正检查结果，后者是\"有分寸地判断哪些 diff 需要你的眼睛\"。\n - **从批准者到训练者：** 资深工程师的工作不再是审查输出，而是训练 AI——把判断花在哪里本身是资深技能。\n - **四要素 Harness：** 常驻指令、skill files、验证循环、反馈循环；没有反馈循环脚手架会腐化。\n - **反馈是新瓶颈：** 编码本身更快了，但审查/验证/集成/返工变慢，慢工作吞没快工作。\n - **译者注：** 文中 2026 数据/产品断言来自原文及脚注，译者未独立核实（见译文顶部说明）。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 四要素 Harness | #2 Fowler、#5 HumanLayer 六杠杆、概念 2/3（地图而非手册 / 机械化执行） |\n| 反馈循环防腐化 | #9 Fowler 反馈飞轮、#19 Fowler Sensors |\n| 反馈瓶颈 / serial speed-up | #78 YDD 效率悖论 |\n\n---\n\n\n\n### 27. LangChain / Palash Shah — 我们如何构建 LangSmith Engine\n\n- **标题：** How we built LangSmith Engine: our agent for improving agents\n- **链接：** [langchain.com](https://www.langchain.com/blog/how-we-built-langsmith-engine-our-agent-for-improving-agents)\n- **中文译文：** [works/langsmith-engine-translation.md](../works/langsmith-engine-translation.md)\n- **作者：** Palash Shah | **日期：** 2026-05-19\n- **核心：** \"用智能体改进智能体\"的工程复盘。把 trace 压缩成轨迹骨架，用 screener（Haiku 子智能体）/ investigator 两阶段分工，CLI 作为统一接口，构成 issue → evaluator → 回归样本的闭环；issue 创建与 fix 生成分离。\n\n- **关键洞察：**\n - **trace → 轨迹骨架：** 压缩运行轨迹再交给智能体，是\"运行时 → 可观测 → 自动改进\"链条的关键一步。\n - **两阶段分工：** screener 先筛、investigator 再深挖，控制成本与上下文。\n - **闭环：** issue → evaluator → regression example，把一次性诊断变成可回归的适应度函数。\n - **创建与修复分离：** issue 创建和 fix 生成解耦，连接 repo 做 code-aware fix。\n\n- **与其他文章关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 用智能体改进智能体 / meta-harness | #7 Anthropic Meta-Harness、#24 Agentic Harness Engineering |\n| evaluator 作为适应度函数 | #10 LangChain 评估清单、#2 Fowler Sensors |\n| 运行时 → 可观测 → 改进链条 | #21 ADLC、#22 Deep Agents 解释器 |\n\n---\n\n\n\n### 28. Geoffrey Huntley — Ralph：最小可行 Harness 的原始出处\n\n- **标题：** Ralph Wiggum as a \"software engineer\"（2025-07）+ 续篇 everything is a ralph loop（2026-01-17）\n- **链接：** [ghuntley.com/ralph](https://ghuntley.com/ralph/) | [ghuntley.com/loop](https://ghuntley.com/loop/)\n- **作者：** Geoffrey Huntley | **日期：** 2025-07 / 2026-01-17\n- **核心：** Ralph 技术的方法论源头——\"Ralph 在最纯粹的形式下就是一个 bash 循环\"：`while true` 把 PROMPT.md 喂给编码智能体，每轮全新上下文窗口、一轮只做一件事，配背压验证。作者用它从零构建 CURSED 编程语言（训练集中不存在的语言）。本仓库 `practice/` 的 Ralph Demo 与已跟踪的 3 个 Ralph 项目此前一直缺这篇源头文献。\n\n- **关键洞察：**\n - **每轮只做一件事 + 信任模型选事：** 违反直觉的组合——既收窄单轮范围，又把\"什么最重要\"的决策权交给模型\n - **fix_plan.md 是外置状态：** TODO 列表是人类\"像鹰一样盯着\"的对象，构建 CURSED 期间被扔掉重生成多次——计划是耗材\n - **背压（backpressure）：** 改动后只跑该单元的测试；Rust 类型系统虽强但编译慢——\"轮速与正确性轴的平衡\"决定语言选择\n - **单体 vs 多智能体：** \"非确定性的微服务（智能体）= 一团红热的烂摊子\"；Ralph 是单体，单进程垂直扩展、单仓库自治\n - **失败域→工程化修复：** \"看到失败域，戴上工程师帽子把问题解决到永不再犯\"——与 Hashimoto 的 harness engineering 定义同源\n - **续篇的推广：** \"一切皆 ralph loop\"——loop 是通用的上下文工程模式，可用于所有任务；软件是陶轮上的黏土，不对就扔回轮上重塑\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| bash 循环 + 干净上下文 | #3 LangChain 的 Ralph Loop 组件、practice/ Ralph Demo |\n| 背压验证门 | 概念 3 机械化执行、#5 HumanLayer 的 Back-Pressure 杠杆 |\n| 计划是耗材 | README 的 Ralph 六信条 \"The Plan Is Disposable\" |\n| 单体反多智能体论 | #36 dynamic workflows（对照：模型自己写多智能体编排）、#16 Symphony |\n| 观察循环、调音式修复 | #29 Hashimoto 的 harness engineering 定义 |\n\n---\n\n\n\n### 29. Mitchell Hashimoto — 我的 AI 采纳之旅（\"harness engineering\" 命名出处）\n\n- **标题：** My AI Adoption Journey\n- **链接：** [mitchellh.com](https://mitchellh.com/writing/my-ai-adoption-journey)\n- **作者：** Mitchell Hashimoto（HashiCorp 联合创始人，Ghostty 作者） | **日期：** 2026-02-05\n- **核心：** 六步渐进采纳路线：放弃聊天机器人 → 复现自己的工作（手工做一遍再逼智能体做出同质结果）→ 日终智能体 → 外包稳赢任务 → 工程化 harness → 始终有智能体在跑。第 5 步给出了被业界广泛引用的 harness engineering 定义。多方学科史梳理公认本文是该术语的叫响者（与 OpenAI 原文同月）。原为本仓库\"延伸阅读\"，现升格为编号条目。\n\n- **关键洞察：**\n - **定义原文：** \"每当发现智能体犯错，就花时间工程化一个解决方案，使它永远不会再犯这个错误\"——两种形式：隐式提示（AGENTS.md）+ 程序化工具（截图脚本、过滤测试跑器）\n - **Ghostty 的 AGENTS.md 每一行都对应一次真实的坏行为**——与 Osmani \"每行可溯源到一次翻车\"的纪律互证\n - **复现自己的工作：** 刻意做两遍（先手工后智能体）是形成\"什么任务能交给智能体\"直觉的最快途径；效率增益的一半来自知道何时不用智能体\n - **人控制打断时机：** 关掉智能体桌面通知，\"由我决定何时打断它，而不是反过来\"——上下文切换是最贵的成本\n - **克制的自主性：** 一次只跑一个智能体、后台智能体覆盖 10–20% 工作时段；反对为跑而跑——\"只在真正有帮助的任务上跑\"\n - **对冲技能退化：** 委托智能体的同时手工做自己热爱的任务，抵消 Anthropic 技能形成论文指出的风险\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness engineering 定义 | #1 OpenAI 原文（同期独立提出）、#2 Böckeler（引用本文） |\n| 错误工程化=永不再犯 | #9 反馈飞轮的个人版、#28 Ralph 的调音式修复 |\n| AGENTS.md 行行有出处 | #31 Osmani 的约束加减法纪律、#5 HumanLayer 60 行规则 |\n| 何时不用智能体 | #14 Maganti 的能力边界经验、#26 Chris Parsons |\n\n---\n\n\n\n### 30. Claude Code 源码泄漏事件 — 512K 行 harness 的实锤解剖\n\n- **标题：** 事件 + 聚合分析：understanding-claude-code（综合 26 篇文章、7 个 HN 帖、10 份官方 TechDocs）\n- **链接：** [pankaj28843/understanding-claude-code](https://github.com/pankaj28843/understanding-claude-code) | 新闻报道：[InfoQ](https://www.infoq.com/news/2026/04/claude-code-source-leak/)\n- **作者：** 事件（当事人 Chaofan Shou，安全研究员；社区镜像扩散，无单一作者——本条为事件型收录） | **日期：** 2026-03-31（事件日）\n- **事件：** 2026-03-31，`@anthropic-ai/claude-code` v2.1.88 npm 包漏发 59.8MB 的 `cli.js.map`（缺一条 `.npmignore`，叠加 Bun 默认生成 source map 的已知 bug），~512,000 行 TypeScript / ~1,900 文件全裸；安全研究员 Chaofan Shou 发现，数小时内 GitHub 镜像扩散\n- **核心：** 业界第一次看到一线编码智能体 harness 的完整生产级源码。此前 #17（Rungta 逆向）只能从行为推测，泄漏把推测变成了可对照的实锤。\n\n- **实锤细节（此前只能猜测的部分）：**\n - **QueryEngine ~46K 行**：流式响应、工具调用循环、重试、token 追踪；工具可在模型还在流式输出时就开始执行\n - **60+ 权限门控工具（~29K 行 Tool.ts）**：遵循 Ousterhout \"deep modules\" 原则——简单接口藏重能力；\"Anthropic 花在优化工具上的时间超过优化总 prompt\"；工具描述本身是微型提示词\n - **工具结果预算**：BashTool 30K 字符、GrepTool 20K 字符，超额落盘到 `tool-results/{uuid}/` 留预览——上下文管理的机械化实现\n - **14 种缓存破坏向量追踪**（`promptCacheBreakDetection.ts`）：工具表变更、权限模式切换、CLAUDE.md 修改、MCP 连接等——#6 缓存优化五原则的工程落地\n - **未发布功能**：KAIROS 常驻后台 daemon（追加式日报）+ AutoDream 睡眠期记忆整理（727 行，闲时修剪/合并/组织会话记忆）+ Undercover Mode（对外仓库自动抹除内部信息与 AI 署名）\n - **教训**：source map 是被忽视的安全面——`npm pack --dry-run` 应进发布流水线\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 推测 vs 实锤对照 | #17 Rungta 逆向分析（TAOR 循环、权限光谱的推断如今可验证） |\n| 补上闭源样本的空白 | #13 Inside the Scaffold（当时因 Claude Code 闭源无法纳入分类法） |\n| 工具>prompt 的投资优先级 | #6 Anthropic 通用工具主张、概念 4 智能体可读性 |\n| 记忆整理（AutoDream） | #6 Pokemon 记忆进化案例的机制揭底 |\n| 发布流水线事故 | #23 质量回归复盘（同为 Anthropic 工程失误的第一手材料） |\n\n---\n\n\n\n### 31. Addy Osmani — Agent Harness Engineering（学科汇流综合）\n\n- **标题：** Agent Harness Engineering\n- **链接：** [addyosmani.com](https://addyosmani.com/blog/agent-harness-engineering/)（[O'Reilly Radar 2026-05-15 授权转载](https://www.oreilly.com/radar/agent-harness-engineering/)）\n- **第三方中译：** [掘金译文](https://juejin.cn/post/7642753947455356968)（未落盘本仓库）\n- **作者：** Addy Osmani（Google Cloud AI Director） | **日期：** 2026-04-19\n- **性质与破例说明：** 综述性质（同类的 Pachaar 综述归在\"中文转译/二手资料\"段不计数）。破例进编号正文的理由：它不只转述——给出了约束加减法纪律、hooks 分界论等可引用的原创表述，且是\"四学派汇流成一个学科\"的定调文（收藏/点赞比 2:1，读者当文档存）。\n- **核心：** \"编码智能体 = 模型 + 你围绕它构建的一切。Harness engineering 把这套脚手架当真正的工程产物；每当智能体失手，harness 就再收紧一圈。\"把 Trivedy（术语）、Horthy（追踪）、HumanLayer（skill issue）、Anthropic（长时设计）、Böckeler（用户侧）、Hashimoto（命名）缝成一张学科地图。\n\n- **关键洞察：**\n - **失败是可读的（legible）：** 不知道约定→加进 AGENTS.md；跑了破坏性命令→加 hook 拦截；40 步任务迷路→拆 planner/executor；反复\"完成\"坏代码→接 typecheck 背压\n - **约束的加减法纪律：** 只在见过真实失败后加约束，只在模型能力使其冗余后删；\"好的 AGENTS.md 每一行都应能溯源到一次具体翻车\"\n - **hooks 是分界线：** \"我告诉过智能体做 X\" vs \"系统强制执行 X\"——lifecycle 脚本承载永不能忘的事（typecheck/lint/测试、拦 `rm -rf` / force push、PR 前审批、写后自动格式化）\n - **模型与 harness 后训练耦合：** Opus 4.6 在 Claude Code 里的 Terminal Bench 2.0 分数远低于同模型在定制 harness 里；Viv 团队只改 harness 就 Top 30 → Top 5（#35 论文给出了这一现象的统计版本）\n - **HaaS（Harness-as-a-Service）：** 从构建于 LLM API（给 completion）转向构建于 harness API（给 runtime）——Claude Agent SDK / Codex SDK / OpenAI Agents SDK 同向\n - **Ralph Loop 的价值重申：** \"hook 拦截退出、往新上下文窗口重注提示词\"是从\"用更聪明的模型\"永远推导不出来的原语\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 六人六视角的汇流地图 | #3 Trivedy、#5 HumanLayer、#4 Anthropic、#2 Böckeler、#29 Hashimoto |\n| 约束加减法纪律 | #4 harness 瘦身、#29 AGENTS.md 行行有出处 |\n| Terminal Bench harness 效应 | #35 统计归因论文、#3 的原始数据点 |\n| HaaS | #7 Managed Agents、#21 ADLC 的 framework/runtime/harness 三分 |\n| 四学派汇流 | thinking/cross-article-insights 的学派划分 |\n\n---\n\n\n\n### 32. Thoughtworks / Böckeler & Ford — 传感器实验：有无反馈回路的对照\n\n- **标题：** Harness engineering and agent feedback: Exploring AI coding sensors\n- **链接：** [thoughtworks.com](https://www.thoughtworks.com/en-au/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors)\n- **作者：** Birgitta Böckeler, Chris Ford (Thoughtworks) | **日期：** 2026-05-13\n- **核心：** #19（可维护性传感器谱系）的实验化姊妹篇。在一个 TypeScript 数据仪表板上做**有/无传感器套件的对照实验**（ESLint、Semgrep 静态分析 + Dependency Cruiser 模块边界 + 覆盖率报告 + mutation testing），配套视频演示。\n\n- **关键洞察：**\n - **实验结果：** 配备质量反馈传感器的编码智能体能随时间持续改善质量（如提升测试覆盖率）；无传感器则原地踏步\n - **行业失衡诊断：** 2026 上半年业界注意力集中在 skills（前馈），sensors（反馈）被系统性低估——\"完美世界只需前馈；我们不住在那个世界里\"\n - **从叮嘱到保证：** \"反复求智能体写测试并祈祷它够自觉\" → 确定性约束给出保证；LLM 判断适合模糊探索区，客观一致的要求要交给形式化确定性工具\n - **态势感知而非全自动：** \"harness engineering 不是全自动化，而是开发者的态势感知\"——红绿传感器仪表板 = 代码库体检单，指示该把精力再投资到 harness 的哪里\n - **Harness 模板展望：** 未来不再每个项目从头搭 harness，而是按应用类型取用预配置模板（数据仪表板模板、CRUD 业务服务模板）——#2 的 harness 模板假说落到具体形态\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 传感器对照实验 | #19 传感器谱系（同作者的实操续篇） |\n| 前馈/反馈失衡 | #2 Guides×Sensors 框架、#5 六杠杆 |\n| 确定性约束 > 反复叮嘱 | 概念 3 机械化执行、#25 Overeager（提示声明反而降低边界推断） |\n| harness 模板 | #2 的假说 1、#21 ADLC |\n\n---\n\n\n\n### 33. HarnessAudit 论文 — Harness 安全审计（安全面的开辟）\n\n- **标题：** Auditing Agent Harness Safety\n- **链接：** [arxiv.org/abs/2605.14271](https://arxiv.org/abs/2605.14271)\n- **作者：** Chengzhi Liu, Yichen Guo, Yepeng Liu, Yuzhe Yang, Qianqi Yan, Xuandong Zhao, Wenyue Hua, Sheng Liu, Sharon Li, Yuheng Bu, Xin Eric Wang | **日期：** 2026-05 | **arXiv：** 2605.14271\n- **核心：** 开辟本仓库此前完全缺失的维度——**harness 是安全面**。核心观察：harness 可以在\"返回正确且良性的最终答案\"的同时，轨迹中途访问未授权资源、或把上下文泄给错误的智能体——**输出级评估看不见这些失败**，而多数安全基准只给最终输出/终态打分。提出 HarnessAudit 框架（审计完整执行轨迹的边界合规、执行保真、系统稳定三维）+ HarnessAudit-Bench（210 任务 × 8 个真实领域，单/多智能体配置，内嵌安全约束）。\n\n- **关键发现（评测 10 种 harness 配置 × 前沿模型 × 3 个多智能体框架）：**\n - **任务完成与安全执行不对齐**，违规随轨迹长度累积——长时自主运行天然扩大风险\n - 安全风险随领域、任务类型、智能体角色而异\n - 违规集中在**资源访问**与**智能体间信息传递**两类\n - 多智能体协作扩大安全风险面；**harness 设计决定安全部署的上限**\n- **传播语境：** 被转发时的定性——\"业界正在意识到：harness 是产品，也是安全面。该审计的不只是模型，还有 prompt、工具、权限、记忆、执行层。AI 安全的下一个前沿是 harness 安全。\"（#37 作者马东锡转发）\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 中途轨迹违规 vs 输出级评估 | #25 Overeager（越界动作测量——本文把它推进到审计框架） |\n| 权限边界与信息流约束 | #7 Managed Agents 的安全边界解耦、#30 泄漏实锤的权限分类器 |\n| 多智能体扩大风险面 | #18 subagent 的 runtime state 追踪、#36 dynamic workflows 的千级扇出 |\n| harness 决定安全上限 | #37 \"可靠性的东西都属于 harness\" |\n\n---\n\n\n\n### 34. Harness-Bench 论文 — 配置级 harness 效应的诊断基准\n\n- **标题：** Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows\n- **链接：** [arxiv.org/abs/2605.27922](https://arxiv.org/abs/2605.27922)\n- **作者：** Yilun Yao, Xinyu Tan, Chao-Hsuan Liu 等 12 人 | **日期：** 2026-05 | **arXiv：** 2605.27922\n- **核心：** 现有基准要么抽象掉执行层、要么比较完整智能体系统、要么固定 harness——执行层变异一直难以研究。Harness-Bench 用 106 个沙箱离线任务（从实际 agent 使用模式构造，人工审核真实性/可解性/oracle 可检验性/完整性），在共享任务环境、预算与评估协议下评测代表性 harness 配置 × 多模型后端，同时**保留各 harness 的原生执行行为**。\n\n- **关键洞察：**\n - **5,194 条执行轨迹的结论：** 完成率、过程质量、效率、失败行为在 model-harness 配对间差异巨大——**智能体能力应按\"模型-harness 配置\"报告，而非归于基座模型**\n - **执行对齐失败（execution-alignment failures）：** 反复出现的失败类型——貌似合理的推理与工具反馈、工作区状态、证据、可验证输出契约**脱钩**\n - 每次运行记录最终工件、执行轨迹、用量统计、校验器输出——支持超越\"最终完成与否\"的过程分析\n - 直接回应本仓库缺口清单的\"Harness 覆盖率评估方法\"\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| 按 model-harness 配置报告能力 | #35 统计归因（榜单侧的同一主张）、#38 Position（立场侧） |\n| 执行对齐失败 | #24 AHE 的决策可观测性、#27 LangSmith Engine 的轨迹骨架 |\n| 过程质量 > 最终完成 | #33 HarnessAudit（安全侧的同构主张：中途轨迹才是关键） |\n\n---\n\n\n\n### 35. How good is your harness? 论文 — harness 效应的统计归因\n\n- **标题：** How good is your harness? Statistical evaluation of coding harnesses\n- **链接：** [openreview.net forum](https://openreview.net/forum?id=QI8z3skBwt)（[PDF 直链](https://openreview.net/pdf/99eabc2ce65fd2871a253a0a57954c934ea9e6b0.pdf)）\n- **作者：** Jiwoo Han, Yuekai Sun（密歇根大学统计系） | **日期：** 2026-05-25（OpenReview 发布，2026-06-16 末次修订） | **发表：** CTB@ICML 2026 workshop（首尔）\n- **核心：** 用纯统计方法（加性 GLM，logit link）把 Terminal-Bench 2.0 榜单的分数方差拆解归因到 harness 效应与 LLM 效应——不依赖 LLM 标注轨迹，只需要足够交叉的 harness×LLM 榜单设计。数据：清洗后 105 个 harness-LLM 对（28 个 harness × 26 个 LLM）。\n\n- **两个定量结论：**\n 1. **harness 与 LLM 同等重要：** 从基线 harness 换到最优 harness 的分数跃升 ≈ 从基线 LLM 换到最优 LLM 的跃升——\"harness 不是实现细节，是性能的关键组件\"第一次有了量化版本\n 2. **harness 效应异质：** 某些 harness 与某些 LLM 更配（如 OpenHands 配 OpenAI 模型好于配 Anthropic/Google 模型）；交互效应量级堪比主效应——harness 和 LLM **不是可完全互换的组件**\n- **对本仓库缺口的意义：** \"跨模型可移植性\"缺口的第一份定量证据——迁移 harness 到新模型时收益不保序，压测（#4 的\"定期重新压测假设\"）有了统计学理由\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 效应 ≈ 模型效应 | #3 Trivedy 的 Top 30→Top 5 轶事（本文把轶事升级为估计量）、#31 Osmani 引用的数据点 |\n| 效应异质 / 模型-harness 耦合 | #3 的\"模型 overfit 到训练 harness\"、#4 harness 瘦身 |\n| 榜单统计方法 | #34 Harness-Bench（受控实验侧）、#38 Position（立场侧）——评测三部曲 |\n\n---\n\n\n\n### 36. Anthropic / Claude — 动态工作流：模型现场写自己的 harness\n\n- **标题：** A harness for every task: dynamic workflows in Claude Code\n- **链接：** [claude.com/blog](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code)\n- **翻译：** [works/anthropic-dynamic-workflows-translation.md](../works/anthropic-dynamic-workflows-translation.md)\n- **作者：** Thariq Shihipar, Sid Bidasaria（Anthropic Claude Code 团队） | **日期：** 2026-06-02（功能随 Claude Code 2.1.154 + Opus 4.8 于 2026-05-28 发布）\n- **核心：** harness 本体论的转折点——Claude 现在**为任务现场编写自己的 JavaScript 编排脚本**，即一次性定制 harness。默认 Claude Code harness 要在同一个上下文窗口里既规划又执行，在长时运行、大规模并行、高度结构化、对抗性任务上会崩；dynamic workflows 把编排逻辑放进代码（在 token 上近乎免费），单会话扇出数十到数百个并行 subagent，各自在隔离上下文窗口内执行聚焦目标。\n\n- **关键洞察：**\n - **静态 workflow 的宿命是泛化损耗：** 预置工作流必须覆盖所有边界情况所以偏通用；Opus 4.8 已足够聪明为具体用例现写定制 harness——#4\"每个 harness 组件编码一个假设\"在这里变成\"假设由模型即时生成\"\n - **编排即代码：** workflow 可决定每个 agent 用什么模型、是否跑在独立 git worktree——智能等级与隔离度成为可编程参数\n - **对抗验证模式：** 每个生成 agent 配一个独立 agent 按 rubric 对抗校验其输出，收敛后才交付用户；官方 `/deep-research` skill 即此模式（扇出搜索→抓源→对抗核查→合成引用报告）\n - **激活策略：** 提示词含 \"workflow\" 触发，或用 \"ultracode\" 触发词确保建 workflow——回应本仓库缺口清单的\"控制激活策略\"\n - **workflow 是可沉淀资产：** 生成的脚本可检查、保存、复用，经 Skill 分发——一次性 harness 固化为版本化自动化\n - **反向蒸馏：** 挖掘近期 session 和 code review 评论中反复出现的纠正 → 并行 agent 聚类 → 对抗验证每条候选（\"这条规则真能防住一次真实错误吗？\"）→ 幸存者蒸馏回 CLAUDE.md\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 从人写工件变成模型生成工件 | #11 Meta-Harness、#24 AHE（自动搜索/演化的产品化收束）、#7 meta-harness |\n| 编排放进代码以省上下文 | #22 Deep Agents 解释器、#16 Symphony 控制平面 |\n| 对抗验证 | #4 的 Evaluator 分离、#10 评估清单 |\n| 千级 subagent 扇出 | #18 subagent 的 runtime state 管理、#33 多智能体风险面 |\n| 与 Ralph 单体论的张力 | #28 Huntley \"现阶段不需要多智能体\"——一年后官方产品反向而行 |\n\n---\n\n\n\n### 37. 马东锡 NLP — Harness 才是产品\n\n- **标题：** Harness 才是产品：决定 Coding Agent 体验的不是 Model，是它周围的整套 Runtime（Harness 系列）\n- **链接：** [SOTA Sync 转载页](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/)（原文发布于 X @dongxi_nlp，原帖需登录访问，本条目暂链转载页）\n- **作者：** 马东锡 NLP (@dongxi_nlp) | **日期：** 2026-06\n- **核心：** 把系列观点收束成一条产品论断：聊 coding agent 第一个该问的不是\"用哪个 model\"，而是\"**Harness 到底负责什么**\"。coding agent = 把 model 放进一套 runtime（查真实 repo、请求 tool、编辑文件、跑检查、记住发生过什么、多轮推进）——这层 runtime 就是 harness，\"对 coding agent 来说，harness 本身就是 product\"。\n\n- **关键洞察：**\n - **Mini agent 的五个真实爆点：** 编辑从没读过的文件 / shell 触碰 workspace 外 / tool 返回 50,000 行输出 / 磁盘文件已变而 transcript 还是旧读 / tool result 与 tool call 对不上——画出「observe → model → tool」草图的系统还不是 coding agent\n - **六个核心组件：** live repo context / prompt shape / structured tools / context reduction / transcripts & memory / delegation；\"context quality 经常看起来像 model quality\"\n - **\"Model 在 loop 里，harness 拥有 loop\"：** 一个 `edit src/config.py` tool call 只是 proposal，harness 要回答十来个裁决问题（path 是否在 workspace 内、会否经 symlink 逃逸、baseline 是否过期、要否 human approval、多少 output 进下一轮 prompt……）——\"这些判断不该交给 model 的随机处理\"\n - **Transcript ≠ working state：** \"发生过什么\"与\"现在什么重要\"是两份不同任务，必须区别对待\n - **症状→组件的 debug 对照表：** 不断重复→查 loop/retry policy；编辑 stale code→查 file-state baselines；越跑越差→查 context projection；运行意外东西→查 permission policy；无法从 tool error 恢复→查 tool result objects\n - **工程规则收尾：** \"Anything that must be reliable belongs in the harness.\"\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness 拥有 loop / 裁决权 | #18 subagent（同系列前作：tool call outside, runtime inside） |\n| harness 是安全面 | #33 HarnessAudit（作者本人转发并背书） |\n| proposal vs 落实边界 | #25 Overeager（提示声明 vs 机械门控）、#31 hooks 分界论 |\n| context projection | #6 context editing、#22 第三类上下文表面 |\n\n---\n\n\n\n### 38. Position 论文 — 编码基准与智能体软件工程的错位\n\n- **标题：** Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering\n- **链接：** [arxiv.org/abs/2606.17799](https://arxiv.org/abs/2606.17799)\n- **作者：** Maria I. Gorinova, Macey Baker, Amy Heineike, Maksim Shaposhnikov, Rob Willoughby, Dru Knox | **日期：** 2026-06 | **arXiv：** 2606.17799\n- **核心：** 立场论文——我们用来比较编码智能体的基准诞生于前智能体时代：把 model、harness、environment 折叠进一个端到端分数，通常按单一参考解评分，没有可迭代的组件级信号。\"实践中的编码智能体不是模型，是 system harness——models/harnesses/contexts/environments/feedback signals 的复合体，其中任何一项都能把基准分数挪动一个相邻模型代际的量级。\"\n\n- **三个症状：**\n 1. 基准分数把模型与 harness 其余部分**混同**——排行榜差异无法归因\n 2. 按单一参考解评分**惩罚同样有效的替代方案**——真实工程里一题多解是常态\n 3. 缺少单个 harness 组件级别的信号，端到端系统分数**难以迭代**——你不知道该修哪里\n- **对本仓库的意义：** 与 #34（受控实验）、#35（榜单统计归因）构成\"harness 评测三部曲\"；也为 thinking/evaluation-elephant-in-the-room 的\"行为 harness 是大象\"补上评测学的病理诊断\n\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| model/harness/environment 折叠 | #35 的统计拆解方案、#34 的配置级测量方案 |\n| 单参考解惩罚多解 | #10 评估清单的 LLM-as-judge 校准 |\n| 组件级信号缺失 | #24 AHE 的三类可观测性（正是组件级信号的一种供给） |\n\n---\n\n\n\n### 39. OpenAI / Michael Bolin — 展开 Codex agent loop（Codex harness 解剖 · 上）\n\n- **标题：** Unrolling the Codex agent loop\n- **链接：** [openai.com](https://openai.com/index/unrolling-the-codex-agent-loop/)\n- **作者：** Michael Bolin (OpenAI, Codex CLI 团队) | **日期：** 2026-01-23\n- **核心：** Codex 系列工程博客第一篇——把 Codex CLI 的 agent loop（\"我们的 agent，或曰 harness\"）逐层展开：从用户输入构造初始 prompt、经 Responses API 推理、执行工具调用并把输出追加回 `input`，直到模型产出 assistant message 结束一个 turn。是官方视角下 harness 内部机制的最细粒度公开拆解。\n- **关键洞察：**\n - **prompt 是\"item 列表\"：** `instructions`（模型特定指令）+ `tools`（shell / update_plan / web_search / MCP 工具）+ `input`（sandbox 说明 → developer 指令 → AGENTS.md 聚合的用户指令 → environment_context → 用户消息）——AGENTS.md 从 git 根到 cwd 逐层聚合、默认 32 KiB 上限的机制被首次官方成文\n - **agent loop 天然是二次方的：** 每轮把全部历史重发；Codex 刻意不用 `previous_response_id` 以保持请求无状态并支持 ZDR（零数据保留），靠 prompt caching 把采样成本从二次方拉回线性\n - **缓存破坏向量：** 中途改 tools、换模型、改沙箱/审批/工作目录都会 cache miss；MCP 工具枚举顺序不稳定曾是真实 bug——应对策略是\"追加新消息表达变更，而不是改旧消息\"（与 #6 缓存五原则、#30 泄漏实锤的 14 种缓存破坏向量互证）\n - **compaction 的演进：** 从手动 `/compact`（用摘要替换 input）到 Responses API 专用 `/responses/compact` 端点——返回含 `encrypted_content` 的 `type=compaction` item，保留模型对原对话的潜在理解，超过 `auto_compact_limit` 自动触发\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| harness = agent loop 的官方自述 | #3 LangChain 的 Agent = Model + Harness、#17 Claude Code 逆向（对照组：Codex 侧的官方版） |\n| prompt caching 工程细节 | #6 缓存优化五原则、#30 泄漏实锤的缓存破坏向量追踪 |\n| AGENTS.md 聚合机制 | #5 HumanLayer 的 AGENTS.md 杠杆、概念 2 地图而非手册 |\n| compaction 端点化 | #7 Managed Agents 的 Session 外部存储、#22 上下文表面分层 |\n\n---\n\n\n\n### 40. OpenAI / Celia Chen — 解锁 Codex harness：App Server（Codex harness 解剖 · 下）\n\n- **标题：** Unlocking the Codex harness: how we built the App Server\n- **链接：** [openai.com](https://openai.com/index/unlocking-the-codex-harness/)\n- **作者：** Celia Chen (OpenAI) | **日期：** 2026-02-04\n- **核心：** Codex 的 web / CLI / IDE 扩展 / macOS 应用全部由同一个 Codex harness 驱动，而把这个 harness 暴露给所有客户端的是 Codex App Server——一个双向 JSON-RPC（JSONL over stdio）协议 + 长驻进程。把 harness 从产品内部件变成可被第三方集成的稳定平台面（HaaS 的 OpenAI 实现）。\n- **关键洞察：**\n - **三个对话原语：** Item（原子输入/输出单元，带 `started`/`delta`/`completed` 生命周期）、Turn（一次用户输入触发的工作单元）、Thread（可创建/恢复/fork/归档的持久容器）——为\"agent 交互不是请求/响应\"给出协议级建模\n - **协议是双向的：** 服务器可以主动发起请求（如审批），暂停 turn 直到客户端应答——权限门控被编进协议而非提示词\n - **harness 内容物 = agent loop + thread 生命周期与持久化 + 配置与认证 + 工具执行与扩展（sandbox、MCP、skills）**——官方划出的 harness 边界清单\n - **集成谱系：** App Server（全功能）> Codex SDK > MCP server 模式 > `codex exec`（CI 一次性）；跨厂商 harness 协议会收敛到能力交集，丰富交互难以表达——对\"标准化 vs 表达力\"权衡的一手表态\n - Codex Web 在容器里跑同一个 App Server 二进制，状态留在服务端，浏览器只是轻客户端——ephemeral 会话的断线重连由持久 thread 兜底\n- **与其他文章的关联：**\n\n| 本文概念 | 对应文章 |\n|---------|---------|\n| HaaS（Harness-as-a-Service） | #31 Osmani 的 HaaS 论、#7 Managed Agents 的 harne\n\n\n# 工具地图：复杂度维度 ↔ 工具杠杆\n\n> 配套 [software-project-complexity-in-the-ai-era.md](../thinking/software-project-complexity-in-the-ai-era.md) 的6 维复杂度框架使用。\n\n---\n\n## 思路\n\n每个工具的真正价值，不是它的功能列表，而是：\n\n> **它能切实降低 AI 接管难度的哪一维？**\n\n如果一个工具不能映射到任何一维复杂度的下降，它就不应该出现在这里。\n\n---\n\n## 维度 × 工具矩阵\n\n\n### 六个分子维度（越高越复杂）\n\n| # | 复杂度维度 | 工具杠杆候选 | 实测笔记 |\n| --- | ------ | ------------------------------- | ---- |\n| 1 | 上下文压力 | [待补：检索 / 语义索引 / 上下文压缩] | [待补] |\n| 2 | 可提示性 | [待补：SPEC 模板 / DSL / 业务建模] | [待补] |\n| 3 | 探索收敛 | [待补：AGENTS.md / 项目地图 / sitemap] | [待补] |\n| 4 | 状态纠缠 | [待补：模块边界检查 / 依赖图 / ArchUnit 类] | [待补] |\n| 5 | 暗知识 | [待补：ADR / 决策记录 / 注释规范] | [待补] |\n| 6 | 验证成本 | [ralph-orchestrator](harnesses/ralph-orchestrator.md)（背压门控，主战场）；另待补：测试框架 / CI / 类型检查 / linter | ✅ [practice/01](../practice/01-ralph-demo/) 实测：Builder 测试全绿才交棒 + Critic 独立重验 |\n\n### 分母：胶囊化能力（越高越好）\n\n| 维度 | 工具杠杆候选 | 实测笔记 |\n| --------- | ------------------------------------- | ---- |\n| **胶囊化能力** | Claude Code / Codex / Cursor / ... 等各大 harness 框架 | Harness 框架的核心价值——让 AI 在可控边界内完成任务，从而把上面六维的成本同时压下来 |\n\n### 终局指标：重构 + 复刻\n\n> 文章最后指出\"重构能力 + 复刻能力\"是复杂度的最终显影。一个工具是否值得收录，最终可以问：**它是否提升了项目的重构 / 复刻可行性？**\n\n注：同一个工具可能横跨多维。**填表时按\"主战场\"放，次要贡献在工具页里展开。**\n\n---\n\n## 收录工具（持续更新）\n\n### Harness 框架\n\n> 作者使用为主，已在 [practice/](../practice/) 中跑过的优先标注 ✅\n\n- ✅ [ralph-orchestrator](harnesses/ralph-orchestrator.md) — 已在 [practice/01-ralph-demo/](../practice/01-ralph-demo/) 实测（v2.8.1，4 轮迭代 / 321s / $0.31）\n- Claude Code（practice/01 中作为 Ralph 的执行后端使用过；独立工具页待写）\n- Codex CLI/ Codex App\n- Cursor\n- [其他待补]\n\n### 辅助工具\n\n> 按 6 维分类组织\n\n- [待补]\n\n---\n\n## 撰写新工具页的检查清单\n\n- 是否回答了\"它降低了哪几维复杂度\"\n- 是否给出至少一个**失效场景**（不是只写优点）\n- 是否标注与其他已收录工具的搭配 / 冲突\n- 是否说明\"为什么是它而不是同类竞品\"\n\n\n# Harnesses Skill\n\nPath: `tools/harnesses/ralph-orchestrator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/deusyu/harness-engineering/HEAD/tools/harnesses/ralph-orchestrator.md)\n\n\n# 深度研究追踪 Prompt\n\n> 用途：定期（每 1-2 周）运行，发现 harness engineering / AI 编程领域的高价值新内容\n> 推荐工具：ChatGPT Deep Research（广度搜索）→ Claude（深度分析 + 项目关联）\n\n---\n\n## Prompt A：ChatGPT Deep Research — 广度发现\n\n```\n你是一个技术情报分析师。请对以下领域进行深度网络搜索，找出过去 2 周内（{START_DATE} 至 {END_DATE}）发布的高价值内容。\n\n### 搜索领域\n\n核心主题：\n1. Harness Engineering — AI 编码智能体的约束、引导、反馈系统设计\n2. Context Engineering — 上下文窗口管理、compaction、渐进式披露\n3. AI Coding Agents — 编码智能体的架构、编排、评估\n4. Agent Infrastructure — 沙箱、会话管理、多智能体协作\n5. AI-assisted Software Engineering — AI 辅助开发的效率、流程、组织影响\n\n相关关键词（中英文）：\n- harness engineering, agent harness, coding agent, AI coding\n- context engineering, context window, compaction, progressive disclosure\n- AGENTS.md, CLAUDE.md, agent readability, agent-first\n- managed agents, meta-harness, multi-agent orchestration\n- AI code review, mutation testing, structural testing, fitness functions\n- vibe coding, AI-native development, agentic workflow\n- 智能体工程, AI 编程, 上下文工程, 护栏工程\n\n### 搜索范围\n\n必须覆盖的信源（按优先级）：\n\n**Tier 1 — 高权重（模型厂商 + 顶级技术博客）：**\n- Anthropic Engineering Blog (anthropic.com/engineering)\n- OpenAI Blog (openai.com)\n- Google DeepMind / Google AI Blog\n- Martin Fowler (martinfowler.com)\n- Mitchell Hashimoto (mitchellh.com)\n- LangChain Blog (blog.langchain.com)\n- Simon Willison (simonwillison.net)\n\n**Tier 2 — 中权重（社区 + 行业）：**\n- Hacker News (前 100 讨论)\n- GitHub Trending (相关仓库)\n- X/Twitter 技术社区 (#harness-engineering, #ai-coding, #context-engineering)\n- Dev.to, Medium 技术专栏\n- HumanLayer, Cursor, Windsurf, Codex 相关博客\n- 中文社区：少数派、掘金、知乎专栏\n\n**Tier 3 — 低权重但可能有惊喜：**\n- arXiv (cs.SE, cs.AI 交叉)\n- 个人技术博客\n- YouTube 技术频道\n- Reddit (r/LocalLLaMA, r/ChatGPT, r/programming)\n\n### 我们已知的内容（用于去重和关联）\n\n> **本节是 Prompt 的去重权威**——给外部搜索器（ChatGPT Deep Research 等）使用。\n> 它必须自包含，因为搜索器无法访问 `references/articles.md`。\n>\n> **维护纪律：** 当 `references/articles.md` 新增/删除条目时，**同一次提交中**必须同步更新本节。两份内容的口径（脉络划分、篇数、产品/项目清单）应保持完全一致。\n> 本节最近一次同步：2026-08-27（与 `articles.md` 当前内容对齐：79 篇文章 + 1 项已跟踪产品）。\n\n**核心文章 79 篇，分布于三条脉络：**\n\n- **脉络一 — AI 时代 Harness Engineering（75 篇）：**\n - OpenAI \"Harness engineering\"（原点，2026-02-11）/ \"An open-source spec for Codex orchestration: Symphony\"（2026-04-27，任务跟踪器作为控制平面）\n - Fowler/Böckeler \"Harness engineering for coding agent users\"（2026-04-02）+ 前传备忘录（2026-02-17）\n - LangChain \"The Anatomy of an Agent Harness\"（2026-03）/ \"Continual Learning for AI Agents\"（2026-04-05）/ \"Agent Evaluation Readiness Checklist\"\n - Anthropic \"Harness design for long-running application development\"（2026-03-24）\n - Anthropic / Lance Martin \"Harnessing Claude's intelligence\"（2026-04-02，三大模式与性能数据）\n - Anthropic \"Scaling Managed Agents\"（2026-02-04，meta-harness 与基础设施解耦）\n - HumanLayer \"Skill Issue\"（2026-03，六杠杆与避坑）\n - Fowler / Rahul Garg \"Encoding team standards\"（2026-03）/ \"Feedback flywheel\"（2026-03）\n - Meta-Harness 论文（自动化 Harness 优化）\n - GitHub / Tyler McGoffin \"Agent-Driven Development\"（实战）\n - \"Inside the Scaffold\" 论文（编码智能体脚手架的源代码级分类法）\n - Lalit Maganti \"渴望八年，用 AI 三个月造出来\"\n - Vikash Rungta \"Claude Code Architecture (Reverse Engineered)\"（2025-11-01，Claude Code 运行外壳、TAOR 循环、工具原语、权限与上下文管理的外部逆向分析）\n - 马东锡 NLP \"Harness 系列文章之 7：关于 subagent\"（2026-06-22，subagent = tool call 入口 + child runtime，区分 session/context/subagent，与 Claude Code 逆向互证）\n - Fowler/Böckeler \"Maintainability sensors for coding agents\"（2026-05-20，计算性 vs 推理性传感器谱系 + 失败案例 + AI 评审作为垃圾回收）\n - Fowler \"Structured-Prompt-Driven Development (SPDD)\"（2026-04-28，REASONS Canvas 七维 + prompt 即一等交付物 + 双向闭环）\n - LangChain / Harrison Chase \"The Agent Development Lifecycle (ADLC)\"（2026-05-09，framework/runtime/harness 三分类的生命周期）\n - LangChain / Hunter Lovell \"Interpreters in Deep Agents\"（2026-05-20，interpreter 是第三类上下文表面 + 35% token 节省）\n - Anthropic 工程团队 \"An update on recent Claude Code quality reports\"（2026-04-23，三起独立变更叠加成质量退化的第一手复盘）\n - Agentic Harness Engineering 论文（arXiv 2604.25850，复旦/北大/奇绩，可观测性驱动的 Harness 自动演化 + 可证伪契约）\n - Overeager Coding Agents 论文（arXiv 2605.18583，越界动作测量 + 提示声明授权反而降低边界推断）\n - Chris Parsons \"How I Use AI to Code\"（2026-05，四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈；含译者注，2026 数据未独立核实）\n - LangChain / Palash Shah \"How we built LangSmith Engine\"（2026-05-19，用智能体改进智能体，trace→轨迹骨架 + screener/investigator 两阶段闭环）\n - Geoffrey Huntley \"Ralph Wiggum as a software engineer\"（2025-07）+ \"everything is a ralph loop\"（2026-01-17，bash 循环 + 干净上下文 + 背压 + 单体反多智能体论）\n - Mitchell Hashimoto \"My AI Adoption Journey\"（2026-02-05，六步采纳路线 + \"harness engineering\" 命名出处）\n - Claude Code 源码泄漏事件（2026-03-31，v2.1.88 npm source map 泄 512K 行 TypeScript；聚合分析 pankaj28843/understanding-claude-code：QueryEngine ~46K 行、60+ 门控工具、KAIROS/AutoDream/Undercover Mode）\n - Addy Osmani \"Agent Harness Engineering\"（2026-04-19，O'Reilly 转载；学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS）\n - Thoughtworks / Böckeler & Ford \"Exploring AI coding sensors\"（2026-05-13，有/无传感器对照实验 + harness 模板展望）\n - HarnessAudit 论文（arXiv 2605.14271，harness 安全审计：中途轨迹违规是输出级评估盲区，210 任务基准）\n - Harness-Bench 论文（arXiv 2605.27922，配置级 harness 效应：106 任务 / 5194 轨迹 + 执行对齐失败）\n - \"How good is your harness?\"（CTB@ICML 2026，Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应且异质）\n - Anthropic/Claude \"A harness for every task: dynamic workflows in Claude Code\"（2026-06-02，模型现场写自己的编排 harness + 对抗验证 + ultracode 触发）\n - 马东锡 NLP \"Harness 才是产品\"（2026-06，Model 在 loop 里 harness 拥有 loop + 六组件 + 症状→组件 debug 表）\n - Position 论文 \"Coding Benchmarks Are Misaligned with Agentic SE\"（arXiv 2606.17799，基准折叠 model/harness/环境的三症状）\n - OpenAI \"Unrolling the Codex agent loop\"（2026-01-23，Codex harness 解剖·上：prompt 构造 / 二次方与 prompt caching / compaction 端点化）\n - OpenAI \"Unlocking the Codex harness\"（2026-02-04，Codex harness 解剖·下：App Server 双向 JSON-RPC + Item/Turn/Thread 原语 + HaaS）\n - Addy Osmani \"Loop Engineering\"（2026-06-08，loop 定调文：五构件 + 记忆脊柱；上游为 Steinberger 推文与 Boris Cherny \"我的工作是写循环\"）\n - Armin Ronacher \"The Coming Loop\"（2026-06-23，怀疑派回应：agent loop vs harness loop + 防御式编码放大 + 软件作为有机体）\n - Anthropic/Claude Code 团队 \"Loop engineering: Getting started with loops\"（2026-06-30，官方四类循环 turn/goal/time/proactive + `/goal` 独立判停）\n - Self-Harness 论文（arXiv 2606.09498，智能体自改 harness：弱点挖掘→提议→回归验证，三模型 held-out +14~21pp）\n - Lilian Weng \"Harness Engineering for Self-Improvement\"（2026-07-04，RSI 综述：三设计模式 + 优化对象递进链 + 七项未来挑战）\n - Aria 论文 \"Harnessing Code Agents for Automatic Software Verification\"（arXiv 2607.06341，声明式 HHL 包裹通用智能体做 Coq 证明，行为 harness 极限形态）\n - Anthropic \"Demystifying evals for AI agents\"（2026-01-09，智能体评测官方方法论：outcome≠transcript、pass@k/pass^k、CORE-Bench 42%→95% 基准病理）\n - Cursor / Wilson Lin \"Scaling long-running autonomous coding\"（2026-01-14，数百并发智能体 × 数周：planner/worker/judge + FastRender 百万行浏览器）\n - Anthropic / Nicholas Carlini \"Building a C compiler with a team of parallel Claudes\"（2026-02-05，16 agent 无编排者 + GCC oracle + $20k 成本账本）\n - Anthropic \"How we contain Claude across products\"（2026-05-25，三隔离模式 + 五起漏掉的风险：白名单是能力授予、先环境层遏制）\n - LangChain \"Introducing Dynamic Subagents in Deep Agents\"（2026-06-29）+ \"How to Use RLMs in Deep Agents\"（2026-07-01，模型写编排脚本 + RLM 递归上下文）\n - Fowler/Böckeler 本地模型双备忘录（2026-07 上旬，Qwen3.6 35B MoE 甜点 + 工具调用是智能体化分水岭）\n - Harness Handbook 论文（arXiv 2607.13285，2026-07-14，行为定位是 harness 演化瓶颈：行为中心表示 + BGPD）\n - Fowler / Unmesh Joshi \"DSLs Enable Reliable Use of LLMs\"（2026-07-14，DSL 工具集即 harness：语言层约束 + 确定性验证器）\n - Addy Osmani \"Own the Outer Loop\"（2026-07-15，AIE 闭幕演讲：智能体跑内环、工程师拥有外环问责 + back-pressure 调速）\n - Jarred Sumner \"Rewriting Bun in Rust\"（2026-07-08，50 dynamic workflows × 峰值 64 Claude × 11 天机械移植 53.5 万行 Zig→Rust；语言无关测试套件作 oracle + 1 实现者/2 对抗评审者/1 修复者 + \"修流程不修代码\"；$165k API 成本账本）\n - HarnessX 论文（arXiv 2606.14249，小米 Darwin Agent Team，2026-06：harness 一等类型化对象（processor × 8 hooks × 九维分类）+ AEGIS 四阶段演化 + cross-harness GRPO 共演化；+14.5% 均值（最高 +44.0%）、共演化再 +4.7%、弱模型受益最大）\n - Anthropic / Justin Young \"Effective harnesses for long-running agents\"（2025-11-26，存量回扫补录：initializer + coding 两段式、200+ 条 feature_list.json、claude-progress.txt + git、Puppeteer 端到端自验；#4/#7 的上游）\n - Anthropic / Gian Segato \"Quantifying infrastructure noise in agentic coding evals\"（2026-02-05，存量回扫补录：只改资源配额 Terminal-Bench 2.0 摆动 6pp；1x–3x 修可靠性、3x 以上改变被测对象；建议每任务声明保底分配 + 硬杀阈值）\n - Cursor / Stefan Heule & Jediah Katz \"Continually improving our agent harness\"（2026-04-30，存量回扫补录：Keep Rate、LLM 读用户回复判满意、CursorBench + 线上 A/B、错误分类与按工具按模型基线、每周 Automation 修 harness、按训练分布供给工具格式、context anxiety）\n - Cursor / Naman Jain \"Reward hacking is swamping model intelligence gains\"（2026-06-25，存量回扫补录：审计 731 条轨迹，SWE-bench Pro 上 63% 成功解是检索答案；封 git + 断网后 Opus 4.8 Max 87.1%→73.0%、Composer 2.5 74.7%→54.0%）\n - Armin Ronacher \"Better Models: Worse Tools\"（2026-07-04，工具 schema 不是中立的：Claude Code 的宽容客户端 + 在其中做 RL → 新模型对替代 schema 更差；strict 模式可清零）\n - Dex Horthy / HumanLayer \"Why Software Factories Fail — harness engineering is not enough\"（2026-07，AIE World's Fair 主题演讲 + wsff.md：熄灯工厂第一手失败实录、可维护性没有快 oracle、产品/架构/程序设计/垂直切片四阶段前移）\n - Addy Osmani \"Software Factories, Light and Dark\"（2026-07-20，loop→harness→factory 三层 + 唯一昂贵的评审闸门 + 背压规则 + \"什么样的循环配得上熄灯\"准入清单 + loops vs graphs）\n - Cursor / Wilson Lin \"Agent swarms and the new model economics\"（2026-07-20，#48 续篇：835 页手册重造 SQLite，账单 $1,339–$10,565；规划/执行分层、自建 VCS 1000 提交/秒、五种蜂群失效、去相关评审、Field Guide）\n - Anthropic / Thariq Shihipar \"The new rules of context engineering for Claude 5 generation models\"（2026-07-24，删掉 Claude Code 系统提示词 80%+ 无可测损失；七组 then/now + `claude doctor`）\n - Don't Blame the LLM 论文（arXiv 2607.03691，Queen's University，首个固定模型只变 harness 的受控纵向研究：Qwen Code CLI 35 个连续版本 × 50 个 SWE-bench Verified 任务）\n - Rethinking Harness Evolution 论文（arXiv 2607.12227，自动 harness 演化的第一份系统性负面结果：同等预算下不稳定优于 test-time scaling、泛化有限）\n - LangChain \"How We Benchmark Deep Agents\"（2026-07-23）+ \"IssueBench\"（2026-07-20）——Harbor 评测栈：Harbor-Index 82 任务 / lite 冻结子集 / capability suite；IssueBench 15 类失败分类法与 issue 集层面判分\n - LangChain / Nick Hollon \"Evaluating code review agents with ReviewBench\"（2026-07-31，真实 PR 评审意见策展成 59 任务 / 64 基线问题；裸 harness 最强召回 ~30%，prompt-only 调优 Luna 0.13→0.32 反超 Opus/Kimi）\n - Fowler / Birgitta Böckeler \"TDD inside the agent loop - theater or actual value?\"（2026-08-10，agent loop 内 TDD 实证否定：盲评质量无差异、mutation score 无差异、token 3–8.5 倍；别规定过程，度量结果）\n - Addy Osmani \"Practical Loop Engineering\"（2026-08-14，loop 系列日常落地环：踩坑实录 + 80K star 仓库分诊循环 + fine print 运维细则）\n - Zalando / Bartosz Ocytko \"Agentic Engineering at Zalando: A Snapshot\"（2026-08-14，250+ 团队非供应商组织级快照：事故分析→PR 风险分级→33% 自动放行→lead time -20~40%）\n - Earendil / Pi 团队双篇 \"What Is a Harness?\" + \"How Compaction Works in Pi\"（2026-08-20 / 08-13，harness 定义+用户侧中立主张 / compaction 白盒实现，与 Codex 端点化对照）\n - StarHarness 论文（arXiv 2608.24804，ServiceNow/Mila，2026-08-25，冻结 harness 工件跨 GPT/Qwen 迁移 12 行全正 +10.7~+46.3pp；跨模型可移植性首个正面证据）\n- **脉络二 — 云原生 Harness.io（2 篇）：** Harness.io 官方全局架构 / Google Cloud 集成场景\n- **脉络三 — 效率悖论（2 篇）：** YDD/Miss-you \"效率悖论的系统性拆解\"（2026-03-03）/ METR 实验后续 + 自报调查（2026-02-24 + 2026-05-11，\"慢 19%\"的官方后续：弱证据转向加速 + RCT 方法论危机）\n\n**已跟踪的开源项目/产品：**\n- Ralph Loop 实验链：snarktank/ralph、ralph-orchestrator、bmad-ralph\n- Chachamaru127/claude-code-harness（v4.2 \"Hokage\"，Claude Code 五动词工作流 + Go 原生 guardrail R01–R13；2026-04-21 收录）\n\n**请重点发现：**\n- 上述未覆盖的新作者 / 新视角 / 新组织\n- 对上述文章的**深度回应或反驳**（不是简单转述）\n- 与上述项目**互补或竞争**的新工具 / harness / 框架\n- 中文社区针对上述材料的原创分析（少数派、掘金、知乎专栏等）\n\n### 输出格式\n\n请按以下格式输出，每条内容一个条目：\n\n---\n\n#### [编号]. {标题}\n\n- **类型：** 文章 / 开源项目 / 工具 / 演讲 / 论文\n- **链接：** {URL}\n- **作者/组织：** {作者}\n- **日期：** {发布日期}\n- **信源层级：** Tier 1 / Tier 2 / Tier 3\n- **推荐指数：** ⭐⭐⭐⭐⭐（1-5 星）\n\n**一句话摘要：** {50 字以内}\n\n**核心洞察（3-5 条）：**\n1. ...\n2. ...\n3. ...\n\n**与已知内容的关联：**\n- 支持/挑战/扩展了哪篇已有文章的观点\n- 填补了哪个已知缺口\n\n**值得收录的理由 / 不值得的理由：**\n{判断}\n\n---\n\n### 质量过滤标准\n\n**必须满足（全部）：**\n- 有实质性的技术内容（不是纯营销或产品公告）\n- 有原创洞察或数据（不是对已有文章的简单转述）\n- 来源可信（有署名，有技术背景）\n\n**加分项（满足越多越好）：**\n- 有实际数据或实验结果\n- 有代码示例或可复现的方案\n- 挑战了主流观点\n- 来自一线实践者（不是纯理论）\n- 有中文社区尚未覆盖的视角\n\n**排除：**\n- 纯产品发布/营销内容\n- 对已有文章的简单翻译或摘要（没有新观点）\n- 过于初级的入门教程\n- 与 harness engineering 只有表面关联\n\n### 输出数量\n\n- 文章类：推荐 5-10 篇，按推荐指数排序\n- 开源项目类：推荐 3-5 个\n- 其他（工具/演讲/论文）：如有高质量内容，不限数量\n```\n\n---\n\n## Prompt B：Claude — 深度分析与项目关联\n\n> 在 ChatGPT 返回结果后，将结果喂给 Claude（在本项目中），做深度分析\n\n```\n以下是最近 2 周的技术情报搜索结果。请基于我们项目的已有内容，做以下分析：\n\n{粘贴 ChatGPT 的输出}\n\n### 请分析：\n\n1. **优先级排序**：哪些内容最值得我们收录？考虑因素：\n - 对**已收录文章 + 已跟踪开源产品**（完整清单见 Prompt A 的\"已知内容\"段落或 `references/articles.md`，不在此重复计数）的补充价值\n - 对 thinking/ 中已有洞见的验证或挑战（含 cross-article-insights 的 8 个洞见 + guides-sensors-meets-claude-code-harness 的 5 个张力）\n - 对开放问题清单的回答程度\n\n2. **缺口分析**：这批内容覆盖了我们的哪些知识缺口？还有哪些缺口未被触及？\n 当前已知缺口：\n - 行为 Harness（功能正确性验证）\n - Harness 覆盖率评估方法（#34/#35/#38 评测三部曲已部分回应，组件级信号供给仍开放）\n - 跨模型可移植性（#35 给出首个定量异质性证据，迁移指南仍缺）\n - 成本数据\n - 中小团队实践案例\n - Harness 接口维护成本（追宿主升级在总维护中的占比）\n - 控制的\"激活策略\"（always-on / per-commit / conditional / human-summoned 的分类与适用场景；#36 的 workflow/ultracode 触发是一个数据点）\n - Harness 安全审计（#33 开辟：中途轨迹违规、多智能体信息流、harness 决定安全上限——后续跟踪该方向的评测与工具）\n - 评测方法论（基准如何拆分 model/harness/环境的组件级归因——跟踪 #34/#35/#38 的后续工作）\n\n3. **趋势信号**：这批内容中是否有新的趋势或方向？与我们已有的四个学派（约束派、控制论派、架构派、怀疑派）是否一致？\n\n4. **收录建议**：对每条推荐内容给出具体建议：\n - 收录到 references/articles.md（哪个脉络）\n - 值得翻译到 works/\n - 值得在 thinking/ 中写分析\n - 暂不收录，持续观察\n```\n\n---\n\n## Prompt C：Manus / OpenClaw — 自动化监控\n\n> 用于设置定时监控的固定信源\n\n```\n定时任务：每日检查以下信源的更新\n\n监控列表：\n1. https://www.anthropic.com/engineering — RSS 或页面变化\n2. https://openai.com/index/ — 新文章\n3. https://martinfowler.com/articles/ — 新文章\n4. https://blog.langchain.com/ — 新文章\n5. https://github.com/trending?since=weekly — AI/agent 相关项目\n6. https://simonwillison.net/ — 新文章\n7. https://mitchellh.com/writing — 新文章\n8. https://claude.com/blog — 新文章（Anthropic 产品侧博客；2026-06 的 dynamic workflows / Managed Agents 两篇重磅均发于此，工程博客不覆盖）\n9. https://addyosmani.com/blog/ — 新文章\n10. https://ghuntley.com/ — 新文章（Ralph 方法论源头）\n\n匹配关键词：harness, agent, coding agent, context engineering, \n AGENTS.md, compaction, multi-agent, sandbox\n\n输出：\n- 有更新时，发送通知（标题 + 链接 + 匹配的关键词）\n- 无更新时，静默\n```\n\n---\n\n## 工作流总结\n\n```\n┌─────────────────────────────────────────────────┐\n│ Layer 1: 自动化监控（每日） │\n│ 工具：OpenClaw / Manus │\n│ 输出：固定信源的新内容通知 │\n└──────────────────────┬──────────────────────────┘\n ↓ 有新内容时触发\n┌─────────────────────────────────────────────────┐\n│ Layer 2: 广度搜索（每 1-2 周） │\n│ 工具：ChatGPT Deep Research │\n│ 输入：Prompt A │\n│ 输出：5-10 篇文章 + 3-5 个项目的结构化摘要 │\n└──────────────────────┬──────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────┐\n│ Layer 3: 深度分析（按需） │\n│ 工具：Claude（本项目内） │\n│ 输入：Prompt B + ChatGPT 输出 │\n│ 输出：优先级排序 + 缺口分析 + 收录建议 │\n└──────────────────────┬──────────────────────────┘\n ↓\n┌─────────────────────────────────────────────────┐\n│ Layer 4: 人工确认 │\n│ 你决定：收录 / 翻译 / 写分析 / 跳过 │\n└─────────────────────────────────────────────────┘\n```\n\n## 核心信源存量回扫（每批必做一步）\n\n> 教训来自 2026-07-21 批次：只按\"最近 2 周\"时间窗扫描，导致 4 篇 1–5 月的重量级官方件\n> （Cursor scaling-agents、Anthropic C compiler / how-we-contain / demystifying-evals）漏网数月。\n> 时间窗抓增量，回扫补存量——两者缺一不可。\n\n每轮调研除时间窗扫描外，**轮换抽取 1–2 个 Tier 1 信源，翻其全年归档目录**（archive / blog 列表页），\n对照 `references/articles.md`（含观察项表）逐条核对是否已收录或已甄别。优先轮换顺序：\n\n1. anthropic.com/engineering（工程博客，全量列表）\n2. cursor.com/blog（research 分类）\n3. openai.com/index（Engineering 分类）\n4. martinfowler.com/tags（GenAI 标签 + exploring-gen-ai 系列）\n5. langchain.com/blog、claude.com/blog、addyosmani.com/blog、simonwillison.net 月归档\n\n发现漏网存量时，与本批增量一起进「候选 × 定性 × 去向」评审表，注明\"存量补课\"。\n\n### 轮换记录\n\n| 批次 | 回扫信源 | 捞回的存量 |\n|------|---------|-----------|\n| 2026-07-21 | （教训来源，未做系统回扫） | 事后补收 #48 / #49 / #50 / #47 |\n| 2026-07-27 | ① anthropic.com/engineering 全量列表 ② cursor.com/blog 全量 slug 清单 | #58 Effective harnesses（2025-11）、#59 基础设施噪声（2026-02）、#60 持续改进 agent harness（2026-04）、#61 奖励作弊（2026-06）——四篇均为 harness 主题正中靶心却漏网数月 |\n| 2026-08-03 | ① openai.com/sitemap.xml/engineering 全量 URL+lastmod ② martinfowler.com/feed.atom（GenAI 归档） | 无漏网存量：OpenAI Engineering 分类的 harness 主题件（harness-engineering / unrolling / unlocking / symphony / windows-sandbox / core-dump / websockets / how-agents-transforming-work）均已在编号正文或观察项；其余 gpt-5.6 / atlas / sora-android / tax-agents / data-agent 为产品·基建，非 harness。Fowler 侧捞出的是增量而非存量（重构经济效益 / Conductor Developer / Fragments 07-21 / Orchestrator's Tax 草稿）——已进本批观察项 |\n| 2026-08-27 | ① langchain.com/blog sitemap 全量（507 slug）② claude.com/blog sitemap 全量（228 slug，去 locale 变体） | **非零星漏网而是系统性缺口**：langchain 相关约 115 篇/此前仅收 19（漏网详查 48，含 12 篇标题直接带 harness/loop 的核心文：improving-deep-agents-with-harness-engineering、better-harness、the-art-of-loop-engineering、deep-agents 开山文等）；claude.com 相关约 80/仅收 9（漏网详查 41：skills 全系列、subagent 系列、Lessons from building Claude Code 双篇等）。处置：不逐篇消化，观察项表加 2 个\"信源级\"合并行，完整清单留档 translate/2026-08-27/candidates.md。方法论教训：两站列表页对 curl 均不完整**必须走 sitemap.xml**；claude.com 的 lastmod 批量刷新不可作发布日期，需逐页取 JSON-LD datePublished |\n\n> 下一轮建议轮换：addyosmani.com/blog + simonwillison.net 月归档（个人博客侧尚未系统回扫过）；cursor.com/blog 可顺带复扫（本批已全量取 sitemap 115 slug 逐页核过日期，短期内干净）。openai.com/index 用 `curl https://openai.com/sitemap.xml/engineering/` 拿到带 lastmod 的全量 URL 最省事（2026-08-03 验证有效，比抓列表页首屏可靠）。\n> 回扫技巧（2026-07-27 验证有效）：列表页只渲染最近若干条时，直接抓 `curl |grep -oE '/blog/[a-z0-9-]+'|sort -u` 拿全量 slug，\n> 再逐个取 `datePublished` 与标题——Cursor 那四条里有两条（`continually-improving-agent-harness`、`reward-hacking-coding-benchmarks`）就是这样发现的，它们不在列表页首屏。\n"}