题记：本文编译自 Anthropic 官方博客《Improving skill-creator: Test, measure, and refine Agent Skills》，原文链接：https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills。本文在翻译基础上做了整理和补充。

写了几十个 Claude Skill 之后，我最大的困惑不是怎么写，而是它到底有没有用。每次写完一个 Skill，扔到.claude/skills/ 目录里，然后就开始凭感觉判断效果了。有时候觉得有用，过两天再看结果好像又变差了，不确定是 Skill 在起作用，还是模型本来的随机行为导致的。更麻烦的是，Claude 每次更新之后，原来好用的 Skill 会不会悄悄失效，完全不知道。

这个困惑应该不只我一个人有。写 Skill 的人大多不是工程师，清楚自己的工作流程，但缺少工具来验证 Skill 到底有没有在起作用。昨天 Anthropic 更新了 skill-creator（《Improving skill-creator: Test, measure, and refine Agent Skills》），核心思路是把软件工程那套东西搬过来，测试、基准评估、迭代改进，但不需要写代码。

Claude Code 用户可以直接执行下面的命令安装：

claude plugin install skill-creator

Claude.ai 和 Cowork 里直接跟 Claude 说用 skill-creator 创建想要的 SKILL 就行。

先搞清楚你在写哪种 Skill

在聊测试之前，有一个框架我觉得挺有价值的，可以帮你在下笔之前想清楚一件事。

Anthropic 把 Skill 分成了两种，回头一想，确实是这么回事。

第一种是能力补充型，给模型添加它本来做不好的能力。Claude 官方提供的文档生成类 Skill 是个典型的例子，里面编码了一套技巧和模式，生成结果比直接提示词好得多。模型没有这个 Skill，就达不到这个效果。

第二种是流程编排型，模型原本就能处理每个环节，但 Skill 把这些环节按照团队规范串联起来，给的是“用什么顺序做什么事”这样的约束。NDA 审查、每周报告生成这类 Skill 属于这种。

这个区分对设计 Skill 很有参考价值：能力补充型有个隐患，随着模型变强，它可能会慢慢变得多余，甚至是限制 Claude 的能力。这有点像你精心写了一本新员工培训手册，结果新来的人比老员工还熟练，手册自然就没人翻了。如果有测试，你能及时发现“这个 Skill 已经完成历史使命了”，而不是一直带着一个没用的包袱。

流程编排型更耐用，但价值完全依赖于流程的严格执行，测试的重点是验证它有没有按预定顺序走完每一步。

写之前先想清楚自己在写哪种，测试策略和预期生命周期都不一样。

用 eval 取代感觉

skill-creator 现在可以帮你写 eval。形式也很简单，你给出测试提示词，描述期望的行为，然后让 skill-creator 判断你的 Skill 是否经得住检验。做过软件测试的人会觉得这个模式很熟悉，区别是不用写代码，用自然语言描述预期结果就够了。

比如 PDF Skill，以前处理不可填写的表单时经常出错，原因是 Claude 需要在没有字段定义的情况下精确定位文字放置位置。写了 eval 之后，才定位到这个具体失败点，最后通过把定位锚定到提取出来的文字坐标解决了问题。如果没有 eval，这个 bug 可能就一直隐藏着，每次遇到不可填写的表单就悄悄出问题。

eval 最直接的价值是捕捉质量回归。模型升级或周边基础设施变动之后，原本好用的 Skill 可能行为发生变化。在变化影响到实际工作流之前，eval 能提前给你预警。

不过还有一个更微妙的用途，即判断 Skill 是否还有存在的必要。对于能力补充型 Skill 来说，如果基础模型不加载 Skill 就能通过 eval，说明这些技巧已经被模型内化了，Skill 不是坏了，只是完成使命了。这个信号你只能靠测试发现，靠感觉永远看不出来。

更新里还加了 benchmark 模式，可以跑标准化评估，跟踪 eval 通过率、耗时和 token 用量。数据保存在本地，可以集成到 dashboard 或 CI 系统里。

