最近两年，“AI Agent”这个词的出镜率变得越来越高。做大模型的人在讨论，做产品的人在研究，做应用开发和工程落地的从业者，也都频繁提及这个概念。

但目前最大的问题在于，所有人嘴上说的都是“Agent”，指代的东西却未必一样。

有人将能够调用工具的大模型直接称作Agent；有人认为，驱动模型自主完成任务的一整套完整系统才是Agent；还有一部分人，把负责单一细分子任务的小型功能模块命名为Agent。

这三种叫法目前业内都普遍存在，各类行业文章、线下技术会议里都能见到，但本质上，三者指代的是完全不同的事物。

如果你刚入门AI Agent这个赛道，翻看的资料越多，反而越容易一头雾水。造成这种情况的原因，从来都不是相关资料太少，而是行业内术语杂乱堆砌，最基础的概念定义始终没能达成统一。

本文的目的很简单：从零开始，完整梳理AI Agent相关的全套基础概念，讲清楚 Model、Tool、Skill、Rules、Hooks、Harness 分别是什么，以及各个概念之间的内在联系。

弄懂这些内容之后，你再去研究各类Agent产品、开发框架以及相关学术论文，就不会轻易被繁杂的术语绕晕。

一、核心定义先行：Agent从来不是模型，而是一整套系统

在拆解细分概念之前，我先点明最核心的重点：

AI Agent是以大模型为核心载体，可以自主调用外部工具、接收任务反馈，并且能持续性推进、落地完整任务的系统。

这句话里最关键的关键词，既不是大模型，也不是工具调用能力，而是——持续性完成任务。

我们日常使用的普通对话大模型，运作模式非常简单：你发送提问，它给出对应回答，单次对话到此结束。开启新一轮对话后，模型不会主动延续上一轮的内容，更不会自主推进相关任务。

Agent的运作模式则完全不同。你只需要给它一个明确目标，比如“帮我搜集某个行业近三个月的动态，整理成结构化摘要”，它不会直接直白给出一段文字。

而是自主拆分执行步骤：先确定搜索方式、检索相关信息、读取整合搜索结果，再根据现有内容判断是否需要补充数据，反复迭代操作，直至圆满完成整个任务。

这种依托目标驱动、分步拆解任务、循环持续执行的运作模式，就是Agent和普通对话大模型最本质的区别。

也正因如此，部分复杂任务只有Agent才能胜任，普通聊天模型根本无法实现：

检索行业资料并整理成结构化摘要；读取本地文件并深度分析文件内容；调用代码工具批量处理数据，并根据运行结果调整方案；

在网页端自主完成一连串操作步骤；拆解复杂整体任务，分配给多个子单元同步执行，最后整合所有结果。

这些任务都有一个共同特征：无法依靠单次问答完成，需要多步操作，中途还要自主判断决策、调用工具、接收反馈并循环优化。

二、Model与Agent：核心内核和完整系统的从属关系

明确Agent是一套系统之后，很多人都会产生一个疑问：大模型在整套系统里，究竟扮演什么样的角色？

不少人存在两个认知误区：要么觉得Agent就是性能更强的高级大模型，要么认为Agent只是大模型叠加若干工具。这两种理解其实都不够严谨。

直白来说，模型是Agent的核心，但绝对不等于Agent的全部。

大模型本身的能力是有明确边界的，它的底层逻辑只有一个：文本输入、文本输出。

你向模型输入内容，它基于自身能力生成对应文本结果。它能够理解用户目标、读取历史上下文、按照既定规则做出决策、规划后续执行动作，还能以结构化格式发起工具调用请求。

但要分清一点：模型提出调用工具的需求，和真正落地执行工具调用，是两码事。

模型没办法自主点击网页按钮、读取你电脑本地的文件、向外部API发送请求，更没办法自动跑完一整套任务执行循环。这些落地层面的操作，全都需要模型外围的配套系统来实现。

那到底是什么东西，让抽象的任务规划真正落地运行？

是围绕大模型搭建的整套配套系统：工具调用通道、状态数据管理、任务执行循环、结果反馈机制、异常故障处理、上下文实时更新等等。所有模块组合起来，才是一个能够真正落地干活的Agent。

