课程介绍

理解HarnessEngineering的核心概念与演进脉络，建立"Agent = Model + Harness"的系统认知；

掌握Guides（前馈控制）与Sensors（反馈控制）的分类体系与工程实现方法；

结合AICoding工具与智能体落地实践，学会构建可靠的Agent驾驭体系

课程对象

架构师、AI工程师、技术负责人、核心开发人员（建议30人以内）

课程产出

Agent Harness架构设计模板、Guides/Sensors清单与落地检查表、团队Harness工程化行动方案

课程大纲

背景导入：为什么需要HarnessEngineering？

• "能玩"与"能用于生产"的剪刀差：全球AIToken消耗量从2024年初到2026年3月暴增1800倍，但超过70%的企业LLMPoC走不到生产环境——缺的不是更好的模型，而是"驾驭"模型的工程能力

• 三代AI工程范式的演进：

Ø  2022-2024 Prompt Engineering：解决"怎么问"——优化单次交互的输入质量

Ø  2025 Context Engineering：解决"看到什么"——管理模型在一次会话中可见的信息

Ø  2026 Harness Engineering：解决"怎么运转"——让Agent跨越多次会话、自主运行时仍然可靠

• 里程碑事件：2026年2月，MitchellHashimoto（Terraform&Ghostty创造者）提出Agent =      Model + Harness公式；随后OpenAICodex团队发布实战报告（3人团队、零人工编码、5个月100万行生产代码），MartinFowler/Thoughtworks发布Guides-Sensors分类体系

模块一：HarnessEngineering核心概念与架构

目标：建立"驾驭工程"的系统认知，理解Harness的组成要素与设计原则。

1. Agent = Model + Harness：重新理解AI Agent

• 核心洞见：模型提供推理能力（日益商品化），Harness提供规则、约束、数据上下文和验证机制——让模型从"灵光一现"变为"可靠交付"

• Harness的定义：包裹在模型之外的完整基础设施——工具编排、状态管理、错误恢复、可观测性、多会话协调

2. Guides与Sensors：驾驭工程的两大支柱

来源：Martin Fowler / Birgitta Böckeler的分类体系

• Guides（前馈控制/指南）——在Agent行动之前约束和引导

Ø  系统提示词（SystemPrompt）

Ø  项目规范文件（CLAUDE.md / AGENTS.md）

Ø  约束文档与架构规则

Ø  目的：收窄行动空间，提供结构化知识，防患于未然

• Sensors（反馈控制/传感器）——在Agent行动之后观察和验证

Ø  评估（Evals）与验证循环

Ø  输出解析器（OutputParsers）

Ø  自动化测试与代码审查

Ø  目的：发现偏差，驱动自我修正

• 两种执行类型：

Ø  计算型（Computational）：确定性、快速——Linter、类型检查、结构化测试（毫秒~秒级）

Ø  推理型（Inferential）：语义分析、LLM-as-Judge——AI代码审查、意图校验（较慢、更贵、非确定性）

3. 研讨

• 回顾各自团队在AI Agent/AI Coding实践中遇到的"不可靠"问题，尝试用Guides/Sensors框架归类：哪些问题可以通过前馈控制预防？哪些需要反馈控制纠正？

模块二：Harness的工程实现——以AICoding为示范场景

目标：以AICoding场景为切入点，掌握Harness各组件的具体工程实现。

1. Guides实战：如何在Agent行动前建立约束

• CLAUDE.md / AGENTS.md——项目级驾驭规范

Ø  作用：为Agent提供持久化的项目上下文——代码规范、工作流约定、架构约束

Ø  实践：如何编写有效的规范文件（好的 vs. 差的CLAUDE.md对比）

Ø  "Prompt as Code"：规范文件纳入版本控制，像管理代码一样管理Agent指令

• Hooks——Agent生命周期事件钩子

Ø  概念：类似GitHooks，在Agent生命周期的关键节点自动执行用户定义的命令/脚本

Ø  应用场景：文件保存时自动格式化、提交前自动检查、工具调用前权限校验

Ø  这就是"每当Agent犯一次错，就在环境中工程化一个永久修复"（MitchellHashimoto的核心习惯）

2. Sensors实战：如何在Agent行动后验证和纠偏

• Linter与类型检查——计算型Sensor

Ø  LLM生成代码的常见错误模式与Linter规则定制

Ø  静态强制执行：结构化日志、命名规范、文件大小限制、平台特定可靠性要求

• 自动化测试——Agent产出的质量底线

Ø  单元测试 + 集成测试作为Agent自测手段

Ø  Commit级审查 + 里程碑级Review的双层质量保障机制

Ø  关键发现回顾：Commit级Review通过但里程碑级整体Review能发现深层问题

• LLM-as-Judge——推理型Sensor

Ø  用一个模型审查另一个模型的输出

Ø  AI + 人工双重CodeReview的实操流程

Ø  适用场景与局限性

• 可观测性（Observability）

Ø  对Agent决策过程的追踪与监控

