点点工程机械
116.25M · 2026-04-01
刚从上海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 是第一波浪潮。ChatGPT 爆红之后，人们发现一个惊人的事实：同样的问题，用不同方式提问，得到的答案质量天差地别。
Prompt Engineering 就是这门"如何提问"的学问：用什么措辞、给什么样的示例、设定什么角色、用什么结构……
想象你穿越到了一个封建王朝，想请皇帝批准一个项目。
一个没有外交训练的人可能直接冲进大殿说："陛下，我有个主意，你帮我批个条子。"
结果：被拖出去打板子。
而一个经验丰富的外交官知道：
Prompt Engineer 就是这个外交官——他不改变皇帝本身，也不改变朝廷的制度，他只研究如何说话。
角色扮演：你是一位拥有20年经验的资深架构师...
思维链：请一步步思考这个问题...
Few-shot：这里有三个例子，按照同样的格式回答...
结构化输出：请用JSON格式输出，包含name、age、score字段...
Prompt Engineering 的本质是一次性的、手工的、脆弱的。
你精心调教出来的一段 Prompt，换个模型、换个任务，就可能完全失效。而且它解决不了一个根本问题：当任务变得复杂、需要多轮推理和记忆时，光靠措辞是不够的。
随着 LLM 的上下文窗口从 4K 扩展到 128K 再到百万 token，人们意识到：模型的能力上限不再是"能不能理解"，而是"给了它什么信息"。
Context Engineering 就是精心设计和管理 AI 上下文窗口内容的工程。包括：放什么进去、不放什么、以什么顺序放、信息如何结构化……
这个概念在 2024 年被大量讨论，Andrej Karpathy（前 OpenAI 联合创始人）在 2025 年更是直接发推说：
战争爆发了，将军（AI）需要做出作战决策。
一个差劲的参谋长只是说："将军，敌人来了，你看着办。" → 将军啥都不知道，只能随机应变，大概率失败。
**一个顶级的参谋长（Context Engineer）**在战前会准备：
把这些信息精心整理、装进将军出发前的作战简报包（上下文窗口），将军就能做出高质量的决策。
Context Engineering 的核心不是"说什么话"，而是"给 AI 看什么文件"。
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 是为 AI Agent 设计和构建运行环境、约束系统、工具生态和执行基础设施的工程师。
"Harness"这个词来得绝妙，因为它在英语里有三层含义，每层都精准对应了这个职业的一个维度：
一匹烈马拥有巨大的力量，但如果没有马具（缰绳、颈轭、鞍具），这股力量要么无法使用，要么会把车夫摔死。
马具工程师设计的马具，让这头野兽的力量能够被精确地引导到有用的方向——拉犁、驾车、骑乘。
AI 模型就是那匹烈马。它拥有惊人的能力，但如果没有精心设计的"驾具"，这能力就是失控的。Harness Engineer 设计的系统，就是让 AI 的能力被可控地、有方向地释放出来。
高空作业工人腰上系的那根绳子，就叫 Safety Harness（安全驾具）。
没有它，工人无法在危险的高空工作。有了它，工人可以大胆探出身子、完成精密操作，因为即使失手，也不会坠落。
AI Agent 在真实世界中执行任务，就像工人在高空工作——一不小心可能删掉生产数据库、发出无法撤回的邮件、触发错误的 API 调用。
Harness Engineer 设计的权限系统、沙箱、回滚机制、审批流程，就是这根安全绳——让 AI 能够大胆工作，同时确保即使出错，后果也在可控范围内。
软件工程里有个经典概念叫 Test Harness：为被测组件提供一个受控的、可重复的、可观测的运行环境。
AI Agent 也需要类似的东西：一个定义清晰的工具集、一套可预期的执行环境、完整的日志和坚控。Harness Engineer 构建的这套基础设施，让 AI Agent 的行为变得可测试、可调试、可观测。
想象 NASA 把一名宇航员（AI Agent）送上太空执行任务。
光靠"提前训练宇航员说话方式"（Prompt Engineering）显然不够。 光靠"给宇航员看完整的任务简报"（Context Engineering）也不够。
真正让这次任务成功的，是地球上那套庞大的支撑系统：
Harness Engineer 就是设计和维护这套"任务控制中心"的人。
说了这么多概念，来看看 Harness Engineer 在实际工作中到底做什么。
Claude Code 里有一个叫 Hooks 的功能，完美诠释了 Harness Engineering：
// .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 的对话里，不在 Prompt 里，也不在上下文里——它在 Harness（驾具）里。AI 自己甚至不知道这些检查在发生，但它的每次行为都被这套系统静默地管控着。
这就是 Harness Engineering 最核心的思想：把控制逻辑从 AI 的"意识"里拿出来，放到外部系统里。
一个设计良好的 AI Harness，不是简单地"允许/禁止"，而是精细化的权限矩阵：
可以自由执行：读取文件、运行测试、查询只读 API
️ 需要审批：修改生产配置、发送外部请求、删除文件
永久禁止：修改 .env 文件、直接操作数据库、推送代码到 main 分支
这套权限系统不靠"告诉 AI 不要做某件事"（Prompt Engineering），而是在系统层面物理上限制了某些操作的可能性。
这就是安全绳的价值——不是靠宇航员的自律，而是靠工程设计确保安全。
Harness Engineer 的一大核心工作是工具设计（Tool Design）。
一个糟糕的工具设计：
# 给 AI 一个"万能工具"
def execute_anything(command: str) -> str:
return subprocess.run(command, shell=True, capture_output=True).stdout
一个好的工具设计：
# 职责单一、边界清晰的工具集
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 系统的可靠性。设计工具不是编程题，是架构题。
当任务复杂到单个 AI 难以胜任，Harness Engineer 需要设计多智能体流水线：
用户请求
↓
[策略 Agent] ← 负责任务分解和规划
↓
┌───────────────────────┐
│ [研究 Agent] [代码 Agent] [测试 Agent] │ ← 并行执行
└───────────────────────┘
↓
[综合 Agent] ← 负责整合结果和质量把关
↓
最终输出
这套架构中，每个 Agent 的职责边界、通信协议、共享状态管理、失败回滚策略——都是 Harness Engineer 的设计工作。
这就像设计一个公司的组织架构，而每个"员工"都是 AI。
真实世界中的 AI Agent 系统，必须有完整的可观测性：
# 每次工具调用都记录：是谁调用的、什么时间、参数是什么、结果是什么、花了多久
@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（因为要设计工具描述、任务指令）。
三者的关系，就像：
时机的出现有其必然性。
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/settings.json
mkdir -p .claude
touch .claude/settings.json
然后从简单的 Hook 开始：
深入研究 OpenAI/Anthropic 的 Function Calling 规范，思考：
不需要全部精通，选一个深入研究它的设计哲学。
Harness Engineering 最重要的素质不是技术，而是对风险的直觉：
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 的实际使用经验。如果你有不同的理解或实践经验，欢迎在评论区交流。
