本文转载自微信公众号「智能体AI」，作者智能体AI 。转载本文请联系智能体AI公众号。

最近两年，”AI Agent”这个词出现的频率越来越高。做模型的人在讲，做产品的人在讲，做应用和工程的人也在讲。

但问题是，同样是”Agent”这个词，大家说的未必是同一件事。

有人把”会调用工具的大模型”叫 Agent，有人把”驱动模型执行任务的整套系统”叫 Agent，还有人把”负责某个子任务的小模块”叫 Agent。这三种用法都有人在用，都能在文章和会议里见到，但它们描述的其实是三个完全不同的东西。

如果你刚刚开始接触这个方向，看多了资料可能反而越来越乱——不是资料太少，是术语越堆越高，但基础定义却没有对齐过。

这篇文章想做一件事：把 AI Agent 这套概念从头梳理一遍，搞清楚 Model、Tool、Skill、Rules、Hooks、Harness 这些词分别指什么，它们之间是什么关系。

梳理完之后，再去看 Agent 产品、Agent 框架、各种 Agent 论文，应该就不会那么容易被绕进去了。

图片

一、先给出一个核心定义：Agent 不是模型，是系统

在讲各种细节之前，先把最重要的一句话说清楚：

AI Agent 是一个以大模型为核心，能够调用工具、接收反馈，并持续完成任务的系统。

这句话里最关键的，不是”大模型”，不是”调用工具”，而是持续完成任务。

普通的聊天模型是”你问一句，我答一句”。你发给它一个问题，它给你一个回答，这一轮就结束了。下一轮对话，它不会主动接着推进什么事情。

Agent 不一样。你给它一个目标——比如”帮我搜集这个行业近三个月的动态，整理成一份摘要”——它不会直接吐出一段文字给你，而是开始分步骤执行：先决定用什么方式搜索，搜完之后读结果，根据结果判断还需要补充什么，再做一步，再观察，直到任务真正完成。

这种”目标驱动、分步推进、持续执行”的工作方式，是 Agent 和普通聊天模型最本质的区别。

所以，有些事情是 Agent 才能做的，普通聊天模型做不了：

• 搜索资料并整理成有结构的摘要
• 读取一个本地文件并分析里面的内容
• 调用代码工具处理一批数据，看结果再调整
• 在网页上连续完成多个操作步骤
• 把一个复杂任务拆开，交给多个子模块分头执行，最后汇总

这些任务有一个共同点：不是一次回答就能完成的，需要多个步骤，中间有判断，有工具，有反馈循环。

二、Model 和 Agent：核心与系统的关系

讲清楚 Agent 是个系统之后，紧接着一个问题：模型在这个系统里扮演什么角色？

很多人会以为 Agent = 一个更强的模型，或者 Agent = 模型 + 一些工具。这两种理解都不太准确。

模型是 Agent 的核心，但不是 Agent 的全部。

模型本身能做的事情是有边界的。它的本质是”文本进，文本出”——给它一段输入，它产生一段输出。它可以理解目标，可以读取上下文，可以按照规则做判断，可以生成下一步应该做什么的意图，也可以以结构化的方式表达”我要调用某个工具”的请求。

但是，它说要调用工具，和真正执行这个调用，完全是两件事。

模型不会真正点击网页，不会真正读取你电脑上的文件，不会真正向外部 API 发请求，也不会自动把一个任务循环跑完。这些事情，都需要模型外面的系统来完成。

那么，真正把任务”跑起来”的是什么？

是围绕模型搭建的整套系统：工具调用、状态管理、任务循环、结果反馈、异常处理、上下文更新……这些加在一起，才构成一个能实际干活的 Agent。

有一个比喻可以帮助理解：模型是大脑，但 Agent 是一个能把大脑、手、规则和执行系统组织起来的完整工作流。

光有大脑，手脚不动，什么也完不成。

三、Scaffolding 与 Harness：怎么想，和怎么跑

理解了 Agent 是一个系统之后，下一步是搞清楚这个系统里的两层关键结构。

这里有两个词经常出现，容易被一起叫成”Agent 框架”，但它们其实在做完全不同的事情：Scaffolding 和 Harness。

用一句话区分：Scaffolding 管”怎么想”，Harness 管”怎么跑”。

Scaffolding：给模型搭思考框架

Scaffolding 关心的是模型在执行任务时的”思考结构”。

它包括：任务怎么拆解，推理步骤怎么设计，模型扮演什么角色，输出要满足什么格式，工具怎么选，多轮执行的策略是什么。这些都属于 Scaffolding 的范畴。

Scaffolding 更偏向于”软件”层面的设计——它影响的是模型如何理解任务、如何规划步骤、如何做出决策、如何把中间结果组织起来。

Harness：让 Agent 真正动起来的执行系统

Harness 管的是执行层面的事情。

