考察点
这道题出自蚂蚁集团 Agent 暑期实习一面（2026 年牛客面经），属于横向对比题，前提是候选人用过不止一种 agent 工具。面试官想看的不是功能清单对比，而是你理解不同产品背后知识注入机制的差异：Claude Code 的 skill 是"按需加载的能力包"，而很多其他 harness 的规则文件是"常驻注入的静态约束"，这个差异直接决定了可扩展性和上下文成本。能进一步讲到创建方式（元 skill 自动生成 vs 手写规则）和生态打通（skill 与工具、subagent 的关系），就说明你有真实的多工具实践。追问可能往"如果让你给自家 agent 设计 skill 机制，你会抄哪套、改哪里"上走。
参考答案
先看两种范式
回答这道题要抓住一个主线：各家在"怎么把团队知识注入 agent"这件事上分成了两种范式——按需加载的能力包和常驻注入的规则，Claude Code 是前者的代表，多数其他 harness 是后者。
Claude Code 创建 skill 的方式
Claude Code 的 skill 是一个标准化的目录结构：带 YAML front matter 的 SKILL.md（name、description、允许的工具），正文写流程，目录里可以放脚本、模板等附属资源。创建上有几个鲜明特点。
一是有专门的"元 skill"来创建 skill。官方提供 skill-creator，你用自然语言描述"我需要一个什么样的 skill"，它会引导你澄清使用场景、然后生成符合规范的 SKILL.md 骨架，包括帮你打磨 description。skill 的创建过程本身就是一次 agent 协作，这个设计自洽得很漂亮。
二是渐进披露机制决定了写法。因为启动时只有 name 和 description 进上下文，所以创建 skill 的核心功夫花在 description 上——它承担召回职责，写得像触发条件而不是功能介绍。正文可以放心写长，反正用到才加载。
三是skill 不是孤立的，和整个体系打通：skill 里可以声明 allowed-tools 限定工具范围，可以被 subagent 引用，可以调用 MCP 工具，和用户级（~/.claude/skills）、项目级（.claude/skills）的分层配置配合，个人沉淀和团队共享分开管理。
其他 harness 的做法
其他 harness agent 创建"类 skill"的方式大致三种。一是静态规则文件：Cursor 的 rules、各类工具认的 AGENTS.md，本质是常驻注入的 markdown 约定，创建方式就是手写文件，全文随会话进入上下文。优点是简单透明，缺点是没有按需加载——规则多了全部堆在上下文里，成本高还互相干扰，也没有触发条件的概念，模型自己判断哪条适用。二是MCP prompt / 插件机制：把可复用流程包装成 MCP server 暴露的 prompt 模板，按需调用，思路接近 skill，但创建成本高（要写 server），且缺少 description 自动召回的惯例，更依赖显式调用。三是自研 harness 里的配置化 skill：不少团队仿照 Claude Code 实现了自己的目录式 skill，但往往简化掉了工具绑定和分层加载。
区别的本质
归纳起来，差异在四个维度：加载时机（渐进披露 vs 全量注入），这决定了 skill 库能不能规模化；召回方式（description 自动匹配 vs 模型自己从规则堆里找），这决定了触发准确率；可组合性（能否带脚本、绑工具、被子 agent 引用 vs 纯文本），这决定了 skill 是"能力"还是"建议"；创建体验（元 skill 引导生成 vs 手写），这影响沉淀知识的门槛。
我的判断是 Claude Code 把 skill 当成一等公民的工程设计，其他家多数还停留在"提示词文件"的层面。但这个格局变化很快，按需加载的思路明显是对的，各家都在跟进。
可能的追问
让你给自研 agent 设计 skill 机制，你会怎么做？ 抄 Claude Code 的骨架（目录 + front matter + 渐进披露），加两样我们自己需要的：触发埋点用于召回率分析，以及 skill 的版本管理与灰度——团队场景下一个坏 skill 的影响面比个人工具大得多。
静态规则文件会被淘汰吗？ 不会完全消失，全局无条件约束（安全红线、代码风格底线）放常驻规则反而比 skill 合适，因为不该依赖召回。两者是分工关系：规则管"永远成立"，skill 管"按需触发"。
MCP prompt 和 skill 会不会融合？ 方向上在融合——MCP 解决跨工具互通，skill 解决知识封装，理想的形态是 skill 作为上层抽象、底层能力走 MCP，现在已经有产品往这个方向做。