Dify 实验 · MCP 集成

Dify MCP 集成实验（06）：企业级交付验收——MCP 集成方案如何验收与交付？

1. 业务场景

先讲一个我们实际遇到的场景。

一家做客服工单 SaaS 的公司，要给客户（企业客服工单 SaaS 数字化负责人）交付一套「AI 智能体 + 企业系统对接」方案：门户对话应用通过 MCP 接入工单状态查询、客户信息查询（受认证保护）。交付的最后一步不是演示跑通，而是正式验收——验收报告要回答客户三个问题：功能对不对、边界在哪、出了问题谁能说清。

我们第一次接这类需求时，第一反应是「功能演示过了，交付就完事了」。真正动手才发现——「跑通了」和「能交付」是两回事：客户要的是正式验收报告，不是口头承诺；工具报错是「显式失败」在技术上正确，客户侧体验却生硬；平台能力边界不写清楚，后续运维全是扯皮。验收的收口，是把这些全部钉成文档。

这不是个例。任何交付项目的最后一公里都是这个模式：交付最后一步不是「跑通了」，而是「验收报告客户看得懂、边界说得清、出了问题有人能排查」——产物即「企业级 AI 智能体系统集成」服务包样板。

2. 场景痛点

这个流程的痛点，在交付收口时体现得最直接：

「跑通了」不等于「能交付」：功能演示过了，但客户要的是正式验收报告，不是口头承诺——没有报告，尾款和口碑都悬。
边界说不清：平台能力问题（消息通道/认证机制/沙箱执行环境/形态级限制）不算缺陷——不声明边界，后续运维全是扯皮。
工具错误体验生硬：MCP 工具 isError → workflow failed（显式非静默）——技术上是「正确行为」，客户侧体验却生硬，投诉跟着来。
交付物不成体系：用例、报告、服务包各说各话——客户没法拿去做决策，下次复购也没依据。

本质上，交付的收口是「验收报告客户看得懂、边界说得清、出了问题有人能排查」——产物即服务包样板。

3. 方案：为什么是 dify-app-acceptance 流程

把 107-01~05 的产物组合成完整 MCP 集成方案，按 dify-app-acceptance 流程做正式验收：用例 Excel 3-Sheet + 报告 Word 7 节（客户语言版）。

选它的理由：

四层用例设计：确定性/内容核对/语义/边界，P1/P2 分级，每工具 happy/error/edge 三态 + 认证失败路径 + 跨工具编排——覆盖完整，不是抽查；
机器断言 + 判定纪律：确定性用例机器断言（node-outputs/Service API 证据链）；语义用例单次异常重跑确认，多次复现才定缺陷——判定有据，不冤枉也不漏网；
交付物成套：用例 Excel 3-Sheet（测试设计说明/用例/测试结果）+ 验收报告 Word 7 节（概述含快照+可复现性声明/设计说明/执行结果/缺陷清单/改进建议/结论/附件）+ 服务包样板（能力清单客户语言版/定价梯度参考/需求边界声明/交付流程）。

这篇文章我们就用它把 107-01~05 的产物组合成完整 MCP 集成方案，做一次正式验收，产出客户语言版报告 + 服务包样板。

4. 整体架构

graph TD s1["dify107_01_time_server（:8901）"] s2["dify107_02_support_server（:8902）"] s3["dify107_04_crm_server（:8904）"] s4["dify107_05_auth_server（:8905，受保护）"] app["Dify 服务器：组合应用 dify107_06_验证应用（workflow）"] st["start（ticket_id, customer_id）"] t1["tool（get_ticket_status@107-02）"] t2["tool（get_customer_info@107-04）"] llm["LLM 汇总（工单状态 + 客户画像）"] en["end"] s1 --> app s2 --> app s3 --> app s4 --> app app --> st st --> t1 st --> t2 t1 -- "并行" --> llm t2 -- "并行" --> llm llm --> en

链路很清晰：四台 MCP server → 组合应用（双 MCP 工具并行）→ LLM 汇总 → end。关键设计是多 server 组合零新坑——provider_id 区分无冲突，结构化工具输出字段直接展开、直连 LLM。

5. 模块设计

5.1 多 MCP server 编排

两个 MCP provider 工具并行调用无冲突（provider_id 区分），结构化工具输出字段直接展开、直连 LLM——复用 107-03 模式，多 server 组合零新坑。

- data:

    provider_id: dify107_02_support_server

    provider_type: mcp

    tool_name: get_ticket_status

    tool_parameters:

      ticket_id: {type: mixed, value: '{{#start.ticket_id#}}'}

    type: tool