一个完整的 Harness 要做这些：接收模型的输出，解析里面的工具调用请求，把这个请求路由到对应的工具，拿到工具的返回结果，更新上下文，判断任务是继续推进还是结束。除此之外，还要处理各种工程问题：异常、超时、失败重试。

Harness 不关心模型”想什么”，它只关心”执行”。

没有 Harness，模型只是在说”我想做什么”，但什么都不会真正发生。有了 Harness，工具调用才能落地，多轮任务才能推进，结果才能回传给模型继续处理。

有一句话可以很好地概括这两者：真正的 Agent 能力，往往不是只靠模型涌现出来的，而是模型能力与 Harness 工程共同作用的结果。

这也是为什么两个使用同一个模型的 Agent，表现可能差距很大——Harness 搭得好不好，直接决定了 Agent 能不能把模型的能力真正用出来。

四、Context Engineering 与 Policy：看见什么，和怎么选择

Agent 系统里还有两个概念经常被提到，值得单独讲清楚：Context Engineering 和 Policy。

Context Engineering：管理模型每一步看到的信息

很多人知道 Prompt Engineering，但 Context Engineering 要比它宽得多。

Prompt Engineering 关心的是”提示词怎么写”。Context Engineering 关心的是：在整个任务执行过程中，模型在每一步到底应该看到什么信息。

这些信息包括：系统提示词、用户给的任务、历史对话、工具的说明文档、工具调用的返回结果、从知识库检索回来的内容、上传的文件、中间的推理状态、当前的任务进度……

而且，这不是一次性设置好就完事了的。随着任务推进，Harness 要持续决定：哪些信息保留，哪些可以压缩，哪些应该丢弃，哪些需要重新注入。

Context Engineering 在训练和推理两个阶段都适用，但代价不一样。训练时如果注入了错误的上下文，模型可能学偏，代价很高。推理时如果上下文配错了，通常还可以通过调整提示词或重新配置来补救。

这个区别值得记住。

Policy：Agent 是按什么方式做选择的

Policy 指的是 Agent 在给定情境下的行为方式——面对多个可能的下一步，它会如何选择。

几个具体的问题可以帮助理解 Policy：

• 拿到任务之后，是先去搜索，还是先尝试直接总结？
• 不确定的时候，是继续追问用户，还是自主推进？
• 遇到多条路径，是保守地走最稳的那条，还是尝试探索更多可能性？

这些选择背后的逻辑，就是 Policy。

LLM Agent 的 Policy 不是来自单一的地方，它受到很多因素的影响：模型训练中学到的行为模式、系统提示词、工具的描述方式、规则约束、记忆系统、Harness 的执行逻辑，甚至外部的评估和反馈机制。

有一点需要特别说清楚：Policy 不等于 Agent 本身。Agent 是那个在环境里真正采取行动的完整系统，Policy 是它表现出来的行为方式。同一个 Agent 系统，配置不同的提示词和规则，Policy 会完全不一样。

五、Tool、Skill、Sub-agent：动作、套路与分工

这三个词是 Agent 里被混用得最频繁的。很多人觉得它们差不多，其实对应的是三个完全不同的层次。

Tool：Agent 的”手”

Tool 是最基础的一层，指的是 Agent 能伸手够到的外部能力。

常见的 Tool 包括：搜索引擎、各种 API、数据库查询、文件系统操作、代码解释器、浏览器控制、计算器、图像生成工具。

Tool 有几个特点：通常是单次调用，输入和输出比较明确，模型只负责表达”我要用这个工具”的意图，真正执行这个调用的是 Harness。

所以，Tool 是 Agent 的”手”——模型说想伸手，Harness 负责把手真正伸出去。

Skill：Agent 的”套路”

Skill 不是一个单独的动作，而是一套围绕某类任务沉淀下来的方法。

举几个例子：排查一个 bug、做一次数据清洗、写一份市场调研摘要、生成竞品分析、完成一次代码审查。这些都不是一次工具调用能完成的事情，它们需要一组步骤、一套判断标准、特定的工具组合、经验积累下来的处理模式，以及相对固定的输出模板。

Skill 是可以复用的。同样的任务类型，有了对应的 Skill，Agent 不需要每次都从零开始思考怎么做。

所以，Skill 是 Agent 的”套路”——遇到这类任务，按照这套路子走。

Sub-agent：独立完成子任务的执行单元

Sub-agent 比 Skill 又更进一步。它不是一套方法，而是另一个可以独立运作的 Agent。

它能做什么？自己理解分配给它的子任务，自己规划步骤，自己调用工具，自己处理中间结果，最后把结果返回给主 Agent。

一个典型的场景：主 Agent 要完成一份行业分析报告。它把任务拆开，分别交给：资料收集 Sub-agent、数据整理 Sub-agent、观点提炼 Sub-agent、初稿写作 Sub-agent、审校优化 Sub-agent。每个 Sub-agent 独立运行，最后把结果汇给主 Agent 整合。

三者的关系可以这样理解：

六、Rules 与 Hooks：边界、插槽与可治理性

