Dify MCP 集成实验06企业级交付验收——MCP 集成方案如何验收与交付Dify 实验系列 · MCP 集成 06/6 | 实验编号DIFY-107-06基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家做客服工单 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. 整体架构并行并行dify107_01_time_server:8901dify107_02_support_server:8902dify107_04_crm_server:8904dify107_05_auth_server:8905受保护Dify 服务器组合应用 dify107_06_验证应用workflowstartticket_id, customer_idtoolget_ticket_status107-02toolget_customer_info107-04LLM 汇总工单状态 客户画像end链路很清晰四台 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_serverprovider_type:mcptool_name:get_ticket_statustool_parameters:ticket_id:{type:mixed,value:{{#start.ticket_id#}}}type:tool-data:provider_id:dify107_04_crm_serverprovider_type:mcptool_name:get_customer_infotool_parameters:customer_id:{type:mixed,value:{{#start.customer_id#}}}type:tool5.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. 运行验证场景预期结果T1002CUS-001双正常工单 open VIP 客户画像完整通过T9999CUS-001工单不存在明确「未找到该工单」 客户画像正常不编造通过T1003CUS-002pendingnormal状态 等级 联系方式准确通过T1001CUS-999客户不存在workflow failed工具 not_found 显式失败通过显式失败改进建议①空输入参数校验拦截显式失败通过显式失败abcabc格式错param_invalid 显式失败通过显式失败验收结论10 用例 10 PASS3 条错误路径为设计行为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 集成全部完结从用 Dify 到接生态 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。