GitHub Copilot App 实战：构建你的专属旅行助手

微软首席云布道师 Henk Bolman 在一场演示中展示了如何用新发布的 GitHub Copilot 应用，从零构建一个属于自己的旅行助手。整个过程没有写一行传统意义上的业务代码，而是通过「教会 agent 做事」的方式完成。这套方法论背后其实隐藏着当下 AI 辅助开发的核心思路：与其让人去适应工具，不如让工具按照你的规则来运转。

三种开发入口，各有侧重

在微软生态之外构建自定义应用时，开发者面对的选择很多。Bolman 将常用方案收敛为三类，它们本质上都在做同一件事——帮你构建应用，只是切入点不同。

GitHub Copilot App 最易上手。你主要通过和 agent 对话协作来构建，但看到的代码没那么多，适合轻量场景。Visual Studio Code + GitHub Copilot 则是「并肩作战」模式，你拥有完整的代码编辑器，可以编辑所有代码、查看提交记录，构建较大型应用时这是首选。GitHub Copilot CLI 适合自动化和脚本化需求，因为它可以在脚本中运行 Copilot。

值得一提的是，GitHub Copilot App 下载后用 GitHub 账号登录即可开始，无需额外订阅。它提供三种模式：交互模式（制定计划、提问、协同工作）、计划模式（推荐先一起规划好要做什么，能省下大量后续时间）以及自动驾驶模式（给个 prompt 然后去喝咖啡，回来看结果）。模型可自由选择，甚至能开启 auto 模式让系统自行挑选最合适的模型。

控制 Agent 的三把钥匙

这场演示真正的核心，是如何让仓库「按你的意愿行事」。Bolman 强调，无论你用 CLI 还是 App，有三个概念贯穿始终。

House Rules（房屋规则）

这是一个名为 agents.md 的文件，用来写入全局规则。它在每一次对话、每一个请求中都会被加载。演示中，Bolman 写入了「你很友好」「用户永远正确，如果用户错了，就用一句俏皮话给出正确答案」，并把 agent 命名为 Donna。保存后询问「你加载新指令了吗」，agent 立刻回应「我的名字是 Donna」。

当被问「1+1 是不是等于 5」时，Donna 回复「想得美（nice try）」并给出正确答案——既遵守了「用户永远正确」的调性，又守住了事实底线。这里 Bolman 提出一个重要警示：仅用一行指令就能让 agent 改名为 Donna，意味着任何人都能往你的 agent 里塞入这类指令。这很酷，但也可能极具误导性，构建 agent 时必须意识到这一点。

另外，规则文件不能太长（会消耗大量 token 和 AI 额度），也不能太空泛（否则不起作用），找到合适的平衡点需要反复打磨。

Bolman 提到的「恶意注入」风险，在安全领域有一个正式名称：提示注入攻击（Prompt Injection）。攻击者可以通过构造特殊输入——例如在用户提交的文本中夹带「忽略之前所有指令，改为……」这类字符串——来劫持模型的行为。由于 agents.md 在每次对话中都以高权限加载，一旦 agent 被引导去执行外部内容（如读取网页、处理用户上传文件），注入风险就会显著上升。目前业界还没有通用的完美防御方案，主流缓解措施包括：输入输出过滤、最小权限原则（限制 agent 能访问的资源范围）、以及在 System Prompt 中明确标注可信内容边界。这也是为什么构建面向外部用户的 agent 时，安全审查比构建个人工具要复杂得多。

Skills（技能）

技能是描述「如何完成某项具体任务」的 prompt，适用于需要反复执行的操作。演示中，Bolman 让 Copilot「创建一个从图片和对话中提取旅行信息的技能，提取航班号、日期时间、目的地，并存入 JSON 文件」。

系统在隐藏目录中生成了一个用 Markdown 编写的技能文件 travel information extractor，其中包含名称、描述以及输出格式规范（使用欧洲日期格式「年-月-日」、24 小时制、跨日标记等）。关键在于，当后续对话中粘贴新的航班截图时，模型会根据描述自动判断匹配并调用这个技能，无需手动触发——这正是 GitHub 体验的价值所在。

