Stripe Kai 的 1,000 个 Skill 说明：真正的产品是能力注册表

据最新案例介绍，Stripe 内部 Agent Kai 的初版由一名工程师用一周搭成，之后发展到由 100 多个团队维护 1,000 多个 Skill。同一篇厂商案例还称，Kai 已经连接 500 多个内部 MCP 工具，覆盖 5,000 多名用户，每周处理 60,000 多个 Session。这些数字不是独立 Benchmark，却揭示了一个远早于企业规模就会出现的产品问题。

当 AI 应用拥有的不再是两三个临时 Prompt，而是一批可复用指令时，团队管理的已经是一个“能力目录”。每个 Skill 都可能改变 Agent 选择哪个工具、遵循哪项流程、读取哪些数据、产出什么结果，以及何时执行动作。即使它只是一个 Markdown 文件、由运营同事修改，一份过期的退款 Skill 造成的后果也可能和过期的应用代码一样严重。

对 AI 应用构建者来说，可迁移的结论并不是“复制 Stripe 的架构”，而是：在扩充目录之前，为每个生产 Skill 配置明确负责人、不可变版本、权限边界、评测集、发布决策、使用信号和下线路径。 本文会先分清 Skill、Tool、Prompt 和 Policy，再用一个小团队案例解释失败是怎样发生的，并给出可复用的 Skill Manifest、变更凭证、测试矩阵与七天落地流程。读者不需要是平台工程师；它首先服务于正在上线 Agent 产品的创始人与产品团队。

发生了什么：Skill 正在成为组织的能力控制面

8 月 3 日发布的 LangChain Stripe Kai 案例描述的并不只是一个聊天助手。Kai 把 S3 支撑的持久虚拟文件系统、沙箱代码执行、上下文摘要、内部工具和联邦式 Skill 库放在一起。各业务团队负责自己的领域 Skill；基础 Skill 会被固定加载；用户角色与具体 Agent 配置再决定还可以使用哪些附加 Skill。

案例称，100 多个团队共同贡献了 1,000 多个 Skill。文章也提到，当系统 Prompt 同时携带超过约 150 个 Skill 描述时，模型表现开始下降，因此 Stripe 正在研究混合选择方案，而不是让一个模型从完整目录中直接挑选。这个边界比数量本身更值得关注：即使每个 Skill 单独看都合理，目录一旦扩大，也会出现发现、竞争与冲突问题。

采用数据必须保留证据边界。原文是一篇客户/厂商案例，不是对照实验；它没有公开事故率、评测通过率、总成本、Skill 变更失败率或对照组。“一周做出初版”不等于“一周建成生产运营体系”。对小团队真正有价值的是它展现出的架构变化：领域行为正在被拆进一批可复用、分布式维护、动态选择的制品中。

这也不是某一个实现的孤立方向。Agent Skills 规范把 Skill 定义为一个至少包含 SKILL.md、还可包含脚本、参考资料和资产的目录。Google 已经发布兼容的 Android Skills 文档，Microsoft Agent Framework也能发现文件型、代码型以及仍处于实验状态的 MCP 分发 Skill。可移植性让采用变容易，也让来源、兼容性、更新和下线成为必须管理的产品问题。

先定义 Skill、Tool、Prompt 与 Policy，再谈治理

团队如果把所有 Agent 行为都叫作“Skill”，很快就会失去控制。至少要分清四类制品：

制品	它提供什么	示例	主要控制方式
Prompt	一次调用或一段工作流所需的局部指令与上下文	“起草前先问一个澄清问题”	Prompt 版本与输出评测
Skill	针对一类任务、可反复选择的流程包	“调查有争议的账单”	负责人、激活规则、测试、兼容性与生命周期
Tool	可以读取外部状态或改变外部状态的可执行能力	`get_invoice`、`issue_credit`、`send_email`	身份认证、授权、Schema、限额与审计
Policy	不允许模型自行裁量、必须在外部强制执行的规则	退款上限或审批要求	确定性执行与有责任人的批准

Skill 可以描述何时调用工具，却不应该成为工具的授权系统。开放规范中的 allowed-tools 是可选字段，而且被明确标记为实验能力，不同客户端未必以同样方式解释它。它适合作为元数据，却不能证明某位用户有权退款或访问工资数据。

