Kilo 自定义斜杠命令实战：用 `ai-deps` 命令审计并规划 AI SDK 依赖升级
Kilo 自定义斜杠命令实战用ai-deps命令审计并规划 AI SDK 依赖升级【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode导读本篇文章围绕 KiloKiloCode / opencode 系开源仓库内置的自定义命令 .opencode/command/ai-deps.md 展开它是一份由 YAML frontmatter 与自然语言提示词组成的斜杠命令定义专门用来审计仓库中 AI SDK 系列依赖ai、ai-sdk/*、openrouter/ai-sdk-provider等仅筛出可安全升级的 minor / patch 版本并输出一份升级报告。读完本文你将掌握如何读懂并复刻这类命令文件、命令在 Kilo 中的加载与发现机制、AI SDK 依赖在仓库中的真实分布以及如何用子代理与模板变量把它改造成自己的依赖巡检工具。命令文件的结构frontmatter 提示词正文.opencode/command/ai-deps.md是一个典型的 Kilo 自定义命令文件文件开头是 YAML frontmatter--- description: Bump AI sdk dependencies minor / patch versions only ---在 Kilo 的配置体系中command/与commands/目录以及.kilo/、.kilocode/、全局配置根目录下的同名目录内的 Markdown 文件会被识别为斜杠命令文件名去掉.md后缀即为命令名即这里定义了一个可通过/ai-deps调用的命令。frontmatter 中的description字段会显示在命令列表中帮助用户理解该命令的用途。除此之外frontmatter 还支持agent路由到特定 agent、model覆盖模型、subtask以子任务方式运行等可选字段完整字段说明见 packages/opencode/src/kilocode/skills/kilo-config.md。从源码层面看命令的发现与解析逻辑位于 packages/opencode/src/kilocode/command-files.ts它通过Glob.scan({command,commands}/**/*.md, ...)同时扫描command/和commands/两种目录命名并把文件名转换为命令名configEntryNameFromPath。这解释了为什么该命令文件恰好放在 .opencode/command/ 下——仓库本身就用这套命令机制管理开发工作流同目录下还有changelog.md、commit.md、issues.md、translate.md等一批内置命令。提示词正文逐段拆解一次完整的 AI 依赖审计任务frontmatter 之下的正文就是发给 agent 的任务描述它的逻辑可以拆成六个环节指定输入文件要求 agent 先读取根目录的 package.json 与 packages/opencode/package.json这两份文件是所有依赖信息的权威来源。明确审计对象与范围只关注 AI SDK 依赖且只接受 minor / patch 升级明确忽略 major 变更。这是语义化版本SemVer策略的典型应用——major 升级通常伴随破坏性 API 变更不应被自动化流程擅自采纳。产出报告为每一个依赖列出当前版本 → 可升级到的版本形成一份完整的依赖升级清单。增值信息对每个依赖给出变更摘要并附带 changelog 链接或参考信息便于人工判断这些升级修复了哪些 bug、引入了哪些新特性。节省上下文窗口文档明确建议Consider using subagents for each dep to save your context window——即为每个依赖派生一个子代理去独立调研避免主会话的上下文被大量 changelog 文本撑爆。这与仓库中 agent / subagent 机制subtask字段、steps上限等见 packages/opencode/src/kilocode/skills/kilo-config.md是配套使用的。约束与落盘不得直接执行升级只做审计与规划最终把发现写入ai-sdk-updates.md相对当前工作目录即仓库根目录作为可供人工 review 的交付物。正文还给了一个非穷举的依赖示例清单ai、ai-sdk/openai、ai-sdk/anthropic、openrouter/ai-sdk-provider并注明 etc, etc强调要覆盖全面而不是只查这几个。仓库实况AI SDK 依赖到底长什么样要真正执行这个命令需要理解 AI SDK 依赖在当前仓库中的真实分布情况。根级 catalog 统一版本管理根 package.json 通过workspaces.catalog把关键版本集中钉死其中就包括ai: 6.0.235aiVercel AI SDK 主包由根 catalog 统一定版各工作区通过ai: catalog:引用同时根patchedDependencies里可以看到多个ai-sdk/*的补丁如ai-sdk/xai3.0.102.patch、ai-sdk/mistral3.0.51.patch、ai-sdk/google3.0.73.patch这些补丁位于 patches/ 目录。这意味着升级这些包时不能只看版本号还要确认升级后的版本是否仍能命中对应的补丁规则否则需要同步更新补丁。opencode 包AI SDK 生态的集中地packages/opencode/package.json 是 AI SDK 相关依赖最密集的工作区dependencies中包含了数十个 AI SDK 家族成员及其当前版本依赖当前版本依赖当前版本ai-sdk/openai3.0.88ai-sdk/google3.0.73ai-sdk/anthropic3.0.82ai-sdk/google-vertex4.0.128ai-sdk/azure3.0.93ai-sdk/mistral3.0.51ai-sdk/xai3.0.102ai-sdk/perplexity3.0.26ai-sdk/amazon-bedrock4.0.112ai-sdk/groq3.0.31ai-sdk/cohere3.0.27ai-sdk/cerebras2.0.60ai-sdk/togetherai2.0.41ai-sdk/deepinfra2.0.41ai-sdk/alibaba1.0.17ai-sdk/gateway3.0.157ai-sdk/openai-compatible2.0.48ai-sdk/vercel2.0.39ai-sdk/provider3.0.14ai-sdk/provider-utils4.0.40openrouter/ai-sdk-provider2.9.0ai-gateway-provider3.1.2venice-ai-sdk-provider2.1.1gitlab-ai-provider6.12.1从源码结构看Kilo 的 provider 层正是建立在 Vercel AI SDK 抽象之上的packages/opencode/AGENTS.md 明确写到 Uses the Vercel AI SDK as the abstraction layerprovider 从内置映射加载、也可在运行时动态安装。因此ai-deps命令的审计范围实际上覆盖了这些 provider 适配包与核心ai包之间的版本兼容性。模板变量让命令可以参数化虽然ai-deps命令本身不需要入参但理解 Kilo 命令的模板语法有助于你复刻或扩展它。根据 packages/opencode/src/kilocode/skills/kilo-config.md命令正文支持以下变量$1$N按位置传入的参数例如/ai-deps ai-sdk/openai时$1即ai-sdk/openai$ARGUMENTS完整参数字符串file引用文件并将文件内容注入提示词!cmd执行 shell 命令并将输出注入提示词。本命令通过package.json、packages/opencode/package.json的file引用语法把两份依赖清单直接喂给 agent这就是命令开头两句的来源。如果希望ai-deps支持指定某个依赖单独审计完全可以改成读取$1指定的依赖并只对其做 minor / patch 检查。如何运行这个命令由于仓库以 Bun 作为包管理器根 package.json 中packageManager: bun1.3.14dev脚本为bun run --cwd packages/opencode --conditionsnode src/index.ts在开发环境中启动 Kilo CLI 后直接在会话中输入/ai-depsagent 会按提示词依次读取两份 package.json、枚举所有 AI SDK 依赖、查询各自可用的 minor / patch 版本并最终把报告写入仓库根目录的ai-sdk-updates.md。整个过程中 agent 只会给出升级建议不会改动 package.json 或 packages/opencode/package.json 本身——这正是先审计、后决策的稳妥做法先由人工 review 报告再决定是否执行升级必要时同步更新 patches/ 下的ai-sdk/*补丁与根 catalog 版本。落地建议与注意事项结合源码与文档使用或复刻该命令时有几点值得注意补丁联动仓库为多个ai-sdk/*包维护了本地补丁见根 package.json 的patchedDependencies升级前应在报告中标注目标版本是否落在补丁版本区间内避免升级后补丁失效。catalog 优先级ai等包由根 catalog 统一定版命令报告中的可升级版本需要区分是仅改工作区依赖还是同步改 catalog——后者影响全部工作区风险面更大建议单独标注。major 版本红线文档明确要求忽略 major 变更。实践中可以把存在 major 升级单独列一节提示人工关注但不要纳入自动升级范围。子代理分摊成本当需要逐个依赖抓取 changelog 时为每个依赖派生子代理查询可以显著节省主会话上下文这也正是命令正文中那句建议的用意。输出文件约定报告固定写入ai-sdk-updates.md可将其视为可提交给团队 review 的变更规划文档如需改为其他文件名直接修改命令正文最后一行即可。通过这个例子可以看出Kilo 的命令体系把一段可复用的 agent 任务沉淀为仓库内的一等公民文件ai-deps正是用最小成本实现依赖体检的样板——理解它的结构后你可以按同样模式写出自己的security-audit、license-check等巡检命令。【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考