Anthropic工程师弃用单体Agent：技能化AI构建的4个关键

从造Agent到造技能：AI构建思路的转向

Anthropic的两位工程师Barry Jeng和Mahesh Murag——正是技能（Skills）机制的创造者——最近抛出一个反直觉的观点：他们不再为每个任务单独重建一个智能体了。原因在于底层模型的通用能力已经远超预期，与其反复造轮子，不如给同一个通用智能体配上可复用的"技能"。

这个转向可以用手机来类比：模型好比处理器，智能体运行时好比操作系统，而技能就是一个个应用。处理器和操作系统由少数厂商提供，你几乎不会去改动它们，但你可以自由安装应用，每个应用赋予同一部手机一项具体能力。Claude Code已经能读文件、写代码、调用工具完成任务，你没必要每次做演示文稿、调研公司或写LinkedIn帖子时都从头搭建一遍——只需要给它一个包含流程、上下文、脚本和事例的技能。

这套思路正在重塑AI的搭建方式。下面拆解让技能真正好用的四个关键点。

关键一：把验证过的代码存下来，别重复发明

Anthropic团队反复观察到一个现象：Claude每次给幻灯片套样式时，基本都在写一模一样的Python脚本。这会消耗大量token去重建已经写过的代码，而且每次从头生成的结果都可能不一样，一致性很差。

解决办法很直接——让Claude把脚本保存进技能里，用他们的话说是"给未来的自己留一个工具"。下次需要套样式时，直接跑那个已经验证过能用的版本即可。这其实就是软件开发里的DRY原则（Don't Repeat Yourself，不要重复自己）：解决方案一旦成型就存下来复用，而不是每次重写。

实操上，当Claude给出一段你满意的脚本时，别让它困在聊天记录里丢失。开新对话时告诉它：把刚才用的脚本存到技能的脚本文件夹，更新技能MD文件，以后直接执行那个文件。然后再跑一遍验证结果。关键在于对比同一任务的两次输出，确认技能确实在调用保存好的文件。输出可能仍有细微差异，但你已经用一段验证过的代码替换了一次全新的猜测。

关键二：给技能精确的描述，让Claude只加载对的那个

像修车师傅换轮胎前不会把几百件工具全倒在台面上一样，Claude也不会一启动就读完所有技能的完整说明。Anthropic设计了"渐进式披露"机制：启动时只读每个技能的名称和描述（即YAML前置元数据），当你的提示词匹配到某个技能描述时，才去读完整的技能MD文件，更大的参考文件和脚本则留在文件夹里按需加载。

这种"按需加载"能把不相关的指令挡在工作上下文之外，避免臃肿和所谓的"上下文腐化"。但前提是描述写得足够清楚。如果一个技能写"帮忙处理内容"，另一个写"创建营销素材"，描述重叠又没说明触发时机，Claude只能靠猜。

更好的写法是用真人语言说清用途和触发条件，比如"这个技能可以根据主题、文字记录或大纲生成领英轮播图，当用户要求做轮播图、轮播幻灯片或领英帖子时使用"。你甚至可以让Claude Code自我审查：列出每个技能的功能、触发时机以及与其他技能的重叠，只重写含糊的描述。之后用三种请求测试——明显请求应触发、换种说法仍应触发、完全不相关的请求绝不能触发。记住：一个找不到的技能，基本等于不存在。

"上下文腐化"（Context Poisoning/Context Bloat）是大语言模型应用中一个常见的工程问题。由于模型在推理时需要将所有上下文信息一并处理，如果上下文窗口中塞入了大量不相关的指令、工具说明或历史记录，模型的注意力会被分散，导致它在相关任务上的表现反而下降。这类似于人在嘈杂环境中试图专注于一件事——背景信息越多，聚焦越难。YAML前置元数据（Front Matter）是一种在Markdown文件顶部用---分隔符包裹的结构化数据格式，常用于存储文件的元信息，如标题、描述、触发条件等。Anthropic的渐进式披露机制正是利用这一格式，让系统在初始化阶段只解析轻量的元数据字段，而不必将每个技能的完整内容全部载入上下文，从而在技能数量增多时保持系统响应的精准性和效率。

关键三：把每次纠正沉淀为持久指令

很多人纠正Claude后随手关掉对话，那条教训也就丢了。也许它用错了语气、跳过了验证步骤、或把输出格式弄成你再也不想看的样子。如果只说"修一下"，它大概会修好，但流程本身仍然是坏的。

