在终端里造一个AI智能体：GitHub Copilot CLI实战

用户打开一个网站，往往不是带着明确的筛选条件来的，而是带着一种模糊的感觉。Tailspin Toys 是一个面向开发者主题桌游的众筹网站，它的分类和发行商筛选功能虽然实用，却无法回答"喜欢 Gitpans 的人会喜欢哪些游戏"这类问题。于是，一位开发者用 GitHub Copilot CLI 配合 Microsoft Foundry 和 Azure 技能，构建了一个名为"Backer Concierge"的智能体——它能记住对话上下文，更重要的是，绝不编造信息。

核心设计：信任边界与数据接地

整个项目的起点是一个 catalog.json 文件，包含 21 款游戏的信息，每款有标题、描述、类别、发行商和星级评分。说个细节，这个文件里没有任何关于筹款总额、支持者账户、奖品或游玩时长的数据——这个信息缺口就是开发者所说的"信任边界"，智能体必须尊重它。

在 GitHub Copilot CLI 中，开发者切换到计划模式，要求它使用 Microsoft Foundry 技能来规划一个托管智能体，并指定了偏好的技术栈和代码文件结构。Copilot 引入 Azure 技能、最佳实践和 Foundry 文档后，确认了核心目标：智能体只基于目录内容回答。

随后，Copilot 创建了 Azure 资源组和 Foundry 项目。过程中出现了一个插曲——所选区域拒绝新建 Foundry 资源，Copilot 自动删除了在错误区域创建的内容，并根据开发者指引在另一个区域重建。这种自动纠错能力展现了工具链的成熟度。

什么是"数据接地"（Grounding）？ 在大模型语境中，接地指的是让模型的回答严格锚定在给定的可信数据源上，而非依赖训练时记忆的知识进行自由生成。未经接地的模型容易产生"幻觉"（Hallucination），即编造看似合理但实际不存在的信息。RAG（检索增强生成）是最常见的接地手段，而本文采用的是更直接的方式：把 catalog.json 全部内容作为上下文喂给智能体，并在系统提示中明确约束"只基于目录回答"。接地的价值在于可验证性——每个回答都能回溯到目录中的某条记录，从而让推荐结果对用户可信。

信任边界（Trust Boundary） 原本是安全领域的术语，指系统中不同信任级别的区域之间的分界。本文借用这个概念描述"智能体知道什么、不知道什么"的界线：catalog.json 中没有筹款总额、支持者账户等字段，这条边界一旦被跨越，智能体就只能编造。把边界显式化，既是提示词约束的依据，也是评估集的验收标准来源。

模型选型与测试策略

面对数千个可选模型，开发者让 Copilot 根据需求文档中的验收标准推荐两到三个方案。Copilot 综合考量了退役日期、能力、任务匹配度和订阅配额，推荐了 GPT 5.4 Mini、GPT 5.6 Lunar 和 GPT 5.4 Nano。最终选择了 GPT 5.4 Mini，覆盖智能体的全部需求。

在编写智能体代码之前，开发者先测试了模型本身。Copilot 发送了一个典型的支持者问题和目录数据，报告了输出结果和 token 用量。测试通过——模型给出了基于数据的正确答案，当答案不在目录中时，它如实说明而非编造。这个 token 计数为后续预算提供了基线。

为什么要在写智能体代码前单独测试模型？ 大模型本身的能力（是否忠于上下文、是否在信息缺失时承认不知道）与智能体框架的编排逻辑是两回事。先做"模型级"测试，可以用最小的成本确认底层模型的接地能力是否达标——如果模型天然爱编造，再精巧的提示词工程也难以根治。此外，单次调用的 token 用量在此阶段就能测量出来，为后续的配额规划和成本预算提供基线，避免上线后才发现速率或费用超支。这种"先验证组件、再组装系统"的思路，与传统软件工程中的单元测试一脉相承。

从模型到智能体：代码生成与本地评估

将模型转化为智能体只用了一条提示：基于计划中捕获的基础托管智能体样本，要求每个回答都接地于目录，绝不编造缺失信息。Copilot 编写了智能体代码并连接了智能体检查器，方便测试。开发者用 /diff 命令检查了新增文件，其中 azure.yaml 配置文件的第七行将主机设置为 azure.ai.agent，指向 Foundry 智能体服务的部署。

本地评估阶段，开发者使用了一个小型评估集——七组问题与预期答案配对。首轮测试四组通过，三组失败：遗漏了已知事实、跳过了后续追问、触发了速率限制。核心任务——从目录中给出准确答案——已经达成，但行为层面仍有优化空间。开发者让 Copilot 根据这些结果收紧提示词，并在 Foundry 门户中提高了模型的速率限制。很快，全部验收测试通过。

部署与安全连接

本地运行当然好，但目标是云端托管。开发者要求 Copilot 检查部署就绪状态并部署到 Microsoft Foundry。底层操作是 Azure Developer CLI 打包代码、远程构建并发布。Backer Concierge 上线后，测试提示返回了目录中的真实游戏 Bug Buster Brain Teaser。

最后一步是将智能体连接到网站。Tailspin Toys 网站是完全预渲染的，没有后端服务器，浏览器无法直接调用智能体，也不应持有 Foundry 凭证。开发者让 Copilot 构建了一个小型 Azure Functions 代理，在本地运行，用开发者自己的 Azure 登录认证到 Foundry，调用智能体，只将答案返回给浏览器。有了这个安全的服务端凭证边界，最后一个拼图是网站上的可访问聊天组件。现在，支持者可以描述他们的心情偏好、追问后续问题，并获得接地于目录的推荐。

为什么预渲染网站不能直接调用智能体？ 纯预渲染（Static Site Generation）的站点没有自己的服务端，所有代码都在浏览器中执行。若浏览器直接请求 Foundry 智能体服务，API 密钥或访问令牌就必须下发到前端，任何用户按 F12 就能查看并盗用，等于把云资源凭证公开。Azure Functions 代理的作用是在服务端建立一条可信通道：代理使用托管身份或开发者登录态向 Foundry 认证，浏览器只与代理交互，凭证始终不出服务端。这是典型的"后端换凭证"（Backend-for-Frontend）模式，让静态站点也能安全地消费需要密钥的 AI 服务。

工作流启示：每一步都始于一条提示

回顾整个流程：测试模型的接地能力、构建和测试托管智能体、部署到 Microsoft Foundry、通过凭证安全的代理连接到网站——每一个步骤都始于一条提示。Copilot CLI 和 Foundry、Azure 技能负责构建，开发者只做决策。

这种工作流的价值不在于"AI 替代了开发者"，而在于将基础设施搭建、配置管理、部署编排等机械性工作压缩成了对话。开发者需要具备的仍然是架构判断力：设定信任边界、选择模型、设计评估集、识别安全边界。工具降低了执行门槛，但没有降低思考门槛。

说个细节，开发者在演示结束时提醒：完成后记得删除资源组。这个细节反映了云资源管理的现实——再智能的工具链也需要人工把控成本。

"提示即操作"意味着什么？ 传统的云开发需要在门户点击、编写 IaC 模板、手动配置 CLI 命令；而 Copilot CLI 把这些动作压缩成了自然语言指令，由它调用 Azure Developer CLI（azd）、Foundry 技能等底层工具去执行。开发者从"操作者"变成了"意图表达者与结果审查者"。但需要警惕的是：自动化遮蔽了执行细节，一旦出错（如区域选错导致资源创建失败），仍需要开发者理解底层机制才能给出正确指引。因此提示驱动的工作流并不会消灭对基础设施知识的需要，反而要求开发者更清楚"我到底想让系统做什么"。