语境中的范式转变：超越 MCP 的对话原生开发
Source: Dev.to
请提供您希望翻译的具体文本内容，我将为您翻译成简体中文。
介绍
MCP 代表了大型语言模型与外部系统交互方式的根本转变。与其依赖碎片化、一次性的集成，MCP 提供了一种统一的方式，让代理能够访问数据并执行工具。虽然该协议解决了管道问题，但真正的挑战现在在于编排：构建感觉像是对话原生的应用，而不是从网页改编而来。
工具和代理概念
- 工具：一种可调用的函数或 API，使模型能够超出其内部知识进行操作。
- 代理：根据用户意图决定何时以及如何使用这些工具的逻辑。
大多数今天接触 MCP 的开发者来自以浏览器为中心的范式，应用围绕页面、表单和点击构建。转向聊天原生开发需要放弃许多这些假设，并围绕对话作为主要界面进行设计。
常见错误
MCP 应用中最常见的错误是把聊天当作命令行来使用，而不是把它视为一个活的、具备上下文的环境。有效的聊天原生系统依赖以下三大核心原则：
- 持久的对话上下文
- 基于推理的内容生成
- 通过大型对话平台（如 ChatGPT）进行分发
设计原则
MCP 使意图和操作能够在同一对话线程中共存。与其将聊天中的信息复制到其他应用程序，MCP 支持的系统可以直接对用户的意图采取行动。例如，关于餐食计划的对话可以直接生成已填好的购物车，而无需离开聊天，从而消除摩擦并避免上下文切换。
工具设计
大型语言模型通过参数进行推理，而模糊或写得不好的工具元数据常常导致调用错误或失败。高质量的 MCP 实现会高度重视精确的工具描述和参数定义，以便代理能够可靠地判断何时以及如何在对话中调用相应的功能。
“Vibe Coding” 与 Fractal
“Vibe coding” 描述了一种转变，开发者使用自然语言表达意图，让 AI 系统生成底层实现。这种方法显著降低了研究人员和领域专家的门槛——他们了解工作流，但并不深入熟悉编程语言。
像 Fractal 这样的平台通过使用专用代理来处理开发的规划阶段，应用了这一概念。开发者不再手动定义 schema，而是提供一个 API 端点和预期体验的描述。系统随后：
- 读取并解释 API 文档
- 提出一个兼容 MCP 的工具 schema，并附上适当的元数据
- 生成一个沙盒化的接口用于测试和迭代
这种转变将瓶颈从 如何 构建转移到 构建什么。当代理能够一次性生成可工作的 MCP 工具时，真正的价值在于设计引人入胜的、聊天原生的体验，而不是编写样板代码。
技术细节
在底层，MCP 依赖于客户端与服务器之间的结构化交互。当用户提交提示时，模型会评估可用的工具定义，这些定义通常以 JSON 架构的形式描述工具的用途和输入。
实际上，这需要在聊天界面和底层 API 之间进行精细的连接。工具定义必须与模型解释意图和参数的方式保持一致。越来越多地，AI 系统被用于自行生成这些指令，因为模型往往比人工工程师更了解自己的调用约定。这提升了可靠性，并确保用户请求能够以正确的上下文参数映射到合适的工具。
当前状态与未来方向
MCP 的当前阶段类似于移动开发的早期。最初的应用仅仅是把已有的网页体验包装起来，导致界面显得笨拙且受限。真正的突破出现在开发者采用移动原生设计，而不是迁移桌面模式时。
MCP 仍然主要处于这种迁移阶段。许多实现只是对现有服务的薄包装。真正的颠覆将来自聊天原生系统，在这些系统中，界面是次要的，核心在于编排和上下文管理。
一个尚未解决的挑战是工具调用时的幻觉（hallucination）。错误的参数可能触发意外操作，尤其是在敏感领域。随着 MCP 系统的成熟，强大的验证层和人工在环（human‑in‑the‑loop）确认将变得至关重要。
致谢
感谢 Hanh Nguyen 和 Fractal 团队在 MCP 开发者峰会上的演讲。该演讲 “The Easiest Way to Build ChatGPT Apps (Instead of MCP Apps)” 提供了关于从传统应用开发向对话原生设计转变的宝贵见解。也感谢更广泛的 MCP 与 AI 社区推动开放、可互操作的代理系统。
The Easiest Way to Build ChatGPT Apps (Instead of MCP Apps)