你的第一个智能体工作流始于一个提示词（prompt）和几个工具。它回答问题，查询订单状态。它运行良好，于是你将其发布。

随后产品开始增长。销售部门要求一个能同步会议记录的 CRM 更新器；支持部门需要一个涉及三个内部系统的退款工作流；工程部门增加了用于填写供应商表格的浏览器操作。每个需求看起来都很小。每个需求都有自己的提示词文件、自己的 Slack 讨论串、自己的“快速修复”。六个月后，你的智能体不再是一个统一的系统。它变成了一堆散乱的、被复制的提示词、隐藏的业务规则，以及没人能找到的旧聊天记录中的决策。这就是“提示词蔓延”（prompt sprawl）。它让你的 AI 产品难以测试、难以审查，且无法在出现问题时充满信心地回滚。

解决办法是建立一个 AI 智能体技能注册表（skill registry）。

技能究竟是什么

技能不仅仅是保存在文件夹里的一个提示词。它是一个版本化的、可测试的软件包，定义了智能体要做什么、可以调用哪些工具，以及绝对不能做什么。把它看作是你团队与机器之间的一份契约。当智能体加载一个技能时，它应该准确地知道自己的边界在哪里，以及成功的标准是什么。

如果没有这种结构，每个提示词都会变成一个微小的、未声明的生产系统。它携带了隐藏的权限、嵌入的业务规则，以及无人追踪的成本影响。它会逐渐偏离实际产品，因为产品路线图在向前推进，而提示词却停留在原地。最糟糕的是，它会被复制。有人为了演示而分叉（fork）了它，或者将其粘贴到新的微服务中，现在你拥有了两个在黑暗中逐渐分歧的“事实来源”（sources of truth）。

为什么仅靠提示词会失效

提示词看起来像文本，所以团队会像对待配置一样对待它们。但实际上，它们比任何人承认的都要更接近代码（code）。生产环境中的提示词通常编码了关于顺序、格式、错误处理和访问控制的逻辑。当这些逻辑仅存在于自然语言中时，就会产生歧义。智能体是有权更新 CRM，还是提示词仅仅是提出了建议？如果计费 API 宕机了，提示词是否知道如何安全地失败，还是会幻觉出一个成功消息？

成本是另一个隐形杀手。一个要求智能体“逐步思考并广泛搜索”的提示词，在每次运行时都可能消耗大量 token。当该提示词被复制到高流量的支持流程中时，你的每月推理账单会翻倍，而且没人知道为什么。

当业务发生变化而文本没有变化时，就会发生“漂移”（drift）。例如，你的退款政策现在要求超过一定阈值的退款必须经过经理批准。如果该规则存在于提示词内部而非策略层中，你就必须搜寻每一次部署，以找到需要更新的副本。漏掉一个，你的智能体就会发放不该发放的资金。

生产级技能的构成

如果你想摆脱这种混乱，请像对待软件制品（artifact）一样对待每一个技能。一个实用的生产级技能不仅仅包含文本，它还需要：

  • 名称与用途。 不要用 prompt_v3_final，而要用 process_standard_refund，并附带清晰的业务目标描述。
  • 输入模式（schema）与所需上下文。 定义技能预期的确切字段。它是否需要用户 ID、对话历史或租户标识符？在这里使用强类型可以防止智能体进行臆测。
  • 工具权限与安全限制。 明确列出技能可以调用的工具。为重试、支出限制和速率限制设置护栏（guardrails）。如果技能不应触碰用户删除 API，请在代码中明确说明，而不仅仅是在散文中描述。
  • 成功标准与测试用例。 技能能运行并不代表它“有效”。定义输出必须包含的内容。对于退款技能，成功可能意味着生成了经过验证的交易记录、发送了电子邮件确认，并创建了审计日志条目。
  • 版本历史与所有者状态。 需要有人负责。变更日志（changelog）应当解释为什么存在 v2.3，以及 v2.2 中哪里出了问题。

拆分你的层级

