从 Prompt Engineering 到 Harness Engineering

一、为什么最近大家都在聊 Harness Engineering

如果你最近在看 AI Agent 相关视频、文章或技术分享，你大概率会发现一个现象：

前几年大家在讨论 Prompt Engineering，后来开始讨论 RAG、Context Engineering，而最近越来越多人开始讨论 Harness Engineering。

这背后并不是因为大家喜欢不断发明新名词，而是因为 AI 系统的重心确实在变化。

在早期，大部分 AI 应用更像一个“会回答问题的聊天机器人”。这个阶段最重要的是：

• 你怎么写 Prompt
• 你怎么把知识喂给模型
• 你怎么让模型输出更稳定

但随着模型能力增强，AI 应用开始从“回答”走向“行动”：

• 它不只是回复你一句话
• 它会调用工具
• 它会读写文件
• 它会访问浏览器
• 它会执行多步任务
• 它会根据中间结果调整下一步

当系统进入这个阶段，真正困难的问题就不再只是“怎么问模型”，而变成：

• 这个 AI 该在什么条件下调用什么工具
• 它如果走偏了，怎么拉回来
• 它如果中断了，怎么恢复
• 它做错了，怎么评估和回归测试
• 它执行高风险操作时，什么时候该让人介入

OpenAI 在 2026 年 2 月 11 日发布的文章 Harness engineering: leveraging Codex in an agent-first world 中，把重点明确放在“为 agent 搭建外部工作环境和控制系统”上。Anthropic 在 2026 年 1 月 9 日的文章 Demystifying evals for AI agents 中，也明确区分了 agent harness 和 evaluation harness。这说明行业关注点已经明显从“单次调用模型”转向“如何把 agent 放进一个可靠系统里”。

这就是 Harness Engineering 开始变热的背景。

二、从零开始：先把几个最容易混淆的概念分清楚

很多初学者一开始学 AI Agent，会把 Model、Agent、Workflow、Runtime、Harness 混在一起。其实这些概念对应的是不同层次的问题。

1. Model 是什么

Model，也就是大语言模型，比如 GPT、Claude、Gemini 这一类，本质上负责的是：

• 理解输入
• 生成输出
• 进行语言层面的推理
• 在一定程度上做规划和判断

你可以把它理解成系统里的“大脑”，但它只是大脑，不等于完整的系统。

模型本身通常不会天然拥有这些能力：

• 长时间稳定执行一个任务
• 自动恢复中断
• 安全地访问外部工具
• 按业务规则完成审批流程
• 对错误进行结构化回滚

所以模型很重要，但模型不等于 AI Agent，更不等于完整的企业级 AI 系统。

2. Tool 是什么

Tool 指的是模型之外、可以被调用的能力。比如：

• 搜索
• 数据库查询
• 浏览器操作
• 文件读写
• 调用内部 API
• 执行代码

工具的意义在于把模型从“只会说”变成“能做事”。

Anthropic 在 2025 年的研究文章 Trustworthy agents in practice 里，把 model、harness、tools、environment 作为 agent 系统的核心组件来讨论。这种分层很有帮助：模型不是孤立存在的，它通常要和工具、环境、外层控制系统一起工作。

3. Workflow 是什么

Workflow 可以理解成“预先设计好的固定流程”。

例如一个很简单的工作流：

1. 用户提交需求
2. 系统搜索知识库
3. 模型总结结果
4. 结果发给用户

这个流程里，步骤和顺序大体是固定的。它可能很有用，但它不一定是一个“agent”。

4. Agent 是什么

Agent 的关键，不在于它会不会说自然语言，而在于它是否会为了一个目标，自主决定下一步要做什么。

例如一个 coding agent：

• 先读需求
• 再搜代码
• 找到相关文件后尝试修改
• 修改完跑测试
• 测试失败后回头再改
• 必要时再补日志、再查错误

这里的关键不是“多步”，而是“它会根据执行结果动态调整路径”。

所以可以这样简单区分：

• Workflow 更像固定流程
• Agent 更像带有自主决策能力的执行者

5. Runtime / Orchestration 是什么

当 agent 开始变复杂后，你会发现必须有一个东西负责：

• 保存状态
• 管理节点之间的流转
• 控制循环与分支
• 处理中断与恢复
• 做权限与人工审批