多 Agent 并行

之前 eval 是顺序执行的，速度慢不说，测试之间上下文还会互相污染。前一个测试的内容可能影响到后一个的判断。现在 skill-creator 支持多 Agent 并行跑 eval，每个 Agent 在独立的上下文里运行，有各自的 token 和耗时统计，互不干扰。

另外还加了 comparator agent，用来做 A/B 对比：两个版本的 Skill 对比，或者 Skill vs 不加 Skill。有点像双盲实验，负责评判的 Agent 不知道自己看的是哪个版本的输出，尽量排除评估偏差。这个设计基本解决了“我觉得改好了，但其实不知道”的问题。

触发时机最容易被忽略

输出质量测完了，是不是就够了？不一定。Skill 首先得在对的时候触发才有意义。这是我自己写 Skill 时踩得最多的地方：描述写得太宽，每次稍微相关的请求都会触发；描述写得太窄，只有完全匹配的词才会触发，平时根本用不上。两种情况都让人头疼。

skill-creator 现在能分析当前的 Skill 描述，对照一组测试提示词，推荐修改来减少误触发和漏触发。Anthropic 测试了 6 个公共文档创建类 Skill，有 5 个的触发精度通过这个方法得到了改善。

说实话，这个功能我觉得是这次更新里最实用的，因为触发问题是最隐蔽的。你写的逻辑完全正确，但描述没有匹配到用户的表达方式，Skill 就等于白写了。

设计 eval 其实是在把期望说清楚

看完这次更新，我对 Skill 写作有了一个新认识：设计 eval 的过程，本质上是在逼你把“期望什么行为”说清楚。很多时候 Skill 效果差，不是因为提示词写得不好，而是作者自己也没想清楚什么叫成功。当你被迫用语言描述“在这个输入下，Claude 应该做到什么”，很多模糊的预期就会浮出水面。

Anthropic 还提到了一个有意思的预判：随着模型越来越强，Skill 和 spec 之间的边界可能会模糊。现在的 SKILL.md 本质上是实现计划，在告诉 Claude 怎么做事。以后也许只需要描述你想要什么，模型自己搞清楚怎么做。eval 框架恰好在往这个方向走，eval 描述的是 what，也就是期望的结果。某种程度上，这个描述本身可能就是未来形态的 Skill。

如果你也在写 Skill，下次不妨少靠感觉，给它加个 eval 验一验。不需要多复杂，一条提示词、一段预期描述就够了。跑一遍，可能会发现一些你没意识到的问题。

相关资源

• skill-creator 插件：https://github.com/anthropics/claude-plugins-official/tree/main/plugins/skill-creator
• Anthropic 官方 Skills 仓库：https://github.com/anthropics/skills
• 原文链接：https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 OpenAI 开发者博客《Shell + Skills + Compaction: Tips for Long-Running Agents》，由 Charlie Guo 撰写，发表于 2026 年 2 月 11 日。本文在翻译基础上做了整理和补充。

用 Agent 做过稍微复杂一点任务的朋友，应该都碰到过这几个问题：跑着跑着上下文爆了，中间结果没地方存，任务流程每次都要从头描述一遍。

这些问题说白了就是一个核心矛盾：Agent 要做的事越来越重，但它的“工作记忆”和“工具箱”还停留在对话级别。

OpenAI 最近发了一篇实践指南，专门聊怎么用三个互相配合的能力来解决这些问题：Skills、Shell Tool 和 Compaction。

我自己在 Claude Code 和 Codex 上都用过类似的机制，读完这篇觉得有几个点挺实用，整理分享一下。

三个核心概念

先把这三个东西分别说清楚。

Skills：可复用的指令包

Skills 本质上是一组带版本控制的指令文件，核心是一个SKILL.md 清单文件，里面写着这个技能是干什么的、什么时候该用、怎么用。你可以把它理解成给 Agent 准备的操作手册，平时不用的时候不占上下文，需要的时候按需加载。

