从 Transformer 到 Harness Engineering：一篇看懂 AI Agent 技术栈

这两年 AI 领域的新概念几乎是按周在长。
LLM、RAG、Function Calling、MCP、Agent、Multi-Agent、Context Engineering、Agent Skill、Harness Engineering……如果只是零散地看，很容易觉得每个词都像“新一代终极方案”。

更稳的理解方式，是把它们放回同一条技术链路里看：

• 底层先解决“模型本身能不能生成”
• 中间层解决“模型怎么更准、怎么拿到外部知识、怎么接工具”
• 再往上才是“怎么把模型做成一个能持续执行任务的系统”
• 最后才进入“怎么复用经验、怎么稳定交付、怎么把系统工程化”

这篇文章就按这个顺序，把 12 个高频概念整理成一份导读。目标不是追求定义最学术，而是尽量回答两个更实际的问题：

1. 这个概念到底解决什么问题？
2. 它和相邻概念的边界在哪里？

一、基础层：先理解模型从哪里来

1. LLM

如果把整个技术栈往下追，第一层当然还是 LLM。

大语言模型之所以成为今天生成式 AI 的基础设施，核心原因是 Transformer 架构把“基于注意力机制的大规模序列建模”这件事做成了通用底座。它不再像更早期模型那样严重依赖固定长度记忆或严格顺序传播，而是允许模型在生成当前 token 时，动态关注输入上下文中的不同部分。

到了今天，最主流的实现路线基本都收敛在 Decoder-Only Transformer 上。原因也很直接：

• 对自回归生成任务天然合适
• 训练目标统一，便于大规模扩展
• 既能做聊天，也能做代码、文档、推理和工具调用

从工程角度看，LLM 这一层决定的是模型有没有基础表达和推理能力。但它并不直接决定系统能不能落地。后面很多技术，都是围绕“怎么把一个强生成器变成可控、可用、可接入真实世界的系统”展开的。

2. Prompt Engineering

Prompt 本质上是给模型的一组输入约束。最常见的两类是：

• System Prompt
• User Prompt

前者定义角色、规则和边界，后者给出当前任务。

Prompt Engineering 做的不是训练模型，而是通过设计输入，让模型在当前能力范围内更稳定地表现出来。这也是它一直特别受欢迎的原因：成本低、反馈快、不需要动参数。

但这里有个常见误区需要先讲清：

提示词工程提升的是“调用效果”，不是“模型智力”。

也就是说：

• 它可以让模型更听话
• 可以减少格式错误
• 可以把输出引到更接近目标的方向

但它不能凭空让模型学会一个根本不会的领域能力，也不能替代知识更新、工具接入和系统设计。

所以 Prompt Engineering 很重要，但通常不是终局，而是整个链路里最靠前的一层控制杆。

3. Fine-tuning（微调）

如果 Prompt 解决不了问题，下一层就会来到 Fine-tuning。

微调的核心思路是：在已有基础模型上，再用特定任务的数据继续训练，让模型在某个场景里形成更强的偏好、更稳定的格式、更高的专用能力。

和 Prompt 不同，微调真正改动的是模型参数。
这意味着它的收益和成本都更重：

• 收益是能力能被长期固化
• 成本是要准备数据、训练、评估、部署和版本管理

这也是为什么 LoRA 这样的参数高效微调方法会这么重要。
LoRA 不需要全量更新全部权重，而是只训练少量低秩参数，就能把训练成本和部署门槛压下来。

可以把 Prompt 和 Fine-tuning 的差别记成一句话：

• Prompt 是“换提问方式”
• Fine-tuning 是“改模型习惯”

4. RAG（检索增强生成）

很多场景下，模型回答不准，不是因为不会推理，而是因为知识不在参数里，或者参数里的知识已经过时。

这时候比起微调，很多团队先选 RAG。

RAG 的逻辑很简单：

1. 先从外部知识库检索相关内容
2. 再把检索结果作为上下文喂给模型
3. 最后基于“模型能力 + 最新知识”生成答案

它解决的是知识时效性和事实覆盖问题，典型适合：

• 企业知识库问答
• 文档助手
• 客服支持
• 内部制度、产品说明、代码库检索

RAG 和 Fine-tuning 经常被拿来比较，但两者解决的问题并不一样：

• RAG 更像临时补知识
• Fine-tuning 更像长期改能力

如果模型“不知道事实”，优先考虑 RAG。
如果模型“知道材料但老做不出你想要的输出风格或任务结构”，再考虑微调。

二、连接层：让模型不只会生成，还能接入世界

到了这一层，重点已经不是“模型本身怎么变强”，而是“模型怎么和外部系统协作”。

5. Function Calling

Function Calling 的意义非常大，因为它让模型从“只会输出文本”变成“能够发起结构化调用请求”。

具体说，它不是让模型真的自己执行函数，而是让模型按约定格式产出：