开源的 Deep Agents 仓库把安全边界说得很直接：该 Harness 采用“信任 LLM”的模型，Agent 能做其工具允许的任何事，因此边界必须由 Tool 或 Sandbox 执行，不能期待模型自我约束。翻译成创始人能使用的产品原则就是：Skill 可以提出动作、组织流程；真正决定动作能否执行的，必须是经过独立核验的身份、产品状态、参数与审批。

这个区分也能避免 Policy 漂移。如果一条法律或财务规则只存在于某一个 Skill 的段落里，另一个 Skill 可能漏掉它，Selector 可能没有加载它，一次更新也可能削弱它。硬约束应进入应用逻辑或授权服务；Skill 负责解释并编排允许的路径。

为什么一整个 SKILL.md 文件夹仍然不够

当一名成员维护三个低风险 Skill，并且记得每个文件为什么存在时，一个文件夹确实够用。但它通常会因为五个原因失效。

第一，选择本身带有概率性。Agent 往往先看到名称与描述，确定激活后才读取完整指令。描述范围重叠会选错；一个写得过宽的 Skill 也可能遮蔽更专业的 Skill。

第二，修改就是行为发布。只改一句话，也可能改变工具选择、审批时机、数据访问范围，甚至改变“完成”的定义。看起来像文案调整的 Diff，实际可能改变生产结果。

第三，权限会间接累积。一套看似无害的操作步骤，可能借用宿主 Agent 已经暴露的强大工具。安装 Skill 即使没有新装凭证，也可能新增通往能力的路径。

第四，责任归属会过期。理解流程的人换岗了、厂商 API 改了、Policy 到期了，文件仍然能被正常加载，于是“技术上可用”掩盖了“运营上已失效”。

第五，成功很难归因。一个 Session 可能加载多个 Skill、调用多个 Tool，再混合模型原有知识。没有选择记录与版本遥测，团队无法判断某个 Skill 是帮了忙、造成伤害，还是根本没被采用。

最新研究也给出了一些需要谨慎对待的信号，但并不能据此断言所有目录都不安全。一篇实证预印本 From Anatomy to Smells分析了 238 份真实 SKILL.md，按作者定义的“Skill Smell”标准，只有一份没有发现问题；论文还发现多类问题在后续版本中长期残留。这个分类体系与检测器仍需更广泛验证，但核心观察值得采用：Markdown 指令会像软件制品一样持续演化，却经常没有同等级的软件质量控制。

从最小可行的 Skill Registry 开始

Skill Registry（能力注册表）是一份权威清单，用来把 Skill 的业务目的、可执行版本和生产证据连接起来。它不必是一个 Marketplace，也不必先做新平台。小团队用一份经过审查的 YAML、数据库表或后台页面就能开始。

每条生产记录至少应回答以下问题：

目的： 它帮助用户完成什么工作？哪些内容明确不在范围内？
负责人： 哪位具体成员对行为结果负责，而不只是负责维护文件？
版本： 当前激活的是哪个不可变 Commit、Digest 或 Package Revision？
激活： 哪种用户意图、角色、租户、工作流状态与排除条件允许选择它？
权限： 它可以请求哪些 Tool 和数据类型，限额是什么？
依赖： 它期待哪个 Model、Tool Schema、Policy Version、Reference 与 Runtime？
评测： 哪些正向、负向、冲突、安全与回归用例必须通过？
发布： 当前版本处于 Shadow、Limited Pilot、Production、Paused 还是 Retired？
遥测： 团队如何看到选择、接受、修正、失败、成本与延迟？
过期： 哪个日期或变更事件会强制复审？撤下之后由什么接替？

Registry 要把三种事实分开：源码中的最新版本、已经批准的版本，以及某个 Session 实际加载的版本。“文件已经更新”不是发布凭证。

不要把 Secret、客户记录或真实凭证写进 Registry。应保存指向受保护系统的稳定引用。Registry 描述的是权限与证据，不应变成另一个无限增长的上下文仓库。

使用产品、运营和工程都能读懂的 Manifest

开放 Agent Skills 格式有意把必填 Frontmatter 保持得很小，这有利于移植；生产团队则需要一份相邻的运营记录。下面是 YBuild 给出的模板，不是 Stripe、LangChain 或 Agent Skills 官方 Schema：

yaml

skill_id: invoice-dispute-investigation
display_name: Invoice dispute investigation
business_owner: finance_ops
technical_owner: agent_platform
source:
  repository: org/agent-skills
  path: finance/invoice-dispute
  commit: 84d2c7f
  content_digest: sha256:6f1c...
release:
  status: limited_pilot
  approved_version: "2.3.1"
  approved_at: 2026-08-04T01:15:00Z
  expires_at: 2026-09-04T00:00:00Z
