TomorrowBye | WAKAJA

开篇：一个令人不安的实验

2025 年 11 月，Anthropic 工程团队做了一个看似简单的实验：让 Claude Agent SDK 自主构建一个 claude.ai 的完整克隆应用。

结果出人意料地糟糕。

即使是当时最强大的模型 Opus 4.5，在连续多个 context window 的循环中，仅凭一个高层级提示词（比如'克隆 claude.ai'）根本无法构建出生产级质量的 Web 应用。

问题出在哪里？模型没有变笨。问题在于——没有人给 Agent 设计好它工作的环境。

Anthropic 团队随后设计了一套双层架构：一个初始化 Agent 搭建环境（功能清单、进度文件、初始化脚本），一个编码 Agent 逐个功能增量开发。结果性能飙升。这就是 Harness Engineering 的力量——不是让模型更强，而是让模型工作的环境更好。

'Harness design has a substantial impact on the effectiveness of long running agentic coding.' — Anthropic Engineering, Effective Harnesses for Long-Running Agents, 2025

这正是今天我们要聊的话题：Harness Engineering——AI 时代工程师必须掌握的新核心能力。

什么是 Harness Engineering？

先说清楚：Harness 不是 CI/CD，不是 DevOps 换个名字。

在 AI Agent 的语境下，Harness 是指围绕 AI Agent 构建的整个工作环境——包括初始化的上下文、可用的工具集、反馈机制、进度追踪、测试验证、状态管理等一切让 Agent 能够高效、可靠、持续工作的基础设施。

Anthropic 对 Context Engineering 的定义是：

'Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference.' — Anthropic, Effective Context Engineering for AI Agents, 2025

Harness Engineering 是这个概念的工程化延伸——不仅关注单个推理的上下文优化，更关注跨多个 Agent 会话的持续性环境设计。

简单说：Prompt Engineering 解决'怎么说'的问题，Context Engineering 解决'给什么信息'的问题，而 Harness Engineering 解决'如何搭建一个让 Agent 持续高效工作的完整系统'。

为什么需要它？

让我们直面三个 Agent 在没有良好 Harness 时的典型失败模式：

失败模式一：贪多嚼不烂

Agent 倾向于一次性尝试完成整个项目。它会在 context window 耗尽时留下一半实现、毫无文档的代码，下一个会话的 Agent 只能猜测前面发生了什么，花大量时间修复基础功能。

失败模式二： premature victory

在部分功能完成后，后续 Agent 实例环顾四周，看到已有进展，就会宣布任务完成——即使还有很多功能没实现。

失败模式三：自测缺失

Agent 做了代码变更，甚至跑了单元测试，但没有进行端到端验证。它认为功能完成了，但作为真实用户去使用时，问题一堆。

Anthropic 的解决方案揭示了 Harness Engineering 的核心价值：

用 feature_list.json 替代模糊的提示词
用 claude-progress.txt 替代' Agent 自己记住'
用 git commit + 进度更新 替代口头交接
用 init.sh + 浏览器自动化测试 替代'应该能跑吧'

这些不是花哨的 AI 技术，而是最基础的软件工程实践——只不过现在你的同事是一个没有记忆、但执行力极强的 AI Agent。

前端工程师的视角：UI 可测试性设计

2026 年 3 月，Anthropic Labs 的 Prithvi Rajasekaran 发表了一篇关于 Harness Design 的深度文章，揭示了一个关键洞察：主观质量可以被编码为可评估的标准。

他设计了四个评估维度：

设计质量：颜色、排版、布局、意象是否形成统一的整体风格？
原创性：有定制决策，还是模板化布局、库默认值和 AI 生成模式？
工艺：字体层级、间距一致性、色彩和谐度、对比度
功能性：用户能否理解界面功能、找到主要操作、完成任务？

然后他用这套标准构建了一个 Generator-Evaluator 循环，灵感来自 GAN（生成对抗网络）——一个 Agent 生成设计，另一个 Agent 用 Playwright MCP 直接操作页面并评分，反馈驱动迭代改进。

对前端工程师的启示是深刻的：

// ❌ 糟糕的设计：AI 无法评估
// '做一个好看的页面'
 
// ✅ Harness Engineering 的方式：
// 在你的组件系统中编码约束
interface DesignConstraint {
  maxColors: number // 配色方案上限
  spacingScale: number[] // 间距体系
  typographyLevels: Record<string, { size: string; weight: string }>
  accessibilityMinContrast: number
}
 
// Agent 生成设计后，自动验证约束
const violations = checkConstraints(designOutput, constraints)
// violations 直接驱动下一轮迭代

前端工程师在 Harness Engineering 中的核心任务：让设计决策变得可验证。设计系统的 token、组件契约、无障碍标准——这些不再只是团队协作的约定，而是 Agent 工作的边界条件。

