需求录入.md 3.7 KB
doc_id: INT-202606-001 feature_id: FEAT-202606-006-agent-semantic-interaction type: intake title: Agent 语义交互与命令治理需求录入 status: reviewing owner: 医梦研发团队 created_at: 2026-06-29 updated_at: 2026-07-01 reviewers:
- 产品负责人
- 架构负责人 related_docs:
- PRD-202606-001
- DDS-202606-001
- DDS-202606-002 related_modules:
- emoon-openplatform
- emoon-ai-agent
- emoon-ai-card
- emoon-ai-mcp tags:
- Agent
- 卡片定位
- 语义响应
- 命令治理 ---
Agent 语义交互与命令治理需求录入
来源
需求来自挂号 Agent 实际设计复盘。原方案先定义科室、医生、时段等卡片，再使用卡片动作串联业务。 该方案在演示阶段路径清晰，但真实患者会一次性表达多个约束，也会在无结果时要求调整日期、职称或院区。
典型输入：
我想挂明天呼吸科主任医师的号。
纯文本与 MCP 工具调用可以直接查询完整候选，并自然说明相邻日期等替代方案；固定卡片链则要求模型输出 指定 JSON，并按系统预设顺序重复选择，导致业务能力受 UI Schema 反向约束。
问题
- 卡片被当作 Agent 流程节点，而不是展示与确认手段。
- 模型必须直接输出严格
cardKey/cardData，格式失败会影响整个回答。 - 查询、选择和写操作共用卡片动作协议，无法按风险区分。
- 信息卡也创建持久化实例，带来无必要的状态和渲染开销。
nextCard固化线性流程，无法自然覆盖信息已齐全、条件修改、无结果推荐和插入问答。- 卡片定义同时承载展示、动作和流程，长期会形成隐式工作流。
用户和场景
- 患者：通过 Web、小程序、自助机、机器人或导诊屏进行挂号查询和确认。
- 医院运营/实施人员：配置 Agent 能力、工具、展示策略和命令风险规则。
- 终端开发者：消费统一 SSE 事件，并按终端能力渲染文本、语音或无状态展示。
- 后端开发者：维护 TaskState、MCP、命令状态机、幂等、审计和 FastGPT 适配。
首个纵向样板为挂号 Agent，覆盖查询、替代推荐、选择、锁号和最终挂号确认。
预期收益
- Agent 可以根据用户目标和已知约束动态查询，不再重复补问。
- 卡片渲染失败不影响文本或语音完成回答。
- FastGPT 不再直接生成最终卡片 JSON，也不能直接执行医疗写操作。
- 所有副作用按统一风险等级进入确定性命令协议。
- 文本、卡片、语音与终端适配引用同一份可信工具结果。
- 查询灵活性与医疗写操作的安全、幂等和审计同时保留。
初步范围
包含：
- SemanticResponse、ResultSnapshot、Presentation、Command 的统一模型；
- TaskState 唯一事实源；
- FastGPT 优先接入及只读 MCP 边界；
- OpenAPI v2 与 SSE 事件；
- 挂号 Agent 纵向样板；
- 旧卡片链、模块、数据表和文档口径的分阶段实施、最终单次切换方案。
不包含：
- 代码、SQL、Maven 或终端实现；
- Dify、自研 AgentEngine 和多引擎运行时；
- 其他医疗 Agent 的完整实现；
- 生产历史数据迁移和新旧协议双轨。
依赖和风险
- FastGPT 必须支持可靠的工具/函数调用或等效结构化工具节点。
- HIS/MCP 查询结果具有实时性，展示快照不能代替锁号前复核。
- 患者身份、租户、项目和终端权限必须由医梦后端校验。
- 无状态展示和命令确认需要终端配合实现新的 SSE 与接口协议。
下一步
进入 PRD-202606-002 需求评审，并同步评审 ADR、详细设计、OpenAPI v2 和测试计划。