From 8e754f3c1f010c9bd080b4f7b51f559ebba273f2 Mon Sep 17 00:00:00 2001 From: wenshao Date: Sat, 28 Mar 2026 15:25:32 +0800 Subject: [PATCH 1/3] Add Anthropic Harness Engineering insights to 4 docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Source: "Harness design for long-running application development" https://www.anthropic.com/engineering/harness-design-long-running-apps (Prithvi Rajasekaran, Anthropic Labs, 2026-03-24) #30 Multi-Agent Deep-Dive: - New "GAN式评估 vs Arena竞争" comparison table - Anthropic 3-agent architecture (Planner→Generator→Evaluator) - Key insight: "tuning a standalone evaluator is far more tractable than making a generator critical of its own work" - Sprint Contract pattern: negotiate success criteria before coding - Evaluator calibration: explicit skepticism + few-shot alignment #27 Context Compression Deep-Dive: - New "Context Anxiety" concept: models prematurely finish work when context approaches capacity (Sonnet 4.5 severe, Opus 4.6 fixed) - Explains WHY compression thresholds differ across agents - Practical advice: threshold should consider model anxiety level #36 Test Reflection Deep-Dive: - New "生成者不应评价自己" principle with 5-agent comparison table - Anthropic finding: agents confidently praise mediocre self-output - Links to existing tool designs (Claude /review independent agents, Copilot actual compilation, Aider lint/test deterministic) build-your-own-agent.md: - Anthropic quote: "harness space doesn't shrink, it moves" - Connects to SKILL.md + Hooks as lightweight harness Co-Authored-By: Claude Opus 4.6 (1M context) --- .../context-compression-deep-dive.md | 14 +++++++ docs/comparison/multi-agent-deep-dive.md | 37 ++++++++++++++++++- docs/comparison/test-reflection-deep-dive.md | 22 +++++++++++ docs/guides/build-your-own-agent.md | 2 + 4 files changed, 74 insertions(+), 1 deletion(-) diff --git a/docs/comparison/context-compression-deep-dive.md b/docs/comparison/context-compression-deep-dive.md index 682c828c..59d88510 100644 --- a/docs/comparison/context-compression-deep-dive.md +++ b/docs/comparison/context-compression-deep-dive.md @@ -215,6 +215,20 @@ done_messages ──→ 总 token > max_tokens (1024)? | 中触发 | Goose（80%）/ Kimi（85%） | 接近上限 | 平衡保留与安全 | 大会话可能来不及 | | 晚触发 | Claude Code（~95%） | 接近极限 | 保留最多上下文 | 紧急压缩、无验证时间 | +### "Context Anxiety"上下文焦虑（来源：[Anthropic Engineering Blog](https://www.anthropic.com/engineering/harness-design-long-running-apps)，2026-03-24） + +Anthropic 工程团队在长任务 harness 开发中发现：**模型在上下文接近容量时会提前结束工作**——不是因为任务完成，而是因为"感知到"上下文即将耗尽。 + +- **Sonnet 4.5**：context anxiety 严重，单靠压缩不够，需要**完全重置上下文**（context reset）才能保持长任务连贯性 +- **Opus 4.6**：不再有此问题，SDK 自动压缩即可处理 + +**这解释了压缩阈值差异的深层原因**： +- Claude Code 设 ~95% 阈值——因为 Opus 4.6 不焦虑，可以安全地晚触发 +- 如果使用 Sonnet 作为主模型，可能需要更早触发（如 ECC 推荐的 50%） +- Gemini CLI 50% 阈值——可能 Gemini 模型也存在类似的 context anxiety + +> **实践建议**：压缩阈值不应只考虑"保留多少上下文"，还应考虑"模型在多少容量下开始焦虑"。不同模型的焦虑阈值不同。 + ### 验证步骤的价值 只有 Gemini CLI 实现了独立验证（Phase 4 Probe）。其他所有工具都信任单次 LLM 输出。这是**成本与质量的核心权衡**——额外一次 LLM 调用的成本 vs 压缩质量提升。 diff --git a/docs/comparison/multi-agent-deep-dive.md b/docs/comparison/multi-agent-deep-dive.md index 576886b1..08dcd75d 100644 --- a/docs/comparison/multi-agent-deep-dive.md +++ b/docs/comparison/multi-agent-deep-dive.md @@ -272,16 +272,51 @@ Action → EventStream（发布/订阅总线）→ Runtime → Observation → ## 设计模式对比 -### 协作 vs 竞争 vs 委托 +### 协作 vs 竞争 vs 评估 vs 委托 | 模式 | 代表 | 优势 | 劣势 | |------|------|------|------| | **协作分工** | Claude Teammates | 任务并行，效率高 | 协调复杂 | | **竞争选优** | Qwen Arena | 多视角，质量高 | 资源浪费（N 倍成本） | +| **GAN 式评估** | Anthropic Harness（Planner→Generator→Evaluator） | 独立评估，质量可控 | 延迟高，成本高 | | **专用委托** | Gemini 5 子代理 | 职责清晰，资源可控 | 灵活性有限 | | **事件解耦** | OpenHands EventStream | 最灵活，异步 | 架构最复杂 | | **流水线** | Aider Architect | 简单高效 | 非并行 | +### GAN 式评估 vs Arena 竞争（来源：[Anthropic Engineering Blog](https://www.anthropic.com/engineering/harness-design-long-running-apps)，2026-03-24） + +两种解决"Agent 自评失败"问题的不同路径： + +| 维度 | GAN 式评估（Anthropic Harness） | Arena 竞争（Qwen Code） | +|------|-------------------------------|----------------------| +| **核心思路** | 1 个 Generator + 1 个独立 Evaluator | N 个 Generator 竞争同一任务 | +| **质量保证** | Evaluator 按标准打分，不达标则退回重做 | 用户从 N 个结果中选最优 | +| **成本模型** | 固定（1 生成 + 1 评估 × 迭代次数） | 线性（N 倍生成成本） | +| **适用场景** | 长任务、主观质量（前端设计、UX） | 短任务、客观质量（代码正确性） | +| **关键发现** | "调校独立评估者比让生成者自我批评**容易得多**" | 多模型视角减少单一模型偏见 | + +**Anthropic 的三代理架构**： + +``` +Planner（规划） + → 将 1-4 句用户需求扩展为完整产品规格 + → 重范围界定，轻技术细节 + +Generator（生成） + → 增量式实现，每个 Sprint 前与 Evaluator 协商"冲刺契约" + → 使用 React/Vite/FastAPI/SQLite + Git + +Evaluator（评估） + → 通过 Playwright 测试运行中的应用 + → 4 维度评分：设计质量、原创性、技术工艺、功能完整性 + → 主观维度（设计、原创性）权重 > 客观维度（技术） +``` + +**关键洞察**： +- Generator 自评时倾向"自信地夸赞平庸作品"——与人类 code review 中的"自审盲区"一致 +- Evaluator 天然倾向宽松，需要显式"怀疑指令" + few-shot 校准 +- 评估标准的措辞会**隐式引导 Generator**（如"museum quality"导致视觉趋同） + ### 隔离策略 | Agent | 隔离方式 | 上下文共享 | diff --git a/docs/comparison/test-reflection-deep-dive.md b/docs/comparison/test-reflection-deep-dive.md index 7a291cca..c1eed864 100644 --- a/docs/comparison/test-reflection-deep-dive.md +++ b/docs/comparison/test-reflection-deep-dive.md @@ -212,6 +212,28 @@ _step() --- +## "生成者不应评价自己"原则 + +> 来源：[Anthropic Engineering Blog](https://www.anthropic.com/engineering/harness-design-long-running-apps)（2026-03-24） + +Anthropic 在长任务 harness 开发中发现了一个关键问题：**当 Agent 被要求评价自己产出的作品时，它会自信地夸赞——即使质量平庸**。 + +这解释了为什么各工具的验证架构都倾向于**分离生成和评估**： + +| 工具 | 生成者 | 评估者 | 分离程度 | +|------|--------|--------|---------| +| **Claude Code /review** | Sonnet（变更摘要） | **独立 Opus 代理**（Bug 扫描 + 安全分析） | 完全分离 | +| **Copilot CLI /review** | Agent | **实际编译 + 运行测试**（非 LLM） | 完全分离（确定性验证） | +| **Aider 反射循环** | 主模型 | **lint/test 工具**（非 LLM） | 完全分离（确定性验证） | +| **Anthropic Harness** | Generator | **独立 Evaluator**（Playwright 测试） | 完全分离 | +| **Qwen Code Arena** | 多个 Generator | **用户**选优 | 生成分离，评估靠人 | + +> **Anthropic 原文**："Tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work."（调校独立评估者比让生成者自我批评**容易得多**。） + +**实践建议**：如果你在构建 Agent 验证流程，**永远不要让 Agent 评价自己的输出**。用独立代理、确定性工具（编译/测试）、或人类评审。 + +--- + ## 理想验证架构（未来方向） 目前没有任何工具同时实现： diff --git a/docs/guides/build-your-own-agent.md b/docs/guides/build-your-own-agent.md index d427ca14..34652962 100644 --- a/docs/guides/build-your-own-agent.md +++ b/docs/guides/build-your-own-agent.md @@ -46,6 +46,8 @@ | **Git 集成** | 需自建 | 继承（checkpoint / rewind / worktree） | | **MCP 生态** | 需自接 | 内置支持 | +> **Anthropic 的 Harness 洞察**（[来源](https://www.anthropic.com/engineering/harness-design-long-running-apps)）："The space of interesting harness combinations doesn't shrink as models improve. Instead, it moves."——**Harness 的价值不会随模型进步消失，只会迁移**。今天需要的 Sprint 分解，明天可能不再需要；但新的 Harness 组件（如 Evaluator 校准、Context Anxiety 管理）会出现。选择"路径 B 成品扩展"不意味着不需要 Harness 思维——而是用 SKILL.md + Hooks 实现轻量级 Harness。 + --- ## 选择决策树 From 7051fb2a2d1ea343d8ff4a3bfb500f25991a2954 Mon Sep 17 00:00:00 2001 From: wenshao Date: Sat, 28 Mar 2026 15:35:11 +0800 Subject: [PATCH 2/3] Fix 4 issues from Qwen-Code + GLM-5.1 review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1. Context Anxiety model attribution: "Opus 4.6" → "Opus 4.5" Blog original: "Opus 4.5 largely removed that behavior on its own" 2. Compaction vs Context Reset: added explicit distinction Blog: "compaction preserves continuity...context anxiety can still persist" vs reset: "a clean slate, at cost of handoff artifact" 3. Evaluation criteria: split into TWO systems (were wrongly merged) - Frontend: design quality, originality, craft, functionality - Full-stack: product depth, functionality, visual design, code quality Weighting clarified: applies to frontend only 4. Sprint Contract lifecycle: added note it was REMOVED for Opus 4.6 Blog: "I removed the sprint construct entirely...Opus 4.6 could natively handle the job without this sort of decomposition" Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/comparison/context-compression-deep-dive.md | 10 ++++++---- docs/comparison/multi-agent-deep-dive.md | 11 +++++++---- 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/docs/comparison/context-compression-deep-dive.md b/docs/comparison/context-compression-deep-dive.md index 59d88510..0293855b 100644 --- a/docs/comparison/context-compression-deep-dive.md +++ b/docs/comparison/context-compression-deep-dive.md @@ -219,12 +219,14 @@ done_messages ──→ 总 token > max_tokens (1024)? Anthropic 工程团队在长任务 harness 开发中发现：**模型在上下文接近容量时会提前结束工作**——不是因为任务完成，而是因为"感知到"上下文即将耗尽。 -- **Sonnet 4.5**：context anxiety 严重，单靠压缩不够，需要**完全重置上下文**（context reset）才能保持长任务连贯性 -- **Opus 4.6**：不再有此问题，SDK 自动压缩即可处理 +- **Sonnet 4.5**：context anxiety 严重，**单靠 compaction（原地摘要）不够**——因为 compaction 保持了连续性但没有给 Agent 一个"干净起点"，焦虑仍然持续。需要**完全重置上下文**（context reset，清空重来）才能保持长任务连贯性 +- **Opus 4.5**：**基本消除了此行为**（原文："Opus 4.5 largely removed that behavior on its own"），可以移除 context reset 机制 + +> **Compaction vs Context Reset 的区别**（原文）：Compaction 是"原地摘要，保持连续性"；Context Reset 是"清空重来，代价是需要足够的交接信息让下一个 Agent 接手"。 **这解释了压缩阈值差异的深层原因**： -- Claude Code 设 ~95% 阈值——因为 Opus 4.6 不焦虑，可以安全地晚触发 -- 如果使用 Sonnet 作为主模型，可能需要更早触发（如 ECC 推荐的 50%） +- Claude Code 设 ~95% 阈值——新模型（Opus 4.5+）不焦虑，可以安全地晚触发 +- 如果使用 Sonnet 作为主模型，可能需要更早触发或使用 context reset - Gemini CLI 50% 阈值——可能 Gemini 模型也存在类似的 context anxiety > **实践建议**：压缩阈值不应只考虑"保留多少上下文"，还应考虑"模型在多少容量下开始焦虑"。不同模型的焦虑阈值不同。 diff --git a/docs/comparison/multi-agent-deep-dive.md b/docs/comparison/multi-agent-deep-dive.md index 08dcd75d..0b9585b8 100644 --- a/docs/comparison/multi-agent-deep-dive.md +++ b/docs/comparison/multi-agent-deep-dive.md @@ -303,19 +303,22 @@ Planner（规划） → 重范围界定，轻技术细节 Generator（生成） - → 增量式实现，每个 Sprint 前与 Evaluator 协商"冲刺契约" - → 使用 React/Vite/FastAPI/SQLite + Git + → 增量式实现，React/Vite/FastAPI/SQLite + Git + → 早期版本使用 Sprint 分解（Sonnet 4.5 需要），Opus 4.6 已移除 Sprint 机制 Evaluator（评估） → 通过 Playwright 测试运行中的应用 - → 4 维度评分：设计质量、原创性、技术工艺、功能完整性 - → 主观维度（设计、原创性）权重 > 客观维度（技术） + → 前端设计评估 4 维度：设计质量、原创性、技术工艺（craft）、功能 + （设计+原创性权重更高——推动模型承担更多审美风险） + → 全栈应用评估 4 维度：产品深度、功能完整性、视觉设计、代码质量 + → Few-shot 校准 + 显式怀疑指令 ``` **关键洞察**： - Generator 自评时倾向"自信地夸赞平庸作品"——与人类 code review 中的"自审盲区"一致 - Evaluator 天然倾向宽松，需要显式"怀疑指令" + few-shot 校准 - 评估标准的措辞会**隐式引导 Generator**（如"museum quality"导致视觉趋同） +- **Sprint 分解不是永恒的**——Sonnet 4.5 需要 Sprint 才能保持连贯，Opus 4.6 直接移除了 Sprint 机制（原文："I removed the sprint construct entirely"） ### 隔离策略 From 09b51ee12edbada6d73496c930c805d2526bcdab Mon Sep 17 00:00:00 2001 From: wenshao Date: Sat, 28 Mar 2026 15:42:25 +0800 Subject: [PATCH 3/3] Fix 3 residual issues from Qwen-Code + GLM-5.1 round 2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1. Weighting rationale: "推动审美风险" → "因为 Claude 在工艺和功能性 上已默认表现良好" (practical calibration, not risk-pushing) 2. Sprint timeline: "Sonnet 4.5 需要" → "Sprint 最初用于所有模型 （含 Opus 4.5），Opus 4.6 移除" (Sprint was used through Opus 4.5, not just Sonnet-specific) 3. "Opus 4.5+" extrapolation → "Opus 4.5 起" with "largely removed" qualifier (blog only confirmed Opus 4.5, not all subsequent models) Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/comparison/context-compression-deep-dive.md | 2 +- docs/comparison/multi-agent-deep-dive.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/comparison/context-compression-deep-dive.md b/docs/comparison/context-compression-deep-dive.md index 0293855b..2e351e3e 100644 --- a/docs/comparison/context-compression-deep-dive.md +++ b/docs/comparison/context-compression-deep-dive.md @@ -225,7 +225,7 @@ Anthropic 工程团队在长任务 harness 开发中发现：**模型在上下 > **Compaction vs Context Reset 的区别**（原文）：Compaction 是"原地摘要，保持连续性"；Context Reset 是"清空重来，代价是需要足够的交接信息让下一个 Agent 接手"。 **这解释了压缩阈值差异的深层原因**： -- Claude Code 设 ~95% 阈值——新模型（Opus 4.5+）不焦虑，可以安全地晚触发 +- Claude Code 设 ~95% 阈值——Opus 4.5 起 context anxiety 基本消除（"largely removed"），可以安全地晚触发 - 如果使用 Sonnet 作为主模型，可能需要更早触发或使用 context reset - Gemini CLI 50% 阈值——可能 Gemini 模型也存在类似的 context anxiety diff --git a/docs/comparison/multi-agent-deep-dive.md b/docs/comparison/multi-agent-deep-dive.md index 0b9585b8..97a67382 100644 --- a/docs/comparison/multi-agent-deep-dive.md +++ b/docs/comparison/multi-agent-deep-dive.md @@ -304,12 +304,12 @@ Planner（规划） Generator（生成） → 增量式实现，React/Vite/FastAPI/SQLite + Git - → 早期版本使用 Sprint 分解（Sonnet 4.5 需要），Opus 4.6 已移除 Sprint 机制 + → Sprint 分解：v0/v1 harness 使用（含 Opus 4.5），v2（Opus 4.6）已移除 Evaluator（评估） → 通过 Playwright 测试运行中的应用 → 前端设计评估 4 维度：设计质量、原创性、技术工艺（craft）、功能 - （设计+原创性权重更高——推动模型承担更多审美风险） + （设计+原创性权重更高——因为 Claude 在工艺和功能性上已默认表现良好） → 全栈应用评估 4 维度：产品深度、功能完整性、视觉设计、代码质量 → Few-shot 校准 + 显式怀疑指令 ``` @@ -318,7 +318,7 @@ Evaluator（评估） - Generator 自评时倾向"自信地夸赞平庸作品"——与人类 code review 中的"自审盲区"一致 - Evaluator 天然倾向宽松，需要显式"怀疑指令" + few-shot 校准 - 评估标准的措辞会**隐式引导 Generator**（如"museum quality"导致视觉趋同） -- **Sprint 分解不是永恒的**——Sonnet 4.5 需要 Sprint 才能保持连贯，Opus 4.6 直接移除了 Sprint 机制（原文："I removed the sprint construct entirely"） +- **Sprint 分解不是永恒的**——Sprint 最初用于所有模型（含 Opus 4.5），Opus 4.6 的长任务能力提升使得 Sprint 机制可以被完全移除（原文："I removed the sprint construct entirely"） ### 隔离策略