星澜

天接云涛连晓雾，星河欲转千帆舞

01. AI Agent 与 Harness：概念梳理

mingzaily / 2026-03-29 · 协作：Codex、Claude

系列文章 · AI Agent 与 Harness

  1. 01. AI Agent 与 Harness：概念梳理
  2. 02. AI Agent 与 Harness：从 Prompt 到 Harness
  3. 03. AI Agent 与 Harness：V2 Harness 的验证设计
  4. 04. AI Agent 与 Harness：Repo Instructions、Skills 与团队工作流
  5. 05. AI Agent 与 Harness：Agent Harness、Graph 与退款 Agent
  6. 06. AI Agent 与 Harness：Harness 是终局还是中间态？
  7. 番外. AI Agent 与 Harness：Anthropic 和 LangChain 的 Harness Engineering

引言

最近一直在反复想几个词：agent、harness、skill、tool、MCP、context、memory。
它们在视频、推文、产品宣传、框架文档里经常被混着说，结果就是每个词都像懂了，又都不算真懂。

这篇文章想做的事很简单：把这些词放回工程语境里，先理顺它们之间的关系，再把这组文章的阅读顺序摆清楚。

总结

压成一句话就是：

model 负责想，agent 负责持续做，harness 负责让它做得稳、做得可控。

概念地图

从工程视角，三者的包含关系更像：

harness 包含 agent，agent 使用 model

也就是：

Model、Prompt、Context、Memory 到底是什么关系

Model 比较像大脑。

它负责理解上下文、生成内容、进行推理、总结、归纳、给出下一步建议。
但它本身并不天然拥有文件系统权限、数据库权限、浏览器能力、测试能力，也不天然具备长期状态管理和任务闭环能力。

所以只把一个模型放在网页对话框里，它更像一个“会聊天、会分析、会写东西的超级大脑”，还不是一个完整 agent。

Prompt engineering 是最早也最容易理解的一层。
它主要解决：

但它的边界也很明显。
只靠 prompt，你很难解决长任务失忆、工具调用、状态持久化、自动验证、失败返工这些问题。

Context 和 Memory 也经常被混淆。

我的理解是：

如果打比方：

所以：

context != memory

这个区别很重要，因为很多所谓“记忆问题”，其实本质上是上下文管理问题，而不一定真的是长期 memory 问题。

Tool、MCP、Skill 分别是什么

这三个词经常一起出现，但它们在系统里的位置并不一样。

Tool 是什么

Tool 最好理解。

它就是 agent 运行时可调用的能力接口，比如：

所以：

tool 是能力，不是协议。

MCP 是什么

MCP 则更像接线标准。

它的意义是让 agent 用统一方式连接外部系统和资源，比如 GitHub、Jira、Slack、数据库、浏览器、内部知识系统。它更像 USB-C 或 HTTP 这种协议层，而不是具体能力本身。

更准确地拆开看：

所以在概念上：

MCP 更接近协议，不直接等于能力。

但在日常语境里，大家说“装了 MCP”“接了 MCP”，很多时候其实是在说：

装了某个具体的 MCP server。

Skill 是什么

Skill 则最像 SOP，但又不只是 SOP。

它可以是：

所以 skill 可以先粗略理解成：

但它比普通 SOP 更强，因为它常常还能附带：

顺手澄清一个常见误解：

skill 可以依赖 MCP server，但 MCP server 本体一般不算 skill 的组成内容。

到底什么才叫 AI Agent

这是最容易被说乱的部分。

在比较宽泛的市场语境里，很多人会把“模型 + 提示词”也叫 agent。
这么叫不算完全错，但如果进入工程讨论，这个定义太松了。

放到工程语境里，一个更实用的定义是：

AI agent = LLM + state + tool use + planning/orchestration + action loop

也可以从能力角度理解：

所以在工程语境里：

也正因为这样：