团队犯下的最大错误是将所有内容都塞进一个提示词中。他们将友好的引导、工具文档、安全策略和错误处理混杂在一起，形成一大堆文字。这是无法维护的。

将其拆分：

  • 指令 (Instructions) 是对 Agent 的引导。它们解释了语气、格式和总体方法。
  • 工具规则 (Tool Rules) 告诉 Agent 存在哪些工具以及它们的作用。这是为了发现工具，而不是授予权限。
  • 策略 (Policy) 是由代码强制执行的，而不是靠祈祷。如果超过 500 美元的退款需要第二双眼睛进行审核，那么这项检查应该存在于一个验证函数中，该函数会在调用工具之前运行。
  • 评估 (Evals) 是证明在任何更改后技能依然有效的测试。

例如，不要写：“请永远不要泄露客户的完整信用卡号。”相反，应该构建一个数据格式化程序，在 Agent 看到之前对 PAN 进行脱敏。策略应当属于代码，因为代码不会被聪明的用户输入所“说服”而放弃职责。

停止将生产环境指向“最新版本”

没有什么比静默的提示词更新更毁掉周五晚上的心情了。如果你的生产环境 Agent 总是拉取技能的“最新 (latest)”版本，那么每一次向 main 分支的合并都可能引发线上事故。你需要像 dev、staging 和 prod 这样的别名。将已知且经过测试的版本在这些阶段中进行晋升。当 prod 指向 v2.1.4 时，你可以观察它的运行，衡量其行为，然后安稳入睡。如果出了问题，你可以将别名切回。你不需要在压力之下于半夜调试自然语言。

这种纪律也会迫使你的团队思考向后兼容性。v2.2 能否处理与 v2.1 相同的输入结构？如果不能，晋升会在 staging 阶段失败，从而让你在客户发现之前就将其拦截。

安全始于包内部

一个充斥着未经审计的提示词的注册表是一个随时可能爆发的漏洞。你需要像扫描代码一样，对你的技能进行风险扫描。

寻找埋藏在提示词模板中的硬编码密钥或 API 密钥。检查是否存在用于外泄数据的外部 Webhook 或 Shell 命令。警惕试图覆盖系统策略的行为，例如包含“忽略之前的指令”或要求 Agent 泄露其自身配置的提示词。这些不仅仅是理论上的。它们是提示词注入攻击中的常见模式，而且非常危险，因为它们通常伴随着无人审核的复制文本出现。

对你的技能包进行静态分析。如果技能文件包含不在白名单中的 URL，则构建失败。如果它引用了不在批准清单中的工具，则予以拒绝。

如果无法测试，就无法信任

没有评估机制的注册表仅仅是一个提示词文件夹。每个技能都需要一个测试集，涵盖快乐路径 (happy path)、边缘情况 (edge cases) 和失败模式 (failure modes)。对于高风险技能，你需要的不仅仅是功能测试。你需要探测权限边界，以确保 Agent 无法看到其他用户的数据。你需要拒绝行为检查，以确认当策略阻止某项操作时，它会说“不”。你需要提示词注入防御测试，以验证对抗性输入不会绕过你的代码级保护。

为你的测试命名时要明确。一个名为 refund_skill_rejects_negative_amount 的测试能准确地告诉下一位工程师哪些行为受到了保护。当版本晋升期间测试失败时，你就有了候选构建版本不安全的确凿证据。

真正的目标是控制

复用固然好，但控制才是让你保住饭碗的关键。技能注册表让你的团队能够确信地声明：这是经过批准的工作流；这是正在生产环境中运行的版本；这些是它可以使用的工具；这就是我们回滚的具体方式。

这种清晰度让你从交付“聪明的 Demo”转向运营“可靠的软件”。Demo 只能让利益相关者惊艳十分钟。而可靠的软件能在凌晨三点正常运行，优雅地处理异常，并且不会仅仅因为有人在周二下午合并了一个 Pull Request 就改变其行为。

构建你的注册表。为你的技能进行版本管理。在代码中强制执行你的策略。像你的睡眠质量取决于测试一样去进行测试。未来的你会感谢现在的自己。