Ø  OpenLLMetry等工具：基于OpenTelemetry的LLM调用与Agent步骤追踪

Ø  与既有监控体系（Grafana、Datadog等）的集成

3. 实操演练

• 以一个实际项目为例，现场配置一套完整的AI Coding Harness：

Ø  编写CLAUDE.md规范文件

Ø  配置Hooks（提交前检查、工具调用审批）

Ø  设置Linter规则

Ø  运行Agent观察Harness的控制效果

• 对比：有Harness vs. 无Harness的Agent输出质量差异

模块三：从AICoding到通用Agent——HarnessEngineering的扩展应用

目标：将HarnessEngineering思维从AICoding场景推广到企业级Agent系统的全面治理。

1. 企业级AgentHarness架构设计

• 编排循环（OrchestrationLoop）

Ø  TAO循环（Thought-Action-Observation）：组装提示 → 调用LLM → 解析输出 → 执行工具调用 → 结果回传 → 循环直到完成

Ø  与多智能体协作模式的结合：层级式/对等式/混合式编排中的Harness设计

• 工具层（ToolLayer）

Ø  工具注册、Schema验证、参数提取、沙箱执行、结果格式化

Ø  从Harness角度理解Skill：Skill即Harness中的标准化工具单元

• 护栏（Guardrails）设计

Ø  限制文件访问范围、要求提交前Lint、阻断破坏性命令（除非显式批准）

Ø  设计原则："先严后松"——从严格约束开始，随信心增长逐步放开

Ø  四类软件分级策略及过渡：第四类（人工值守）→第一类（全自动）对应从最严到最松的Guardrails配置

• 人类介入点（Human-in-the-Loop）设计

Ø  哪些操作需要人工审批：触及生产数据、修改基础设施、变更安全配置

Ø  人类的角色转变：从"写代码的人"到"在更高抽象层工作的人"——优先级排序、需求翻译为验收标准、结果验证

Ø  “敏捷AI工程”中AIBP角色：AIBP本质上是Harness中Human-in-the-Loop节点的承担者

2. "熵管理"——Harness的持续维护

• Agent环境的"漂移"问题：文档过时、规范偏离、工具版本不匹配

• OpenAI的实践：定期"垃圾回收"扫描——用Agent检测漂移并建议修复

• 与3AD生命周期的对应：第四阶段"自主运营与监控"的核心任务之一

3. 实战案例复盘

• OpenAI      Codex团队案例：3人团队、5个月、100万行代码——Harness如何让这成为可能

Ø  分层架构 + 自定义Linter强制依赖方向

Ø  1500个已合并PR，全部由Agent生成

• 企业级案例：CRM重构全程中的Harness实践——里程碑驱动、Commit级与Repo级审查、版本切分

• “敏捷AI工程”的大规模Harness实践：在大规模生产级智能体落地项目中，Ontology先行 + Fail Fast验证 + 周度复盘机制如何发挥Harness的作用

4. 研讨与工作坊

• 各组选取一个实际Agent/AICoding应用场景，设计完整的Harness方案：

Ø  列出需要的Guides清单（规范文件、Hooks、架构约束）

Ø  列出需要的Sensors清单（Linter规则、测试策略、审查流程、可观测性方案）

Ø  定义Human-in-the-Loop介入点与审批规则

Ø  设计"熵管理"机制——如何保持Harness本身不漂移

• 讲师点评与落地建议

模块四：落地路径与行动规划

目标：将HarnessEngineering理念转化为团队可执行的行动方案。

1. 团队Harness成熟度评估

• Level      0 — 裸奔：直接使用模型，无任何系统性约束

• Level      1 — 基础约束：有CLAUDE.md/AGENTS.md，有基本的Linter

• Level      2 — 系统化Harness：Guides + Sensors完整覆盖，有自动化测试与审查流程

• Level      3 — 自演进Harness：有"熵管理"机制，Harness随项目演进持续更新，Agent自身参与Harness维护

2. 从AICoding到组织能力的升级路径

• 近期（1个月）：为当前AICoding实践建立基础Harness——CLAUDE.md + Hooks + Linter

• 中期（2-3个月）：将Harness思维扩展到Agent项目——工具层标准化、护栏分级、可观测性建设

• 远期（4-6个月）：建立组织级Harness工程能力——Harness模板库、最佳实践沉淀、新角色定义

3. 新岗位与能力要求

• Harness      Engineer的能力模型：横跨Prompt Engineering、Context Engineering、DevOps、质量工程

• 与既有角色的融合：Skill封装工程师 → Harness工具层工程师、AI效能教练 → Harness成熟度教练

• 程序员能力转型方向的补充："架构师 + 提示词工程师 + 代码审查员" → "Harness工程师"

4. 综合研讨

• 各组制定团队HarnessEngineering行动方案：

Ø  当前成熟度自评

Ø  优先落地的Harness组件选择

Ø  2个月行动计划

• 讲师点评与Q&A