GPT88 / API Docs
வலைப்பதிவுக்குத் திரும்பு

Anthropic 从 Agents 到 Skills：能力封装为什么比重复造 Agent 更重要

AI 工作流2026-10-1511 நிமிட வாசிப்புAnthropicClaudeAgent SkillsAgentAI 工作流

本文依据白白说大模型的视频整理。公开可读取的证据包括视频标题、频道 RSS 的发布时间和描述，以及视频缩略图；当前没有可下载的公开字幕，因此本文不是逐字稿。关于 Agent Skills 的定义、文件结构和加载方式，另以 Anthropic 官方工程文章和 Claude Code 官方文档核对。视频标题中的“从 Agents 转向 Skills”是内容创作者的概括，不能直接当作 Anthropic 已宣布停止使用 Agents 的官方结论。

视频标题提出了一个值得讨论的判断：Anthropic 的重点似乎正在从“再造一个 Agent”转向“把能力封装成 Skill”。如果只看标题，很容易把它理解成两种技术路线的替代；对照 Anthropic 的公开资料后，更准确的说法是：Agent 仍然负责理解目标、调用工具和推进任务，Skill 则把程序性知识、工作步骤和辅助资源整理成可复用的能力模块。

这改变的不是“有没有 Agent”，而是 Agent 如何获得稳定、可维护、可迁移的专业能力。

先把三个概念分开

Agent：负责推进一次任务

Agent 通常包含目标理解、规划、工具调用、状态管理和结果反馈。它可以决定先读哪些文件、调用哪个工具、何时验证和是否继续尝试。Agent 的优势在于处理开放式任务，但如果每次都从空白上下文开始，它会重复猜测同一套领域流程。

Skill：负责复用一套做事方法

Anthropic 官方工程文章将 Skill 描述成一个包含 SKILL.md 的目录，也可以附带脚本、参考资料和其他资源。它更像一份可执行的入职手册：告诉 Agent 什么时候使用这项能力、按什么步骤做、需要读取哪些资料、怎样判断结果完成。

Skill 不需要独立承担完整任务。它提供的是稳定的程序性知识，Agent 仍然负责把这项能力放进具体任务的上下文中。

Prompt：负责当前这一次沟通

Prompt 适合表达本次目标、输入和约束；Skill 适合保存会反复使用的流程；Agent 适合把多个能力串成一次任务。三者混在一起，常见结果就是一段越来越长的提示词，既难维护，也难判断哪些规则应该在什么时候生效。

层级主要职责适合放什么
Prompt描述当前任务目标、输入、输出格式、当前限制
Skill封装可复用方法步骤、检查清单、脚本、参考资料、模板
Agent推进开放式工作计划、工具调用、状态、交接和重试

为什么 Skills 会成为重要的能力层

1. 把专业经验从对话里搬出来

很多团队已经有一套做事方法，只是散落在旧项目、聊天记录、个人记忆和长篇 CLAUDE.md 中。模型每次都要重新理解这些规则，容易漏掉前置条件和验收步骤。

把流程写成 Skill 后，可以显式记录：

  • 什么时候应该触发这项能力；
  • 第一步需要检查哪些输入；
  • 哪些工具和文件是必需的；
  • 失败后如何恢复或升级；
  • 什么证据可以证明任务已经完成。

这让“经验”变成可以审阅、提交、复用和迭代的项目资产。

2. 通过渐进式披露节省上下文

Anthropic 的 Agent Skills 文章强调了渐进式披露：Agent 启动时只需要知道每个 Skill 的名称和描述；只有判断当前任务相关时，才读取完整的 SKILL.md；更深的参考资料或脚本可以在需要时继续加载。

Claude Code 官方文档也采用类似思路：Skill 的主体只在使用时加载，长篇参考资料不会因为“可能有用”而在每次对话中占用上下文。

这比把所有规范永远塞进系统提示更适合大型项目，因为不同任务需要的知识不同。上下文不是仓库的目录索引，越多不一定越好；关键是让模型能找到正确的入口，并在需要时继续深入。

3. 让不同 Agent 使用同一套方法

如果部署多个 Agent，每个 Agent 都有一份略有不同的提示词，团队会很快遇到版本漂移：一个知道要跑回归测试，另一个只检查类型；一个会保存证据，另一个只返回结论。

共享 Skill 可以把关键流程集中维护。Agent 可以有不同的规划方式和工具组合，但在发票处理、数据分析、发布检查或安全审计等环节使用同一套最低标准。

4. 让能力跨工具迁移

Anthropic 官方资料指出，Agent Skills 已经朝开放标准发展。只要不同工具都能理解目录、SKILL.md 和相关资源，团队就有机会把一套程序性知识带到不同的 Agent 产品中，而不是为每个产品重写一遍。

跨工具迁移仍需核对具体实现：命令名、权限模型、脚本运行环境和动态上下文机制可能不同。标准提供了共同语言，不代表所有运行时都能无修改执行同一 Skill。

一个 Skill 的最小结构

一个可维护的 Skill 至少需要清晰的名称、触发描述和执行说明。概念结构可以写成：

my-skill/
├── SKILL.md          # 触发条件、核心步骤和验收标准
├── references/       # 只有需要时才读取的长篇资料
├── scripts/          # 可重复执行的检查或转换脚本
└── assets/           # 模板、样例或其他辅助资源

SKILL.md 的开头应包含简短元数据，让 Agent 在启动时知道这项能力是什么、什么时候可能相关。正文应该保持精炼，把不常用的细节拆到 references/，把确定性操作放进脚本，把模板和样例放进资源目录。