- data:

    provider_id: dify107_04_crm_server

    provider_type: mcp

    tool_name: get_customer_info

    tool_parameters:

      customer_id: {type: mixed, value: '{{#start.customer_id#}}'}

    type: tool

5.2 验收交付（dify-app-acceptance 流程）

用例设计：四层（确定性/内容核对/语义/边界），P1/P2 分级，每工具 happy/error/edge 三态 + 认证失败路径 + 跨工具编排 → Excel 3-Sheet（测试设计说明/用例/测试结果）
验收执行：确定性用例机器断言（node-outputs/Service API 证据链）；语义用例判定纪律——单次异常重跑确认，多次复现才定缺陷
报告：Word 7 节（概述含快照+可复现性声明/设计说明/执行结果/缺陷清单/改进建议/结论/附件），客户语言版（如「MCP 工具集」→「系统行为覆盖维度」）
服务包样板：能力清单客户语言版 + 定价梯度参考 + 需求边界声明 + 交付流程

5.3 服务包能力清单（对外交付素材，客户语言版）

能力项	内容
MCP Server 开发	外部系统契约封装为 MCP server（工具/资源/提示词）
Dify 工作流集成	多 MCP server 编排进客服门户，输出字段展开直连 LLM
企业系统对接	CRM/ERP/OA 通过 MCP 接入（选型：MCP vs 插件）
企业级认证	OAuth 2.1 + PKCE / client_credentials / header 三模式
测试验证报告	用例 Excel 3-Sheet + 验收报告 Word 7 节

6. 运行验证

场景	预期	结果
T1002+CUS-001（双正常）	工单 open + VIP 客户画像完整	通过
T9999+CUS-001（工单不存在）	明确「未找到该工单」+ 客户画像正常（不编造）	通过
T1003+CUS-002（pending+normal）	状态 + 等级 + 联系方式准确	通过
T1001+CUS-999（客户不存在）	workflow failed（工具 not_found 显式失败）	通过（显式失败，改进建议①）
空输入	参数校验拦截（显式失败）	通过（显式失败）
abc+abc（格式错）	param_invalid 显式失败	通过（显式失败）

验收结论：10 用例 10 PASS（3 条错误路径为设计行为）；P1/P2 缺陷 0；改进建议 3 条（优雅降级/工具列表刷新/资源读取封装）；结论=功能验收通过，补优雅降级后投入生产。

7. 实战坑

坑	现象	修复
工具错误无优雅降级	MCP 工具 isError → workflow failed（显式非静默），客户侧体验生硬	产品化时工具节点后加错误分支（按错误信息匹配 not_found/param_invalid）输出友好提示（实测）
多 server 编排	两个 MCP provider 工具并行调用	provider_id 区分无冲突，展开字段直连 LLM（实测）
空输入	工具参数必填校验拦截	显式失败非静默，验收用例按设计行为记录（实测）
认证模式混用	组合应用用 header 鉴权，OAuth 未纳入	107-05 已单独验证 OAuth；如需演示，把 107-05 server 配 headers 后接入即可（实测）

8. 实验文档及源码获取

实验文档（完整操作步骤）：DIFY-107-06：企业级交付验收.md
源码（可直接导入）：dify107_06_验证应用.yml
交付验证记录（组合应用冒烟 + 验收结论）：验证记录-06-企业级交付验收.md
服务包样板（对外交付素材）：服务包样板.md
全部目录：dify-107/experiments | dify-107/dsl | dify-107/servers | dify-107/delivery

文章聚焦核心配置与采坑点；实验的完整分步操作（节点搭建/参数表/调试指引）见实验文档原文。

系列完结

至此，《Dify 实验系列》六批次全部完结：中级（21 实验，核心能力）、高级（10 实验，综合场景）、企业级（12 实验，业务系统）、韧性验证（8 实验，故障与降级）、插件开发（12 实验，扩展平台）、MCP 集成（6 实验，对接生态）。

从「用 Dify」到「接生态」：104 回答「Dify 能不能做」，105 回答「能不能验」，106 回答「Dify 没有的能不能自己造」，107 回答「Dify 外面的（9400+ MCP server 生态）能不能接进来」。本篇为该系列终篇——MCP 集成方案的验收与交付，正好是交付的最后一公里：功能对不对、边界在哪、出了问题谁能说清，验收报告替客户把这三件事钉死。

本系列 · Dify 实验 · MCP 集成