开发与本地验证扩展

开发原生扩展可以从官方 mcp-server 模板开始。以下是供扩展作者执行的步骤，不会替项目自动安装或发布依赖。

创建和编译

qwen extensions new my-first-extension mcp-server
cd my-first-extension
npm install
npm run build
qwen extensions link .

模板包含 example.ts、qwen-extension.json、package.json、tsconfig.json。build 把 TypeScript 编译到 dist/example.js，清单通过 ${extensionPath} 指向产物。link 在 Qwen 扩展目录连接开发目录，不像 install 创建静态副本。

重启会话并从 /mcp 检查服务发现。修改源文件后仍要重编译，链接不会自动把 TypeScript 变为 JavaScript。官方示例提供 fetch_posts 工具，可用实际模板任务检查调用结果。

先添加无动态 shell 的命令

创建 commands/review-summary.md：

---
description: Summarize the requested review evidence.
---

Summarize the evidence for {{args}} and distinguish confirmed findings from open questions.

重载对应能力或重启后使用 /review-summary。需要动态工具或 shell 注入时，先阅读自定义命令的参数与审批行为；不要把任意用户参数直接当作已验证的 shell 片段。

加入 Skill 和 agent

Skill 放在 skills//SKILL.md，提供 name、description 和执行步骤。扩展名为 my-first-extension、Skill 名为 code-analyzer 时，实际调用 /my-first-extension:code-analyzer。

专门角色放在 agents/ 的 Markdown/YAML 文件中，在 /agents manage 的 Extension Agents 中检查。为角色明确工具集合、任务范围和结果标准，见Subagents。

条件规则与常驻上下文

rules/*.md 应声明 paths，只有触及匹配文件才注入。没有 paths 的扩展规则会被跳过；标签会携带扩展所有者。

根 QWEN.md 或 contextFileName 指定文件则在扩展启用的每个会话、每次请求中加入系统提示，不按任务相关性筛选，也没有该机制的大小上限。只保留身份、术语和硬约束；具体场景方法放 Skill，用 /context detail 测量开销。

分发前检查

确认清单引用的编译产物、命令、Skills 和脚本都在分发包内。实际运行一次发现、调用和错误路径；link 开发环境能用，不代表发布包包含相同文件。准备好后按发布渠道选择 Git、Release 归档或 npm。