从 Prompt 工程师到 Harness 工程师：AI 协作范式的三次进化

写在前面

刚从上海GDPS2026（全球开发者先锋大会）回来，学到了一个新词"Harness Engineer"，目前还没有贴切的中文翻译。我在现场听完嘉宾的分享，还是云里雾里，于是乎花了点时间研究了下这个概念的具体含义，力求用最简单的方式把它解释清楚。

故事要从大模型兴起之初的提示词工程开始讲起。在 Harness Engineer 之前，AI 领域已经先后出现了 Prompt Engineer（提示词工程师）和 Context Engineer（上下文工程师）。这三个概念不是独立的，而是一条清晰的进化链条------每一个新概念的诞生，都意味着人类对"如何与 AI 协作"这件事的理解又深了一层。

这篇文章，我就带你把这三个概念从头捋清楚。不堆砌术语，用人类世界里最熟悉的场景来类比，让你看完就能理解，理解完就能用。

一、先理解"进化"的本质

在深入三个概念之前，先建立一个整体框架。

这三次进化，本质上是人类对 AI 施加影响的位置在不断后移：

阶段	影响位置	核心问题
Prompt Engineer	单次对话的措辞	"我怎么说，AI 才能听懂？"
Context Engineer	AI 能看到的信息	"AI 需要知道什么，才能干好活？"
Harness Engineer	AI 运行的系统	"我要搭什么样的环境，AI 才能安全、高效地自主工作？"

一句话总结：从"怎么说"→"说什么"→"搭什么舞台"。

二、Prompt Engineer：外交官的艺术（2022---2023）

概念本质

Prompt Engineer 是第一波浪潮。ChatGPT 爆红之后，人们发现一个惊人的事实：同样的问题，用不同方式提问，得到的答案质量天差地别。

Prompt Engineering 就是这门"如何提问"的学问：用什么措辞、给什么样的示例、设定什么角色、用什么结构......

人类世界类比：宫廷外交官

想象你穿越到了一个封建王朝，想请皇帝批准一个项目。

一个没有外交训练的人可能直接冲进大殿说："陛下，我有个主意，你帮我批个条子。"

结果：被拖出去打板子。

而一个经验丰富的外交官知道：

先颂扬皇帝的英明神武（角色设定）
把自己的诉求包装成"对江山社稷的贡献"（框架转换）
用已有的成功案例佐证（Few-shot 示例）
提问方式要让皇帝感觉"这是他自己的主意"（引导式提问）

Prompt Engineer 就是这个外交官------他不改变皇帝本身，也不改变朝廷的制度，他只研究如何说话。

典型技法

erlang 复制代码

✅ 角色扮演：你是一位拥有20年经验的资深架构师...
✅ 思维链：请一步步思考这个问题...
✅ Few-shot：这里有三个例子，按照同样的格式回答...
✅ 结构化输出：请用JSON格式输出，包含name、age、score字段...

局限性

Prompt Engineering 的本质是一次性的、手工的、脆弱的。

你精心调教出来的一段 Prompt，换个模型、换个任务，就可能完全失效。而且它解决不了一个根本问题：当任务变得复杂、需要多轮推理和记忆时，光靠措辞是不够的。

三、Context Engineer：参谋长的情报艺术（2023---2024）

概念本质

随着 LLM 的上下文窗口从 4K 扩展到 128K 再到百万 token，人们意识到：模型的能力上限不再是"能不能理解"，而是"给了它什么信息"。

Context Engineering 就是精心设计和管理 AI 上下文窗口内容的工程。包括：放什么进去、不放什么、以什么顺序放、信息如何结构化......

这个概念在 2024 年被大量讨论，Andrej Karpathy（前 OpenAI 联合创始人）在 2025 年更是直接发推说：

"提示词工程（Prompt Engineering）这个词已经有些过时了，更准确的说法应该是上下文工程（Context Engineering）------为 LLM 精心设计和管理整个上下文窗口的艺术。"

人类世界类比：出征前的参谋长简报

战争爆发了，将军（AI）需要做出作战决策。

一个差劲的参谋长只是说："将军，敌人来了，你看着办。" → 将军啥都不知道，只能随机应变，大概率失败。

**一个顶级的参谋长（Context Engineer）**在战前会准备：

