把 Agent Skill 接到 Omnilude 里
引言
之前我写过一篇介绍 Skill 与 Agent Workflow 的文章。
读那篇文章的时候，我一直在想，如果把技能接到 AI 聊天里，应该会非常有用。
这篇文章就是从这个想法开始的实现记录。我想把 Skill 从 Claude Code、Codex 这样的工具里拿出来，让 Agent 在真实的工作流中调用它，看看会发生什么变化。如果这件事做得顺，也许配置没那么高的 LLM 也能一点点更接近 Jarvis。
用一句话解释 Skill
最简短的说法是，skill 就是 一个把特定任务的处理顺序和判断标准，重复地教给代理的工作包。
Anthropic 公布的 skill 指南也把 skill 描述为一个以 SKILL.md 为中心、按需要附带 scripts、references、assets 的文件夹。真正重要的不是外形，而是原理。与其每次都把所有知识硬塞进 prompt，不如让代理只在需要的时候，按阶段打开 skill 本体和参考文件。
这一点比看上去更重要。通用代理很聪明，但一遇到重复任务就容易摇摆。即使在同一个仓库、同一个任务、同一个人的请求下，输出的语气、结构和遗漏点也可能不同。skill 就是用来减少这种波动的装置。
我尤其看重三个原则。第一是 progressive disclosure，也就是只在必要时再打开更深的文档。第二是 composability，也就是一个 skill 不试图独自解决全部问题，而是与其他 skill 一起工作。第三是 portability，也就是不要把它绑死在某个界面或某个工具上。
我正在实现的 Skill 链
在我的本地仓库里，.codex/skills 下已经有 25 个 skill。文档生成、API 实现、后台 CRUD、SSE、故事流水线、翻译、评审、提交等重复性工作，都由它们分别负责。.agents/skills 里则放着同一套目录，以便在另一种 surface 上复用。
另外，我总是在提 Claude Code，却突然开始说 Codex，也是有原因的。最近在韩国，通过 Kakao 出现了一次接近 90% 折扣的 OpenAI Pro 活动。机会不错，所以我现在已经切到 Codex 了。
回到正题，在这些 skill 里，我最常用的主轴其实很清楚。prd-generator 接收需求并生成符合文档规则的 PRD，endpoint-implement-skill 则把从 Entity 到 Controller 的实现模式固定下来。需要时，frontend-task-handover 会继续生成前端交接文档，而 branch-review 会在最后重新检查回归与风险。
也就是说，我更常把 skill 看成一条 链，而不是单独的功能。
实际上，CLAUDE.md 里已经写明了针对不同工作类型，优先应该连接哪些 skill。比如 API 开发走的是 prd-generator -> endpoint-implement-skill -> frontend-task-handover，后台开发走的是 prd-generator -> backoffice-crud-skill -> frontend-task-handover。到了这个阶段，skill 已经不太像一个辅助功能，而更像工作运行规则本身。
有意思的是，这篇文章本身也建立在同样的哲学上。我现在正在使用的 blog-post-writer skill，被设计成一次性对齐博客分类、reading time、tone、excerpt 长度、canonical URL、缩略图提示词，以及 import JSON schema。就连写作本身，也不再只是凭感觉，而是被打包进一种可重复的输出格式里。
技能与助手
当 skill 进入产品之后，它就不再能只靠 SKILL.md 来解释了。以 current-weather-checker 的详细蓝图为参照，真正的 skill 更接近一个运行时单元，它不仅包含说明文和参考文档，还绑定了可执行代码、元数据、网络策略和触发策略。所以现在我看待 skill 时，已经不只看文件夹结构，而是会一起看 存了什么、执行了什么、以及 它如何连接到助手。
技能结构总览
沿着 current-weather-checker 这份蓝图看下去，就会发现 skill 的实体比表面上更立体。屏幕上先看到的是名称和说明，但在背后还挂着 Instructions、Scripts、References、Assets、Metadata、Runtime Policy。正是因为有这套结构，某些 skill 才能只增强上下文，某些 skill 才能直接在 sandbox 中执行，还有某些 skill 能安全地控制外部网络访问。
总结一下，skill 并不只是一个 prompt 文件，它更接近一个把 说明文本 + 执行资源 + 运行策略 绑在一起的定义对象。尤其对于 script skill 来说，networkPolicy 和 allowedDomains 这样的执行策略会直接决定真实权限。只看 body，并不足以理解这个 skill 真正能做什么。这正是蓝图文档有价值的地方，因为它能一次性还原屏幕背后的结构。
助手联动总览
下一步真正重要的，不是 skill 本身，而是 谁拥有这个 skill、它在什么条件下被调起、以及被选中之后会沿着什么路径执行。在 Omnilude 这套结构里，skill 不是松散地挂在 agent 上，而是映射到 assistant 上，再由 orchestrator 读取 mapping 和 trigger 信息，决定实际的执行路径。可执行 skill 会流向 sandbox，一些仅用于补充上下文的 material 则会流向最终回答的 prompt。
隔离执行环境
可执行 skill 的脚本并不会直接在 assistant 进程内部运行。AssistantSkillScriptExecutor 会通过 sandbox-bridge 把执行委托给独立的 sandbox pod，而脚本就在这个隔离环境里接收 stdin JSON 输入，并返回 stdout JSON 结果。这样的结构把助手本体和执行代码分开，同时也能用 networkPolicy 和 allowedDomains 控制外部访问范围。
简单来说，assistant 负责决定 执行什么，sandbox 则是 安全处理执行的地方。随着 skill 越来越多，这种分离会越来越重要。它能隔离执行失败，更细粒度地拆分网络权限，也更容易在事后追踪哪个 script 是在什么策略下运行的。
从这个流程来看，skill 与其说是 assistant 的附属文档，不如说是 assistant 在需要时选择并执行的模块。所以 attached skill 越强，真正重要的就越不是 说明写得有多长，而是 mapping、trigger、execution、observability 设计得有多清楚。最终，一个好的 skill 不是一篇写得漂亮的文档，而是一个能被助手稳定调用的结构化执行表面。
结尾
如果 2026 年 2 月 18 日那篇 workflow 文章讲的是 代理是如何流动的，那这篇文章讲的就是，如何把这条流动通过 skill 固定成一种稳定结构。
Skill 不是魔法按钮。但它依然是一个相当有力的工具，可以把个人和团队的重复工作、工作标准、参考上下文、输出格式与执行路径，收束成同一个单元。
下一次，我想带来一些更具体的实现与运维案例，继续讨论 skill 与 assistant 的组合，究竟能怎样提升真实的代理体验。