• 要调用哪个函数
• 带什么参数
• 调用意图是什么

然后由外部程序去真正执行。

这一步非常关键，因为一旦模型可以稳定地产生结构化调用指令，它就不再只是聊天接口，而可以开始：

• 查数据库
• 调 API
• 搜索网页
• 发消息
• 下任务
• 跑脚本

所以 Function Calling 的本质不是“多一个输出格式”，而是模型第一次获得了工具使用入口。

6. MCP（Model Context Protocol）

如果说 Function Calling 解决的是“模型如何发起一次工具调用”，那么 MCP 解决的是更上层的问题：

模型如何用统一协议连接各种外部工具、数据源和服务。

MCP 的价值不只是“能接”，而是“接入方式标准化”。
一旦标准化，工具就可以跨不同 AI 应用复用，生态才会长出来。

这件事和早期互联网协议很像。
不是每个应用都重新发明一套连接方式，而是有一套相对统一的接口规范，应用层才能快速组合能力。

从工程角度看，MCP 最重要的意义至少有三个：

• 降低工具接入成本
• 提高能力复用性
• 让 Agent 应用更容易共享同一批外部能力

但也要注意一个边界：

MCP 不是 Agent 本身。

它更像 Agent 背后的“标准化外设总线”。
有了它，Agent 接工具会更顺；但没有任务编排、上下文管理和反馈回路，系统依然只能算“会调工具的模型接口”。

三、系统层：从模型升级为任务执行系统

7. Agent

当模型能够接工具、能够读取上下文、能够根据目标连续推进时，才真正进入 Agent 这一层。

Agent 的核心不是“像人聊天”，而是它能围绕目标形成一个持续循环：

• 思考
• 行动
• 观察
• 再调整下一步

这就是大家常说的 Think -> Act -> Observe。

从最小构成看，一个 Agent 通常至少需要三样东西：

• LLM
• Prompt
• Tools

有了这三样，模型就不再只是一次性回答器，而开始具备最基本的任务执行能力。

不过这里也要保持克制。
很多时候所谓 Agent，并不是一个“神秘的新物种”，而只是：

• 一个带状态的 LLM 调用器
• 一套工具路由逻辑
• 一层循环控制

也正因为如此，Agent 的效果很少只由模型本身决定，更多取决于：

• 工具好不好接
• 状态怎么存
• 失败后怎么回退
• 什么时候停

8. Multi-Agent

当单个 Agent 开始遇到瓶颈，才会进入 Multi-Agent。

它的基本思路是，把复杂任务拆给多个分工不同的 Agent 协作完成。这样做通常有两个直接收益：

• 拆分任务复杂度
• 隔离上下文污染

例如：

• 一个 Agent 负责检索
• 一个 Agent 负责分析
• 一个 Agent 负责写作
• 一个 Agent 负责校验

听上去很美，但 Multi-Agent 绝对不是默认选项。
它的代价往往也很重：

• token 消耗暴涨
• 调试链路更长
• 协调逻辑更复杂
• 子 Agent 之间可能互相放大错误

所以更稳的原则通常是：

单 Agent 能做的，不要急着上 Multi-Agent。

只有当任务确实存在明显的：

• 角色分工边界
• 上下文隔离需求
• 并行处理收益

再考虑把系统拆开。

9. Context Engineering

很多团队做到 Agent 阶段后，真正遇到的大问题不再是“模型够不够强”，而是：

到底该把哪些信息给模型看。

这就是 Context Engineering。

对 Agent 来说，进入模型上下文窗口的一切内容都算上下文，比如：

• 用户输入
• 历史对话
• 系统规则
• 外部知识
• 工具结果
• 中间计划
• 任务状态

上下文工程关注的不是“信息越多越好”，而是：

• 哪些信息该进入
• 什么时候进入
• 什么时候该被压缩
• 什么状态应该隔离在模型外部

它的目标是最大化模型每一步决策时的信号质量，而不是单纯堆 token。

很多 Agent 系统后期效果变差，不是因为模型退化，而是因为上下文越来越脏：

• 无关历史越来越多
• 中间结果不断堆积
• 老规则和新规则互相打架
• 工具输出把注意力吃光

所以 Context Engineering 往往是 Agent 进入工程化之后，最需要补的一课。

四、工程层：把经验、框架和约束做成系统资产

10. Agent Skill

Agent Skill 可以理解成一种轻量、开放、可复用的能力封装格式。它不是单个 prompt，也不只是单个工具，而是一整套可以被按需激活的任务能力包。

一个 Skill 里通常可以包含：

• prompt 模板
• 工具脚本
• 参考知识文件
• 执行说明
• 任务 SOP

从工程效果上看，它经常扮演一个“轻量子 Agent”或“能力插件”的角色。
它的重点不在于再造一个更大的 Agent，而在于把可重复流程沉淀下来，让系统在需要时自动加载。

