1. Harness 概念演进：三代范式
关键洞察：模型能力固然重要，但决定 AI Agent 生产可靠性的是 Harness 的质量。同等模型配合优秀 Harness，可以比裸模型输出提升数倍效果。
2. AI Agent Harness Engineering 设计方法
来源：Martin Fowler（Birgitta Böckeler, Thoughtworks 首席工程师，2026-04-02）
2.1 核心设计哲学
将人类开发者的隐性经验外部化、显性化。
| 人类开发者自带的隐性能力 | AI Agent 缺少的 |
|---|---|
| 无缝吸收组织规范 | 组织对齐意识 |
| 感知复杂认知代价 | 代码审美感知 |
| 承担社会责任 | 约定俗成的判断力 |
| 识别技术债 | 历史决策背景 |
2.2 双轨控制机制
Harness 的核心设计是通过前馈（Feedforward Guides）和反馈（Feedback Sensors）两条控制轨道管理 Agent 行为：
2.3 三种监管类别
根据监管目标，Harness 分为三个层次：
? 可维护性线束（Maintainability Harness）
监控内部代码质量和结构规范。
| 检测类型 | 计算型传感器 | 推理型传感器 |
|---|---|---|
| 可靠捕获 | 结构问题（重复代码、圈复杂度、风格违规） | 语义重复、冗余测试 |
| 挑战较大 | — | 误诊、过度工程化 |
工具：ESLint、Prettier、SonarQube、Semgrep、PMD
?️ 架构适应性线束（Architecture Fitness Harness）
监控架构约束、性能指标、可观测性规范。
| 前馈（Guides） | 反馈（Sensors） |
|---|---|
| 性能要求技能卡 | 性能基准测试 |
| 日志标准文档 | API 质量检查 |
| 模块边界规范 | ArchUnit 约束检测 |
| 依赖管理约定 | Dependency-Cruiser |
? 行为线束（Behaviour Harness）
监控功能行为正确性——当前最具挑战性的领域。
方法一：AI 生成测试 + 绿色测试套件 状态：置信度不足，存在测试与实现同步错误风险方法二：Approved Fixtures（审批通过的测试夹具） 状态：部分场景有效，非通用方案方法三：人工测试用例 + 自动执行 状态：目前最可靠，但需要大量人工投入方法四：LLM 作为评判者（LLM-as-Judge） 状态：推理成本高，但在语义验证上有独特价值
2.4 执行类型矩阵
| 执行类型 | 速度 | 确定性 | 成本 | 适用场景 |
|---|---|---|---|---|
| 计算型（Computational） | 毫秒~秒 | ✅ 确定 | 极低 | Linter、类型检查、单元测试、架构检测 |
| 推理型（Inferential） | 秒~分钟 | ❌ 概率性 | 较高 | 语义审查、设计质量评估、自然语言约束 |
原则：计算型传感器优先，推理型传感器作为补充。
2.5 时序策略——质量左移
2.6 AGENTS.md 规范（前馈引导核心组件）
AGENTS.md（或 CLAUDE.md、CURSOR_RULES 等）是 Agent 感知项目上下文的核心引导文件：
# AGENTS.md 标准结构## 项目概述- 系统用途、核心域、关键约束## 技术栈规范- 语言版本、框架版本、禁止使用的技术## 代码规范- 命名约定、目录结构、模块边界## 工作流程- 如何运行测试：`npm test`- 如何构建：`npm run build`- 如何启动：`npm run dev`## 禁止行为- 不得修改 /core 目录下文件- 不得引入新的直接依赖（需审批）## 当前上下文- 正在进行的功能：[Feature X]- 已知技术债：[描述]
2.7 持续改进循环（Steering Loop）
3. Anthropic 多智能体 Harness 架构设计
来源：Anthropic Engineering Blog（Prithvi Rajasekaran，2026-03-24）
3.1 核心问题
| 问题 | 描述 |
|---|---|
| 上下文窗口耗尽 | 长任务随上下文填满而失去连贯性 |
| 上下文焦虑 | 模型接近上下文限制时过早收尾 |
| 自我评估偏差 | 模型评估自己的输出时过度宽容 |
3.2 三代理架构（Full-Stack 场景）
3.3 前端设计 Harness：四维评分体系
| 维度 | 权重 | 评分要点 |
|---|---|---|
| Design Quality（设计质量） | ⭐⭐⭐⭐⭐ | 是否形成有机整体；颜色、排版、布局是否统一 |
| Originality（原创性） | ⭐⭐⭐⭐⭐ | 是否有自定义决策；惩罚 AI 生成模式（紫色渐变白卡片等） |
| Craft（工艺） | ⭐⭐⭐ | 排版层次、间距一致性、色彩和谐、对比度 |
| Functionality（功能性） | ⭐⭐⭐ | 用户能否理解界面、找到主操作、完成任务 |
3.4 上下文管理策略
| 策略 | 描述 | 适用场景 |
|---|---|---|
| Context Reset（上下文重置） | 清空窗口，携带结构化摘要继续 | 早期模型，上下文焦虑明显时 |
| Compaction（压缩） | 总结历史保留连续性 | 需要保持上下文连贯性时 |
| 连续会话 + 自动压缩 | 最新模型原生支持 | 模型能力强、上下文焦虑改善后 |
3.5 实验结果
| 方案 | 耗时 | 成本 | 输出质量 |
|---|---|---|---|
| 单代理（Solo） | 20 分钟 | $9 | 界面有缺陷，核心功能不工作 |
| 完整三代理 Harness | 6 小时 | $200 | 功能完整、可正常运行的完整应用 |
3.6 Harness 简化原则
"找到最简单的解决方案，只有在需要时才增加复杂度。"
每个 Harness 组件都编码了一个「模型做不到」的假设——这些假设必须随模型能力提升而定期重新检验。