敌情报告（相关背景知识）
己方力量分析（当前可用资源）
地形图（任务的结构和约束）
历史战例（相关的 Few-shot 示例）
指挥官意图（当前任务目标）
通讯频道（格式规范和输出要求）

把这些信息精心整理 、装进将军出发前的作战简报包（上下文窗口），将军就能做出高质量的决策。

Context Engineering 的核心不是"说什么话"，而是"给 AI 看什么文件"。

典型实践

javascript 复制代码

✅ RAG（检索增强生成）：不把所有知识塞进 prompt，而是动态检索最相关的片段
✅ 记忆管理：决定哪些历史对话值得保留，哪些可以压缩或丢弃
✅ 信息分层：重要信息放在上下文的开头和结尾（LLM 对首尾更敏感）
✅ 结构化注入：用 XML 标签、JSON 结构让 AI 更容易定位信息
✅ 系统 Prompt 设计：CLAUDE.md、system prompt 就是典型的 Context Engineering

一个真实案例

你有没有用过 Claude Code？

当你在项目里放一个 CLAUDE.md 文件，写上"这个项目的技术栈是 Next.js 14，禁止修改 package.json，代码风格遵循 XX 规范"------这就是 Context Engineering。

你不是在教 Claude "怎么说话"，而是在精心设计它每次工作前能看到的信息。这个文件会被自动注入到每次对话的上下文中，成为 AI 行为的"隐形宪法"。

局限性

Context Engineering 解决了"给 AI 看什么"的问题，但还有一个更深层的挑战没有解决：

当 AI 不再只是"回答问题"，而是要"自主执行任务"时怎么办？

AI Agent 需要调用工具、执行代码、访问文件、发送请求......这些行为涉及真实世界的资源和风险。光靠精心准备的上下文，已经不够了。

四、Harness Engineer：驯马师与安全工程师的结合（2025---）

概念本质

终于到了今天的主角。

Harness Engineer 是为 AI Agent 设计和构建运行环境、约束系统、工具生态和执行基础设施的工程师。

"Harness"这个词来得绝妙，因为它在英语里有三层含义，每层都精准对应了这个职业的一个维度：

三重含义的完美类比

第一重：马具（Horse Harness）------驾驭原始力量

一匹烈马拥有巨大的力量，但如果没有马具（缰绳、颈轭、鞍具），这股力量要么无法使用，要么会把车夫摔死。

马具工程师 设计的马具，让这头野兽的力量能够被精确地引导到有用的方向------拉犁、驾车、骑乘。

AI 模型就是那匹烈马。它拥有惊人的能力，但如果没有精心设计的"驾具"，这能力就是失控的。Harness Engineer 设计的系统，就是让 AI 的能力被可控地、有方向地释放出来。

第二重：安全绳（Safety Harness）------让人在危险环境中安全工作

高空作业工人腰上系的那根绳子，就叫 Safety Harness（安全驾具）。

没有它，工人无法在危险的高空工作。有了它，工人可以大胆探出身子、完成精密操作，因为即使失手，也不会坠落。

AI Agent 在真实世界中执行任务，就像工人在高空工作------一不小心可能删掉生产数据库、发出无法撤回的邮件、触发错误的 API 调用。

Harness Engineer 设计的权限系统、沙箱、回滚机制、审批流程 ，就是这根安全绳------让 AI 能够大胆工作，同时确保即使出错，后果也在可控范围内。

第三重：测试驾具（Test Harness）------提供受控的运行环境

软件工程里有个经典概念叫 Test Harness：为被测组件提供一个受控的、可重复的、可观测的运行环境。

AI Agent 也需要类似的东西：一个定义清晰的工具集、一套可预期的执行环境、完整的日志和监控。Harness Engineer 构建的这套基础设施，让 AI Agent 的行为变得可测试、可调试、可观测。

人类世界类比：NASA 飞行控制中心

想象 NASA 把一名宇航员（AI Agent）送上太空执行任务。

光靠"提前训练宇航员说话方式"（Prompt Engineering）显然不够。光靠"给宇航员看完整的任务简报"（Context Engineering）也不够。

真正让这次任务成功的，是地球上那套庞大的支撑系统：