一个发布检查 Skill 可以这样组织：

---
name: release-check
description: 检查文档发布前的路由、SEO、媒体引用和构建结果。涉及发布或提交前检查时使用。
---

## 工作流

1. 确认目标路由和变更范围。
2. 检查本地链接、canonical 和 JSON-LD。
3. 运行 lint、build 和静态路由审计。
4. 检查 git diff --check。
5. 把失败项、未验证项和可发布结论分开报告。

## 完成条件

- 目标页面可生成。
- 关键链接和媒体引用存在。
- 检查命令通过，或明确记录失败原因。

这段内容不是让模型机械执行每一行，而是把一套团队共识变成可调用的入口。涉及生产写入、凭证、数据库或外部服务时，还要在 Skill 中写清权限、审批和停止条件。

从“造 Agent”转向“造能力模块”

传统的 Agent 项目往往从一个完整角色开始：做一个研究 Agent、客服 Agent、数据 Agent 或编码 Agent。这样做适合验证端到端体验，但长期维护时容易重复建设。

更可持续的拆分方式是先识别能力模块：

旧问题可抽出的 Skill
每个 Agent 都重新做资料核验来源核验与证据记录
每个 Agent 都用不同方式生成报告报告结构、引用和质量检查
每个 Agent 都重新理解仓库启动命令项目运行与验证流程
每个 Agent 都自己判断是否可以发布发布前审计与回滚检查
每个 Agent 都用自然语言描述错误错误归类、日志采集和恢复步骤

Agent 负责组合这些模块：先调用资料核验 Skill，再调用分析 Skill，最后调用报告或发布检查 Skill。这样做的收益不是架构图更漂亮，而是每个模块都有自己的输入、输出和验证标准，失败时更容易定位。

迁移路径：从长提示词和 CLAUDE.md 开始

不需要一次性重写所有 Agent。可以从最常重复的流程开始：

第一步：找出重复粘贴的内容

收集团队经常复制到对话里的检查清单、命令、格式要求和排障步骤。重复出现，通常说明它已经不是一次性 Prompt，而是一项候选 Skill。

第二步：区分事实和流程

项目名称、目录位置、API 端点等稳定事实可以留在项目说明中；“先做什么、失败时怎么办、怎样验收”属于流程，更适合放到 Skill。不要把所有背景资料都搬进去。

第三步：先写触发条件

description 要说明何时使用，而不是只写“这是一个很有用的工具”。触发条件越具体，Agent 越容易在正确的任务中加载它，也越容易避免不相关的上下文污染。

第四步：把确定性操作交给脚本

格式转换、文件检查、路由扫描、数据校验等步骤如果可以确定地执行，应尽量用脚本完成。Skill 负责告诉 Agent 什么时候运行脚本以及如何解读结果，减少模型手工重写命令的机会。

第五步：补上失败和停止条件

一个只有“成功路径”的 Skill 不够可靠。需要写清：缺少输入怎么办、权限不足怎么办、输出不一致怎么办、何时停止并交给人处理。尤其不要让“继续尝试”变成无限重试。

第六步：用真实任务评估

选择几次历史任务做回放，比较使用 Skill 前后的漏检、返工、人工时间、错误类型和结果一致性。Skill 的价值应体现在更稳定的结果，而不是文件数量增加。

Skills 不是安全边界

Skill 可以包含脚本、命令和外部资料，因此它也是一个需要审阅的执行入口。安装或共享 Skill 前，应检查：

  • 是否会读取不必要的密钥、Cookie、浏览器数据或个人文件；
  • 脚本是否会联网、下载依赖、修改生产数据或执行危险命令；
  • 参考资料和模板是否包含过期、矛盾或未经授权的内容；
  • Skill 的权限是否与任务范围匹配；
  • 结果是否有独立验证，而不是让 Agent 用同一上下文自我评分。

把流程写成 Skill 不会自动让它变安全。相反，能力模块越容易复用，越应该把权限、审计、脱敏、审批和回滚写成明确条件。

一个实用的验收清单

在把 Agent 能力封装成 Skill 后，可以用下面的问题检查它是否真的有用：

  1. 不看聊天历史，另一个 Agent 能否知道何时加载它？
  2. 输入不完整时，Skill 是否会报告缺口而不是自行猜测？
  3. 每一步是否都有可观察的输出或证据？
  4. 哪些步骤由脚本或测试确定执行，哪些步骤仍依赖模型判断？
  5. 失败时是否有停止、升级和恢复路径？
  6. Skill 是否可以在另一个项目或工具中复用？需要改动的地方是否清楚？
  7. 运行它需要什么权限，权限是否可以进一步收窄？
  8. 有什么外部结果可以证明它比长 Prompt 或一次性 Agent 更稳定？

结语：Agent 是运行方式，Skill 是可复用的做事方法

视频标题里的“从 Agents 转向 Skills”抓住了一个重要变化：当模型越来越能调用电脑、文件和工具时，真正稀缺的不是再写一个角色介绍，而是把专业流程整理成可加载、可审阅、可验证、可迁移的能力模块。

但这不是 Agent 被 Skills 取代。Agent 仍然负责理解目标、组合能力和推进任务；Skill 让它不必每次都从零猜测专业流程。两者结合，才更接近可维护的 AI 工作系统。

如果现在只能做一件事，可以先挑一个每周重复、失败代价明确的流程，写成一个小 Skill：只包含触发条件、核心步骤、一个确定性检查和一个完成标准。等它在真实任务中稳定后，再增加参考资料、脚本和跨工具支持。

来源与核验