最近两年，"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 的全部。

模型本身能做的事情是有边界的。它的本质是"文本进，文本出"——给它一段输入，它产生一段输出。它可以理解目标、读取上下文、按照规则做判断、生成下一步应该做什么的意图。但是，它说要调用工具，和真正执行这个调用，完全是两件事。模型不会真正点击网页，不会真正读取你电脑上的文件，不会真正向外部 API 发请求，也不会自动把一个任务循环跑完。

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

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

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

Agent 系统里有两层关键结构经常被一起叫成"Agent 框架"，但它们其实在做完全不同的事情：Scaffolding 管"怎么想"，Harness 管"怎么跑"。

Scaffolding（思考框架）关心的是模型在执行任务时的"思考结构"。它包括：任务怎么拆解、推理步骤怎么设计、模型扮演什么角色、输出要满足什么格式、工具怎么选、多轮执行的策略是什么。Scaffolding 更偏向于"软件"层面的设计——它影响的是模型如何理解任务、如何规划步骤、如何做出决策。

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

Harness 不关心模型"想什么"，它只关心"执行"。没有 Harness，模型只是在说"我想做什么"，但什么都不会真正发生。有一句话可以很好地概括这两者：真正的 Agent 能力，往往不是只靠模型涌现出来的，而是模型能力与 Harness 工程共同作用的结果。这也是为什么两个使用同一个模型的 Agent，表现可能差距很大——Harness 搭得好不好，直接决定了 Agent 能不能把模型的能力真正用出来。

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

Context Engineering（上下文工程）比 Prompt Engineering 宽得多。Prompt Engineering 关心的是"提示词怎么写"，Context Engineering 关心的是在整个任务执行过程中，模型在每一步到底应该看到什么信息。

这些信息包括：系统提示词、用户给的任务、历史对话、工具的说明文档、工具调用的返回结果、从知识库检索回来的内容、上传的文件、中间的推理状态、当前的任务进度……而且这不是一次性设置好就完事的。随着任务推进，Harness 要持续决定：哪些信息保留，哪些可以压缩，哪些应该丢弃，哪些需要重新注入。

Policy（策略）指的是 Agent 在给定情境下的行为方式——面对多个可能的下一步，它会如何选择。拿到任务之后，是先去搜索还是先尝试直接总结？不确定的时候，是继续追问用户还是自主推进？遇到多条路径，是保守地走最稳的那条还是尝试探索更多可能性？这些选择背后的逻辑，就是 Policy。

LLM Agent 的 Policy 受到很多因素影响：模型训练中学到的行为模式、系统提示词、工具的描述方式、规则约束、记忆系统、Harness 的执行逻辑，甚至外部的评估和反馈机制。有一点需要特别说清楚：Policy 不等于 Agent 本身。Agent 是那个在环境里真正采取行动的完整系统，Policy 是它表现出来的行为方式。同一个 Agent 系统，配置不同的提示词和规则，Policy 会完全不一样。

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

这三个词是 Agent 里被混用得最频繁的，它们对应的是三个完全不同的层次。

Tool（工具）——Agent 的"手"。Tool 是最基础的一层，指的是 Agent 能伸手够到的外部能力。常见的 Tool 包括搜索引擎、各种 API、数据库查询、文件系统操作、代码解释器、浏览器控制、计算器、图像生成工具。Tool 通常是单次调用，输入和输出比较明确，模型只负责表达"我要用这个工具"的意图，真正执行这个调用的是 Harness。

Skill（套路）——Agent 的"方法"。Skill 不是一个单独的动作，而是一套围绕某类任务沉淀下来的方法。比如排查一个 bug、做一次数据清洗、写一份市场调研摘要、生成竞品分析、完成一次代码审查。这些都不是一次工具调用能完成的，它们需要一组步骤、一套判断标准、特定的工具组合、经验积累下来的处理模式，以及相对固定的输出模板。Skill 是可以复用的——遇到这类任务，按照这套路子走。

Sub-agent（子智能体）——独立执行单元。Sub-agent 比 Skill 又更进一步。它不是一套方法，而是另一个可以独立运作的 Agent。它能自己理解分配给它的子任务，自己规划步骤，自己调用工具，自己处理中间结果，最后把结果返回给主 Agent。

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

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

一个没有约束、不可干预的 Agent 在实际部署中是危险的。这里就要说到两个很实用的概念：Rules 和 Hooks。

Rules（规则）——给 Agent 划清行为边界。Rules 是 Agent 必须遵守的显式规则：哪些工具可以调用，哪些不行；哪些内容绝对不能出现在输出里；哪些操作必须先得到用户确认才能执行；遇到不确定的信息时应该怎么处理；任务失败的时候是静默放弃还是允许重试。

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

Hooks（钩子）——在关键节点插入额外逻辑。如果说 Rules 是"规定 Agent 应该怎么做"，那么 Hooks 就是"在执行过程中，允许你在关键位置插入额外的处理逻辑"。Hooks 通常挂在这些节点上：模型调用前、模型调用后、工具调用前、工具调用后、上下文更新前、最终输出前、异常发生的时候。

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

Rules 让 Agent 有边界，Hooks 让 Agent 可扩展、可监管、可工程化。这两个概念合在一起，构成了 Agent 系统里的"治理层"——决定了一个 Agent 能不能真正安全、稳定地跑在生产环境里。

训练 Agent 的视角：Environment、Rollout、Reward、Trainer

前面讲的概念主要和"搭建一个 Agent"有关。如果你还关注"如何让 Agent 越来越强"，就会遇到另外一套词汇，来自强化学习的传统。

Environment（环境）是 Agent 执行动作、观察结果的场所。它可以是浏览器、文件系统、代码仓库、数据库、游戏环境、模拟的任务空间，或者企业内部的业务系统。

Rollout（执行轨迹）是 Agent 从任务开始到结束的完整记录——看到了什么上下文、做了哪些决策、调用了哪些工具、每一步拿到了什么结果、最终有没有完成任务。你可以把 Rollout 理解成一段"录像"。

Reward（奖励）是对这次执行结果的评价，告诉系统这次做得好不好。来源可以是测试用例是否通过、人工对结果的偏好评估、基于规则的自动评分、用户满意度、任务完成率等。

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