这个层通常可以叫：

• runtime
• orchestration
• workflow engine
• agent runtime

这就是 LangGraph 这类框架所在的位置。

6. Harness 是什么

Harness 这个词，如果直译，可以理解成“套具”“控制装置”“外层约束系统”。放到 AI Agent 里，它不是模型本身，而是把模型安全、稳定、可控地放进真实工作环境里的那套外层系统。

它通常包含：

• 工具接入
• 上下文装配
• 状态管理
• 权限控制
• 人工审批
• 重试机制
• 超时机制
• 日志与追踪
• 评测与回归测试
• 失败恢复

所以，harness 不是一个单独的小功能，而更像“agent 在现实世界里工作的外层骨架与控制系统”。

三、什么是 Harness Engineering

从现有公开资料看，Harness Engineering 更像一个正在快速成形的行业实践术语，而不是一个已经被学术界完全标准化的正式学科名词。

如果用最容易懂的话来解释，它指的是：

不只是让模型回答得更好，而是设计整套外部系统，让 agent 能可靠、可控、可恢复、可评估地工作。

你可以把几个相近概念这样区分：

这个区分不是某一家官方文档里的唯一标准表述，而是我基于 OpenAI、Anthropic、LangGraph 等资料做的归纳。这个归纳对初学者很有帮助，因为它能帮你理解：为什么你写了一个“很聪明的 prompt”，系统还是容易出问题。

原因通常不是模型太笨，而是外层系统没有搭好。

Harness Engineering 主要关心什么

如果你从工程视角看，Harness Engineering 主要关心的是这些问题：

• 任务如何被拆成可执行步骤
• 每一步需要哪些上下文
• 什么情况下允许调用哪些工具
• 某一步失败后如何重试
• 某一步超时后如何终止
• 遇到危险操作时如何人工审批
• 整个过程如何记录、回放、审计
• 上线后如何持续评估和回归

Anthropic 在 Demystifying evals for AI agents 一文中区分了：

• agent harness：让 agent 执行任务的那套运行系统
• evaluation harness：评估 agent 表现的那套系统

这个区分非常重要，因为很多团队第一次做 AI Agent 时，会把“能跑起来”和“能稳定评估”混为一谈。实际上，二者都是必要的，而且都属于更大的 Harness Engineering 范畴。

四、LangGraph 到底是什么

1. 官方定位

LangChain 官方文档把 LangGraph 定位为：

• 一个 low-level orchestration framework
• 一个 runtime
• 面向 long-running, stateful agents

这几个词很关键。

它不是“又一个聊天 API 包装器”，也不是只会串几个工具的轻量脚手架。它真正解决的是：

• agent 不是单轮对话，而是长时间运行
• agent 不是无状态调用，而是要带状态前进
• agent 不是线性脚本，而是会分支、循环、暂停、恢复

2. 为什么叫 Graph

LangGraph 的核心思路是：把 agent 执行过程建模成一个图。

一个图通常包含三样东西：

• State：当前任务已积累的状态
• Node：一个具体步骤
• Edge：下一步流向哪里

举个简单例子，一个 coding agent 的图可能是：

1. 读取需求
2. 搜索代码库
3. 修改代码
4. 运行测试
5. 如果失败，回到修改代码
6. 如果成功，进入完成状态

这就是一个很典型的图结构：它不是单向流水线，而是允许循环与条件分支。

3. LangGraph 为什么火

因为它正好踩在今天 AI Agent 最难、也最核心的点上：

• 需要状态
• 需要可恢复
• 需要可观察
• 需要人工介入
• 需要复杂控制流

LangGraph 官方概览里强调的能力包括：

• durable execution
• human-in-the-loop
• comprehensive memory
• streaming
• debugging with LangSmith

这说明它的目标不是“让你更快写一个 demo”，而是“让你把 agent 当成一个真正运行的系统去设计”。

4. LangGraph 和 LangChain 是什么关系

很多人第一次接触会混淆这两者。

你可以这样理解：

• LangChain 更像上层组件和应用开发生态
• LangGraph 更像底层 agent runtime 和控制流引擎

官方也明确提到，LangChain 的 agents 构建在 LangGraph 之上。也就是说，如果你只是要快速用现成 agent abstraction，可能会先接触 LangChain；但如果你要细致地控制 agent 的执行过程，LangGraph 更关键。

