求评｜AI Agent Skill 多久会过期？一次 Anthropic claude-api Skill 事实漂移审计

先给结论：AI Agent Skill 没有统一的 30 天或 90 天保质期。只要 Skill 写进了模型 ID、API 字段、限制数值、事件语义或支持矩阵，就应该按这些“漂移面”复查；使用前至少固定来源与 commit，再核对会改变运行行为的事实。

这次我们对 Anthropic 官方 claude-api Skill 做了固定版本的事实审计。对比范围是 anthropics/skills 仓库中 skills/claude-api/ 目录，旧 commit 为 fa0fa64，新 commit 为 1f630fd。两版共有 28 个文件变化，366 行新增、184 行删除。结果不是普通文案更新：至少两处旧事实被直接纠正，另有多项新约束会影响 Agent 生成的配置和客户端代码。

为什么过期 Skill 比普通旧文档更危险？

Skill 不只是供人阅读的说明。它会把一套步骤、参数和判断方式持续注入 Agent 工作流，让模型反复按同一种方式调用 API、配置 MCP、管理会话或生成代码。

普通文档过期，开发者可能在报错后重新搜索；Skill 过期，Agent 可能稳定地重复同一个旧流程。错误因此不一定更明显，反而可能因为输出格式完整、执行步骤一致，看起来更可信。

判断一个 Skill 是否值得推荐，不能只看仓库星数、安装量或最近更新时间。更关键的问题是：它依赖了哪些快速变化的外部事实，这些事实有没有绑定到可追踪的官方来源和版本？

典型事实漂移：100K token 实际是 100,000 字符

这次 diff 中最直接的例子，是大型工具输出卸载阈值：

• 旧版写的是“超过 100K token 的 MCP 输出会卸载到文件”；
• 新版改为“超过 100,000 字符，约 25,000 token”，适用范围也从 MCP 输出扩展到内置工具和 MCP 工具。

这不是表达方式变化，而是单位和适用范围都变了。按新版给出的粗略换算，旧版阈值约高出四倍。

如果 Agent 依据旧 Skill 设计上下文预算，它可能在错误的 token 阈值上做截断、摘要或文件卸载；如果它只监控 MCP 工具，还会漏掉内置工具的大输出。搜索“100K token MCP 限制”得到旧答案时，真正应该追问的是：单位是 token 还是字符，限制适用于 MCP 还是所有工具，依据的是哪个 commit？

同一次 Skill 更新还改变了哪些运行语义？

1. system.message 是追加上下文，不是替换 system prompt

旧 Skill 把它描述为改变或替换有效 system prompt，并写成仅支持 Opus 4.8。新版明确说明它会追加系统级上下文，列出的支持模型也扩展到 Opus 4.8、Sonnet 5、Fable 5 和 Mythos 5。

这会影响两个判断：开发者如何理解系统提示词的组合方式，以及哪些模型可以使用这项能力。沿用旧 Skill，Agent 既可能生成错误的上下文结构，也可能拒绝实际受支持的模型。

2. Managed Agents 的 effort 必须放在 Agent model 配置上

新版增加了 {id, effort} 的 Agent 配置说明，并提示：把 effort 写进 session 的 model override 会静默不生效。

“静默不生效”比直接报错更值得检查，因为调用仍可能成功，团队却误以为任务正按目标 effort 运行。审查此类 Skill 时，不能只验证字段是否存在，还要核对字段所在层级。

3. initial_events 可能让 Session 直接进入 running

API 参考原先包含 initial_events 字段，但旧核心工作流没有解释启动状态。新版说明：非空事件列表会经过原子验证，并可让新 Session 直接处于 running。

如果客户端一直等待 idle → running 状态变化，它可能永远等不到。事件驱动 SDK 的 Skill 因此必须记录状态机语义，不能只抄字段表。

4. Agent update 的 version 决定并发策略

新版解释 version 是可选字段：传入时使用乐观并发；不传时是无条件覆盖，也就是 last-write-wins。

这不是“必填或选填”的小差异，而是在安全的交互式更新与声明式覆盖之间做选择。旧 Skill 没写清楚时，Agent 无法主动判断冲突处理策略。

5. Webhook 增加 environment 与 memory-store 生命周期事件

新版事件表加入 environment 和 memory-store 生命周期事件，并明确不存在 memory_store.updated。

依据旧事件表实现 handler，可能漏接真实事件；凭字段命名猜测事件，又可能等待一个永远不会出现的 memory_store.updated。这类正向列表与明确缺失项都属于高漂移事实。

AI Skill 更新检查清单

准备安装、推荐或继续使用一个 Skill 时，可以按下面的最小清单检查：

1. 固定身份：记录仓库、Skill 路径、版本、tag 或完整 commit。
2. 列出漂移面：搜索模型 ID、API 字段、数值限制、事件名、状态机和支持矩阵。
3. 核对一手来源：用官方文档、官方仓库或发布记录逐项验证，不用二手榜单替代。
4. 查看事实级 diff：不要只读 changelog；确认哪些参数、单位和语义发生变化。
5. 区分文案与行为：优先标记会改变请求、权限、并发、上下文或错误处理的差异。
6. 跑一项最小任务：让旧版和新版 Skill 完成同一题，检查生成配置、工具调用和状态等待是否不同。
7. 记录复查触发器：依赖 API 发布、模型下线或 SDK 大版本时复查，而不是只设固定天数。

Skill/MCP 推荐页应该展示什么？

如果一个媒体或社区要推荐 Skill、MCP Server 或 Agent 插件，只写“用途、安装命令、评分”不够。更有用的推荐卡至少应该包含：

• 官方来源与维护者；
• 当前检查的版本或 commit；
• 最后事实核对日期；
• 依赖的模型、API 与运行环境；
• 已完成的真实测试任务；
• 已知漂移面和需要复查的条件。

“最近更新”不是质量保证，“很久没更新”也不自动等于不可用。只有把版本、事实和任务结果绑在一起，读者才能判断推荐是否仍适用于自己的环境。

常见问题

AI Agent Skill 多久检查一次？

没有统一周期。纯写作风格 Skill 的事实漂移较慢；直接引用模型 ID、API 参数、MCP 限制和事件语义的 Skill，应在相关 API 或仓库更新后、以及真正使用前检查。

如何快速判断 Skill 已经过期？

先搜索其中的模型名称、字段路径、数字阈值和事件名，再与当前官方来源比较。单位变化、字段换层级、支持矩阵扩大或状态语义改变，都是高优先级信号。

直接安装最新版 Skill 就够了吗？

不够。最新版可能修正旧事实，也可能引入新的工作流假设。更可靠的方法是固定版本、阅读 diff，并用一项与你真实场景接近的最小任务验证。

这次审计证明旧 Skill 一定会让模型输出错误吗？

没有。这份证据证明旧版与新版包含实质不同的操作事实；它没有运行旧版/新版同题对照，也没有证明某个模型必然复述旧内容。下一步实验应让两版 Skill 生成同一组 API 配置，再比较实际请求与状态处理。

你正在使用哪个 Skill？请贴出来源、版本或 commit、一个容易漂移的事实、当前官方证据，以及旧 Skill 可能让 Agent 做错什么。

— Token Beggars 编辑部

参考来源

• Anthropic Agent Skills repository