任务控制中心：实时监控所有参数，随时介入（Orchestration）
工具清单：精心设计的宇航服、工具包，每件工具都有明确用途（Tool Design）
通信协议：规范的指令格式，确保双向沟通清晰（API Design）
紧急预案：每种故障场景都有预设的应急流程（Error Handling）
权限分级：宇航员可以自主执行某些操作，但某些关键操作需要地面确认（Permission System）
飞行日志：所有操作全程记录，事后可追溯（Observability）

Harness Engineer 就是设计和维护这套"任务控制中心"的人。

五、Harness Engineering 的实践落地

说了这么多概念，来看看 Harness Engineer 在实际工作中到底做什么。

1. Hooks 系统：给 AI 的"反射弧"

Claude Code 里有一个叫 Hooks 的功能，完美诠释了 Harness Engineering：

json 复制代码

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo '🔍 即将执行命令，进行安全检查...' && security-check.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "git add -A && git status"
          }
        ]
      }
    ]
  }
}

这段配置的含义是：

每次 AI 想执行 Bash 命令之前，自动运行安全检查脚本
每次 AI 写完文件之后，自动暂存 git 变更

注意：这些逻辑不在 AI 的对话里，不在 Prompt 里，也不在上下文里------它在 Harness（驾具）里。AI 自己甚至不知道这些检查在发生，但它的每次行为都被这套系统静默地管控着。

这就是 Harness Engineering 最核心的思想：把控制逻辑从 AI 的"意识"里拿出来，放到外部系统里。

2. 权限系统：精细化的信任边界

一个设计良好的 AI Harness，不是简单地"允许/禁止"，而是精细化的权限矩阵：

bash 复制代码

✅ 可以自由执行：读取文件、运行测试、查询只读 API
⚠️  需要审批：修改生产配置、发送外部请求、删除文件
❌  永久禁止：修改 .env 文件、直接操作数据库、推送代码到 main 分支

这套权限系统不靠"告诉 AI 不要做某件事"（Prompt Engineering），而是在系统层面物理上限制了某些操作的可能性。

这就是安全绳的价值------不是靠宇航员的自律，而是靠工程设计确保安全。

3. 工具设计：给 AI 合适的"双手"

Harness Engineer 的一大核心工作是工具设计（Tool Design）。

一个糟糕的工具设计：

python 复制代码

# 给 AI 一个"万能工具"
def execute_anything(command: str) -> str:
    return subprocess.run(command, shell=True, capture_output=True).stdout

一个好的工具设计：

python 复制代码

# 职责单一、边界清晰的工具集
def read_file(path: str) -> str: ...          # 只读，有路径白名单
def write_file(path: str, content: str): ...  # 有路径校验、大小限制
def run_tests(test_path: str) -> TestResult: ... # 沙箱执行，超时保护
def search_web(query: str) -> List[Result]: ...  # 有域名白名单

工具的颗粒度、边界清晰度、错误处理完善度，直接决定了 AI Agent 系统的可靠性。设计工具不是编程题，是架构题。

4. 多智能体编排：设计"组织架构"

当任务复杂到单个 AI 难以胜任，Harness Engineer 需要设计多智能体流水线：

css 复制代码

用户请求
    ↓
[策略 Agent]   ← 负责任务分解和规划
    ↓
┌───────────────────────┐
│  [研究 Agent]  [代码 Agent]  [测试 Agent]  │  ← 并行执行
└───────────────────────┘
    ↓
[综合 Agent]   ← 负责整合结果和质量把关
    ↓
最终输出

这套架构中，每个 Agent 的职责边界、通信协议、共享状态管理、失败回滚策略------都是 Harness Engineer 的设计工作。

这就像设计一个公司的组织架构，而每个"员工"都是 AI。

5. 可观测性：给系统装上"神经系统"

真实世界中的 AI Agent 系统，必须有完整的可观测性：

python 复制代码

# 每次工具调用都记录：是谁调用的、什么时间、参数是什么、结果是什么、花了多久
@trace_tool_call
def execute_task(task_id: str, params: dict) -> Result:
    ...

# 关键决策节点打点
span = tracer.start_span("agent_decision")
span.set_attribute("decision_type", "file_modification")
span.set_attribute("confidence", agent_confidence)

没有可观测性的 AI 系统，就像没有仪表盘的飞机------出了事不知道哪里出了问题，也无法优化。

六、三者的关系：不是替代，是嵌套

这里有一个非常重要的认知：Prompt Engineer、Context Engineer、Harness Engineer 不是谁取代谁的关系，而是嵌套包含的关系。

