Concurrence 用 Unity Gateway 治理万亿级临床 AI

医疗 AI 几乎没有容错空间。协助协调患者护理的 AI 智能体依赖于可靠的患者上下文、对数据和模型访问的清晰管控，以及对每一次交互的可见性，同时还要满足严格的合规要求。

Concurrence正在以可观规模运营这些医疗智能体系统。该公司构建了覆盖患者端和医疗服务提供者端工作流的临床 AI 智能体，从 AI 临床医生、护士和护理协调员，到环境文档、护理计划摘要和知识检索。

在其生产 AI 环境中，Concurrence 现在每 30 天处理约 1008 亿个输入 token 和 1120 万次 LLM 调用，相当于约 1.2 万亿输入 token 的年化运行率。月度 token 量已从 2025 年末的基线增长约 5 倍，达到 2026 年 7 月的水平。

在高风险的临床工作流中，可靠的 AI 智能体始于可信、治理良好的数据。要大规模支撑这种可靠性，需要强大的合规性、严格的智能体测试和受治理的 AI 访问。Concurrence 正在 Databricks 上整合这些能力，借助Lakebase管理运营智能体和对话状态，借助Unity Catalog治理数据和 AI 资产，并借助Unity Gateway为其快速增长的开发者 AI 工作负载提供集中式 AI 访问和安全保障。

在可信数据上构建可靠的临床 AI

医疗数据在不同系统之间常常相互冲突。患者提供的信息可能与现有记录不同，而最新的值并不总是最可靠的。

Concurrence 通过将新信息记录为不可变事件而非覆盖现有记录来解决这一问题。基于该历史记录，Concurrence 计算当前患者状态，同时保留每项信息的来源和出处，它将其称为世界模型。这为智能体提供了关于患者已知信息的一致视图和历史记录，同时允许它们从患者和临床医生那里获知的信息反馈到状态中，供未来工作流使用。

Databricks 为此架构提供了共享数据基础。事件通过Zerobus Ingest流入受治理的 Delta 表，包括每月 270 万条世界模型事件，高峰时每天 9 万条。Apache Spark™ Declarative Pipelines派生 Concurrence 的世界模型和临床数据；Unity Catalog 治理每个客户环境；Lakebase 为运营应用提供所需的患者状态、智能体和对话状态以及知识库数据。

护理缺口和用药依从性外展是一个例子。Concurrence 的智能体可以致电或发短信给随访护理逾期或正在漏服药物的患者，利用现有患者上下文引导对话，并将获知的信息记录回患者状态，供未来工作流使用。Concurrence 还在 Databricks Apps 上运行生产应用，包括护理包指南、护士护理计划摘要和临床内容审查界面。每个应用都建立在同一套受治理的患者上下文和基础设施之上。迁移到此架构还使 Concurrence 能够淘汰其自研的提示日志存储和反向 ETL 作业，转而采用受治理的 Delta 表和 Lakebase Synced Tables。

在生产前测试临床 AI 智能体

Concurrence 新平台上的每个智能体在接触真实患者之前，都要针对模拟患者进行测试。如今，新平台上的模拟和评估流量约为生产流量的七倍。

Concurrence 的数据架构使这种测试成为可能。由于患者状态是根据不可变事件历史计算得出的，团队可以重放该状态并测试不同路径，而不会更改真实患者记录。这使 Concurrence 能够在将智能体部署给患者之前，评估其对不同场景的响应方式。

智能体追踪数据通过 Zerobus Ingest 流入，并与产生它们的临床数据一起落入 Delta 表。使用 Databricks 托管的 Claude 运行的定时 ai_query 作业随后对这些交互进行对话质量和安全性评分，提取记忆，并将结果写回 Delta。由于患者数据、追踪数据、结果和评估都位于同一受治理的基础上，团队可以调查性能变化是来自模型、数据还是工作流。

在医疗保健中执行 AI 治理与合规

对 Concurrence 而言，HIPAA 要求从一开始就塑造了架构。Concurrence 目前已符合 HIPAA、GDPR 和 SOC 2，同时正在推进 HITRUST 和 ISO 27001/42001。每个医疗组织都有自己的 schema 和服务主体，访问控制、血缘和审计追踪均通过 Unity Catalog 治理。

