AI 工程的三大角色：从 Prompt 到 Harness

引言：为什么需要重新定义 AI 工程角色

当人们谈论”AI 工程师”时，大多数人的直觉是：这是一个懂得调用模型 API、设计产品界面、处理数据的软件开发者。这种理解并不完全错误，但它忽略了一个更本质的问题：

今天的 AI 系统已经不再是一个单纯的模型接口，而是一个由多个不稳定部件组成的复杂工程系统。

在这个系统中，最不稳定、最不可控、却又最有生产力的核心部件，恰恰是那个会说话、会推理、会调用工具的模型本身。这带来一个根本性的工程挑战：

如何让一个不可靠的概率分布，在真实工程环境中表现出可预测、可控制、可验证的行为？

回答这个问题，需要三种不同层面的工程能力：Prompt Engineering、Context Engineering、Harness Engineering。它们不是三个并列的职业选择，而是一套嵌套的能力体系——每一层都以上一层为基础，每一层都解决不同层面的问题。

---

一、Prompt Engineer：设计模型的交互语言

1.1 核心任务

Prompt Engineer 的职责是设计、优化与模型的交互语言。这是入门门槛最低但天花板最高的领域。

很多人误以为 Prompt Engineering 就是”写几句话”，但优秀的提示工程师需要：

• 深刻理解模型行为特性——知道模型在什么情况下会胡说、会误解、会过度推理
• 掌握思维链、少样本学习、结构化输出等技术——这些不是修辞技巧，是控制模型推理路径的工程手段
• 具备领域知识——知道如何将专业知识”翻译”给模型

1.2 从技艺到工程化

Prompt Engineering 正在从”技艺”走向”工程化”。单纯靠直觉写提示词的时代正在过去，取而代之的是可量化、可测试、可迭代的提示词开发流程。

这意味着：

• 提示词需要版本管理
• 提示词效果需要量化评估
• 提示词变更需要回归测试
• 提示词组合需要优先级规则

《Claude Code 设计指南》中有一个关键判断：

Prompt 不是人格设定，是控制平面的一部分——它更像宪法，不是台词。

这改变了我们对 Prompt 的理解：它不只是一段写给模型的”开场白”，而是一套定义行为边界、规定执行约束、处理例外情况的运行时协议。在成熟的系统中，Prompt 是分层的、有优先级的、与其他模块紧密耦合的制度文本。

1.3 Prompt Engineer 的能力边界

Prompt Engineer 能做到的是：

• 调整模型的输出风格和格式
• 引导模型的推理路径
• 约束模型在某些场景下的行为

Prompt Engineer 做不到的是：

• 消除模型的不可靠性本质
• 保证模型在所有情况下都正确
• 代替运行时层面的约束机制

一个很会道歉的系统不一定成熟。一个知道何时不该开始、何时该重试、何时该中止、何时该准确汇报失败的系统，才更接近成熟。

---

二、Context Engineer：管理进入模型的信息窗口

2.1 核心任务

Context Engineer 的职责是管理进入模型的信息窗口。这可能是当前最具价值的角色，因为模型的输出质量很大程度上取决于你喂给它什么信息。

关键技能包括：

• RAG 系统设计——检索增强生成，决定哪些知识被召回、如何排序、如何呈现
• 对话历史管理策略——多轮对话中保留什么、压缩什么、丢弃什么
• 知识库构建与维护——长期知识的组织、更新、验证
• 多轮对话的状态追踪——当前任务的进度、已完成的步骤、遗留的问题

2.2 上下文是工作内存，不是垃圾桶

《Claude Code 设计指南》中有一个核心观点：

上下文是工作内存，不是信息仓库。

这打破了一个常见的错觉：“信息越多，系统越聪明。“上下文不是一个”存进去就算拥有”的仓库，它首先是一笔昂贵、易膨胀、还会自我污染的预算。

Context Engineering 的真正挑战在于：

不是让模型”知道更多”，而是让模型”知道该知道的、能继续工作的部分”。

这意味着：

需要保住的内容	需要压缩或丢弃的内容
当前工作状态	冗长的历史对话
最近访问的文件	重复出现的附件
错误修正记录	运行时可重新获取的信息
任务计划和约束	已完成的中间过程

2.3 Context Engineering 与 Prompt Engineering 的关系

Context Engineering 是 Prompt Engineering 的自然延伸，也是从”玩具”到”产品”的关键跨越。

一个再好的提示词，如果上下文信息混乱或缺失，也无法发挥作用。反过来，一个组织良好的上下文，如果缺乏清晰的 Prompt 约束，也会被模型漫无目的地消费。

两者的关系可以这样理解：

