为何我们放弃定制API封装转投MCP协议

如果你曾通过将 OpenAPI 规范塞进系统提示词来连接 LLM 和内部 REST API，你就会知道具体的失败点：

// What you asked for:
{ "action": "update_user", "user_id": "usr_9912", "status": "active" }

// What the model hallucinated at 2 AM:
{ "action": "modify_account", "id": 9912, "state": "enabled", "force": true }

当 LLM 幻觉出参数或编造出不存在的查询字符串时，这不仅仅是一个错误——它可能破坏生产数据库状态。

在 Omnifys，我们的 Agent 直接与 CRM、ERP 和内部 SQL 数据库交互。我们很快意识到，为每个工具调用编写自定义 JSON Schema 粘合代码是不可维护的。这就是我们将整个 Agent 执行层迁移到 Model Context Protocol (MCP) 的原因。

Custom Tool Calling 的核心问题

基于自定义提示词的工具调用因三个架构缺陷而失败：

Schema Drift Vulnerability： 如果你修改了后端 endpoint，更新整个管道中的每个系统提示词和微调指令是脆弱的。

Context Window Waste： 将大量 API 文档塞进提示词 token 会增加延迟并消耗计算预算。

Weak Sandboxing： 嵌入在 Agent 上下文中的直接 API 密钥会在发生间接提示词注入时暴露后端服务。

MCP 蓝图：标准化工具执行

MCP 将工具视为独立的、类型化的服务器，而非静态的提示词文本。Agent 在运行时向 MCP 服务器查询以发现能力：

[ Inbound Request ] │ ▼ [ LLM Reasoning Step ] │ ▼ [ MCP Client ] ── (Discovers available tools via standardized schema) │ ▼ [ MCP Server ] ── (Validates types, checks row-level auth, executes handler) │ ▼ [ Production API / DB ]

Strongly Typed Schemas

工具暴露具有严格 JSON Schema 验证的标准化 schema。如果模型尝试传递 "id": 9912（而需要字符串 UUID），MCP 边界会在负载接触网络之前拒绝它。

Ephemeral Context Discovery

Agent 根据任务意图动态查询 MCP 服务器，而非将整个后端 API 加载到系统提示词中。这保持了提示词 token 的最小化，并将响应延迟保持在 400ms 以下。

Least-Privilege Scoping

工具权限在传输层处理。Agent 永远不会收到原始数据库凭据；它只收到一个会话范围的令牌，允许在严格的租户边界内进行特定的读或写操作。

实践要点

将 AI 工具视为标准协议端点而非自定义提示字符串，使混乱的模型输出转化为可靠、确定性的代码执行。

如果你正在评估 Agent 架构或构建治理自动化管道，欢迎访问 https://omnifys.com/ 了解我们如何实现 MCP 和 Agent 工作流。

你的看法

你目前在使用 MCP、Function Calling 还是自定义提示词包装器来处理 Agent 工具？工具 schema 验证中最大的痛点是什么？