对于批量 AI 工作负载，Concurrence 在 BAA 下运行ai_query作业，使用 Databricks 托管的 Claude。其端点解析器只允许使用 BAA 覆盖命名空间内的模型，防止 PHI 被路由到未覆盖的模型。同一条受覆盖路径还运行 Concurrence 针对自残、自杀意念和医疗紧急情况的安全分类。因此，其一些最高风险的 AI 工作负载受到同一架构约束的保护。这也塑造了 Concurrence 的模型路由方法：路由首先受合规限制，其次才受成本限制。模型必须先满足工作负载的合规要求，Concurrence 才会考虑质量、性能或成本。

实时患者和临床医生推理目前仍运行在 Concurrence 现有的提供商基础设施上。Concurrence 已经构建了用于实时推理的 Unity Gateway 集成，并通过功能开关控制，同时有一个合成金丝雀持续对其进行端到端测试。一旦所需的合规覆盖可用，生产流量就可以迁移到 Unity Gateway。

使用 Unity Gateway 治理编码智能体

Concurrence 将同样的方法应用于开发者 AI。编码代理被用于工程、运营和研究领域，包括在客户环境中工作的前沿部署工程师，这些环境处理敏感的医疗保健数据。

Concurrence 将所有编码代理的模型和工具流量路由通过 Unity Gateway 的编码 CLI，ug。开发者获得一条通往已批准模型和 MCP 工具的单一受治理路径，同时每个请求仍与其发起人的身份相关联。MCP 访问通过同一环境集中管理，权限按工程师组分配，当代理访问 Databricks、Datadog 和 Linear 等工具时，每个用户单独进行身份验证。

规模已经相当可观。7 月份，14 个独立用户通过 Unity Gateway 生成了 358.5 亿输入 token，其中 95.37% 为缓存读取。自 ug 于 7 月 10 日推出以来，Concurrence 的编码代理已生成约 36 万次请求和 610 亿累计输入 token。

集中化编码代理流量使 Concurrence 能够了解开发者 AI 的使用方式及其成本。每个请求都归属于发起它的工程师，允许个人通过 ug usage 监控自己的使用情况。在组织层面，Concurrence 使用来自 system.ai_gateway.usage 的 Databricks 使用数据来跟踪正在使用的模型、token 消耗、缓存率以及按个人和团队划分的支出。

使用 Unity Gateway 集中化 AI 访问

Concurrence 的目标是将生产、批处理和开发者 AI 纳入 Unity Gateway 这一共同的推理控制点之下。开发者 AI 已经通过 Unity Gateway 运行，而批处理推理则通过 BAA 覆盖的路径在 Databricks 托管的模型上运行。目前，Claude Opus 4.8 和 GPT-5.6 Sol 占编码代理模型使用量的大部分，Opus 5 的使用量正在增长。在所需的合规覆盖到位之前，实时患者和临床医生推理仍保留在 Concurrence 现有的提供商基础设施上。

这种多模型方法对 Concurrence 的临床工作负载尤为重要。该公司目前有 14 个模型提供生产推理，并有一个包含 46 个模型的受治理目录。大多数生产量运行在更小、更快的模型上，前沿模型则保留用于更复杂的推理。Concurrence 正在开发临床推理基准，以确定哪些模型在不同医疗保健任务中表现最佳。

Concurrence 也对 Unity Gateway 的创新速度感到兴奋。最近他们已开始测试 Unity Gateway Smart Routing，对照其正在开发的医疗保健特定路由方法，并将公布结果。由于医疗保健中的模型资格始于合规，这些评估将评估智能路由如何在为每个工作负载设定的边界内优化模型选择。在开发者方面，Concurrence 还在探索 Omnigent 作为其编码代理环境的元框架。

医疗保健 AI 的统一基础

随着 Concurrence 将更多工作流迁移到 Databricks，这一基础随着每一次代理交互而变得更有价值。每个代理的工作可以丰富下一个代理启动时所依据的患者状态，使新工作流能够复用现有上下文而非重建它，从而降低添加新 AI 工作流的增量成本和工作量。

以约 1.2 万亿生产输入 token 的年化速率计算，这一复利基础至关重要。通过将患者上下文、运营状态、追踪、评估、治理和 AI 访问汇聚在 Databricks 上，Concurrence 可以扩展高风险的临床 AI，同时保持医疗保健所要求的可靠性和控制。