HuggingFace 前几天发了篇博客，《Harness, Scaffold, and the AI Agent Terms Worth Getting Right》，专门理 Agent 领域最容易混的那批词。
读完了。一个词都没记住。
我在服务器上跑着一个叫 Hermes 的 Agent 框架。跑了一阵以后发现，这些词随便一个操作都能对上号。没跑过的时候它们只是字典条目，跑过以后，它们变成了你下次 debug 时知道该改什么的东西。
Model 和 Agent
先讲最基础的一组。
我们平时说「我用 Claude」「我用 DeepSeek」，指的是模型。模型就干一件事：
输入一段文本，输出一段文本。
没了。没有记忆，不会自己循环，不会主动打开文件、搜网页、跑命令。它能表达「我想读这个文件」，但真去读文件的不是它。
Agent 是另一回事。
Agent = Model + 让它能观察、决策、行动、循环的一套完整系统。
拿我的 Hermes 来说。我在微信上发「帮我看看服务器磁盘还剩多少」，接下来发生的事情：
- 消息进入系统，被组装进上下文
- 模型被调用，输出「我建议执行一个查磁盘的命令」
- 系统真的去执行了那个命令
- 命令结果被放回上下文
- 模型再次被调用，把结果翻译成人话——「磁盘用了 67%，还剩 8.2G」
- 回复通过微信发回来
模型只做了两件事：判断该用什么命令，把结果翻译成自然语言。中间的「真执行命令」「管理上下文」「判断什么时候停」，跟模型没关系。
模型是脑子。Agent 是脑子加手脚加记事本加规则书。
所以你用 Codex、用 Cursor，看起来底层模型差不多，体验天差地别。差在 Agent 系统怎么设计的。
Scaffolding 和 Harness
这次 HuggingFace 那篇博客最核心的贡献，就是把模型之外的东西拆成了两层。
Scaffolding：模型「依据什么」行动
Scaffolding 不执行任何东西。它就是一套结构，告诉模型你是谁、在什么环境里、能用什么工具、该按什么格式输出、该记住什么忘掉什么。
在 Hermes 里，最直观的就是 System Prompt。我写的那段——「你是一个长期 AI 产品经理协作 Agent」「回答时先给结论再给步骤」「涉及删除文件必须先确认」——这些全部属于 scaffolding。
Scaffolding 不干活。它只负责告诉模型边界在哪。
Harness：系统「怎么」行动
Harness 是让一切跑起来的东西。它负责调用模型、接收工具调用请求、把请求路由到真正的函数、把结果塞回上下文、判断该继续还是停止、处理错误。
回到刚才那个例子。模型说「我建议查磁盘」，是 harness 识别出这是一个工具调用，找到对应的命令，在服务器上跑完，拿结果，放回上下文，再调一次模型。命令执行失败了？也是 harness 决定报错、重试、还是换条路。
为什么要拆开
很多产品把模型之外的所有东西统称 harness。日常沟通这么简化没问题，但当你需要诊断问题的时候，不拆开就很难受。
你的 Agent 跑偏了。怎么判断？
模型输出格式不对、忘了自己的角色、用错了工具——大概率是 scaffolding 的问题，改 prompt。
工具调用成功但结果没传回上下文、循环停不下来、错误没有兜底——大概率是 harness 的问题，改代码。Hermes 里的 config.yaml 也算代码这一侧。
拆开了，你知道该改什么。
拆不开，只能说「这个 Agent 不行」，连问题出在哪都说不出来。
Tool、Skill、Sub-agent
最后一组容易混的。
| 是什么 | 举例 | |
|---|---|---|
| Tool | 一个动作 | 读文件、搜内容、跑命令 |
| Skill | 完成一类任务的能力包 | 按流程排查 bug、按风格改文章 |
| Sub-agent | 能独立推理的子代理 | 派一个代码审查 agent 审查某个模块 |
拿 Hermes 说。
Tool 就是那些基础能力——执行命令、读文件、打开网页。每个 tool 干一件事，调一次就结束。
Skill 是打包好的经验。我让 Hermes 写 PRD，它不是只调「写文件」这一个 tool。它会先读背景文档、拆需求、搭框架、写正文、检查一致性。整套流程被封装成一个 skill，下次类似任务直接加载。Skill 里可能包含多个 tool 调用，对外暴露的是一个完整能力。
Sub-agent 更进一步。写代码的时候，主 Agent 负责协调，同时派一个子 Agent 审代码安全，另一个子 Agent 查文档。子 Agent 有自己的模型和 scaffold，能独立推理和决策。
这对产品经理有什么用
设计一个 AI 产品的时候，你要决定的不止是「要不要加 AI」。更具体的：
哪些事适合做成 tool——单一动作，确定性高，不需要推理。
哪些经验该沉淀为 skill——经常重复出现，有套路可循。
哪些任务需要独立的 sub-agent——复杂度高，需要独立推理，主流程不该被打断。
拿 AI 客服系统举例。查订单状态是一个 tool，调一下 API 就回来。处理退换货是一个 skill，包含确认订单、判断退货条件、生成退货单、通知仓库，是个打包的流程。处理需要升级的投诉可以交给 sub-agent——让它独立调查问题、查阅历史沟通记录、形成处理建议，再返回给主流程或人工客服。
这三样东西如果全叫「功能」，产品设计根本没法做。
这些词到底改变了什么
HuggingFace 那篇博客是在给一个快速膨胀的领域做概念整理。
它漏了一件事。这些词不是为了让你看起来更技术，是为了让你能更准确地思考和沟通。
分清 Model 和 Agent，你不会再问「换个更强的模型能不能解决所有问题」。不能，问题可能出在 harness 上。
分清 Scaffolding 和 Harness，你知道什么时候改 prompt，什么时候改系统逻辑。
分清 Tool、Skill 和 Sub-agent，你能在设计产品时做更精细的能力拆解，不用把所有功能揉在一起叫「AI 能力」。
我以前看codex的更新日志，只会说「又加了新功能」。现在我会想，它这次是改了 harness 的停止策略，还是扩展了 tool 的范围，还是把某些 skill 提前加载了。三件事，完全不同的产品方向。
Agent 不是一个更会聊天的模型。它是模型、上下文、工具、执行循环、技能和策略组合起来的工作系统。
理解了这一点，你不是在学怎么用 AI，是在学怎么设计 AI 做事的方式。