一、引言：软件工程范式的再一次跃迁

软件工程的发展史，本质上是一部“控制权迁移”的历史。

• 早期：开发者完全控制机器（汇编语言）

• 中期：开发者通过抽象控制系统（高级语言、框架）

• 现代：开发者通过架构控制系统（微服务、云原生）

而在大模型（LLM）时代，这种控制权再次发生转移：

系统的行为，不再完全由代码决定，而是由“模型 + 控制系统”共同决定

这意味着一个根本变化：

• 过去：你写“怎么做”

• 现在：你设计“让 AI 怎么做”

围绕这一变化，逐渐形成了一套新的工程体系：

• Harness（控制层）

• Hermes Agent（调度层）

• 驱动式工程（Harness-based Engineering）

本文将从原理、结构、案例、工程实践四个层面，系统讲清这三者的关系。

---

二、Harness：驱动模型行为的控制核心

2.1 什么是 Harness？

Harness 本质上不是一个具体工具，而是一种工程结构：

Harness = 对大模型行为的系统性控制机制

它的作用类似于：

• 操作系统中的“调度控制”

• 分布式系统中的“控制面（Control Plane）”

---

2.2 为什么必须有 Harness？

大模型本质是概率系统，存在以下问题：

1）不稳定性

同样输入，可能输出不同结果。

---

2）不可控性

模型可能：

• 偏离任务

• 编造信息

• 忽略约束

---

3）不可复现性

难以保证一致行为。

---

4）不可组合性

难以直接嵌入复杂系统。

---

结论

如果没有 Harness，大模型无法成为工程系统的一部分

---

2.3 Harness 的四大组成模块

---

（1）Prompt：行为定义层

决定模型的：

• 角色（Role）

• 目标（Goal）

• 规则（Constraints）

示例：

你是一个法律顾问，回答必须基于事实，不得编造。

---

（2）Context：信息输入层

决定模型“看到什么”。

包括：

• 用户输入

• 历史对话

• 知识库（RAG）

• 系统状态

---

（3）Tool：能力扩展层

让模型具备执行能力：

• 查询数据库

• 调用 API

• 操作外部系统

---

（4）Execution：执行策略层

控制模型如何完成任务：

• 单轮推理

• 多轮推理（ReAct）

• 分步骤执行

---

2.4 Harness 的核心作用

可以总结为四句话：

限制输入
约束行为
扩展能力
控制执行

---

三、驱动式工程：Harness 的工程化范式

3.1 定义

驱动式工程 = 以 Harness 为核心，用其驱动模型行为的工程方法论

---

3.2 与传统工程的本质差异

传统工程（确定性）

if (user.level > 5) {
  unlockFeature()
}

---

驱动式工程（生成式）

请根据用户等级判断是否开放功能，并说明理由

---

本质区别

维度	传统工程	驱动式工程
控制方式	代码	Harness
决策主体	程序	模型
流程	固定	动态
可扩展性	低	高

---

3.3 驱动式工程的三个核心原则

---

原则一：行为外包给模型

开发者不再写决策逻辑，而是：

设计决策规则

---

原则二：系统围绕 Harness 构建

代码职责变为：

• 构建 Prompt

• 管理 Context

• 调度 Tool

---

原则三：流程由模型动态生成

系统不再是固定流程，而是：

由模型实时生成执行路径

---

四、案例一：智能客服系统（单 Harness）

---

4.1 目标

构建一个自动客服系统：

• 能理解用户问题

• 能查询数据

• 能生成回复

---

4.2 传统实现

需要写大量逻辑：

if (question.includes("订单")) { ... }
else if (question.includes("退款")) { ... }

问题：

• 难扩展

• 难维护

• 覆盖不全

---

4.3 Harness 实现

---

Prompt

你是一个专业客服，请准确回答用户问题，不确定时说明无法确认。

---

Context

• 用户问题

• FAQ 文档

• 订单数据

---

Tool

• 查询订单 API

• 查询物流 API

---

Execution

• 判断是否调用工具

