简介：本文从AI Agent领域常见的概念混淆出发，系统对比Model、Tool、Skill、Rules、Hooks与Harness之间的区别与联系。通过架构分层、职责边界、调用关系与选型建议四个维度，帮助开发者准确理解Agent系统各组成部分的定位，避免因术语混用导致的设计偏差与沟通成本。
最近两年，“AI Agent”这个词的出现频率越来越高。做模型的人在讲，做产品的人在讲，做应用和工程的人也在讲。但问题是，同样是“Agent”这个词，大家说的未必是同一件事。有人把“会调用工具的大模型”叫Agent，有人把“驱动模型执行任务的整套系统”叫Agent，还有人把“负责某个子任务的小模块”叫Agent。这三种用法同时存在于技术文章、产品文档和会议分享中，但它们描述的其实是三个完全不同的抽象层级。
如果你刚刚开始接触这个方向，阅读的资料越多，困惑往往越深。原因不在于资料本身匮乏，而在于社区对基础术语没有形成统一对齐。每个框架、每个平台都在用自己的方式定义“Tool”“Skill”“Rules”“Hooks”“Harness”这些概念，相同词汇在不同语境下可能指向完全不同的组件。
本文尝试做一件事：将AI Agent体系中的核心概念进行一次系统性梳理与对比，明确Model、Tool、Skill、Rules、Hooks、Harness各自的职责边界、调用关系和使用场景。梳理完成之后，再去看Agent产品、Agent框架或相关论文，就不容易被术语表面含义带偏。
在展开细节之前，需要先确立一个基本判断：
AI Agent是一个以大模型为核心，能够调用外部能力、接收环境反馈，并以持续执行方式完成目标的系统。
这个定义中，最关键的不是“大模型”，也不是“调用工具”，而是“持续执行”。普通的聊天模式遵循“一次提问、一次回答”的交互逻辑。用户输入一条消息，模型返回一条回复，交互轮次即告结束。即便后续对话有上下文延续，模型本身也不会主动推进任务状态的变化。
Agent的工作方式与此有本质区别。当用户给出一个目标——例如“收集近三个月某行业的核心动态并整理成摘要”——Agent不会直接生成一段文字作为最终结果，而是进入一个分步推进的执行循环：决定获取信息的途径，执行检索或调用，读取返回结果，判断是否满足目标要求，如不满足则继续补充操作，直到任务收敛。
这种“目标定义—计划生成—动作执行—结果观察—计划修正”的循环，是Agent区别于普通对话模型的核心特征，也正是Harness、Hooks、Skill等概念产生的根源：仅靠模型本身无法完成这一循环，必须有一套外围系统来承载状态管理、动作编排和反馈处理。
Model指大语言模型本身，是Agent系统的推理引擎。它负责理解用户意图、生成执行计划、对中间结果进行语义判断，并产出最终回复。在层级上，Model只处理“思考”与“生成”，不直接操作外部资源。
模型层的边界很清晰：它不维护任务状态，不触发定时动作，不感知外部事件。模型的能力上限决定了Agent整体的理解与推理上限，但模型本身不等同于Agent。
Tool是模型与外部世界交互的基本单元。一次搜索调用、一次数据库查询、一次文件读写、一次通知推送，都可以封装为一个Tool。Tool的粒度通常较细，一个Tool完成一个相对原子的动作。
在Agent架构中，Tool的定义包含几个必要部分：工具名称、用途描述、参数schema、执行逻辑。模型通过Function Calling或类似机制发起调用请求，由Agent系统路由到具体实现。Tool的调用结果会回传给模型，成为后续推理的新上下文。
需要特别区分的是：Tool是“能力原子”，它本身不理解任务目标，也不知道何时被调用。调用决策权在模型，执行调度权在Agent系统。
Skill是比Tool更高一层的抽象。一个Skill通常由多个Tool调用、条件分支和上下文参数组合而成，承载一个相对完整的子能力。例如，“信息搜集与摘要”这个Skill可能包含搜索工具调用、结果过滤规则、多轮补充查询逻辑和摘要生成模板。
Skill与Tool的本质差异在于：Skill包含“流程知识”——它不仅定义了能做什么，还定义了在什么条件下按什么顺序、满足什么条件才做。一个Skill可以被复用在不同的Agent任务中，降低重复编排成本。
从工程实践看，Skill通常以声明式配置或脚本化流程的形式存在，Agent系统在执行时将其展开为具体的Tool调用序列。
Rules是Agent系统的约束条件，用于限定模型与工具的行为边界。规则可以是硬性的（如禁止调用特定工具、输出格式必须满足某schema），也可以是软性的（如优先使用缓存结果、在不确定时倾向于向用户确认）。
Rules的作用对象不是单一组件，而是整个执行链路。它可以约束模型的输出格式，可以约束工具的调用权限，也可以约束Hooks的触发条件。在多层Agent架构中，不同层级可以定义不同优先级的Rules，形成策略层级。
Rules与Skill的边界有时容易模糊。二者区别在于：Skill描述“怎么做”，Rules描述“什么不能做”或“在什么条件下必须怎么做”。
Hooks是Agent执行流程中的拦截点。它们不承载业务逻辑本身，而是在特定生命周期节点触发额外的检查、记录或修改操作。常见的Hooks插入点包括：模型调用前、模型调用后、Tool执行前、Tool执行后、任务启动时、任务终结时。
Hooks的典型用途包括：在模型输出后自动校验格式合规性；在Tool调用前注入当前用户权限上下文；在任务结束时记录完整执行轨迹用于审计；在模型产生低置信度输出时触发人工确认流程。
Hooks与Rules的关联紧密但职责不同。Rules定义策略内容，Hooks提供策略生效的执行机制。一个Rule可能需要多个Hooks来落地，一个Hook也可能执行多条Rule的检查逻辑。
Harness是承载以上所有组件的运行时环境，也是Agent系统的“骨架”。它负责维护任务状态、调度模型与Tool之间的消息循环、管理多轮执行上下文、处理超时与异常、连接各类Hooks并执行Rules校验。
Harness可以理解为“Agent的执行操作系统”。它不决定“想什么”（模型的事），也不决定“具体做什么”（Tool和Skill的事），而是决定“以什么节奏、什么顺序、什么约束完成整个循环”。
在不同工程实现中，Harness的复杂度差异极大。简单场景下，一个Harness可能只是几十行的循环控制逻辑；复杂企业级场景下，Harness可能包含状态持久化、分布式任务队列、多Agent调度、人工介入工作流和完整的可观测性支持。
下表从六个维度对上述核心概念进行对比：
| 维度 | Model | Tool | Skill | Rules | Hooks | Harness |
|---|---|---|---|---|---|---|
| 核心职责 | 理解与生成 | 执行单步动作 | 组合子流程 | 约束行为边界 | 拦截生命周期节点 | 编排完整任务循环 |
| 抽象层级 | 推理底座 | 能力原子 | 流程模板 | 策略约束 | 扩展机制 | 运行时框架 |
| 是否感知任务目标 | 是 | 否 | 部分感知 | 否 | 否 | 是 |
| 是否直接操作外部资源 | 否 | 是 | 通过Tool间接操作 | 否 | 否 | 否 |
| 可复用范围 | 跨场景通用 | 单能力复用 | 跨任务复用 | 跨任务复用 | 跨任务复用 | 场景级复用 |
| 典型依赖关系 | 被Harness调用 | 被Skill或模型调用 | 依赖Tool | 被Harness和Hooks引用 | 注册到Harness | 整合所有组件 |
从架构分层视角看，Harness处于最外层，Model处于最内层。Tool和Skill构成纵向能力轴，Rules和Hooks构成横向控制轴。这个“内外分层、纵向能力、横向约束”的结构，是理解Agent系统的基本框架。
Tool是原子操作，Skill是复合流程。当某个能力可以被一句话描述为“一个动作”时，它适合封装为Tool；当描述中必然包含“先—然后—再—如果—则”等流程语义时，它更适合定义为Skill。
混淆二者的后果是架构边界不清：将复杂流程硬塞进单个Tool会导致参数爆炸、逻辑不可维护；将简单动作过度封装为Skill则增加不必要的编排开销。
Rules回答“什么必须遵守”，Hooks回答“在什么时刻执行这些检查”。一个没有Hooks承接的Rule只是静态文档；一个没有Rules支撑的Hook容易退化为零散的补丁逻辑。
在工程实践中，建议先定义清晰的Rules集合，再选择合适的生命周期节点用Hooks挂载执行。
Agent是业务解决方案，Harness是承载解决方案的工程骨架。一个Harness可以支撑多种不同类型的Agent任务；一个Agent任务也可以运行在不同Harness实现之上。将“任务本身”与“运行任务的框架”混为一谈，是设计时最常见的概念错误。
在此场景下，团队重心是验证“模型+工具”是否能够完成目标任务。建议从简单的Harness实现开始，直接串联Model和少量Tool，暂不引入复杂Skill体系和重型Rules配置。Hooks仅保留最必要的错误捕获与日志记录。
当原型验证通过，需要将Agent能力集成到生产系统时，Harness的健壮性成为首要关注点。需要引入状态持久化、超时控制、重试策略和结果校验Hooks。Rules层面至少需要覆盖权限校验和输出格式约束。Skill的拆分以可测试性和可监控性为准则。
多Agent场景下，单一Harness的复杂度急剧上升。此时需要明确每个Agent的Skill边界，通过Rules定义Agent之间的通信协议与优先级，利用Hooks在跨Agent消息传递时进行一致性校验。Harness可能需要支持分布式调度和部分异步执行能力。
如果目标是构建一个可被多个业务方复用的Agent平台，则Harness、Rules和Hooks的设计需要优先考虑隔离性与可扩展性。不同租户的Rules集合需要隔离管理，Hooks需要允许按租户或按场景注册，Skill和Tool需支持分级发布与版本管理。Model层也需考虑多模型路由与降级策略。
如果团队已有初步的Agent实现，正在向更清晰的架构迁移，以下问题需要提前评估：
关于Tool与Skill的拆分：迁移时不要一次性将所有Tool强行组合为Skill。建议先识别高频复用的工具调用序列，优先将调用次数多且业务语义完整的流程抽象为Skill。对于仍在演化中的流程，可保持Tool级调用灵活调整。
关于Rules的落地顺序：先落地影响安全与合规的硬性Rules（如权限边界、输出格式约束），再逐步补充体验优化类软性Rules。过多软性Rules会显著增加调试难度。
关于Hooks的维护成本：每一个Hooks都增加了执行链路的认知负担。建议对Hooks数量设置上限，并定期检视每个Hook的实际触发频率和必要性。低频但必要的Hook（如安全审计）可通过日志旁路方式实现，避免阻塞主链路。
关于Harness的替换风险：Harness承载了任务状态和执行轨迹，替换Harness意味着需要完整迁移运行中的任务上下文。如果原有实现将状态存储在Harness内部而非外部存储，迁移风险会成倍增加。建议在初期就将任务状态外置化，为未来可能的Harness升级留出空间。
Model、Tool、Skill、Rules、Hooks、Harness这六个概念，构成了理解AI Agent系统的基本词汇表。它们之间不是简单的平级关系，而是分层协作关系：Model提供推理能力，Tool提供操作能力，Skill组合操作形成流程能力，Rules定义约束边界，Hooks在生命周期节点上执行约束与扩展逻辑，Harness将以上所有要素编排成一个可持续运行的执行循环。
理解这些概念之间的区别与联系，不是为了制造更多术语壁垒，而是为了在架构设计、技术选型和团队协作中建立一致的沟通基础。当讨论“Agent应该如何设计”时，需要先明确讨论的是哪一层的问题——是模型能力不足，还是Tool覆盖不全，是Skill编排不合理，还是Harness的状态管理存在缺陷。只有在正确的层级上定位问题，才能找到正确的解决路径。