Skip to content

Add Anthropic Harness Engineering insights to 4 deep-dive docs #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
wenshao merged 3 commits into from
Mar 28, 2026
Merged

Add Anthropic Harness Engineering insights to 4 deep-dive docs #5

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8e754f3
Add Anthropic Harness Engineering insights to 4 docs
wenshao Mar 28, 2026
7051fb2
Fix 4 issues from Qwen-Code + GLM-5.1 review
wenshao Mar 28, 2026
09b51ee
Fix 3 residual issues from Qwen-Code + GLM-5.1 round 2
wenshao Mar 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions docs/comparison/context-compression-deep-dive.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -215,6 +215,22 @@ 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 开发中发现：**模型在上下文接近容量时会提前结束工作**——不是因为任务完成，而是因为"感知到"上下文即将耗尽。

@wenshao wenshao Mar 28, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 事实错误："Opus 4.6" 应为 "Opus 4.5"

博客原文：

Opus 4.5 largely removed that behavior [context anxiety] on its own

博客中 Opus 4.6 的角色是取消了 Sprint Contract 和 Sprint 分解，而不是修复 context anxiety。

实际时间线：

  • Sonnet 4.5 → context anxiety 严重，需要 context reset
  • Opus 4.5 → 基本消除了 context anxiety
  • Opus 4.6 → 进一步提升长任务能力，取消了 Sprint 分解

建议修正为 **Opus 4.5**：大幅缓解了此问题

— Qwen-Code + GLM-5.1


- **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 接手"。

@wenshao wenshao Mar 28, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 小问题："Opus 4.5+" 是外推

修复后写的是：

新模型（Opus 4.5+）不焦虑

博客原文只说了 Opus 4.5 "largely removed" 了 context anxiety，没有对 4.5 之后的所有模型做保证。"4.5+" 是一个外推。建议改为更保守的 Opus 4.5 或 Opus 4.5 起。

— Qwen-Code + GLM-5.1 (Round 2)

**这解释了压缩阈值差异的深层原因**：
- Claude Code 设 ~95% 阈值——Opus 4.5 起 context anxiety 基本消除（"largely removed"），可以安全地晚触发
- 如果使用 Sonnet 作为主模型，可能需要更早触发或使用 context reset
- Gemini CLI 50% 阈值——可能 Gemini 模型也存在类似的 context anxiety

> **实践建议**：压缩阈值不应只考虑"保留多少上下文"，还应考虑"模型在多少容量下开始焦虑"。不同模型的焦虑阈值不同。

### 验证步骤的价值

只有 Gemini CLI 实现了独立验证（Phase 4 Probe）。其他所有工具都信任单次 LLM 输出。这是**成本与质量的核心权衡**——额外一次 LLM 调用的成本 vs 压缩质量提升。
Expand Down
40 changes: 39 additions & 1 deletion docs/comparison/multi-agent-deep-dive.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -272,16 +272,54 @@ 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） | 短任务、客观质量（代码正确性） |

@wenshao wenshao Mar 28, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 事实错误：评估标准混淆了前端和全栈两套不同标准

博客中实际有 两套不同的评估标准：

前端设计任务（4 维度）：

  1. Design quality（设计质量）
  2. Originality（原创性）
  3. Craft（工艺——排版层级、间距一致性、色彩和谐、对比度）
  4. Functionality（功能性——可用性）

全栈任务（4 维度）：

  1. Product depth（产品深度）
  2. Functionality（功能性）
  3. Visual design（视觉设计）
  4. Code quality（代码质量）

PR 中写的"设计质量、原创性、技术工艺、功能完整性"是前端标准的意译，但缺少来源说明这是前端设计任务的标准，而非通用标准。容易误导读者认为这是所有任务的统一标准。

建议明确标注这是前端设计任务的评估标准，或分别列出两套标准。

— Qwen-Code + GLM-5.1

| **关键发现** | "调校独立评估者比让生成者自我批评**容易得多**" | 多模型视角减少单一模型偏见 |

**Anthropic 的三代理架构**：

