简介：本文系统梳理AI Agent中Model、Tool、Skill、Rules、Hooks、Harness六大核心概念的定义、职责与相互关系，帮助读者区分"模型能力"与"系统能力"的边界。通过对比分析各层的功能定位、适用场景与选型依据，读者将掌握Agent系统的分层设计思路，避免术语混淆，并为技术选型与架构决策提供清晰参考。
近两年，”AI Agent”一词的使用频率急剧上升。做模型的团队在讲，做产品的团队在讲，做应用与工程的团队也在讲。但同样是”Agent”这个词，不同人所指的对象未必是同一件事：有人把”会调用工具的大模型”称为 Agent，有人把”驱动模型执行任务的整套系统”称为 Agent，还有人把”负责某个子任务的小模块”称为 Agent。这三种用法都真实存在，却描述了三个完全不同的层次。
对于刚接触这个方向的读者而言，资料越多反而越容易迷失——术语不断堆叠，而基础定义从未对齐。本文的目标是做一次概念层面的”对齐”：把 Model、Tool、Skill、Rules、Hooks、Harness 这六个词分别指什么、各自解决什么问题、彼此如何协作讲清楚，并在对比中给出选型与使用边界上的判断依据。
需要先明确一个贯穿全文的核心定义：AI Agent 不是模型，而是系统。它以大模型为核心，能够调用工具、接收反馈，并持续完成目标任务。这句话中最重要的不是”大模型”，也不是”调用工具”，而是”持续完成任务”。普通聊天模型是”你问一句，我答一句”，一轮结束即终止；Agent 则是目标驱动、分步推进、持续执行——你给它一个目标，它会先决定用什么方式获取信息，读取结果，判断是否还需补充，再执行下一步，观察，直到任务真正完成。这种工作方式的差异，决定了 Agent 必须具备模型之外的多层结构。
在展开对比之前，先逐一给出各概念的基本定义与职责边界。
Model（模型） 是整个系统的推理核心，负责理解输入、生成决策与文本。它提供的是”认知能力”，但不具备持久执行、外部交互与状态管理能力。模型是 Agent 的”大脑”，但大脑 alone 不构成一个完整的执行体。
Tool（工具） 是模型可以调用的外部能力接口，例如检索、计算、读写数据、调用业务 API 等。工具解决的是”模型无法直接完成的操作”这一问题，把模型的意图转化为对外部世界的实际动作。工具的关键属性是：有明确的输入输出契约、可被结构化调用、执行结果可被模型理解。
Skill（技能） 是对一类任务能力的封装，通常由”提示策略 + 工具组合 + 执行流程”构成。与单一 Tool 相比，Skill 更偏向”完成某类任务的成套方法”，例如”检索并总结””多步数据核对”。Tool 是原子能力，Skill 是组合能力，二者是粒度差异而非层级对立。
Rules（规则） 是对 Agent 行为的约束与引导，包括但不限于：可调用工具的白名单、输出格式要求、安全与合规边界、任务优先级策略、禁止行为清单。Rules 解决的是”能力有了，但如何确保行为可控、可预期”的问题，属于治理层。
Hooks（钩子） 是系统在执行流程的关键节点插入的拦截与扩展机制，例如在工具调用前做参数校验、在模型输出后做内容过滤、在任务阶段切换时做日志埋点或人工确认。Hooks 解决的是”流程可干预、可观测、可扩展”的问题，属于控制流层面。
Harness（运行框架/ harness） 是承载上述所有要素的运行环境与调度系统，负责会话与状态管理、任务编排、工具注册与路由、错误重试、上下文管理、权限与审计等。Harness 是把 Model、Tool、Skill、Rules、Hooks 组装成一个可持续运行系统的”骨架”。
尽管定位不同，这六个概念在目标层面高度一致：都是为了让系统从”单轮问答”走向”目标驱动的多步执行”。具体表现为三点共同逻辑。
其一，都以模型推理为决策起点。无论是工具选择、技能触发、规则判定还是钩子拦截，最终的判断依据大多来自模型的输出或模型与系统状态的结合。
其二，都强调”契约化”。Tool 有输入输出契约，Skill 有流程契约，Rules 有行为契约，Hooks 有拦截点契约，Harness 有调度契约。契约化是系统可组合、可维护的前提。
其三，都服务于可控性与可扩展性。单独一个模型无法保证行为稳定，也无法接入真实业务；正是这些层次的存在，才让 Agent 从演示走向生产。
Model 处于系统最内层，是纯推理组件，边界清晰但能力有限。Tool 处于系统与外部世界的交界面，是”出口”。Skill 位于模型与工具之间，承担编排职责。Rules 与 Hooks 横切于整个执行链路，前者偏静态约束，后者偏动态干预。Harness 则是包裹全部要素的运行时容器，决定了系统的部署形态、资源管理与生命周期。
一个常见的误区是把 Harness 等同于”框架代码”。实际上，Harness 更接近”运行时 + 调度器 + 治理层”的集合体，它决定了 Agent 能否支持多轮会话、并发任务、失败重试与状态持久化。
Model 决定推理质量上限；Tool 决定可触达的外部能力范围；Skill 决定复杂任务的完成度；Rules 决定行为的合规性与一致性；Hooks 决定流程的可干预程度；Harness 决定系统的整体承载能力。换句话说，模型强不等于 Agent 强——若 Tool 覆盖不足，模型再强也无法获取实时信息；若 Harness 孱弱，再好的 Skill 也无法稳定运行。
接入 Model 通常只需接口适配；接入 Tool 需要定义清晰的参数结构与返回格式；引入 Skill 需要梳理任务流程并做提示工程；配置 Rules 多为声明式策略；植入 Hooks 需要在执行链路上预留拦截点；而选择或自建 Harness 则是架构级决策，改造量最大、影响面最广。实践中，改造成本从低到高大致为：Rules < Tool < Hooks < Skill < Harness < Model 替换（模型替换因涉及效果回归，往往成本被低估）。
Rules 与 Hooks 是安全治理的主要抓手：Rules 负责”事前约束”，如工具白名单、数据访问范围；Hooks 负责”事中拦截”，如敏感信息过滤、人工确认节点。Harness 则负责”事后审计”，如日志留存、调用链路追踪。Model 本身不提供合规保证，Tool 的权限控制需在 Harness 层统一管理。因此，安全能力不是单点能力，而是多层协同的结果。
Model 的运维主要是版本与效果监控；Tool 的运维涉及接口可用性与鉴权；Skill 的运维涉及流程变更与效果回归；Rules 与 Hooks 的运维涉及策略更新与拦截点验证；Harness 的运维复杂度最高，涵盖容量规划、故障恢复、版本升级与多租户隔离。团队运维能力有限时，应优先选择托管化程度更高的 Harness 形态，而非自建全套调度。
成本可分为资源成本、人力成本与迁移成本。Model 以推理资源成本为主；Tool 与 Skill 以开发与维护人力为主；Rules 与 Hooks 以策略维护人力为主；Harness 则同时涉及资源与人力，且迁移成本最高——更换 Harness 往往意味着重写调度逻辑与状态管理。选型时应把”长期维护成本”纳入评估，而非仅看初期接入成本。
| 维度 | Model | Tool | Skill | Rules | Hooks | Harness |
|---|---|---|---|---|---|---|
| 定位 | 推理核心 | 原子外部能力 | 组合任务能力 | 行为约束 | 流程拦截扩展 | 运行时与调度 |
| 系统层级 | 最内层 | 交界层 | 编排层 | 治理层 | 控制流层 | 容器层 |
| 主要职责 | 理解与决策 | 执行具体动作 | 完成一类任务 | 保证行为可控 | 保证流程可干预 | 承载与调度全链路 |
| 接入成本 | 低 | 中 | 中高 | 低 | 中 | 高 |
| 安全作用 | 无直接保证 | 需权限管控 | 依赖规则约束 | 事前约束 | 事中拦截 | 事后审计 |
| 运维复杂度 | 低 | 中 | 中 | 低 | 中 | 高 |
| 迁移成本 | 中（需效果回归） | 中 | 高 | 低 | 中 | 最高 |
当需求是”快速验证一个想法”时，重点应放在 Model 与少量 Tool 上，Harness 可采用轻量方案，Rules 与 Hooks 可先简化。
当需求是”在受控环境下完成多步业务任务”时，Skill 与 Rules 的权重上升，需要明确任务流程与行为边界，Hooks 用于关键节点的人工确认或内容过滤。
当需求是”面向多用户、多任务的生产级系统”时，Harness 成为核心决策点，需重点评估其状态管理、并发调度、权限隔离与审计能力，同时把 Rules 与 Hooks 作为治理基础设施纳入设计。
当需求是”高合规场景”时，应优先强化 Rules 与 Hooks 的多层拦截，并确保 Harness 具备完整的调用链路日志与审计能力，而非仅依赖模型自身的输出约束。
选型不应追求”最强”，而应追求”匹配”。可参考以下条件化思路：
涉及方案切换时，需要重点评估四类风险。其一是接口兼容性：Tool 的输入输出契约若发生变化，Skill 与 Hooks 的拦截逻辑需同步调整。其二是状态管理：更换 Harness 时，会话状态与任务状态的持久化格式往往不兼容，需设计迁移方案。其三是权限与审计：新环境下身份认证与日志链路需重新验证，避免出现治理盲区。其四是效果回归：Model 或 Skill 变更后，应建立回归测试集，覆盖典型任务与边界场景。
使用边界方面，需明确：Agent 不适合替代确定性极强的批处理流程；Rules 无法覆盖所有异常，Hooks 也不应被滥用为业务逻辑的主要承载点；Harness 的能力再强，也无法弥补 Tool 契约设计不清带来的问题。
回到对比主题：Model、Tool、Skill、Rules、Hooks、Harness 并非互相替代的关系，而是同一系统中不同职责的六个层次。Model 提供认知，Tool 提供触达，Skill 提供组合方法，Rules 提供行为边界，Hooks 提供流程干预，Harness 提供运行承载。理解它们的差异，本质上是理解”能力”与”治理”、”原子”与”组合”、”静态约束”与”动态干预”之间的分工。
选型时的核心判断思路可以归纳为三句话：先明确任务的风险等级，再确定治理层（Rules/Hooks）的投入；再评估任务的复杂程度，决定 Skill 的粒度；最后根据团队运维能力与长期成本，选择 Harness 的形态。把这六层对齐之后，再去看各类 Agent 产品、框架与论文，就不容易被术语绕进去，也能更清楚地判断某一方案到底补的是哪一层的能力。