MCP orchestrator production

MCP编排器v2——第6阶段（完整自述文件）

一个生产就绪、以微服务为中心的编排框架，构建于：

• 规范JSON v2信封
• 严格类型的微服务I/O
• 使用端到端可追溯性 trace_id
• 完全解耦的通道→ 适配器→ 编排器→ 微服务
• 无存根逻辑的生产安全流程
• 后端无关的POST微服务（n8n/Make/API/DB/POS）

______________________________________________________________________

1.高层架构

______________________________________________________________________

2.与典型代理框架的比较（更新）

为何这很重要

此MCP v2不是聊天机器人包装器，而是 真实编排平台.

传统的代理框架依赖于单个LLM来猜测工作流。MCP v2转而使用：

• 确定性流逻辑
• 编码微服务路由
• 严格的JSON合约
• 完全可观测性
• 后端/LLM独立性

这就是MCP v2的原因 可维护、可扩展、可预测和企业就绪.

______________________________________________________________________

3.规范JSON v2信封规范

（保留了上一代的确切细节。）

3.1渠道→ 适配器输入

channel_input.json

{
  "version": "1.1",
  "timestamp": "2025-11-21T21:28:56.146Z",
  "context": {
    "channel": "voice",
    "device": "browser",
    "locale": "en-US",
    "tenant": "blinksbuy"
  },
  "session": {
    "session_id": "sess-123:web",
    "conversation_id": "conv-001",
    "user_id": "user-123",
    "turn": 1
  },
  "request": {
    "type": "text",
    "text": "Can you read me the menu?",
    "transcript": "can you read me the menu"
  },
  "observability": {
    "trace_id": "trace-abc-123",
    "message_id": "msg-1"
  }
}

3.2适配器→ 编排器

mcp_adapter_request.json

{
  "text": "Can you read me the menu?",
  "user_id": "user-123",
  "channel": "web",
  "session_id": "sess-123:web",
  "trace_id": "trace-abc-123"
}

3.3编排器→ 适配器输出

mcp_orchestrator_response.json

{
  "decision": "reply",
  "reply_text": "Here is the menu...",
  "session_id": "sess-123:web",
  "route": "menu",
  "intent": "menu",
  "intent_confidence": 0.92,
  "trace_id": "trace-abc-123"
}

______________________________________________________________________

4.内部微服务I/O合同

保留了精确的I/O文件（意图、流程、菜单、顺序、推荐、跟踪、配置文件）。

每个如下：

POST /service
Body:
{
  "user_id": "",
  "session_id": "",
  "channel": "",
  "trace_id": "",
  ...service‑specific fields...
}

4.1意向服务I/O

（…完全包含在早期的JSON集合中…）

4.2流量服务I/O

（…完全包含…）

4.3菜单/订购/推荐/跟踪/个人资料服务

（…完全包含不变…）

______________________________________________________________________

5.美人鱼图

flowchart TD
    classDef actor fill:#fdf6e3,stroke:#555;
    classDef layer fill:#eef3ff,stroke:#555;
    classDef svc fill:#f9f9ff,stroke:#777;
    classDef json fill:#fff,stroke:#aaa;

    U[User]:::actor
    C[Channel]:::layer
    CI[[channel_input.json]]:::json
    A[MCP Adapter]:::layer
    AR[[mcp_adapter_request.json]]:::json
    O[MCP Orchestrator]:::layer

    I[Intent Service]:::svc
    II[[intent_service_input.json]]:::json
    IO[[intent_service_output.json]]:::json

    F[Flow Engine]:::svc
    FI[[flow_service_input.json]]:::json
    FO[[flow_service_output.json]]:::json

    subgraph M[Microservice Layer]
        MMenu[Menu]:::svc
        MOrder[Order]:::svc
        MRec[Recommend]:::svc
        MTrack[Tracking]:::svc
        MProf[Profile]:::svc
    end

    U --> C --> CI --> A --> AR --> O
    O --> II --> I --> IO --> O
    O --> FI --> F --> FO --> O

    F --> MMenu --> F
    F --> MOrder --> F
    F --> MRec --> F
    F --> MTrack --> F
    F --> MProf --> F

    O --> A --> C --> U

______________________________________________________________________

MCP JSON信封传输路径

6.为什么MCP v2已准备好投入生产

• 无存根逻辑
• 每个微服务的严格类型I/O
• 规范JSON v2端到端
• 管道中的单个trace_id
• 独立微服务扩展
• 适配器/编排器分离
• 与实际后端（n8n、Make、API、DB、POS）配合使用
• 面向未来的多传输MCP v3

______________________________________________________________________

7.环境变量表

______________________________________________________________________

端点

GET/健康

基本准备状态检查。

POST/编排

所有通道流量的主端点。

______________________________________________________________________

目录结构

app/
 ├── main.py
 ├── flows/
 ├── tools/
 ├── services/
 ├── models/
 ├── logging_loki.py
 └── session_manager.py
README.md
requirements.txt
Procfile

______________________________________________________________________

可观察性和可追溯性

所有日志包括：

• trace_id
• 会话id
• 事件类型
• service_type
• io（输入/输出）
• latency_ms
• 序列化请求/响应有效载荷

在Grafana搜索：

{ trace_id="trace-abc-123" }

______________________________________________________________________

类型化微服务模型

包括：

• 菜单响应
• 订单响应
• 建议响应
• 跟踪响应
• 用户个人资料响应

使用严格的Pydantic模型进行了充分验证。

______________________________________________________________________

路线图

• 第7阶段——错误分类
• 第8阶段——与运输无关的编排
• 第9阶段——多租户路由
• 第10阶段——自动化测试和模拟