这里给大家打个通俗易懂的比方：大模型相当于人类的大脑，而Agent，是集合大脑、四肢、行为规则、执行体系于一体的完整工作个体。

只有大脑，没有四肢和执行体系，什么实际工作都做不了。

三、Scaffolding与Harness：负责思考，以及负责执行

弄懂Agent的系统属性后，我们再来拆解系统内部两大核心结构。这两个概念经常被混称为“Agent框架”，但二者的职能分工截然不同。

一句话简单区分：Scaffolding管控模型的思考逻辑，Harness管控Agent的落地执行。

Scaffolding：为模型搭建专属思考框架

Scaffolding的核心作用，是规范模型执行任务时的思考逻辑。

它涵盖的内容范围很广：如何拆解复杂任务、如何设计推理步骤、定义模型的角色定位、统一输出内容格式、工具的筛选逻辑、多轮任务的整体执行策略等等，全部都属于Scaffolding的管控范畴。

Scaffolding偏向软件设计层面，直接影响模型理解任务的方式、规划步骤的逻辑、做出决策的思路，以及整合中间结果的形式。

Harness：驱动Agent运转的执行系统

如果说Scaffolding管思考，那Harness就只管执行，全权负责落地层面的所有事务。

一套完整的Harness需要完成这些工作：接收模型输出内容、解析其中的工具调用请求、将请求分发至对应的工具、获取工具返回数据、同步更新上下文信息、判断任务是否需要继续推进或是直接结束。

除此之外，还要处理各类工程常见问题，比如程序异常、请求超时、任务失败重试等。

Harness从来不关心模型到底在思考什么，它只专注执行动作本身。

如果没有Harness，模型所有的工具调用想法、任务规划都只是空想，无法产生任何实际效果。有了Harness之后，工具调用才能落地，多轮迭代任务才能稳步推进，执行结果也能回传给模型，形成完整的闭环。

有句话精准概括了二者的关系：优质的Agent能力，从来不是单纯依靠大模型本身就能实现的，而是模型能力与Harness工程体系相辅相成、共同作用的结果。

这也能解释，为什么不同开发者使用同款大模型，搭建出的Agent性能差距悬殊——Harness搭建质量的好坏，直接决定能不能百分百释放模型的潜在能力。

四、Context Engineering与Policy：信息视野，以及行为选择

在Agent系统中，还有两个高频出现的专业概念，同样容易被混淆，我单独给大家拆解清楚：Context Engineering 和 Policy。

Context Engineering：管控模型每一步所能获取的信息

大部分人都听过提示词工程（Prompt Engineering），但Context Engineering的覆盖范围，要远比前者宽泛。

Prompt Engineering只聚焦一个点：如何优化提示词的撰写内容。而Context Engineering，核心是统筹整个任务周期内，模型在每一个执行环节，能够看到哪些信息。

这些信息包含：系统初始提示词、用户下达的原始任务、历史对话记录、各类工具的使用文档、工具调用后的返回数据、知识库检索内容、用户上传文件、阶段性推理状态、当前任务完成进度等等。

并且上下文配置不是一次性设置完毕就万事大吉。随着任务不断推进，Harness会实时判断：哪些信息需要保留、哪些内容可以精简压缩、哪些无效数据需要剔除、哪些关键信息需要补充注入。

Context Engineering在模型训练和推理两个阶段都会用到，但试错成本差异很大。

训练阶段一旦注入错误的上下文信息，会直接导致模型学习偏差，造成不可逆的负面影响；推理阶段如果上下文配置出错，一般只需调整提示词、重新配置参数就能修复。

Policy：界定Agent的行为选择逻辑

Policy指代Agent在不同场景下的行为准则，简单来说，就是面对多种备选执行方案时，Agent的选择逻辑。

我举几个直白的例子，方便大家理解：接到任务后，Agent是优先检索资料，还是直接尝试自主作答？遇到不确定的问题时，是主动向用户求证，还是自主推进任务？存在多条执行路径时，是保守选择稳妥方案，还是主动尝试更多可能性？