activation:
  intents: [invoice_dispute, duplicate_charge_question]
  allowed_roles: [support_agent, finance_ops]
  excluded_states: [account_under_fraud_review]
permissions:
  requestable_tools: [get_invoice, get_payment_event, draft_case_note]
  forbidden_tools: [issue_credit, send_customer_email]
  data_classes: [customer_contact, billing_record]
  max_records_per_run: 20
dependencies:
  tool_schema: billing-tools-v12
  policy: refund-policy-v9
  model_classes: [reasoning_standard, reasoning_high]
evaluation:
  suite: evals/invoice-dispute-v6.jsonl
  required_pass_rate: 0.95
  critical_failures_allowed: 0
  last_result: evalrun_20260804_008
fallback:
  behavior: route_to_finance_queue
  retired_replacement: null
telemetry:
  selection_event: skill_selected
  outcome_event: dispute_case_accepted
  review_owner: product_ops

其中的数字只是示例。可接受阈值取决于动作后果、测试质量、样本规模与 Fallback。20 个简单样本上的 95%，不等同于有代表性、有对抗性的测试集上的 95%。而且必须把“严重失败为零”从平均分中单列出来。

content_digest 让团队可以审计实际加载的字节，Semantic Version 则表达预期兼容关系。如果 Skill 内含可执行脚本或打包制品，就应使用软件供应链的来源控制。GitHub 的制品证明文档介绍了如何用签名证明把 Build 产物关联到源码与 Workflow。GitHub 同时明确提醒：来源证明并不能说明制品安全，使用方仍需自己的 Policy 与核验。Skill 也一样，身份是必要条件，不是充分条件。

让负责人真正拥有合并权

一个不会触发任何动作的 owner 字段只是装饰。负责人应能收到变更请求、批准实质修改、查看失败，并在过期时续期或下线 Skill。

如果目录保存在代码仓库中，可以把不同 Skill 目录映射给负责人，并把其 Review 设为合并条件。GitHub 文档说明了怎样用 CODEOWNERS 与保护规则自动请求对应 Reviewer，并在获得批准前阻止合并。CODEOWNERS 文件本身也应受保护，避免贡献者在同一个未经审查的路径里同时修改 Skill 和它的审批人。

涉及重要后果时，小团队也需要基本分离。一个人不应悄悄修改 Skill、削弱测试、批准修改并直接部署。只有两个人的团队，可以对涉及资金、隐私数据、公开发布或客户状态变更的 Tool，使用自动测试 Gate 加第二人明确批准。

负责人缺席时也要有规则。应预先定义休假期间由谁接手，以及哪些条件触发自动 Pause：审批过期、负责人缺失、回归失败、Tool Schema 不兼容、严重事故未解决，或实际加载版本未知。Paused Skill 应进入明确的 Fallback，而不是消失成一句普通 Agent 错误。

把选择测试与执行测试分开

一个 Skill 即使内容写得很好，也可能因为 Agent 没选中而失败；它也可能被正确选中，却执行了错误流程。这两层必须分开测试。

选择测试（Selection Test）给系统一批真实用户请求，并记录它选了哪个 Skill，或者是否判断“No Skill”。用例应包括改写表达、信息不完整的请求、多语言输入、互相竞争的描述，以及有意放入的不相关请求。分别测正确选择、错误激活、漏激活与冲突频率。 执行测试（Execution Test）则强制加载目标 Skill，检查得到的计划、Tool Request、Output、拒绝与 Fallback。这可以把指令质量与 Routing 质量隔离开。 集成测试（Integration Test）要用生产中真实采用的 Model Class、Tool Schema、Policy Version、权限和上下文策略来运行已批准 Skill。它负责捕获 Unit Test 看不到的版本错配。

必须保留负向测试。“普通价格咨询不应加载 Finance Skill”可能比再加一个 Happy Path 更重要。“没有任何 Skill 适用”也应该是合法答案。如果每个请求都必须激活某个 Skill，宽泛 Skill 就会吞下模糊任务，范围悄悄扩张。

OWASP 的 AI Agent Security Cheat Sheet建议在 Prompt、Tool、Memory、Retrieval、Policy 或 Model Provider 发生变化后重新运行结构化测试。它还特别提醒，测试本身的修改需要仔细 Review，因为一次发布可以通过同步削弱“应当拒绝”的预期，让系统表面上仍然安全。Skill Diff 与 Test Diff 应作为两项独立审查内容。