这个概念其实来自 Anthropic。Anthropic 在 Claude Code 上早就实现了类似的机制，Codex CLI 后来也跟进了。OpenAI 这次把它的 API 也标准化了，对齐了 Agent Skills 开放标准。平台会把每个 Skill 的名字、描述和路径暴露给模型，让模型自己决定什么时候调用。

我自己用 Claude Code 的 Skills 已经有一段时间了，体验下来最大的好处就是：把那些重复性的工作流固化下来，不用每次都在 Prompt 里写一遍。

Shell：真正的执行环境

Shell Tool 给 Agent 提供了一个真实的终端环境，可以是 OpenAI 托管的容器，也可以是本地运行时。在这个环境里，Agent 可以安装依赖、跑脚本、生成文件，而且有受控的网络访问权限。

这跟简单的代码执行还是有本质区别的。举个例子，你让 Agent 分析一个 CSV 数据集，它可以在 Shell 里先pip install pandas matplotlib，然后写一段 Python 脚本做数据清洗和可视化，最后把生成的图表存到/mnt/data/ 目录。整个过程不需要你提前配环境，Agent 自己就能搞定。

两种模式（托管容器和本地运行）通过 Responses API 保持了统一的工具语义。开发阶段在本地快速迭代，上线后切到托管容器做隔离，API 调用方式是一样的：