更好的做法是让智能体回溯，展示它的工作过程——比如遇到"找不到文件"时，不要直接把路径塞给它，而是让它说明搜了哪里、为什么漏掉，然后更新路由或技能，让下次运行从正确的地方开始。

技能存储的是完成特定任务所需的程序性知识，而非每次对话的录音。因此当流程有问题就更新技能MD里的指令；缺少语气、品牌或事例就加一个参考文件；同一个错误反复出现就加一条明确规则专门防止它。然后重新运行同一任务验证修复。随着时间推移，技能就变成了"你想如何完成工作"的活记录。

需要澄清的是：没有任何技能能让弱模型表现得和强模型完全一样，不同模型的输出和理解方式仍有差异。但你的流程是可移植的——Agent Skills是开放格式，同一个skills文件夹可以在Codex、Hermes等兼容框架间通用。拿关键技能到另一个框架测试，如果崩了，就去找隐藏假设或只有某个模型才懂的指令，再收紧技能。

这里提到的"程序性知识"（Procedural Knowledge）来自认知科学，指"知道如何做某件事"的知识，有别于"知道某件事是什么"的陈述性知识。技能文件存储的是完成任务的步骤、规则和流程，而不是某次对话的具体内容，这使得它的积累方式更接近于企业的标准操作程序（SOP）而非聊天记录归档。文中提到的Agent Skills开放格式，意味着技能文件夹本身是跨框架可移植的规范，不绑定于特定的AI平台。Codex和Hermes是支持该格式的兼容框架示例，这种互操作性降低了厂商锁定风险——用户积累的工作流知识存储在通用格式中，可以随着工具链的演进而迁移，而不必从零重建。

关键四：让技能自带验证，别把初稿直接丢给你

这一点可能最重要，也是众多AI工作流中最大的缺口。技能生成东西、保存文件后跟你说"搞定了"，你一打开却发现格式乱、来源撑不住结论、脚本对目标受众毫无效果。AI完成七八成，剩下两三成还得人来收尾。

如果你已经知道怎么亲自检查，那就把检查步骤写进技能。做幻灯片时，让它把每页渲染成图片、检查截图、修复被裁剪或超出边界的地方再重新渲染；做研究报告时，让它打开原始来源把论点和证据对应起来，删掉无法验证的内容。

对于更主观的内容，可以设置多个子智能体扮演不同角色审阅：新手告诉你哪里困惑，怀疑型买家告诉你他们不信什么，目标受众告诉你他们在哪里会滑走。你不必接受每一条反馈，但技能能找出反复出现的问题做出最有力的修改。

关键在于：验证不能是让Claude读自己的作品然后说"看起来不错"，它需要出稿之外的客观证据——截图、测试结果、来源参考或多角色反馈。可以给几乎任何技能加上这样的流程：先定义验收标准，创建初版，用验证方法检查，修好所有问题再重跑，全部达标才输出，并附上检查了什么的简短总结。无法验证的地方就明确告知。这样你第一眼看到的不该是智能体的初稿，而是它自我审查过第四、第五甚至第六次的成品。

多智能体审阅（Multi-Agent Review）是一种通过设置多个具有不同角色预设的AI实例来模拟多视角评估的技术手段。其理论依据在于：单一模型在审阅自己生成的内容时存在系统性偏差——它倾向于认同自身的推理路径，难以发现逻辑漏洞或受众体验问题。通过给不同子智能体赋予"怀疑型买家""目标读者新手"等角色提示，可以在一定程度上打破这种自我确认偏误，获得更多元的反馈信号。这种做法本质上是在工作流内部模拟人工审稿流程，将原本需要人工干预的质检环节自动化。值得注意的是，多智能体反馈并不等同于真实用户测试，在涉及高度情境化判断（如品牌语气、文化敏感性）的场景中，仍需人工最终把关。

结语：用一个通用智能体，教它按你的方式干活

把这四点串起来，Anthropic工程师真正在构建的其实是一套可自我进化的系统：存下验证过的代码而不是重写，给每个技能配精确描述让Claude只加载正确的那一个，把每次修正转化为持久指令，并在你看到之前就完成验证。

最终拍板的仍然是人——尤其涉及品味、策略和商业判断时。但目标是把AI能自己发现的问题交给它处理，让你不再浪费精力去抓那些低级错误。这也是从"盲目造Agent"走向"技能化构建"的核心价值所在。