agent-model-tool-skill-rules-hooks-harness-">一文读懂 AI Agent：Model、Tool、Skill、Rules、Hooks 与 Harness 的对比与关系拆解

一、对比背景：为什么这些概念容易混淆

“AI Agent”这个词近年来出现频率极高，做模型的、做产品的、做工程的都在使用。但同样一个词，不同人所指的对象并不一致：有人把“会调用工具的大模型”叫 Agent，有人把“驱动模型执行任务的整套系统”叫 Agent，还有人把“负责某个子任务的小模块”也叫 Agent。这三种用法都真实存在，却描述了三个层次完全不同的东西。

造成混乱的根源在于：AI Agent 并非单一技术，而是一套分层协作的系统。Model、Tool、Skill、Rules、Hooks、Harness 分别处于这套系统的不同位置，承担不同职责。本文的核心对比对象，就是这六个概念——它们各自的定义是什么、边界在哪里、彼此如何协作，以及在构建 Agent 系统时应该如何取舍与组合。

先把最重要的结论说清楚：AI Agent 不是模型，而是系统。它以大模型为核心，能够调用工具、接收反馈，并持续完成任务。这句话的关键不在“大模型”，也不在“调用工具”，而在“持续完成任务”。普通聊天模型是“你问一句，我答一句”，一轮结束即终止；Agent 则是目标驱动、分步推进、持续执行——给它一个目标，它会先决定用什么方式执行，执行后读结果，根据结果判断还需补充什么，再做一步、再观察，直到任务真正完成。

理解了这个层次差异，才能理解下面六个概念为何不能混为一谈。

二、对象定义：六个概念分别是什么

Model（模型）：Agent 的推理内核。它负责理解目标、生成决策、判断下一步动作。模型本身不具备执行能力，它输出的是“意图”或“计划”，而不是“结果”。模型的推理质量、上下文长度、指令遵循能力，直接决定 Agent 的上限。

Tool（工具）：Agent 与外部世界交互的接口。搜索、文件读写、代码执行、网页操作、数据查询等，都是工具的具体形态。工具是“能力的外延”——模型本身不能读文件，但通过工具可以；模型本身不能执行代码，但通过工具可以。工具的关键属性是可描述性（模型能理解它做什么）与可调用性（系统能安全执行它）。

Skill（技能）：面向特定任务的能力封装。一个 Skill 通常由“若干 Tool 的组合 + 固定的执行逻辑 + 输入输出约定”构成。Tool 是原子能力，Skill 是组合能力。例如“搜集行业动态并整理摘要”是一个 Skill，它内部可能调用搜索工具、读取工具、文本处理工具。Skill 的价值在于把可复用的任务模式沉淀下来，避免每次都由模型从零规划。

Rules（规则）：约束 Agent 行为的边界条件。包括但不限于：哪些工具允许调用、哪些操作需要审批、输出必须符合什么格式、什么情况下必须终止、敏感数据如何处理。Rules 是“护栏”，它不提升 Agent 的能力上限，但决定 Agent 的行为下限与安全边界。

Hooks（钩子）：在 Agent 执行流程的关键节点插入的拦截与扩展机制。典型节点包括：模型调用前、工具调用前、工具返回后、任务完成前。Hooks 与 Rules 的区别在于：Rules 是“静态约束”，描述“允许/不允许”；Hooks 是“动态介入”，描述“在某个时刻执行某段逻辑”，可用于日志记录、参数改写、结果校验、人工审批插入等。

Harness（运行框架/ harness）：承载上述所有组件的运行时系统。它负责调度模型调用、管理工具注册与执行、加载 Skill、注入 Rules、触发 Hooks、维护任务状态与上下文、处理错误与重试。Harness 是“骨架”，Model、Tool、Skill、Rules、Hooks 都是挂载其上的“器官”。同一个模型，换一个 Harness，Agent 的行为表现可能完全不同。

三、相同点分析：它们共同服务于“持续完成任务”