五、Durable Execution 是什么，它到底能解决什么

1. 最简单的理解：断点续跑

LangGraph 文档里的 Durable execution 可以先用一句话理解：

任务在中断后，可以从已经保存的进度继续执行，而不是从头重来。

这类中断包括：

• 进程崩溃
• 容器重启
• 网络闪断
• 模型提供商临时故障
• 人工主动暂停

对于长任务来说，这个能力非常重要。

因为如果一个 agent 要连续执行 15 分钟、30 分钟，甚至更久，那么“执行过程中一定会不会出故障”几乎不是一个现实假设。更现实的假设是：故障一定会发生，只是发生在哪一步的问题。

2. 它为什么重要

假设你让一个 coding agent 完成下面的任务：

1. 读 PRD
2. 找相关代码
3. 修改 4 个文件
4. 跑单测
5. 修复失败用例
6. 再跑集成测试
7. 生成变更摘要

如果执行到第 5 步时连接中断，而系统没有 durable execution，那么下次往往只能从头开始。这样会带来几个问题：

• 浪费 token 和时间
• 可能重复执行副作用操作
• 容易让上下文和结果不一致

有了 durable execution，系统就能尽量从上一个可恢复的节点继续执行。

3. 但它不能单独解决“agent 卡死”

这是初学者最容易误解的地方。

durable execution 解决的是“恢复”，不是“智能纠错”。

它比较擅长解决：

• 断了以后怎么继续
• 崩了以后怎么恢复
• 长任务如何暂停后再接着跑

它不能单独解决：

• agent 陷入无限循环
• agent 策略错误，反复走错路
• 工具调用无超时地卡住
• 业务逻辑层面的死锁

所以如果你的痛点是“agent 经常转圈、卡死、出不来”，单有 durable execution 不够。你还需要：

• timeout
• max steps
• retry policy
• watchdog
• interrupt
• human approval
• observability

换句话说：

• durable execution = 断了以后能续上
• anti-stuck design = 不让它一直傻转圈

这两个问题相关，但不是一回事。

4. 为什么官方会强调 deterministic 和 idempotent

LangGraph 官方文档提到，要想更可靠地恢复执行，任务里的某些部分最好满足：

• deterministic：在相同输入下，行为尽量可预测
• idempotent：重复执行不会造成不可控副作用

这个要求非常工程化。

例如，如果某个节点的副作用是“向数据库重复写入一条订单”，那它就不太适合被无脑重放。你通常需要：

• 用唯一任务 ID 去重
• 把副作用放在更容易控制的节点
• 在恢复时区分“已完成副作用”和“未完成副作用”

这也是为什么 LangGraph 看起来像一个 AI 框架，但学进去会越来越像在学分布式系统和工作流引擎。

六、为什么 LangGraph 明明很强，却经常被说“上手难”

很多人在学习视频或文档时会说：

“LangGraph 看起来很强，但学起来不轻松。”

这个判断是对的，但原因不是它做得差，而是它把真实复杂度直接摆在你面前了。

1. 它让你显式处理状态

在简单 demo 里，很多状态都被你藏在 prompt 里，或者直接放在代码局部变量里。

但一旦任务要：

• 跨多步执行
• 中断后恢复
• 支持人工介入
• 支持回放与调试

你就必须明确回答：

• 当前状态有哪些字段
• 哪些字段是可持久化的
• 哪些字段是临时值
• 哪些字段会影响后续决策

这本来就是复杂问题，只是 LangGraph 不帮你假装它不存在。

2. 它让你显式处理控制流

简单系统里，你可以写一个 for 循环、一个 if 判断就结束了。

但真正的 agent 通常会遇到：

• 是否继续尝试
• 是否换策略
• 是否回到上一步
• 是否请求人工审批
• 是否因为风险过高而终止

LangGraph 的图模型，逼你把这些流转逻辑说清楚。

3. 它让你正面处理失败恢复

对于很多初学者来说，最自然的想法是：

“先让 agent 跑起来，出了问题再说。”

但 LangGraph 这种框架其实在提醒你：如果你现在不设计失败恢复，以后线上出问题时你会付出更大代价。

4. 它的思路更接近系统工程，而不只是 Prompt 技巧

