命令行里的 Power Platform，第一部分：Copilot CLI 是什么以及插件如何组织
微软现在为 Power Platform 开发提供了一套官方的智能体插件，放在 microsoft/power-platform-skills 市场上。这套插件兼容两款使用相同插件格式的命令行智能体工具：GitHub Copilot CLI 和 Anthropic 的 Claude Code。本系列将从零开始完整介绍：这两款 CLI 是什么，如何下载所有 Power Platform 插件，如何读懂插件做了什么，逐一盘点全部七个插件，最后用一个实际例子把它们串成一个完整方案。由于这两款 CLI 极其相似，我会全程同时展示 Copilot CLI 和 Claude Code 的命令，你选哪一款都行——插件完全一样。
什么是“智能体 CLI”？
如果你在 VS Code 里用过 GitHub Copilot，应该熟悉那种自动补全加聊天式的体验。而智能体 CLI 完全是另一回事。它是一个在终端里运行的程序，能和你对话、读写项目文件、执行 Shell 命令、调用 MCP 服务器，还能代表你执行多步骤操作——每一步都会停下来向你请求许可。目前主流的有两款，它们之所以重要，是因为都支持同一种插件格式：
- GitHub Copilot CLI — GitHub 的终端智能体，通过
copilot命令启动，需要 GitHub Copilot 订阅。 - Claude Code — Anthropic 的终端智能体，通过
claude命令启动，需要 Claude 订阅或 API 密钥。
同一个微软市场能同时服务这两款，是因为它们对“插件”的定义达成了一致：一个文件夹，里面包含 skills、agents、MCP 服务器定义以及一个清单文件。Copilot CLI 查找 .plugin/ 文件夹；Claude Code 查找 .claude-plugin/ 文件夹；而 Power Platform 仓库直接把两种文件夹都打包好，内容完全一样。
安装 CLI
两款 CLI 都通过 npm 安装，也都需要较新版本的 Node。
GitHub Copilot CLI（需要 Node.js 22 以上，以及有效的 Copilot 订阅）：
npm install -g @github/copilot
第一次启动 copilot 时会提示你进行身份验证。进入会话后，使用 /login 斜杠命令进行身份验证，并按照提示操作。如果你更想用 token，可以创建一个具有 Copilot Requests 权限的细粒度个人访问令牌，并将其导出为 COPILOT_GITHUB_TOKEN（或 GH_TOKEN / GITHUB_TOKEN）。
Claude Code 需要 Node.js 18+ 和一个 Claude 账户：npm install -g @anthropic-ai/claude-code
首次启动 claude 时会引导你完成登录。
两者都是交互式 REPL（读取-求值-输出循环）。你直接用自然语言输入请求，代理会建议操作，然后你批准执行。斜杠命令（任何以 / 开头的命令）是用来控制工具本身，而不是跟模型对话——这就是你管理插件的方式。
文件存在磁盘的哪里？
这部分很容易让人搞混，所以具体说明一下。两种工具都不会把插件直接丢进你的项目目录里，它们各自使用一个用户专属的家目录。
Copilot CLI 的组织方式如下：
~/.copilot/
├── installed-plugins/
│ ├── <marketplace-name>/
│ │ └── <plugin-name>/ # 从市场安装的插件
│ └── _direct/
│ └── <source-id>/ # 直接安装的插件（非通过市场）
└── ... # 配置文件、日志、会话状态
市场本身会单独缓存到操作系统特定的位置——Linux 下是 ~/.cache/copilot/marketplaces/，macOS 下是 ~/Library/Caches/copilot/marketplaces/，Windows 下是对应的位置。每个插件还会获得一个私有的可写临时目录，该目录通过环境变量 COPILOT_PLUGIN_DATA 暴露给插件。
Claude Code 在自己的家目录下保存类似的结构：
~/.claude/
├── plugins/ # 已安装的插件 + 市场克隆
├── settings.json # 权限、默认模式等
在命令行中使用 Power Platform，第一部分：Copilot CLI 是什么，插件如何组织
两者的心智模型是一样的：市场本质上就是一个装满插件的 Git 仓库；安装插件时，会把该插件的文件夹复制（或链接）到 CLI 的家目录下，这样插件中的技能和代理就能在每个会话中使用了。
插件文件夹结构解析
接下来才是真正有用的部分。一旦你掌握了插件的结构，就能在大约一分钟内打开任意一个插件并搞懂它的功能——完全不需要文档。Power Platform 市场中的所有插件都采用相同的布局。以下是经过精简的 power-pages 插件的真实结构：
power-pages/
├── .plugin/plugin.json # 清单文件（Copilot CLI 读取此文件）
├── .claude-plugin/plugin.json # 相同的清单文件（Claude Code 读取此文件）
├── .mcp.json # 此插件附带的 MCP 服务器
├── AGENTS.md # 代理为该领域加载的指令
├── CLAUDE.md -> AGENTS.md # 符号链接，使两个工具读取相同的指引
├── README.md
├── skills/ # 你可以调用的各项能力
│ ├── create-site/
│ │ └── SKILL.md
│ ├── deploy-site/
│ ├── plan-alm/
│ └── ...
├── agents/ # 技能委派给专门的子代理
│ ├── data-model-architect.md
│ └── ...
├── references/ # 技能根据需要引用的参考文档
├── scripts/ # 辅助脚本（版本检查、启动器等）
插件的目录结构详解
下面几个文件夹承载了大部分含义：
-
manifest（
plugin.json）：插件的身份证明——名称、版本、描述、作者和关键词列表。Copilot CLI 会按顺序查找：.plugin/plugin.json→plugin.json→.github/plugin/plugin.json→.claude-plugin/plugin.json。Claude Code 只在.claude-plugin/plugin.json里找。两个都放上，你的插件就能在不同平台间移植。 -
skills（
skills/*/SKILL.md）：真正的能力。每个 skill 是一个文件夹，里面有个SKILL.md文件，其 front matter 声明了名称、使用场景描述、是否允许人类直接调用，以及它可以使用哪些工具。当你对 CLI 说“创建一个 Power Pages 网站”，实际调用的就是名为create-site的 skill，它会被加载来指导整个工作。第 2 部分我们会逐行解读一份 skill 文件。 -
agents（
agents/*.md）：更细分的专业选手。一个 skill 可以把任务交给更专一的 agent 去处理——比如data-model-architect，它只专注于设计 Dataverse 表。插件正是通过这种机制实现并行化和专注。 -
MCP 配置（
.mcp.json）：列出了插件依赖的 Model Context Protocol 服务。例如 Power Pages 插件自带一个 Playwright 服务（让 agent 可以在浏览器里打开你的网站并检查效果），外加托管的 Microsoft Learn MCP 服务（这样 agent 就能查阅官方文档，而不是瞎猜）。CLI 会在需要时自动启动这些服务——你不需要单独安装它们。 -
AGENTS.md / CLAUDE.md：针对该领域的常驻简报：约定、规则，以及各个 skill 如何配合。通过符号链接，Copilot CLI（读
AGENTS.md）和 Claude Code（读CLAUDE.md）读取的是完全相同的指导内容。
为什么要理解这个结构
你不需要盲目信任一个插件。因为所有东西都是明文文件——JSON 清单、Markdown skill、一个很小的 MCP 配置——你可以在运行插件之前，清清楚楚看到它会做什么、能接触到什么。这种透明性正是下一篇的重点：我们会添加 Power Platform 市场、安装插件，然后打开它们，看看每个插件到底干了什么。