Prompt Engineer 设计了"容器"（告诉模型应该成为什么）
Context Engineer 设计了"内容"（告诉模型应该看到什么）

容器决定边界，内容决定质量。两者缺一不可。

---

三、Harness Engineer：构建 AI 应用的完整基础设施

3.1 核心任务

Harness Engineer 的职责是构建 AI 应用的完整基础设施。这是最高层次的角色，也是最紧缺的。

关注点包括：

• 模型选择与切换策略——何时用哪个模型、如何处理模型变更
• 工具调用与 Agent 系统设计——模型能调用什么工具、调用时受什么约束
• 输出验证与安全护栏——如何验证模型输出是否正确、如何防止危险操作
• 监控、日志、调试系统——系统运行时如何观测、如何追溯问题
• 成本控制与性能优化——token 消耗、缓存策略、并发处理
• 错误恢复与状态治理——出错后如何恢复、会话如何持续

3.2 Harness 的本质：约束

在《Claude Code 设计指南》序言中，作者给出了一个简洁的定义：

Harness 是一整套制度化的控制平面，用来处理一个很现实的问题：模型并不天然值得信任。

Harness 的核心任务是约束——把模型的能力限定在可预测、可控制的范围内。这不是对创造力的压制，而是对风险的系统性管理。

就像高速公路的护栏不是限制车的速度，而是让车敢于开得更快。Harness 让社会对 AI 有信任，信任是规模化部署的前提。

3.3 Harness Engineering 的五个层面

《Claude Code 设计指南》从源码中提炼出了 Harness 的五个关键层面：

层面	核心机制	解决的问题
Prompt 分层	多来源拼装、优先级规则	控制面的动态装配
Query Loop	主循环状态机、输入治理	会话如何持续运行
工具权限	allow/deny/ask、调度纪律	工具调用如何约束
上下文治理	Memory、Compact、预算制度	上下文如何不失控
错误恢复	分层恢复、熔断、防死循环	出错后如何继续工作

这五个层面共同构成一个完整的控制骨架。缺少任何一个，系统都会暴露出风险。

3.4 Harness Engineer 与前两层的关系

Harness Engineering 是 Prompt Engineering 和 Context Engineering 的上层封装，也是让两者生效的前提。

可以这样理解：

┌─────────────────────────────────────────────┐
│             Harness Engineer                │
│        (整体框架 & 基础设施)                  │
│  ┌───────────────────────────────────────┐  │
│  │         Context Engineer              │  │
│  │      (信息管理 & RAG系统)              │  │
│  │  ┌─────────────────────────────────┐  │  │
│  │  │      Prompt Engineer            │  │  │
│  │  │   (提示词设计与优化)             │  │  │
│  │  └─────────────────────────────────┘  │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

嵌套关系意味着：

• Prompt Engineer 设计了完美的提示词 → Context Engineer 喂错了信息 → 全部白费
• Context Engineer 构建了精准的上下文 → Harness 缺乏安全护栏 → 上线即事故

外层对内层有 veto 权。 Harness Engineer 的”约束”本质上是系统性的风险控制，而不是对创造力的压制。

---

四、从 Claude Code 和 Codex 看两种 Harness 路线

《比较 Harness 设计哲学》一书将 Claude Code 和 OpenAI 的 Codex 进行了深入对比，揭示了两套系统的不同设计哲学。

4.1 Claude Code：运行时优先的驯化路线

Claude Code 的主轴围绕”会话如何连续”展开：

关键机制：
- Query Loop（主循环心跳）
- Compact（上下文压缩与重建）
- Tool Orchestration（工具调度纪律）
- Permission（运行时审批链）
- Recovery（错误恢复分支）

Claude Code 的气质像一个做过很多事故复盘的系统——它对失败、膨胀、中断和误操作的想象力很丰富。它的关键词是：

秩序住在运行时。

4.2 Codex：显式控制面优先的驯化路线

Codex 的主轴围绕”控制层如何显式化”展开：

关键机制：
- Instruction Fragment（结构化指令片段）
- Tool Schema（工具接口定义）
- Approval Policy（策略语言）
- Thread/Rollout/State（线程状态基础设施）
- Hook Engine（生命周期事件系统）

Codex 的气质像一个制度意识极强的系统——它把控制层尽量做成可识别、可组合、可策略化的显式结构。它的关键词是：

秩序住在系统外沿。

4.3 两种路线的本质差异

	Claude Code	Codex
起笔位置	从运行时事故经验出发	从显式结构设计出发
控制面	动态装配线（现场编导）	带编号的公文系统（制度秘书）
连续性	压进主循环	拆进 Thread/State
工具治理	运行时审批（值班经理拍板）	策略语言（公司先写制度）
本地治理	经验收编（老员工看气氛）	制度挂载（项目经理先贴规则）