支撑这些决策选择的底层逻辑，就是Policy。

LLM Agent的Policy并非由单一因素决定，会受到多重条件影响：模型训练阶段形成的行为习惯、系统提示词约束、工具描述话术、人为设定规则、记忆存储系统、Harness执行逻辑，甚至外部的评估与反馈机制。

这里着重强调一点：Policy不等同于Agent本身。Agent是落地执行任务的完整系统，Policy是这套系统对外呈现出的行为模式。哪怕是同一套Agent系统，只要更换提示词、调整约束规则，对应的Policy也会发生彻底改变。

五、Tool、Skill、Sub-agent：基础动作、复用套路、任务分工

这三个概念是业内混用最严重的，很多人误以为三者大同小异，实际上它们分属三个完全不同的能力层级。

Tool：Agent的执行双手

Tool是最基础的能力单元，指代Agent能够调用的所有外部功能。

我们常见的Tool包括：搜索引擎、各类第三方API、数据库查询功能、文件操作系统、代码解释器、浏览器自动化控件、计算器、图像生成工具等。

Tool具备两个鲜明特征：大多为单次独立调用，输入输出的格式和结果清晰明确；模型仅负责生成调用指令，真正完成调用动作的依旧是Harness。

所以直白来讲，Tool就是Agent的双手：模型下达调用指令，Harness操控工具完成实际操作。

Skill：Agent的专属执行套路

Skill不等于单一操作动作，而是针对某一类固定任务，沉淀固化下来的成套执行方法。

举几个实际场景：排查程序bug、完成批量数据清洗、撰写行业调研摘要、制作竞品分析报告、开展代码审查。

这类任务没办法靠单次工具调用完成，需要搭配固定执行步骤、明确判断标准、组合多种工具，再结合过往经验形成标准化处理模式，配套专属输出模板，整套内容，就是Skill。

同时Skill支持重复复用。遇到同类任务时，Agent不需要从零开始规划执行方案，直接调用对应的Skill即可。

如果继续沿用之前的比喻：Tool是Agent的双手，那Skill就是Agent日积月累练就的做事套路。

Sub-agent：独立承接子任务的执行单元

Sub-agent的能力层级高于Skill，它不是一套静态的执行方法，而是一个能够独立运转的小型Agent。

它可以自主解析主Agent分配的子任务、拆解执行步骤、按需调用各类工具、处理执行过程中的突发问题，任务完成后，统一将结果反馈给主Agent。

给大家举个典型应用场景：主Agent需要制作一份完整的行业分析报告，它会直接拆分整体任务，分别分配给资料搜集Sub-agent、数据整理Sub-agent、观点提炼Sub-agent、初稿撰写Sub-agent、审校优化Sub-agent。

各个子Agent互不干扰、独立运行，最终由主Agent整合所有子任务成果，输出完整报告。

六、Rules与Hooks：划定行为边界，实现灵活管控

具备自主执行任务、调用工具的能力后，Agent看似已经无所不能。但在实际生产落地场景中，无任何约束、无法人工干预的Agent，反而存在极大的安全隐患。

这就需要用到两个偏向落地治理的核心概念：Rules 和 Hooks。

Rules：为Agent划定硬性行为边界

Rules是人为制定、Agent必须严格遵守的显性规则。

规则覆盖范围十分全面：明确可调用与禁止调用的工具类型、划定输出内容的违禁红线、高危操作是否需要用户授权、信息存疑时的处理方案、任务执行失败后是直接终止还是自动重试等等。

Rules最大的价值，是让Agent的所有行为变得可预判。在测试环境中，无规则约束的Agent或许表现亮眼，但投入生产环境后，大概率会出现各种意料之外的问题。

而Rules能够搭建安全防护边界，保障业务流程统一规范，一旦出现故障，也能快速追溯问题根源。

Hooks：在关键节点嵌入自定义逻辑

如果说Rules是强制规定Agent“必须怎么做”，那Hooks的作用，就是在任务执行的关键节点，嵌入额外的自定义处理逻辑。