尽管层次不同，这六个概念在目标上高度一致：

• 共同服务于目标驱动执行：所有组件都围绕“给定目标、分步推进、直至完成”这一工作方式展开，而非单轮问答。
• 共同构成反馈闭环：Model 决策、Tool 执行、结果回传、Model 再判断，Rules 与 Hooks 在环中做约束与介入，Harness 维护整个闭环的运转。
• 共同强调可组合性：Tool 可注册、Skill 可复用、Rules 可配置、Hooks 可插拔，都是为了在不同任务间灵活组合。
• 共同依赖上下文管理：六者都需要与任务状态、历史结果、中间产物打交道，上下文如何组织是共同的工程难点。

正因为目标一致，才更容易被混为一谈——它们看起来都在“让 Agent 干活”，但干的活完全不同。

四、核心差异分析：从六个维度拆解

1. 技术定位与系统边界

Model 是推理组件，位于系统最内层，只负责“想”；Tool 是执行组件，位于系统边界，负责“做”；Skill 是组合层，位于二者之间，负责“按套路做”；Rules 与 Hooks 是横切关注点，贯穿整个流程；Harness 是容器，包裹全部。用一句话概括：Model 决定“能不能想明白”，Tool 决定“能不能做到”，Skill 决定“能不能稳定做好”，Rules 决定“能不能安全地做”，Hooks 决定“能不能在关键处干预”，Harness 决定“整套系统能不能跑起来”。

2. 功能能力覆盖范围

Model 覆盖理解、规划、判断；Tool 覆盖单点外部操作；Skill 覆盖端到端任务模式；Rules 覆盖权限、格式、终止条件等约束；Hooks 覆盖流程节点的拦截与扩展；Harness 覆盖调度、状态、错误处理、可观测性。能力覆盖范围从“点”（Tool）到“线”（Skill）到“面”（Harness），层次分明。

3. 接入与配置复杂度

Model 的接入主要是选型与提示工程；Tool 的接入需要定义描述、参数、执行逻辑与错误处理；Skill 的接入需要编排多个 Tool 并固化流程；Rules 的接入是策略配置；Hooks 的接入是代码级插桩；Harness 的接入则是整套运行时环境的搭建或选型。复杂度大致呈递增趋势：Tool < Rules < Hooks < Skill < Harness，Model 则取决于是否自建。

4. 安全与合规考量

Model 层面关注输出内容安全与提示注入风险；Tool 层面关注调用权限、参数校验、执行隔离；Skill 层面关注组合流程中的越权与副作用；Rules 层面本身就是安全策略的载体；Hooks 层面可用于审计埋点与人工审批插入；Harness 层面关注身份认证、租户隔离、操作审计与密钥管理。安全不是某一层的事，而是六层共同承担。

5. 运维与可观测性

Harness 是运维主战场：需要监控任务成功率、平均步数、工具调用失败率、模型延迟与成本；Hooks 是埋点与告警的天然插入点；Rules 的变更需要版本化管理；Skill 的复用需要注册与发现机制；Tool 需要健康检查与降级策略；Model 需要版本管理与灰度切换。

6. 成本结构

Model 成本主要来自推理调用量与上下文长度；Tool 成本来自外部资源调用与执行开销；Skill 成本来自开发与维护；Rules 与 Hooks 成本来自配置与代码维护；Harness 成本来自运行时资源与工程投入。成本优化的着力点不同：Model 靠压缩上下文与缓存，Tool 靠减少无效调用，Skill 靠复用，Harness 靠弹性与调度效率。

五、对比表格：关键差异一览

维度	Model	Tool	Skill	Rules	Hooks	Harness
系统定位	推理内核	执行接口	任务封装	行为约束	流程拦截	运行时容器
核心职责	理解与决策	单点外部操作	组合能力复用	允许/禁止边界	节点介入扩展	调度与状态管理
粒度	组件	原子	组合	策略	插桩点	系统
接入复杂度	中	低	中高	低	中	高
安全职责	输出安全	调用权限	流程越权	策略载体	审计审批	隔离与认证
运维重点	版本与成本	健康与降级	注册与复用	版本管理	埋点告警	可观测性
成本来源	推理量	外部调用	开发维护	配置维护	代码维护	资源与工程