后端工程师的视角：API 契约与服务边界

Anthropic 在 Writing Tools for Agents 中提出了一个关键概念：工具是确定系统与非确定性 Agent 之间的契约。

'Tools are a new kind of software which reflects a contract between deterministic systems and non-deterministic agents.' — Anthropic, Writing Effective Tools for AI Agents, 2025

对后端工程师来说，这意味着 API 设计的范式转变：

// ❌ 传统 API 设计：面向人类开发者
// GET /api/users?page=2&limit=20&sort=name
 
// ✅ Agent 友好的 API 设计：
// 1. 返回结构化、自描述的数据
// 2. 包含足够的上下文让 Agent 理解数据含义
// 3. 错误信息明确指向修复方向
 
interface AgentFriendlyResponse {
  data: User[]
  meta: {
    total: number
    hasNext: boolean
    nextPage: string | null
    // 明确告诉 Agent 下一步该做什么
    suggestedAction: string
  }
}
 
// MCP Tool 定义也要遵循最小可行集原则
// 如果人类工程师都无法明确判断该用哪个工具，
// Agent 更不可能做对

后端工程师在 Harness Engineering 中的角色：定义清晰的工具契约和验证边界。这包括：

为 Agent 编写专门的 MCP 工具，而非简单包装现有 API
工具返回值要 token-efficient，避免信息过载
工具之间功能边界清晰，避免模糊的决策点
错误处理要提供可执行的修复建议

全栈工程师的视角：端到端流程设计

当 Anthropic 将 Generator-Evaluator 模式扩展到全栈开发时，他们设计了一个 三 Agent 架构：Planner（规划）、Generator（生成）、Evaluator（评估）。

Planner → 拆解需求 → 功能清单
  ↓
Generator → 实现功能 → 提交代码 + 更新进度
  ↓
Evaluator → 端到端测试 → 评分 + 详细反馈
  ↓
Generator → 根据反馈迭代 → 改进或转向

这个架构的关键设计决策：

1. 增量开发

每个 Agent 会话只做一个功能。不贪多。完成一个、验证一个、提交一个。

2. 结构化交接

每个会话结束时，必须：

提交 git commit（带描述性信息）
更新 claude-progress.txt
确保代码处于可合并状态

3. 会话开始时先验证现状

新会话的 Agent 第一件事不是写代码，而是：

读 git log 和进度文件
运行 init.sh 启动开发服务器
用浏览器自动化测试基础功能
确认环境正常后再开始新功能

全栈工程师在 Harness Engineering 中的价值在于设计端到端的反馈闭环。你需要同时理解前端如何被测试、后端如何被验证、部署如何被监控——因为只有理解全链路，才能设计出有效的 Harness。

Agent 工程师的视角：一个全新的角色

如果你认为 Harness Engineering 意味着需要一个新的工程师角色，你是对的。

**Agent 工程师（Agent Engineer）**不是单纯的 Prompt Engineer，也不是传统的 DevOps。他们的核心职责是：

设计 Agent 的工作环境：上下文管理、工具集、验证机制
编写 Agent 可用的工具：MCP Server、API 包装、自动化脚本
构建评估体系：定义成功标准、设计测试用例、运行基准测试
监控和优化：追踪 Agent 的行为模式、识别失败模式、迭代改进

核心技能清单：

技能领域	具体内容
LLM 理解	Context Window 限制、Attention 机制、Context Rot
工具设计	MCP Protocol、Tool Description 优化、Token Efficiency
测试工程	端到端测试、浏览器自动化、评估框架设计
系统设计	多 Agent 编排、状态管理、错误恢复
观察性	Agent 行为追踪、性能指标、失败模式分析

核心能力清单

Harness Engineering 要求的技术栈和思维模式：

技术栈：

MCP（Model Context Protocol）—— Agent 工具生态的标准协议
Agent SDK（Claude Agent SDK 等）—— 编排 Agent 工作流
浏览器自动化工具（Playwright、Puppeteer）—— 端到端验证
Git 工作流 —— 状态管理和交接
评估框架 —— 量化 Agent 表现

思维模式：

增量思维：大任务拆解为小步骤，每个步骤可验证
契约思维：确定性系统与非确定性 Agent 之间的接口设计
反馈循环：生成 → 评估 → 迭代，而非一次到位
约束编码：把主观判断转化为可验证的标准
状态意识：每个会话都是独立的全新开始，必须显式管理状态

从何入手：渐进式路径

不要一上来就搞多 Agent 编排。以下是循序渐进的路径：

第一阶段：单个 Agent + 验证工具（1-2 周）

从最基本的开始。让一个 Agent 能在你的代码库中自主工作，但给它清晰的验证能力：