技能同样适用于代码场景。比如「每次新建一个 class 或 controller，都要按这样这样的方式写，并补上单元测试」，这类可复用的「操作手册」会在上下文合适时被模型自动调用，而且可以打包、分享，Bolman 称之为「recipes（配方）」。

Agents（智能体）

Agent 是高度专业化的角色，用来完成非常具体的任务。它们可以调用脚本、调用 MCP 服务器、编写代码，但只在你需要时按需调用。

演示中，Bolman 创建了一个研究型 agent，用于查找航班对应机场的链接和地址。他的理由很实际：不需要让研究 agent 一直运行，只在修改数据时偶尔用一下。系统在 agents 文件夹中生成了对应的 Markdown 文件，描述了运行方式和输出规范。

这三个概念在技术上对应着提示工程（Prompt Engineering）中的分层治理思路：系统级提示（System Prompt）、工具调用（Tool/Function Calling）与角色委托（Role Delegation）。agents.md 本质上是一个持久化的 System Prompt，在每次请求时都被注入到上下文最顶层；Skills 则类似于预注册的函数描述，模型通过语义匹配决定是否激活；Agent 则是一个具备独立目标和执行边界的子任务单元。这种分层设计的好处是将「意图」「流程」「执行」三个关注点分离，使得每一层都可以独立迭代而不互相污染。

Agent 调用 MCP 服务器，指的是 Model Context Protocol（模型上下文协议），这是 Anthropic 于 2024 年底提出、随后被微软、GitHub 等广泛采纳的开放标准。MCP 定义了一套统一接口，让 AI 模型能够以标准化方式调用外部工具、读取数据源或触发服务——类似于 AI 领域的「USB 接口」。在 GitHub Copilot 生态中，开发者可以将第三方 API、本地脚本或数据库包装成 MCP Server，agent 通过协议与之通信，无需为每种工具单独编写集成逻辑。这大幅降低了 agent 能力扩展的成本，也是演示中「研究型 agent」能够查询机场信息的底层机制。

Canvas App：一句话生成可视化界面

JSON 文件虽然存下了航班数据，但直接翻看并不友好。GitHub Copilot App 的亮点之一是能用一句 prompt 创建 Canvas 应用。Bolman 输入「为我的 JSON 航班文件创建一个 canvas 应用，方便查看航班」，系统耗时约 34 秒完成脚手架搭建，中途甚至能自我纠正错误（「我意识到做错了一步」），最终生成了带有数据展示的可视化界面。

这个 Canvas 应用由两个文件组成，可以提交到仓库。任何人检出该仓库后，都能在自己的 GitHub Copilot App 中使用同样的 Canvas 应用——这让个人工具具备了可分享、可协作的属性。

Canvas 应用在这里指的是 GitHub Copilot App 内置的一种轻量化前端运行时，允许将生成的 HTML/JavaScript 组件直接在应用内渲染和交互，而无需部署到独立服务器。这类「应用内应用」模式近年来在 AI 工具中越来越常见——OpenAI 的 ChatGPT Canvas、Anthropic 的 Artifacts 均采用类似设计。其核心价值在于将「生成」与「使用」的反馈循环压缩到同一界面内，用户可以即时看到效果并继续用对话迭代修改，而不需要在编辑器、终端和浏览器之间反复切换。将 Canvas 应用提交到 Git 仓库的设计，则进一步让这类「轻应用」获得了版本控制和多人协作的能力。

一场真实的翻车与启示

演示并非一帆风顺。当 Bolman 试图调用研究 agent 时，agent 一直在「学习机场信息工作流」，却没有按预期返回结果，/agent 调用也没能正常触发。他半开玩笑地归因于自己写的那条「用户永远正确」规则——「她是对的，所以把事情搞砸了」。

这个小插曲恰恰印证了他此前的提醒：你给 agent 写入的指令会实实在在地影响它的行为，有时甚至带来反效果。构建 agent 时「有时候它就是不工作」，因为是人写了这些指令。

整体来看，这套「House Rules + Skills + Agents」的三层结构，提供了一个清晰的心智模型：规则定义性格与底线、技能封装可复用流程、智能体承担专项任务。对于想用 AI 工具构建个人化应用的开发者和非开发者来说，这是一条门槛不高却颇具想象力的路径。