这对团队特别重要，因为很多真实经验不是写在论文里，而是沉淀在：

• 排障脚本
• 操作手册
• 历史案例
• 隐性的团队习惯里

Skill 的意义，就是把这些东西从“口口相传”变成“可执行、可复用、可迁移”的模块。

对组织来说，这几乎就是 SOP 的数字化。
某种意义上，离职同事最终确实可以“化作温暖的 Skill”。

11. OpenClaw

当我们开始谈 OpenClaw 这类框架时，关注点已经不是单个概念，而是这些能力如何被整合进一个真实产品框架。

按你的定义，OpenClaw 是一个开源、高可扩展、基于 TypeScript 的 AI Agent 框架，面向的是“可自定义的私人 AI 助手”这一类场景。

它的价值不只是再做一个 Agent Loop，而是把一整套系统能力往产品方向推进，例如：

• 多入口接入
• 外部工具集成
• 框架扩展能力
• 更贴近日常工作的交互渠道

像“支持飞书这类入口”这件事，表面上看像功能点，实际上很重要。
因为这意味着 Agent 不再被困在单一聊天窗口里，而是可以进入更接近真实协作流程的环境。

从这个角度看，OpenClaw 代表的是一类框架思路：

• 不是只关心模型怎么回答
• 而是关心 Agent 怎么变成真正可被使用的私人助手系统

12. Harness Engineering

如果说前面的概念是在回答“Agent 具备哪些能力”，那么 Harness Engineering 关注的是另一个更硬的问题：

怎么让 Agent 在长周期、复杂、受约束的任务里稳定完成工作。

它强调的不是多一个技巧，而是一整套围绕 Agent 建立起来的受控运行环境，包括：

• 约束机制
• 反馈回路
• 状态管理
• 可靠上下文
• 失败恢复
• 评估与验证

可以把它理解成给 Agent 搭一套“工作台”：

• 它能接触什么
• 它不能做什么
• 每一步如何被记录
• 结果怎么检查
• 出错后如何回滚

当任务从“问答”变成“跑数小时的复杂流程”时，Harness Engineering 就会变得特别重要。
因为这时候最大的风险已经不是模型说错一句话，而是系统在长链路里逐步失控。

五、把这 12 个概念放在一起，关系就清楚了

如果用一句更工程化的话来概括，可以这么看：

• LLM 提供基础生成能力
• Prompt Engineering 负责低成本引导输出
• Fine-tuning 负责长期固化专用能力
• RAG 负责补充外部知识
• Function Calling 负责让模型能发起工具调用
• MCP 负责把外部工具连接方式标准化
• Agent 负责把模型升级成任务闭环
• Multi-Agent 负责在必要时拆分协作
• Context Engineering 负责管理模型看到的信息
• Agent Skill 负责沉淀和复用 SOP
• OpenClaw 代表把这些能力产品化、框架化的一类实践
• Harness Engineering 负责让整个系统在复杂任务里可靠运行

这里最容易混淆的几个点，再压缩说一遍：

• Prompt Engineering 不等于训练模型
• RAG 不等于微调
• Function Calling 不等于 Agent
• MCP 不等于 Agent 框架
• Multi-Agent 不是越多越高级
• Skill 不只是提示词片段
• Harness Engineering 不是某个单一组件，而是一套系统工程方法

六、一个更实用的学习顺序

如果是从零开始，我更推荐按下面这个顺序理解，而不是按热点词出现顺序追：

1. 先弄懂 LLM、Transformer、Decoder-Only
2. 再理解 Prompt Engineering、Fine-tuning、RAG
3. 接着看 Function Calling 和 MCP
4. 然后进入 Agent 与 Context Engineering
5. 最后再看 Multi-Agent、Skill、Harness Engineering

原因很简单：

• 不理解模型，就容易把所有问题都推给 Prompt
• 不理解 RAG 和微调，就容易乱选方案
• 不理解工具接入，就会把 Agent 想成“高级聊天机器人”
• 不理解上下文工程，就会在系统变复杂时很快失控
• 不理解 Harness Engineering，就很难把 Demo 变成长期可运行的产品

七、结语

今天的 AI Agent 领域，最缺的往往不是新名词，而是分层理解能力。

当你把这些概念放回同一张地图里，就会发现它们其实并不神秘：

• 有的在解决模型能力问题
• 有的在解决知识问题
• 有的在解决工具连接问题
• 有的在解决任务编排问题
• 有的在解决系统工程问题

真正重要的，不是能不能把这些词全部背下来，而是遇到一个具体问题时，能不能判断：

• 这是模型本身的问题
• 还是知识获取的问题
• 还是工具接入的问题
• 还是上下文污染的问题
• 还是系统约束和工程治理的问题

一旦层次判断对了，方案选择通常就不会太偏。