• 再生成回复

---

4.4 效果

系统变成：

由 Harness 驱动模型理解问题并执行

---

五、Hermes Agent：系统级调度层

5.1 定义

Hermes Agent = 多个 Harness 的调度与编排系统

---

5.2 为什么需要 Hermes？

当系统复杂时：

• 多任务

• 多角色

• 多数据源

单个 Harness 已无法应对。

---

5.3 Hermes 的核心能力

---

1）任务拆解

把复杂任务拆成子任务。

---

2）Agent 调度

把任务分配给不同 Agent。

---

3）上下文分发

给不同 Agent 提供不同信息。

---

4）执行控制

控制顺序、并行、重试。

---

六、案例二：自动化内容生产系统（Hermes + 多 Harness）

---

6.1 目标

自动生成一篇高质量行业分析文章。

---

6.2 系统结构

Hermes（调度层）

负责整体流程。

---

多个 Agent（每个有 Harness）

---

6.3 子系统拆解

---

Agent 1：调研

• 收集数据

---

Agent 2：分析

• 提取结论

---

Agent 3：写作

• 生成文章

---

Agent 4：审核

• 检查逻辑

---

6.4 执行流程

用户请求
   ↓
Hermes 拆解任务
   ↓
调研 → 分析 → 写作 → 审核
   ↓
输出结果

---

6.5 核心点

• 每个 Agent 用 Harness 控制

• Hermes 只做调度

---

七、案例三：复杂任务执行系统（多步骤协同）

---

7.1 目标

自动生成一份商业计划书

---

7.2 任务拆解（Hermes）

1. 市场调研
2. 用户分析
3. 商业模型设计
4. 财务预测
5. 文档生成

---

7.3 执行结构

每一步都是一个 Agent（Harness）。

---

7.4 系统流程

Hermes
  ↓
多个 Harness Agent
  ↓
LLM + Tools

---

7.5 优势

• 高扩展性

• 可替换性

• 可优化性

---

八、案例四：自动化数据分析平台（进阶案例）

---

8.1 目标

用户上传数据 → 自动生成分析报告

---

8.2 Hermes 拆解任务

数据清洗
数据分析
图表生成
报告撰写

---

8.3 各 Agent（Harness）

---

数据清洗 Agent

• 清理异常值

---

分析 Agent

• 统计分析

---

可视化 Agent

• 生成图表

---

报告 Agent

• 写报告

---

8.4 核心价值

系统变成：

一个“自动运行的数据分析团队”

---

九、三者关系的最终结构

---

9.1 分层模型

驱动式工程（方法论）
   ↓
Harness（控制层）
   ↓
Hermes（调度层）
   ↓
LLM + Tools（执行层）

---

9.2 职责总结

层级	作用
Harness	驱动模型
Hermes	调度系统
驱动式工程	指导方法

---

十、为什么这是未来的软件形态？

---

10.1 系统复杂度提升

现代系统：

• 多任务

• 多数据

• 多角色

---

10.2 人类无法写完所有逻辑

必须让 AI 参与决策。

---

10.3 软件正在演化为“智能系统”

未来系统：

由多个智能体协同完成任务

---

十一、工程实践中的关键挑战

---

11.1 Prompt 不稳定

解决：

• 模板化

• 版本管理

---

11.2 Context 爆炸

解决：

• RAG

• 压缩策略

---

11.3 调度复杂

解决：

• 明确 Hermes 层

---

十二、最终总结

---

12.1 一句话结论

驱动式工程的核心是 Harness
Hermes 是其上的调度系统

---

12.2 再压缩一句

• Harness：控制 AI 行为

• Hermes：组织 AI 协作

---

12.3 本质理解

软件工程正在从“写逻辑”转向“设计智能系统”

---

结语

当系统不再只是代码，而是“智能体网络”时：

• Harness 让智能变得可控

• Hermes 让智能可以协同

而驱动式工程，则是连接两者的核心方法论。

这不仅是技术演进，更是软件工程的一次范式革命。