doc_id: DES-202606-002 feature_id: FEAT-202606-002-fastgpt-integration type: design title: 医梦与深信服 FastGPT 商业谈判与技术合作边界方案 status: draft owner: 医梦研发团队 created_at: 2026-06-20 updated_at: 2026-06-20 reviewers: [] related_docs:

DDS-202606-002
ODS-202606-001
STD-202605-001
STD-202605-002 related_modules:
emoon-openplatform
emoon-ai-agent
emoon-ai-card
emoon-ai-mcp
emoon-ai-file
emoon-ai-meter
emoon-ai-billing
emoon-ai-contract tags:
FastGPT
深信服
商业谈判
技术边界
医疗智能体
Medical Control Plane
MCP Gateway
Card Runtime
知识库源资产
医生反馈
商业闭环 source:
/Users/destiny/.codex/attachments/711d76a5-87d2-4cd0-834c-24251a0c78/pasted-text.txt
/Users/destiny/.codex/attachments/ea4e7e4b-e103-4b11-9ad7-20c1c72f73/pasted-text.txt ---

医梦与深信服 FastGPT 商业谈判与技术合作边界方案

0. 文档定位

本文以两份附件为主体，作为医梦与深信服 FastGPT 团队沟通时的商业谈判底稿和技术边界说明稿。文档目标不是论证“医梦平台和 FastGPT 谁替代谁”，而是把双方合作模式、医梦不可替代价值、技术团队边界、数据与商业底线、会议话术和 PoC 落地路径说清楚。

本文结合项目既有文档做了少量校准：

FastGPT 在医梦体系中应作为 AgentEngine 的实现层之一，而不是替代医梦 AI 中台。
医梦已有工程约束要求 OpenPlatform、Agent、Card、MCP、File、Meter、Billing、Contract 分层承接医疗业务闭环。
统一入口客户端、Card Runtime、MCP Gateway、知识库源资产、医生反馈和计量账本是医梦必须掌握的核心边界。
深信服平台能力清单需要按实际 FastGPT 版本、商业版能力、私有化部署条件逐项确认，不能在谈判中无条件默认全部可用。

1. 谈判总判断

这次沟通不能进入“医梦中台和 FastGPT 谁更强”的防御式讨论。正确开场是：

我们认可 FastGPT 在智能体构建、Workflow、RAG、模型接入、MCP / Tool 调用、私有化部署、算力和平台安全上的价值。
医梦不打算重复建设一个通用智能体平台。

但医疗项目不是把一个通用智能体平台交给医院就能落地。
医院需要的是能进入真实业务系统、能被医生确认、能被患者理解、能留痕审计、能持续运营、能被甲方验收的医疗智能体闭环。

所以双方最合理的合作模式是：
深信服提供 AI 能力底座，医梦提供医疗智能体应用控制层。

一句话压缩：

FastGPT 解决 AI 能力运行。
医梦解决医疗业务闭环。

更技术化的表达：

深信服负责 Agent Runtime。
医梦负责 Medical Control Plane。

更商业化的表达：

没有 FastGPT，医梦交付成本高。
没有医梦，FastGPT 在医疗行业容易停留在 Demo。

2. 一句话总口径

建议双方采用：

深信服提供 FastGPT、模型、算力、RAG、Workflow、OCR、私有化部署等 AI 底座能力；医梦提供医疗智能体控制层，统一承接用户入口、医院系统接口、医疗业务状态、卡片交互、医生反馈、知识库源资产和场景运营。

更直接地说：

FastGPT 只与医梦医疗智能体控制层对接，不直接连接医院业务系统和用户端。

这不是为了人为加一层，而是因为医疗项目有强业务边界、强审计、强责任、强数据安全要求。深信服负责 AI 能力执行，医梦负责医疗业务闭环。

3. 合作系统定位

3.1 深信服定位

深信服在合作中定位为 AI 能力底座与基础设施提供方。

能力	说明	谈判确认点
FastGPT 平台	智能体构建、Workflow、工具调用、知识库运行	确认社区版、商业版、私有化版能力差异
大模型服务	LLM 调用、模型接入、推理服务	确认模型清单、并发、私有化和计费
多模态能力	OCR、PDF / 图片解析、视觉模型等	确认可用范围，不默认全部可用
RAG 能力	向量化、检索、知识库运行副本	确认版本、回滚、日志和导出能力
Workflow 能力	工作流画布、节点编排、AI 子流程执行	确认版本、发布、灰度和可观测性
Tool / MCP 能力	HTTP Tool、MCP Client、工具调用节点	确认鉴权、Schema、白名单、日志和超时
算力与 GPU	推理资源、GPU、超融合、资源调度	确认项目部署和运维边界
私有化部署	院内或政务环境部署、安全运维	确认网络、数据、日志、运维责任
平台日志	FastGPT 调用日志、模型消耗、资源监控	可用于成本核算，不能直接替代医梦计量账本

深信服解决的是：

AI 能力如何运行、如何部署、如何支撑大规模平台化调用。

3.2 医梦定位

医梦在合作中定位为医疗智能体应用控制层与医疗业务闭环提供方。