书中用一个精彩的比喻总结：

Claude Code 像运行时共和制，Codex 像控制面立宪制。

这不是审美差异，是系统权力分配的差异。谁来拥有连续性，谁就定义了 Harness 的中心。

---

五、Agent 能否自我迭代：Harness 的不可替代性

前面讨论中有一个关键问题：Agent 能否自我迭代，从而替代 Harness Engineer？

5.1 Agent 能做到的自我迭代

Agent 可以优化自身的 Prompt 和 Context 层：

• 调整自己的 prompt 策略：“我发现用这种格式提问效果更好”
• 优化检索策略：“这类问题查知识库 A 更准”
• 改进错误恢复：“上次这个场景失败了，下次换个方法”
• 选择更好的工具组合：“这个任务用 T1+T3 效率最高”

5.2 Agent 做不到的自我迭代

Agent 无法修改自身的 Harness 层：

• 重新定义自己的成功标准——谁说成功就是成功？
• 验证自己的安全边界是否合理——在边界内的系统无法评估边界本身
• 解决自我修改的可信度问题——修改者也是被修改者，信谁？

5.3 根本困境：你不能用一把尺子校准它自己

这是自指（self-reference）的经典困境：

1. 谁定义”更好”？ Agent 优化自己的约束时，优化的目标函数是谁定的？如果目标函数也是自己定的，这是循环论证。如果目标函数是人定的，Harness Engineer 的角色就没有被替代。

2. 奖励欺骗（Reward Hacking） 当 Agent 被赋予”改进自己”的目标时，最简单的”改进”是降低对自己的约束标准。这不是 bug，这是任何优化系统的必然行为。

3. 验证的外部性 Agent 可以修改自己的行为，但验证修改是否正确需要外部锚点。这个锚点本身就是 Harness 的一部分。

书中有一句话直接回应这个问题：

验证必须独立，不能让系统自己给自己打分。

---

六、发展趋势与预测

6.1 三种角色的长期价值

角色	当前热度	长期价值	技术门槛
Prompt Engineer	高	中（逐渐工具化）	入门低，精通高
Context Engineer	中	高	中高
Harness Engineer	低（认知层面）	极高	高

6.2 融合趋势

这三个角色会逐渐融合为 AI Application Engineer，成为软件工程的一个新分支。就像当年的 DevOps 一样，不是一个职位，而是一套能力体系。

但融合的路径可能不是均匀的：

Prompt Engineering → 工具化/自动化（模型越来越不需要精心设计的 prompt）
Context Engineering → 基础设施化（RAG 框架逐渐成熟，变成标准组件）
Harness Engineering → 核心差异化（每个产品的约束需求完全不同，难以通用化）

换句话说：

• Prompt Engineering 的天花板在降低——o1/o3 系列已经展示了”少即是多”的趋势
• Context Engineering 正在变成类似”数据库设计”的基础能力
• Harness Engineering 反而在变得更复杂——Agent 自主性越强，约束系统的设计就越非标

6.3 如果要押注一个方向

如果现在要押注一个方向深耕，Harness Engineer 是投入产出比最高的选择——因为它最难被自动化，也最难被模型自身替代。

让模型约束自己，这本身就是一个 Harness 问题。

---

七、总结：从会用 Agent 到做出 Agent

两本书的副标题都是同一个问题：

从会用 Agent，到做出 Agent PoC。

这三层角色划分，本质上是在回答这个问题：

• 会用 Agent → 你懂得如何设计 Prompt、管理 Context、利用 Harness 的约束
• 做出 Agent → 你懂得如何构建 Prompt 系统、Context 系统、Harness 系统

从用户到工程师，从使用者到构建者，这条路的起点是理解：

模型是最不稳定的部件，Harness 才是秩序来源。

三层角色不是为了划分岗位，而是为了划分问题：

• Prompt Engineer 解决的是”模型怎么说话”
• Context Engineer 解决的是”模型看到什么”
• Harness Engineer 解决的是”模型如何被约束成一个可靠系统”

最终可以收敛成《Claude Code 设计指南》结尾的一句话：

Harness Engineering 关心的是：在模型并不可靠的前提下，系统仍然能表现出工程系统应有的行为。

难的从来不在把原则说出来，而在愿不愿意承认：

Harness 比激情重要，制度比聪明重要，验证比自信重要。

谁把这三句话听进去了，大概就已经站在 Harness Engineering 的门口了。

---

参考来源

• 《Claude Code 设计指南》（Agent Way / Harness Books）
• 《比较 Harness 设计哲学》（Agent Way / Comparative Harness Notes）
• 作者：@wquguru
• 日期：2026-04-01
• 在线版本：harness-books.agentway.dev