LangGraph 官方文档还提到，它的灵感来自 Pregel、Apache Beam、NetworkX 等系统。这说明它更接近一种“图式计算与工作流调度”思路，而不只是给大模型包一层链式调用。

这就是为什么很多人会有一种感觉：

“我本来只是想学 agent，结果发现自己像在学工作流引擎和分布式控制逻辑。”

这个感觉没有错。

七、如果不只看 LangGraph，当前有哪些常见的开源落地产品

下面这部分不是在说“谁最好”，而是在说“它们分别解决哪一层问题”。

这个分层是我基于各自官方文档定位做的工程归纳，目的不是给框架贴绝对标签，而是帮助你建立地图。

1. 编排 / Runtime 层

这类产品更偏“agent 的执行底座”。

LangGraph

• 代表能力：复杂控制流、状态图、durable execution、人类介入
• 适合：复杂、多步骤、长时间运行的 agent
• 官方资料：LangGraph Overview

PydanticAI

• 代表能力：Python 生态友好、类型化、工具调用、图与 durable execution、人工审批
• 适合：Python 团队做工程化 agent 后端
• 官方资料：PydanticAI

CrewAI

• 代表能力：多 agent 协作、Crews 和 Flows
• 适合：想快速组织多角色 agent 协作的场景
• 官方资料：CrewAI Documentation

2. Coding Agent / 执行型 Agent 层

这类产品更偏“让 agent 真正在开发任务上执行”。

OpenHands

• 代表能力：代码任务执行、CLI / GUI / SDK、多步软件开发任务
• 适合：coding agent、自动修复、代码理解与修改
• 官方资料：OpenHands Introduction

3. 浏览器执行层

如果你的 agent 需要操作网页、表单、后台系统，这一层会很重要。

Browser Use

• 代表能力：把浏览器自动化封装成 agent 可用能力
• 适合：网页操作、采集、表单、后台工作流自动化
• 官方资料：Browser Use Docs

4. 观测 / 追踪 / Prompt 管理层

这类产品不是直接帮你“做决定”，而是让你看清 agent 到底做了什么。

Langfuse

• 代表能力：trace、observability、prompt 管理、datasets、evals
• 适合：给生产中的 agent 增加可观测性与评估能力
• 官方资料：Langfuse Docs

5. Evals / 回归 / 安全测试层

这类工具对于生产系统非常重要，因为“能跑起来”和“能长期稳定地跑”是两回事。

Promptfoo

• 代表能力：prompt、RAG、agent 的 eval 与 red teaming
• 适合：做回归测试、比较模型和提示词版本
• 官方资料：Promptfoo GitHub

Inspect AI

• 代表能力：面向 LLM 与 agent 的开源评测框架
• 适合：更系统化的评测、实验与基准
• 官方资料：Inspect AI

6. 低代码 / 快速验证层

如果你的目标是快速做一个业务验证版本，而不是一开始就深度自研 runtime，这一层更友好。

Dify

• 代表能力：可视化工作流、知识库应用、应用级封装
• 适合：快速构建企业内部 AI 应用
• 官方资料：Dify Introduction

Flowise

• 代表能力：可视化搭建 LLM 应用与 agent 流程
• 适合：PoC、教学、低门槛原型
• 官方资料：Flowise Docs

八、企业里到底该怎么选，而不是盲目追“最强”

这是最关键的一部分。

很多团队做技术选型时，最容易犯的错误，不是选了一个差框架，而是错误地理解了“最强”。

企业里真正应该问的问题，不是：

哪个框架最火、最强、最先进？

而是：

在我们的业务目标、团队技术栈、上线节奏、维护成本、安全要求下，哪个方案最合适？

1. 先看业务形态

不同业务，适合的框架完全不同。

• 如果你做的是简单问答助手，重型 agent runtime 可能过度设计
• 如果你做的是长流程审批 agent、自动化执行 agent，轻量框架可能撑不住
• 如果你做的是 coding agent，通用聊天框架不一定合适
• 如果你做的是浏览器代理，重点在网页执行与恢复，而不只是提示词

2. 再看团队技术栈

技术栈会直接影响落地效率。

• Python 团队通常更容易接受 LangGraph、PydanticAI
• 需要可视化搭建和业务侧自助时，Dify、Flowise 更容易推动
• 偏开发自动化、代码理解任务时，OpenHands 这类工具更直接