能力	说明	医梦必须掌握的原因
统一入口客户端	小程序、Web、医生端、设备端、统一卡片展示	掌握用户入口和项目品牌露出
医疗场景路由	判断报告解读、慢病任务、挂号、导诊、随访等场景	医疗主流程不能交给通用平台猜测
医疗任务状态机	管理挂号、报告解读、慢病任务等业务流程状态	医疗任务不是一次问答，而是强状态业务
医梦 MCP Gateway	封装 HIS、LIS、EMR、慢病、物联、支付、叫号等接口	医院系统差异和安全责任必须由医梦治理
Card Runtime	医疗卡片、医生确认、患者确认、幂等、过期、状态流转	医疗关键动作不能直接由模型输出触发
医生反馈闭环	采纳率、修正文案、错误类型、知识库优化	医生反馈是医疗智能体持续进化的数据资产
知识库源资产	血常规、慢病、中医、报告解读等源文件和版本	医学结构、审核流程、复用权必须沉淀在医梦
医疗安全规则	禁止自动诊断、禁止自动处方、高风险转人工	医疗责任边界不能由通用模型直接承担
场景运营与计量	能力值、场景包、项目实施、综合运营服务费	支撑医梦商业闭环，而不只是 token 成本
多平台适配	FastGPT Adapter、Dify Adapter、自研 AgentEngine Adapter	保持医梦平台可替换、可演进，不被单一底座锁死

医梦解决的是：

医疗智能体如何真正进入医院业务系统、
如何让医生和患者安全使用、
如何形成可审计、可运营、可收费的医疗闭环。

4. 推荐架构与不建议架构

4.1 推荐架构：FastGPT 在医梦后方

患者端 / 医生端 / 龙岗加一 / 医院门户 / 自助机 / 机器人 / 导诊屏
        ↓
医梦统一入口客户端 / 医梦 OpenAPI
        ↓
医梦医疗智能体应用控制层
        ├── 医梦 MCP Gateway → HIS / LIS / EMR / 慢病 / 物联 / 支付 / 叫号
        ├── Card Runtime → 医生端卡片 / 患者端卡片 / 任务卡片
        ├── 医生反馈中心 → 知识库源资产 / Prompt / 模板迭代
        ├── 场景运营与能力值计量
        └── FastGPT Adapter → 深信服 FastGPT API
                                      ↓
                              LLM / OCR / RAG / Workflow / GPU / 超融合

核心原则：

外部入口只接医梦。
医院系统只接医梦。
FastGPT 只接医梦。

4.2 不建议架构：FastGPT 直接接医疗业务

用户端 / 医生端 / 医院系统
        ↓
FastGPT
        ↓
医梦参与配置、Prompt、知识库或实施

这种模式短期看简单，但长期会导致：

医梦失去统一入口控制权。
医梦无法控制医院接口权限。
医梦无法掌握医生反馈闭环。
医梦知识库和模板沉淀到深信服平台。
客户只认深信服，不认医梦。
医梦变成 FastGPT 背后的医疗实施团队。
后续复制项目时医梦容易被替代。

5. 医疗项目为什么不能只靠 FastGPT

5.1 通用 Agent 平台解决 AI 能力，医院项目需要业务闭环

FastGPT 擅长的链路是：

用户输入
→ 意图理解
→ 调用知识库 / 工具 / 模型
→ 生成回答

医院真实业务链路是：

用户身份识别
→ 场景判断
→ 权限校验
→ 医院系统取数
→ 数据脱敏与最小化
→ AI 生成建议
→ 医疗安全校验
→ 医生端 / 患者端差异化输出
→ 卡片确认
→ 医生反馈
→ 业务系统写入
→ 审计留痕
→ 运营计量
→ 知识库迭代

谈判口径：

FastGPT 可以很好地完成 AI 子流程，但医疗主流程需要医梦控制层承接。我们不是要削弱 FastGPT，而是要让 FastGPT 的能力真正进入医疗业务闭环。

5.2 医疗场景不是问答系统，而是强状态任务系统

以挂号为例，表面是一句话：

我想挂明天上午神经内科李一鸣医生的号。

真实流程包含：

科室识别
→ 医生识别
→ 日期时段识别
→ 医生与科室关系校验
→ 号源查询
→ 患者身份确认
→ 号源锁定
→ 支付确认
→ 挂号订单创建
→ 成功通知
→ 审计留痕

以报告解读为例，表面是：

帮我解读血常规报告。

真实流程包含：

报告索引
→ 报告获取
→ OCR / 结构化解析
→ 指标标准化
→ 参考区间校验
→ 异常指标识别
→ 异常组合判断
→ 医生端专业摘要
→ 患者端通俗表达
→ 医生反馈
→ 知识库迭代

谈判口径：

医疗智能体不是一个聊天机器人，而是一套可控的任务系统。FastGPT 可以做生成和编排，但任务状态、卡片确认、业务写操作、医生反馈和责任边界必须在医梦医疗控制层。

6. 医梦不可替代的八大价值

价值一：医梦把 FastGPT 从通用 Agent 平台变成医疗可交付系统

深信服已有能力：

Agent Builder；
Workflow；
RAG；
模型调用；
OCR / 多模态；
Tool / API 调用；
私有化部署；
安全和算力底座。

医梦补齐能力：

医疗场景定义；
医疗任务状态机；
医院业务接口语义；
医生端 / 患者端输出差异；
医疗卡片确认；
医生反馈闭环；
医疗安全规则；
场景验收标准；
持续运营和商业计量。