六、典型场景选择：什么时候该关注哪个概念

场景一：任务简单、单轮可完成。此时无需完整 Harness，关注 Model 的指令遵循能力即可，Tool 按需少量接入。

场景二：需要调用外部能力但流程固定。优先沉淀 Skill，把 Tool 组合固化，减少对模型规划的依赖，提升稳定性。

场景三：多租户、有合规要求的企业应用。Rules 与 Hooks 是重点：用 Rules 定义权限与终止条件，用 Hooks 插入审计与人工审批，Harness 承担租户隔离。

场景四：任务复杂、步骤多、需长期运行。Harness 的调度能力、状态管理、错误重试成为瓶颈，Model 的规划能力与上下文管理同样关键。

场景五：快速验证想法。可先轻量 Harness + 通用 Tool + 强 Model，暂不沉淀 Skill，待模式稳定后再抽象。

七、选型建议：条件化的判断思路

• 若团队工程能力有限、希望快速上线，可优先选择托管化程度更高的 Harness，把调度与可观测性交给平台，自身聚焦 Tool 与 Skill 的设计。
• 若任务模式高度重复，应优先投入 Skill 的沉淀，而非反复依赖模型现场规划——前者稳定、可测试，后者灵活但波动大。
• 若安全合规是硬约束，Rules 与 Hooks 必须前置设计，不能事后补救；此时 Harness 是否支持细粒度拦截与审计至关重要。
• 若成本敏感，优先优化 Model 的上下文与 Tool 的调用次数，再考虑 Harness 的弹性调度。
• 若需要多 Agent 协作（把复杂任务拆给多个子模块），Harness 的任务编排与子模块隔离能力是选型关键，Skill 则作为子模块的能力单元复用。

不存在“哪个方案一定更好”。在高并发、长任务场景下更需要关注 Harness 的弹性与状态管理；在团队运维能力有限时，可优先考虑托管化程度更高的方案；在对行为可控性要求极高的场景，Rules 与 Hooks 的完备性比 Model 的聪明程度更重要。

八、迁移与使用注意事项

若从“单模型调用”迁移到“完整 Agent 系统”，需注意：接口层面，原有点对点调用需改为经 Harness 调度；权限层面，Tool 的调用权限需重新梳理，避免模型获得超出预期的执行能力；数据层面，上下文与中间产物的存储位置与生命周期需明确；稳定性层面，需为 Tool 失败、模型超时、Hooks 异常设计降级与重试；兼容性层面，Skill 的输入输出约定应版本化，避免流程固化后难以调整；运维层面，需提前规划日志、指标与追踪，否则长链路任务的问题定位成本会显著上升。

示意性伪代码（通用表达，非特定平台接口）：

harness.register(tool_search)
harness.register(tool_read_file)
harness.load(skill_collect_and_summarize)
harness.apply_rules(policy_least_privilege)
harness.on("before_tool_call", audit_hook)
harness.on("after_tool_call", validate_hook)
result = harness.run(goal="搜集行业动态并整理摘要")

九、总结

回到对比主题：Model 是“想”，Tool 是“做”，Skill 是“按套路做”，Rules 是“能做什么不能做什么”，Hooks 是“在哪儿插手”，Harness 是“让这一切跑起来的系统”。六者不是竞争关系，而是分层协作关系；混淆它们，会导致选型时把“模型能力不足”误判为“框架不行”，或把“约束缺失”误判为“模型不听话”。

清晰的认知框架是：先明确任务需要哪一层的能力，再判断瓶颈在 Model、Tool、Skill 还是 Harness，最后用 Rules 与 Hooks 补齐安全与可控性。按这个顺序思考，再看各类 Agent 产品、框架与论文，就不容易被术语绕进去。