Agent Skills 不只是 Prompt:微软把可执行能力包接进 Python Agentチャプター1×0:08事件播报:Agent Skills 进入稳定版1:29技术拆解:它改变的是循环里的上下文边界3:18工程意义:技能库会变成新的依赖面5:00落地建议:先把技能分成三个权限层6:30片尾0:006:580:08主持人微软把 Agent Skills for Python 推到了稳定版。微软 Agent Framework 官方博客在北京时间七月十六日凌晨发布消息,明确说 Python 侧的核心 Skills API 已经稳定、可以用于生产,不再挂着实验性接口的标记。对正在搭 Agent 的团队来说,这不是又多了一个提示词模板,而是把「能力怎么打包、什么时候加载、能不能执行」正式放进了框架层。 这里的 Skill,可以理解成一个可移植的领域能力包。最常见的文件形态,是一个名为 SKILL.md 的说明文件,旁边放参考资料、模板和脚本。Agent 先看到技能的名字和描述,任务匹配以后再加载指令,需要时才读取资料,最后才调用脚本。官方把这套过程称为渐进式披露,目的很实际:不要把所有公司的政策、排障手册和代码工具,永远塞进每一次对话的上下文。 这次 Python 发布支持三种写法。第一种是文件技能,适合放在共享仓库里,由业务或跨职能团队维护。第二种是类技能,可以打成内部 Python 包。第三种是直接在应用代码里定义,适合技能内容要根据租户、用户角色或运行时状态动态生成的场景。微软自己的样例还展示了把这几类技能混合到同一个 Provider 里,也展示了从 MCP 服务发现技能的方式。1:29主持人把它放回 Agent Loop 里看,变化有三层。 第一层是上下文。传统做法很容易把所有规则都写进 system prompt,或者每轮都把整套知识库检索回来。技能把这件事拆成了「目录、说明、资源、执行」四个层级。Agent 平时只拿到技能目录,命中任务后才读说明,遇到具体问题再取资源。上下文预算被当成一个需要调度的运行时资源,而不是一次性配置。 第二层是能力的组合方式。微软官方的描述是,团队可以独立维护技能,Agent 根据技能描述自行选择,不需要应用方为每个技能重新写一套路由逻辑。这个方向很像把工具注册表往前推了一步:工具告诉 Agent「我能调用什么」,技能还告诉 Agent「遇到什么任务,应该按什么知识和步骤来做」。 但这里有一个容易被忽略的区别。技能里的说明是模型要理解的内容,技能里的脚本却是系统真的要执行的代码。两者不能用同一套信任等级处理。Python 的代码技能和类技能脚本是在进程内运行的,文件技能的脚本则交给应用方提供的 runner。也就是说,微软没有替你完成沙箱。官方文档明确建议生产环境补上隔离、 CPU、内存和时间限制、输入校验、可执行脚本白名单,以及结构化审计日志。 第三层是审批。Skills Provider 暴露了三个动作:加载技能、读取资源、运行脚本。默认情况下,三类动作都需要审批。官方样例允许把可信的只读加载和读资源操作改成自动通过,但脚本执行仍然保留人工确认。这个默认值很有价值,因为「读取一份说明」和「运行一段来自共享目录的代码」,风险根本不在一个级别。3:18主持人我的判断是,Agent Skills 真正带来的工程问题,不是怎么写一个 SKILL.md,而是技能库以后会像包管理器和工具注册中心一样,成为 Agent 的依赖面。 先看内容这一侧。技能描述会影响 Agent 什么时候选择它,说明文件会影响 Agent 怎么做,参考资料会影响 Agent 依据什么回答。于是技能的评审,不能只看 Markdown 有没有错别字。至少要测三件事:它会不会在不该触发的任务上被选中,加载以后会不会挤爆上下文,以及它给出的步骤能不能被评估集稳定复现。技能也应该有负责人、版本、兼容环境和变更记录,不能从一个共享目录里悄悄漂移。 再看执行这一侧。文件技能的脚本来自文件系统,最终会落到你提供的 runner 上。这个 runner 不是一个小工具,而是技能的执行边界。它要限制网络、文件系统、进程权限和资源消耗,还要把输入参数、退出状态和输出结果记下来。对于会写数据库、发邮件、改代码或者调用外部 API 的动作,最好不要让技能脚本直接拿到生产凭证,而是把副作用收敛到已有的工具网关,通过身份、幂等和审批继续管住。 还有一个常见误区:渐进式披露减少了上下文占用,但它没有自动解决提示词注入、恶意技能或知识过期。技能只是更容易被复用,也更容易被大规模复用。规模一上来,来源审查、版本锁定、租户过滤和使用审计就得跟上。微软文档提供了技能过滤和按键缓存隔离的能力,这些能力应该被看成多租户 Agent 的基础配置,而不是上线以后再补的优化项。5:00主持人如果团队今天就要试,我建议先把技能分成三个权限层。 第一层是只读知识技能,比如费用政策、排障手册和编码规范。它们可以自动发现,资源按需读取,重点做选择准确率和回答评估。第二层是受控计算技能,比如数据清洗、报告生成和离线校验。脚本放到隔离 runner 里,限制资源,并把输入和输出留下记录。第三层是会产生外部副作用的技能,比如发信、改库、提交代码和改云资源。这一层不应该因为包装成 Skill 就绕过原有的工具权限,默认需要人工批准,最好还能先生成计划和预览,再执行。 发布流程也要像发布软件包。技能目录进入代码审查,版本固定,依赖和权限写清楚,选一组真实任务做回归评估;上线后记录每次加载了哪个版本、读了哪些资源、跑了哪个脚本。这样出了问题,团队才能回答是模型选错了技能,技能内容变了,还是 runner 放行了不该放行的动作。 微软这次发布的重点,可以浓缩成一句话:把领域知识从 Agent 的大提示词里拿出来,变成一个可发现、可组合、可治理的组件。但组件一旦能被 Agent 自己发现并调用,就必须拥有清楚的所有者、版本和权限边界。今天你可以先检查自己的 Agent 技能库:当它发现一个新技能时,系统能不能说清楚谁发布、它能读什么、能执行什么、谁批准,以及失败之后怎么撤回?6:30主持人这里是 AI Loop Engineering。今天的主题是 Agent Skills 进入稳定版,以及能力包如何进入 Agent 的上下文和执行循环。通勤路上如果你只记住一个检查项,就去看技能脚本的 runner:它有没有隔离、限额、白名单和审计。明天见。