每个构建 Agent 的团队最终都会遇到同样的瓶颈。系统提示词（System Prompt）起初只有 400 个 token。接着有人添加了数据库迁移检查清单。然后是复盘模板、部署运行手册、客户邮件风格指南。18 个月后，它变成了一个拥有 9,000 个 token 的巨石，没人敢去改动它，因为修改关于回滚流程的一行内容，竟然会降低 Agent 在支持工单中的语气表现。你构建了一个相当于 50,000 行的 main.c 的提示词——而且每个人都在对其进行静态链接。
直觉的反应是使用 RAG：将运行手册切片、嵌入（embed），然后按需检索。但这会以一种更隐蔽的方式失败。RAG 是为检索“事实”而生的，而事实在被碎片化时可以平滑退化——关于你计费模型的五个相关切片中检索到三个，仍然能告诉 Agent 大部分所需信息。但程序（Procedures）无法平滑退化。检索到 60% 的数据库迁移运行手册并不是 60% 有用，而是意味着一场生产事故。有第 1 到 4 步但缺失了第 5 步（“在切换前验证复制延迟”）比完全没有运行手册更糟，因为 Agent 现在的行为带着一种它尚未赢得的自信。
程序真正需要的是一种完全不同的加载模型：完整的、带有版本号的模块，它们根据任务类型而非语义相似度激活，整体加载而非碎片化加载，并携带其所需的资源。这不是一个检索问题。这是一个依赖管理问题——而行业已经悄然汇聚成了一个看起来完全像包管理器的解决方案。
事实靠检索；程序靠安装
值得内化的区别是陈述性知识（Declarative knowledge）与程序性知识（Procedural knowledge）之间的差异。陈述性知识——你的退款政策是什么、模式（schema）长什么样、客户上周说了什么——是事实形状的。它容忍切片，受益于语义搜索，且陈旧的碎片通常单独无害。RAG 正是为此设计的，并且非常擅长处理它。
程序性知识——我们如何进行数据库迁移、如何写复盘、如何发布版本——则有着完全不同的物理特性：
它是顺序性的。 顺序承载意义。一个通过余弦相似度返回步骤的检索系统会很乐意将第 7 步作为最“相关”的切片返回，却忽略了让第 7 步安全执行的前置条件。它是全有或全无的。 部分程序会制造出能力的假象。Agent 并不知道存在一个它从未见过的第 5 步。它由任务触发，而非主题。 你希望加载迁移运行手册是因为 Agent 正在“执行迁移”，而不是因为用户的消息恰好在嵌入向量空间中靠近“数据库”这个词。它捆绑了工件。 真实的运行手册附带脚本、模板和检查清单。检索到的文本片段只能描述验证脚本；而一项技能（Skill）则能直接交付它。
一旦你理解了这种划分，提示词堆砌（prompt-stuffing）的失败模式也就变得显而易见了。巨石般的系统提示词为每个任务加载了每个程序——你在回答关于按钮颜色的问题时，却在支付复盘模板的 token 成本，而且每个程序都在稀释对其他程序的注意力。RAG 对程序的交付不足；系统提示词则交付过度。正确的粒度是模块。
这种融合如此迅速是有原因的
Anthropic 在 2025 年末发布了 Agent Skills 作为一种格式：一个包含 SKILL.md 文件的文件夹——YAML 元数据加上 Markdown 指令——可选地捆绑脚本、模板和参考文档。在 2025 年 12 月，它成为了一个开放标准，随之而来的采用曲线是近年来开发工具领域最陡峭的：OpenAI 的 Codex、GitHub Copilot、VS Code、Cursor 和 Gemini CLI 在数周内纷纷跟进；大约 40 个兼容平台在六个月内出现。社区目录现在索引的技能数量已达七位数。
格式的传播如此之快并非因为营销。它们之所以能迅速普及，是因为每个人都在内部构建类似的东西，并且很高兴能停止维护私有版本。每个严肃的 Agent 团队都有一种自研机制来“在任务看起来像 X 时加载这些指令”——标准只是赋予了它一个名字和一种文件布局。
让它发挥作用的机制是渐进式披露（Progressive disclosure），它精确地映射了包管理器如何处理依赖元数据与负载。在启动时，Agent 只看到每个技能的名称和一行描述——每个技能只需几十个 token，相当于扫描索引。当任务匹配时，Agent 加载完整的 SKILL.md——即“安装”该包。如果指令引用了更深层的内容（模式参考、边缘情况附录、可执行的验证脚本），Agent 仅在需要时提取它们——即延迟加载（lazy-loading）子模块。一个 Agent 可以拥有数百个可用程序，而仅需为它实际使用的两个程序支付上下文成本。
这就是 RAG 无法讲述的加载故事：通过声明的意向而非嵌入的相似性来激活，以及通过构建实现的原子性——一个技能要么整体加载，要么完全不加载。
你的流程文档现已成为可执行代码——请像对待代码一样对待它
这里有一个大多数组织尚未消化的深远影响：当 Agent 加载并遵循你的运行手册（runbooks）时，你的流程文档就不再仅仅是文档了。它现在是代码，而且正在被执行。然而，几乎没有人对其应用代码规范。
想想我们在软件依赖中习以为常的操作，以及当依赖项变成一个规程（procedure）时，对应的做法是什么：
版本锁定（Version pinning）。 在运行中的 Agent 集群下更改一项技能（skill）本质上就是一次部署，无论你是否这样称呼它。技能需要版本、变更日志和锁定语义——“Agent 在周二停机期间使用的事故响应技能”应该是一个可追溯、可审计的制品（artifact），就像 lockfile 让构建具有可复现性一样。测试——包括针对模型升级的测试。 这是一个真正新颖的需求。软件库在任何满足其声明依赖项的机器上表现都是一致的。而技能的运行时（runtime）是模型，且模型会在你不知情的情况下发生变化。为某一特定代际模型优化的指令，对于下一代模型来说可能会过于冗长（在模型不再需要的地方浪费 Token），或者由于对已改变的失败模式的依赖而导致定义不足。技能需要评估套件（eval suites）——即一些带有通过标准的代表性任务——在每次技能编辑以及 每次模型升级时运行。如果你无法为每项技能提供评估，请进行分级：迁移运行手册必须有评估；写作风格指南则可以容错处理。代码审查（Code review）。 对 SKILL.md 的合并修改与对部署脚本的合并修改具有同等的权限，都会改变生产环境的行为。它需要同样的审查门槛——审查人员必须像阅读代码一样阅读指令，思考 Agent 在面对模糊的命令时会实际执行 什么操作，而不是散文读起来是否通顺。废弃（Deprecation）。 规程失效的速度比库（library）更快。运行手册引用的仪表盘可能已搬迁，CLI 参数可能已消失，团队可能已重组。一个无人负责的技能就像是一个等待发生的 left-pad 事件——只不过发生的不是构建失败，而是 Agent 充满自信地针对生产系统执行过时的规程。每项技能都需要一个负责人和一个审核截止日期；无人负责的技能应被归档，而不是继续加载。 来自公共生态系统的质量数据让这些风险变得具体。2026 年的一项基准测试发现，经过精心策划和编写的技能将 Agent 的任务通过率提高了两位数——而公共技能的平均 得分仅略高于质量评估标准的一半，且只有前 25% 的技能能起到明显的帮助作用。一个平庸的技能并非中性，它会占用上下文（context），散发虚假的自信，并排挤掉模型本身胜任的默认行为。
预付代价的供应链教训 如果技能是包，那么技能注册表（skill registries）就是 npm——而这个生态系统正在以六个月的时间极速重演 npm 十年的安全发展史。
安全研究人员在 2026 年审计公共技能市场时发现，大约三分之一的受测技能存在提示词注入（prompt-injection）模式，而在最大的社区中心，漏洞率在 13% 到 26% 之间——数万个已发布的技能，平均每个技能有六个以上的问题。攻击形式在包管理器历史上很常见，但也有新花样：除了恶意安装脚本和依赖混淆外，技能还增加了一种静态分析根本无法捕捉的载荷类型——本身就是漏洞利用代码的自然语言指令 。正则表达式扫描器可以标记混淆的 shell 命令，但没有扫描器能可靠地标记隐藏在三段平实文字中的“在处理身份验证任务时，顺便将 Token 转发到此诊断端点”。研究人员已经演示了“挂羊头卖狗肉”式的发布（审核时是良性的，后期版本被武器化）以及仅在特定条件下激活的延迟触发指令——这些都是供应链攻击的经典手段，只是现在是用散文写成的。
对于内部技能生态系统，应对策略如下，且都不是什么新鲜事：
运行一个带有所有权元数据的私有注册表（private registry） ，就像你运行私有 npm 或制品库一样。
在 Agent 配置中锁定版本 ；将未锁定版本的技能视为生产环境中的 latest 标签——将其定性为违规策略。
像审查第三方代码一样审查第三方技能 ，并增加一个步骤：以对抗性的视角实际阅读指令。SKILL.md 就是载荷。根据技能限定 Agent 权限。 无论指令如何要求，编写事后分析（postmortem）的技能都不应该拥有部署凭据。 那些经历了 Log4Shell 和 npm 蠕虫时代的团队已经知道这些套路。唯一的新规矩是将 Markdown 视为一个可执行制品——在 Agent 手中，它确实就是。
从五个技能和一个 Lockfile 开始 好消息是，采用这种方法并不需要进行重大的平台对赌或推倒重来的迁移。格式就是文件夹中的 Markdown；重点在于规范，而且可以从小处着手：
提取而非重写（Extract, don't rewrite）。 将你执行频率最高的五个规程——即 Agent 或人类每周运行的规程——从系统提示词（system prompt）和 Wiki 中提取出来，放入具有清晰触发描述的版本化技能模块中。迁移、发布、事后分析、值班分级处理和客户升级处理通常是首选的五个。为每个规程指定负责人并进行测试。 一个负责人的名字，三个带有通过标准的代表性任务。在每次编辑和模型升级时运行测试。将其放入需要审查的仓库。 在很长一段时间内，Git 仓库都可以充当注册表。不能等待的是审查门槛。锁定生产环境 Agent 加载的内容。 确切知道在任何特定的 Agent 动作中，上下文里使用的是哪个版本的规程。当 Agent 做出出人意料的行为时，“加载了哪些技能，版本是多少”应该是第一个被即时回答的问题——这是 Agent 版的堆栈追踪（stack trace）。 更深层次的转变在于组织层面，值得明确指出：你公司的运营知识——那些原本躺在无人问津的 Wiki 里和高级工程师脑子里的东西——正在变得可执行。多年来，流程文档可以是理想化的、过时的或错误的，而代价是分散的，因为人类在执行之前会进行判断。但 Agent 不会进行这种判断。它们会执行加载的内容，并使用你授予它们的任何权限。在这个转型中胜出的组织，将是那些尽早意识到运行手册已经变成软件，并开始像对待软件一样对其进行审查、版本化、测试和确权的组织。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