```
Planner（规划）
→ 将 1-4 句用户需求扩展为完整产品规格
→ 重范围界定，轻技术细节

Generator（生成）

@wenshao wenshao Mar 28, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 误导性省略：Sprint Contract 在 Opus 4.6 中被完全移除

博客原文：

Sprint construct was removed entirely with Opus 4.6, as the model could natively handle work without that decomposition.

PR 详细描述了 Sprint Contract 模式，但省略了关键信息：这个模式在更好的模型出现后就被废弃了。这对读者理解该模式的适用性很重要。

建议补充："⚠️ 该模式在 Opus 4.6 中中被完全移除，因为模型已能原生处理无分解的长任务。"

— Qwen-Code + GLM-5.1

→ 增量式实现，React/Vite/FastAPI/SQLite + Git

@wenshao wenshao Mar 28, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 残留：Sprint 时间线表述

修复后写的是：

Sonnet 4.5 需要 Sprint 才能保持连贯，Opus 4.6 直接移除了 Sprint 机制

博客原文的时间线：

  • Sonnet 4.5 → Sprint + Context Reset（harness v0）
  • Opus 4.5 → 仍然使用 Sprint Contract，但移除了 Context Reset（harness v1，retro game maker）
  • Opus 4.6 → 移除 Sprint 机制（harness v2，DAW）

"Sonnet 4.5 需要 Sprint"暗示 Sprint 是 Sonnet 特有的需求，但实际上 Opus 4.5 也在用 Sprint。更准确：Sprint 分解最初用于所有模型版本（包括 Opus 4.5），Opus 4.6 的长任务能力使 Sprint 机制被完全移除

— Qwen-Code + GLM-5.1 (Round 2)

→ Sprint 分解：v0/v1 harness 使用（含 Opus 4.5），v2（Opus 4.6）已移除

Evaluator（评估）

@wenshao wenshao Mar 28, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 残留：加权描述仍不准确

修复后写的是：

设计+原创性权重更高——推动模型承担更多审美风险

但博客原文的意思是：

Design quality and originality were emphasized over craft and functionality, since Claude already scored well on the latter two by default.

这是一个实用性校准（已经擅长的维度不需要额外加权），而非"推动模型承担审美风险"。两轮修改都未准确传达原文意思。

建议改为：（设计+原创性权重更高——因为 Claude 在工艺和功能性上已默认表现良好，不需要额外加权）

— Qwen-Code + GLM-5.1 (Round 2)

→ 通过 Playwright 测试运行中的应用
→ 前端设计评估 4 维度：设计质量、原创性、技术工艺（craft）、功能
（设计+原创性权重更高——因为 Claude 在工艺和功能性上已默认表现良好）
→ 全栈应用评估 4 维度：产品深度、功能完整性、视觉设计、代码质量
→ Few-shot 校准 + 显式怀疑指令
```

@wenshao wenshao Mar 28, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 表述不准确："主观维度权重 > 客观维度" 的归因有误

博客原文：

Design quality and originality were emphasized over craft and functionality, since Claude already scored well on the latter two by default.

这是一个实用性的校准决策（对已擅长的维度降低权重），而非"主观比客观更重要"的哲学判断。PR 中的"主观维度（设计、原创性）权重 > 客观维度（技术）"暗示了一种主客观价值的层级关系，扭曲了原文的意思。

建议改为："设计质量和原创性权重更高——因为 Claude 在工艺和功能性上已默认表现良好，不需要额外加权。"

— Qwen-Code + GLM-5.1


**关键洞察**：
- Generator 自评时倾向"自信地夸赞平庸作品"——与人类 code review 中的"自审盲区"一致
- Evaluator 天然倾向宽松，需要显式"怀疑指令" + few-shot 校准
- 评估标准的措辞会**隐式引导 Generator**（如"museum quality"导致视觉趋同）
- **Sprint 分解不是永恒的**——Sprint 最初用于所有模型（含 Opus 4.5），Opus 4.6 的长任务能力提升使得 Sprint 机制可以被完全移除（原文："I removed the sprint construct entirely"）

### 隔离策略

| Agent | 隔离方式 | 上下文共享 |
Expand Down
22 changes: 22 additions & 0 deletions docs/comparison/test-reflection-deep-dive.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 扫描 + 安全分析） | 完全分离 |

@wenshao wenshao Mar 28, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 小问题：Copilot CLI /review 的评估者描述

表中写 Copilot CLI /review 的评估者是"实际编译 + 运行测试（非 LLM）"。请确认是否确实完全使用确定性验证。根据项目中的 copilot-cli EVIDENCE.md，/review 可能也使用 LLM 进行代码分析。如果确实如此，"分离程度"列标注为"完全分离（确定性验证）"可能不够准确。

— Qwen-Code + GLM-5.1

| **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 评价自己的输出**。用独立代理、确定性工具（编译/测试）、或人类评审。

---

## 理想验证架构（未来方向）

目前没有任何工具同时实现：
Expand Down
2 changes: 2 additions & 0 deletions docs/guides/build-your-own-agent.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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。

---

## 选择决策树
Expand Down