简介：很多开发者对AI Agent的理解停留在“会调用工具的大模型”层面，实际上Agent涉及模型、工具、技能与执行框架等多个层次的协同。本文从架构视角拆解Model、Tool、Skill与Harness四个核心概念，分析它们的职责边界、相互关系、关键差异与适用场景，帮助读者建立清晰的Agent技术认知，为后续设计、选型与落地智能体应用提供判断依据。
AI Agent 正在从概念验证走向工程落地。越来越多的团队开始构建能够自主规划、调用外部能力并持续完成任务的智能体系统。但在实践过程中，一个常见的问题是概念混用：有人把“模型”等同于“Agent”，有人把“工具”和“技能”混为一谈，还有人将“执行框架”与“模型能力”绑定在一起讨论。
这种混用会带来几个实际问题：
因此，有必要从技术架构的角度，对 Model、Tool、Skill 和 Harness 四个核心概念进行系统对比。它们共同构成了一个完整的 Agent 系统，但各自解决的是不同层面的问题。
Model 是 Agent 的“大脑”，通常指具备语言理解、推理和生成能力的大语言模型。它的核心职责可以概括为三件事：
需要强调的是，Model 本身是一个“文本进、文本出”的组件。它不直接执行文件读取、网页操作或代码运行，也不维护跨轮次的会话状态——这些都由外围系统承担。模型的优势在于泛化推理能力，而不是执行能力。
从工程角度看，模型的角色类似于传统软件系统中的“决策引擎”：它负责判断和规划，但不负责具体的 IO 操作和副作用执行。
Tool 是 Agent 能够触达的、具体可执行的外部能力单元。一个 Tool 通常具备三个特征：
Tool 的典型示例包括：
| 类别 | 示例 | 说明 |
|---|---|---|
| 数据获取 | 文件读取、数据库查询、API 请求 | 从外部系统拉取数据 |
| 数据处理 | 代码执行、格式转换、数据清洗 | 对数据进行变换或计算 |
| 外部操作 | 网页操作、消息发送、任务创建 | 在外部系统中产生副作用 |
| 检索类 | 文档检索、网页搜索 | 补充模型缺乏的知识或实时信息 |
Tool 的设计要点在于“原子性”和“可组合性”。一个设计良好的工具应该只做一件事，并且能够被多个不同的 Agent 流程复用。相反，如果一个工具内部混杂了多种职责，不仅会增加模型调用时出错的概率，也会让权限控制和错误处理变得更加复杂。
Skill 是在 Tool 之上的一层抽象，它将多个相关工具或操作步骤组合成一个面向特定任务的完整能力。如果说 Tool 是“螺丝刀”，那么 Skill 就是“组装一把椅子”的完整工序。
Skill 的核心价值体现在以下几个方面：
第一，降低模型规划负担。 当模型面对一个复杂任务时，如果每一步都需要从零开始选择工具并判断参数，不仅推理成本高，而且容易出错。Skill 将常见的操作序列封装起来，模型只需要识别“这是哪个技能”，然后按预定义流程执行即可。这类似于人类专家面对熟悉任务时的“肌肉记忆”。
第二，封装领域知识。 有些任务需要特定的执行顺序或业务规则，这些知识不一定存在于通用模型中。通过 Skill，团队可以将领域最佳实践固化下来。例如，“分析一份财务报表并生成摘要”这个技能，可能涉及文件读取、数据提取、指标计算和文本生成多个步骤，每一步都需要遵循特定规范。
第三，提供稳定可复用的任务单元。 Skill 可以在不同 Agent 之间共享，也可以在同一 Agent 的不同会话中反复调用。这种复用性带来了行为的一致性——用户不用每次都担心模型会“发挥不稳定”。
Skill 与 Tool 的关键区别在于：Tool 是“能做什么”，Skill 是“怎么做好一件事”。前者关注能力的有无，后者关注任务的完成质量和效率。
Harness 是概念中最容易被忽视、但实际上最关键的一层。它是围绕模型构建的执行框架，负责将 Model、Tool 和 Skill 串联起来，形成一个真正能够自主循环运转的系统。
Harness 的核心职责包括：
Harness 的存在解释了为什么“模型 ≠ Agent”。一个裸模型只能做单次文本生成，而 Harness 赋予了模型跨轮次执行的能力。它定义了 Agent 的“生命周期”：
用户输入 → 目标理解 → 规划 → 选择工具/技能 → 执行 → 观察结果 → 判断是否完成↑ |└──────────────── 否：继续迭代 ←───────────────┘↓ 是返回最终结果
这个循环是 Agent 区别于普通聊天机器人的根本所在。没有 Harness，模型只是一个回答问题的人；有了 Harness，模型才成为能够完成任务的执行者。
尽管职责不同，这四个概念之间存在一些共同的技术逻辑：
共同服务于任务完成目标。 无论是 Model 的推理、Tool 的执行、Skill 的封装还是 Harness 的调度，最终目的都是让系统能够从用户目标出发，自主完成一个需要多步骤协作的任务。它们不是孤立存在的组件，而是一个完整链条上的不同环节。
都强调结构化与契约化。 Model 需要输出结构化指令，Tool 需要定义清晰的输入输出契约，Skill 需要规范执行流程，Harness 需要管理状态机。这种对结构化和确定性的追求，是 Agent 从“不可控的模型输出”走向“可工程化的系统”的基础。
都面临可靠性挑战。 模型可能产生错误推理，工具可能返回异常结果，技能可能遇到边界情况，框架可能在长流程中丢失状态。系统的整体可靠性上限，取决于每一层的健壮性和层与层之间的容错设计。
Model 是纯计算组件，不产生副作用；Tool 负责产生副作用或获取外部数据；Skill 是纯逻辑编排，定义“做什么”和“按什么顺序做”；Harness 是运行时基础设施，负责“驱动整个系统跑起来”。这四者在架构上形成了清晰的层次：
| 层级 | 组件 | 依赖方向 | 是否产生副作用 |
|---|---|---|---|
| 决策层 | Model | 无（被 Harness 调用） | 否 |
| 编排层 | Skill | 依赖 Tool | 否（间接通过 Tool 产生） |
| 执行层 | Tool | 独立或依赖外部系统 | 是 |
| 框架层 | Harness | 依赖以上所有 | 是（管理状态和流程） |
这种分层带来的好处是各层可以独立演进。例如，替换模型时不需要修改工具定义；增加新工具时不需要改动执行框架；优化某个技能时不影响模型选型。
Model 的能力边界在于“知道但不一定能做”。它能理解复杂指令并生成合理的调用计划，但无法越过框架直接操作外部世界。模型的输出质量高度依赖提示词设计、上下文质量和工具描述的质量。
Tool 的能力边界在于“能做但不一定做对”。工具执行的结果可能受到参数错误、外部系统不稳定或数据格式不匹配的影响。Tool 层的设计重点是让契约尽可能清晰，减少模型调用时的歧义。
Skill 的能力边界在于“封装已知路径，但难以应对未知变化”。当任务偏离预定义流程时，Skill 需要依赖模型的判断来动态调整，或者退回到基础 Tool 调用模式。
Harness 的能力边界在于“管理流程，但不理解任务语义”。它不知道某个任务“应该”怎么做，只负责确保循环执行、错误处理和状态管理按照规则运行。
从开发成本来看，Model 层通常采用预训练或微调的大模型，开发者的主要工作在于提示词工程和上下文设计；Tool 层需要编写具体的执行逻辑和接口适配；Skill 层需要梳理业务流程并设计组合方案；Harness 层则需要处理状态管理、并发、错误恢复等工程问题，通常是开发工作量最大的部分。
从维护成本来看，模型层随上游版本变化可能需要重新测试提示词效果；工具层需要跟随外部系统变化而同步更新；技能层在业务流程调整时需要重新梳理步骤；框架层则需要持续监控稳定性、内存占用和异常行为。
安全考量在四个层面的侧重点不同：
| 维度 | Model | Tool | Skill | Harness |
|---|---|---|---|---|
| 核心职责 | 理解、推理、决策 | 执行具体原子操作 | 封装多步骤任务流程 | 驱动循环、管理状态 |
| 技术形态 | 大语言模型 | 函数/接口/服务 | 编排定义/流程配置 | 运行时框架/中间件 |
| 输入 | 自然语言+上下文 | 结构化参数 | 任务指令 | 完整的用户目标 |
| 输出 | 文本/结构化意图 | 执行结果 | 任务完成结果 | 最终交付结果 |
| 典型问题 | 推理错误、幻觉 | 执行失败、参数异常 | 流程不适用 | 状态丢失、循环失控 |
| 可替换性 | 高（同能力模型可替换） | 中（需适配接口） | 中（需迁移流程定义） | 低（深度绑定系统架构） |
| 开发重点 | 提示词、上下文设计 | 接口契约、错误处理 | 流程设计、领域知识 | 状态机、调度、可观测性 |
如果业务需求仅仅是回答用户问题、生成文本内容，不需要操作外部系统，那么一个 Model 配合基础的会话管理即可满足。这种情况下引入完整的 Harness 和大量 Tool 反而会增加不必要的复杂度。
当需求是“根据用户输入调用一个外部接口”，例如查询天气、获取股票价格，核心工作是设计好 Tool 的契约和描述，让模型能够稳定地生成正确的调用参数。此时 Harness 可以简化为“模型 → 工具 → 返回结果”的单次循环，Skill 层可能暂时不需要。
如果任务需要多个步骤、多个工具协同完成，例如“读取一份数据文件 → 清洗数据 → 生成统计图表 → 撰写分析摘要”，则 Skill 的价值开始凸显。将这个过程封装为一个技能，可以让模型每次面对类似任务时不必重新规划每一步，同时保证输出质量的一致性。
当 Agent 需要长时间运行、处理复杂嵌套任务、面对大量不确定情况时，Harness 的设计质量成为系统成败的关键。需要考虑的有：执行循环的终止条件如何设置、状态如何持久化、工具调用失败后如何重试或降级、如何追踪一次完整任务的执行链路等。
选型判断的核心逻辑可以概括为：
任务复杂度 × 执行时长 × 工具数量 = 对 Harness 和 Skill 的依赖程度
任务越复杂、执行链路越长、涉及的工具越多，就越需要成熟的框架层和技能封装来保证系统的可靠性和可维护性。反之，简单场景下过度设计会带来不必要的开发和运维负担。
如果团队正在从“直接调用模型 API”的模式向“完整的 Agent 架构”迁移，有几个关键点需要提前评估：
接口兼容性。 现有的 Tool 是否具备清晰的参数定义和错误返回格式？如果工具接口设计得过于随意，融入 Agent 框架后容易出现调用歧义和异常处理混乱。迁移前需要对工具进行契约化改造。
状态管理策略。 长任务执行过程中，会话状态、中间结果和工具返回值如何存储？选择内存存储还是持久化存储？多用户并发时如何隔离状态？这些问题需要在 Harness 设计阶段明确，否则上线后容易出现串数据或状态丢失的问题。
安全审批机制。 当模型的工具调用权限扩大后，需要在 Harness 层加入人工审批或风险分级机制。对于涉及数据写入、消息发送或资金操作的高风险工具，应设置确认环节，避免模型误操作造成不可逆影响。
可观测性与调试能力。 Agent 的调试难度远高于普通应用，因为问题可能出现在模型推理、工具执行或框架调度中的任何一个环节。建议从第一天就建立完整的执行日志和链路追踪机制，记录每一次模型输出、工具调用和状态变化。
渐进式演进。 不需要一开始就构建完整的四层架构。合理的路径是：先用模型解决简单任务 → 逐步引入 Tool → 在积累足够的工具后抽象出 Skill → 最后根据实际需求完善 Harness 能力。这种渐进式演进可以避免过早陷入框架设计的复杂性，让每一层都在真实需求的驱动下生长。
Model、Tool、Skill 与 Harness 共同构成了 AI Agent 的技术栈，但它们分别回答的是四个不同的问题：
理解这四个概念的区别与联系，是构建可靠 Agent 系统的基础。在实际项目中，与其纠结于“哪个概念更重要”，不如根据具体场景判断当前最需要加强的是哪一层。对于简单任务，模型和少量工具可能已经足够；对于复杂生产环境，完善的框架层和技能封装才是系统能够长期稳定运行的关键。技术选型的核心原则始终是：用合适的复杂度，解决真实的问题。