Hooks一般挂载在这些核心节点：模型调用前后、工具调用前后、上下文更新前后、内容最终输出前、程序出现异常时。

依托Hooks，我们可以实现很多拓展功能：运行日志记录、操作权限校验、输出内容审核、调用成本统计、接口流量限流、清洗工具返回的无效数据、触发任务失败重试、发起人工审核确认、自动评估任务完成质量等。

简单总结：想新增权限校验？挂载一个Hook；想统计工具调用成本？挂载一个Hook；想过滤违规输出内容？依旧依靠Hook实现。

因此，Rules帮Agent划定安全边界，Hooks让Agent具备可观测、可干预、可拓展的工程化属性。

二者相辅相成，共同组成Agent系统的治理层，决定一个Agent能否安全、稳定、长期落地在正式生产环境中。

七、AI训练相关核心词：Environment、Rollout、Reward、Trainer

前面拆解的所有概念，都围绕“如何搭建可用的Agent”展开。如果大家还想深入了解“如何持续优化、升级Agent能力”，就需要接触一套源自强化学习体系的专属术语，我简单通俗讲解一下，新手可以先跳过，后续用到再回看即可。

Environment：Agent的交互运行载体

Environment是Agent执行各类动作、接收外部反馈的载体环境。

它的形式并不固定，可以是浏览器、本地文件系统、代码仓库、数据库、游戏场景、模拟任务空间，也可以是企业内部专属的业务系统。Agent在环境内执行操作，环境同步更新状态，并返回对应的执行结果。

Rollout：单次完整任务的执行轨迹

Rollout指代Agent从接收任务到任务结束的完整执行全过程，包含全程的上下文数据、所有决策动作、工具调用记录、每一步的执行结果，以及最终的任务完成状态。

大家可以把Rollout理解成一段完整的运行录像，完整记录Agent的全部行为，后续可用于问题复盘和模型迭代训练。

Reward：针对执行结果的评分反馈

Reward就是给单次Rollout执行轨迹的综合评分，直白告诉系统：本次任务完成质量如何，哪些操作值得保留，哪些行为需要优化摒弃。

Reward的评分来源多种多样：测试用例通过率、人工主观评价、自动化规则评分、用户满意度反馈、整体任务完成率等等。

Trainer：驱动Agent迭代升级的工具

Trainer的核心工作，是批量收集海量Rollout执行轨迹，结合对应的Reward评分，甄别优质行为与劣质行为，进而更新模型权重、优化行为策略，让Agent在不断试错的过程中，持续迭代变强。

简单区分：搭建Agent，解决的是Agent能不能正常运行的问题；训练Agent，解决的是Agent能不能越用越强的问题。两件事同等重要，但底层逻辑完全不同。

八、串联所有概念，理清整体逻辑

讲到这里，我帮大家把所有概念串联起来，大家可以结合配图，在脑海里搭建完整的结构框架，不用死记硬背：

Model处于整套系统的最中心；Harness负责驱动整体执行流程；Context Engineering统筹全流程信息；Rules和Hooks负责整体治理；Tool、Skill、Sub-agent对应三个层级的执行能力；Policy则是整套系统最终呈现出的行为模式。

九、写在最后：跳出模型思维，建立系统思维

绝大多数新手入门Agent时，都会陷入同一个误区：要么把Agent当成性能更强的大模型，要么单纯理解成会调用工具的聊天机器人。

这个认知不算错误，但会带来致命局限：大家会一直用“模型思维”，去评判一个Agent的综合实力。

实际上，Agent的好坏，从来不是单一模型就能决定的。

Context Engineering的配置质量、Harness的运行稳定性、Rules的合理性、Hooks的节点覆盖度、Skill的沉淀完善度，多个维度共同决定了Agent能否稳定、高效地完成完整目标。

跳出单一的模型思维，建立完整的系统思维后，你再去分析市面上各类Agent产品、开发框架，就能看懂以往被忽略的底层设计逻辑。

AI Agent的核心本质，从来不是优化模型单次问答的答案质量，而是依托工具、规则与工程系统，辅助大模型自主拆解目标、稳步推进流程，最终落地完整复杂任务。