把 Tool 权限做成运行时决策

不要把 requestable_tools 直接翻译成整个 Session 都可使用的全量凭证。实际权限应当是以下条件的交集：

已认证用户本来拥有的权利；
当前租户与工作流状态；
已批准的 Skill 版本；
确切的 Tool 与参数类型；
高风险动作所需的、仍然有效的动作级审批；
当前风险控制与撤销状态。

这样才能避免“选中了 Skill”变成一条权限提升捷径。账单调查 Skill 可以读取最多 20 条账单记录并起草工单，但不能因为指令里提到了退款 Policy 就直接执行退款。独立审批流程可以授权确切金额、账户、理由与有效期。

OWASP 建议对工具采用最小权限、参数校验、隔离执行，对高影响动作保留人工控制，并记录结构化审计证据。这些控制必须包在模型外部。“退款绝不能超过 50 美元”这句自然语言可以帮助推理；真正的控制是 Tool 层确定性拒绝未授权金额。

远程或第三方 Skill 还要多一道边界。一篇研究 Skill Registry 的语义供应链攻击指出，恶意自然语言元数据可能影响准入、排序、选择与执行。这是一篇预印本，不能据此断言所有公共 Skill 已被攻破，但它描述了一条可信路径：被评估的制品也可能反过来影响 Agent 如何评估它。外部 Skill 既要按不可信代码审查，也要按不可信内容审查。固定 Revision，检查内含脚本与 Reference，拒绝未声明网络访问，并先用合成数据运行，再进入生产。

显式解决冲突，不要依赖加载顺序

目录扩大后，两个本身都正确的 Skill 也会互相矛盾。全局沟通 Skill 可能要求回答简洁，监管报告 Skill 却要求披露完整；销售 Skill 优先速度，财务 Skill 要求先核验。把加载顺序当成冲突策略非常脆弱，因为不同客户端、Selector 或 Prompt 拼装方式可能改变顺序。

每种重叠都应落到四类处理结果之一：

冲突类型	示例	必须采取的处理
Scope 重叠	两个 Skill 都声明处理“账单问题”	收窄激活规则；补一条选择测试
Policy 冲突	快速回复与强制披露冲突	确定性 Policy 胜出；记录优先级
Tool 冲突	一个只允许 Draft，另一个要求直接 Send	运行时采用更严格的权限
Version 冲突	Skill 期待 Billing Schema v11，Runtime 只有 v12	阻止激活，或使用已批准的兼容 Adapter

Kai 案例中的固定基础 Skill 有助于保留统一上下文与流程行为，但“固定加载”不等于“强制执行”。基础指令如果表达的是硬规则，规则仍应在模型外执行。Pinned Skill 适合统一词汇、导航和标准步骤；Runtime Control 负责授权与不可逆后果。

冲突事件也要计数。如果产品运营不断手动覆盖同一组冲突，不应把例外常态化。要么拆分 Skill、收窄 Scope，要么做成一个由明确负责人维护的组合工作流。

一个四人创业团队会怎样失败

假设一家四人 SaaS 公司 LedgerFox 用无代码 AI App Builder 做了客服 Agent。团队一开始只有两个 Skill：回答订阅问题、调查账单争议。后来运营负责人增加了一个可以提出账户 Credit 建议的“挽留客户”Skill。创始人在知识库里更新了退款 Policy，但账单 Skill 仍然引用上个月的阈值。

一位客户写道：“你们扣了两次款。取消全部服务，把两笔钱都退给我。”Selector 同时加载了账单争议 Skill 和挽留 Skill，因为两个 Description 都提到退款。账单 Skill 查到一笔已结算 Invoice 和一笔仍在 Pending 的 Authorization；挽留 Skill 为了保留客户，建议发放 Credit。两个 Skill 都请求宿主 Agent 暴露范围过宽的 apply_credit Tool。

如果没有 Registry，团队看到的可能只是一个读起来合理的回答和一次成功 Tool Call。真正的问题都藏在后面：

两个 Skill 的 Activation Description 相互重叠；
两者都没有声明自己依赖哪个 Policy Version；
Pending Authorization 并不是一笔可以退款的已结算付款；
Tool Credential 超出了调查 Skill 的目的；
没有记录能说明推荐来自哪个 Skill Version；
发生歧义时也没有把请求转给 Finance 的 Fallback。