谈判口径：

FastGPT 是很强的平台，但医疗客户最终验收的不是“平台能不能搭 Agent”，而是“报告解读是否准确、医生是否愿意用、患者是否看得懂、业务系统是否能打通、风险是否可控”。

医梦的价值就是把 FastGPT 的平台能力转化成医院能上线、能验收、能复用的医疗场景包。

价值二：医梦掌握医疗业务接口语义，避免 FastGPT 陷入医院系统细节

医疗系统不是普通 API。HIS、LIS、EMR、慢病平台、物联平台，每个系统都涉及医疗业务含义。

例如 report.getReportDetail 不是简单“查报告”，还要判断：

报告是否最终审核；
报告是否作废；
是否允许患者查看；
是否允许医生查看；
参考区间来自哪里；
指标单位是否一致；
是否存在危急值；
是否需要隐藏敏感信息；
是否可以进入 AI 解读。

再如 his.lockRegistrationSlot 不是简单“调接口锁号”，还涉及：

患者身份是否确认；
号源是否仍有效；
是否重复锁号；
锁号超时释放；
支付状态；
挂号失败补偿；
审计责任。

医梦通过 MCP Gateway / Tool Proxy 把医院系统封装成标准医疗工具：

HIS 工具集
LIS / 报告工具集
EMR 工具集
慢病平台工具集
物联平台工具集
支付 / 挂号 / 叫号工具集

对深信服的价值：

深信服不需要陷入每家医院 HIS、LIS、EMR 的业务细节。医梦把这些复杂接口封装成标准医疗工具 API，FastGPT 只需要调用医梦提供的受控工具。

这不是增加复杂度，而是帮 FastGPT 保持平台通用性，同时降低医疗项目交付风险。

价值三：医梦负责医疗安全边界，避免模型输出直接形成风险

医疗 AI 输出不能只追求自然、完整、流畅，还必须满足：

不直接诊断；
不直接开药；
不替代医生；
不制造患者恐慌；
不给出越权建议；
高风险场景提示就医；
危急值场景转人工或医生处理；
所有关键建议可追溯。

患者端报告解读不建议输出：

你可能是细菌感染，建议吃抗生素。

建议输出：

白细胞偏高可能与感染、炎症或身体应激有关，需要结合症状和其他检查判断。是否需要用药应由医生决定。

医梦补齐能力：

患者端禁止表达库；
医生端专业表达模板；
风险等级规则；
高风险转人工规则；
医生确认点；
患者端免责声明；
医疗安全后处理；
输出 Schema 校验。

谈判口径：

FastGPT 可以生成内容，但医疗项目最终不能把模型原始输出直接给医生或患者。医梦控制层会做医疗安全校验、风险分层、患者端语言转换和卡片封装，保证输出能被医院安全使用。

价值四：医梦拥有医疗知识库工程能力，而不是简单上传文档

FastGPT 可以承载知识库运行副本，但医疗知识库不是文档堆叠。

以血常规为例，知识库至少应拆成：

指标解释库
异常组合库
风险分层库
趋势分析库
患者端语言转换库
医生端摘要模板库
禁止表达库
医生反馈优化池

以慢病管理为例，知识库至少应拆成：

高血压任务规则
糖尿病任务规则
饮食处方规则
运动处方规则
用药提醒规则
复诊随访规则
危险信号规则
医生审核规则
患者端通俗表达规则

双方分工：

内容	主责
知识库源文件	医梦
医学规则结构	医梦
医学审核流程	医梦
患者端表达规范	医梦
医生反馈驱动迭代	医梦
知识库向量化	深信服
RAG 检索	深信服
知识库运行副本	深信服
检索日志	深信服

谈判口径：

FastGPT 做知识库运行平台，医梦做医疗知识库源资产。

医梦负责知识怎么拆、怎么写、怎么审核、怎么版本化、怎么根据医生反馈迭代；深信服负责向量化、检索和运行能力。

这样 FastGPT 的 RAG 能力才能在医疗场景中有质量，而不是简单上传几份指南。

价值五：医梦设计医生反馈闭环，让智能体越用越准

通用平台的反馈通常是：

点赞 / 点踩 / 日志 / token / 调用量

医疗智能体需要的反馈是：

医生是否采纳？
医生改了哪里？
哪个指标解释不准确？
是否漏掉关键异常？
患者端表达是否不合适？
是否存在医疗风险？
哪条知识库需要修订？
哪个 Prompt 需要调整？
哪个 Workflow 节点不合理？

医梦反馈 Schema 示例：

字段	说明
`feedbackType`	准确 / 部分准确 / 不准确 / 存在风险
`score`	1-5 分
`target`	指标 / 文本段落 / 建议 / 风险等级
`issueType`	漏掉重点 / 解释错误 / 过度诊断 / 患者端不适合
`correctedText`	医生修正文案
`adopted`	是否采纳 AI 输出
`knowledgeEntryId`	关联知识条目
`workflowVersion`	关联流程版本
`modelVersion`	关联模型版本

对深信服的价值：

优化知识库；
优化 Prompt；
优化 Workflow；
优化检索策略；
形成医疗场景 Benchmark；
支撑后续专病模型训练。

谈判口径：

医生反馈不是普通日志，而是医疗智能体持续进化的数据资产。医梦负责把医生反馈结构化，再把优化后的知识库、Prompt 和 Workflow 反馈给 FastGPT 运行。