Codex、Claude Code 这种更像已经封装好的现成 agent 产品。
而单纯一个网页聊天框，更多还是 assistant。

几个直观的 coding agent 例子

先说最熟悉的一类，也就是 coding agent。

Claude 和 Claude Code 其实不是一回事。
Claude 是 Anthropic 的模型家族，Claude Code 才是 Anthropic 做的 coding agent 产品。Anthropic 官方在文档里直接把它叫做 an agentic coding tool。

Codex 也是一样。
这里说的不是早年那个模型名，而是 OpenAI 现在的 coding agent 产品。OpenAI 官方文档把它描述成可以读代码、改代码、运行代码的 coding agent，Codex CLI 的 README 也直接写着它是 a coding agent from OpenAI that runs locally on your computer。

OpenCode 则是社区开源实现的例子。
它的 README 直接写的是 The open source AI coding agent。

这几个例子的共同点不是“都会写代码”这么简单，而是：

所以它们更像真正的 agent，而不是只会回复一段文字的 assistant。

再看几个业务 agent 的例子

agent 当然不只存在于写代码场景。

比如一个 客服分诊 agent，它的工作可能是：

再比如一个 退款 / 订单管理 agent，它可能会：

OpenAI 在官方的 agent building guide 里，也把 refund approval、order tracking、returns or refunds 当作典型场景。

还有一些更偏运营和风控的例子，比如：

它们的共同点也很像：

所以更准确地说：

Agent 的分类

如果只用一条线来给 agent 分类，很容易把产品形态和技术实现揉在一起。
更清楚的办法，是把它拆成两个维度来看。

产品视角：通用型 vs 垂直型

这一维看的是任务空间：

这个 agent 服务的到底是通用任务，还是某个垂直业务。

技术视角：Workflow-First vs Agentic

这里说的 workflow 是广义概念，指预定义流程、规则节点和 orchestration 层，不特指某个具体框架。

所以这一维讨论的，不是某一个产品名，而是：

系统主要靠预定义流程推进，还是更多靠模型在执行中动态决策。

这里最容易让人误会的一点是：

有 graph，不等于它就是 workflow-first。

几乎所有生产级 AI 系统，最终都能被画成某种状态图、流程图或 orchestration graph。
业务一旦真的落地，也很难完全脱离流程骨架、权限边界和状态管理。

真正的区别不在于“有没有图”，而在于：

换句话说，graph 更像一种 orchestration 表达方式，本身并不天然站在 workflow-first 这一边。
真正会把系统往 workflow-first 推过去的，是你在图里写死了多少业务步骤、审批节点和规则分支。

放到工程实现里看：

所以画 graph 这件事本身没有问题。
更常见的现实其实是：

这类系统并不是“不 agentic”，而是：

在受约束的骨架里运行 agentic 能力。

这一维看的是执行方式：

这个系统主要靠固定流程推进，还是主要靠 agent 自主决策推进。

这两条轴不是一一对应的。

比如：

所以很多所谓“业务 agent”，落地时往往更像 workflow-first + 局部 agentic 能力。
这不是降级，反而通常更符合业务系统的现实。

说得直白一点：
目前真正“完全没有流程骨架”的业务 AI 产品非常少。更常见的现实是：

先有一个可控的 graph 骨架，再把规划、路由、返工这些更 agentic 的能力放进其中某些节点和循环里。

Harness 到底是什么

如果说 agent 是开始干活的数字员工，harness 就是把这个数字员工变得可控、可交付、可复用的整套工程装置。

它通常会落到这些东西上：

“harness” 这个词本身就来自马具（reins, saddle, bit）——把一匹强壮但方向不定的动物引导到可控方向的那套装置：

马再强，没有马具就方向不定；model 再好，没有 harness 就跑偏。

harness 不是替代 model，而是把 model 的能力引导到有价值、可预期的方向。

Harness 的四个关键概念

如果把各种零散说法压缩一下，我觉得比较好记的四个关键概念是：

