简介：本文面向正在设计智能体系统的开发者，系统辨析Agent Harness与Agent Skills两个常被混淆的概念。读者将理解二者在职责边界、抽象层次与工程定位上的核心差异，掌握从任务编排、工具调用到能力复用的选型思路，并能在实际项目中判断何时需要强化Harness控制层、何时应沉淀可复用的Skills能力模块。
在智能体系统（Agent）的工程实践中，开发者经常会遇到两个高频概念：Agent Harness 与 Agent Skills。前者常出现在讨论“如何让模型可靠运行”的语境中，后者则多见于“如何让智能体具备可复用能力”的讨论。二者听起来都与“智能体能做什么”有关，但在系统设计中承担着完全不同的职责。
本文围绕这两个概念展开对比，重点回答三个问题：它们分别是什么、差异体现在哪里、在实际项目中如何配合使用与选型。
当开发者设计一套智能体流程时，往往会同时涉及“流程控制”和“能力封装”两件事。例如一个代码修复智能体，既需要决定“先读文件、再改代码、然后跑测试、失败则重试”的执行顺序，也需要具备“读文件”“执行命令”“解析测试输出”这些具体能力。
前者是运行控制，后者是能力供给。由于两者在代码中常常写在同一个工程里，甚至由同一个模块承载，很多团队会把它们统称为“我的 Agent 流程”，从而模糊了二者的边界。一旦系统规模扩大、需要多人协作或跨项目复用时，这种模糊就会带来维护成本：控制逻辑无法独立演进，能力模块难以被其他智能体复用。
因此，有必要把 Agent Harness（运行控制层） 与 Agent Skills（能力模块层） 明确区分开来。
Harness 原意是“挽具、约束装置”，在智能体语境中，它指的是让智能体可靠运行起来的外部控制层。它不负责“模型有多聪明”，而负责“模型在什么时机、以什么约束、按什么规则去行动”。
一个完整的 Harness 通常包含以下职责：
可以用一段示意性伪代码来描述 Harness 的典型结构：
harness.run(task):state = init_state(task)while not state.finished and state.steps < MAX_STEPS:action = model.decide(state) # 让模型决定下一步if action.needs_approval and not approved(action):state = wait_for_human(action) # 人工审批continueresult = tools.execute(action) # 工具调度state = update_state(state, result) # 状态管理if result.failed:state = handle_error(state, result) # 重试 / 重规划 / 终止if verifier.check(state): # 结果验证state.finished = Truereturn state.output
可以看到，Harness 关心的是流程的可靠性：即使模型判断出现偏差、工具调用失败、外部环境不稳定，系统依然能按既定策略收敛到可接受的结果。
Skills 指的是智能体可以调用的具体能力单元。它回答的是“智能体会做什么”，而不是“智能体怎么组织这些动作”。
一个 Skill 通常具备以下特征：
示意性描述如下：
skill: read_filedescription: 读取指定路径的文本内容input: { path: string }output: { content: string, truncated: boolean }constraints: 仅允许访问工作目录内文件skill: run_testsdescription: 执行测试命令并返回结构化结果input: { command: string }output: { passed: int, failed: int, logs: string }
Skills 关心的是能力的标准化与复用性：同一套“读文件”“执行测试”“检索文档”的能力，可以被代码修复智能体、文档生成智能体、数据分析智能体共同使用。
尽管定位不同，二者在工程目标上存在明显交集：
正因为交集明显，团队在早期常把它们写在一起；但也正因职责不同，规模上来后必须拆分。
Harness 处于编排层，关注“多个动作如何按顺序与条件组织”；Skills 处于能力层，关注“单个动作如何被准确定义与执行”。一个是横向的流程，一个是纵向的能力。
| 维度 | Agent Harness | Agent Skills |
|---|---|---|
| 核心问题 | 智能体如何可靠运行 | 智能体具备哪些能力 |
| 关注对象 | 流程、状态、时机、约束 | 单个能力的输入输出与实现 |
| 典型组成 | 调度器、状态机、验证器、审批网关 | 工具函数、能力描述、参数schema |
| 变更频率 | 随业务流程调整而变 | 随能力需求扩展而变 |
| 复用范围 | 通常绑定某类任务流程 | 可跨智能体、跨项目复用 |
| 失败处理 | 重试、降级、重规划、终止 | 返回结构化错误，交由上层决策 |
Harness 决定模型在流程中的角色：是每一步都让模型决策，还是仅在关键节点让模型判断；是否允许模型自主规划；是否引入独立的验证模型。Skills 则决定模型能看见哪些能力：能力描述的清晰度、参数约束的严格程度，直接影响模型选择与调用参数的准确性。
换句话说，Harness 影响“模型怎么被使用”，Skills 影响“模型能用什么”。
Harness 的复杂度主要来自状态管理与异常路径：长任务的状态持久化、并发任务隔离、人工审批介入、失败后的幂等重试。Skills 的复杂度主要来自契约设计与实现质量：参数校验、权限边界、输出结构稳定性、对大输出的截断与摘要处理。
Harness 是权限策略的执行者：它决定哪些动作需要审批、哪些工具在何种条件下可用、单次任务可消耗多少资源。Skills 是权限约束的承载者：它自身限定可访问的路径、可执行的命令范围、可读取的数据边界。二者需要配合，但职责不可互相替代。
| 对比维度 | Agent Harness | Agent Skills |
|---|---|---|
| 定义 | 智能体运行控制层 | 智能体可复用能力模块 |
| 解决的问题 | 流程可靠、可控、可恢复 | 能力标准化、可复用、可描述 |
| 抽象层次 | 编排层 | 能力层 |
| 关键组成 | 调度、状态、验证、审批、重试 | 工具实现、能力描述、参数契约 |
| 接入方式 | 与业务流程深度绑定 | 以注册/描述方式挂载 |
| 扩展方式 | 新增流程分支、策略 | 新增能力单元 |
| 运维关注点 | 任务监控、状态恢复、异常告警 | 能力可用性、输出稳定性、版本兼容 |
| 适用场景 | 多步骤、长流程、高风险任务 | 能力复用需求强、多智能体协作 |
| 使用边界 | 过度设计会拖慢简单任务 | 契约不清会导致模型误用 |
场景一：单轮问答类应用。 模型调用一次即可返回结果，流程极简。此时无需复杂 Harness，重点应放在能力描述与输出约束上，Skills 的设计质量更关键。
场景二：多步骤任务型智能体。 涉及任务拆解、工具调用、失败重试、结果验证。此时 Harness 是核心，需要明确状态管理、错误处理与终止条件；Skills 作为被调度的能力单元，按契约提供即可。
场景三：多智能体协作平台。 多个智能体共享一套能力库。此时 Skills 的标准化与复用价值凸显，需要统一的能力描述规范；Harness 则更多体现为各智能体自身的编排策略与平台级的调度约束。
场景四：高风险操作场景。 涉及文件修改、命令执行、数据写入。Harness 的审批网关与权限控制不可缺失，Skills 需在实现层再做一层边界校验，形成双重防护。
Agent Harness 与 Agent Skills 并非同一层次的概念：Harness 是让智能体可靠运行的外部控制层，Skills 是让智能体具备可复用能力的模块层。前者回答“怎么组织与约束”，后者回答“能做什么与怎么调用”。
在实践中，二者是配合关系而非替代关系：Harness 负责流程的可靠性，Skills 负责能力的标准化。判断选型时，应先看任务复杂度与失败代价决定 Harness 的投入程度，再看复用需求决定 Skills 的抽象程度。把二者边界划清、契约定稳，智能体系统才能在规模扩大后依然保持可维护、可测试、可演进。