这样 FastGPT 在医疗行业不是一次性交付，而是可以持续变好。

价值六：医梦用 Card Runtime 承接医疗关键动作，避免 AI 越权

医疗场景不能只靠聊天输出。

挂号、支付、报告解读、慢病任务、医生审核、随访计划，都需要可确认、可审计、可回滚的卡片。

医疗卡片示例：

报告异常摘要卡
患者通俗解读卡
医生反馈卡
慢病任务草案卡
医生审核卡
挂号医生选择卡
排班号源卡
支付确认卡
随访风险提醒卡

Card Runtime 要解决：

卡片状态；
卡片动作；
幂等；
过期；
审计；
用户确认；
医生确认；
与医院系统写操作绑定；
与能力值计量绑定。

项目工程约束补充：Card Runtime 负责卡片实例、动作状态、确认和审计；具体业务写操作应进入医梦应用服务或 AgentActionOrchestrator，再由受控服务调用 MCP Gateway，避免卡片运行时直接绕过业务编排。

谈判口径：

FastGPT 可以生成结构化建议，但医疗关键动作必须通过医梦 Card Runtime 承接。

例如 AI 可以生成慢病任务草案，但不能直接下发给居民；必须形成医生审核卡，医生确认后才能调用慢病系统发布任务。

价值七：医梦把平台能力包装成甲方可采购、可验收的医疗场景包

深信服卖平台，甲方可能觉得大而全，但不知道怎么落地。医梦把能力变成具体场景包：

报告解读智能体场景包
慢病任务生成场景包
挂号智能体场景包
导诊分诊场景包
随访智能体场景包
中医四诊场景包
病历质控场景包

每个场景包包含：

业务流程；
MCP 工具清单；
知识库结构；
Prompt 模板；
Card Schema；
医生反馈 Schema；
风险规则；
测试用例；
验收指标；
运营指标。

报告解读验收指标示例：

结构化解析成功率
异常指标识别准确率
医生端采纳率
患者端理解度
严重错误率
响应时间
医生反馈闭环可用率
知识库版本追溯能力

谈判口径：

医院不会单独验收“有没有 Workflow、有没有 RAG”。医院验收的是场景结果。医梦负责把 FastGPT 的平台能力转成可采购、可试点、可验收、可复制的医疗智能体场景包。

价值八：医梦补齐医疗商业化计量，而不只是 Token 成本统计

FastGPT 能统计：

token；
Workflow 调用；
模型调用；
RAG 检索；
工具调用；
GPU 消耗。

但医疗商业化需要统计：

按医院；
按科室；
按医生；
按患者端 / 医生端；
按报告类型；
按智能体；
按设备；
按场景；
按医生采纳率；
按慢病任务生成量；
按服务包转化量；
按质量评分；
按能力值。

谈判口径：

FastGPT 的 usage 统计解决 AI 成本核算，医梦的场景计量解决医疗商业闭环。

如果没有医梦的场景计量，项目后续只能按平台资源或人天收费，很难形成报告解读包、慢病任务包、知识库运营费、综合运营服务费等商业模式。

7. 双方技术边界

7.1 总分工表

层级	产品 / 能力	主责	边界说明
用户入口层	统一入口客户端	医梦	小程序、Web、医生端、设备端
医疗业务控制层	权限、路由、状态机、Card、反馈、计量	医梦	医梦医疗智能体控制层
智能体构建平台	FastGPT Agent Builder	深信服	平台能力、管理端、运行环境
医疗智能体模板	报告解读、慢病、挂号、导诊模板	医梦	医疗流程、Prompt、验收用例
Workflow 引擎	FastGPT Workflow	深信服	工作流画布、节点运行
医疗 Workflow 设计	医疗业务流程设计包	医梦	医生确认点、风险规则
MCP / Tool 平台能力	FastGPT Tool Runtime / Client	深信服	平台侧工具调用能力
医疗工具网关	医梦 MCP Gateway / Tool Proxy	医梦	封装 HIS、LIS、EMR、慢病、物联
知识库平台	FastGPT Knowledge / RAG	深信服	向量化、检索、运行副本
医疗知识库源资产	血常规、慢病、中医等源文件	医梦	知识结构、医学规则、版本主控
AI 能力	LLM、OCR、Embedding、Rerank	深信服	AI 能力底座
基础设施	GPU、超融合、负载均衡、安全运维	深信服	底层资源
反馈闭环	医生反馈中心	医梦	采纳率、修正、知识库优化
商业计量	能力值、场景计量、质量看板	医梦	商业闭环

7.2 Workflow 边界

Workflow 拆成两层。

深信服负责 Workflow 引擎：

Workflow 画布；
节点运行；
RAG 节点；
LLM 节点；
OCR 节点；
工具调用节点；
运行日志；
版本发布。

医梦负责医疗 Workflow 设计：

报告解读流程；
慢病任务生成流程；
挂号槽位补全流程；
分诊问诊流程；
医生确认点；
患者确认点；
高风险转人工点；
卡片输出结构；
医疗安全规则；
验收用例。

谈判口径：

Workflow 引擎用你们的，医疗 Workflow 的业务设计、模板和验收标准由医梦提供。

7.3 MCP / Tool 边界