1. 上下文工程

核心问题是：
每一轮让模型看到什么，怎么组织，怎么避免关键信息丢失。

常见做法包括：

2. 架构约束

核心问题是：
怎么给 agent 上护栏，不让它在错误的时候做错误的动作。

常见做法包括：

3. 反馈循环

核心问题是：
不能只靠模型说“我已经完成了”，而要让它接受外部验证。

典型循环是：

生成 -> 执行 -> 观察 -> 验证 -> 反馈 -> 再生成

这也是为什么测试、evaluator、浏览器自动化、数据校验这么重要。

4. 熵管理

这是长任务里最容易被忽略、但其实最关键的部分。

任务一长，上下文就会膨胀，信息会漂移，状态会变乱，模型还会反复修同一个地方。
这其实就是熵在上升。

所以需要：

一句话就是：

不要让长任务越跑越糊。

Harness 在不同场景里的样子

Harness 不是一个固定的实现形式，它在不同场景里落地的样子差别很大。

区分两种场景会更清楚：

为了说明分层，下面会把 agent 产品自带的执行环境、工具组织和指令加载机制，暂且称为 product harness。
再把团队基于 AGENTS.md、skills、MCP 使用约定和验证流程补上的这一层，暂且称为“团队侧 harness”；这不是严格行业术语，只是为了把不同责任边界讲清楚。

使用现成 agent 产品时，产品本身已经带了一层 harness

如果是在团队里使用 Codex、Claude Code、OpenCode 这类产品，很多底层能力其实已经被产品方做好了。

以 Codex 为例，产品自带的 agent harness 至少已经包括：

这些都不是模型自己天然会的，而是产品方预先搭好的系统骨架。

注意其中的 AGENTS.md：产品提供的是加载和解析机制，团队负责填写其中的内容。机制是 product harness 的一部分，内容属于“团队侧 harness”的一部分。

所以从使用者视角看，团队真正要补的，是在 product harness 基础上，把团队自己的那层补齐——AGENTS.md、skills、MCP 配置和验证流程，这些都可以看作“团队侧 harness”的组成部分。

自己开发业务 agent 时，重点就会落到 agent harness

如果是自己做退款 agent、审批 agent、客服分诊 agent，情况就反过来了。

这时候你不再只是使用一个现成 agent 产品，而是在搭一套真正属于自己业务的 agent harness。
你要补的是：

也就是说，真正需要写代码、定义节点、处理状态和路由的，通常就是这一层。

两种场景下的 harness 形态

使用现成 agent 产品时：

用户 → 团队侧 harness（AGENTS.md / skills / MCP / 验证流程）→ product harness（Claude Code / Codex）→ model

自己开发业务 agent 时：

用户 → agent harness（graph / policy engine / validators / state / tools）→ model

两种场景里的 harness 都是真实的 harness。差别只在于谁搭了哪一层： 产品方搭好了底层，团队在上面再加一层；或者团队从头搭一套自己的。

退款 agent 里，harness 怎么落

拿一个 退款 agent 来看：

如果这套退款 agent 是用 coding agent 辅助开发的，那么仓库里还需要把团队的工作方式写成 harness：

这两层都是 harness，只是面向的对象不同：前者约束退款 agent 的运行，后者约束辅助开发的 coding agent 的行为。

把这些概念串成一句话

把前面的概念压成一条线，大概就是：

我真正想说明的，不是又多记住了几个新名词，而是这些词终于能落到同一张工程地图里。

延伸阅读

如果你更想看”为什么大家会从 prompt 工程一路谈到 harness engineering”，可以接着读：

如果你更关心落地阶段最硬的一层，也就是验证闭环，可以接着读：

如果你想继续把 agent harness 和仓库规则 / skills / 工作流分开看，可以接着读：

如果你想看外部两篇代表性文章在各自强调什么，可以接着读：

参考