智能编排：使用 Model Context Protocol 简化代理工作流

Source: Dev.to

请提供您希望翻译的具体文本内容（除代码块和 URL 之外），我将把它翻译成简体中文并保留原有的格式。谢谢！

概览

在当前的人工智能格局中，tool 是指大型语言模型（LLM）可以调用的、用于与外部世界交互的离散功能单元，而 agent 则是能够规划并执行这些工具序列以实现目标的自主实体。

开发者长期面临的挑战是这些工具的定义和连接方式高度碎片化。Model Context Protocol (MCP) 通过提供一个统一的标准，解决了代理如何发现并与外部资源交互的问题。

为什么 MCP 很重要

• 通用集成 – 与之前需要为每个新 API 编写定制集成代码的框架不同，MCP 允许开发者只需一次编写服务器，即可将其功能暴露给任何符合规范的客户端。
• 对话式编排 – NimbleBrain Studio 使用该协议，用对话界面取代传统自动化平台中复杂的“盒子‑线”图示。用户与编排器交互，编排器了解可用的工具注册表，并通过自然语言配置工作流。

从确定性逻辑到基于意图的执行

传统的自动化工具（例如 Zapier、Make.com）依赖静态路径；一次步骤失败或轻微的需求变更往往会迫使整个工作流进行手动重新设计。

相比之下，基于 MCP 的方法使用大型语言模型（LLM）来：

1. 实时解释用户意图。
2. 将意图映射到注册表中的相应工具。
3. 动态执行这些工具。

NimbleBrain的 AI 助手 – Nerra

Nerra 充当指南，帮助导航底层的 MCP 生态系统。

• 示例请求： “监控科技头条并给我发送摘要邮件。”
• 发生的过程：
  1. 系统查询其内部 MCP 注册表，寻找能够获取新闻并发送电子邮件的服务器。
  2. 系统将这些能力合成为一个 playbook（剧本）——一组指令，代理通过调用相应的 MCP 工具来执行。

关键开发者收益

部署 MCP 服务器 – MCPB 概念

虽然协议定义了运行时通信，但部署可能相当复杂。MCP Bundle (MCPB) 将服务器打包成轻量、可移植的制品。

构建生命周期

1. 使用 TypeScript、Go 或 Python 编写逻辑（通常会使用 FastMCP 等辅助库）。
2. 通过 GitHub Actions 将其 打包 为针对特定架构的 MCPB 制品。
3. 将制品 发布 到注册表，以实现即时可发现性。

示例：使用 FastMCP（Python）的简易 MCP 服务器

from fastmcp import FastMCP

# Create an MCP server
mcp = FastMCP("WeatherService")

@mcp.tool()
def get_weather(city: str) -> str:
    """Fetch the current weather for a given city."""
    # In a real scenario, this would call a weather API
    return f"The weather in {city} is sunny, 25°C."

if __name__ == "__main__":
    mcp.run()

制品是惰性的压缩文件，包含服务器运行所需的一切。 由于它们已经预编译，运行时可以在几秒钟内启动，大幅降低用户提示与代理首次调用工具之间的延迟。

Runtime Flow When a Playbook Executes

1. Intent Parsing – LLM 分析用户请求并识别所需的功能。
2. Registry Lookup – 系统根据 MCP 注册表模式（MCP registry schema）查询 MCP 注册表，以获取相应的 bundle。
3. Resource Provisioning – 基于 Kubernetes 的运行时（例如 Nimble Tools Core）拉取所需的 MCPB bundle。
4. Execution – 运行时启动服务器并建立通信通道（通常通过 stdio 或 SSE），使代理能够执行工具调用。
5. Validation – “LLM Judge” 对工具调用的输出与原始意图进行评估，以判断成功、部分成功或失败。

此流程使得即使是 私有 或 小众 数据源（例如本地车辆数据库）也能与 Slack、HubSpot 等公共 API 一起编排。该协议提供了将不同系统桥接到统一对话工作区所需的“语法糖”。

平衡对话自动化与可靠性

• 生产力提升 – 通过 MCP 抽象线路，使研究人员和工程师能够专注于高级逻辑，而不是低层 API 的繁琐工作。
• 非确定性 – 依赖 LLM 会引入变异性。“LLM Judges” 能在一定程度上缓解此问题，但要实现对关键任务 ETL 过程的 100 % 可靠性仍具挑战。
• 混合未来 – 对话式界面在快速原型和人机交互任务中表现出色，而传统的基于 DAG 的工作流在大批量、严格模式的流水线中仍具优势。

致谢

我想感谢 Mathew Goldsborough 在 MCP 开发者大会上关于 Orchestrating Intelligence with MCP 的深刻演讲。他对 NimbleBrain Studio 的演示清晰展示了 MCPB 与对话工作流的实际应用。我也感谢更广泛的 MCP 和 AI 社区，他们致力于建立开放标准，使代理互操作性成为可能。