diff --git a/AGENTS.md b/AGENTS.md index cdebe0c..4c689bb 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -23,7 +23,7 @@ - [x] Phase 2：形成自己的观点（thinking/，9 篇，持续中） - [x] Phase 3：选一个小项目实践（practice/，1 个 Ralph Demo） - [x] Phase 4：记录反馈迭代（feedback/，1 篇，持续中） -- [x] Phase 5：输出可展示的作品（works/，22 篇翻译 + 1 篇原创 + 2 篇外部中文收录） +- [x] Phase 5：输出可展示的作品（works/，24 篇翻译 + 1 篇原创 + 2 篇外部中文收录） > 进度详情以人类向 README.md 的"学习路线"段为准；本节是给智能体的快照。 diff --git a/README.en.md b/README.en.md index 49b58f3..a852f04 100644 --- a/README.en.md +++ b/README.en.md @@ -1,8 +1,8 @@ [中文](README.md) | English ![License: MIT](https://img.shields.io/badge/license-MIT-blue) -![Articles](https://img.shields.io/badge/articles-30-green) -![Translations](https://img.shields.io/badge/translations-22-orange) +![Articles](https://img.shields.io/badge/articles-42-green) +![Translations](https://img.shields.io/badge/translations-24-orange) # Harness Engineering Study Guide @@ -112,10 +112,10 @@ harness-engineering/ ├── thinking/ # Phase 2: Independent analysis (9 articles) ├── practice/ # Phase 3: Hands-on experiments (1 Ralph Demo) ├── feedback/ # Phase 4: Lessons learned (1 article) -├── works/ # Phase 5: Shareable outputs (22 translations + 1 original + 2 external Chinese captures) +├── works/ # Phase 5: Shareable outputs (24 translations + 1 original + 2 external Chinese captures) ├── tools/ # Tools that reduce the 6 complexity dimensions ├── prompts/ # Validated prompts collection -└── references/ # External resource index (30 articles with deep summaries) +└── references/ # External resource index (42 articles with deep summaries) ``` Each subdirectory has its own `AGENTS.md` explaining its purpose and conventions — a direct practice of the "progressive disclosure" principle from the original article. @@ -126,29 +126,31 @@ Each subdirectory has its own `AGENTS.md` explaining its purpose and conventions - [x] **Phase 2: Form your own opinions** — 9 independent analyses (ongoing) - [x] **Phase 3: Pick a small project to practice** — Ralph Demo completed (321s, $0.31) - [x] **Phase 4: Record feedback & iterations** — 1 article (ongoing) -- [x] **Phase 5: Produce shareable work** — 22 professional translations + 1 original synthesis + 2 external Chinese captures +- [x] **Phase 5: Produce shareable work** — 24 professional translations + 1 original synthesis + 2 external Chinese captures ## 📚 Research Library -30 articles across three knowledge tracks + 3 extended readings: +42 articles across three knowledge tracks + 2 extended readings: | Track | Coverage | Perspectives | |-------|----------|-------------| -| AI-Era Harness Engineering | 27 articles | OpenAI → Fowler → Anthropic → LangChain → Stanford → Claude Code reverse engineering → Subagent runtime → Sensors/SPDD/ADLC → Out-of-scope & quality postmortem → Practice recap & Engine | +| AI-Era Harness Engineering | 38 articles | OpenAI → Fowler → Anthropic → LangChain → Stanford → Claude Code reverse engineering & source leak → Subagent runtime → Sensors/SPDD/ADLC → Out-of-scope, safety auditing & quality postmortems → Evaluation trilogy → Dynamic workflows → Origins (Ralph / Hashimoto) & discipline synthesis | | Cloud-Native Harness.io | 2 articles | CI/CD platform architecture (same name, different meaning) | -| Efficiency Paradox & Capability Evolution | 1 article | YDD systematic teardown: TOC + Spec/Rule/Skill | -| Extended Reading | 3 articles | Mitchell Hashimoto, Context Engineering, Human-Agent collaboration | +| Efficiency Paradox & Capability Evolution | 2 articles | YDD systematic teardown + METR follow-up (measurement-methodology crisis) | +| Extended Reading | 2 articles | Context Engineering, Human-Agent collaboration | See [references/articles.md](references/articles.md) — each article includes core thesis, key data, and cross-article connections. ## 📖 Translations
-22 Chinese translations of key articles (click to expand) +24 Chinese translations of key articles (click to expand) | Translation | Original Author | Source | |-------------|----------------|--------| | ⭐ [Eight Years of Wanting](works/maganti-eight-years-building-ai-translation.md) | Lalit Maganti | Personal blog | +| [A Harness for Every Task: Dynamic Workflows](works/anthropic-dynamic-workflows-translation.md) | Thariq Shihipar et al. | Anthropic / Claude | +| [METR: Changing Our Productivity Experiment Design](works/metr-uplift-update-translation.md) | Joel Becker et al. | METR | | [Inside the Scaffold](works/inside-the-scaffold-paper-translation.md) | Benjamin Rombaut | Huawei / arXiv | | [Meta-Harness](works/meta-harness-paper-translation.md) | Yoonho Lee et al. | Stanford / arXiv | | [Harness Engineering (full)](works/fowler-harness-engineering-full-translation.md) | Birgitta Böckeler | Martin Fowler | @@ -207,7 +209,7 @@ The "Ralph Wiggum Loop" is the core implementation pattern of Harness Engineerin | Resource | Description | |----------|-------------| | [vibe-coding-cn](https://github.com/tukuaiai/vibe-coding-cn) | Chinese Vibe Coding community guide | -| [Mitchell Hashimoto: Engineer the Harness](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness) | Another origin of the "Harness" concept | +| [Mitchell Hashimoto: Engineer the Harness](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness) | Where "harness engineering" got its name (now indexed as article #29 in references/articles.md) | ## 🛠️ Development Notes diff --git a/README.md b/README.md index 1ad4ef8..bcba67c 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,8 @@ 中文 | [English](README.en.md) ![License: MIT](https://img.shields.io/badge/license-MIT-blue) -![Articles](https://img.shields.io/badge/articles-30-green) -![Translations](https://img.shields.io/badge/translations-22-orange) +![Articles](https://img.shields.io/badge/articles-42-green) +![Translations](https://img.shields.io/badge/translations-24-orange) # Harness Engineering 学习指南 @@ -111,10 +111,10 @@ harness-engineering/ ├── thinking/ # Phase 2：独立思考与质疑（9 篇） ├── practice/ # Phase 3：小项目实验（1 个 Ralph Demo） ├── feedback/ # Phase 4：踩坑与迭代心得（1 篇） -├── works/ # Phase 5：可展示的作品（22 篇翻译 + 1 篇原创 + 2 篇外部中文收录） +├── works/ # Phase 5：可展示的作品（24 篇翻译 + 1 篇原创 + 2 篇外部中文收录） ├── tools/ # 工具具像化：降低 6 维复杂度的杠杆库 ├── prompts/ # 验证有效的提示词积累 -└── references/ # 外部资源索引（30 篇文章深度摘要） +└── references/ # 外部资源索引（42 篇文章深度摘要） ``` 每个子目录都有自己的 `AGENTS.md`，说明该目录的用途和写作约定。这本身就是原文「渐进式披露」的实践。 @@ -125,29 +125,31 @@ harness-engineering/ - [x] **Phase 2：形成自己的观点** — 9 篇独立思考（持续中） - [x] **Phase 3：选一个小项目实践** — Ralph Demo 完成（321 秒，$0.31） - [x] **Phase 4：记录反馈迭代** — 1 篇（持续中） -- [x] **Phase 5：输出可展示的作品** — 22 篇专业翻译 + 1 篇原创综合分析 + 2 篇外部中文收录 +- [x] **Phase 5：输出可展示的作品** — 24 篇专业翻译 + 1 篇原创综合分析 + 2 篇外部中文收录 ## 📚 研究资料库 -跨三条知识脉络 30 篇文章 + 3 篇延伸阅读： +跨三条知识脉络 42 篇文章 + 2 篇延伸阅读： | 脉络 | 覆盖 | 核心视角 | |------|------|---------| -| AI 时代的 Harness Engineering | 27 篇 | OpenAI → Fowler → Anthropic → LangChain → Stanford → Claude Code 逆向 → Subagent runtime → 传感器/SPDD/ADLC → 越界与质量复盘 → 实践复盘与 Engine | +| AI 时代的 Harness Engineering | 38 篇 | OpenAI → Fowler → Anthropic → LangChain → Stanford → Claude Code 逆向与源码实锤 → Subagent runtime → 传感器/SPDD/ADLC → 越界·安全审计·质量复盘 → 评测三部曲 → 动态工作流 → 起源考据（Ralph / Hashimoto）与学科汇流 | | 云原生 Harness.io | 2 篇 | CI/CD 平台架构（同名不同义的参照） | -| 效率悖论与能力进化 | 1 篇 | YDD 系统性拆解：约束理论 + Spec/Rule/Skill | -| 延伸阅读 | 3 篇 | Mitchell Hashimoto、Context Engineering、人机协作 | +| 效率悖论与能力进化 | 2 篇 | YDD 系统性拆解 + METR 实验后续（测量方法论危机） | +| 延伸阅读 | 2 篇 | Context Engineering、人机协作 | 详见 [references/articles.md](references/articles.md) — 每篇文章含核心论点、关键数据、跨文章关联的深度摘要。 ## 📖 翻译作品
-22 篇核心文章的中文翻译（点击展开） +24 篇核心文章的中文翻译（点击展开） | 作品 | 原作者 | 来源 | |------|--------|------| | ⭐ [渴望了八年，用 AI 三个月造出来](works/maganti-eight-years-building-ai-translation.md) | Lalit Maganti | 个人博客 | +| [为每个任务配一套 harness：动态工作流](works/anthropic-dynamic-workflows-translation.md) | Thariq Shihipar 等 | Anthropic / Claude | +| [METR：我们正在更改生产力实验设计](works/metr-uplift-update-translation.md) | Joel Becker 等 | METR | | [Inside the Scaffold 论文](works/inside-the-scaffold-paper-translation.md) | Benjamin Rombaut | Huawei / arXiv | | [Meta-Harness 论文](works/meta-harness-paper-translation.md) | Yoonho Lee 等 | Stanford / arXiv | | [Harness Engineering 正式版](works/fowler-harness-engineering-full-translation.md) | Birgitta Böckeler | Martin Fowler | @@ -206,7 +208,7 @@ harness-engineering/ | 资源 | 说明 | |------|------| | [vibe-coding-cn](https://github.com/tukuaiai/vibe-coding-cn) | 中文 Vibe Coding 社区指南 | -| [Mitchell Hashimoto: Engineer the Harness](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness) | "Harness" 概念的另一个起源 | +| [Mitchell Hashimoto: Engineer the Harness](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness) | "harness engineering" 命名出处（已收录为文章 #29，深度摘要见 references/articles.md） | ## 🛠️ 开发须知 diff --git a/prompts/deep-research-tracker.md b/prompts/deep-research-tracker.md index 7938a8f..568f157 100644 --- a/prompts/deep-research-tracker.md +++ b/prompts/deep-research-tracker.md @@ -61,11 +61,11 @@ > 它必须自包含，因为搜索器无法访问 `references/articles.md`。 > > **维护纪律：** 当 `references/articles.md` 新增/删除条目时，**同一次提交中**必须同步更新本节。两份内容的口径（脉络划分、篇数、产品/项目清单）应保持完全一致。 -> 本节最近一次同步：2026-06-25（与 `articles.md` 当前内容对齐：30 篇文章 + 1 项已跟踪产品）。 +> 本节最近一次同步：2026-07-08（与 `articles.md` 当前内容对齐：42 篇文章 + 1 项已跟踪产品）。 -**核心文章 30 篇，分布于三条脉络：** +**核心文章 42 篇，分布于三条脉络：** -- **脉络一 — AI 时代 Harness Engineering（27 篇）：** +- **脉络一 — AI 时代 Harness Engineering（38 篇）：** - OpenAI "Harness engineering"（原点，2026-02-11）/ "An open-source spec for Codex orchestration: Symphony"（2026-04-27，任务跟踪器作为控制平面） - Fowler/Böckeler "Harness engineering for coding agent users"（2026-04-02）+ 前传备忘录（2026-02-17） - LangChain "The Anatomy of an Agent Harness"（2026-03）/ "Continual Learning for AI Agents"（2026-04-05）/ "Agent Evaluation Readiness Checklist" @@ -89,8 +89,19 @@ - Overeager Coding Agents 论文（arXiv 2605.18583，越界动作测量 + 提示声明授权反而降低边界推断） - Chris Parsons "How I Use AI to Code"（2026-05，四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈；含译者注，2026 数据未独立核实） - LangChain / Palash Shah "How we built LangSmith Engine"（2026-05-19，用智能体改进智能体，trace→轨迹骨架 + screener/investigator 两阶段闭环） + - Geoffrey Huntley "Ralph Wiggum as a software engineer"（2025-07）+ "everything is a ralph loop"（2026-01-17，bash 循环 + 干净上下文 + 背压 + 单体反多智能体论） + - Mitchell Hashimoto "My AI Adoption Journey"（2026-02-05，六步采纳路线 + "harness engineering" 命名出处） + - Claude Code 源码泄漏事件（2026-03-31，v2.1.88 npm source map 泄 512K 行 TypeScript；聚合分析 pankaj28843/understanding-claude-code：QueryEngine ~46K 行、60+ 门控工具、KAIROS/AutoDream/Undercover Mode） + - Addy Osmani "Agent Harness Engineering"（2026-04-19，O'Reilly 转载；学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS） + - Thoughtworks / Böckeler & Ford "Exploring AI coding sensors"（2026-05-13，有/无传感器对照实验 + harness 模板展望） + - HarnessAudit 论文（arXiv 2605.14271，harness 安全审计：中途轨迹违规是输出级评估盲区，210 任务基准） + - Harness-Bench 论文（arXiv 2605.27922，配置级 harness 效应：106 任务 / 5194 轨迹 + 执行对齐失败） + - "How good is your harness?"（CTB@ICML 2026，Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应且异质） + - Anthropic/Claude "A harness for every task: dynamic workflows in Claude Code"（2026-06-02，模型现场写自己的编排 harness + 对抗验证 + ultracode 触发） + - 马东锡 NLP "Harness 才是产品"（2026-06，Model 在 loop 里 harness 拥有 loop + 六组件 + 症状→组件 debug 表） + - Position 论文 "Coding Benchmarks Are Misaligned with Agentic SE"（arXiv 2606.17799，基准折叠 model/harness/环境的三症状） - **脉络二 — 云原生 Harness.io（2 篇）：** Harness.io 官方全局架构 / Google Cloud 集成场景 -- **脉络三 — 效率悖论（1 篇）：** YDD/Miss-you "效率悖论的系统性拆解"（2026-03-03） +- **脉络三 — 效率悖论（2 篇）：** YDD/Miss-you "效率悖论的系统性拆解"（2026-03-03）/ METR 实验后续 + 自报调查（2026-02-24 + 2026-05-11，"慢 19%"的官方后续：弱证据转向加速 + RCT 方法论危机） **已跟踪的开源项目/产品：** - Ralph Loop 实验链：snarktank/ralph、ralph-orchestrator、bmad-ralph @@ -181,12 +192,14 @@ 2. **缺口分析**：这批内容覆盖了我们的哪些知识缺口？还有哪些缺口未被触及？ 当前已知缺口： - 行为 Harness（功能正确性验证） - - Harness 覆盖率评估方法 - - 跨模型可移植性 + - Harness 覆盖率评估方法（#34/#35/#38 评测三部曲已部分回应，组件级信号供给仍开放） + - 跨模型可移植性（#35 给出首个定量异质性证据，迁移指南仍缺） - 成本数据 - 中小团队实践案例 - Harness 接口维护成本（追宿主升级在总维护中的占比） - - 控制的"激活策略"（always-on / per-commit / conditional / human-summoned 的分类与适用场景） + - 控制的"激活策略"（always-on / per-commit / conditional / human-summoned 的分类与适用场景；#36 的 workflow/ultracode 触发是一个数据点） + - Harness 安全审计（#33 开辟：中途轨迹违规、多智能体信息流、harness 决定安全上限——后续跟踪该方向的评测与工具） + - 评测方法论（基准如何拆分 model/harness/环境的组件级归因——跟踪 #34/#35/#38 的后续工作） 3. **趋势信号**：这批内容中是否有新的趋势或方向？与我们已有的四个学派（约束派、控制论派、架构派、怀疑派）是否一致？ @@ -214,6 +227,9 @@ 5. https://github.com/trending?since=weekly — AI/agent 相关项目 6. https://simonwillison.net/ — 新文章 7. https://mitchellh.com/writing — 新文章 +8. https://claude.com/blog — 新文章（Anthropic 产品侧博客；2026-06 的 dynamic workflows / Managed Agents 两篇重磅均发于此，工程博客不覆盖） +9. https://addyosmani.com/blog/ — 新文章 +10. https://ghuntley.com/ — 新文章（Ralph 方法论源头） 匹配关键词：harness, agent, coding agent, context engineering, AGENTS.md, compaction, multi-agent, sandbox diff --git a/references/AGENTS.md b/references/AGENTS.md index 0aa91a4..e501a59 100644 --- a/references/AGENTS.md +++ b/references/AGENTS.md @@ -9,10 +9,10 @@ ## 文章 -详见 [articles.md](articles.md) — 完整的文章索引，含三条脉络 **30 篇文章 + 1 项已跟踪产品** 的深度摘要。 +详见 [articles.md](articles.md) — 完整的文章索引，含三条脉络 **42 篇文章 + 1 项已跟踪产品** 的深度摘要。 权威计数与编号规则以 `articles.md` 头部为准；本表是它的概览缓存。 -### 脉络一：AI 时代的 Harness Engineering（27 篇） +### 脉络一：AI 时代的 Harness Engineering（38 篇） | # | 文章 | 作者 | 核心贡献 | |---|------|------|---------| @@ -43,19 +43,31 @@ | 25 | [Overeager Coding Agents 论文](https://arxiv.org/html/2605.18583v1) | Yubin Qu 等 | 越界动作测量 + 提示声明授权反而降低边界推断 | | 26 | [How I Use AI to Code](https://chrismdp.com/coding-with-ai/) | Chris Parsons | 四要素 Harness + 从批准者到训练者 + 反馈是新瓶颈 | | 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 两阶段闭环 | +| 28 | [Ralph 原始文章 + 续篇](https://ghuntley.com/ralph/) | Geoffrey Huntley | Ralph = bash 循环 + 每轮干净上下文 + 背压；单体反多智能体论（还上 practice/ Ralph Demo 的理论债） | +| 29 | [My AI Adoption Journey](https://mitchellh.com/writing/my-ai-adoption-journey) | Mitchell Hashimoto | 六步采纳路线 + "harness engineering" 命名出处（由延伸阅读升格） | +| 30 | [Claude Code 源码泄漏事件](https://github.com/pankaj28843/understanding-claude-code) | Chaofan Shou 发现 / 社区聚合分析 | 512K 行 harness 实锤解剖：QueryEngine/60+ 门控工具/KAIROS/AutoDream，#17 推测的对照组 | +| 31 | [Agent Harness Engineering](https://addyosmani.com/blog/agent-harness-engineering/) | Addy Osmani | 学科汇流综合 + 约束加减法纪律 + hooks 分界论 + HaaS（综述破例进编号正文） | +| 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 模板展望 | +| 33 | [HarnessAudit 论文](https://arxiv.org/abs/2605.14271) | Chengzhi Liu 等 | harness 安全审计：中途轨迹违规是输出级评估的盲区 + 210 任务基准 | +| 34 | [Harness-Bench 论文](https://arxiv.org/abs/2605.27922) | Yilun Yao 等 | 配置级 harness 效应测量（106 任务/5194 轨迹）+ 执行对齐失败分类 | +| 35 | [How good is your harness? 论文](https://openreview.net/pdf/99eabc2ce65fd2871a253a0a57954c934ea9e6b0.pdf) | Jiwoo Han, Yuekai Sun | Terminal-Bench 2.0 榜单方差统计归因：harness 效应 ≈ 模型效应，且效应异质 | +| 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 | +| 37 | [Harness 才是产品](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/) | 马东锡 NLP | "Model 在 loop 里，harness 拥有 loop" + 六组件 + 症状→组件 debug 对照表 | +| 38 | [Position: 基准错位论文](https://arxiv.org/abs/2606.17799) | Maria I. Gorinova 等 | 基准把 model/harness/环境折叠进一个分数的三症状诊断 | ### 脉络二：云原生 Harness.io（2 篇） | # | 文章 | 核心贡献 | |---|------|---------| -| 28 | [Harness.io 官方](https://www.harness.io/blog/understanding-ci-cd-platforms-the-backbone-of-modern-devops) | CI/CD 平台全局架构 | -| 29 | [Google Cloud Architecture](https://docs.cloud.google.com/architecture/partners/harness-cicd-pipeline-for-rag-app) | Harness + GCP 部署 RAG | +| 39 | [Harness.io 官方](https://www.harness.io/blog/understanding-ci-cd-platforms-the-backbone-of-modern-devops) | CI/CD 平台全局架构 | +| 40 | [Google Cloud Architecture](https://docs.cloud.google.com/architecture/partners/harness-cicd-pipeline-for-rag-app) | Harness + GCP 部署 RAG | -### 脉络三：效率悖论与能力进化（1 篇） +### 脉络三：效率悖论与能力进化（2 篇） | # | 文章 | 核心贡献 | |---|------|---------| -| 30 | [YDD / Miss-you](https://yousali.com/posts/20260303-ai-coding-efficiency-to-evolution/) | 效率悖论的系统性拆解：约束理论 + Spec/Rule/Skill + 验证闭环 + 并发 | +| 41 | [YDD / Miss-you](https://yousali.com/posts/20260303-ai-coding-efficiency-to-evolution/) | 效率悖论的系统性拆解：约束理论 + Spec/Rule/Skill + 验证闭环 + 并发 | +| 42 | [METR 实验后续 + 自报调查](https://metr.org/blog/2026-02-24-uplift-update/) | METR | "慢 19%" 的官方后续：弱证据转向加速 + AI 渗透破坏 RCT 可行性本身 | ### 已跟踪产品 / 项目（不计入文章数） @@ -83,16 +95,18 @@ | 资源 | 说明 | |------|------| -| [Mitchell Hashimoto: Engineer the Harness](https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness) | "Harness" 概念的另一个起源 | | [Martin Fowler: Context Engineering for Coding Agents](https://martinfowler.com/articles/context-engineering-coding-agents.html) | Context Engineering 专题 | | [Martin Fowler: Humans and Agents in SE Loops](https://martinfowler.com/articles/humans-and-agents.html) | 人类与智能体的协作模式 | +> Mitchell Hashimoto 的 My AI Adoption Journey 原在此表，2026-07 已升格为编号条目 #29。 + ## 待补充 > 占位条目统一收在这里，**不进 `articles.md` 的编号正文**，避免污染文章计数。 -- [ ] Geoffrey Huntley 的 Ralph 原始文章 -- [ ] OpenAI 相关文章：Codex App Server、Responses API +- [x] Geoffrey Huntley 的 Ralph 原始文章 → 已收录为 #28（2026-07） +- [ ] OpenAI 相关文章：Codex App Server（已定位：[Unlocking the Codex harness](https://openai.com/index/unlocking-the-codex-harness/)，2026-02-04，待评审收录）、Responses API +- [ ] 马东锡 Harness 系列其余篇目（仓库已收 #18 之 7、#37 才是产品；X 原帖需本地工具抓取） - [ ] Medium 实战专栏 — "Beyond Migration: How We Engineered a Secure & Intelligent Delivery Platform with Harness CICD"（标题可能已变更或文章已下架） ## 下一步 diff --git a/references/articles.md b/references/articles.md index 0500937..bfde4ff 100644 --- a/references/articles.md +++ b/references/articles.md @@ -10,7 +10,7 @@ > **下游引用都是本文的冗余缓存：** 根 `README.md` / `README.en.md` 的 badge、`prompts/deep-research-tracker.md` 的去重清单、`references/AGENTS.md` 的概览表。 > 新增/删除文章时，必须**同一次提交**更新本文 + 所有下游缓存。 > -> 当前规模：**30 篇文章**（脉络一 27 + 脉络二 2 + 脉络三 1）+ **1 项已跟踪产品**（不计入文章数）。最近一次同步：2026-06-25。 +> 当前规模：**42 篇文章**（脉络一 38 + 脉络二 2 + 脉络三 2）+ **1 项已跟踪产品**（不计入文章数）。最近一次同步：2026-07-08。 ## 脉络一：AI 时代的 Harness Engineering（大模型护栏与认知工程） @@ -744,7 +744,7 @@ |---------|---------| | 四要素 Harness | #2 Fowler、#5 HumanLayer 六杠杆、概念 2/3（地图而非手册 / 机械化执行） | | 反馈循环防腐化 | #9 Fowler 反馈飞轮、#19 Fowler Sensors | -| 反馈瓶颈 / serial speed-up | #28 YDD 效率悖论 | +| 反馈瓶颈 / serial speed-up | #41 YDD 效率悖论 | --- @@ -774,20 +774,323 @@ --- + + +### 28. Geoffrey Huntley — Ralph：最小可行 Harness 的原始出处 + +- **标题：** Ralph Wiggum as a "software engineer"（2025-07）+ 续篇 everything is a ralph loop（2026-01-17） +- **链接：** [ghuntley.com/ralph](https://ghuntley.com/ralph/) | [ghuntley.com/loop](https://ghuntley.com/loop/) +- **作者：** Geoffrey Huntley | **日期：** 2025-07 / 2026-01-17 +- **核心：** Ralph 技术的方法论源头——"Ralph 在最纯粹的形式下就是一个 bash 循环"：`while true` 把 PROMPT.md 喂给编码智能体，每轮全新上下文窗口、一轮只做一件事，配背压验证。作者用它从零构建 CURSED 编程语言（训练集中不存在的语言）。本仓库 `practice/` 的 Ralph Demo 与已跟踪的 3 个 Ralph 项目此前一直缺这篇源头文献。 + +- **关键洞察：** + - **每轮只做一件事 + 信任模型选事：** 违反直觉的组合——既收窄单轮范围，又把"什么最重要"的决策权交给模型 + - **fix_plan.md 是外置状态：** TODO 列表是人类"像鹰一样盯着"的对象，构建 CURSED 期间被扔掉重生成多次——计划是耗材 + - **背压（backpressure）：** 改动后只跑该单元的测试；Rust 类型系统虽强但编译慢——"轮速与正确性轴的平衡"决定语言选择 + - **单体 vs 多智能体：** "非确定性的微服务（智能体）= 一团红热的烂摊子"；Ralph 是单体，单进程垂直扩展、单仓库自治 + - **失败域→工程化修复：** "看到失败域，戴上工程师帽子把问题解决到永不再犯"——与 Hashimoto 的 harness engineering 定义同源 + - **续篇的推广：** "一切皆 ralph loop"——loop 是通用的上下文工程模式，可用于所有任务；软件是陶轮上的黏土，不对就扔回轮上重塑 + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| bash 循环 + 干净上下文 | #3 LangChain 的 Ralph Loop 组件、practice/ Ralph Demo | +| 背压验证门 | 概念 3 机械化执行、#5 HumanLayer 的 Back-Pressure 杠杆 | +| 计划是耗材 | README 的 Ralph 六信条 "The Plan Is Disposable" | +| 单体反多智能体论 | #36 dynamic workflows（对照：模型自己写多智能体编排）、#16 Symphony | +| 观察循环、调音式修复 | #29 Hashimoto 的 harness engineering 定义 | + +--- + + + +### 29. Mitchell Hashimoto — 我的 AI 采纳之旅（"harness engineering" 命名出处） + +- **标题：** My AI Adoption Journey +- **链接：** [mitchellh.com](https://mitchellh.com/writing/my-ai-adoption-journey) +- **作者：** Mitchell Hashimoto（HashiCorp 联合创始人，Ghostty 作者） | **日期：** 2026-02-05 +- **核心：** 六步渐进采纳路线：放弃聊天机器人 → 复现自己的工作（手工做一遍再逼智能体做出同质结果）→ 日终智能体 → 外包稳赢任务 → 工程化 harness → 始终有智能体在跑。第 5 步给出了被业界广泛引用的 harness engineering 定义。多方学科史梳理公认本文是该术语的叫响者（与 OpenAI 原文同月）。原为本仓库"延伸阅读"，现升格为编号条目。 + +- **关键洞察：** + - **定义原文：** "每当发现智能体犯错，就花时间工程化一个解决方案，使它永远不会再犯这个错误"——两种形式：隐式提示（AGENTS.md）+ 程序化工具（截图脚本、过滤测试跑器） + - **Ghostty 的 AGENTS.md 每一行都对应一次真实的坏行为**——与 Osmani "每行可溯源到一次翻车"的纪律互证 + - **复现自己的工作：** 刻意做两遍（先手工后智能体）是形成"什么任务能交给智能体"直觉的最快途径；效率增益的一半来自知道何时不用智能体 + - **人控制打断时机：** 关掉智能体桌面通知，"由我决定何时打断它，而不是反过来"——上下文切换是最贵的成本 + - **克制的自主性：** 一次只跑一个智能体、后台智能体覆盖 10–20% 工作时段；反对为跑而跑——"只在真正有帮助的任务上跑" + - **对冲技能退化：** 委托智能体的同时手工做自己热爱的任务，抵消 Anthropic 技能形成论文指出的风险 + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| harness engineering 定义 | #1 OpenAI 原文（同期独立提出）、#2 Böckeler（引用本文） | +| 错误工程化=永不再犯 | #9 反馈飞轮的个人版、#28 Ralph 的调音式修复 | +| AGENTS.md 行行有出处 | #31 Osmani 的约束加减法纪律、#5 HumanLayer 60 行规则 | +| 何时不用智能体 | #14 Maganti 的能力边界经验、#26 Chris Parsons | + +--- + + + +### 30. Claude Code 源码泄漏事件 — 512K 行 harness 的实锤解剖 + +- **标题：** 事件 + 聚合分析：understanding-claude-code（综合 26 篇文章、7 个 HN 帖、10 份官方 TechDocs） +- **链接：** [pankaj28843/understanding-claude-code](https://github.com/pankaj28843/understanding-claude-code) | 新闻报道：[InfoQ](https://www.infoq.com/news/2026/04/claude-code-source-leak/) +- **事件：** 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 镜像扩散 +- **核心：** 业界第一次看到一线编码智能体 harness 的完整生产级源码。此前 #17（Rungta 逆向）只能从行为推测，泄漏把推测变成了可对照的实锤。 + +- **实锤细节（此前只能猜测的部分）：** + - **QueryEngine ~46K 行**：流式响应、工具调用循环、重试、token 追踪；工具可在模型还在流式输出时就开始执行 + - **60+ 权限门控工具（~29K 行 Tool.ts）**：遵循 Ousterhout "deep modules" 原则——简单接口藏重能力；"Anthropic 花在优化工具上的时间超过优化总 prompt"；工具描述本身是微型提示词 + - **工具结果预算**：BashTool 30K 字符、GrepTool 20K 字符，超额落盘到 `tool-results/{uuid}/` 留预览——上下文管理的机械化实现 + - **14 种缓存破坏向量追踪**（`promptCacheBreakDetection.ts`）：工具表变更、权限模式切换、CLAUDE.md 修改、MCP 连接等——#6 缓存优化五原则的工程落地 + - **未发布功能**：KAIROS 常驻后台 daemon（追加式日报）+ AutoDream 睡眠期记忆整理（727 行，闲时修剪/合并/组织会话记忆）+ Undercover Mode（对外仓库自动抹除内部信息与 AI 署名） + - **教训**：source map 是被忽视的安全面——`npm pack --dry-run` 应进发布流水线 + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| 推测 vs 实锤对照 | #17 Rungta 逆向分析（TAOR 循环、权限光谱的推断如今可验证） | +| 补上闭源样本的空白 | #13 Inside the Scaffold（当时因 Claude Code 闭源无法纳入分类法） | +| 工具>prompt 的投资优先级 | #6 Anthropic 通用工具主张、概念 4 智能体可读性 | +| 记忆整理（AutoDream） | #6 Pokemon 记忆进化案例的机制揭底 | +| 发布流水线事故 | #23 质量回归复盘（同为 Anthropic 工程失误的第一手材料） | + +--- + + + +### 31. Addy Osmani — Agent Harness Engineering（学科汇流综合） + +- **标题：** Agent Harness Engineering +- **链接：** [addyosmani.com](https://addyosmani.com/blog/agent-harness-engineering/)（[O'Reilly Radar 2026-05-15 授权转载](https://www.oreilly.com/radar/agent-harness-engineering/)） +- **第三方中译：** [掘金译文](https://juejin.cn/post/7642753947455356968)（未落盘本仓库） +- **作者：** Addy Osmani（Google Cloud AI Director） | **日期：** 2026-04-19 +- **性质与破例说明：** 综述性质（同类的 Pachaar 综述归在"中文转译/二手资料"段不计数）。破例进编号正文的理由：它不只转述——给出了约束加减法纪律、hooks 分界论等可引用的原创表述，且是"四学派汇流成一个学科"的定调文（收藏/点赞比 2:1，读者当文档存）。 +- **核心：** "编码智能体 = 模型 + 你围绕它构建的一切。Harness engineering 把这套脚手架当真正的工程产物；每当智能体失手，harness 就再收紧一圈。"把 Trivedy（术语）、Horthy（追踪）、HumanLayer（skill issue）、Anthropic（长时设计）、Böckeler（用户侧）、Hashimoto（命名）缝成一张学科地图。 + +- **关键洞察：** + - **失败是可读的（legible）：** 不知道约定→加进 AGENTS.md；跑了破坏性命令→加 hook 拦截；40 步任务迷路→拆 planner/executor；反复"完成"坏代码→接 typecheck 背压 + - **约束的加减法纪律：** 只在见过真实失败后加约束，只在模型能力使其冗余后删；"好的 AGENTS.md 每一行都应能溯源到一次具体翻车" + - **hooks 是分界线：** "我告诉过智能体做 X" vs "系统强制执行 X"——lifecycle 脚本承载永不能忘的事（typecheck/lint/测试、拦 `rm -rf` / force push、PR 前审批、写后自动格式化） + - **模型与 harness 后训练耦合：** Opus 4.6 在 Claude Code 里的 Terminal Bench 2.0 分数远低于同模型在定制 harness 里；Viv 团队只改 harness 就 Top 30 → Top 5（#35 论文给出了这一现象的统计版本） + - **HaaS（Harness-as-a-Service）：** 从构建于 LLM API（给 completion）转向构建于 harness API（给 runtime）——Claude Agent SDK / Codex SDK / OpenAI Agents SDK 同向 + - **Ralph Loop 的价值重申：** "hook 拦截退出、往新上下文窗口重注提示词"是从"用更聪明的模型"永远推导不出来的原语 + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| 六人六视角的汇流地图 | #3 Trivedy、#5 HumanLayer、#4 Anthropic、#2 Böckeler、#29 Hashimoto | +| 约束加减法纪律 | #4 harness 瘦身、#29 AGENTS.md 行行有出处 | +| Terminal Bench harness 效应 | #35 统计归因论文、#3 的原始数据点 | +| HaaS | #7 Managed Agents、#21 ADLC 的 framework/runtime/harness 三分 | +| 四学派汇流 | thinking/cross-article-insights 的学派划分 | + +--- + + + +### 32. Thoughtworks / Böckeler & Ford — 传感器实验：有无反馈回路的对照 + +- **标题：** Harness engineering and agent feedback: Exploring AI coding sensors +- **链接：** [thoughtworks.com](https://www.thoughtworks.com/en-au/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors) +- **作者：** Birgitta Böckeler, Chris Ford (Thoughtworks) | **日期：** 2026-05-13 +- **核心：** #19（可维护性传感器谱系）的实验化姊妹篇。在一个 TypeScript 数据仪表板上做**有/无传感器套件的对照实验**（ESLint、Semgrep 静态分析 + Dependency Cruiser 模块边界 + 覆盖率报告 + mutation testing），配套视频演示。 + +- **关键洞察：** + - **实验结果：** 配备质量反馈传感器的编码智能体能随时间持续改善质量（如提升测试覆盖率）；无传感器则原地踏步 + - **行业失衡诊断：** 2026 上半年业界注意力集中在 skills（前馈），sensors（反馈）被系统性低估——"完美世界只需前馈；我们不住在那个世界里" + - **从叮嘱到保证：** "反复求智能体写测试并祈祷它够自觉" → 确定性约束给出保证；LLM 判断适合模糊探索区，客观一致的要求要交给形式化确定性工具 + - **态势感知而非全自动：** "harness engineering 不是全自动化，而是开发者的态势感知"——红绿传感器仪表板 = 代码库体检单，指示该把精力再投资到 harness 的哪里 + - **Harness 模板展望：** 未来不再每个项目从头搭 harness，而是按应用类型取用预配置模板（数据仪表板模板、CRUD 业务服务模板）——#2 的 harness 模板假说落到具体形态 + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| 传感器对照实验 | #19 传感器谱系（同作者的实操续篇） | +| 前馈/反馈失衡 | #2 Guides×Sensors 框架、#5 六杠杆 | +| 确定性约束 > 反复叮嘱 | 概念 3 机械化执行、#25 Overeager（提示声明反而降低边界推断） | +| harness 模板 | #2 的假说 1、#21 ADLC | + +--- + + + +### 33. HarnessAudit 论文 — Harness 安全审计（安全面的开辟） + +- **标题：** Auditing Agent Harness Safety +- **链接：** [arxiv.org/abs/2605.14271](https://arxiv.org/abs/2605.14271) +- **作者：** 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 +- **核心：** 开辟本仓库此前完全缺失的维度——**harness 是安全面**。核心观察：harness 可以在"返回正确且良性的最终答案"的同时，轨迹中途访问未授权资源、或把上下文泄给错误的智能体——**输出级评估看不见这些失败**，而多数安全基准只给最终输出/终态打分。提出 HarnessAudit 框架（审计完整执行轨迹的边界合规、执行保真、系统稳定三维）+ HarnessAudit-Bench（210 任务 × 8 个真实领域，单/多智能体配置，内嵌安全约束）。 + +- **关键发现（评测 10 种 harness 配置 × 前沿模型 × 3 个多智能体框架）：** + - **任务完成与安全执行不对齐**，违规随轨迹长度累积——长时自主运行天然扩大风险 + - 安全风险随领域、任务类型、智能体角色而异 + - 违规集中在**资源访问**与**智能体间信息传递**两类 + - 多智能体协作扩大安全风险面；**harness 设计决定安全部署的上限** +- **传播语境：** 被转发时的定性——"业界正在意识到：harness 是产品，也是安全面。该审计的不只是模型，还有 prompt、工具、权限、记忆、执行层。AI 安全的下一个前沿是 harness 安全。"（#37 作者马东锡转发） + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| 中途轨迹违规 vs 输出级评估 | #25 Overeager（越界动作测量——本文把它推进到审计框架） | +| 权限边界与信息流约束 | #7 Managed Agents 的安全边界解耦、#30 泄漏实锤的权限分类器 | +| 多智能体扩大风险面 | #18 subagent 的 runtime state 追踪、#36 dynamic workflows 的千级扇出 | +| harness 决定安全上限 | #37 "可靠性的东西都属于 harness" | + +--- + + + +### 34. Harness-Bench 论文 — 配置级 harness 效应的诊断基准 + +- **标题：** Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows +- **链接：** [arxiv.org/abs/2605.27922](https://arxiv.org/abs/2605.27922) +- **作者：** Yilun Yao, Xinyu Tan, Chao-Hsuan Liu 等 12 人 | **日期：** 2026-05 | **arXiv：** 2605.27922 +- **核心：** 现有基准要么抽象掉执行层、要么比较完整智能体系统、要么固定 harness——执行层变异一直难以研究。Harness-Bench 用 106 个沙箱离线任务（从实际 agent 使用模式构造，人工审核真实性/可解性/oracle 可检验性/完整性），在共享任务环境、预算与评估协议下评测代表性 harness 配置 × 多模型后端，同时**保留各 harness 的原生执行行为**。 + +- **关键洞察：** + - **5,194 条执行轨迹的结论：** 完成率、过程质量、效率、失败行为在 model-harness 配对间差异巨大——**智能体能力应按"模型-harness 配置"报告，而非归于基座模型** + - **执行对齐失败（execution-alignment failures）：** 反复出现的失败类型——貌似合理的推理与工具反馈、工作区状态、证据、可验证输出契约**脱钩** + - 每次运行记录最终工件、执行轨迹、用量统计、校验器输出——支持超越"最终完成与否"的过程分析 + - 直接回应本仓库缺口清单的"Harness 覆盖率评估方法" + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| 按 model-harness 配置报告能力 | #35 统计归因（榜单侧的同一主张）、#38 Position（立场侧） | +| 执行对齐失败 | #24 AHE 的决策可观测性、#27 LangSmith Engine 的轨迹骨架 | +| 过程质量 > 最终完成 | #33 HarnessAudit（安全侧的同构主张：中途轨迹才是关键） | + +--- + + + +### 35. How good is your harness? 论文 — harness 效应的统计归因 + +- **标题：** How good is your harness? Statistical evaluation of coding harnesses +- **链接：** [openreview.net](https://openreview.net/pdf/99eabc2ce65fd2871a253a0a57954c934ea9e6b0.pdf) +- **作者：** Jiwoo Han, Yuekai Sun（密歇根大学统计系） | **发表：** CTB@ICML 2026 workshop（首尔） +- **核心：** 用纯统计方法（加性 GLM，logit link）把 Terminal-Bench 2.0 榜单的分数方差拆解归因到 harness 效应与 LLM 效应——不依赖 LLM 标注轨迹，只需要足够交叉的 harness×LLM 榜单设计。数据：清洗后 105 个 harness-LLM 对（28 个 harness × 26 个 LLM）。 + +- **两个定量结论：** + 1. **harness 与 LLM 同等重要：** 从基线 harness 换到最优 harness 的分数跃升 ≈ 从基线 LLM 换到最优 LLM 的跃升——"harness 不是实现细节，是性能的关键组件"第一次有了量化版本 + 2. **harness 效应异质：** 某些 harness 与某些 LLM 更配（如 OpenHands 配 OpenAI 模型好于配 Anthropic/Google 模型）；交互效应量级堪比主效应——harness 和 LLM **不是可完全互换的组件** +- **对本仓库缺口的意义：** "跨模型可移植性"缺口的第一份定量证据——迁移 harness 到新模型时收益不保序，压测（#4 的"定期重新压测假设"）有了统计学理由 + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| harness 效应 ≈ 模型效应 | #3 Trivedy 的 Top 30→Top 5 轶事（本文把轶事升级为估计量）、#31 Osmani 引用的数据点 | +| 效应异质 / 模型-harness 耦合 | #3 的"模型 overfit 到训练 harness"、#4 harness 瘦身 | +| 榜单统计方法 | #34 Harness-Bench（受控实验侧）、#38 Position（立场侧）——评测三部曲 | + +--- + + + +### 36. Anthropic / Claude — 动态工作流：模型现场写自己的 harness + +- **标题：** A harness for every task: dynamic workflows in Claude Code +- **链接：** [claude.com/blog](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code) +- **翻译：** [works/anthropic-dynamic-workflows-translation.md](../works/anthropic-dynamic-workflows-translation.md) +- **作者：** Thariq Shihipar, Sid Bidasaria（Anthropic Claude Code 团队） | **日期：** 2026-06-02（功能随 Claude Code 2.1.154 + Opus 4.8 于 2026-05-28 发布） +- **核心：** harness 本体论的转折点——Claude 现在**为任务现场编写自己的 JavaScript 编排脚本**，即一次性定制 harness。默认 Claude Code harness 要在同一个上下文窗口里既规划又执行，在长时运行、大规模并行、高度结构化、对抗性任务上会崩；dynamic workflows 把编排逻辑放进代码（在 token 上近乎免费），单会话扇出数十到数百个并行 subagent，各自在隔离上下文窗口内执行聚焦目标。 + +- **关键洞察：** + - **静态 workflow 的宿命是泛化损耗：** 预置工作流必须覆盖所有边界情况所以偏通用；Opus 4.8 已足够聪明为具体用例现写定制 harness——#4"每个 harness 组件编码一个假设"在这里变成"假设由模型即时生成" + - **编排即代码：** workflow 可决定每个 agent 用什么模型、是否跑在独立 git worktree——智能等级与隔离度成为可编程参数 + - **对抗验证模式：** 每个生成 agent 配一个独立 agent 按 rubric 对抗校验其输出，收敛后才交付用户；官方 `/deep-research` skill 即此模式（扇出搜索→抓源→对抗核查→合成引用报告） + - **激活策略：** 提示词含 "workflow" 触发，或用 "ultracode" 触发词确保建 workflow——回应本仓库缺口清单的"控制激活策略" + - **workflow 是可沉淀资产：** 生成的脚本可检查、保存、复用，经 Skill 分发——一次性 harness 固化为版本化自动化 + - **反向蒸馏：** 挖掘近期 session 和 code review 评论中反复出现的纠正 → 并行 agent 聚类 → 对抗验证每条候选（"这条规则真能防住一次真实错误吗？"）→ 幸存者蒸馏回 CLAUDE.md + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| harness 从人写工件变成模型生成工件 | #11 Meta-Harness、#24 AHE（自动搜索/演化的产品化收束）、#7 meta-harness | +| 编排放进代码以省上下文 | #22 Deep Agents 解释器、#16 Symphony 控制平面 | +| 对抗验证 | #4 的 Evaluator 分离、#10 评估清单 | +| 千级 subagent 扇出 | #18 subagent 的 runtime state 管理、#33 多智能体风险面 | +| 与 Ralph 单体论的张力 | #28 Huntley "现阶段不需要多智能体"——一年后官方产品反向而行 | + +--- + + + +### 37. 马东锡 NLP — Harness 才是产品 + +- **标题：** Harness 才是产品：决定 Coding Agent 体验的不是 Model，是它周围的整套 Runtime（Harness 系列） +- **链接：** [SOTA Sync 转载页](https://sotasync.com/reader/2026-06-09-dongxi-nlp-harness-is-the-product/)（原文发布于 X @dongxi_nlp，原帖需登录访问，本条目暂链转载页） +- **作者：** 马东锡 NLP (@dongxi_nlp) | **日期：** 2026-06 +- **核心：** 把系列观点收束成一条产品论断：聊 coding agent 第一个该问的不是"用哪个 model"，而是"**Harness 到底负责什么**"。coding agent = 把 model 放进一套 runtime（查真实 repo、请求 tool、编辑文件、跑检查、记住发生过什么、多轮推进）——这层 runtime 就是 harness，"对 coding agent 来说，harness 本身就是 product"。 + +- **关键洞察：** + - **Mini agent 的五个真实爆点：** 编辑从没读过的文件 / shell 触碰 workspace 外 / tool 返回 50,000 行输出 / 磁盘文件已变而 transcript 还是旧读 / tool result 与 tool call 对不上——画出「observe → model → tool」草图的系统还不是 coding agent + - **六个核心组件：** live repo context / prompt shape / structured tools / context reduction / transcripts & memory / delegation；"context quality 经常看起来像 model quality" + - **"Model 在 loop 里，harness 拥有 loop"：** 一个 `edit src/config.py` tool call 只是 proposal，harness 要回答十来个裁决问题（path 是否在 workspace 内、会否经 symlink 逃逸、baseline 是否过期、要否 human approval、多少 output 进下一轮 prompt……）——"这些判断不该交给 model 的随机处理" + - **Transcript ≠ working state：** "发生过什么"与"现在什么重要"是两份不同任务，必须区别对待 + - **症状→组件的 debug 对照表：** 不断重复→查 loop/retry policy；编辑 stale code→查 file-state baselines；越跑越差→查 context projection；运行意外东西→查 permission policy；无法从 tool error 恢复→查 tool result objects + - **工程规则收尾：** "Anything that must be reliable belongs in the harness." + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| harness 拥有 loop / 裁决权 | #18 subagent（同系列前作：tool call outside, runtime inside） | +| harness 是安全面 | #33 HarnessAudit（作者本人转发并背书） | +| proposal vs 落实边界 | #25 Overeager（提示声明 vs 机械门控）、#31 hooks 分界论 | +| context projection | #6 context editing、#22 第三类上下文表面 | + +--- + + + +### 38. Position 论文 — 编码基准与智能体软件工程的错位 + +- **标题：** Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering +- **链接：** [arxiv.org/abs/2606.17799](https://arxiv.org/abs/2606.17799) +- **作者：** Maria I. Gorinova, M D Baker, Amy Heineike, Maksim Shaposhnikov, Rob Willoughby, Dru Knox | **日期：** 2026-06 | **arXiv：** 2606.17799 +- **核心：** 立场论文——我们用来比较编码智能体的基准诞生于前智能体时代：把 model、harness、environment 折叠进一个端到端分数，通常按单一参考解评分，没有可迭代的组件级信号。"实践中的编码智能体不是模型，是 system harness——models/harnesses/contexts/environments/feedback signals 的复合体，其中任何一项都能把基准分数挪动一个相邻模型代际的量级。" + +- **三个症状：** + 1. 基准分数把模型与 harness 其余部分**混同**——排行榜差异无法归因 + 2. 按单一参考解评分**惩罚同样有效的替代方案**——真实工程里一题多解是常态 + 3. 缺少单个 harness 组件级别的信号，端到端系统分数**难以迭代**——你不知道该修哪里 +- **对本仓库的意义：** 与 #34（受控实验）、#35（榜单统计归因）构成"harness 评测三部曲"；也为 thinking/evaluation-elephant-in-the-room 的"行为 harness 是大象"补上评测学的病理诊断 + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| model/harness/environment 折叠 | #35 的统计拆解方案、#34 的配置级测量方案 | +| 单参考解惩罚多解 | #10 评估清单的 LLM-as-judge 校准 | +| 组件级信号缺失 | #24 AHE 的三类可观测性（正是组件级信号的一种供给） | + +--- + ## 脉络二：云原生时代的 Harness.io（交付与平台工程） - + -### 28. Harness.io 官方 — 全局架构 +### 39. Harness.io 官方 — 全局架构 - **标题：** Understanding CI/CD Platforms: The backbone of modern DevOps - **链接：** [harness.io](https://www.harness.io/blog/understanding-ci-cd-platforms-the-backbone-of-modern-devops) - **核心：** 标准 CI/CD 平台介绍。8 大组件：SCM → Build → Test → Code Quality → Security Scan → Artifact → Deploy → Monitor - **Harness 差异化：** 统一管线、Test Intelligence 智能测试、最少脚本、Policy-as-Code 治理 - + -### 29. Google Cloud Architecture — 前沿场景结合 +### 40. Google Cloud Architecture — 前沿场景结合 - **标题：** Harness CI/CD pipeline for RAG applications - **链接：** [docs.cloud.google.com](https://docs.cloud.google.com/architecture/partners/harness-cicd-pipeline-for-rag-app) @@ -800,9 +1103,9 @@ ## 脉络三：效率悖论与能力进化 - + -### 30. YDD / Miss-you — 效率悖论的系统性拆解 +### 41. YDD / Miss-you — 效率悖论的系统性拆解 - **标题：** 为什么 AI 写代码更快但交付没变，以及我怎么把它扳回来的 - **链接：** [yousali.com](https://yousali.com/posts/20260303-ai-coding-efficiency-to-evolution/) @@ -848,6 +1151,35 @@ --- + + +### 42. METR — 生产力实验的后续：结论松动与方法论危机 + +- **标题：** We are Changing our Developer Productivity Experiment Design（2026-02-24）+ Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity（2026-05-11） +- **链接：** [metr.org 实验设计更新](https://metr.org/blog/2026-02-24-uplift-update/) | [metr.org 自报调查](https://metr.org/blog/2026-05-11-ai-usage-survey/) | [后续研究数据集](https://github.com/METR/Measuring-Late-2025-AI-on-OSS-Devs) +- **翻译：** [works/metr-uplift-update-translation.md](../works/metr-uplift-update-translation.md)（实验设计更新篇） +- **作者：** Joel Becker, Nate Rush, Tom Cunningham, David Rein, Khalid Mahamud (METR) | **日期：** 2026-02-24 / 2026-05-11 +- **核心：** #41 YDD 的论证基石（METR RCT "AI 辅助反而慢 19%"）的官方后续。late-2025 复现实验（57 名开发者、143 仓库、800+ 任务）的原始结果转向加速——原班开发者估计 **-18% 加速**（CI -38%~+9%）、新开发者 -4%（CI -15%~+9%）——但 METR 自己判定这只是**很弱的证据**，并宣布改实验设计。真正的信息量在于：**AI 渗透已经破坏了任务级随机对照实验本身的可行性**。 + +- **选择效应的三重来源（实验设计为何失效）：** + - 开发者拒绝参与——越来越多人不愿在无 AI 条件下工作（时薪 $50 也不愿），最乐观的采纳者系统性缺席 + - 任务被挑选——30–50% 的开发者承认不提交某些任务，因为"不想在没 AI 的条件下做它们"，高预期增益任务系统性缺失 + - 计时不可靠——并发跑多个智能体的开发者"等 agent 干活时在做别的任务"，时间花费无法测量 +- **开发者原话：** "AI 能 2 小时搞定、我要 20 小时的 issue，我根本不敢提交——万一被随机到禁 AI 组太痛苦了"；"像习惯了打车之后再让我步行穿城，头都要炸了" +- **2026-05 自报调查：** 349 名技术工作者（87 名软件工程师）自报工作价值变化中位数 **1.4–2x**，且预期继续增长；METR 同时援引 Becker et al. (2025)——开发者自报增益平均高估 40+ 个百分点，提醒对量级保持怀疑 +- **对本仓库的意义：** 脉络三的证据基座更新——YDD 引用的"慢 19%"是 early-2025 快照，不能再当活事实引用；同时"实验测不动了"本身就是能力进化的间接证据 + +- **与其他文章的关联：** + +| 本文概念 | 对应文章 | +|---------|---------| +| 19% 减速数据的后续 | #41 YDD 第一章效率悖论（引用了原实验） | +| 感知与现实的偏差 | #41 的 39 个百分点偏差、自报高估 40+ 个百分点 | +| 并发智能体使计时失效 | #41 第五章并发策略（并发正是 YDD 开出的药方） | +| 测量方法的时代错位 | #38 Position 论文（基准侧的同构诊断：测量工具追不上被测对象） | + +--- + ## 两条脉络的关系 ``` @@ -870,7 +1202,7 @@ Harness Engineering（AI 护栏） Harness.io（交付管线） ## 中文转译 / 二手资料（不计入文章数） > 这里收录的是**他人已发布的中文译介或二手综述**——本仓库做了归档但**不视为一手文献**。 -> 本段不参与 `### N. ...` 的全局编号，不计入 30 篇文章总数；与上方编号正文严格区分，避免污染脉络计数。 +> 本段不参与 `### N. ...` 的全局编号，不计入 42 篇文章总数；与上方编号正文严格区分，避免污染脉络计数。 > 收录标准：内容与 Harness Engineering 直接相关、来源可追溯到具名作者 / 译者、且对本仓库已有一手文献有补充或对照价值。 ### Akshay Pachaar — The Anatomy of an Agent Harness（中译版） @@ -894,12 +1226,22 @@ Harness Engineering（AI 护栏） Harness.io（交付管线） | 「房子盖好后脚手架要拆」（协同进化） | #4 Anthropic Harness 瘦身原则、Fowler 的 harness 假设 | - **为什么不进编号正文：** 本文是综述科普，不是一手文献。编号正文中的文章分别对应 OpenAI / Fowler / Anthropic / LangChain 等团队的一手工程博客、论文、外部逆向分析或中文社区原创分析；将综述纳入会污染「一手/准一手」的语义边界与一致性脚本（C1/C2/C6）的语义。归到本段保留对照价值即可。 +- **对照案例：** #31 Osmani 综述经人工评审后**破例**进了编号正文（有原创表述 + 学科定调价值）；本文维持不计数——两者共同构成"综述收录边界"的判例。 + +### InfoQ 中文 — Böckeler QCon 纽约演讲整理（Coding Agent 技术全景图） + +- **类型：** 演讲的第三方中文整理，非一手文献 +- **链接：** [infoq.cn](https://www.infoq.cn/article/UFLm5D5VDPmu9Ykc9CdJ) +- **原讲者：** Birgitta Böckeler（Thoughtworks 全球 AI 辅助软件交付负责人） | **整理：** InfoQ 中文站 | **日期：** 2026-06（QCon 纽约站演讲） +- **内容定位：** 过去一年 coding agent 范式转移的演讲版总览：Skills/Subagents 的上下文调控 → 云端低监督自主开发 → 用确定性 Harness 约束非确定性产出。可作为 #2 / #19 / #32 的中文入口与口语化对照。 +- **增量信息：** "未来可能不再从服务模板起步，而是从 Harness 模板起步——届时甚至不在乎是 React 还是 Vue，决策维度变成'有没有现成的 Harness'"——harness 模板假说的最新表述。 +- **为什么不进编号正文：** 二手整理稿，论点均已被 #2（框架）、#19（传感器谱系）、#32（传感器实验）的一手文献覆盖。 --- ## 已跟踪产品 / 项目（不计入文章数） -> 这里收录的是**开源产品 / 框架 / 工具**，不是文章。本段不参与"### N. ..." 的全局编号，不计入 30 篇的文章总数。 +> 这里收录的是**开源产品 / 框架 / 工具**，不是文章。本段不参与"### N. ..." 的全局编号，不计入 42 篇的文章总数。 > 触发"产品级实现案例"的判定通常是：有可运行代码、有版本号、被本仓库 thinking/ 或 works/ 单独分析。 ### ⭐ Chachamaru127 — claude-code-harness v4.2 "Hokage"（产品级实现案例） @@ -927,7 +1269,7 @@ Harness Engineering（AI 护栏） Harness.io（交付管线） ## 观察项 / 候选材料（不计入文章数） -> 2026-05 调研中已抓取并翻译、但**暂不值得做成正式文章**的产品页 / README / 短 bliki / 发布稿。本段不参与 `### N.` 编号，不计入 30 篇文章总数。 +> 2026-05 起各轮调研中已甄别、但**暂不值得做成正式文章**的产品页 / README / 短 bliki / 发布稿 / 工程随笔。本段不参与 `### N.` 编号，不计入 42 篇文章总数。 > 中文译文留在本地 `translate/`（gitignored）作阅读辅助；下表只记上游链接与定性，方便下次快速复看。 > **去向标记：** 🔵 待实测后入 `tools/`（遵守 tools/「只收用过的工具」标准，未实测前不正式收录） ｜ ⚪ 长期观察 ｜ ⏭️ 暂存不收。 @@ -947,5 +1289,15 @@ Harness Engineering（AI 护栏） Harness.io（交付管线） | Vibe Coding | bliki | ⚪ | Fowler 给 vibe coding 的权威定义锚点；可做术语引用 | [martinfowler](https://martinfowler.com/bliki/VibeCoding.html) | | Interrogatory LLM | bliki | ⚪ | 让 LLM 反向访谈人类生成上下文的 pattern；可做 `prompts/` 引用 | [martinfowler](https://martinfowler.com/bliki/InterrogatoryLLM.html) | | Google Antigravity | 发布稿 | ⏭️ | I/O 2026 开发者亮点；产品罗列，与已收录 Managed Agents 重复 | [blog.google](https://blog.google/innovation-and-ai/technology/developers-tools/google-io-2026-developer-highlights/) | +| Claude Managed Agents 演进 | 产品文 | ⚪ | #7 的产品化续篇（Agent SDK → Managed Agents 的演进叙事 + `/claude-api` skill 入口）；发布稿口吻，2026-06-10 | [claude.com](https://claude.com/blog/building-with-claude-managed-agents) | +| LangChain Deep Agents 上下文管理 | 工程文 | ⚪ | 压缩三技术（大结果落盘 / 阈值触发摘要 / 子智能体隔离）+ **targeted evals**（针对单个压缩机制的小型回归测试，可迁移的做法）；与 #22 互补 | [langchain](https://www.langchain.com/blog/context-management-for-deepagents) | +| LangChain 生产级 Deep Agents 的 Runtime | 工程文 | ⚪ | harness（prompts/tools/skills）与 runtime（durable execution/memory/multi-tenancy/HITL/观测）的分界陈述；与 #7、#21 重叠度高 | [langchain](https://www.langchain.com/blog/runtime-behind-production-deep-agents) | +| Arize：harness 为何取代 framework | 分析 | ⚪ | framework（人组装的抽象+绳子）vs harness（开箱即跑，人只给目标）的划界 + 一套 harness 运营指标（成功率/重试/工具效率/恢复/工具幻觉/单条成功轨迹成本）；2026-06-18 | [arize.com](https://arize.com/blog/what-is-an-agent-harness-why-harnesses-are-replacing-agent-frameworks/) | +| Code as Agent Harness 综述 | 论文 | ⚪ | "代码即 harness 基底"的三层大地图（接口/机制/多智能体扩展），横跨编码/GUI/具身/科研场景；综述体裁，检索地图价值大于论点价值 | [arxiv 2605.18747](https://arxiv.org/abs/2605.18747) | +| NLAH：自然语言 Agent Harness | 论文 | ⚪ | 把 harness 控制逻辑外化为可执行自然语言工件 + 共享运行时（IHR），主张 "harness 表示科学"；与 #16 SPEC.md 模式互证，待更多后续工作 | [arxiv 2603.25723](https://arxiv.org/abs/2603.25723) | +| Microsoft Agent Framework `HarnessAgent` | 产品/文档 | ⚪ | 微软入场：batteries-included harness 作为一等 API（`AsHarnessAgent`）；微软视角此前仓库空白，暂只有文档无深度工程文 | [learn.microsoft.com](https://learn.microsoft.com/en-us/agent-framework/agents/harness) | +| OpenAI Core dump 流行病学 | 工程复盘 | ⚪ | "群体级诊断 > 逐例分析"修复 18 年 libunwind 老 bug，ChatGPT 参与写分析管线；可观测性方法论好文但与 harness 关系间接，2026-06-30 | [openai](https://openai.com/index/core-dump-epidemiology-data-infrastructure-bug/) | +| thedeepfeed：学科史梳理 | 编年 | ⚪ | "七个声音九个月汇流成一个学科"的传播史（含 Osmani 文收藏/点赞比 2:1 等传播数据）；二手史料，配 #31 看 | [thedeepfeed.ai](https://www.thedeepfeed.ai/posts/2026-05-09-agent-harness-engineering-the-discipline/) | +| Boris Cherny 工作流 | 实践 | ⚪ | Claude Code 作者本人"出奇原味"的用法（~100 行 CLAUDE.md、plan mode 纪律、跑偏就回 plan 重规划）；源头是其 X 帖，链接为社区维护的档案站（非 Anthropic 官方） | [howborisusesclaudecode.com](https://howborisusesclaudecode.com) | > 三篇短 bliki / 随笔（Vibe Coding、Interrogatory LLM、Genie Tarpit）若日后要收，建议合并成一个「概念定义 / 上下文工程 pattern」小专题，别各开条目稀释精品信号。 diff --git a/works/AGENTS.md b/works/AGENTS.md index 32ce488..bbdb1ac 100644 --- a/works/AGENTS.md +++ b/works/AGENTS.md @@ -50,6 +50,8 @@ language: "zh-CN" | [arxiv-overeager-coding-agents-translation.md](arxiv-overeager-coding-agents-translation.md) | Overeager Coding Agents (论文) | Yubin Qu 等 / arXiv | | [chris-ai-code-translation.md](chris-ai-code-translation.md) | How I Use AI to Code | Chris Parsons / 个人博客 | | [langsmith-engine-translation.md](langsmith-engine-translation.md) | How we built LangSmith Engine | LangChain / Palash Shah | +| [anthropic-dynamic-workflows-translation.md](anthropic-dynamic-workflows-translation.md) | A harness for every task: dynamic workflows in Claude Code | Anthropic / Claude · Thariq Shihipar, Sid Bidasaria | +| [metr-uplift-update-translation.md](metr-uplift-update-translation.md) | We are Changing our Developer Productivity Experiment Design | METR / Joel Becker 等 | ### 中文转译 / 二手资料 diff --git a/works/anthropic-dynamic-workflows-translation.md b/works/anthropic-dynamic-workflows-translation.md new file mode 100644 index 0000000..4ebc4f1 --- /dev/null +++ b/works/anthropic-dynamic-workflows-translation.md @@ -0,0 +1,197 @@ +--- +title: "为每个任务配一套 harness：Claude Code 中的动态工作流" +sourceTitle: "A harness for every task: dynamic workflows in Claude Code" +sourceUrl: "https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code" +sourceAuthor: "Thariq Shihipar, Sid Bidasaria (Anthropic, Claude Code 团队)" +sourcePublishedAt: "2026-06-02" +sourceSiteName: "Claude by Anthropic" +summary: "Claude Code 现在能为手头任务现场编写并编排自己的多智能体 harness。本文介绍动态工作流的工作原理、六种常用编排模式（分类路由 / 扇出合成 / 对抗验证 / 生成过滤 / 锦标赛 / 循环至完成），以及从迁移重构到深度调研的十类用法。" +sourceLanguage: "en" +language: "zh-CN" +translationMethod: "人工整理逐段翻译（cloud agent，对照原文全文）" +--- + +# 为每个任务配一套 harness：Claude Code 中的动态工作流 + +> Claude Code 现在可以现场编写并编排自己的多智能体 harness。本文讲解动态工作流的工作原理，以及最能发挥它们价值的使用模式。 + +上周，我们在 Claude Code 中发布了动态工作流（dynamic workflows）。Claude 现在可以现场编写自己的 harness，为手头的任务量身定制。 + +虽然默认的 Claude Code harness 是为编码而构建的，但它对许多其他类型的任务同样有用——因为事实证明，很多任务都长得像编码任务。不过，有一些任务类别，我们过去必须在 Claude Code 之上构建定制 harness 才能达到峰值性能，比如调研（Research）、安全分析、智能体团队（agent teams）或代码审查（Code Review）。 + +工作流让你可以在 Claude Code 之上动态创建 harness，使 Claude 能更原生地解决所有这些问题。你还可以把这些工作流分享给他人复用。 + +在这篇文章里，我会分享我使用工作流的初步体验和心得，帮助你把它用到极致。请记住：最佳实践仍在形成中——动态工作流通常消耗更多 token，最适合复杂、高价值的任务。 + +## 提示词示例 + +在深入技术细节之前，我想先给出几个提示词示例，帮你打开对工作流可能性的想象： + +- "这个测试大概每 50 次跑挂 1 次。搭一个工作流来复现它。对竞态条件形成几个相互竞争的假设，直到只有一个假设能扛住证据为止，不要停。" +- "用一个工作流，翻我最近 50 个 session，挖出我反复在做的纠正，把高频出现的沉淀成 `CLAUDE.md` 规则。" +- "用一个工作流，挖一遍 Slack 里 #incidents 频道过去六个月的记录，找出那些反复出现、却没人建工单的根因。" +- "拿着我的商业计划书，跑一个工作流：让不同的智能体分别从投资人、客户和竞争对手的视角把它撕碎。" +- "这个文件夹里有 80 份简历，用一个工作流针对后端岗位排序，并复核前十名。先用 AskUserQuestion 工具采访我，生成一份评分标准（rubric）。" +- "我需要给这个 CLI 工具起名。用一个工作流头脑风暴一批选项，再跑一场锦标赛选出前 3。" +- "用一个工作流，把我们的 User 模型在所有地方重命名为 Account。" +- "过一遍我的博客草稿，用一个工作流对照代码库核实每一条技术断言——我不想发出去任何错的东西。" + +## 动态工作流如何工作 + +动态工作流执行的是一个 JavaScript 文件，其中带有几个用于派生（spawn）和协调 subagent 的特殊函数。（**译注：原文此处附有列出这些特殊函数的代码示例，网页正文未随文本导出，请参见原文。**） + +动态工作流同样包含 JSON、Math、Array 等标准 JavaScript 功能，用来处理数据。 + +特别值得知道的是：动态工作流可以决定某个智能体使用哪个模型、subagent 是否跑在自己的 worktree 里——也就是让 Claude 自行选择所需的智能等级与隔离程度。 + +如果工作流被打断（比如用户操作或退出终端），恢复该 session 后，工作流可以从中断处继续。 + +## 为什么需要动态工作流 + +当你让默认的 Claude Code harness 做一个任务时，它必须在同一个上下文窗口里既做规划又做执行。对许多编码任务而言这非常有效，但在长时运行、大规模并行、高度结构化和/或对抗性的任务上，它会失灵。 + +原因在于：Claude 在单个上下文窗口里处理复杂任务的时间越长，就越容易陷入几种特定的失败模式： + +- **智能体式偷懒（Agentic laziness）**：Claude 在特别复杂的多部分任务完成之前就停下来，只取得部分进展就宣布任务完成——比如一次安全审查的 50 个事项只处理了 35 个。 +- **自我偏好偏差（Self-preferential bias）**：Claude 倾向于偏爱自己的结果或发现，尤其是被要求按评分标准验证或评判它们的时候。 +- **目标漂移（Goal drift）**：在多轮对话中对原始目标的保真度逐渐丢失，尤其是在压缩（compaction）之后。每一步总结都是有损的，边界条件要求、"不要做 X"这类约束细节都可能丢掉。 + +创建工作流能对抗这些失败模式：它编排彼此独立的 Claude subagent，每个都有自己的上下文窗口和聚焦、隔离的目标。 + +## 动态工作流 vs 静态工作流 + +你可能此前已经用 Claude Agent SDK 或 `claude -p` 创建过静态工作流，用来协调多个 Claude Code 实例协同工作。 + +但静态工作流必须覆盖所有边界情况，所以通常更加通用（也就更钝）。有了 Claude Opus 4.8 和动态工作流，Claude 现在已经足够聪明，可以为你的具体用例现写一套量身定制的 harness。 + +## 使用动态工作流的常用模式 + +你只要直接让 Claude 建一个工作流，或者使用触发词 "`ultracode`" 来确保 Claude Code 创建工作流，就可以开始使用了。 + +但为动态工作流建立一个心智模型，会帮助你理解什么时候该用它们、以及如何通过提示词去引导 Claude。 + +Claude 在构建工作流时可能使用并组合以下几种常见模式： + +### 分类后行动（Classify-and-act） + +用一个分类器智能体判断任务类型，然后按任务路由到不同的智能体或行为。也可以在末尾用分类器决定输出。 + +### 扇出并合成（Fan-out-and-synthesize） + +把任务拆成许多更小的步骤，每步跑一个智能体，然后合成这些结果。当小步骤数量很大、或每一步都受益于干净独立的上下文窗口（避免互相干扰、交叉污染）时特别有用。合成步骤是一道屏障（barrier）——它等待所有扇出的智能体完成，然后把它们的结构化输出合并成一个结果。 + +### 对抗验证（Adversarial verification） + +为每个派生出来的智能体，再跑一个独立的智能体，按评分标准或准则对抗性地验证其输出。 + +### 生成并过滤（Generate-and-filter） + +围绕一个主题生成一批想法，然后按评分标准或验证结果过滤、去重，只返回质量最高、经过检验的想法。 + +### 锦标赛（Tournament） + +不是分工，而是让智能体竞争。派生 N 个智能体，每个用不同的方法尝试同一个任务，然后由提示词或模型（评判智能体）以两两比较的方式评判结果，直到决出胜者。 + +### 循环至完成（Loop until done） + +对于工作量未知的任务，循环派生智能体直到满足停止条件（没有新发现、或日志里不再有错误），而不是跑固定的轮数。 + +## 使用场景 + +要有创造性地思考何时、如何让 Claude Code 创建动态工作流。我发现工作流有时对非技术工作甚至更有用。 + +### 迁移与重构 + +Bun 从 Zig 重写为 Rust 就是用工作流完成的。你可以在 Jarred 的 X 线程里读到具体做法。 + +关键是把任务分解成一系列需要逐一处理的步骤，比如调用点（callsites）、失败的测试、模块等。为每个修复在 worktree 里派生一个 subagent 去改，再让另一个智能体做对抗性审查，然后合并。可以考虑告诉智能体不要使用资源密集的命令，这样你就能在不耗尽机器资源的前提下最大化并行。 + +### 深度调研 + +我们在 Claude Code 里发布了一个使用动态工作流的深度调研 skill（`/deep-research`）。具体来说，它扇出网络搜索、抓取来源、对抗性核查这些来源的断言，最后合成一份带引用的报告。 + +这类调研不止于网络搜索。比如，让 Claude 从 Slack 的上下文里汇编一份状态报告，或者通过深入探索代码库来调研某个功能是如何工作的。 + +### 深度核查 + +反过来，如果你有一份报告，想对其中引用的每一条事实断言做核查和溯源，可以生成这样一个工作流：一个智能体识别出所有事实断言，然后为每一条派生一个 subagent 做细致核查。你还可以再加一个验证智能体去检查负责溯源的 subagent，确保其来源足够可靠。 + +### 排序 + +你可能有一列条目，想按某种你相信 Claude Code 擅长评估的定性指标排序——比如按 bug 严重程度排序支持工单。但如果你试图在一个提示词里排 1000+ 行，质量会退化，上下文也装不下。正确做法是跑一场锦标赛、一条两两比较智能体组成的流水线（比较式评判比绝对打分更可靠），或者并行分桶排序再归并。每次比较都是一个独立的智能体，确定性的循环持有对阵表（bracket），上下文里只保留当前的执行顺序。 + +### 记忆与规则遵从 + +如果有一组规则 Claude 总是漏掉或做不好——即使已经写进了 `CLAUDE.md`——可以创建一个工作流，把规则列成清单，由验证智能体逐条检查：一条规则一个验证者。再创建一个"怀疑论者"人设的 subagent 复审这些规则是否合理，可以避免过多误报。 + +反方向同样成立：挖掘你最近的 session 和 code review 评论里反复出现的纠正，用并行智能体聚类，对每条候选做对抗验证（"这条规则真能防住一次真实错误吗？"），然后把幸存者蒸馏回 `CLAUDE.md`。 + +### 根因调查 + +调试的最佳做法是提出几个相互独立的假设并逐一检验，但如果只用一个上下文窗口，Claude 会陷入自我偏好偏差。 + +工作流可以在结构上防止这一点：派生多个智能体，从彼此不相交的证据出发生成假设——例如日志、文件、数据各一个智能体。每个假设随后要面对一个由验证者和反驳者组成的评审团。 + +这不只适用于代码。工作流可以用于销售（三月的销售额为什么掉了？）、数据工程（这条管道为什么挂了？），或任何事后复盘（post-mortem）演练。 + +### 规模化分诊 + +每个团队都有支持队列、bug 报告，或某种人力处理不完的积压。 + +分诊（triage）工作流对每个条目做分类、与已跟踪事项去重，然后采取行动——可能是尝试修复，也可能是升级给人类处理。 + +分诊工作流的一个有用模式是**隔离检疫（quarantine）**：禁止那些阅读不可信公开内容的智能体执行高权限操作，高权限操作改由负责"根据信息行动"的智能体执行。 + +把分诊工作流与 `/loop` 搭配，可以让 Claude 持续不断地做这件事。 + +### 探索与品味 + +在探索一个解法的不同方向时，工作流很有用——尤其是设计、命名这类品味型问题，它们受益于一份明确的评分标准。 + +试着让 Claude 探索一批解法，并给一个审查智能体一份"好解法长什么样"的评分标准。当审查智能体认为达标时任务才算完成。解法也可以基于评分标准，通过锦标赛来排序或筛选。 + +### 轻量评测（Evals） + +你可以为特定任务跑轻量评测：在 worktree 里派生独立的智能体产出结果，再派生比较智能体按评分标准对具体输出进行比较和打分。例如，按特定标准评测并打磨你创建的某个 skill。 + +### 模型与智能路由 + +创建一个针对你的任务调优的分类器智能体，由它决定用哪个模型。当任务涉及大量工具调用、且执行前的调研能识别出最适合的模型时，这很有帮助。 + +例如，"解释 auth 模块是怎么工作的"这个任务的最佳模型，取决于 auth 模块有多少文件、代码库长什么形状。分类器智能体可以先做这个调研，再按预期复杂度路由到 Sonnet 或 Opus。 + +## 什么时候不该用动态工作流 + +工作流还很新。虽然在许多用例上它能创造超额回报，但并非每个任务都需要它，而且它可能消耗显著更多的 token。 + +最好把工作流用在创造性的地方，把 Claude Code 推向你以前没到过的地方。对常规编码任务，先问问自己：它真的需要更多算力吗？比如，大多数传统编码任务并不需要一个五人审查团。 + +## 构建动态工作流的技巧 + +### 提示词 + +使用上文描述的具体模式做详细提示，能让动态工作流产出最好的结果。 + +工作流不只服务于大任务。你可以提示模型使用"快速工作流（quick workflow）"——例如对某个假设做一次快速的对抗性审查。 + +### 与 /goal 和 /loop 组合 + +对可重复执行的工作流（如分诊、调研、核查），可以与 `/loop` 搭配定期运行，并用 `/goal` 设定硬性的完成要求。 + +### token 用量预算 + +你可以为动态工作流设置显式的 token 用量预算，限制一个任务消耗多少 token。直接在提示词里给预算即可，比如"用 1 万 token"，它会设置上限。 + +### 保存与分享动态工作流 + +在工作流菜单里按 "s" 可以保存工作流。你可以把它们签入 `~/.claude/workflows`，或通过 skill 分发。 + +通过 skill 分享时，把 JavaScript 工作流文件放进 skill 文件夹，并在 SKILL.md 里引用。为了保留更多弹性，你可能想提示 Claude 把 skill 里的工作流当作**模板**看待，而不是必须逐字执行的脚本。 + +## 一个新的探索起点 + +工作流是扩展 Claude Code 的一种有用的新方式。我鼓励你把它们当作一个起点，去探索让 Claude 帮你完成任务的新方法。关于怎么把它们用到最好，还有很多东西有待发现。欢迎告诉我你的发现。 + +关于"什么东西本来就该放进 harness"的原则，请参阅我们的三种 harness 设计模式。 + +*本文由 Anthropic Claude Code 团队的技术成员 Thariq Shihipar 与 Sid Bidasaria 撰写。* diff --git a/works/metr-uplift-update-translation.md b/works/metr-uplift-update-translation.md new file mode 100644 index 0000000..cb4597b --- /dev/null +++ b/works/metr-uplift-update-translation.md @@ -0,0 +1,89 @@ +--- +title: "我们正在更改开发者生产力实验的设计" +sourceTitle: "We are Changing our Developer Productivity Experiment Design" +sourceUrl: "https://metr.org/blog/2026-02-24-uplift-update/" +sourceAuthor: "Joel Becker, Nate Rush, Tom Cunningham, David Rein, Khalid Mahamud (METR)" +sourcePublishedAt: "2026-02-24" +sourceSiteName: "METR" +summary: "METR 那项著名的\"AI 辅助反而慢 19%\"RCT 的官方后续：late-2025 复现实验的原始结果转向加速（原班开发者 -18%、新开发者 -4%），但 METR 判定选择效应已使数据只剩很弱的证据力——开发者拒绝在无 AI 条件下工作、回避提交高增益任务、并发跑智能体使计时失效。实验设计本身要改了。" +sourceLanguage: "en" +language: "zh-CN" +translationMethod: "人工整理逐段翻译（cloud agent，对照原文全文）" +--- + +# 我们正在更改开发者生产力实验的设计 + +METR 此前发表过一篇论文，使用 2025 年 2 月至 6 月的数据发现：在经验丰富的开源开发者中，使用 AI 工具会导致完成任务的时间变慢 20%（**译注：即被广泛引用的"慢 19%"研究，19% 为点估计，此处原文行文取整为 20%**）。 + +为了理解 AI 对开发者生产力的影响如何随时间变化，我们在 2025 年 8 月启动了一项新实验，扩大了开发者池子，并使用最新的 AI 工具。 + +不幸的是，根据参与者反馈与问卷调查，我们认为新实验的数据对"AI 工具当前的生产力效应"给出的是**不可靠的信号**。首要原因是：我们观察到，选择不参与研究的开发者显著增多，因为他们**不愿意在没有 AI 的条件下工作**——这很可能使我们对 AI 辅助加速的估计被系统性压低。此外我们认为还存在因报酬降低（时薪从 150 美元降到 50 美元）带来的选择效应；而对于并发使用多个 AI 智能体的那部分开发者，我们对每个任务耗时的测量也不可靠。 + +基于与研究参与者的交流，我们认为：与我们对 2025 年初的估计相比，开发者现在（2026 年初）**更可能从 AI 工具中获得加速**。然而，由于实验中的选择效应，我们的数据对这一增幅的大小**只构成很弱的证据**。 + +我们的原始结果显示出一些加速的迹象。2025 年初的研究发现使用 AI 使任务耗时延长 19%，置信区间为 +2% 至 +39%。而对参与了后续研究的原班开发者子集，我们现在估计的加速为 **-18%**，置信区间 -38% 至 +9%；在新招募的开发者中，估计加速为 **-4%**，置信区间 -15% 至 +9%。 + +但在那些被实验"选择掉"的开发者和任务上，真实加速可能高得多。一些开发者自报了非常高的加速——不过正如我们在早前研究中记录的，这类自我估计可能相当不可靠。 + +鉴于这些选择效应的严重性，我们正在着手修改研究设计。下文将提供更多细节，并介绍我们研究 AI 对开发者生产力影响的其他手段。 + +## AI 的广泛采用，使任务级生产力测量变得更难 + +我们的第二项研究自 8 月开始，包含原研究的 10 名开发者，加上从更多样化的开源项目中新招募的 47 名开发者。参与者的报酬为每小时 50 美元。 + +与初始研究一样，开发者需要预先指定自己打算做的每个任务，然后提交任务描述参与随机分配。每个任务被分到"允许用 AI"或"禁止用 AI"条件。开发者记录完成任务所花的时间，我们据此比较典型任务在有 AI 和无 AI 条件下的平均耗时。 + +整个 2025 年，开源开发者中智能体工具（如 Claude Code 和 Codex）的使用不断增加。AI 的广泛采用对我们的研究产生了两个重要影响： + +**开发者的招募与留存变难了。** 越来越多开发者表示，他们不愿意在 50% 的工作中不用 AI——即使我们付每小时 50 美元、让他们做自己选择的任务。因此，我们的研究系统性地漏掉了对 AI 价值预期最乐观的那批开发者。 + +**开发者提交任务时变得更挑了。** 问卷显示，30% 到 50% 的开发者告诉我们，他们选择不提交某些任务，因为不想在没有 AI 的条件下做这些任务。这意味着我们系统性地漏掉了预期 AI 增益最高的任务。 + +这两个效应加在一起，使得上文报告的估计**很可能是 AI 对这些开发者真实生产力效应的下界**。选择效应似乎只影响少数开发者和任务，这限制了偏差的程度；但我们很可能缺失了 AI 最积极采纳者的数据，而他们恰恰可能是最值得关注的人群。随着 AI 能力持续增长、开发者预期水涨船高，这些效应只会愈发剧烈，进一步限制这种研究设计的效度。 + +基于访谈和问卷，我们认为选择效应增强的主因是开发者对 AI 增益的预期变高了。不过第二项研究的报酬也更低（每小时 50 美元 vs 原研究的 150 美元），这很可能也加剧了选择。 + +我们还注意到一些其他问题，尽管我们判断其严重程度较低： + +- 一些开发者表示，用智能体 AI 时他们**尝试的任务类型变了**，会倾向于发挥 AI 的长处。这有两个后果：(a) 研究内与研究外的任务选择不同；(b) 由于任务类型的替换，研究内的时间差可能无法代表价值差。 +- 一些开发者表示，同一任务在允许 AI 与禁止 AI 条件下的**最终产出质量不同**——例如主观代码质量、或他们选择编写的文档和测试的数量。 +- 一些开发者在任务被分到禁止 AI 条件后**更不愿意完成它**。有一位开发者没有完成任何被分到禁止 AI 条件的任务。 +- 一些开发者反映，使用智能体工具时**很难报告任务耗时**，因为他们经常在等智能体干活时去做别的无关任务。 + +综合起来，这些问题使我们的中心估计难以解读。我们认为它很可能不是 AI 工具对这些开发者真实生产力影响的好代理。 + +## 部分开发者原话 + +"我很纠结。我想帮忙为这个问题提供最新数据，但我也真的很喜欢用 AI！"——一位原 2025 年初研究的开发者，在被邀请参加 2025 年末研究时说。 + +"我发现我在挑 issue 上有严重偏向……我会回避那种 AI 两小时能搞定、我自己要花 20 小时的 issue。如果这种任务被随机到禁止 AI 组，我会非常痛苦。"——一位新研究的开发者，谈选择提交哪些任务时的选择效应。 + +"如果非要用老办法干太多活，我的头会炸掉。就像已经习惯了打 Uber 之后，突然又要走路穿过整座城市。"——另一位新研究的开发者。 + +## 测量生产力的其他手段 + +AI 工具对开发者生产力的影响，是 AI 研发加速的重要输入。我们计划继续探索以下研究路线： + +- **更高强度的实验。** 如果依从率更高，选择问题会得到缓解——可以通过运行更短、更密集的实验并可能提高报酬来实现。 +- **观察性数据。** 关于 AI 在软件开发中使用情况的丰富数据源很多——从聚合统计（例如约 4% 的 GitHub commit 由 Claude Code 署名）到细粒度转录。我们打算继续观察我们的开源开发者池，理解 AI 是如何被使用的。 +- **问卷调查。** 尽管自报的生产力反事实难以解读、可能有偏，我们仍乐观地认为，精心设计的问卷问题配合时间使用研究，能产生有用的信号。 +- **固定任务实验。** 我们的原始研究的新颖之处是让开发者先自选任务、再做随机化。我们可以退回更简单的设计：给开发者固定的任务，随机分配是否允许 AI 辅助。 +- **能力评测。** METR 会继续构建任务评测，衡量智能体自主完成任务的能力——这与智能体采纳的生产力效应有明确的相关性。 +- **开发者级实验。** 另一种设计是在开发者层面而非任务层面做随机化，即每位参与者要么所有任务都用 AI、要么都不用。这缓解了任务级的选择问题，但加重了开发者级的选择问题，并且检测生产力效应的统计功效更低。 + +随着模型能力持续提升，我们预计需要不断重新设计我们的一部分能力与测量技术。 + +## 生产力研究的细节 + +我们付给开发者每小时 50 美元，让他们在自己现有的开源项目上工作，并把 issue 随机分为允许 AI 或禁止 AI。开发者都是经验丰富的开源贡献者，从业年限中位数 10 年。我们的数据覆盖 57 名开发者、143 个仓库、800+ 个任务。 + +其中 10 名开发者来自原研究，其余为新招募，来自更多样化的仓库集合——包括更小、更绿地（greenfield）、成熟度更低的仓库。 + +早期研究的完整数据集与最近这次研究的数据集均已公开。 + +--- + +> **译注（本仓库视角）：** 这篇是 [YDD 效率悖论文章](../references/articles.md#article-41)所引用的 METR RCT（"AI 辅助反而慢 19%"）的官方后续。三点值得注意： +> 1. "慢 19%" 从此只能作为 **early-2025 的历史快照**引用，不能再当作活事实； +> 2. 新数据的方向转为加速（-18% / -4%），但 METR 自己反复强调这是**弱证据**——诚实报告测量失效本身，比给出一个新数字更有价值； +> 3. 最有信息量的发现或许是元层面的：**AI 渗透已经破坏了任务级 RCT 这种测量手段本身**（拒绝参与、回避提交高增益任务、并发智能体使计时失效）——"测量方法追不上被测对象"，与编码基准侧的诊断（[Position 论文](../references/articles.md#article-38)）同构。