Claude Skills 火了，但大多数人没看懂它真正解决的问题

发现一个很有意思的现象，模型能力已经不是瓶颈了。

Claude、GPT 这些大模型，生成能力都够用。完成任务本身，早就不是什么难事。

真正让人头疼的，是系统怎么处理判断。

我们把太多本该固化下来的东西，交给模型每次临场发挥。

这个问题刚开始其实看不出来。Agent 第一版跑得挺好，一个 prompt 配几个工具调用，流程就通了。

但随着业务场景变多，上下文开始叠加各种历史约束，需求从一次性任务变成持续运行，问题就来了。

系统行为开始变得不可预测，但你又定位不了问题在哪。

模型参数没变，数据分布看起来也没变，逻辑路径大体一致。

结果就是有时对、有时不对。

这种状态在工程上其实挺危险的。

关键不在于模型稳不稳定，而在于我们是不是在逃避一个更基础的问题。

哪些判断应该被固化成系统能力？哪些判断才值得每次重新推理？

如果所有判断都让模型即时完成，系统规模越大，不确定性就被放大得越快。

从这个角度再看 Claude Skills，会发现它解决的不是怎么让 Agent 更聪明。

Anthropic官方发布Agent Skills

它解决的是一个更底层的工程问题。

怎么把反复验证过的能力，从不透明的 prompt 行为里拆出来，变成可管理、可复用、可回收的系统组件。

Anthropic 在 AI Engineer 大会上甚至直接喊出了这个观点。

Don't Build Agents Build Skills Instead

不要构建 Agent，要构建 Skills。

Skill 的价值不在于能力本身。

在于它让经验第一次有了长期资产的形态。

一个 Skill 的结构其实很简单。

Skill文件夹结构

SKILL.md 是核心指令，定义触发条件和执行流程。scripts 放可执行代码，references 放参考文档，assets 放素材资源。

本质上就是把散落在 prompt 里的经验，用文件夹的方式结构化沉淀下来。

也正是这个背景下，像特赞科技 atypica.AI 团队提出的 skill0（https://skill0.io/）这样的能力承载层开始显得必要。

skill0平台首页

当系统里的 Skills 从十几个增长到几十个、上百个，工程问题就变得很具体了。

哪些能力已经被验证？哪些还在实验阶段？不同团队是不是在重复造轮子？

skill0的skill-installer详情页

如果这些问题没有一个明确的系统层来承载，所谓的 Agent 架构，最终一定会退化回 prompt 的堆叠。

当能力被 Skill 化之后，Agent 本身的定位也会变。

它不再是一个会做很多事的执行体，更像一个调度者。

理解上下文、做路径选择、判断要不要调用某种能力。

执行的确定性尽可能被 Skills 吸收，不确定性才留给推理层处理。

这时候系统的关注点自然会从输出是否漂亮，转向判断是否正确。

目前行业里其实还没有一个被广泛接受的概念，能完整描述这种以判断为中心、由 Skills 和上下文共同驱动、面向长期运行的 Agent 系统形态。

我们看到的更多是零散的说法。

Agentic AI、Multi-Agent Systems、Tool-augmented LLMs，各自指向系统的一部分，但很少覆盖完整形态。

也因为缺乏公共语言，不同团队讨论类似问题时，只能反复用长句解释架构假设，而不是直接指向一个明确的系统类型。

最近看到特赞科技的 atypica.AI 团队提到了 GEA（Generative Enterprise Agent），我觉得这个概念对了。

GEA架构图

GEA 这种架构思路不是一个新名词，而是一种工程上的自我约束。

在企业级系统里，生成永远不是第一步，判断才是。

左边是外部基础设施，LLM、MCP、APIs 这些能力层。中间是核心流程，从意图理解到推理到执行再到输出。右边是上下文系统，Memory、Assets、Skills 构成的知识库。

Skills 负责把正确的经验规模化，上下文负责约束判断的适用范围，推理层的任务是在复杂环境中做取舍，而不是一味执行。

这是一种工程理性的回归。

当 AI 开始真正进入生产系统，判断能力、结构清晰度和长期可演化性，终究会比短期的能力炫技更重要。

文章来自于“AI产品普洱”，作者 “AI产品普洱”。