实现 Agent Skills 支持：三个值得分离的加载决策
摘要
作者在为财务智能体添加 Agent Skills 支持时，总结了三个需要分离的架构决策：服务器端加载方式、模型上下文可见性、以及工具可用时机，并指出技能加载只教工作流而非安装能力。
在为我的财务智能体添加技能支持时，我发现“加载技能”这一说法掩盖了三个独立的架构决策：
1. **服务器加载什么？** 对于我自己维护的、仅有指令的小型技能目录，我会在启动时读取并校验这些文件，然后将它们保存在注册表中。这样可以避免每一轮对话都去读取文件系统。文件本身仍是编写格式，修改需要重启。
2. **模型看到什么？** 只有名称和描述会被放入系统提示词中。当任务需要时，通过 load_skill(name) 调用来获取技能正文。所有技能都存在于服务器内存中，并不意味着所有技能都在模型上下文中。
3. **工具何时可用？** 我的智能体已经具备了技能所引用的工具。加载技能只是教它工作流，而不是安装能力。对于小型工具集来说这很容易管理，同时也能让定义保持稳定，有利于提示词缓存的复用。大型目录可能需要加入工具发现机制。
最后一个选择有一个后果：模型可能在未查阅技能的情况下就尝试完成工作。因此，仅仅测试加载器是不够的。我会评估这些指令是否在其应该指导的操作之前就已加载，以及智能体是否会避免为简单问题生成不必要的图表。
我还选择不为第一个技能添加代码沙盒。这是一个支出报告工作流，其价值在于选择有用的图表并设计查询。经过测试的 UI 组件负责渲染结果。对于仅有指令的技能，SKILL.md 就足够了；脚本和其他资源是可选的。如果你的工作流依赖执行代码，这会改变对宿主环境的要求。
我围绕这些决策写了一份框架无关的指南，其中包含 TypeScript/Python 示例和 Cameron。链接会放在评论区。
如果你正在构建技能系统，在你的智能体中，价值最大的部分来自哪里：可复用的指令、可执行的脚本，还是对辅助资源的访问？
相似文章
多数智能体框架都忽视了一个关键区分：技能“是什么”与“如何执行”
一篇技术分析提出，智能体框架应把技能所描述的内容（角色、工具、工作流）与其执行方式（无状态 vs 有状态）区分开来，认为这一区分对构建健壮的实境智能体系统至关重要。
智能体技能的大规模工程化
本文讨论了大规模工程化AI代理技能的策略，包括上下文最小化、懒加载、可执行操作和基于结果的测量。
@QingQ77: agent 的 skill 越来越多后，每次对话不可能把所有 skill 说明都塞进上下文。这个工具把 skill 整理成一棵树，agent 收到任务时先查树、再按需加载对应的 skill。 https://github.com/maip…
SkillTree 是一个将 AI agent 的多个 skill 整理成树形结构并按需加载的工具，避免一次性将所有指令塞入上下文，提升 agent 效率。
@10xmylife: 我忽然意识到，随着 Agent 能力不断进化，Skill 很可能会成为比软件更重要的应用形态 传统软件，本质上是在给用户规定一种固定的工作方式：打开应用、寻找功能、填写表单、按照流程一步步操作 但 Skill 不一样。它没有提供界面，而是…
本文探讨了随着AI Agent能力的进化，Skill（技能/工作流封装）可能取代传统软件成为更重要的应用形态，未来Agent将围绕任务动态组合Skill，而软件则退居后台作为基础设施。
@shao__meng: Perplexity 团队内部 Agent Skills 设计、迭代与维护之道 Perplexity Agents 团队的内部规范公开版，核心论点很反直觉：写 Skill 不是写代码，而是为模型构建上下文。把工程师写代码的本能直接套到 S…
Perplexity 团队公开了 Agent Skills 的设计、迭代与维护规范，强调 Skill 编写并非传统编码，而是为模型构建上下文。文章提出了以评测为先、渐进式加载及通过处理特例（Gotchas）来优化 Agent 行为的反直觉方法论。