如果 FastGPT 支持 MCP / Tool Runtime，可以使用 FastGPT 的工具调用能力，但工具背后只能调用医梦 API：

FastGPT Workflow
  ↓
FastGPT Tool Runtime
  ↓
医梦受控工具 API
  ↓
医梦 MCP Gateway
  ↓
医院业务系统

如果 FastGPT 不支持 MCP Server 构建，由医梦提供 MCP Server / Tool Server，FastGPT 作为 MCP Client 或 HTTP Client 调用：

FastGPT Workflow
  ↓
MCP Client / HTTP Client
  ↓
医梦 MCP Server
  ↓
医梦 MCP Gateway
  ↓
医院业务系统

无论哪种方式，底线一致：

医院业务接口由医梦封装。
FastGPT 不直接连接医院系统。
FastGPT 不保存医院接口账号、密钥和写权限。

7.4 知识库边界

医梦负责知识库源资产：

血常规指标解释库；
异常组合库；
风险分层库；
患者端语言转换库；
医生端摘要模板库；
高血压任务知识库；
糖尿病任务知识库；
中医四诊知识库；
禁止表达库；
医生反馈优化池。

深信服负责知识库运行副本：

向量化；
切片；
RAG 检索；
召回；
Embedding；
Rerank；
检索日志。

正确流程：

医梦维护知识库源文件
  ↓
医学审核
  ↓
发布知识库版本
  ↓
同步运行副本到 FastGPT
  ↓
FastGPT RAG 检索
  ↓
医生反馈回医梦
  ↓
医梦修订源文件
  ↓
再次发布运行副本

谈判口径：

FastGPT 可以承载知识库运行副本，但知识库源文件、医学结构、版本主控和医生反馈迭代必须在医梦。

8. 医梦必须守住的底线

8.1 技术底线

FastGPT 只与医梦控制层对接。
医院系统只接医梦 MCP Gateway。
用户入口只接医梦统一入口。
医梦负责医疗业务状态。
FastGPT 负责 AI 子流程执行。
FastGPT 不直接执行医疗写操作。
医梦掌握医生反馈闭环。
医梦保留知识库源资产和模板复用权。

最关键的一句话：

FastGPT 可以帮我们跑智能体，但不能绕过医梦直接接业务系统。

8.2 数据底线

医梦负责对医院数据做最小化和脱敏。
FastGPT 只接收必要上下文。
FastGPT 不保存医院接口密钥。
FastGPT 不直接访问医院系统。
医生反馈原始数据回医梦。
真实患者数据归客户所有。
医梦有脱敏质量分析权。
深信服有平台运行日志和模型调用日志，但日志内容、留存和脱敏规则需项目确认。

8.3 商业底线

深信服负责 AI 底座。
医梦负责医疗场景能力。
医梦不是深信服隐形外包。
对外方案应体现医梦角色。
医梦医疗模板和知识库结构可复用。
深信服复制医梦医疗模板到其他项目，应有授权或分成。
医梦收入不应只按人天，应包括智能体设计费、场景实施费、知识库建设费、运营服务费和场景包授权费。

8.4 可让步范围

为促成合作，医梦可以让步：

通用智能体构建平台使用 FastGPT。
Workflow 引擎和运行时使用 FastGPT。
RAG 运行副本部署在 FastGPT。
模型、OCR、Embedding、Rerank、GPU 和私有化环境优先采用深信服能力。
PoC 阶段可先选择一个场景做最小链路，不要求一次性覆盖所有医疗闭环。

但不能让步：

用户入口不能绕过医梦。
医院系统接口不能绕过医梦。
医疗写操作不能由 FastGPT 直接执行。
知识库源资产、医疗模板、医生反馈和场景计量不能完全沉淀在深信服平台。
医梦不能在联合方案中退化为实施外包或 Prompt 配置团队。

9. 关键业务流程示例

9.1 报告解读流程

1. 医生或患者从小程序 / Web / 医生端进入报告解读
2. 请求进入医梦统一入口
3. 医梦识别场景：报告解读
4. 医梦校验身份、权限、端类型
5. 医梦 MCP Gateway 查询 LIS / 报告系统
6. 医梦获取结构化报告或 PDF / 图片
7. 医梦进行数据裁剪、脱敏、上下文构造
8. 医梦 FastGPT Adapter 调用 FastGPT
9. FastGPT 执行 OCR / RAG / LLM 解读
10. FastGPT 返回结构化结果
11. 医梦做医疗安全校验、风险分层
12. 医梦 Card Runtime 生成医生端 / 患者端卡片
13. 医生提交反馈
14. 反馈进入医梦反馈中心
15. 医梦更新知识库源文件和模板

关键边界：

FastGPT 不查报告。
FastGPT 不直连 LIS。
FastGPT 不直接面向患者输出。
FastGPT 不保存报告业务主状态。

9.2 慢病任务生成流程

1. 医生进入慢病患者详情
2. 请求进入医梦统一入口
3. 医梦识别场景：慢病任务生成
4. 医梦 MCP Gateway 查询慢病档案、用药、血压血糖、物联数据
5. 医梦构造患者专科视图
6. 医梦裁剪、脱敏、构造任务上下文
7. 医梦调用 FastGPT
8. FastGPT 基于慢病知识库运行副本生成任务草案
9. 医梦封装为医生审核卡
10. 医生确认、修改或驳回
11. 医梦记录医生反馈
12. 医生确认后，医梦 MCP Gateway 调用慢病系统发布任务
13. 居民端收到健康任务