3. 再看工程成熟度

你要判断团队现在处于哪一个阶段：

• 只是做 PoC
• 在做内部试点
• 准备上生产
• 已经要做多团队共享平台

PoC 阶段，速度往往比完美架构更重要。
生产阶段，可观测性、权限、回归评测、失败恢复往往比“快速搭出来”更重要。

4. 再看风险与治理要求

如果系统会做这些事：

• 改代码
• 调数据库
• 下单
• 发邮件
• 访问内部系统

那么 harness 的重要性会急剧上升。因为这时你需要的不只是“效果不错”，而是：

• 可追溯
• 可中断
• 可回滚
• 可审批
• 可审计

这时 LangGraph 这类强调 runtime、控制流、恢复能力的框架，价值就会更明显。

5. 一个非常实用的结论

对企业而言，最优框架通常不是能力上限最高的那个，而是：

需求复杂度 × 团队能力 × 上线速度 × 维护成本 × 治理要求
这一组约束下的最优解

所以：

• 最强 不一定 最适合
• 最容易上手 也不一定 最适合
• 真正好的选型，一定是贴着业务和团队现实做出来的

九、如果你是小白，建议怎么学，才不会被概念淹没

初学者最容易掉进两个坑：

• 还没搞清楚 agent 是什么，就一上来学多 agent 和复杂编排
• 还没搞清楚工具和状态，就一上来追最新、最复杂的框架

更稳妥的学习路径通常是：

第一步：先理解最小系统

先搞明白下面这几个最小概念：

• Model
• Tool
• Workflow
• Agent
• State
• Runtime
• Harness

如果这几个词分不清，后面看任何教程都容易晕。

第二步：先做固定流程，再学自治

先做一个简单工作流：

1. 用户提问
2. 查知识库
3. 总结答案

再做一个简单 agent：

1. 读任务
2. 决定是搜索还是调用工具
3. 根据结果决定下一步

这样你就会真正感受到 workflow 和 agent 的区别。

第三步：再学状态与恢复

当你能理解：

• 为什么状态要持久化
• 为什么任务会中断
• 为什么要有 retry、timeout、max steps

你再去看 LangGraph 的 durable execution，会容易很多。

第四步：最后再进入复杂框架

到这一步，再去学：

• LangGraph
• PydanticAI
• CrewAI
• OpenHands
• Langfuse
• Promptfoo

你会更清楚每个工具到底处于哪一层，而不是把它们当成一堆互相替代的“AI 框架”。

十、给初学者的最终结论

如果你只想记住几句话，可以记住下面这些：

第一，模型不是系统。
模型只是大脑，企业级 AI Agent 要想可靠落地，必须有工具、环境、状态、权限、评测、恢复与观测。

第二，Agent 不等于 Workflow。
Workflow 更偏固定流程，Agent 更偏围绕目标自主决策与动态执行。

第三，LangGraph 不是单纯让模型更聪明，而是让 agent 的执行过程更可控。
它强在状态、控制流、恢复、人类介入和生产级运行能力。

第四，durable execution 不等于防卡死。
它更像断点续跑，而不是自动避免错误循环。要防止 agent 卡死，还需要 timeout、max steps、watchdog、人工中断和可观测性。

第五，企业选型不是追最强，而是追最适合。
真正好的技术选型，永远是贴着业务目标、团队能力、治理要求和维护成本做出来的。

参考资料

以下链接均为本文写作时使用的一手或官方资料：

1. OpenAI, 2026-02-11, Harness engineering: leveraging Codex in an agent-first world
2. Anthropic, 2026-01-09, Demystifying evals for AI agents
3. Anthropic, 2025, Trustworthy agents in practice
4. Anthropic, 2026, Building effective agents
5. LangChain, LangGraph Overview
6. LangChain, LangGraph Durable Execution
7. Pydantic, PydanticAI Documentation
8. CrewAI, Documentation
9. OpenHands, Introduction
10. Browser Use, Documentation
11. Langfuse, Documentation
12. Promptfoo, GitHub Repository
13. Inspect AI, Official Documentation
14. Dify, Introduction
15. Flowise, Documentation
16. Martin Fowler / Thoughtworks, 2026-04-02, Harness engineering for coding agent users