跨国深谈← 返回←AI 原生组织如何运行在 Skills 之上

AI 原生组织如何运行在 Skills 之上

关联

人物 Imad Touil

公司 Anthropic · Clearview

概念 技能 · 编码智能体 · 工作流 · harness · MCP · 子智能体 · 上下文窗口 · 微服务 · 渐进式披露 · 提示词注入 · 技术债务 · governance · 技能注册表 · 自动演化 · 沙箱

这一集是一场技术演讲，主角是 Ima Toil，Quantum Black（麦肯锡旗下 AI 部门）的杰出工程师。她讲的主题是：当 AI 原生组织大规模用上编码智能体之后，真正决定工作流质量的东西是 Skills（技能）——而大多数组织还没意识到，不治理 Skills 就等于在制造一类全新的技术债务。

她开场先给听众画了一张「智能体软件栈」的全景图：内循环是编码智能体及其 harness（承载智能体运行的框架），包含上下文管理器、工具与 MCP、记忆与状态、技能加载器；外循环是工作流，包含 Skills、子智能体、MCP 服务器和 hooks；底层还需要环境沙箱、MCP 网关、模型网关、知识图谱和工作流市场这些赋能组件。

日常大家熟悉的软件交付工作流只有四步：Specify（定义要构建什么）、Design/Plan（规划）、Tasks（拆解任务）、Implement（实现）。但 Toil 指出，这只是「构建一个产品增量」这一步。

真实的端到端生命周期要长得多：先定产品战略、成功指标、路线图，做市场调研和竞争分析，再进入探索阶段拆解问题陈述、验证方案、创建用户故事，构建之前还得准备数据（清理数据目录、对接核心系统的集成），然后是数据管道构建与质量验证，回到产品增量，再经过平台工程运维（基础设施即代码等）、上线、性能优化和事故处理，循环往复。而且一个组织里往往散布着多个不同的 SDLC——移动应用一套、内部平台一套、面向客户的又一套，不存在一个统一工作流能构建所有东西。她估计，她画出来的这整套版图，大概只占组织真实复杂度的 10% 到 20%。

为什么 Skills 是关键组件

在工作流的四个组件里——hooks（在工作流过程中预先触发事件）、MCP 服务器、子智能体（用来压缩上下文窗口）、Skills——前三个「有点像现成给定的」，并不真正带来结构化价值。她直言：谁真的构建过大量的 MCP？

大家只是用别人提供的工具。「归根结底，你所有的 know-how 实际上都存在于 Skills 层面。

」如果没有正确的 Skills 结构，你就不真正拥有一个确定性的工作流。她建议把工作流理解成 harness 蓝图——它们在运行时塑造编码智能体的行为。

Skills 的采纳速度惊人：八个月前 Anthropic 发布第一篇关于 Skills 的文章，两个月后出现了开放标准并被各大智能体框架采纳，到今年二月大多数智能体已经支持——如果你留意智能体思考的过程，可以看到它在执行任务时不断拉取 Skills。她 snapshot 了公开 GitHub 仓库和 Skills 注册表，创建量和需求都在快速上升。

效果也有数据支撑：在最新的 SkillsBench（评估 Skills 效果的基准测试）里，最新模型不使用 Skills 跑软件工程和网络安全任务表现不错，而且会持续进步；但一旦应用了更具确定性的 Skills，结果明显更高。

Skills 的设计原则：不是新问题

Toil 强调，这其实是老问题的新形态——和微服务运动是一样的。Skills 应当：可复用、模块化、可发现（别的团队能自动发现并获取你的 Skills）、跨 harness 可移植（因为大家都用同一个开放标准，Claude Code 上的技能移到 Cursor 就能直接工作）、专门化（不要造单体式的万能技能，一个技能定义一个任务——价值就在这里）、可组合（避免技能之间重复、互相冲突）、一致且确定性，最后是成本效率——通过渐进式披露（在正确的时机只加载正确数量的技能），减少 token 消耗。

她给出一个核心判断：Skills 定义了一个新的单元——它让你组织内的 know-how 变得可执行、可移植、而且便宜。她的例子是数据保留策略：当法规要求你操作客户数据时必须合规，把这条规则写成 Skill，再配合披露标准、GDPR 规则、填写模板等技能，法规披露审查工作流会在运行时自动拉取它们，产出确定性的审计报告，并留下改进代码库的回路。

不治理 Skills = 制造新的技术债务

这是全集最警告性的部分。如果放任不管，会出现七类问题：

• 重复：大家用同样的技术栈、建同样的产品，却不共享，团队在一次次重造同样的 Skills；
• 质量退化：不针对任务和不断推出的新模型持续测试验证，质量会随时间衰减；
• 不可发现：她类比 IDP（内部开发者平台）/Backstage 当年解决的问题——不用找人问，进服务目录就能查到谁拥有这个微服务。Skills 没有目录就没人找得到；
• 无所有权：没有 owner 就没人维护和扩展；
• 不可组合：这不会默认发生，需要治理机制来对齐构建什么、怎么设计（类似领域驱动设计塑造服务目录）；
• 安全隐患：公开 Skills 可能带有提示词注入（通过文本诱导模型执行恶意指令），而且 Skills 内含可执行脚本——这是它的确定性来源，也是攻击面。没有安全检查流水线，你可能拉到不安全的东西；
• 权限失控：不是每个技能都该全员可访问，有些含敏感业务逻辑，访问控制至关重要。