response= client.responses.create( model="gpt-5.2", tools=[{"type":"shell","environment": {"type":"container_auto"}# 本地模式改成 "local" }], input="Install pandas, fetch the CSV from S3, and generate a summary report")

这样做的好处是，本地开发和生产环境的切换只需要把environment 类型从container_auto 改成local。

Compaction：上下文不够用怎么办

长时间运行的 Agent 最头疼的问题就是上下文窗口不够用。跑了几十轮工具调用之后，前面的对话内容就被挤出去了，Agent 就可能开始断片。

Compaction 就是解决这个问题的。它有两种方式：一种是自动压缩，在context_management 里设个阈值，上下文超了就自动触发；另一种是通过/responses/compact 接口手动压缩：

# 方式一：自动压缩，上下文超过阈值时服务端自动触发response= client.responses.create( model="gpt-5.2", input=conversation, context_management=[{"type":"compaction","compact_threshold":200000}],)# 方式二：手动压缩，显式调用 compact 接口compacted= client.responses.compact( model="gpt-5.2", input=long_conversation_items,)

核心思路都是把之前的对话历史压缩成摘要，保留关键信息，释放上下文空间。

这个功能的关键在于心态转变，也就是不要把 Compaction 当成上下文快爆了才用的应急措施，而是从一开始就把它作为默认实践。设计任务流程的时候就考虑好：容器要复用，previous_response_id 要传递，压缩要常态化。

五条实践建议

概念说完了，来看具体怎么用好这些能力。OpenAI 在文章里给了几条实操建议，结合我自己的使用经验一起聊聊。

Skill 的描述就是路由逻辑

很多人写 Skill 描述的时候，只写了这个 Skill 是干什么的，这远远不够。描述要能回答三个问题：什么时候该用它、什么时候不该用它、用完之后期望的输出是什么。

具体来说，要写明 Use when 和 Don’t use when 两类场景。举个例子，一个数据分析 Skill 的描述可能是这样的：

# Data Analysis SkillUse when:- User provides a dataset and asks for trends, patterns, or insights- User needs charts or visualizations from raw dataDon't use when:- User asks a simple statistical question (e.g., "what's the average of X")- User just needs data formatting or conversion

不只写用于分析数据集，还要明确告诉模型什么时候不需要大费周章地调用这个 Skill。

反面案例比正面案例更重要

OpenAI 的测试数据显示，光有 Skill 不写反面案例，正确调用率反而会下降大约 20% 。加上什么时候不该用的说明后，路由准确性才恢复并提升。

这个发现挺有意思的。模型看到一个新工具，本能反应是有锤子就找钉子。如果你不明确告诉它边界在哪，它会倾向于过度使用。

模板放在 Skill 里，别放 System Prompt

这条建议很实用。很多人习惯把示例和模板直接塞进 System Prompt 里，结果不管当前任务用不用得上，每次对话都要消耗这些 token。

把模板放在 Skill 内部，效果是不用时基本免费。只有模型决定调用这个 Skill 的时候，模板内容才会被加载进上下文。这对 token 消耗的优化是巨大的，也是 Skill 最大的优点。

需要确定性的时候，别让模型自己选

自动路由在大多数场景下够用了。但在生产环境中对确定性要求高的流程里，最好直接告诉模型用某某 Skill，别让它自己判断。

这就把模糊的路由变成了明确的指令。特别是在多步骤工作流中，每一步用哪个 Skill、按什么顺序执行，都应该在编排层面写清楚，不留给模型自由发挥的空间。

网络安全不能马虎

Skill 加上网络访问权限，等于给 Agent 开了一条可以往外发数据的通道。网络安全这事不能大意。

安全策略说白了就是两层白名单：组织级白名单划定最大范围，请求级白名单只能在这个范围内再缩小。两层都要尽量收紧。

另外一个关键点是，模型绝对不能看到明文凭证。OpenAI 搞了个domain_secrets 机制，在 Skill 里写占位符（比如Authorization: Bearer {{API_KEY}}），实际的密钥只在请求发往白名单里的目标地址时才替换进去。思路跟环境变量注入差不多，但多了目标地址校验。

三种构建模式

OpenAI 还总结了三种递进的构建模式，从简单到复杂，适合不同阶段的需求。

基础模式：安装 → 获取 → 写入

最简单的用法：让 Agent 在 Shell 里安装依赖、拉取外部数据、把结果写到/mnt/data/ 目录。

/mnt/data/ 相当于一个约定好的交付目录，Agent 生成的需要人来审查或者给下游用的文件都放这里。这样做的好处是划清了 Agent 的工作区和最终交付物的界限，后续取用和审查都方便。

工作流模式：Skills + Shell 联动

把重复性工作流封装成 Skill，挂到 Shell 环境里，让 Agent 按固定流程跑。

这种模式特别适合数据处理类任务。拿数据集清洗来说，你可以在 Skill 里定义好标准流程：先检查缺失值比例，超过阈值的列直接丢掉；然后做类型推断和格式标准化；最后输出清洗报告到/mnt/data/。Agent 每次拿到新数据集，都按这个流程走，不用你重复描述一遍。

企业级模式：Skills 作为活的 SOP

到了企业场景，Skills 就不只是技术工具了，而是变成了活的 SOP。公司的业务流程改了，对应的 Skill 跟着更新，Agent 的行为自动对齐，不用重新调参。

OpenAI 提到了 Glean 的早期落地案例：用了这种模式之后，准确率从 73% 提升到 85% ，首次响应延迟降低了 18.1% 。挺有意思的一点是，给 Agent 结构化的指导，不仅提高了质量，还加快了速度。模型不用花那么多 token 去想该怎么做，直接按 Skill 里的步骤走就行了。

写在最后

回过头来看，OpenAI 这篇文章的核心观点其实就一个：长时间运行的 Agent 需要从单次对话的思维模式升级到持续工作流的思维模式。

Skills 解决怎么做的问题，把经验固化成可复用的指令。Shell 解决在哪做的问题，提供真实的执行环境。Compaction 解决记不住的问题，让 Agent 在长任务中保持连贯。

这三个能力并不是 OpenAI 独有的。Claude Code 的 Skills 和 SubAgent、Codex 的 Shell 执行和 Exec Plan，本质上都在解决同样的问题。各家的具体实现不同，但方向是一致的：让 Agent 从聊天助手进化成能持续干活的工作伙伴。

如果你正在做 Agent 相关的开发，有几个建议：先把最常用的工作流封装成 Skill，别急着做通用的。Shell 环境从本地开始，跑通了再考虑容器化。Compaction 从第一天就用上，别等上下文爆了再补救。

原文链接：https://developers.openai.com/blog/skills-shell-tips

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。