在 Claude Code 里创建 Agent 这件事，看起来门槛很低。建一个 markdown 文件，写一段 system prompt，放到 agents 目录，完事。但真跑起来你会发现，Agent 不触发、触发了行为跑偏、或者 prompt 太长 Claude 直接忽略关键约束，这些问题出现的频率远比想象中高。
agent-identifier 是 Anthropic 在 Smithery.ai 上发布的一个技能，专门解决 Agent 开发的标准化问题。它不是什么黑魔法，本质上是一套经过验证的模板和规则，把 Agent 创建从”凭感觉写 prompt”变成了”按规格填参数”。这套规则来自 Claude Code 插件生态的实际工程经验，不是凭空想象的最佳实践。
我花了一个下午把它的 SKILL.md 从头到尾拆了一遍。说实话，一开始我的期待并不高，Agent 开发能有什么新鲜的？但读完之后发现，它把很多我踩过的坑都系统化了，而且给出了足够具体的操作指引。
使用场景
agent-identifier 面向的场景非常明确：你要给 Claude Code 插件创建一个自治子进程。它不适用于写普通的 slash command，也不适用于那种”用户点一下才执行”的交互式功能。Agent 和 Command 的边界就在这：Agent 是主动干活，Command 是等用户叫。如果你不确定该用 Agent 还是 Command，一个简单的判断标准：这个功能能不能在没有人持续干预的情况下跑完整个流程？能，就是 Agent。每一步都要等用户拍板，就该用 Command。
举个例子。你做了一个代码审查插件，想让 Claude 在每次代码变更后自动触发审查流程。这个审查流程涉及好几个环节：
-
读取变更文件 -
搜索已知的代码异味模式 -
比对 diff 找出新增问题 -
生成结构化的审查报告
整个链路是自治的，不需要用户在中间插话。这就是 Agent 的典型场景。Command 更像是快捷键，Agent 是给你配了个助理。
这个技能给出的 Agent 定义文件格式非常清晰。前端 YAML frontmatter 管元数据，name 是标识符，description 是触发条件，model 和 color 控制行为和展示，tools 做权限控制。正文部分直接就是 agent 的 system prompt，用第二人称写给 agent 自己。
有个细节容易忽略：description 里的 example 块是触发 Agent 的关键。Claude Code 会拿 description 里的 example 去匹配用户输入，匹配上了才加载这个 Agent。description 写得太泛，Agent 永远不会被唤醒。写得太窄，又容易漏掉合理的触发场景。技能里给了 2-4 个 example 的具体写法，连 commentary 标签怎么填都明确了。
操作流程
agent-identifier 本身的结构就是一份操作手册。它把创建一个 Agent 拆成了两条路径：AI 辅助生成和手动创建。两条路径共用一个最终的输出格式，差异只在你怎么到达那个终点。
先说手动创建。流程是线性的，7 步走完：
-
选定 agent 标识符，遵守 3-50 字符、小写加连字符的格式约束 -
写 description，必须包含触发条件说明和多个 example 块 -
选 model，绝大多数情况用 inherit -
分配颜色做视觉区分，同类 Agent 用同色 -
定义 tools 列表，遵循最小权限原则 -
写 system prompt，用标准模板结构 -
保存到 agents 目录
每一步技能里都给了正例和反例。标识符这块的反例特别典型：helper 太泛，-agent- 首尾是连字符，my_agent 用了下划线，ag 太短。这些错误单独看都很傻，但实际开发中就是会犯，因为你急着想先把东西跑起来。
AI 辅助路径更有意思。它提供了一个固定的 prompt 模板，你只需要描述你想让 Agent 做什么，然后把这个描述填进模板，让 Claude 帮你生成完整的 Agent 配置。输出格式是结构化的 JSON，包含 identifier、whenToUse 和 systemPrompt 三个字段。拿到 JSON 之后再转成带 frontmatter 的 markdown 文件就完事了。
system prompt 的设计是整份技能最重头的部分。它给的模板不是”你是一个 XX 专家”这种敷衍了事的套路，而是一个六层结构：
-
角色定位：说清楚你是谁 -
核心职责：用编号列出要做什么 -
分析流程：step-by-step 的具体步骤 -
质量标准：输出必须满足什么条件 -
输出格式：返回内容的结构规范 -
边界情况：遇到异常怎么处理
每一层都有明确的内容要求。“分析流程”那部分尤其关键，它让你必须写出可执行的步骤，不是笼统的”请分析代码”。这个结构一旦用惯了，你会发现之前手写的 Agent prompt 大多只覆盖了前两层。
洞察与反思
读完整份 SKILL.md，我最大的感受是这个技能的野心其实很小。它不试图覆盖 Agent 开发的所有可能性，也不给一堆大而全的设计模式。它做的事情很聚焦：确保每个 Agent 都有清晰的定义、可靠的触发机制、完整的 prompt 结构。
但正是这种聚焦让它好用。想想你之前手写的那些 Agent，有几个是严格按照这个标准来的？至少我承认，我的 Agent description 经常写得像一句话简介，example 块要么缺失要么只给了一个，system prompt 也常常是”想到哪写到哪”。
这套规范的价值不在于它多聪明，而在于它把隐性知识显性化了。写了多年 Agent 的人可能已经内化了这些规则，但对于刚接触 Claude Code 插件开发的人来说，这份技能相当于一份”Agent 开发驾照”，把所有交规和操作规范一次性讲清楚。
一个让我意外的点是 tools 权限控制。技能明确建议”只给 Agent 它真正需要的工具”，并在 SKILL.md 里给出了不同场景的工具集推荐：只读分析用 Read + Grep + Glob，代码生成用 Read + Write + Grep，测试用 Read + Bash + Grep。这个细节体现了”最小权限”的工程思维，而不是”懒得想就给全部权限”的惰性做法。实际落地的时候你会发现，给 Agent 少一个工具比多一个工具难得多。少给了它报错，你加回来就行。多给了它就可能做你预期之外的操作，而这种事在自治 Agent 场景下排查起来极其痛苦。
不过这个技能也有明显的局限。它假设你的 Agent 都是单文件定义、无状态、同步执行的，对于需要多 Agent 协作或状态管理的复杂场景，这份指南只提供基础结构，更高级的模式需要你自己去扩展。另外，验证工具只给了 shell 脚本，没有提供 CI/CD 集成的现成方案。
还有一个容易被忽略的点：skill 里强调 Agent description 需要 2-4 个 example，但没给出 example 覆盖度怎么衡量。实际开发中你会发现，example 的数量不是关键，关键是 example 能不能覆盖到用户的不同表达方式。同一个人说”帮我做代码审查”和”review 一下这个 PR”，语义一样但措辞完全不同。如果你的 example 只覆盖了第一种表达，第二种就触发不了。
资源地址
| 资源 | 链接 |
|---|---|
| Smithery 主页 | smithery.ai/skills/anthropics/agent-identifier |
总结
agent-identifier 解决的问题其实就一个：怎么让 Agent 的定义不再是一团模糊的”你觉得该怎么写”。给它一个 name 格式规范，给它一个 description 模板，给它一个 system prompt 结构，给它一个验证脚本。这些约束看似限制了自由，实际降低了写烂 Agent 的概率。
如果你已经在用 Claude Code 做插件开发，这份技能值得花半小时过一遍。不需要把每一条都背下来，但至少在下次建 Agent 的时候，翻出来对照一下。尤其是 name 格式规则和 description 的 example 写法，这两个是最容易被忽视但出错后果最严重的地方。name 写错了 Agent 直接加载不了，description 写泛了 Agent 永远不会被唤醒。如果你刚接触 Agent 开发，这份指南的价值就更大了，它让你从一开始就用对的方式思考 Agent 的定义和触发。
最后一句话：好的 Agent 不是靠长 prompt 堆出来的，是靠精确的 description、清晰的职责边界和恰到好处的工具权限组合出来的。这份技能把这个道理讲透了。如果你问我值不值得装，36 个安装量说明它还没有被足够多人发现，但这恰好是个优势：越少人按规范写 Agent，你的 Agent 质量就越容易在插件生态里脱颖而出。