Agent 和 Skill 不在同一个层级。Agent 是接目标、做判断、调用工具并对结果负责的运行主体；Skill 是它在某类任务里按需加载的做事方法。一句话区分：Agent 决定做什么、下一步怎么走，Skill 规定这类事按什么步骤、什么口径、什么标准做。
企业要处理的，除了两个定义，还有职责怎么分。Agent 建得太大，会把业务方法硬编码在提示词里；Skill 管得太散，又会出现版本冲突、权限越界和结果不可复现。下面从定义、边界、配合流程和企业分工四个层面拆开讲。
Agent 和 Skill 分别是什么
Agent 是有目标、有行动闭环的系统
Agent 从目标开始工作。它接收任务，理解当前环境，拆解步骤，选择工具，执行后根据返回结果继续调整，直到任务完成、需要人接管或触发停止条件。
Anthropic 在 2024 年 12 月的工程文章《Building effective agents》中，把 Agent 定义为由大模型动态决定自身流程和工具使用、并对任务完成方式保有控制权的系统。这个定义把 Agent 和固定工作流区分开来：工作流走预定义的代码路径，Agent 自己决定下一步。
在企业环境里，Agent 还要处理身份、权限、知识、记忆和审计。这也是企业级 AI Agent 与普通聊天机器人的差别。它需要在授权范围内完成动作，并留下可检查的过程。
Skill 是把做事方法打包的能力单元
Skill 是 Agent 在需要时加载的能力包。从使用角度看，它是一套可复用的做事方法；从实现角度看，它通常是一个目录，里面有 SKILL.md、说明文档、脚本、模板和参考资料。
Anthropic 在 2025 年 10 月发布 Agent Skills，将其描述为由指令、脚本和资源组成的有组织文件夹，Agent 可以发现并动态加载，以便在特定任务上表现得更好。2025 年 12 月，这套格式又被发布为跨平台使用的开放标准。
Skill 的关键机制是渐进式披露。Agent 启动时只预加载每个 Skill 的名称和描述，用来判断相关性；确认相关后，才读取完整的 SKILL.md；需要时再打开附属的参考文档、模板或脚本。这样既能让 Agent 知道有哪些能力，又不会把所有资料一次性塞进上下文。
Skill 也可以包含代码。脚本由 Agent 通过工具执行，适合排序、解析文件、跑查询这类需要确定性的操作。Skill 本身不发起任务，也不持有目标循环，它等待被 Agent 加载和调用。
为什么两者容易被混为一谈
三个原因很常见。Agent 装上 Skill 之后能力变强，演示时看起来像同一个东西；Skill 里可以带脚本，容易让人误以为它能独立行动；很多产品把 Agent、Skill 和工具打包成一个界面，用户只看到它能做事，看不到内部分层。
Agent 和 Skill 的区别，可以先看一个关键点：谁拥有目标、决策权和持续行动的循环。 能自己判断下一步、调用工具、根据反馈继续做的，是 Agent；等待被加载、按既定方法提供步骤和资源的，是 Skill。
还有一个简单的检查方法：删掉 Skill，Agent 还在，只是少了某项专业能力；删掉 Agent，Skill 没有执行主体。一个 Agent 可以装载多个 Skill，一个 Skill 也可以被多个 Agent 使用。
| 判断维度 | Agent | Skill |
|---|---|---|
| 目标 | 接收并拆解目标 | 服务某类任务，不自己设定目标 |
| 决策 | 决定步骤、工具和是否继续 | 提供方法、步骤和判断标准 |
| 状态 | 持有会话、记忆和任务进度 | 通常不单独持有运行状态 |
| 权限 | 以自身身份和授权调用工具 | 通常沿用运行它的 Agent 环境 |
| 复用 | 面向一个或一类场景 | 可跨任务、跨 Agent 复用 |
| 变更影响 | 影响该 Agent 的所有任务 | 影响所有调用它的 Agent |
表格最后一行值得企业特别注意。Skill 的复用范围越大，一次修改的影响面也越大。方法写错、口径过时或脚本有漏洞，会沿着所有调用它的 Agent 扩散。
Agent 和 Skill 怎么配合
配合可以拆成六步。
- 接目标，先定边界。Agent 确认任务、成功标准、可用数据和权限范围。信息不够就追问，不带着模糊目标直接执行。
- 用元数据找 Skill。Agent 先看已安装 Skill 的名称和描述，判断哪些与当前任务相关，不把所有内容一次性读入上下文。
- 按需加载方法和资源。相关时读取完整的 `SKILL.md`；遇到具体分支，再打开附属的参考文档、模板或脚本。
- 调用工具执行。查数据库、跑 SQL、调用 API、生成文件。权限和数据范围由 Agent 所在平台控制，Skill 不能绕过。
- 用结果反馈校验。对照成功标准检查结果；遇到数据缺失、口径冲突或脚本失败，回到上一步调整，必要时换一个 Skill。
- 把验证过的做法沉淀为 Skill。记录步骤、口径、例外情况和测试样例，指定负责人维护版本。
Agent 和 Skill 的关系，可以概括为目标、方法和执行的分工。
留存分析里怎么分工
运营负责人问：上周新用户的 7 日留存为什么下降？
Agent 先判断这是诊断任务，确认留存口径，再决定按渠道、版本和投放来源拆开看。执行中发现某个渠道的数据缺失，它会调整范围，最后给出结论和限制条件。
Skill 提供的是这类任务的做法：留存指标怎么定义，同期群怎么切，异常到什么程度值得继续查，报告按什么结构输出。Tool 负责查库、跑 SQL 和画图。
这里的分工很清楚：Skill 不替 Agent 决定先查哪个渠道，Agent 也不临时发明留存口径。 如果这套排查方法每周都要用，就把它沉淀成 Skill；如果步骤永远固定、没有判断空间，直接写成工作流或脚本更省成本。
Skill、Tool、Workflow、MCP 各管什么
这几个概念经常一起出现，边界可以用一张表看清。
| 概念 | 主要作用 | 谁来决定使用 | 典型形态 |
|---|---|---|---|
| Agent | 接目标、做决策、执行并校验 | 自己 | 运行系统 |
| Skill | 提供某类任务的方法、步骤、资源和脚本 | Agent 判断相关性后加载 | 目录、`SKILL.md`、附属文件 |
| Tool | 提供具体动作接口 | Agent 或工作流调用 | API、函数、脚本 |
| Workflow | 按预定义路径编排步骤 | 代码或配置 | 固定流程 |
| MCP | 标准化连接工具和数据源 | 平台或开发者配置 | 协议与连接服务 |
Tool 回答能做什么动作，Skill 回答这类任务怎么做。 一个 Skill 可以指导 Agent 什么时候调用哪个 Tool，也可以把多个 Tool 串成一套做法。
Workflow 适合步骤固定、要求可预测的任务。Agent 适合步骤无法提前写死、需要根据环境反馈调整的任务。两者可以组合，Workflow 里的某一步也可以交给 Agent。
MCP 解决连接问题，不规定业务方法。它让 Agent 更容易接入外部工具和数据源，同一套 MCP 工具可以被不同 Skill 使用。把 MCP 当成 Skill，会低估方法、口径和判断标准的作用；把 Skill 当成 MCP，又会忽略连接层需要单独治理。
企业落地时，Agent 和 Skill 怎么分工
企业里比较稳妥的分法是三层。
平台层负责身份、权限、模型接入、知识、工具连接、任务调度和运行监控。它决定 Agent 能看什么、能做什么、做完留什么记录。
Agent 层负责具体场景的目标拆解、工具选择、结果校验和人工接管。一个 Agent 可以只服务一个窄任务，也可以在多 Agent 协作里承担一个角色。
Skill 层负责业务方法、指标口径、模板、脚本和测试样例。它应该独立于某个 Agent 存在，换一个 Agent 仍然能用。
如果业务方法只写在 Agent 的提示词里，换一个 Agent 就要重写一遍，方法也很难版本化。Skill 化之后，方法有了独立载体，可以审查、测试、回滚和复用。平台层通常还会提供 Agent 编排、权限和运行观测，这部分可以单独看Agent 编排层的职责。
建一个 Skill 之前，先回答四个问题：
- 这项任务是否高频重复？
- 方法是否稳定，指标口径是否统一？
- 成功标准能不能写清楚？
- 是否涉及敏感数据或高风险动作？
前三个问题大多为“是”，适合做成 Skill；如果步骤完全固定，优先考虑工作流或脚本；如果只做一次，直接把要求写进任务里更省事。第四个问题为“是”时，Skill 上线前要增加权限审查、人工确认和回滚机制。
Skill 会把能力放大，也会把错误放大。上线前审来源和脚本，运行时由平台控制权限，上线后看调用记录和结果。第三方 Skill 尤其要审查，因为它会把指令和代码带进 Agent 的可信上下文。
ThinkingAI 的 Agentic Engine 提供 Agent 创建、管理和多 Agent 协作能力，并把一次分析流程沉淀为可复用的 Skill。平台侧处理权限控制、任务调度和运行监控，业务团队把指标口径、分析步骤和报告模板做成 Skill。官方 Skills 库提供行业和场景预制 Skill，企业也可以按自己的方法改。目前 ThinkingAI 已服务全球 1500 家企业，接入产品超 8000 款。
先建 Agent 还是先做 Skill
判断顺序从任务开始。
- 任务开放、步骤无法提前写死、需要跨系统执行，先建 Agent。
- 步骤固定、要求可预测，先做 Workflow。
- 方法稳定、要跨多个 Agent 复用，先做 Skill。
- 只是单次调用一个接口，直接写 Tool 或脚本。
一个稳妥的顺序是：先人工跑通一个窄任务，再让 Agent 辅助执行，把稳定的步骤和口径沉淀成 Skill，最后扩到多 Agent 复用。这个顺序的好处是每一步都能验收，不会一开始就搭一个很大但跑不稳的系统。
验收时看任务完成率、人工接管率、Skill 触发准确率、返工率和单任务成本。Skill 数量只能说明规模，不能说明成熟度；能稳定触发、结果可验收的 Skill 才有价值。 Skill 越多，元数据匹配、版本冲突和权限管理的成本也越高。运行数据怎么看，可以参考AI Agent 可观测性的评估方法。
常见问题
Skill 是不是提示词？
提示词是 Skill 的一部分。Skill 还包括名称、描述、触发条件、脚本、模板和参考资料，并且可以被多个 Agent 复用和版本化管理。把一段提示词复制来复制去，维护成本会越来越高。
有了 Agent，还需要 Skill 吗？
看任务是否重复、方法是否稳定。一次性任务可以把要求直接写进对话；高频、口径固定的任务更适合做成 Skill，这样换 Agent 或换执行人时不用重新讲一遍。
一个 Skill 可以给多个 Agent 用吗？
可以，前提是格式兼容、依赖资源可用、权限范围允许。跨平台使用时还要检查对方是否支持相同的 Skill 规范，以及脚本和外部资源能不能在目标环境里运行。
Skill 会不会取代 Agent？
不会。Skill 提供方法，Agent 保留目标判断、执行和结果责任。没有 Agent，Skill 缺少执行主体；没有 Skill，Agent 仍能工作，只是专业任务的方法要临时补。
Skill 和 MCP 是什么关系？
MCP 解决工具和数据源的连接，Skill 解决某类任务的做法。两者可以一起用，MCP 提供可调用的工具，Skill 规定什么时候调用、怎么组合、结果怎么校验。
参考资料
- Anthropic Engineering. Equipping agents for the real world with Agent Skills. 2025-10-16. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
- Anthropic Engineering. Building effective agents. 2024-12. https://www.anthropic.com/engineering/building-effective-agents
