00:00:00事实证明，使用 Skills 可能并非为智能体提供额外上下文的最佳方案，回归 agents.md 文件反而效果更好。
00:00:08这是 Vercel 在测试如何为编程智能体提供 Next.js 文档的最佳方法时，得出的一个令人意外的结论。
00:00:15那么，让我们直接进入正题，拆解一下究竟发生了什么、原因何在，以及这对于有效使用编程智能体有何启示。
00:00:26正如我所说，Vercel 的目标是为编程智能体提供额外的上下文（在本例中是 Next.js 文档），这样当你使用智能体编写 Next.js 代码时，它能了解所有最新的 API，因为其中一些可能尚未包含在训练数据中，甚至情况恰恰相反。
00:00:41你可能在使用旧版本的 Next.js，并希望确保智能体仅使用该版本中可用的方法。
00:00:47他们想要一套版本匹配的文档系统供智能体使用。
00:00:51为此，他们测试了两种常用的方法。
00:00:54首先是我们的 Skills。
00:00:56Skills 最近非常流行，许多框架和工具都已发布或正在发布相关功能。
00:01:01讽刺的是，Vercel 正是推动其普及的幕后功臣之一，他们推出了 Skills CLI 和相关的 Skills 仓库。
00:01:08强烈建议大家去看看。
00:01:09如果你还不了解 Skills，它们其实是 Anthropic 提出的一种开放标准，本质上是指令、脚本和上下文的模块化捆绑包，智能体可以按需加载，从而更准确地执行任务。
00:01:20但关键细节在于：完全由智能体来决定何时加载这些信息。
00:01:26而这正是目前的硬伤所在。当 Vercel 进行评估测试时，他们发现有 56% 的情况下，Skill 从未被调用。
00:01:35智能体就是决定不去使用它。
00:01:37令人惊讶的是，在评估中，为智能体提供 Skill 相比于完全没有 Skill 的智能体，性能居然没有任何提升。
00:01:44更让人意外的是，他们发现 Skill 甚至可能产生负面影响。
00:01:48在未使用 Skill 的情况下，其表现有时甚至不如基准线，这表明未使用的 Skill 可能会引入噪音或干扰。
00:01:57为了解决这个问题，他们尝试在提示词中明确要求“请使用此 Skill”。
00:02:02这确实奏效了，将 Skill 的触发率提高到了 95%，并将评估通过率提升至 79%。
00:02:09但也随之带来了新问题。他们发现不同的措辞会产生截然不同的结果。
00:02:15例如，如果你只说“你必须使用该 Skill”，它确实照做了，但随后它会忽略项目本身的上下文。
00:02:21所以你不得不说“同时使用该 Skill 和项目上下文”。
00:02:24Vercel 非常不喜欢这种系统的脆弱性，并指出如果微小的措辞调整就能导致巨大的行为波动，那么这种方法在生产环境中使用就显得太不稳定了。
00:02:33因此，他们需要一个更可靠的方案，最好是一个无需智能体自行做出决策的方案。
00:02:40于是他们尝试了 agents.md 文件。
00:02:42这其实是一种许多智能体都在使用的开放格式。如果你是 Claude 的粉丝，这与 CLAUDE.md 完全一样。
00:02:49它用于向编程智能体提供指令，且这些指令始终包含在系统提示词中。
00:02:53因此，与 Skills 不同，智能体不需要负责决定是否去获取信息。
00:02:58信息已经存在于其系统提示词中了。但这本身也可能产生上下文过载的问题。
00:03:03也就是说，当你的上下文增加时，输出质量反而会变差。
00:03:06所以，你总不能把整个 Next.js 文档都塞进 agents.md 文件里吧。
00:03:10那该怎么办呢？为了解决这个问题，Vercel 在 agents.md 中仅使用了一个文档索引。
00:03:17简单来说，它只是文件系统中各个具体文档文件的路径列表。
00:03:22然后，另一个关键点是添加一条指令，要求“在处理任何 Next.js 任务时，优先使用基于检索的推理，而非基于预训练知识的推理”。
00:03:31我个人读到这里时，本以为这会导致和 Skills 类似的结果，因为智能体仍然需要去查找并读取那些文档文件。
00:03:38但当他们在评估中进行测试时，智能体在所有项目中都获得了 100% 的分数，并在构建、代码检查和测试评估中获得了完美评分。
00:03:47因此，它明显比 Skills 更可靠、更准确。这有点像经典的软件工程：即那个看起来更“笨”、更简单的方案，往往才是最好的，你根本不需要过度设计。
00:03:53但为什么会这样呢？为什么 agents 文件优于 Skills？这其实很难解释清楚。
00:03:58AI 在某种程度上是个黑盒，但 Vercel 推测这归结为三个因素，而且都与决策有关。
00:04:03当你使用 agents 文件时，智能体不存在决策点。
00:04:10我们在一开始的系统提示词中就直接告诉它要使用文档，并明确告知每个文件的位置。
00:04:14这样知识就变成了持久化的上下文，而不是让模型自行决定是否按需调用的按需内容。
00:04:20因为它已经包含在系统提示词中，所以直接存在于推理过程中。
00:04:27但这并不意味着 Skills 就完全没用了。事实上，Vercel 发现两者其实是可以互补的。
00:04:31他们表示，Skills 更适用于由用户触发的明确工作流，比如指令“升级我的 Next.js 版本”、
00:04:36“迁移到 App Router”或“应用某些框架最佳实践”。
00:04:41但如果你希望编程智能体具备通用的框架知识，
00:04:45那么使用 agents.md 提供的被动上下文，其表现会优于 Skills，尤其是在目前的模型水平下。
00:04:48我相信未来的模型会针对基于 Skill 的检索工作流进行优化，但现在还没到那个阶段。
00:04:54目前，Vercel 给出的建议是——特别是对于框架作者或那些准备编写 Skills 或 agents.md 的人来说：
00:04:59不要坐等 Skills 的性能提升。应尽可能压缩你的上下文。
00:05:06为检索而设计，而非为记忆而设计。最重要的是，始终通过评估测试（evals）来验证一切。
00:05:10如果你只是这些文件的使用者，Vercel 现在提供了一个工具，可以下载针对你特定 Next.js 版本的文档
00:05:16以及预构建好的 agents.md 文件，让你能够立即体验这种新方法带来的优势。
00:05:21我很想知道其他工具是否也会采取这种做法。我也很想听听你们对此的看法。
00:05:29欢迎在下方评论区告诉我你对 Agents 和 Skills 的想法。
00:05:34顺便点个关注。一如既往，我们下期再见。
00:05:37And while you're there, subscribe. As always, see you in the next one.