一、引言：Harness 的骨架
如果说 Harness Engineering 是一座大厦，那么它的骨架就是三大核心组件：
- 约束机制（Constraints） —— 定义边界，让 Agent 知道什么能做、什么不能做
- 反馈回路（Feedback Loops） —— 验证结果，让 Agent 知道自己的输出是否正确
- 控制平面（Control Plane） —— 指挥调度，让 Agent 的执行可控、可观测、可干预
这三大支柱相互支撑，共同构成了 Harness 的核心架构。本文将深入解析每一支柱的设计原理和实践方法。
二、第一支柱：约束机制（Constraints）
2.1 为什么需要约束？
AI Agent 的能力强大但不可控。如果没有约束，Agent 可能：
- 生成不符合项目规范的代码
- 使用不恰当的技术方案
- 引入安全漏洞
- 消耗过多资源
约束机制的本质：在释放 AI 能力的同时，确保其行为在预期的边界内。
2.2 约束的四个层级
┌─────────────────────────────────────────────────────────┐
│ 约束机制的四个层级 │
├─────────────────────────────────────────────────────────┤
│ │
│ 第 4 层：业务约束 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 领域模型规范 │ │
│ │ • 业务规则验证 │ │
│ │ • 数据一致性要求 │ │
│ │ • 合规性要求 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↑ │
│ 第 3 层：安全约束 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 输入验证规则 │ │
│ │ • 敏感数据处理限制 │ │
│ │ • 权限控制规范 │ │
│ │ • 安全编码标准 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↑ │
│ 第 2 层：代码约束 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 编码风格规范（缩进、命名、注释） │ │
│ │ • 代码结构要求（函数长度、复杂度） │ │
│ │ • 设计模式约束 │ │
│ │ • 文档规范 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↑ │
│ 第 1 层：架构约束 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 项目目录结构 │ │
│ │ • 模块划分和职责边界 │ │
│ │ • 接口定义和规范 │ │
│ │ • 技术栈限制 │ │
│ │ • 依赖管理规则 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 从底层到顶层，约束越来越具体，越来越贴近业务 │
│ │
└─────────────────────────────────────────────────────────┘
2.3 约束的实现方式
约束类型
实现方式
工具示例
架构约束
项目模板、脚手架
Cookiecutter、Yeoman
代码约束
Linter、Formatter
ESLint、Prettier、Black
安全约束
静态安全扫描
SonarQube、Snyk、CodeQL
业务约束
领域模型验证、单元测试
自定义验证框架
2.4 约束设计原则
1. 清晰可验证
yaml
复制
# 好的约束：具体、可验证
code_style:
max_line_length: 100
indent: 2_spaces
naming: camelCase
# 坏的约束：模糊、难验证
code_style:
write_clean_code: true
make_it_readable: true
2. 适度不过度
- 约束太松：Agent 行为不可控
- 约束太紧：限制 Agent 能力发挥
- 找到平衡点：约束核心边界，保留创新空间
3. 可进化
- 约束本身要可版本化
- 根据实践反馈持续优化
- 支持不同场景的灵活配置
三、第二支柱：反馈回路（Feedback Loops）
3.1 为什么需要反馈？
Agent 需要知道：
- 生成的代码是否正确？
- 是否符合预期？
- 如何改进？
反馈回路的本质：建立 Agent 自我学习和持续改进的机制。
3.2 反馈回路的层次结构
┌─────────────────────────────────────────────────────────┐
│ 反馈回路的三层结构 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 第一层：即时反馈（秒级） │ │
│ │ │ │
│ │ • 语法检查：编译/解释是否通过 │ │
│ │ • 静态分析：代码质量、潜在问题 │ │
│ │ • 格式检查：是否符合代码规范 │ │
│ │ │ │
│ │ 目的：快速捕获明显错误，减少无效迭代 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 第二层：功能反馈（分钟级） │ │
│ │ │ │
│ │ • 单元测试：函数/模块行为正确性 │ │
│ │ • 集成测试：模块间交互正确性 │ │
│ │ • 类型检查：类型系统一致性 │ │
│ │ │ │
│ │ 目的：验证功能正确性，确保代码行为符合预期 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 第三层：深度反馈（小时级） │ │
│ │ │ │
│ │ • 端到端测试：完整业务流程验证 │ │
│ │ • 性能测试：响应时间、吞吐量、资源消耗 │ │
│ │ • 安全测试：漏洞扫描、渗透测试 │ │
│ │ • 用户验收：业务方确认 │ │
│ │ │ │
│ │ 目的：全面验证系统质量，确保生产就绪 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
3.3 闭环反馈流程
┌─────────────────────────────────────────────────────────┐
│ 闭环反馈流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ Agent 生成代码 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 执行反馈检查 │ │
│ │ │ │
│ │ 语法检查 ──→ 通过 ──→ 静态分析 ──→ 通过 ──→ 单元测试 │ │
│ │ │ │ │ │ │
│ │ 失败 失败 失败 │ │
│ │ │ │ │ │ │
│ │ └────────────────┴────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ 生成错误报告 │ │
│ │ （位置、原因、建议） │ │
│ │ │ │ │
│ └────────────────────┼──────────────────────────────┘ │
│ │ │
│ ▼ │
│ Agent 接收反馈并修复 │
│ │ │
│ └────────→ 重新提交代码 ──→ 再次检查（循环） │
│ │
│ 直到所有检查通过 → 合并代码 → 部署上线 │
│ │
└─────────────────────────────────────────────────────────┘
3.4 反馈设计要点
1. 快速失败
- 低成本检查优先执行
- 尽早发现问题，减少资源浪费
2. 清晰具体
json
复制
// 好的反馈
{
"status": "failed",
"stage": "unit_test",
"file": "src/utils/helper.js",
"line": 42,
"error": "Expected 3 but got 5",
"suggestion": "Check the calculation logic at line 42"
}
// 坏的反馈
{
"status": "failed",
"message": "Tests failed"
}
3. 可行动
- 反馈要包含修复建议
- 最好能提供参考示例
四、第三支柱：控制平面（Control Plane）
4.1 为什么需要控制平面？
Agent 的执行需要：
- 调度：什么时候执行什么任务？
- 监控：执行得怎么样？
- 干预：出问题怎么办？
控制平面的本质：让 Agent 的执行可见、可控、可管理。
4.2 控制平面的核心组件
┌─────────────────────────────────────────────────────────┐
│ 控制平面架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 1. 任务调度器（Task Scheduler） │ │
│ │ │ │
│ │ • 任务队列管理：优先级、FIFO、公平调度 │ │
│ │ • 资源分配：CPU、内存、并发控制 │ │
│ │ • 依赖管理：任务间的依赖关系处理 │ │
│ │ • 负载均衡：多个 Agent 间的任务分配 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 2. 状态管理器（State Manager） │ │
│ │ │ │
│ │ • 执行状态跟踪：运行中、已完成、失败、暂停 │ │
│ │ • 检查点管理：定期保存执行状态 │ │
│ │ • 故障恢复：中断后从检查点恢复 │ │
│ │ • 历史记录：完整的执行历史可追溯 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 3. 监控告警系统（Monitoring & Alerting） │ │
│ │ │ │
│ │ • 性能监控：执行时间、资源消耗、吞吐量 │ │
│ │ • 质量监控：成功率、错误率、重试次数 │ │
│ │ • 异常检测：偏离正常模式的行为识别 │ │
│ │ • 告警通知：多渠道告警（邮件、Slack、PagerDuty） │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 4. 人机协作接口（Human-in-the-Loop） │ │
│ │ │ │
│ │ • 审批流程：关键操作的人工确认 │ │
│ │ • 手动干预：暂停、恢复、终止任务 │ │
│ │ • 反馈收集：人工评价 Agent 输出质量 │ │
│ │ • 知识注入：人工提供额外上下文信息 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
4.3 控制平面的工作流程
┌─────────────────────────────────────────────────────────┐
│ 控制平面工作流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. 任务提交 │
│ 人类工程师提交任务描述 │
│ │ │
│ ▼ │
│ 2. 任务调度 │
│ 调度器根据优先级和资源情况分配任务 │
│ │ │
│ ▼ │
│ 3. Agent 执行 │
│ Agent 在分配的资源上执行任务 │
│ 状态管理器持续跟踪执行状态 │
│ │ │
│ ▼ │
│ 4. 实时监控 │
│ 监控系统收集性能和质量指标 │
│ 异常时触发告警 │
│ │ │
│ ▼ │
│ 5. 完成或干预 │
│ ┌─────────────┐ │
│ │ 执行完成？ │ │
│ └──────┬──────┘ │
│ │ │
│ 是 ───┴─── 否 │
│ │ │ │
│ ▼ ▼ │
│ 结果输出 需要干预？ │
│ │ │
│ 是 ───┴─── 否 │
│ │ │ │
│ ▼ ▼ │
│ 人工介入 自动重试 │
│ - 审批 - 根据策略重试 │
│ - 指导 - 或标记失败 │
│ - 终止 │
│ │
└─────────────────────────────────────────────────────────┘
五、三大支柱的协同关系
5.1 相互支撑的结构
┌─────────────────────────────────────────────────────────┐
│ 三大支柱的协同关系 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ 控制平面 │ │
│ │ (Control) │ │
│ │ │ │
│ │ 指挥和监控 │ │
│ │ 确保可控性 │ │
│ └──────┬──────┘ │
│ │ │
│ ┌────────────┼────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 约束机制 │ │ 反馈回路 │ │ 持久执行 │ │
│ │(Constraints)│ │(Feedback)│ │(Durable)│ │
│ │ │ │ │ │ │ │
│ │ 定义边界 │ │ 验证结果 │ │ 保障可靠 │ │
│ │ 确保正确性│ │ 确保质量 │ │ 确保持续 │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ └────────────┼────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ AI Agent │ │
│ │ │ │
│ │ 在约束内执行 │ │
│ │ 根据反馈改进 │ │
│ │ 在控制下工作 │ │
│ └─────────────┘ │
│ │
│ 控制平面是大脑，约束和反馈是双手，共同驾驭 Agent │
│ │
└─────────────────────────────────────────────────────────┘
5.2 数据流动
┌─────────────────────────────────────────────────────────┐
│ 三大支柱间的数据流动 │
├─────────────────────────────────────────────────────────┤
│ │
│ 约束机制 ───────→ Agent ───────→ 生成代码 │
│ ↑ │ │
│ │ ▼ │
│ └────────────────────── 反馈回路 │
│ （根据反馈优化约束） │
│ │ │
│ ▼ │
│ 控制平面 │
│ （监控、调度、干预） │
│ │
│ 循环：约束 → 执行 → 反馈 → 优化 → 新的约束 │
│ │
└─────────────────────────────────────────────────────────┘
六、实践案例：三大支柱的设计示例
6.1 示例：Web 应用开发 Harness
yaml
复制
# constraints.yaml - 约束机制
architecture:
project_structure:
- frontend/
- components/ # React 组件
- pages/ # 页面
- utils/ # 工具函数
- backend/
- api/ # API 路由
- models/ # 数据模型
- services/ # 业务逻辑
- shared/ # 共享类型和常量
tech_stack:
frontend: React + TypeScript + TailwindCSS
backend: Node.js + Express + Prisma
database: PostgreSQL
coding_standards:
max_function_length: 50_lines
max_file_length: 300_lines
naming: camelCase
require_tests: true
security:
require_input_validation: true
no_hardcoded_secrets: true
sql_injection_prevention: true
---
# feedback.yaml - 反馈回路
feedback_loops:
instant:
- eslint_check
- typescript_compile
- prettier_format
functional:
- unit_tests:
coverage_threshold: 80%
- integration_tests:
require_database: true
deep:
- e2e_tests:
browser: chromium
- performance_tests:
max_response_time: 200ms
- security_scan:
tool: snyk
---
# control.yaml - 控制平面
control_plane:
scheduling:
max_concurrent_tasks: 5
priority_rules:
- bug_fix: high
- feature: medium
- refactor: low
state_management:
checkpoint_interval: 5_minutes
retention_period: 30_days
monitoring:
metrics:
- task_success_rate
- average_execution_time
- error_rate
alerts:
- condition: error_rate > 5%
action: notify_team
channel: slack
human_in_the_loop:
require_approval_for:
- database_migration
- api_breaking_change
- production_deploy
七、设计原则与最佳实践
7.1 三大支柱的设计原则
支柱
核心原则
关键问题
约束机制
清晰、适度、可进化
边界在哪里？如何验证？
反馈回路
快速、清晰、可行动
反馈有多快？是否具体？能修复吗？
控制平面
可见、可控、可干预
能看到吗？能控制吗？能介入吗？
7.2 常见陷阱
约束机制陷阱：
- ❌ 约束过于严格，限制 Agent 能力
- ❌ 约束过于宽松，Agent 行为失控
- ❌ 约束无法验证，成为摆设
反馈回路陷阱：
- ❌ 反馈太慢，Agent 迭代效率低
- ❌ 反馈模糊，Agent 无法理解
- ❌ 反馈无法行动，Agent 无法修复
控制平面陷阱：
- ❌ 监控不足，问题发现晚
- ❌ 控制过紧，影响 Agent 效率
- ❌ 缺乏干预手段，无法处理异常
八、结语：构建稳固的 Harness
三大支柱——约束机制、反馈回路、控制平面——共同构成了 Harness Engineering 的核心架构。
- 约束机制 确保 Agent 在正确的轨道上
- 反馈回路 确保 Agent 持续改进
- 控制平面 确保整个过程可控可靠
设计好这三大支柱，就构建了一个稳固的 Harness，让 AI Agent 能够高效、可靠、可持续地工作。
这是 Harness Engineering 的核心技能，也是 AI 时代工程师的必备能力。