Agent 能执行任务，还能调用工具，听起来已经很强了。但实际部署中，一个没有约束、不可干预的 Agent，反而是危险的。

这里就要说到两个很实用的概念：Rules 和 Hooks。

Rules：给 Agent 划清行为边界

Rules 是 Agent 必须遵守的显式规则。

哪些工具可以调用，哪些不行；哪些内容绝对不能出现在输出里；哪些操作必须先得到用户确认才能执行；遇到不确定的信息时应该怎么处理；任务失败的时候，是静默放弃还是允许重试。

这些都是 Rules 在约束的范围。

Rules 的价值在于：它让 Agent 的行为变得可预期。没有 Rules 的 Agent，在测试环境里可能表现很好，一到生产环境就会出各种意料之外的事情。有了 Rules，就有了安全边界，有了业务流程的一致性，有了出问题时可以追溯的依据。

Hooks：在关键节点插入额外逻辑

如果说 Rules 是”规定 Agent 应该怎么做”，那么 Hooks 就是”在执行过程中，允许你在关键位置插入额外的处理逻辑”。

Hooks 通常挂在这些节点上：模型调用前、模型调用后、工具调用前、工具调用后、上下文更新前、最终输出前、异常发生的时候。

在这些节点上，可以做很多事情：日志记录、权限校验、内容审核、成本统计、调用限流、对工具返回结果做清洗、触发失败重试、发起人工确认、对结果做自动评估……

Hooks 让 Agent 系统变得”可观测、可干预、可扩展”。想在某个环节加一道权限检查？加一个 Hook。想统计某类工具调用的成本？加一个 Hook。想在输出前做一次内容过滤？还是加 Hook。

所以，Rules 让 Agent 有边界，Hooks 让 Agent 可扩展、可监管、可工程化。

这两个概念合在一起，构成了 Agent 系统里的”治理层”——决定了一个 Agent 能不能真正安全、稳定地跑在生产环境里。

七、训练 Agent 的人在讲什么：Environment、Rollout、Reward、Trainer

前面讲的概念，主要和”搭建一个 Agent”有关。

如果你还关注”如何让 Agent 越来越强”，就会遇到另外一套词汇，来自强化学习的传统：Environment、Rollout、Reward、Trainer。

这部分可以先跳过，等需要的时候再回来。

Environment：Agent 和世界交互的地方

Environment 是 Agent 执行动作、观察结果的场所。

它可以是浏览器、文件系统、代码仓库、数据库、游戏环境、模拟的任务空间，或者企业内部的业务系统。Agent 在环境里采取行动，环境返回新的状态和结果。

Rollout：一次完整任务执行的记录

Rollout 是 Agent 从任务开始到结束的完整轨迹，包括：看到了什么上下文，做了哪些决策，调用了哪些工具，每一步拿到了什么结果，最终有没有完成任务。

你可以把 Rollout 理解成一段”录像”——把 Agent 这次的表现完整记下来，用于后续分析和训练。

Reward：对这次执行结果的评价

Reward 是对 Rollout 的打分。它告诉系统：这次做得好不好，哪里做对了，哪里做错了。

Reward 的来源可以有很多种：测试用例是否通过、人工对结果的偏好评估、基于规则的自动评分、用户满意度、任务完成率……

Trainer：利用反馈让 Agent 越来越强

Trainer 的工作是收集大量的 Rollout，根据对应的 Reward 判断哪些行为好、哪些行为差，然后更新模型权重或策略，让 Agent 在反复试错中逐步变强。

搭建 Agent 关注”能不能跑”，训练 Agent 关注”能不能越跑越好”。两件事都重要，但不是同一件事。

八、把所有概念串在一起

梳理到这里，可以用一张结构图把所有概念的位置关系整理出来：

图片

这张图不一定要背下来，但可以在脑子里建立一个大致的空间感：Model 在中心，Harness 驱动执行，Context Engineering 管信息，Rules 和 Hooks 管治理，Tool/Skill/Sub-agent 是执行的三个层次，Policy 是表现出来的行为方式。

九、最后说一句：从模型思维到系统思维

很多人第一次接触 Agent，会把它理解成”一个更强的模型”，或者”一个能调用工具的聊天机器人”。

这种理解没有大错，但会带来一个问题：用”模型思维”去判断一个 Agent 够不够好。

Agent 够不够好，不完全取决于用了什么模型，更取决于系统整体的设计。Context Engineering 做得好不好，Harness 稳不稳，Rules 是否合理，Hooks 有没有覆盖关键节点，Skill 有没有沉淀——这些加在一起，才决定了一个 Agent 能不能真正可靠地把一个目标推进到完成。

把”模型思维”换成”系统思维”之后，再去看各种 Agent 产品和 Agent 框架，会看到很多之前看不见的东西。

AI Agent 的核心，不是让模型一次性回答得更好，而是让模型在工具、规则和工程系统的支撑下，把一个目标持续推进到完成。

文章来自：51CTO