VS Code 内构建 AI Agent：MCP 集成实战

为什么选择在 VS Code 里构建 Agent

传统 AI Agent 开发往往需要在本地环境、云平台和代码编辑器之间反复切换，调试链路长、上下文容易丢失。而据 YouTube 频道分享的演示，开发者可以直接在 VS Code 中完成从模型配置到工具调用的全流程。这种「不离开编辑器」的体验，把模型部署、系统指令定制、工具连接等环节压缩到同一个工作界面内，显著降低了 Agent 原型的启动成本。

演示的核心思路是：先保存模型，再通过系统指令赋予角色，最后接入外部工具完成真实任务。下面的步骤拆解了这一过程的关键节点。

第一步：保存模型并验证连通性

演示从模型详情更新开始。开发者将模型和名称保存到 Foundry，然后发送了一条简单的「hello」消息进行测试。截图显示这次调用消耗了 20 个 token——这个细节说明模型已经成功响应，且 token 计量正常工作。

这一步的意义在于建立基线：在引入复杂指令和工具之前，先确认模型可用、计费透明。对于后续调试来说，有一个干净的起点能帮助定位问题究竟出在模型、指令还是工具连接上。

Foundry 这里指 Azure AI Foundry（原 Azure AI Studio），是微软提供的模型托管与 AI 应用开发平台。开发者可以在其中部署、管理和版本化模型，并通过统一的端点对外提供推理服务。演示中「将模型和名称保存到 Foundry」意味着模型被注册为一个可被后续调用引用的资源，其名称既是标识符也是调用入口。Foundry 同时提供 token 计量与计费统计，因此 hello 测试中显示的 20 token 消耗正是平台侧返回的用量数据。理解这一点有助于区分「模型本身」与「模型在平台上的部署实例」——后续的系统指令与工具配置都是绑定在部署实例之上的。

第二步：用系统指令定义 Agent 角色

模型连通后，演示转向定制化。开发者添加了系统指令（system instruction），为 Agent 设定了一个具体场景——纸杯蛋糕店（cupcake store）。系统指令的作用是约束 Agent 的行为边界和回复风格，让它围绕特定业务场景作答，而不是给出泛泛的通用回复。

从工程角度看，这一步是把「通用模型」转化为「领域 Agent」的关键。系统指令写得越具体，Agent 在后续调用工具时的意图判断就越准确。演示选择纸杯蛋糕店作为示例，虽然业务简单，但完整覆盖了「角色定义→工具挂载→对话调用」的链路。

第三步：创建 MCP 服务器连接

要让 Agent 真正执行任务，仅靠指令不够，还需要接入外部工具。演示中开发者创建了一个自定义 MCP（Model Context Protocol）服务器连接。配置项包括连接名称（设为 cupcake store）、远程服务器端点，以及认证方式——由于该示例服务不需要认证，因此直接连接、未添加任何鉴权信息。

连接创建成功后，界面提示连接已建立。这里说个细节 MCP 作为工具接入协议的角色：它把外部服务的端点、名称和认证信息封装成一个可被 Agent 调用的连接单元，让模型无需关心底层通信细节。对于需要鉴权的生产服务，同一套配置流程只需补上认证字段即可。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底提出的开放协议，用于标准化大模型应用与外部数据源、工具之间的连接方式。它采用客户端-服务器架构：Agent 一侧作为 MCP 客户端，外部服务以 MCP 服务器形式暴露能力（如查询、检索、执行操作），双方通过 JSON-RPC 消息通信。协议定义了工具（tools）、资源（resources）、提示模板（prompts）等原语，使同一个 MCP 服务器可以被不同模型和不同 Agent 框架复用。这解释了为什么演示中只需填写端点与认证信息即可挂载工具——通信格式与能力描述由协议统一约定，Agent 无需为每个服务单独编写适配代码。

第四步：挂载工具并发起对话

连接就绪后，开发者将纸杯蛋糕店这个工具添加到 Agent 的工具列表中。此时在对话界面中，Agent 已经能够识别并调用该工具，完成与纸杯蛋糕店相关的请求。

整个流程走完，一个具备角色设定和外部工具调用能力的 Agent 就在 VS Code 内完成了搭建。演示没有涉及复杂的多工具编排或错误处理，但把最小可用链路的每个环节都展示清楚了。

工具调用（tool calling / function calling） 是让模型突破纯文本生成、与外部世界交互的机制。其流程为：模型在对话中判断需要外部信息或操作时，输出一个结构化的调用请求（工具名加参数），由运行时执行该调用并将结果回传给模型，模型再据此生成最终回复。因此工具挂载后，Agent 并非「直接知道」纸杯蛋糕店的数据，而是在对话中动态发起调用。工具的描述文本（名称、用途、参数 schema）会作为上下文提供给模型，描述越清晰，模型选择正确工具、填写正确参数的概率越高。这也意味着工具数量增多时需注意上下文开销与选择歧义问题。

这种开发模式的启示

从演示可以看出，VS Code 内的 Agent 构建正在走向「配置驱动」：模型保存、指令编写、连接配置、工具挂载都由界面操作完成，代码量被大幅压缩。这对快速验证想法非常友好——开发者可以在几分钟内把一个业务场景跑通，再决定是否投入更多工程资源。

MCP 的引入则让工具扩展变得标准化。不同外部服务通过统一的连接配置接入，Agent 的能力边界可以按需扩展，而不必为每个服务重写集成逻辑。对于希望在编辑器内完成 AI 应用原型的团队来说，这条路径值得尝试。