关键边界：

FastGPT 不查慢病原始系统。
FastGPT 不直接发布任务。
FastGPT 不直接面向居民下发健康计划。
慢病任务必须医生确认。

9.3 挂号智能体流程

1. 患者提出挂号需求
2. 医梦控制层识别挂号意图
3. 医梦任务状态机抽取科室、医生、日期、时段、患者身份
4. 医梦 MCP Gateway 查询 HIS 排班和号源
5. 如需自然语言理解或推荐，医梦调用 FastGPT
6. FastGPT 返回推荐说明或追问话术
7. 医梦展示科室卡、医生卡、排班卡、确认卡
8. 患者确认
9. 医梦 MCP Gateway 调用 HIS 锁号 / 创建订单
10. 返回挂号成功卡

关键边界：

FastGPT 不锁号。
FastGPT 不创建挂号订单。
FastGPT 不发起支付。
FastGPT 不直接调用 HIS。

10. 下周需要和深信服确认的技术问题

10.1 FastGPT 平台能力确认

问题	需要确认的具体点
FastGPT 是否支持外部 API 调用	REST API、Header、Token、签名
是否支持 MCP Client	能否调用外部 MCP Server
是否支持 MCP Server 构建	能否在平台内创建 MCP / Tool Server
是否支持 Tool 入参 Schema	JSON Schema、必填字段、枚举
是否支持 Tool 出参 Schema	返回结构能否用于后续 Workflow 节点
是否支持工具调用日志	参数、结果、耗时、错误是否可追踪
是否支持工具白名单	不同智能体是否限制不同工具
是否支持动态鉴权	Header Token、AK/SK、签名
是否支持流式输出	SSE / WebSocket / Streaming
是否支持结构化输出	JSON 输出、Schema 校验
是否支持知识库版本	知识库发布、回滚、版本号
是否支持 Workflow 版本	Workflow 发布、回滚、灰度
是否支持调用统计	Token、模型、Workflow、工具消耗
是否支持私有化部署	医院内网、政务云、专属资源
是否支持日志导出	便于医梦做运营和计量归因

10.2 必测 Demo：报告解读最小链路

用户：帮我解读最近一次血常规报告
  ↓
FastGPT Workflow 识别为报告解读
  ↓
调用医梦工具 API：report.searchReports
  ↓
调用医梦工具 API：report.getReportDetail
  ↓
FastGPT 基于返回内容生成解读
  ↓
返回结构化 JSON
  ↓
医梦封装为报告解读卡片

至少验证：

FastGPT 能不能调外部 API。
能不能传入 patientId、reportType。
能不能接收结构化返回。
能不能继续进入后续节点。
能不能输出稳定 JSON。
调用日志是否完整。
错误时能不能降级。
能不能带 traceId。

11. 合作落地分阶段建议

11.1 第一阶段：接口与能力验证

目标：

验证 FastGPT 是否能作为医梦后方 AI 能力层。

工作内容：

确认 FastGPT API 调用方式。
确认 Tool / MCP 能力。
确认 Workflow 输入输出格式。
确认 RAG 知识库接入方式。
确认 OCR / 多模态调用方式。
确认调用日志和 usage。
打通 report.searchReports 最小工具。

交付物：

FastGPT 能力验证清单；
医梦 FastGPT Adapter 初版；
报告解读最小 Demo；
问题清单。

11.2 第二阶段：报告解读 PoC

目标：

验证“医梦取数、FastGPT 生成、医梦封装、医生反馈回医梦”的完整闭环。

交付物：

血常规报告解读智能体；
医生端报告摘要卡；
患者端通俗解读卡；
医生反馈卡；
知识库 v1；
PoC 评估报告。

11.3 第三阶段：慢病任务生成 PoC

目标：

验证 AI 生成任务草案、医生审核、居民执行、数据回流的医疗闭环。

交付物：

高血压任务生成模板；
糖尿病任务生成模板；
医生审核卡；
慢病知识库源文件；
任务采纳率报告。

11.4 第四阶段：统一入口多智能体

目标：

把报告解读、慢病任务、挂号、导诊、随访等场景统一进入医梦入口和 FastGPT 能力底座。

交付物：

统一入口多智能体方案；
场景包清单；
工具 API 清单；
联合解决方案 PPT；
商务边界和授权清单。

12. 会议现场讲解口径

12.1 开场 1 分钟

我们这次想先把双方边界讲清楚。
医梦不打算和 FastGPT 做重复平台竞争，我们认可 FastGPT 在智能体构建、Workflow、RAG、模型、工具调用、算力和私有化部署上的能力。

但医疗项目落地有一个特点：
医院不是买一个通用智能体平台，而是要买能接业务系统、能被医生确认、能被患者理解、能审计、能验收、能持续运营的医疗业务闭环。

所以我们建议双方采用“FastGPT AI 能力底座 + 医梦医疗智能体控制层”的合作模式。
FastGPT 负责 AI 子任务执行，医梦负责医疗主流程闭环。

12.2 讲医梦价值 2 分钟

医梦的价值主要不在于再造一个通用 Agent 平台，而在于医疗行业的最后一公里。