怎么落地：三层推进

落地路径分三层。个人层面：允许工程师用结构化的方式创建、测试、改进和使用 Skills，选定一套认可的机制即可。

团队层面：创建技能的那一刻就要与团队共享、协作改进——同样的技术栈做同样的产品，演进会非常快。组织层面是关键：建一个集中式平台，包含带元数据、可搜索的技能目录；一个接入目录的 MCP 用于搜索，加一个 CLI 把技能拉回本地 IDE 或工厂沙箱；还有依赖关系管理、版本控制与生命周期（智能体能自动识别并拉取技能的最新版本）、访问控制，以及评估与可观测性。

「所有这一切都围绕着治理展开——而这就是技术停止解决问题的地方。」谁来治理？取决于组织结构：应该让架构师、工程负责人、基础设施负责人和网络安全负责人坐下来，各自认领领域，确保技能更新符合组织策略。

一个模拟实验：治理前后的对比

Toil 在 Clearview 里做了一个组织模拟：15 个团队、每队 5 到 12 人，跟踪每人的技能贡献、日均技能调用量、团队间重复率、质量与安全比值。跑六个月的结果是——团队都在创建和使用 Skills，但组织没有可见性，而 Skills 与生产力提升紧密耦合：没有法规相关的 Skill，就有人在反复 vibe coding（凭感觉引导智能体）试图把它做对，既烧 token 又浪费时间；没有清晰维护的技能，实现质量就只能靠人拍板，团队间成熟度参差不齐。有的团队生产力中等、成本却很高。

做了治理之后呢？「不会像我们期望的那样完美」，有些团队还是会分叉，但至少出现了组织级的共同基础：你发布一个技能之后，下一个工程师构建新技能时，编码智能体的 harness 会自动识别到已有技能并直接调用——这几乎解决了前面讲的所有治理问题。

最后两个提醒

第一，Skills 只是工作流的一个组件，搞定了它不等于万事大吉——要把同样的方法应用到整个工作流上。如果集中式平台管理的是所有工作流，下一位工程师要配置基础设施时，可以直接调用一个工作流、用所需的技能构建、运行、测试，再改进后推回平台。

第二，这只是开始，接下来值得关注的三个方向：技能注册表（应该有一个，解决 IDP 问题的厂商已经开始集中化这项能力）；技能评估（正确方法尚有争议，但她发现简单有效的做法是静态测试加对照 Anthropic 最佳实践——技能没被正确调用、结构不对，质量大概率不行）；自动演化（当下的热点，但她泼了冷水：在没有治理机制设置护栏的情况下启动自动演化的闭环，影响只会远超今天的问题）。

本集带走

• Skills 是组织 know-how 的新载体：可执行、可移植、便宜。没治理好 Skills，就没有确定性的智能体工作流。
• 设计原则抄微服务：可复用、模块化、专门化（一个技能一个任务）、可组合、可发现、跨 harness 标准移植，用渐进式披露控制 token 成本。
• 不治理的代价是新技术债：重复造轮子、质量退化、不可发现、无 owner、提示词注入与脚本安全风险、权限失控。
• 落地三层走：个人结构化创建 → 团队共享协作 → 组织级集中平台（目录 + 元数据 + 版本 + 访问控制 + 评估），治理交给架构师和各条线负责人。
• 评估技能的朴素做法很有效：静态测试 + 对照 Anthropic 最佳实践；自动演化先别急，护栏没建好之前别开闭环。

归根结底，你会发现你组织里所有的 know-how 实际上都存在于 Skills 层面。
So at the end of the day, we’ll find all of your know-how is actually at the skills level.
—— Imad Touil · [06:41]

如果你的 Skills 没有正确的结构，那你就不真正拥有一个确定性的工作流。
And if you don’t have the right structure of your skills, then you’re not really having a deterministic workflow.
—— Imad Touil · [06:45]

这让你组织内的 know-how 变得可执行、可移植、而且便宜。
This makes your know-how in your organization executable, portable, and cheap.
—— Imad Touil · [09:52]

然而，如果我们不治理 Skills，我们将开始创造一类全新的技术债务。
However, if we don’t govern skills, we will start creating a new class of technical debts.
—— Imad Touil · [11:21]

而这一切实际上都围绕着治理来展开。这就是技术停止解决问题的地方，对吧？
And then all of this is actually played around a governance. And this is where technology stops solving the problem, right?
—— Imad Touil · [14:46]

如果你自动启动这台机器，其影响将远超今天，因为这会变成在没有治理机制的情况下维持自动演进的技能——而治理机制才是真正为你的组织设置护栏的东西。
If you automatically start this machine, the impacts will be way more than it is today because what I shared earlier is gonna be just maintaining auto-evolving skills without that governance in place that actually put the guardrails for your organization.
—— Imad Touil · [19:48]

如果你不做测试，不确保针对任务、也针对不断推出的最新模型去维护和验证你的技能，那么质量就会随时间开始退化。
If you don’t test and make sure that you’re maintaining and you’re validating your skills, not against your task, but also against the latest models that comes, right, then the quality starts degrading over time.
—— Imad Touil · [11:43]

如果我们没有关于该法规的技能，那就意味着有人在反复 vibe coding，试图弄清楚到底该怎么引导智能体把它正确地实现出来，对吧？
If we don’t have a skill about the regulation, that is someone is vibe coding back and forth and trying to figure out exactly how to steer the agent to implement it properly, right?
—— Imad Touil · [16:26]