# 在你的项目根目录创建 CLAUDE.md
# 告诉 Agent 如何验证它的工作
 
# 测试
- 运行: npm test -- --findRelatedTests <changed-file>
- 不要运行全量测试套件
 
# 类型检查
- 运行: npx tsc --noEmit
 
# 提交前检查
- 运行: npm run lint

第二阶段：功能清单 + 进度追踪（2-3 周）

引入结构化任务管理：

{
  "category": "functional",
  "description": "用户可以注册并登录",
  "steps": ["点击注册按钮", "填写邮箱和密码", "验证邮箱", "成功登录"],
  "passes": false
}

第三阶段：多会话交接（4-6 周）

实现跨 context window 的状态管理：初始化 Agent + 编码 Agent + 结构化交接文件。

第四阶段：Generator-Evaluator 循环（6-8 周）

引入独立的评估 Agent，构建自动反馈迭代。

要解决的核心问题

Harness Engineering 不是炫技，它解决的是一个实实在在的问题：

如何让 AI Agent 在复杂、长期的任务中保持可靠？

Anthropic 的实验数据给出了答案。在 claude.ai 克隆项目中，没有 Harness 的情况下，Agent 无法完成生产级应用。有了 Harness 设计后，Agent 可以连续工作多个小时、跨越多个 context window、逐个功能地构建完整应用。

Prithvi 的三 Agent 架构（Planner + Generator + Evaluator）更是展示了 Harness Engineering 的上限：可以产出丰富的全栈应用，在多小时的自主编码会话中保持高质量。

成本-收益分析也很清晰：

投入：设计 Harness 的时间（功能清单、工具集、评估标准）
收益：Agent 从'无法完成任务'到'自主完成复杂项目'
杠杆效应：一次性的 Harness 设计可以复用于无数次的 Agent 执行

陷阱和边界

Harness Engineering 强大，但不是银弹。以下是明确的边界：

不该用 Harness Engineering 解决的问题：

简单的一次性任务：如果只是'帮我写个正则表达式'，直接问就好
需要人类创造力的工作：品牌故事、情感化文案、艺术创作——这些 Harness 帮不上忙
实时性要求极高的场景：Harness 的反馈循环需要时间，不适合毫秒级决策

常见陷阱：

过度设计 Harness：给 Agent 100 个工具，结果它不知道该用哪个。Anthropic 明确建议：工具集要最小化、边界要清晰。
评估标准偏差：Evaluator Agent 天然倾向于给 Generator 的工作打高分。需要 few-shot 示例校准，明确惩罚通用模式。
忽视 Context Rot：随着 context window 填满，模型的信息召回精度下降。必须主动管理上下文大小。
把 Harness 当 CI/CD：Harness 关注的是 Agent 工作的环境，不是代码的构建和部署流水线。两者有关联，但本质不同。

未来展望

Harness Engineering 正在快速演进。从 Anthropic 最近的工程博文时间线可以看出趋势：

2024 年 12 月：Building Effective Agents —— 定义基础模式
2025 年 9 月：Writing Tools for Agents —— 工具设计方法论
2025 年 9 月：Effective Context Engineering —— 上下文管理
2025 年 11 月：Effective Harnesses for Long-Running Agents —— Harness 设计模式
2026 年 3 月：Harness Design for Long-Running Apps —— 三 Agent 架构
2026 年 4 月：Scaling Managed Agents —— 解耦大脑与执行

这个演进路径清晰地指向一个方向：Agent 的 Harness 将越来越标准化、越来越智能、越来越重要。

未来的工程师可能不再直接写大部分代码，而是设计和维护 Agent 工作的 Harness——定义约束、编写工具、设计评估标准、监控 Agent 行为。

这不是工程师的末日，而是工程师能力的升级。就像编译器让我们从机器码解放到高级语言，Harness Engineering 将让我们从写每一行代码解放到设计让 Agent 写出好代码的系统。

参考资料

Anthropic Engineering, Effective Harnesses for Long-Running Agents, 2025 年 11 月
Anthropic Labs (Prithvi Rajasekaran), Harness Design for Long-Running Application Development, 2026 年 3 月
Anthropic, Effective Context Engineering for AI Agents, 2025 年 9 月
Anthropic, Building Effective Agents, 2024 年 12 月
Anthropic, Writing Effective Tools for AI Agents — Using AI Agents, 2025 年 9 月
Anthropic, Claude Code: Best Practices for Agentic Coding, 2025 年 4 月
Anthropic, Code Execution with MCP: Building More Efficient Agents, 2025 年 11 月
Anthropic, Scaling Managed Agents: Decoupling the Brain from the Hands, 2026 年 4 月
Claude 4 Prompting Guide, Multi-Context Window Workflows
Goodfellow et al., Generative Adversarial Networks, 2014