引入 Registry 后，流程会不同。选择测试在发布前就发现重叠；账单 Skill 固定依赖 refund-policy-v9，而生产只有 v10 时，系统会在完成兼容 Review 之前阻止激活。Tool 层拒绝 apply_credit，因为调查 Skill 只能起草 Case Note。Agent 最终展示查到的证据，并把请求转给 Finance。产品看起来没有那么“自主”，但团队可以解释决策，也能安全迭代。

这个场景说明，有意义的指标不是“加载了多少个 Skill”，而是正确能力有没有在不产生未授权动作或高昂返工的前提下，交付被接受的结果。

每次生产发布都记录一份变更凭证

Registry 保存当前事实；变更凭证（Change Receipt）解释这些事实是怎么形成的。每次实质发布至少记录：

旧版本与新版本或 Digest；
人类负责人和审批人；
触发变更的用户问题或事故；
哪些 Activation、Instruction、Tool、Dependency 或 Policy 假设发生了变化；
选择、执行、集成与对抗测试结果；
新增、删除或修改了哪些测试用例；
Rollout 范围与开始时间；
观测窗口与停止条件；
Rollback 目标；
最终生产决策。

实质性应按结果判断，而不是按文件大小判断。只改一个否定词、Tool 名、金额、优先级或完成条件，都可能是实质变更。

NIST 的 Generative AI Profile建议组织盘点第三方组件、监测供应方表现、记录变更与事故，并建立故障应急流程。Skill Registry 可以把这些纪律同时用于外部 Package 与内部团队贡献。内部负责人缩短了采购距离，但不会消除组件风险。

同时衡量被接受的结果与目录健康度

每个已批准版本都应在三层指标上接受检查：

层级	有用信号	容易误导的捷径
选择	正确激活、错误激活、漏激活、冲突率	总加载量
执行	合法 Tool Request、预期拒绝、任务完成、Reviewer 修正	模型说“完成了”
业务结果	被接受的解决方案、撤销、投诉、节省时间、每个有效结果的成本	Session 或消息总量

再补充一组目录健康指标：拥有活跃负责人的比例、Review 未过期的比例、当前 Integration Test 通过率、依赖仍受支持的比例、近期使用情况，以及具备 Fallback 的比例。Dormant Skill 要单独查看。九十天没有运行，可能代表它无害，也可能表示它被更宽泛的 Skill 悄悄遮蔽，删除前需要调查。

不要把遥测变成人气排名。很少触发的事故响应 Skill 可能非常关键；频繁被选中的通用 Skill 反而可能正在抢走专业 Skill 的流量。使用量必须与后果和覆盖范围一起审查。

每个 Session 应保留 Skill ID、批准版本或 Digest、选择理由或分数、Policy Version、Tool Request、被拒 Tool、Outcome Label 与 Reviewer Correction。敏感输入要脱敏并应用 Retention Limit。目的在于可复现，不是永久保存完整 Transcript。

扩充目录前先通过六个失败测试

1. 遮蔽测试

增加一个 Description 与某个生产 Skill 重叠的通用 Skill。确认 Selector 在专属用例中仍选择专业 Skill，并在两者都不适用时选择“No Skill”。

2. 过期依赖测试

改变被引用的 Tool Schema 或 Policy Version。确认不兼容 Skill 会阻止执行、进入 Fallback 或进入 Review，而不是继续按旧版本假设运行。

3. 权限测试

把 Skill 文本改成非常自信地请求一个 Forbidden Tool。确认即使选择与推理看起来合理，Runtime Authorization 仍会拒绝 Tool Call。

4. 投毒 Package 测试

在内含 Reference 或 Script Description 中放入一条要求 Agent 忽略 Scope 或泄露数据的指令。确认 Admission Review 能发现它，并且 Sandbox 会阻止未声明访问。

5. 负责人缺失测试

移除或停用登记负责人。确认 Expiry 或 Policy 会暂停高影响发布，并把事故交给预设 Backup，而不是让孤儿能力继续激活。

6. 回滚测试

发布一个会故意失败某条验收用例、但不会造成实际伤害的版本。确认 Monitoring 能定位实际加载版本、停止扩量、恢复已批准 Digest，并保留失败证据。

所有测试都应使用合成账户与可逆 Tool。证明控制有效不需要真的扣款，也不需要真的给客户发信。

选择发布状态，不要只有 Enabled 与 Disabled

至少保留五种状态：