复制代码

╔════════════════════════════════════════╗
║         Harness Engineering            ║
║  ┌─────────────────────────────────┐   ║
║  │      Context Engineering        │   ║
║  │  ┌────────────────────────────┐ │   ║
║  │  │    Prompt Engineering      │ │   ║
║  │  └────────────────────────────┘ │   ║
║  └─────────────────────────────────┘   ║
╚════════════════════════════════════════╝

一个优秀的 Harness Engineer，必然也是出色的 Context Engineer（因为要设计 system prompt 和信息注入管道），同时也懂 Prompt Engineering（因为要设计工具描述、任务指令）。

三者的关系，就像：

Prompt Engineer = 知道怎么跟皇帝说话的外交官
Context Engineer = 给外交官准备完整情报包的参谋长
Harness Engineer = 设计整个外交使团的运作体系、规程、权限和备用方案的国务卿

七、为什么 Harness Engineer 现在突然火了？

时机的出现有其必然性。

导火索：AI Agent 的爆发

2025 年，AI Agent 从"有趣的演示"变成了"真实生产力工具"。Claude Code、Cursor、Devin、GitHub Copilot Workspace......AI 开始在真实代码库里执行真实的、有后果的操作。

这一步跨越意味着：错误的代价从"AI 说了句废话"变成了"AI 删掉了生产数据库"。

当 AI 的行为开始影响真实世界，就必须有人来设计那套保证安全、效率、可控的基础设施------这个人就是 Harness Engineer。

模型能力的瓶颈转移

早期，模型的能力是瓶颈，所以大家研究 Prompt Engineering（怎么激发模型潜力）。

后来，模型能力越来越强，信息管理成了瓶颈，所以出现了 Context Engineering（怎么给模型喂对信息）。

现在，模型足够聪明、信息也能管理好，系统架构成了瓶颈------怎么让多个 Agent 协同工作、怎么保证 Agent 行为的可靠性、怎么处理 Agent 失败时的回滚......这就是 Harness Engineering 要解决的。

能力边界在哪里，工程的重心就在哪里。

八、普通开发者如何入门 Harness Engineering？

最后，给想入手的人一些实践建议。

从 Claude Code 的 Hooks 开始

最低成本的 Harness Engineering 入门路径：

bash 复制代码

# 在项目里创建 .claude/settings.json
mkdir -p .claude
touch .claude/settings.json

然后从简单的 Hook 开始：

每次写文件后自动格式化
每次执行命令前打印日志
每次对话结束后自动保存摘要

学习工具调用设计（Function Calling）

深入研究 OpenAI/Anthropic 的 Function Calling 规范，思考：

工具的命名和描述如何影响 AI 的调用决策？
工具的参数设计如何减少 AI 的误用？
工具的错误处理如何让 AI 能够优雅地失败？

研究真实的 Agent 框架

LangGraph：专注于有状态的多步 Agent 工作流
CrewAI：多 Agent 角色协作框架
Claude Code SDK：Anthropic 官方的 Agent 构建工具

不需要全部精通，选一个深入研究它的设计哲学。

把安全意识从一开始就建立起来

Harness Engineering 最重要的素质不是技术，而是对风险的直觉：

"这个操作如果出错，最坏的结果是什么？" "我该在哪个层面加保护？" "这件事 AI 应该自主决定，还是必须人工确认？"

写在最后

Prompt Engineer → Context Engineer → Harness Engineer，这条进化链条本质上讲述了一个故事：

我们和 AI 的关系，正在从"对话者"演变为"系统设计者"。

Prompt Engineer 把 AI 当工具，研究怎么用好这个工具。Context Engineer 把 AI 当专业人员，研究怎么给他完整的信息和授权。而 Harness Engineer 把 AI 当组织成员，研究怎么搭建一个让 AI 能安全、高效、自主工作的组织系统。

这不只是技术的演进，更是思维框架的跃升。

当你开始思考"我要搭什么系统让 AI 来工作"，而不再是"我要怎么跟 AI 说话"------你就已经踏上了 Harness Engineering 的道路。

本文是对 Prompt Engineering、Context Engineering、Harness Engineering 三个概念的系统梳理，结合了 Claude Code 的实际使用经验。如果你有不同的理解或实践经验，欢迎在评论区交流。