企业工作台与部署：把系统交给真实团队
工作台里最危险的按钮，往往不是“生成”，而是一个没有显示目标、版本和差异的“确认”。协调员要能发现候选、理解每条结论、补充缺失、处理冲突、签署并回溯，界面本身就是安全控制的一部分。
MedAgent Forge 的部署目标是把可审核的合成数据工作流交给团队，而不是把一个公开聊天接口伪装成医疗产品。
来龙去脉：从 Demo 到系统的断层
Section titled “来龙去脉：从 Demo 到系统的断层”本地 notebook 通常省略身份、并发、持久化、模型网关、队列、超时、成本、数据迁移和事故恢复。上线后，最常见失败不是“模型完全不会”，而是 API 限流、任务卡住、版本漂移、用户看不懂依据或日志泄露数据。
OpenTelemetry 用 traces、metrics、logs 建立厂商中立遥测，OpenInference 为 AI 调用补充语义。S27S28 但 span 属性不能无脑保存 prompt 和患者内容，应该记录引用、哈希、计数和经过审批的最小摘要。
核心原理：工作台设计
Section titled “核心原理：工作台设计”主页面不是对话流，而是三层：候选试验列表（状态/版本/风险）；criterion 表格（四态、证据数量、冲突）；证据抽屉（原始位置、时间线、来源版本）。人工可以确认、修改或要求补充，并填写理由；机器原始输出不可覆盖。
关键 UI 原则：unknown/conflict 醒目但不恐慌；写操作展示真实目标和 diff；协议更新显示版本差异；模型生成和人工签署视觉分离；键盘/移动端不牺牲证据可读性。
- Web/BFF：会话、CSRF、最小返回。
- API/Runtime：任务状态图、队列、审批。
- Tool gateway：FHIR/DICOM/检索 adapter 与服务端鉴权。
- Data plane：PostgreSQL/向量、对象存储、审计存储分权。
- Model gateway：本地/云 adapter、版本、配额和回退。
- Control plane：OPA、manifest、评测门、配置和 secrets。
本地 Docker Compose 只作开发；企业部署还需 OIDC、网络策略、备份恢复、滚动/蓝绿发布、容量和灾难演练。
| 选择 | 优点 | 风险 |
|---|---|---|
| 单体 + worker | 早期简单、事务清晰 | 扩展边界需纪律 |
| 微服务 | 隔离与独立伸缩 | 分布式复杂度和 trace 成本 |
| 本地模型 | 数据边界可控 | GPU/升级/容量自负 |
| 云模型 | 能力和弹性 | 数据合同、地域、供应商风险 |
先让发布门少一项证据就停止
Section titled “先让发布门少一项证据就停止”python3 labs/run_lab.py --lab 23实验模拟发布门：schema migration、12 场景、policy、性能预算、回滚包、数据卡/模型卡缺一项即阻止 release。可以删除任一项再运行，确认失败信息指向缺失工件，而不是把发布状态模糊写成“稍后再看”。它不启动 Docker，也不声称生产就绪。
贯穿用户旅程：协调员怎样完成一次审核
Section titled “贯穿用户旅程：协调员怎样完成一次审核”登录后首页显示有权限的队列，不暴露全院统计。进入 task，顶部锁定患者最小标识、试验、协议版本、状态与风险；左侧 criteria 列表可筛 unknown/conflict；中部显示机器草案和简短理由；右侧 Evidence drawer 提供时间线和来源定位。审核者逐条确认、覆盖或请求补充，最终签署生成版本化工作单。
界面把“来源事实”“模型判断”“人工决定”视觉分离。数值旁显示单位和日期；旧/冲突证据并列；模型 confidence 不用红绿灯冒充概率。所有高风险 action 展示 diff 与目标。手机可阅读教程/项目展示，但真实复杂审核是否适合手机需用户研究，不能只凭响应式布局决定。
前端状态与 API
Section titled “前端状态与 API”React/TypeScript 前端使用生成/手写 typed client，对 API schema 做版本兼容；server 是权限真源，前端隐藏按钮不是授权。查询 cache key 包含 task/version，不缓存跨患者响应；敏感状态不进 URL/analytics。长任务用 SSE/WebSocket 只传状态事件，断线后可按 task version 重连。
冲突编辑采用 optimistic concurrency：提交携带 assessment version，若他人已更新，展示 diff 而不是覆盖。人工 patch、签署与审批均通过 CSRF/会话/服务端 policy，并产生审计事件。
后端拓扑与模块边界
Section titled “后端拓扑与模块边界”FastAPI/API 层处理身份、schema 和 orchestration command；worker 运行状态图；tool gateway 统一外部 FHIR/DICOM/MCP；PostgreSQL 保存任务/合同/审计索引，pgvector 只存被允许的派生索引；对象存储放公开协议或许可资产；OPA policy 独立版本；model gateway 封装本地/云 route。
早期部署可以模块化单体 + worker + PostgreSQL，减少分布式事务。只有影像 GPU、组织边界、负载或安全证明需要，再拆服务。每个拆分都伴随 SLO、owner、API、trace 和故障模式；“微服务化”本身不算完成。
配置 profile
Section titled “配置 profile”demo-synthetic 一键启动合成数据，无外部医院连接；mac-local 配本地模型 adapter；cuda-full 配独立 inference/training；enterprise-reference 只提供 Helm/Kubernetes 参考，不宣称已在机构验证。每个 profile 列功能与非目标，禁止 demo secret/开放端口进入生产。
Docker Compose 验证服务能组合、健康检查和 migration，不提供高可用。生产需 OIDC、TLS、network policy、secret manager、持久卷、备份、autoscaling、pod/security policy、image signing 和运维 runbook。
可观测性设计
Section titled “可观测性设计”trace root 是 task id，每个 agent/node/tool/model 是 span；metrics 包括队列、节点时延、tool error、unknown/conflict、安全拒绝和成本；logs 结构化但最小化。OpenTelemetry 提供统一信号，S27 OpenInference 可补 model/tool 语义，S28 仍要自行脱敏。
不把 prompt、患者全文和 token 写进通用 APM。debug 访问走受控 break-glass，内容有保留期。trace sampling 对错误/安全事件保留更多，对正常流量按政策采样；审计日志和调试 trace 是不同数据产品。
SLO 与容量
Section titled “SLO 与容量”定义可用性、队列等待、工作单生成、恢复时间与数据新鲜度；模型速度不是唯一 SLO。容量模型估计每日 tasks、平均 criteria、tool calls、模型 tokens、影像计算和人工并发。用负载测试验证队列/backpressure；外部 FHIR 限流时降级到排队，不开并发风暴。
成本按 task/tenant/route 归集。预算超限进入 review 或使用批准 fallback；不能在不告知的情况下换成未经评测的便宜模型。
artifact 包含代码镜像、SBOM、schema migration、policy、model/prompt/tool route、TaskPackage 结果、Model/Dataset Card 和 rollback。先 shadow，再 canary，小流量观察 task/safety；安全硬门任一失败自动停止。database migration 采用 expand/contract，回滚验证数据兼容。
模型回滚与代码不同：必须同时恢复 tokenizer/template/prompt/tool schema。协议/知识索引也有 snapshot。发布清单让“整个行为版本”可恢复，而非只换一个容器 tag。
灾难恢复与运行
Section titled “灾难恢复与运行”定期演练数据库/对象存储恢复，测 RPO/RTO；检查 pending tool calls 和幂等对账；撤销/轮换凭证；验证历史 Evidence 仍可解析。on-call runbook 按 tool outage、model outage、policy spike、data drift、suspected breach 分类。事故后更新 TaskPackage，而不是只改 prompt。
用户研究与组织接入
Section titled “用户研究与组织接入”在合成 sandbox 观察协调员完成时间、误解、覆盖理由和 Evidence 导航；访谈 IT/security/clinical governance。若用户频繁接受机器默认或看不到 conflict，属于界面风险。上线培训、责任、支持和变更沟通与代码同等重要。
章末发布演练
Section titled “章末发布演练”在 staging 让模型服务不可用、FHIR 连续 429、数据库恢复旧备份、policy 拒绝率突增，逐项观察队列、用户提示、trace、告警和回滚。验收目标不是“系统永不失败”，而是失败不越权、不丢审计、不重复副作用，并给协调员明确下一步。
把演练结果写入 VERIFICATION.md：环境、版本、时间、观察、失败、改进和 owner；没有真实执行就标 NOT RUN。截图只使用合成患者并检查无 token/内部地址。
能启动的 Compose、通过的页面性能和漂亮的工作台都只是局部信号。没有回滚演练、权限验证和协调员可用性证据，部署仍停留在演示阶段。
- Docker Compose 启动成功不等于可用性、安全或扩展性完成。
- Lighthouse/页面性能不能代表协调员决策质量，应做可用性研究。
- 观测系统本身是敏感资产，需隔离、访问控制和保留期限。
- 没有回滚演练的“可回滚”只是文档承诺。
资料与延伸阅读
Section titled “资料与延伸阅读”以下参考资料对应策略、观测、模型调用语义和风险治理四个部署面。它们不会替具体团队给出 SLO 或上线批准。