init commit
This commit is contained in:
Junjian Wang
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: Anthropic Harness 设计
|
||||
tags: [核心概念, 架构, 智能体]
|
||||
source: [Anthropic]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# Anthropic Harness 设计
|
||||
|
||||
**Anthropic Harness 设计**是 Anthropic 团队 Prithvi Rajasekaran 提出的多智能体架构，用于长时间运行的应用开发。该设计受生成对抗网络（GAN）启发，使用**生成器**和**评估器**智能体的组合。
|
||||
|
||||
## 问题背景
|
||||
|
||||
### 朴素实现的不足
|
||||
|
||||
之前的工作已经表明，Harness 设计对长时间运行的智能体编码的有效性有重大影响。但对于更复杂的任务，智能体仍然倾向于随着时间推移偏离轨道。观察到两种常见的失败模式：
|
||||
|
||||
1. **上下文窗口填充和"上下文焦虑"**：模型在冗长任务上随着上下文窗口填充而失去连贯性。一些模型还表现出"上下文焦虑"，当它们接近认为的上下文限制时会提前结束工作。
|
||||
|
||||
2. **自我评估问题**：当被要求评估它们自己生成的作品时，智能体倾向于自信地赞扬作品——即使，对于人类观察者来说，质量明显平庸。这个问题对于主观任务（如设计）特别明显，没有二进制检查相当于可验证的软件测试。
|
||||
|
||||
## 核心架构
|
||||
|
||||
### 三智能体系统
|
||||
|
||||
Anthropic 最终构建了一个三智能体系统，每个智能体解决先前运行中观察到的特定差距：
|
||||
|
||||
| 角色 | 职责 |
|
||||
|------|------|
|
||||
| **Planner（规划者）** | 将简单的 1-4 句话提示扩展为完整的产品规格 |
|
||||
| **Generator（生成者）** | 一次一个功能地实现规格，带有 git 版本控制 |
|
||||
| **Evaluator（评估器）** | 使用 Playwright MCP 测试运行中的应用，分级并提供详细反馈 |
|
||||
|
||||
### 上下文重置 vs 压缩
|
||||
|
||||
**上下文重置**：清空上下文窗口并启动一个新的智能体，结合携带先前智能体状态和下一步的结构化交接。
|
||||
|
||||
**上下文压缩**：将对话的早期部分就地摘要，以便同一个智能体可以在缩短的历史上继续。
|
||||
|
||||
虽然压缩保留了连续性，但它没有给智能体一个干净的状态，这意味着上下文焦虑仍然可能存在。重置提供了一个干净的状态，但代价是交接工件必须有足够的状态让下一个智能体干净地接手工作。
|
||||
|
||||
在早期测试中，发现 Claude Sonnet 4.5 表现出足够强的上下文焦虑，以至于仅靠压缩不足以实现良好的长任务性能，因此上下文重置成为 Harness 设计的必要条件。
|
||||
|
||||
## 前端设计：使主观质量可分级
|
||||
|
||||
### 两个洞见
|
||||
|
||||
1. 虽然美学不能完全简化为分数——而且个人品味总是会变化——但它们可以通过编码设计原则和偏好的分级标准来改善。
|
||||
2. 通过将前端生成与前端分级分离，可以创建一个推动生成器朝着更强输出发展的反馈循环。
|
||||
|
||||
### 四个分级标准
|
||||
|
||||
| 标准 | 描述 |
|
||||
|------|------|
|
||||
| **设计质量** | 设计感觉像是一个连贯的整体而不是部分的集合吗？ |
|
||||
| **原创性** | 是否有自定义决策的证据，还是只是模板布局、库默认值和 AI 生成的模式？ |
|
||||
| **工艺** | 技术执行：排版层次结构、间距一致性、色彩和谐、对比度。 |
|
||||
| **功能性** | 独立于美学的可用性。用户能理解界面做什么吗？ |
|
||||
|
||||
强调设计质量和原创性超过工艺和功能性。Claude 已经默认在工艺和功能性上得分很高，因为所需的技术能力往往自然而然地出现在模型中。但在设计和原创性上，Claude 经常产生充其量是乏味的输出。
|
||||
|
||||
### 生成-评估循环
|
||||
|
||||
构建在 Claude Agent SDK 上的循环：
|
||||
|
||||
1. 生成器智能体首先根据用户提示创建 HTML/CSS/JS 前端
|
||||
2. 给予评估器 Playwright MCP，让它在评分每个标准并编写详细批评之前直接与实时页面交互
|
||||
3. 该反馈流回生成器作为下一次迭代的输入
|
||||
4. 每次生成运行 5 到 15 次迭代
|
||||
|
||||
在每次评估后，指示生成器做出战略决策：如果分数趋势良好则改进当前方向，或者如果方法不起作用则转向完全不同的美学。
|
||||
|
||||
## 扩展到全栈编码
|
||||
|
||||
### 架构演变
|
||||
|
||||
Opus 4.5 基本上自行消除了上下文焦虑行为，因此可以完全从 Harness 中删除上下文重置。智能体作为一个连续会话在整个构建中运行，Claude Agent SDK 的自动压缩处理沿途的上下文增长。
|
||||
|
||||
### 冲刺契约
|
||||
|
||||
在每个冲刺之前，生成器和评估器协商一个**冲刺契约**：在编写任何代码之前就该工作块的"完成"看起来像什么达成一致。
|
||||
|
||||
这存在是因为产品规格故意是高级的，需要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提议它将构建什么以及如何验证成功，评估器审查该提议以确保生成器正在构建正确的东西。两者迭代直到达成一致。
|
||||
|
||||
### 结果对比
|
||||
|
||||
使用"创建一个带有关卡编辑器、精灵编辑器、实体行为和可玩测试模式的 2D 复古游戏制作器"提示进行的测试：
|
||||
|
||||
| Harness | 持续时间 | 成本 |
|
||||
|---------|---------|------|
|
||||
| Solo | 20 分钟 | $9 |
|
||||
| 完整 Harness | 6 小时 | $200 |
|
||||
|
||||
Harness 贵了 20 多倍，但输出质量的差异立即显而易见。
|
||||
|
||||
## Harness 简化迭代
|
||||
|
||||
### 移除冲刺构造
|
||||
|
||||
从 Harness 中完全移除了冲刺构造。保留了规划器和评估器，因为每个都继续增加明显的价值。将评估器移动到运行结束时的单次通过，而不是每个冲刺分级。
|
||||
|
||||
### 模型改进的影响
|
||||
|
||||
Opus 4.6 的发布提供了进一步减少 Harness 复杂性的动力。Opus 4.6 更仔细地规划、更长时间地维持智能体任务、可以在更大的代码库中更可靠地操作，并且具有更好的代码审查和调试技能来捕捉自己的错误。它还在长上下文检索方面有了实质性改进。
|
||||
|
||||
### 更新后的 Harness 结果
|
||||
|
||||
使用"使用 Web Audio API 在浏览器中构建功能完整的 DAW"提示进行的测试：
|
||||
|
||||
- 总持续时间：约 4 小时
|
||||
- 总成本：$124.70
|
||||
|
||||
大部分时间花在构建器上，它在没有 Opus 4.5 所需的冲刺分解的情况下连贯运行了两个多小时。
|
||||
|
||||
## 关键经验教训
|
||||
|
||||
随着模型继续改进，可以大致期望它们能够工作更长时间，处理更复杂的任务。在某些情况下，这将意味着随着时间推移，模型周围的支架变得不那么重要，开发人员可以等待下一个模型并看到某些问题自行解决。另一方面，模型越好，开发能够实现超出模型在基线水平所能做到的复杂任务的 Harness 的空间就越大。
|
||||
|
||||
有几个经验教训值得向前推进：
|
||||
|
||||
1. 用你正在构建的模型进行实验总是好的做法
|
||||
2. 在处理更复杂的任务时，有时可以通过分解任务并将专门的智能体应用于问题的每个方面来获得提升
|
||||
3. 当新模型落地时，重新检查 Harness 通常是好的做法，剥离那些不再对性能有负载作用的部分，并添加新部分以实现以前可能无法实现的更大能力
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Generator-Evaluator Loop|生成-评估循环]]
|
||||
- [[Context Reset|上下文重置]]
|
||||
- [[Planner|规划者]]
|
||||
- [[Generator|生成者]]
|
||||
- [[Evaluator|评估者]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. Anthropic - Harness design for long-running application development
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译*
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: 架构约束
|
||||
tags: [核心概念, 架构, Harness]
|
||||
source: [OpenAI, Martin Fowler, NxCode]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# 架构约束
|
||||
|
||||
**架构约束**（Architectural Constraints）是[[Harness-Engineering|Harness 工程]]的三大支柱之一。这是 Harness 工程与传统 AI 提示最显著不同的地方。与其告诉智能体"编写好代码"，不如**机械地强制执行好代码的样子**。
|
||||
|
||||
## 核心思想
|
||||
|
||||
### 约束反而提升生产力
|
||||
|
||||
矛盾的是，约束解决方案空间使智能体**更有生产力**，而不是更少。当智能体可以生成任何东西时，它会浪费 token 探索死胡同。当 Harness 定义清晰的边界时，智能体会更快地收敛到正确的解决方案。
|
||||
|
||||
### 为智能体优化代码库可读性
|
||||
|
||||
由于代码仓库完全由智能体生成，因此首先针对 Codex 的可读性进行了优化。就像团队会努力提升代码对新入职工程师的可导航性一样，人类工程师的目标也是让智能体能够直接从代码仓库推理出完整的业务领域。
|
||||
|
||||
从智能体的角度来看，它在运行时无法在情境中访问的任何内容都是不存在的。存储在 Google Docs、聊天记录或人们头脑中的知识都无法被系统访问。代码仓库本地的、已版本化的工件（例如，代码、Markdown、模式、可执行计划）就是它所能看到的全部。
|
||||
|
||||
## 分层领域架构
|
||||
|
||||
OpenAI 围绕一个严格的架构模型构建了应用。每个业务领域都划分为一组固定的层，依赖方向经过严格验证，并且仅允许有限的一组边。这些约束是通过自定义的 linter（当然是由 Codex 生成的！）和结构测试机械地强制执行的。
|
||||
|
||||
|
||||
|
||||
### 依赖分层规则
|
||||
|
||||
在每个业务领域内（例如应用设置），代码只能"向前"依赖于一组固定的层：
|
||||
|
||||
```
|
||||
Types → Config → Repo → Service → Runtime → UI
|
||||
```
|
||||
|
||||
横切关注点（认证、连接器、遥测、功能标志）通过一个单一的显式接口进入：Providers。其他任何内容都不被允许，并将通过自动化方式强制执行。
|
||||
|
||||
这种架构通常要等到你拥有数百名工程师时才会推迟。对于编码智能体来说，这是一个早期的先决条件：有了约束，速度才不会下降，架构才不会漂移。
|
||||
|
||||
## 约束强制执行工具
|
||||
|
||||
### 1. 确定性 Linters
|
||||
|
||||
自定义规则，自动标记违规。由于这些 lint 是自定义的，编写错误信息时会在智能体情境中注入修复指令。
|
||||
|
||||
在以人为本的工作流程中，这些规则可能会让人感到迂腐或束缚。有了智能体，它们就成了倍增器：一旦编码，它们就能立即应用于所有地方。
|
||||
|
||||
### 2. 基于 LLM 的审计员
|
||||
|
||||
审查其他智能体代码的架构合规性的智能体。
|
||||
|
||||
### 3. 结构测试
|
||||
|
||||
像 ArchUnit，但专门用于 AI 生成的代码。
|
||||
|
||||
### 4. 预提交钩子
|
||||
|
||||
在提交任何代码前的自动检查。
|
||||
|
||||
## 品味不变式
|
||||
|
||||
OpenAI 团队辅以一小组"品味不变式"。例如：
|
||||
|
||||
- 通过自定义 lint 静态地强制执行结构化日志记录
|
||||
- 模式和类型的命名约定
|
||||
- 文件大小限制
|
||||
- 特定平台的可靠性要求
|
||||
|
||||
## 明确界限
|
||||
|
||||
同时，还明确指出了哪些地方需要限制，哪些地方不需要限制。这类似于领导一个大型工程平台组织：在中央层面强制执行边界，在本地层面允许自主权。你非常重视界限、正确性和可重复性。在这些边界内，你允许团队或智能体在解决方案的表达方式上拥有很大的自由。
|
||||
|
||||
生成的代码不总是符合人类的风格偏好，这也没关系。只要输出是正确的、可维护的，并且对未来的智能体运行而言清晰易读，就可以算作达标。
|
||||
|
||||
## 依赖选择
|
||||
|
||||
这一框架明确了许多取舍。倾向于选择那些可以完全内化于在仓库中进行推理的依赖项和抽象。对智能体来说，通常被称为"枯燥"的技术，由于其可组合性、API 稳定性和在训练集里的表现，往往更容易建立模型。
|
||||
|
||||
在某些情况下，让智能体重新实现部分功能子集比绕过公共库中不透明的上游行为更便宜。例如，OpenAI 团队没有引入通用的 p-limit 风格包，而是投入使用了他们自己的带并发的 map 辅助函数：它与他们的 OpenTelemetry 仪表紧密集成，具备 100% 的测试覆盖率，并且其行为完全符合他们的运行时预期。
|
||||
|
||||
将系统的更多部分转化为智能体可以检查、验证并直接修改的形式，可以直接提高杠杆效应——这不仅适用于 Codex，也适用于其他智能体也在参与代码库的开发。
|
||||
|
||||
## 强制执行不变量
|
||||
|
||||
仅靠文档本身，是没法保持完全由智能体生成的代码库的连贯性的。通过强制执行不变量，而非对实施过程进行微观管理，令智能体能够快速交付，而且不会削弱基础。例如，要求 Codex 在边界处解析数据形状，但不规定具体实现方式（模型似乎偏好 Zod，但没有指定特定库）。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Context-Engineering|上下文工程]]
|
||||
- [[Entropy Management|熵管理]]
|
||||
- [[Layered Domain Architecture|分层领域架构]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. OpenAI - Harness Engineering：在智能体优先的世界中利用 Codex
|
||||
2. Martin Fowler - Harness engineering for coding agent users
|
||||
3. NxCode - Harness Engineering: The Complete Guide
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
title: 上下文工程
|
||||
tags: [核心概念, 上下文, Harness]
|
||||
source: [OpenAI, Anthropic, LangChain]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# 上下文工程
|
||||
|
||||
**上下文工程**（Context Engineering）是[[Harness-Engineering|Harness 工程]]的三大支柱之一，专注于确保智能体在正确的时间获得正确的信息。
|
||||
|
||||
## 核心原则
|
||||
|
||||
### 给地图，而不是一千页说明书
|
||||
|
||||
OpenAI 团队学到的最早经验之一很简单：要给 Codex 的是一张地图，而不是一本 1,000 页的说明书。
|
||||
|
||||
他们尝试了"一个大型的 AGENTS.md 方法。可想而知，这是一次失败的尝试：
|
||||
|
||||
- **上下文是一种稀缺资源**：一个巨大的指令文件会挤掉任务、代码和相关文档——因此智能体要么会错过关键约束条件，要么开始针对错误的约束条件进行优化。
|
||||
- **过多的指导反而变得无效**：当一切都"重要"时，一切都不重要了。智能体最终会在本地进行模式匹配，而不是有意识地进行导航。
|
||||
- **它会立即腐烂**：一本庞杂的手册会变成陈旧规则的坟场。智能体无法判断哪些信息仍然有效，一旦人类停止维护它，此文件就会悄然成为一个颇具吸引力的麻烦源头。
|
||||
- **这很难核实**：单个 blob 不适合进行机械检查（覆盖率、新鲜度、所有权、交叉链接），因此漂移是不可避免的。
|
||||
|
||||
因此，他们不再将 AGENTS.md 视为百科全书，而是将其视为内容目录。
|
||||
|
||||
## 静态上下文与动态上下文
|
||||
|
||||
### 静态上下文
|
||||
|
||||
静态上下文是仓库中不会频繁变化的文档和规范：
|
||||
|
||||
- **仓库本地文档**：架构规范、API 契约、风格指南
|
||||
- **AGENTS.md 或 CLAUDE.md 文件**：编码项目特定规则
|
||||
- **交叉链接设计文档**：由 linter 验证的设计文档
|
||||
|
||||
### 动态上下文
|
||||
|
||||
动态上下文是随时间变化的运行时信息：
|
||||
|
||||
- **可观测性数据**：日志、指标、追踪——智能体可访问
|
||||
- **目录结构映射**：智能体启动时的目录映射
|
||||
- **CI/CD 流水线状态**：测试结果和流水线状态
|
||||
|
||||
## 关键规则
|
||||
|
||||
**从智能体的角度来看，它无法在上下文中访问的任何内容都不存在。**
|
||||
|
||||
存储在 Google Docs、Slack 线程或人们头脑中的知识对系统是不可见的。**仓库必须是单一事实来源。**
|
||||
|
||||
### 渐进式披露
|
||||
|
||||
这个框架实现了渐进式披露：智能体从一个小而稳定的切入点开始，并被指导下一步该去哪里查看，而不是一开始就被淹没。
|
||||
|
||||
OpenAI 团队严格执行这一点。专职的 linter 和 CI 作业会验证知识库的更新状况、是否已交叉链接且结构正确。一个定期运行的"doc-gardening"智能体会扫描那些不再反映真实代码行为的过时或废弃文档，并发起修复用的 Pull Request。
|
||||
|
||||
## 实践中的上下文工程
|
||||
|
||||
### OpenAI 的知识库布局
|
||||
|
||||
```
|
||||
AGENTS.md
|
||||
ARCHITECTURE.md
|
||||
docs/
|
||||
├── design-docs/
|
||||
│ ├── index.md
|
||||
│ ├── core-beliefs.md
|
||||
│ └── ...
|
||||
├── exec-plans/
|
||||
│ ├── active/
|
||||
│ ├── completed/
|
||||
│ └── tech-debt-tracker.md
|
||||
├── generated/
|
||||
│ └── db-schema.md
|
||||
├── product-specs/
|
||||
│ ├── index.md
|
||||
│ ├── new-user-onboarding.md
|
||||
│ └── ...
|
||||
├── references/
|
||||
│ ├── design-system-reference-llms.txt
|
||||
│ ├── nixpacks-llms.txt
|
||||
│ ├── uv-llms.txt
|
||||
│ └── ...
|
||||
├── DESIGN.md
|
||||
├── FRONTEND.md
|
||||
├── PLANS.md
|
||||
├── PRODUCT_SENSE.md
|
||||
├── QUALITY_SCORE.md
|
||||
├── RELIABILITY.md
|
||||
└── SECURITY.md
|
||||
```
|
||||
|
||||
设计文档已被编目和索引，其中包括验证状态和一套核心理念，定义了智能体优先的操作原则。架构文档提供域和包分层的顶层地图。一份高质量的文档会对每个产品领域和架构层进行评分，并随着时间的推移追踪差距。
|
||||
|
||||
计划被视为一流的工件。临时轻量计划用于小幅变更，而复杂工作则记录在执行计划中，并附带进度和决策日志，这些日志会被提交到代码仓库。活跃计划、已完成计划和已知的技术债务都已进行版本控制并集中存放，使智能体能够在不依赖外部情境的情况下运行。
|
||||
|
||||
### LangChain 的 LocalContextMiddleware
|
||||
|
||||
LangChain 使用 `LocalContextMiddleware` 在智能体启动时运行，映射 `cwd` 和其他父+子目录。他们运行 `bash` 命令来查找工具如 `Python` 安装。上下文发现和搜索容易出错，因此注入上下文减少了这个错误表面并帮助**将智能体引导到其环境中。**
|
||||
|
||||
## 将更多情境推送到仓库中
|
||||
|
||||
随着时间的推移，需要将越来越多的情境推送到仓库中。那次让团队在架构模式上达成一致的 Slack 讨论？如果智能体无法发现它，那么它就会像迟了三个月入职的新员工一样，对其一无所知。
|
||||
|
||||
为 Codex 提供更多情境意味着要组织和展示正确的信息，好令智能体能够基于这些信息进行推理，而不是用临时指令使其不堪重负。就像你会在产品原则、工程规范和团队文化（包括表情符号偏好）方面为新队友提供引导一样，将这些信息提供给智能体会带来更一致的输出。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Harness-Engineering|Harness 工程]]
|
||||
- [[Context Reset|上下文重置]]
|
||||
- [[Context Anxiety|上下文焦虑]]
|
||||
- [[Architectural-Constraints|架构约束]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. OpenAI - Harness Engineering：在智能体优先的世界中利用 Codex
|
||||
2. LangChain - Improving Deep Agents with harness engineering
|
||||
3. Anthropic - Effective context engineering for AI agents
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
@@ -0,0 +1,137 @@
|
||||
---
|
||||
title: Harness 工程
|
||||
tags: [核心概念, Harness, 架构]
|
||||
source: [OpenAI, Anthropic, Martin Fowler, LangChain, NxCode]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# Harness 工程
|
||||
|
||||
**Harness 工程**（Harness Engineering）是设计和实现使 AI 智能体可靠工作的系统的新学科。如果说 2025 年是 AI 智能体验证它们能够编写代码的一年，那么 2026 年就是我们认识到**智能体不是难点——Harness 才是**的一年。
|
||||
|
||||
## 核心定义
|
||||
|
||||
### 什么是 Harness？
|
||||
|
||||
术语 "Harness" 来源于马具——缰绳、马鞍、马嚼子——用于引导强大但不可预测的动物朝正确方向前进的全套设备。这个比喻是有意为之的：
|
||||
|
||||
- **马**是 AI 模型——强大、快速，但自己不知道要去哪里
|
||||
- **Harness**是基础设施——约束、护栏、反馈循环，用于高效地引导模型的能力
|
||||
- **骑手**是人类工程师——提供方向，而不是亲自奔跑
|
||||
|
||||
没有 Harness，AI 智能体就像开放田野里的纯种马。快速、令人印象深刻，但对于完成任何事情来说完全无用。
|
||||
|
||||
### Harness 工程的正式定义
|
||||
|
||||
**Harness 工程**是设计和实现以下系统的学科：
|
||||
|
||||
1. **约束** AI 智能体可以做什么（架构边界、依赖规则）
|
||||
2. **告知** 智能体应该做什么（上下文工程、文档）
|
||||
3. **验证** 智能体正确执行了（测试、linting、CI 验证）
|
||||
4. **纠正** 智能体出错时（反馈循环、自我修复机制）
|
||||
|
||||
Martin Fowler 将其描述为"我们可以用来控制 AI 智能体的工具和实践"——但它不仅仅是安全。一个好的 Harness 使智能体**更有能力**，而不仅仅是更受控制。
|
||||
|
||||
## 为什么 Harness 工程现在如此重要
|
||||
|
||||
### 模型是商品，Harness 是护城河
|
||||
|
||||
AI 行业正面临一个令人不安的事实：**底层模型的重要性不如围绕它的系统。**
|
||||
|
||||
LangChain 明确证明了这一点。他们的编码智能体在 Terminal Bench 2.0 上从 **52.8% 提升到 66.5%**——从 **Top 30 跃升至 Top 5**——对模型没有做任何改变。他们只改变了 Harness：
|
||||
|
||||
| 改变 | 他们做了什么 | 影响 |
|
||||
|------|-------------|------|
|
||||
| 自我验证循环 | 添加完成前检查清单中间件 | 在提交前捕获错误 |
|
||||
| 上下文工程 | 启动时映射目录结构 | 智能体从一开始就理解代码库 |
|
||||
| 循环检测 | 跟踪重复的文件编辑 | 防止"末日循环" |
|
||||
| 推理三明治 | 规划/验证使用高推理，实现使用中等推理 | 在时间预算内获得更好的质量 |
|
||||
|
||||
**相同的模型。不同的 Harness。显著更好的结果。**
|
||||
|
||||
### OpenAI 的 100 万行代码证明点
|
||||
|
||||
OpenAI 的实验是迄今为止最令人信服的证据：
|
||||
|
||||
- **5 个月**的开发
|
||||
- 最终产品中有 **100 万+ 行代码**
|
||||
- **零行手动编写的代码**——每一行都是由 Codex 智能体生成的
|
||||
- **用人类所需时间的约 1/10 构建**
|
||||
- 产品有**内部日常用户和外部 Alpha 测试者**
|
||||
- 它**交付、部署、出故障并得到修复**——全部由 Harness 内的智能体完成
|
||||
|
||||
工程师的工作？设计 Harness。指定意图。提供反馈。不是编写代码。
|
||||
|
||||
## 三大支柱
|
||||
|
||||
OpenAI 的框架将 Harness 工程组织为三个核心类别：
|
||||
|
||||
### 1. 上下文工程
|
||||
|
||||
上下文工程是关于确保智能体在正确的时间获得正确的信息。
|
||||
|
||||
**静态上下文：**
|
||||
- 仓库本地文档（架构规范、API 契约、风格指南）
|
||||
- 编码项目特定规则的 `AGENTS.md` 或 `CLAUDE.md` 文件
|
||||
- 由 linter 验证的交叉链接设计文档
|
||||
|
||||
**动态上下文：**
|
||||
- 智能体可访问的可观测性数据（日志、指标、追踪）
|
||||
- 智能体启动时的目录结构映射
|
||||
- CI/CD 流水线状态和测试结果
|
||||
|
||||
**关键规则：** 从智能体的角度来看，它无法在上下文中访问的任何内容都不存在。Google Docs、Slack 线程或人们头脑中的知识对系统是不可见的。**仓库必须是单一事实来源。**
|
||||
|
||||
### 2. 架构约束
|
||||
|
||||
这是 Harness 工程与传统 AI 提示最显著不同的地方。与其告诉智能体"编写好代码"，不如**机械地强制执行好代码的样子**。
|
||||
|
||||
**依赖分层：**
|
||||
```
|
||||
Types → Config → Repo → Service → Runtime → UI
|
||||
```
|
||||
|
||||
每层只能从其左侧的层导入。这不是建议——它由结构测试和 CI 验证强制执行。
|
||||
|
||||
**约束强制执行工具：**
|
||||
- **确定性 linters**——自动标记违规的自定义规则
|
||||
- **基于 LLM 的审计员**——审查其他智能体代码的架构合规性
|
||||
- **结构测试**——像 ArchUnit，但用于 AI 生成的代码
|
||||
- **预提交钩子**——在提交任何代码前的自动检查
|
||||
|
||||
**为什么约束能改善输出：** 矛盾的是，约束解决方案空间使智能体**更有生产力**，而不是更少。当智能体可以生成任何东西时，它会浪费 token 探索死胡同。当 Harness 定义清晰的边界时，智能体会更快地收敛到正确的解决方案。
|
||||
|
||||
### 3. 熵管理（"垃圾回收"）
|
||||
|
||||
这是最被低估的组件。随着时间的推移，AI 生成的代码库会积累熵——文档与现实脱节、命名约定分歧、死代码堆积。
|
||||
|
||||
Harness 工程通过**定期清理智能体**来解决这个问题：
|
||||
- **文档一致性智能体**——验证文档与当前代码匹配
|
||||
- **约束违规扫描器**——找到逃过早期检查的代码
|
||||
- **模式强制执行智能体**——识别并修复与既定模式的偏差
|
||||
- **依赖审计员**——跟踪并解决循环或不必要的依赖
|
||||
|
||||
这些智能体按计划运行——每日、每周，或由特定事件触发——保持代码库对人类审查者和未来 AI 智能体都健康。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Context-Engineering|上下文工程]]
|
||||
- [[Architectural-Constraints|架构约束]]
|
||||
- [[Entropy Management|熵管理]]
|
||||
- [[OpenAI Harness Engineering|OpenAI Harness 工程]]
|
||||
- [[Anthropic-Harness-Design|Anthropic Harness 设计]]
|
||||
- [[LangChain Harness Engineering|LangChain Harness 工程]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. OpenAI - Harness Engineering：在智能体优先的世界中利用 Codex
|
||||
2. Anthropic - Harness design for long-running application development
|
||||
3. Martin Fowler - Harness engineering for coding agent users
|
||||
4. LangChain - Improving Deep Agents with harness engineering
|
||||
5. NxCode - Harness Engineering: The Complete Guide
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
title: 自我验证
|
||||
tags: [核心概念, 验证, Harness]
|
||||
source: [LangChain, Anthropic]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
---
|
||||
|
||||
# 自我验证
|
||||
|
||||
**自我验证**（Self-Verification）是[[Harness-Engineering|Harness 工程]]中的关键技术，使智能体能够通过运行中的反馈自我改进。当今的模型是卓越的自我改进机器，但它们没有自然地倾向于进入这种**构建-验证循环**。
|
||||
|
||||
## 核心概念
|
||||
|
||||
### 最常见的失败模式
|
||||
|
||||
LangChain 团队观察到的最常见失败模式是：智能体编写解决方案、重读自己的代码、确认看起来没问题，然后停止。
|
||||
|
||||
测试是自主智能体编码的关键部分。它有助于测试整体正确性，同时为智能体提供信号来进行爬山优化。
|
||||
|
||||
## 构建-验证循环
|
||||
|
||||
LangChain 向系统提示中添加了关于如何解决问题的指导：
|
||||
|
||||
### 阶段 1：规划与发现
|
||||
阅读任务、扫描代码库，并基于任务规格和如何验证解决方案构建初始计划。
|
||||
|
||||
### 阶段 2：构建
|
||||
在考虑验证的情况下实现计划。如果测试不存在则构建测试，并测试愉快路径和边缘情况。
|
||||
|
||||
### 阶段 3：验证
|
||||
运行测试、阅读完整输出、与要求的内容进行比较（而不是与你自己的代码）。
|
||||
|
||||
### 阶段 4：修复
|
||||
分析任何错误、重新访问原始规格，并修复问题。
|
||||
|
||||
## LangChain 的实现
|
||||
|
||||
### PreCompletionChecklistMiddleware
|
||||
|
||||
除了提示外，确定性上下文注入有助于智能体验证它们的工作。LangChain 使用 `PreCompletionChecklistMiddleware` 在智能体退出前拦截它，并提醒它对任务规格运行验证通过。
|
||||
|
||||
这类似于 [Ralph Wiggum Loop|Ralph Wiggum 循环]]，其中一个钩子在智能体退出时强制其继续执行，用于验证。
|
||||
|
||||
|
||||
|
||||
### 强调测试
|
||||
|
||||
LangChain 真正专注于测试，因为它在每次迭代中推动变化。他们发现，测试必须是智能体工作流程的核心部分，而不是事后想法。
|
||||
|
||||
## 环境上下文工程
|
||||
|
||||
Harness 工程的一部分是**为上下文工程构建良好的交付机制。** Terminal Bench 任务带有目录结构、内置工具和严格的超时。
|
||||
|
||||
### 1. 目录上下文与工具
|
||||
`LocalContextMiddleware` 在智能体启动时运行，映射 `cwd` 和其他父+子目录。运行 `bash` 命令来查找工具如 `Python` 安装。上下文发现和搜索容易出错，因此注入上下文减少了这个错误表面并帮助**将智能体引导到其环境中。**
|
||||
|
||||
### 2. 教导智能体编写可测试的代码
|
||||
智能体不知道它们的代码需要如何可测试。添加提示说它们的工作将根据程序化测试来衡量，类似于提交代码时。例如，提及文件路径的任务规格应该被精确遵循，以便解决方案在自动化评分步骤中工作。强调边缘情况的提示有助于智能体避免仅检查"愉快路径"情况。强制模型符合测试标准是避免随着时间推移"烂泥堆积"的强大策略。
|
||||
|
||||
### 3. 时间预算
|
||||
注入时间预算警告以推动智能体完成工作并转向验证。智能体在时间估计方面是出了名的糟糕，因此这种启发式在这种环境中有所帮助。现实世界编码通常没有严格的时间限制，但如果不添加任何约束知识，智能体就不会在时间范围内工作。
|
||||
|
||||
## 循环检测
|
||||
|
||||
智能体一旦决定了一个计划就可能变得短视，导致"末日循环"，对同一破碎方法进行小幅变异（在某些轨迹中超过 10 次以上）。
|
||||
|
||||
LangChain 使用 `LoopDetectionMiddleware`，通过工具调用钩子跟踪每个文件的编辑次数。它在对同一文件进行 `N` 次编辑后添加上下文如"……考虑重新考虑你的方法"。这可以帮助智能体从末日循环中恢复，尽管如果模型认为正确的话它可以继续沿着相同的路径前进。
|
||||
|
||||
重要提示：这是一种设计启发式，围绕当今感知的模型问题进行工程设计。随着模型改进，这些护栏可能会变得不必要，但今天帮助智能体正确和自主地执行。
|
||||
|
||||
## 推理三明治
|
||||
|
||||
推理模型可以自主运行数小时，因此必须决定在每个子任务上花费多少计算。你可以在每个任务上使用最大推理预算，但大多数工作可以从优化推理计算支出中受益。
|
||||
|
||||
Terminal Bench 超时限制创造了一个权衡。更多推理有助于智能体评估每个步骤，但可以燃烧超过 2 倍以上的 token/时间。`gpt-5.2-codex` 有 4 种推理模式，`low`、`medium`、`high` 和 `xhigh`。
|
||||
|
||||
LangChain 发现推理有助于规划以充分理解问题，一些 Terminal Bench 任务非常困难。一个好的计划有助于更快地得到可行的解决方案。
|
||||
|
||||
后期验证也从更多推理中受益，以捕获错误并提交解决方案。作为一种启发式，选择 xhigh-high-xhigh"**推理三明治**"作为基线。
|
||||
|
||||
|
||||
|
||||
**在规划和验证上花费更多的推理计算**
|
||||
|
||||
仅在 `xhigh` 运行由于智能体超时而得分较差，为 `53.9%`，相比之下在 `high` 为 `63.6%`。在推理预算分割的试验运行中没有大的差异，因此坚持使用他们的方法，将分数推到 `66.5%`。
|
||||
|
||||
## Harness 工程师的目的
|
||||
|
||||
**Harness 工程师的目的：准备和交付上下文，使智能体能够自主完成工作。**
|
||||
|
||||
智能体对其环境、约束和评估标准了解得越多，它们就能越好地自主自我指导工作。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[Build-Verify Loop|构建-验证循环]]
|
||||
- [[Reasoning Sandwich|推理三明治]]
|
||||
- [[Doom Loop|末日循环]]
|
||||
- [[Loop Detection|循环检测]]
|
||||
- [[LangChain Harness Engineering|LangChain Harness 工程]]
|
||||
|
||||
## 参考来源
|
||||
|
||||
1. LangChain - Improving Deep Agents with harness engineering
|
||||
2. Anthropic - Harness design for long-running application development
|
||||
|
||||
---
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
Reference in New Issue
Block a user