这个最后一公里包括：
医疗工具语义、医院系统接口封装、数据最小化、医生端和患者端输出差异、医疗安全规则、卡片确认、医生反馈闭环、知识库源资产、场景验收标准和能力值计量。

这些能力可以让 FastGPT 从一个通用智能体平台，变成医院真正能上线、能验收、能复制的医疗智能体解决方案。

12.3 讲双方分工 2 分钟

深信服可以主导 FastGPT 平台、模型、RAG、Workflow、OCR、Embedding、GPU、超融合、安全和私有化部署。

医梦主导统一入口、医疗任务状态机、MCP 医疗工具网关、Card Runtime、医生反馈中心、医疗知识库源资产、医疗安全规则和场景运营计量。

我们建议 FastGPT 只和医梦控制层对接，不直接连接医院系统和用户端。
这样深信服保持平台通用性，医梦承担医疗行业复杂度，双方边界最清晰。

12.4 讲为什么不是给 FastGPT 增加负担

这个架构不是给 FastGPT 增加负担，而是帮 FastGPT 降低医疗行业交付风险。

如果 FastGPT 直接接医院系统，就要面对 HIS、LIS、EMR、慢病、物联、支付、叫号等复杂接口，还要处理医生确认、患者表达、写操作安全和医疗审计。

医梦在前面做医疗控制层，把这些复杂度封装成标准工具和场景包。
FastGPT 只处理标准化后的 AI 子任务，这样平台能力反而更容易复制。

13. 应对深信服可能的追问

问题 1：FastGPT 也能接 API，为什么还需要医梦 MCP Gateway？

回答：

FastGPT 能接 API，但医疗 API 不是普通接口。
医疗接口涉及患者权限、数据脱敏、医生确认、写操作幂等、审计留痕、不同医院厂商差异。

医梦 MCP Gateway 不是简单转发，而是医疗工具语义层和安全控制层。
FastGPT 调用医梦封装后的工具，可以避免平台直接陷入医院系统细节。

问题 2：FastGPT 也有知识库，为什么医梦还要维护知识库？

回答：

FastGPT 的知识库解决的是向量化和检索，这是运行能力。
医梦负责的是医学知识结构、医生端表达、患者端表达、禁止表达、风险分层、医学审核和医生反馈迭代。

医疗知识库不是上传文档，而是知识工程。
我们建议 FastGPT 承载运行副本，医梦维护源资产和版本主控。

问题 3：FastGPT 能不能直接输出给患者端？

回答：

不建议。
患者端输出必须经过医疗安全校验、风险分层、禁止表达过滤、通俗化转换和卡片封装。
尤其是报告解读、慢病任务、用药建议这些场景，模型原始输出不能直接面向患者。

FastGPT 可以生成候选结果，医梦控制层负责最终医疗输出。

问题 4：医生反馈为什么不能直接进 FastGPT？

回答：

可以同步优化结果给 FastGPT，但原始反馈闭环建议在医梦。
医生反馈要关联指标、知识条目、Prompt、Workflow、卡片、场景、模型版本和验收用例。

它不是普通日志，而是医疗智能体持续进化的数据资产。
医梦结构化整理后，再同步知识库和 Workflow 优化结果到 FastGPT。

问题 5：这样是不是深信服只能做底层，被医梦包起来？

回答：

不是。
深信服仍然控制 FastGPT 平台、模型、RAG、Workflow、算力、私有化部署和平台运行。
医梦控制的是医疗业务主链路。

这个分工对双方都有利：
深信服保持平台通用性，医梦承担医疗行业复杂度。
双方形成联合解决方案，而不是谁包谁。

14. 最适合放 PPT 的金句

FastGPT 解决 AI 能力，医梦解决医疗落地。
没有 FastGPT，医梦交付成本高；没有医梦，FastGPT 容易停留在医疗 Demo。
深信服负责 Agent Runtime，医梦负责 Medical Control Plane。
FastGPT 可以生成结果，但医疗业务闭环必须由医梦控制。
医院验收的不是平台能力，而是医疗场景是否真正可用。
FastGPT 做知识库运行副本，医梦做医疗知识库源资产。
FastGPT 调用工具，医梦定义医疗工具语义。
医生反馈不是日志，而是医疗智能体进化的数据资产。
医梦不是给 FastGPT 增加一层，而是给 FastGPT 增加医疗行业适配层。
双方合作的目标不是做一个 Demo，而是做一套可复制、可验收、可收费的医疗智能体解决方案。

15. 建议 PPT 结构

页码	标题	核心内容
P1	医梦 × 深信服 FastGPT 医疗智能体合作模式	FastGPT AI 能力底座 + 医梦医疗智能体控制层
P2	合作总判断	双方不是替代关系，而是互补关系
P3	为什么医疗不能只靠通用 Agent 平台	通用平台关注回答生成，医疗项目关注业务闭环
P4	医梦核心价值地图	医疗场景设计、医院接口网关、知识库源资产、Card、反馈、安全、验收、计量
P5	系统协作架构	用户入口 → 医梦统一入口 → 医梦控制层 → FastGPT Adapter
P6	MCP / Tool 分工	FastGPT 调工具，医梦定义医疗工具语义
P7	知识库分工	医梦掌握源资产，FastGPT 承载运行副本
P8	报告解读场景闭环	查报告、解读、医生端摘要、患者端通俗化、反馈、迭代
P9	对深信服的价值	医梦让 FastGPT 更容易进入医疗项目
P10	合作边界与落地建议	FastGPT 做底座，医梦做控制层，双方共同复制

