星澜

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

01. AI Agent 与 Harness：概念梳理

mingzaily / Codex / 2026-03-29

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

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

这一组现在会分成六篇：

总览

压成一句话就是：

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

概念地图

从工程视角，可以同时记两层关系：

也就是：

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 不是替代模型，而是把模型的力量引导到稳定、正确、可控的方向。

Harness 的四个关键抓手

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

1. 上下文工程

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

常见做法包括：

2. 架构约束

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

常见做法包括：

3. 反馈循环

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

典型循环是：

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

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

4. 熵管理

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

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

所以需要：

一句话就是：

不要让长任务越跑越糊。

Harness 与仓库规则

讲到 harness，最容易混在一起的，其实是两类东西。

一类是产品或系统本身的 agent harness；
另一类是团队写进仓库里的 repo instructions、skills、验证命令和交付流程。

这组文章里说的 harness，主要就是前者。
也就是：模型外面那整套让 agent 能稳定运行、调用工具、推进状态、做验证、交付结果的系统骨架。

后面这类 repo instructions、skills、验证命令和 review / CI 流程，不是另一种官方意义上的 harness，更适合直接按仓库规则和团队工作流来写。

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

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

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

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

所以从使用者视角看，团队真正要补的，往往不是再造一套底层 harness，而是把仓库自己的工作方式写清楚。

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

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

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

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

分层图

用户 -> 仓库规则 / skills / 验证流程 -> agent harness -> model / llm

拆开看会更清楚：

这里最容易误会的是：仓库规则也在约束 agent，但它们不等于 harness 本身。

前者规定的是：

后者规定的是：

退款 agent 里，这两层怎么落

拿一个 退款 agent 来看，会更好分。

如果这个系统跑在现成 coding agent 之上，那么仓库里还可能再补一层使用约定，告诉 agent：

为什么很多能力会下沉到底层

今天经常会听到一种说法：以后也许不需要那么多显式 harness 了。

更准确的说法是，不是 harness 消失了，而是越来越多能力会下沉到底层平台和基础设施里。

比如：

所以变化不是“有没有 harness”，而是：

哪些能力已经变成系统默认能力，哪些还需要团队自己写清楚。

把这些概念串成一句话

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

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

延伸阅读

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

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

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

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

十句话总结

  1. Model 是大脑，不是完整 agent。
  2. Agent 是具有感知、规划、行动、状态闭环的 LLM 系统。
  3. 模型 + prompt 可以被宽泛地叫 agent，但在严格工程语境里更像角色化 assistant。
  4. Tool 是能力；MCP 在概念上是协议，日常语境里常常代指具体的 MCP server 接入。
  5. Skill 很像 SOP，但可以带脚本、模板和资源。
  6. Harness 不是一个组件，而是一整套让 agent 稳定工作的工程化装置。
  7. 这组文章里说的 harness，主要指 agent 外面那套系统骨架；仓库规则、skills 和验证流程是另一层配套。
  8. 反馈循环 和 熵管理 是 harness 里很容易被低估的两层。
  9. skill / tool / MCP 可以是 harness 的组成部分，但都不等于 harness 本身。
  10. 今天讨论 harness，不是在讨论新名词，而是在讨论如何把 AI 从“能聊”推进到“能稳定交付”。

参考