医学世界模型：Steerable AI 与 Harness Engineering 的区别与系统架构思考
熊江辉 jianghui@deepome.com
摘要
随着大模型、RAG、AI Agent 和工具调用系统进入医疗健康领域，一个关键问题正在变得越来越重要：医学 AI 的安全性，是否只需要依靠 prompt、guardrail、workflow、human-in-the-loop 等外部工程约束来实现？
本文讨论 Harness Engineering 与 Steerable Biomedical World Model 的区别。前者主要通过外部工程结构约束 AI 行为，解决“AI 是否越界、是否乱说、是否合规输出”的问题；后者则试图从内部建模医学状态、干预动作、状态转移、反事实推理和质量控制反馈，解决“生物状态如何被表征、推演、检查和修正”的问题。
本文认为，医学 AI 不能只停留在“外部护栏”层面。真正的医学世界模型需要进入 state-action-transition-feedback 的内部架构，使医学推理过程可表征、可推演、可审计、可验证、可修正。
关键词
医学世界模型、Medical AI、Steerable AI、Harness Engineering、AI Agent、RAG、Biomedical World Model、SEWO、SteeraMed、AI Safety
目录
- 什么是 Harness Engineering？
- 医学 AI 为什么当然需要 Harness？
- 为什么 Harness 不等于医学世界模型？
- 什么是 Steerable Biomedical World Model？
- Harness Engineering vs Steerable World Model
- 医学世界模型的核心架构：State-Action-Transition-Feedback
- 一个例子：药物推荐系统 vs 可驾驭医学世界模型
- SteeraMed 应该指向什么？
- 工程实现中的分层架构
- 医学 AI 开发者自查清单
- 科学边界与风险提示
- 总结
- 参考资料
1. 什么是 Harness Engineering？
在当前大模型工程中，很多系统并不是直接把 LLM 裸露给用户，而是会在模型外部加上一整套约束、调度和验证机制。
这类工程实践可以概括为一种广义的 Harness Engineering。
这里的 “harness” 可以理解为：
给一个强大的 AI 模型加上外部的“马具、护栏、流程和校验器”，使其行为更加可控、可检查、可回滚。
典型组件包括：
- Prompt Template
- System Prompt
- RAG 检索增强
- Tool Calling
- Function Calling
- Workflow Orchestration
- Agent Planner
- Output Validator
- Safety Filter
- Rule Engine
- Human-in-the-loop
- Audit Log
- Sandbox Execution
- Permission Control
一个典型的 harness engineering 架构可以写成：
User Input
↓
Input Filter / Intent Classifier
↓
Prompt Template / System Prompt
↓
LLM / Agent
↓
Tool Calling / RAG / External APIs
↓
Output Validator
↓
Safety Filter
↓
Human Review, if needed
↓
Final Output
在软件工程中，这非常有效。
比如代码生成系统可以这样设计：
LLM Code Generator
↓
Static Analysis
↓
Unit Tests
↓
Type Checker
↓
Sandbox Execution
↓
Human Review
↓
Merge / Deploy
也就是说，harness engineering 的核心思想是：
不要求模型本身完全可靠，而是通过外部工程系统，让模型输出更可靠、更安全、更可控。
2. 医学 AI 为什么当然需要 Harness？
医学 AI 比普通 AI 系统更需要外部约束。
因为医学领域存在高风险：
- 误导患者；
- 伪造医学依据；
- 越权诊断；
- 擅自推荐药物；
- 忽视禁忌证；
- 混淆科普和医疗建议；
- 过度解释检查结果；
- 夸大疗效；
- 忽略急症风险；
- 造成延误就医。
因此，一个医学 AI 系统至少需要：
医学知识库
+ RAG 检索
+ 安全规则
+ 输出校验
+ 高风险场景识别
+ 医生审核
+ 免责声明
+ 审计日志
+ 权限控制
例如：
用户问题
↓
风险分级
↓
医学知识检索
↓
LLM 生成回答
↓
医学安全规则校验
↓
是否涉及诊断 / 处方 / 急症？
↓
必要时转人工或提示就医
↓
输出最终回答
这类 harness engineering 对医学 AI 非常重要。
但是，它解决的主要是 AI 行为风险。
例如：
AI 是否乱说？
AI 是否越权？
AI 是否伪造引用？
AI 是否输出危险建议？
AI 是否违反产品边界？
这些问题很重要，但它们不是医学世界模型的全部。
3. 为什么 Harness 不等于医学世界模型？
很多 medical AI agent 系统看起来很复杂：
LLM
+ 医学知识库
+ RAG
+ 工具调用
+ 多 Agent 协作
+ 报告生成
+ 安全过滤
+ 医生审核
这类系统可以做很多有价值的事情：
- 整理病历；
- 总结文献；
- 解释检查指标；
- 生成健康报告；
- 查询指南；
- 辅助医生写病程记录；
- 辅助患者理解医学术语。
但严格来说，这不一定是医学世界模型。
因为它可能没有真正回答以下问题：
1. 当前生物状态是什么？
2. 一个干预动作如何被编码？
3. 给定当前状态和干预动作，状态如何转移？
4. 如果选择另一个动作，反事实路径如何变化？
5. 如果结果没有按预期发生，失败原因如何定位？
换句话说：
有 workflow ≠ 有 world model
有 RAG ≠ 有 state representation
有 agent ≠ 有 transition model
有 guardrail ≠ 有 steerability
医学世界模型关心的不只是“AI 如何安全输出”，而是：
生物状态如何被表示？
干预动作如何被理解？
状态变化如何被推演？
失败如何被诊断？
下一轮如何被修正？
这已经超出了单纯 harness engineering 的范围。
4. 什么是 Steerable Biomedical World Model？
一个普通世界模型通常可以被抽象为：
current state + action → predicted or hypothesized next state
也就是：
S(t), A → S(t+Δt)
其中：
S(t)表示当前状态；A表示动作；S(t+Δt)表示动作之后的未来状态。
在机器人领域，这可能是：
机器人当前位置 + 电机动作 → 下一位置
在游戏智能体中，这可能是：
当前画面 + 玩家动作 → 下一帧状态
而在医学中，更严谨的表达应该是：
患者当前分子 / 功能状态 + 干预动作
→ 可检验的生物状态转移方向假设
这里需要特别强调：
在医学场景中，尤其是在缺乏充分纵向干预数据的早期阶段，所谓 “next state” 更应被理解为 可检验的状态转移方向假设，而不是已经验证的临床结局预测。
医学里的世界模型更难，因为：
- 状态是高维的；
- 动作是复杂的；
- 反馈是延迟的；
- 因果链条很长；
- 个体差异很大；
- 临床验证成本高；
- 安全边界要求极高。
因此，早期的医学世界模型不应被直接表述为“临床疗效预测系统”。
更严谨的说法是：
state-action-transition hypothesis system
也就是：
一个基于当前状态、候选动作、机制约束和已有证据，生成可审计、可验证、可反驳的状态转移假设的系统。
在预印本 World Models for Biomedicine: A Steerability Framework 中，我提出医学世界模型不应只是被动预测系统，而应发展为一个可审计、可质疑、可修正的 steerability framework。其核心包括状态表征、能力量化、干预响应语义、反事实转移和质量控制反馈。[1]
这里的“可驾驭”不是指模型自动控制人体，也不是指模型自动决定治疗，而是指模型能够把状态、动作、转移假设、机制证据和反馈检查显式化，使人类能够审查、质疑和修正推理路径。
5. Harness Engineering vs Steerable World Model
二者的核心区别可以概括为：
Harness Engineering controls the AI system from outside.
Steerable World Model structures biomedical reasoning from inside.
中文可以理解为：
Harness Engineering 是外部约束。
Steerable World Model 是内部可驾驭。
对比如下：
| 对比维度 | Harness Engineering | Steerable Biomedical World Model |
|---|---|---|
| 核心问题 | 如何让 AI 输出更安全？ | 如何让医学状态转移可表征、可推演、可检查？ |
| 主要对象 | 模型行为、工具调用、输出流程 | 生物状态、干预动作、状态转移、机制反馈 |
| 常见组件 | Prompt、RAG、Validator、Guardrail、Workflow | State、Action、Transition、Counterfactual、QC |
| 解决风险 | AI 行为风险 | 生物推理风险 |
| 失败诊断 | 输出是否违规？工具是否调用错误？ | 状态测量错了吗？干预语义错了吗？机制假设错了吗？ |
| 工程层级 | 外部安全层 | 内部世界模型层 |
| 是否构成医学世界模型 | 不充分 | 是核心条件之一 |
| 典型目标 | 安全可控地输出 | 可审计地推演状态变化 |
可以进一步表示为：
Harness Engineering:
LLM → safer output
Steerable World Model:
biological state → action → transition hypothesis → feedback
这并不是说二者相互排斥。
恰恰相反，医学 AI 需要两者同时存在。
但它们属于不同层级，不能互相替代。
6. 医学世界模型的核心架构：State-Action-Transition-Feedback
一个更接近医学世界模型的系统，不应只是：
LLM + RAG + Guardrails
而应该至少包含：
State Representation
Action Representation
Transition Estimation
Counterfactual Reasoning
Mechanism Evidence Chain
Quality-Control Feedback
可以写成如下架构：
Patient Data
↓
State Representation
S(t)
↓
Candidate Action Representation
A
↓
Transition Hypothesis Estimation
Ŝ(t+Δt | A)
↓
Mechanism Evidence Chain
↓
Uncertainty / Confidence
↓
Quality-Control Feedback
↓
Next Iteration
6.1 State Representation：状态表征
医学世界模型首先要回答：
这个人现在是什么状态？
这个状态不应只是：
疾病名称 = 糖尿病
疾病名称 = 抑郁症
疾病名称 = 类风湿关节炎
疾病标签是表型层描述，不等于世界模型的状态空间。
状态表征可以包括：
- DNA 甲基化状态；
- 转录组状态；
- 蛋白组状态；
- 代谢组状态；
- 免疫状态；
- 炎症状态；
- 器官功能状态；
- 通路状态；
- 网络模块状态；
- 衰老模块状态；
- 个体历史轨迹。
例如：
S(t) = [
immune_module_state,
mitochondrial_module_state,
metabolic_module_state,
inflammation_resolution_state,
organ_function_state,
...
]
这类状态可以是向量，也可以是图结构、层级结构或多模态嵌入。
关键不是形式，而是：
模型必须知道自己在模拟什么状态。
在 Capomics / mIC vector 的表达中，一个人可以被表示为多个模块内在能力的组合状态，而不是一个单一年龄或单一风险分数。[1]
6.2 Action Representation：动作表征
医学中的 action 不只是一个标签。
drug A
exercise
nutrition intervention
sleep improvement
behavioral therapy
这些只是表面名称。
在医学世界模型中，一个 action 应该被表示为：
A = {
target_modules,
mechanism,
direction,
dose,
timing,
duration,
sequence,
context,
uncertainty
}
例如，同样是“运动干预”，对不同个体可能意味着完全不同的生物响应：
个体 1：改善胰岛素敏感性
个体 2：诱发炎症负荷
个体 3：改善线粒体适应能力
个体 4：因过度训练导致恢复失败
因此，医学 action 必须进入 intervention-response semantics，不能只是数据库标签。
6.3 Transition Estimation：状态转移估计
世界模型最核心的问题是：
给定当前状态 S(t) 和动作 A，未来状态可能如何变化？
即：
S(t), A → Ŝ(t+Δt | A)
但在医学场景中必须谨慎。
早期系统不应直接声称：
模型预测这个治疗一定有效。
更严谨的表达是：
模型提出一个受机制约束的、可审计的状态转移方向假设。
也就是：
knowledge-constrained transition tendency
其含义是：
基于当前可用的生物机制、网络结构、个体状态和干预语义，估计一个可能的状态变化方向，但该方向仍需实验、随访或临床数据验证。
这一步是医学世界模型与普通医学问答系统之间的重要分界线。
普通问答系统回答：
文献里说什么？
医学世界模型进一步问：
如果当前状态是这样，施加这个动作后，状态可能往哪个方向移动？
这个方向假设能否被验证？
如果失败，原因可能在哪一层？
6.4 Counterfactual Reasoning：反事实推理
医学决策天然是反事实问题。
例如：
如果做 A 而不是 B，会怎样？
如果先做 A 再做 B，会怎样？
如果不做干预，自然轨迹会怎样？
如果相同干预用于不同状态的人，会怎样？
这类问题不能只靠检索回答。
它需要模型能表示：
Ŝ(t+Δt | A)
Ŝ(t+Δt | B)
Ŝ(t+Δt | no intervention)
然后比较不同路径。
这就是医学世界模型区别于普通问答系统的重要地方。
当然，在当前阶段，这种比较更应该被理解为 反事实状态转移假设的比较，而不是已经验证的个体化临床疗效预测。
6.5 Quality-Control Feedback：质量控制反馈
医学世界模型不能只预测，还要能诊断失败。
如果预期状态转移没有发生，系统应该问：
1. 状态是否测量错误？
2. 干预动作是否定义错误？
3. 模块响应是否没有发生？
4. 状态是否没有按预期移动？
5. 下游表型是否没有传播？
6. 时间窗口是否不合适？
7. 剂量或顺序是否不合适？
8. 个体基线是否不同？
这可以表示为：
Expected Transition
↓
Observed Transition
↓
Deviation Detected
↓
Failure Localization
↓
Model Revision / Hypothesis Revision
这也是 steerability 的关键。
普通模型失败时，只能说：
prediction error
可驾驭医学世界模型失败时，应该能说：
failure occurred at state measurement / action semantics / transition assumption / downstream propagation
在预印本中，我把这一点概括为从 “what-if simulator” 走向 “why-not steering system”：不仅要问“如果这样做会怎样”，还要问“为什么没有发生预期结果”。[1]
7. 一个例子：药物推荐系统 vs 可驾驭医学世界模型
假设某患者存在炎症相关异常。
普通知识检索系统可能输出：
某药物与炎症通路有关。
加上 harness engineering 后，它可能输出：
某药物与炎症通路有关，但本文仅供健康科普，不构成医疗建议，请咨询医生。
这个回答更安全。
但它仍然不是世界模型。
一个 steerable biomedical world model 应该进一步分析：
1. 当前炎症模块状态是什么？
2. 该患者的异常是否位于该药物相关通路？
3. 该药物 action 的靶点、方向和模块响应是什么？
4. 该 action 是否可能使状态向期望方向移动？
5. 这种移动是分子层、功能层，还是表型层？
6. 如果干预失败，失败可能发生在哪个环节？
可以对比如下：
| 系统类型 | 输出特点 | 是否具备世界模型能力 |
|---|---|---|
| 医学知识库 | 提供相关知识 | 否 |
| RAG 医学问答 | 检索后生成回答 | 否 |
| 带 Guardrail 的医学 Agent | 更安全地输出 | 不充分 |
| 药物推荐系统 | 给出候选排序 | 不充分 |
| Steerable Biomedical World Model | 建立 state-action-transition-feedback 证据链 | 开始接近 |
这里使用“开始接近”，而不是“已经等于”，是因为真正的医学世界模型还需要数据质量、纵向验证、干预数据、不确定性校准、安全边界、任务适配和临床评估等多方面条件。
8. SteeraMed 应该指向什么？
如果把 SteeraMed 理解为一个面向可驾驭医学 AI 的研究、方法或平台入口，那么它不应只是：
Medical LLM + RAG + Safety Guardrails
这类系统有价值，但更接近医学 AI 应用层。
SteeraMed 更应该关注一个更底层的问题：
How can medical AI become steerable rather than merely constrained?
也就是：
医学 AI 如何从“被约束”走向“可驾驭”？
从架构定位上，SteeraMed 可以被设计为两层：外部 harness layer 与内部 steerability layer。
SteeraMed Architecture
1. Harness Layer
- 权限控制
- 安全边界
- 合规规则
- 输出校验
- 人工审核
- 审计日志
2. Steerability Layer
- 状态表征
- 动作语义
- 反事实转移
- 机制证据链
- 质量控制反馈
第一层回答：
AI 能不能安全说话？
第二层回答：
医学状态能不能被结构化推演和驾驭？
这两层缺一不可。
9. 工程实现中的分层架构
一个严肃的医学 AI 系统，至少应该有如下分层：
┌──────────────────────────────────┐
│ Human Oversight Layer │
│ 医生、研究者、用户、伦理监督 │
└──────────────────────────────────┘
↑
┌──────────────────────────────────┐
│ Clinical Governance Layer │
│ 适用范围、责任边界、监管要求 │
└──────────────────────────────────┘
↑
┌──────────────────────────────────┐
│ Harness Engineering Layer │
│ Prompt / RAG / Guardrail / Audit │
└──────────────────────────────────┘
↑
┌──────────────────────────────────┐
│ Steerable World Model Layer │
│ State / Action / Transition / QC │
└──────────────────────────────────┘
↑
┌──────────────────────────────────┐
│ Biomedical Data Layer │
│ Omics / EHR / Wearables / Imaging │
└──────────────────────────────────┘
每一层解决不同问题：
| 层级 | 解决问题 |
|---|---|
| Biomedical Data Layer | 数据从哪里来 |
| Steerable World Model Layer | 生物状态如何建模和转移 |
| Harness Engineering Layer | AI 如何安全调用和输出 |
| Clinical Governance Layer | 系统是否适合某场景 |
| Human Oversight Layer | 最终如何由人类判断 |
这套分层可以帮助我们避免一个常见误区：
不能用外部 guardrail 来替代内部医学世界模型，也不能用世界模型概念来忽略临床治理和安全部署。
10. 医学 AI 开发者自查清单
如果你正在开发医学 AI 系统，可以用以下问题自查。
10.1 Harness Engineering 自查
[ ] 是否有 system prompt？
[ ] 是否有医学安全边界？
[ ] 是否有高风险意图识别？
[ ] 是否禁止越权诊断和处方？
[ ] 是否有 RAG 来源追踪？
[ ] 是否有输出校验？
[ ] 是否有人工审核入口？
[ ] 是否有审计日志？
[ ] 是否有免责声明？
[ ] 是否能处理不确定性？
10.2 Steerable World Model 自查
[ ] 是否定义了患者状态空间？
[ ] 是否能区分疾病标签和生物状态？
[ ] 是否能表示干预动作？
[ ] 是否能描述干预响应语义？
[ ] 是否能估计状态转移方向？
[ ] 是否能比较反事实路径？
[ ] 是否能生成机制证据链？
[ ] 是否能表达不确定性？
[ ] 是否能定位失败原因？
[ ] 是否能把反馈用于下一轮修正？
如果一个系统只能完成第一组检查，它是一个带护栏的医学 AI。
如果它也能完成第二组检查，它才开始接近医学世界模型。
11. 科学边界与风险提示
需要特别说明：
Steerable Biomedical World Model 不等于临床自动化决策系统。
它不应被理解为：
AI 可以替代医生。
AI 可以自动推荐治疗。
AI 可以预测个体疗效。
AI 可以直接用于临床决策。
更准确的定位是：
一个用于生成、组织和检验医学状态转移假设的研究架构。
真正进入临床应用，还需要：
- 前瞻性验证；
- 临床试验；
- 安全性评估；
- 真实世界随访；
- 医生监督；
- 监管审查；
- 适用范围限定；
- 责任边界定义。
因此，在现阶段，steerability 更适合作为：
研究框架
工程架构
机制推理系统
假设生成系统
而不是已经完成的临床产品能力。
免责声明：
本文讨论的是医学 AI 与生物医学世界模型的研究架构问题，不构成医疗建议、诊断建议或治疗建议。文中提到的 steerable biomedical world model 仍属于研究和工程架构层面的概念，任何临床应用都需要经过前瞻性验证、安全性评估、监管审查和医生监督。
12. 总结
Harness Engineering 与 Steerable Biomedical World Model 都很重要，但它们解决的是不同层级的问题。
Harness Engineering 主要解决：
如何让 AI 系统更安全、更可控、更合规？
Steerable Biomedical World Model 主要解决：
如何让医学状态、干预动作和状态转移变得可表征、可推演、可审计、可修正？
用一句话总结：
Harness engineering makes medical AI safer to use.
Steerable world modeling makes biomedical reasoning more inspectable.
医学 AI 的未来不应该只是：
更大的模型
+ 更多医学文献
+ 更复杂 Agent Workflow
它还需要：
明确的状态表征
+ 明确的动作语义
+ 可检验的状态转移假设
+ 可审计的机制链条
+ 可诊断的反馈闭环
第一代真正有价值的医学世界模型，可能不是那些宣称能预测一切治疗结果的系统。
相反，它们可能是更谦逊、更可审计、更可证伪的系统：
它们不宣称知道未来。
它们只是把每一个关于状态、动作、转移、机制和不确定性的假设，都明确到可以被测试。
这才是医学 AI 从“预测工具”走向“可驾驭系统”的关键一步。
13. 参考资料
-
Xiong J. World Models for Biomedicine: A Steerability Framework. Preprints.org, 2026. DOI:
10.20944/preprints202605.0366.v1. -
SEWO / Steerable Medicine World Model:
-
SteeraMed concept site:
-
SteeraMed concept site:
-
DeepOMe / 深度甲基:
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
1
0- 0
已为社区贡献2条内容
所有评论(0)