16. 最终谈判目标

16.1 技术共识

FastGPT 只与医梦控制层对接。
医院系统只接医梦 MCP Gateway。
用户入口只接医梦统一入口。
医疗业务状态在医梦。
医疗写操作由医梦控制。
医生反馈回医梦。
知识库源资产在医梦。
FastGPT 提供 AI 能力和平台运行能力。

16.2 商务共识

医梦不是深信服隐形实施团队。
医梦作为医疗智能体场景专家出现。
医梦参与需求调研和医生访谈。
医梦保留医疗模板和知识库复用权。
医梦收入不只按人天。
双方共同形成医疗行业联合解决方案。

16.3 产品共识

第一阶段：报告解读 PoC。
第二阶段：慢病任务生成 PoC。
第三阶段：统一入口多智能体。
第四阶段：联合方案复制推广。

17. 结尾总结话术

我们认为双方合作的最佳状态不是深信服自己做完整医疗交付，也不是医梦重复做一个通用 Agent 平台，而是各自守住优势。

深信服守住 FastGPT、模型、RAG、Workflow、算力、安全和私有化部署；
医梦守住医疗入口、医疗工具、医疗状态、医疗知识、医生反馈、卡片交互和场景运营。

这样双方才能形成真正可复制的医疗 AI 联合解决方案，而不是一次性的项目外包。

18. 文档生命周期说明

本文是 FastGPT 接入专题下的谈判与合作边界设计稿，主要服务于商务沟通、PPT 和网页方案制作。根据文档生命周期，专题仍需补齐：

缺口	用途
`需求录入.md`	记录甲方诉求、深信服合作背景、医梦谈判目标
`需求文档.md`	固化 PoC 范围、非目标、验收标准和商业边界
ADR	记录“FastGPT 作为 AgentEngine 实现层之一，而非医疗主入口”的架构决策
`接口说明.md`	固化医梦 Tool API、FastGPT Adapter、报告解读最小链路接口
`测试计划.md`	把报告解读 PoC、工具调用、日志、脱敏、降级转成可执行验收项

医梦与深信服FastGPT合作模式方案.md 39 KB History Raw

医梦与深信服 FastGPT 商业谈判与技术合作边界方案

0. 文档定位

1. 谈判总判断

2. 一句话总口径

3. 合作系统定位

3.1 深信服定位

3.2 医梦定位

4. 推荐架构与不建议架构

4.1 推荐架构：FastGPT 在医梦后方

4.2 不建议架构：FastGPT 直接接医疗业务

5. 医疗项目为什么不能只靠 FastGPT

5.1 通用 Agent 平台解决 AI 能力，医院项目需要业务闭环

5.2 医疗场景不是问答系统，而是强状态任务系统

6. 医梦不可替代的八大价值

价值一：医梦把 FastGPT 从通用 Agent 平台变成医疗可交付系统

价值二：医梦掌握医疗业务接口语义，避免 FastGPT 陷入医院系统细节

价值三：医梦负责医疗安全边界，避免模型输出直接形成风险

价值四：医梦拥有医疗知识库工程能力，而不是简单上传文档

价值五：医梦设计医生反馈闭环，让智能体越用越准

价值六：医梦用 Card Runtime 承接医疗关键动作，避免 AI 越权

价值七：医梦把平台能力包装成甲方可采购、可验收的医疗场景包

价值八：医梦补齐医疗商业化计量，而不只是 Token 成本统计

7. 双方技术边界

7.1 总分工表

7.2 Workflow 边界

7.3 MCP / Tool 边界

7.4 知识库边界

8. 医梦必须守住的底线

8.1 技术底线

8.2 数据底线

8.3 商业底线

8.4 可让步范围

9. 关键业务流程示例

9.1 报告解读流程

9.2 慢病任务生成流程

9.3 挂号智能体流程

10. 下周需要和深信服确认的技术问题

10.1 FastGPT 平台能力确认

10.2 必测 Demo：报告解读最小链路

11. 合作落地分阶段建议

11.1 第一阶段：接口与能力验证

11.2 第二阶段：报告解读 PoC

11.3 第三阶段：慢病任务生成 PoC

11.4 第四阶段：统一入口多智能体

12. 会议现场讲解口径

12.1 开场 1 分钟

12.2 讲医梦价值 2 分钟

12.3 讲双方分工 2 分钟

12.4 讲为什么不是给 FastGPT 增加负担

13. 应对深信服可能的追问

问题 1：FastGPT 也能接 API，为什么还需要医梦 MCP Gateway？

问题 2：FastGPT 也有知识库，为什么医梦还要维护知识库？

问题 3：FastGPT 能不能直接输出给患者端？

问题 4：医生反馈为什么不能直接进 FastGPT？

问题 5：这样是不是深信服只能做底层，被医梦包起来？

14. 最适合放 PPT 的金句

15. 建议 PPT 结构

16. 最终谈判目标

16.1 技术共识

16.2 商务共识

16.3 产品共识

17. 结尾总结话术

18. 文档生命周期说明

医梦与深信服FastGPT合作模式方案.md 39 KB

History Raw