0%

MCP 实战思考:让 AI Agent 读懂真实业务上下文

模型知道很多通用知识,却不天然知道公司的菜单 Code、接口约定和发布流程。MCP 的价值,是用一套可组合的协议把这些真实上下文交给 Agent。

MCP 是什么

MCP(Model Context Protocol)是一种让 AI 应用连接外部上下文和工具的协议。可以把它理解为 AI 世界的“适配层”:Host 是承载 Agent 的应用,Client 负责连接,Server 暴露 Tools、Resources 和 Prompts。

1
2
3
4
5
6
Host(Agent / IDE)
↓ Client
MCP Server
├── Tools:执行动作
├── Resources:读取上下文
└── Prompts:复用任务模板

MCP 与普通 API 的区别

普通 API 面向业务程序员,MCP 更强调让模型理解能力边界、参数描述和返回结果。它不是替代权限系统,也不是把数据库裸奔给模型;每一个 Tool 仍然应该做输入校验、权限校验、审计和最小化返回。

一个前端项目的 MCP Server

可以为项目提供“读取页面清单”和“检查路由”的工具:

1
2
3
4
5
6
server.tool("find_page", "按菜单 Code 查找页面", {
code: { type: "string", description: "页面 Code" },
}, async ({ code }) => {
const page = await pageRegistry.find(code);
return { content: [{ type: "text", text: JSON.stringify(page) }] };
});

Agent 因此能够先读取真实注册信息,再提出修改方案,而不是凭经验猜目录结构。

工具、资源和提示词

  • Tools:有副作用的动作,例如运行测试、生成页面、查询接口。
  • Resources:只读上下文,例如设计规范、路由表、接口文档。
  • Prompts:经过验证的任务模板,例如“按项目规范新增一个菜单页面”。

一个成熟系统通常先开放 Resources,再开放只读 Tools,最后对写操作增加人工确认。

安全边界

MCP Server 不应直接暴露生产 Token、用户隐私和任意 Shell。工具参数要有 Schema,来源要可识别,危险动作要二次确认,返回结果要脱敏。对前端团队而言,代码仓库、依赖清单和接口契约都可以作为上下文,但密钥永远不应成为上下文。

如何在前端项目中引入

不需要一开始就把整个公司系统接入 MCP。可以从一个只读 Server 开始,放在项目或团队工具目录中:

1
2
3
4
5
6
7
8
9
tools/mcp/
├── server.ts
├── resources/
│ ├── routes.ts
│ └── components.ts
├── tools/
│ ├── find-page.ts
│ └── check-route.ts
└── README.md

第一阶段只提供读取页面、菜单、组件文档和检查结果的能力;第二阶段再增加生成测试、运行局部检查等低风险动作;修改文件、提交代码和发布操作应继续由开发者明确确认。

1
2
3
4
5
6
const context = await mcp.readResource("project://routes");
const result = await agent.run({
goal: "新增一个合规报表页面",
context: [context],
allowedTools: ["find_page", "check_route"],
});

MCP 在日常开发中的使用方式

一个可落地的任务可以这样执行:先让 Agent 查询现有菜单和页面,再读取设计规范;Agent 输出方案后,由开发者确认;实现时调用本地检查工具;最后把检查结果写入任务报告。这样 Agent 的回答来自项目当前状态,而不是来自过期记忆。

MCP Server 的工具描述也要像公共 API 一样维护。名称要表达动作,参数要有类型,返回值要稳定,并提供失败信息。工具调用日志只记录必要的任务信息,不把源代码、用户数据和凭证无差别写入日志。

小结

MCP 解决的是“Agent 如何连接真实世界”,重点是协议化、可发现和可治理。它让 Agent 从通用问答进入具体项目,但最终质量仍取决于上下文质量和权限设计。

bulb