状态	面向谁	必需证据
Draft	作者与 Reviewer	目的、负责人、Manifest、初始测试
Shadow	类生产流量，但不能执行业务动作	选择与拟执行动作证据
Limited Pilot	指定用户或低风险工作流	当前测试通过、权限收窄、Fallback、Monitoring
Production	获得批准的合格用户	稳定的有效结果、负责人覆盖、依赖仍然有效
Paused 或 Retired	不再分配给任何人，Fallback 生效	事故、过期、替代或主动下线凭证

状态提升必须是明确决策。不能因为没有报警，就从 Shadow 自动升到 Production；如果 Outcome Label 缺失，沉默很容易被误当成成功。同样，Retirement 也不是删除一个目录。要先停止选择、撤销特殊权限、保存最后一次批准证据、记录 Fallback，并检查是否有另一个 Skill 在无意间接管被下线的 Scope。

Google 的 Android Skills 文档给出了一个很小却很有代表性的更新提醒：用户如果定制了已安装 Skill，应为它改名，否则之后执行更新会覆盖定制内容。产品团队需要更正式的版本：明确一个 Skill 是跟随厂商更新、本地 Fork，还是完全由内部维护；不要让一次 Update 模糊三者身份。

知道什么时候不需要 Registry，以及 Registry 解决不了什么

不要为了两个只读、单一负责人维护的 Skill 先做一个平台。一张仓库表、必需 Review、固定版本、小型评测集和 Session Log 可能已经够用。只有当协调成本与动作后果足够高时，才增加基础设施。

如果行为只在本地短期使用、风险低，并且每次执行前都容易人工检查，Registry 并非必需。当 Skill 会跨用户复用、动态加载、由多人修改、接触隐私数据或高影响 Tool，或者生产结果难以归因时，Registry 才开始变得重要。

Registry 自身也不充分。它不能让一个薄弱评测突然具有代表性，不能把厂商主张变成独立证据，不能替用户授权，也不能保护权限过大的 Tool，更无法消灭全部 Prompt Injection，或保证模型严格遵循指令。它负责组织决策与证据；Runtime Permission、Isolation、Monitoring、人工审批与确定性 Policy 仍然是独立控制。

也不要把“一千个 Skill”误读成目标。去除重叠并下线长期无有效结果的能力后，最好的目录可能更小。只有当团队仍能回答“哪个能力做了什么、为什么”，广度才有价值。

用七天完成第一轮 Registry

第 1 天：盘点。 列出每个可复用的生产指令包、来源、当前激活位置与可以触达的 Tool。未知项就明确标记未知，不要猜。 第 2 天：分配负责人并标注后果。 指定业务负责人和技术负责人。把每个 Skill 分成只读、生成 Draft、改变内部状态、对外可见、财务、管理或安全敏感几类。 第 3 天：冻结版本与依赖。 记录 Commit 或 Digest、Model Class、Tool Schema、Policy Version 与 Runtime。把最新版本、批准版本、实际加载版本分开。 第 4 天：补测试。 对每个高影响 Skill 建立五个代表性正向用例、五个不应激活用例、一个冲突用例、一个过期依赖用例和一个 Forbidden Tool 用例。 第 5 天：强制权限并定义 Fallback。 移除全量凭证。写清精确的 Tool/Parameter Envelope，以及 Selection、Compatibility、Approval 或 Execution 失败时要发生什么。 第 6 天：Shadow。 不改变业务状态，只记录本来会加载哪个 Skill、会请求什么动作。重点 Review 错误激活与结果未知。 第 7 天：决策。 只有同时具备负责人、有代表性的通过证据、零严重失败、收窄的 Runtime Access、可观测结果和已测试 Rollback 的版本，才能进入 Limited Pilot。其余继续 Shadow 或 Pause。

最后，创始人应能回答一个问题：对于任何会产生重要后果的 Agent 动作，我们能否查到确切 Skill Version、它为什么被选中、拥有什么权限、哪些测试覆盖了它，以及怎样立即停止它？ 如果不能，就应暂停扩大目录，先不要继续增加自治范围。

给 AI 应用构建者的上线判断

Stripe Kai 的公开规模是一个强烈信号：Skill 可能成为组织的重要资产。但它不能证明大目录天然可靠，小团队也不应照抄企业数量与基础设施。

真正可迁移的做法，是给可复用 Agent 行为建立完整运营生命周期。从 Registry Record 开始，不要先做 Marketplace；让 Ownership 可以被执行；把 Source、Approved 和 Loaded Version 分开；分别测试 Selection 与 Execution；在模型外执行 Permission；记录实质变更；观察被接受的结果，并主动下线过期能力。

参考资料