RAG 解决知识，Skill 解决能力，Harness 解决执行
很多人还在用 2024 年的脑子理解 2026 年的 AI 系统。
一开始，行业都在卷模型。
后来，大家发现模型不知道你的私有知识，于是补 RAG。
再后来，大家发现知道还不够，模型还得学会调用特定工具、遵循特定流程，于是补 Skill。
但系统一旦真的进入生产环境，新的问题马上暴露出来了：就算模型能检索、会调用，也不代表它能稳定、持续、可控地把一件事做完。
这时候，真正开始变重要的，就是 Harness。
如果把这三个词压成一句最短的判断：
RAG 解决的是模型不知道什么。
Skill 解决的是模型不会做什么
Harness 解决的则是模型怎么在真实世界里把事情做完，而且不失控。
为什么 RAG 先火
RAG 之所以率先成为标配，不是因为它最优雅，而是因为它最先打到真实痛点。
大模型再强，也不可能天然知道你的私有文档、最新业务状态、内部流程和不断变化的上下文。
于是最直接的补法，就是不要把所有知识都塞进上下文窗口，而是在运行时按需检索最相关的信息，再把它注入当前推理。
Anthropic 最新的 RAG for Projects 说明里讲得很直白：当项目知识逼近上下文窗口上限时，系统会自动切到 RAG 模式，把容量扩到原来的 10 倍，同时只检索当前问题最相关的那一部分内容。这里的关键词不是“知识更多”，而是“不要一次全塞，只取当前最相关”。
所以 RAG 本质上是在解决一个知识供给问题。
模型不知道。
那就去取。
它把“模型脑子里没有”这个问题，改写成了“系统能不能在运行时把对的知识拿回来”。这一步极其重要，因为它第一次让大家意识到：AI 不是一个封闭的大脑，而是一个会在运行时动态接知识的系统。
但 RAG 也有明确边界。
它只能解决“知道什么”，解决不了“接下来怎么做”。你把一堆对的文档取回来，不代表模型就能稳定地执行多步操作、遵守组织流程、在失败后恢复、在高风险动作前停下来等人批准。RAG 让模型更像一个知道情况的人，但还没把它变成一个可靠的执行者。
为什么 Skill 又补上来
于是下一步，行业开始补 Skill。
Skill 的意义，不是再给模型多一点知识，而是把一类能力、一套流程、一组约束，打包成可以复用的能力单元。
微软最新的 Agent Skills 文档对它的定义很清楚：skills 是“instructions, scripts, and resources”的可移植包，用来给 agent 添加专业能力和领域知识，而且采用 progressive disclosure，也就是只在需要时加载完整说明和资源，避免把上下文撑爆。Harness 自己在 Harness Skills 文档里也走的是同一路线：skill 本质上是结构化的 Markdown 指令，里面封装了生成 pipeline、创建服务、调试执行、分析成本这些领域动作，然后通过 MCP 工具去真正落地。
这一步比 RAG 更进一步。
RAG 还是在补“信息”。
Skill 已经开始补“动作模板”。
你可以把它理解成给模型装插件，但这个比喻其实还不够准确。因为 Skill 不是简单暴露一个 API 列表，而是把“什么时候该用”“怎么用”“遇到什么边界情况怎么办”“需要参考哪些文档”这些东西一起封进去。它不只是把工具挂给模型，而是在教模型如何像某个领域里的熟手那样做事。
所以 Skill 解决的是能力供给问题。
模型原本不会。
那就给它一套可调用的专业能力包。
但到这里，问题仍然没有真正结束。
因为一个系统就算既有 RAG，又有 Skill，也还是可能在真实环境里翻车。它可能在第七步忘了前面做过什么，可能调用工具顺序错乱，可能上下文越来越长之后开始漂移，可能该拦截的危险动作直接放过去，可能一次失败之后无法恢复，可能根本没有可审计的执行轨迹。
也就是说，RAG 和 Skill 解决了“拿什么”和“怎么做”，却还没解决“这一切到底在哪里被管理、被约束、被执行”。
Harness 为什么现在开始变重要
微软在 2026-03-12 发布的 Agent Harness in Agent Framework 里，直接把 harness 定义成 model reasoning 和 real execution 连接起来的那一层，重点包括 shell / filesystem access、approval flows，以及 long-running sessions 的 context management。
SkillMill 则给了一个更适合传播的定义：harness 是执行 AI agents 的 runtime environment，是把语言模型接到 tools、files 和 outside world 的那层软件，你可以把它理解成 AI agent 的 operating system。
Salesforce 的说法更企业化一些：harness 是管理 tools、memory 和 safety 的 operational software layer，用来保证 autonomous task execution 可靠发生。
简单来说，Harness 就是套在模型外面的那层“执行壳”。模型负责想，Harness 负责让它真正下场干活，同时别乱来。它一头接工具、文件、浏览器、终端和外部环境，另一头管权限、审批、状态、记忆和安全边界。没有它，模型更像一个会说话但不会在现实里工作的脑子；有了它，agent 才开始像一个能被组织接纳的执行系统。
这几种说法虽然来自不同阵营，但指向的是同一件事：
Harness 不是模型。
也不是单个 skill。
更不是单纯的工作流编排。
它是包在模型外面的运行时与治理层。
为什么它在 2026 年 suddenly 变得重要？因为行业终于开始承认一个很不体面的现实：模型变强，并不会自动把 agent 变成产品。
Salesforce 那篇文章里有一句话特别值得记住，意思是“a model on its own is not a product”。
这句话看似常识，实际是过去两年里很多 demo 最大的盲点。大家一直在看模型能不能推理、能不能写代码、能不能调用工具，却没有真正把注意力放到另一个问题上：
当任务跨越几十步、持续几小时、涉及多个系统、还要留下责任链的时候，谁来保证这个系统不散架？
答案不是 RAG。
也不是 Skill。
答案正是 Harness。
Harness 到底管什么
如果用工程语言说，Harness 管的是五类东西。
第一，执行环境。
模型要碰文件系统、shell、浏览器、API、数据库，它不能直接裸奔
Harness 决定它能接哪些工具、在哪个环境里运行、哪些动作需要显式批准、哪些动作根本不能做。微软那篇文章里最典型的例子就是 shell harness 和 approval flow：命令不是模型说跑就跑，而是先进入一个受控执行层，必要时过人工审批。
第二，状态与记忆。
单轮对话不是 agent 的真实工作单位。真实任务往往会跨多轮、跨会话、跨时间。Harness 要负责把中间状态存下来，让系统知道自己做到哪一步、失败在哪一步、下次能不能续上，而不是每一轮都重新开机。
第三，上下文压缩与调度。
这是很多人低估的一层。RAG 解决的是“从外部拿什么进来”，Harness 解决的是“当前上下文里留什么、压什么、丢什么、何时补取什么”。微软这次专门把 context compaction 拿出来讲，就是因为长任务真正先爆掉的，经常不是推理，而是上下文管理。
第四，错误恢复与可审计性。
只会成功一次的 agent 不叫系统。Harness 要能记录执行轨迹、复现失败、重试步骤、隔离问题，还要回答企业最关心的那种问题：为什么这次出错？是谁批准的？这一步调用了哪个工具？哪条规则放行的？没有这一层，agent 永远只适合 demo，不适合生产。
第五，治理与责任边界。
模型擅长生成，企业在乎的是约束。高风险动作要不要停下来等人？不同环境权限如何隔离？哪些操作允许自动执行，哪些必须人工拍板？Harness 本质上是在给模型套一层现实世界的法律系统。它决定 agent 可以聪明到什么程度，更决定 agent 可以危险到什么程度。
所以 Skill 更像“给 agent 装能力包”，Harness 更像“给 agent 盖操作系统和监管框架”。
它和 Workflow、Framework、Orchestrator 也不是一回事
这里最容易混淆。
很多人一听 Harness，会把它和 framework、orchestrator、workflow engine 混成一锅。其实这几个词不在同一层。
Framework 提供的是构建 agent 的开发抽象。
Orchestrator 管的是步骤顺序与控制流。
Workflow 解决的是业务流程怎么编排。
Skill 提供的是一类可复用的专长。
RAG 提供的是运行时知识检索。
Harness 则是把这些东西放进一个可运行、可持续、可约束、可恢复的系统里。
如果一定要压成一句最容易记住的话：
Framework 是蓝图。
Skill 是能力包。
RAG 是知识补给。
Orchestrator 是流程导演。
Harness 才是那个真正让系统活着跑起来、而且别出大事的运行层。
这也是为什么我认为，AI 领域接下来会出现一个非常明确的认知升级：以后评价一个 agent 系统，不能再只问“模型是谁”，也不能只问“有没有 RAG”“有没有 Skill”。更关键的问题会变成：
它的 harness 做得怎么样？
有没有上下文治理？
有没有审批机制？
有没有状态持久化？
有没有错误恢复？
有没有可审计轨迹？
有没有把工具接入和安全边界放在同一个运行层里？
这些问题，才决定它是玩具，还是生产系统。
为什么这件事现在特别值钱
因为 AI 的价值中心正在往后移。
早期大家买模型，是在买“会不会说”。后来大家补 RAG，是在买“知不知道我的私有知识”。再后来大家做 Skill，是在买“会不会按我的领域方式干活”。而现在，越来越多组织真正付钱的理由，会变成“它能不能在我的环境里稳定运行，而且出了事我能不能兜得住”。
这是一个很大的迁移。
以前，智能本身稀缺，所以价值长在模型层。
现在，智能供给越来越丰富，价值就会往系统层迁移。谁更会治理上下文、接工具、控风险、管权限、做审计、保持续运行，谁就更接近下一阶段的基础设施位置。
所以严格说，Harness 还不像 RAG 那样已经完全变成一个人人统一使用的标准术语，但它正在快速变成 agent 工程圈里一个越来越关键的共识：模型不是系统，runtime 才决定系统。
最后一句
过去两年，很多人以为 AI 工程的升级路径是：
更强的模型。
更多的知识。
更多的能力。
但这条路径还差最后一层。
真正把 agent 从“会一点”推到“能交付”的，不是再塞更多能力，而是把这些能力放进一个能运行、能恢复、能审计、能约束的 Harness 里。
AI 下一个真正会重新变贵的，不是智力本身。
而是把智力变成可靠执行的那一层系统工程。
参考链接
- Agent Harness in Agent Framework | Microsoft | 2026-03-12
- Agent Skills | Microsoft Learn
- Retrieval augmented generation (RAG) for projects | Claude Help Center
- Harness Skills | Harness Developer Hub | 2026-03-09
- Agent Harness: The Infrastructure for Reliable AI | Salesforce
- What is an Agent Harness? | SkillMill
