MARC v1：面向临床场景的多智能体协作框架实践指南

MARC v1 是字节跳动开源的一个面向临床场景的多智能体协作框架。多数医疗 AI 开源项目只做单模型推理，输入一段主诉，直接输出判断，中间过程不可控。MARC 的思路不太一样：它把诊断推理拆成感知、计划、反思、知识、验证五个环节，让不同智能体分别负责信息抽取、初步判断、复核修正、知识补充和结论一致性检查，再用贝叶斯网络做多轮递归协调。你可以把它理解成一个“能分工、能开会、能复查”的临床 AI 工作流骨架，而不是又一个模型权重。

这个项目最值得关注的不是单点模型能力，而是“临床多智能体怎么协作、怎么验证、怎么落地区别于演示级应用”。对于正在做医疗 NLP、临床决策支持、Agent 工作流编排或想了解企业级框架如何设计“可控 Agent”的人来说，MARC v1 是一个能直接看代码、能改配置、能跑通的框架。

不过要提前说清楚两件事：第一，它不是医疗器械，输出的分诊建议和治疗方向只能用于研究、测试、辅助决策素材，不能直接替代医生诊断；第二，默认基座模型定位偏 Qwen2.5-72B 这个体量，本地完整推理门槛不低，大多数场景会走 API 推理或小模型验证。本文会按“能不能用、怎么部署、怎么验证、怎么接入工程”的顺序拆解这个框架。

1. MARC v1 核心能力速览

这张表里的信息是给读者快速判断用的。是不是所有字段都值得做？不是。如果你只是要一个“症状输入 -> 疾病可能性输出”的问答工具，MARC 的架构对你来说太重了，直接调一个通用大模型 API 更快。如果你的场景要求推理过程可控、分角色复核、中间结果可审计，MARC 这种设计才有优势。

2. 多智能体角色分工与临床协调逻辑

MARC v1 最大的特色在于它把临床推理过程显式建模成“多智能体递归协调”。不要把它想成五个 LLM 并行跑然后投票，更接近一条有明确质检节点的工作流。

2.1 核心智能体角色

框架里存在五个方向的智能体，命名上可以直接对应临床推理链路：

从工作流上看，感知智能体先输出“结构化病历摘要”，计划智能体再出“初步意见”，知识智能体会补入更多鉴别诊断，反思智能体对这些结论提异议，最后验证智能体给出“一致性评分”和“剩余不确定性”。整个过程不是一次性生成，而是多轮递归，每一轮结果会反馈给上一步做修正。

2.2 贝叶斯网络在其中的作用

这里容易出现一种误解：贝叶斯网络不是用来做词嵌入或者语义匹配的。它在 MARC 里更接近“结构化协调器”：把不同智能体给出的结论转化为带概率依赖的变量，通过条件概率来估计“当前证据下这个结论是否可靠”，从而决定是否需要触发下一轮修正。

换句话说，贝叶斯网络给多智能体协作提供了一个“停止条件”。不是所有病例都需要反复讨论，简单病例一轮就能收敛，复杂病例则会因为节点间置信度不统一触发更多轮次。这种设计的工程价值很明显：既保证复杂病例被深挖，又不让小病小痛消耗过多推理资源。

2.3 建议验证的推理链路

部署完成后，建议先跑一组包含明确症状描述的中文测试输入，观察五个智能体各自的输出字段。判断标准如下：

• 感知智能体是否把症状、持续时间、既往史拆开；
• 计划智能体是否给出了带鉴别诊断方向的中间判断；
• 知识智能体是否补充了超越原始输入的医学信息；
• 反思智能体是否对置信度偏高的结论提出反例；
• 验证智能体是否输出最终一致性结论。

任一层缺失，说明配置的基座模型对指令的服从性不足，应优先考虑换成规模更大的模型或调整 Prompt 模板。

适合读这篇博客的读者包括医疗 AI 方向的研究人员、正在设计多智能体工作流的后端工程师、需要把临床数据做结构化整理的算法工程师，以及想在企业内部搭一套“多角色协作 + 审计日志”Agent 框架的架构师。

3. MARC v1 适用边界与合规使用要求

MARC v1 并不适合直接对真实患者提供服务。这不是项目代码问题，而是医疗 AI 监管层面的基本要求。不要因为开源项目宣称 Clinical 就默认它已经通过医疗器械审批。绝大多数开源临床推理框架属于研究性质，可以在模拟数据、内部测试、医生辅助预实验中使用，但不能以“自动诊断工具”的身份面向患者发布。

实际使用时建议明确以下边界：

• 只能处理获得授权或已脱敏的临床文本，禁止直接上传含完整姓名、身份证号、联系方式、家庭住址的原始病历；
• 输出结果必须标注“辅助参考，需专业人士审核”；
• 涉及药物剂量、过敏原、手术建议等内容，一律由具备资质的临床人员人工复核；
• 人脸、声音等生物识别信息如果与病例数据绑定，需额外遵守当地个人信息保护要求；
• 如果你要把输出结果用于发表论文或商业产品，需要重新评估模型合规性与数据来源授权。

对于国内开发者，还需要考虑医疗数据不出院、数据分级分类管理等问题。这里不展开法规细节，但原则上应做到：开发环境全脱敏，测试环境用合成数据，生产环境单独论证合规性。

4. MARC v1 本地部署环境准备

在动手之前先明确硬件和软件条件。因为框架默认基座模型依 Qwen2.5-72B 这一档开源模型展开，它的部署路径会明显分成两类：完整的本地推理和有 API 模型可接入的轻量部署。

4.1 硬件要求

关键点在于，MARC 的智能体角色是写在框架代码里的，模型可以通过配置切换。也就是说，如果你只是为了验证工作流能不能跑通，不需要一上来就上 72B；先用一个 7B 到 14B 的模型把链路跑起来，确认日志输出和 API 返回结构正常，再到靠谱的 API 服务或高性能机器上做正式推理，这样排错成本最低。

4.2 基础依赖环境

通用依赖检查原则如下：

• 操作系统：建议 Linux，Ubuntu 22.04 或更新版本兼容性最好；
• Python：3.10 或 3.11；
• 包管理：pip，建议先创建 conda 或 venv 虚拟环境；
• 数据库：MongoDB，本地安装或通过 Docker 启动均可；
• 代码仓库：克隆 MARC v1 项目仓库并安装 Python 依赖；
• 大模型服务：要么准备 OpenAI 兼容的 API Base URL 与 Key，要么本地启动模型服务。

# 第一步：克隆代码仓库 git clone https://github.com/ # 具体仓库地址和分支请以官网或官方 README 为准 cd marc-v1 # 实际目录名以仓库为准 # 第二步：创建虚拟环境 python3.11 -m venv venv source venv/bin/activate # 第三步：安装依赖 pip install -r requirements.txt

如果项目提供requirements.txt，这一步通常能完成大部分后端依赖安装。过程中会出现网络慢、包版本冲突、torch 安装体积过大等常见问题。建议在虚拟环境中安装，不要直接往系统 Python 里塞依赖。

4.3 MongoDB 准备

MongoDB 在 MARC 里扮演结构化存储角色。多智能体的中间结果、任务状态、最终输出都会写入集合中，方便后续审计和批量任务开发。本地没有 MongoDB 环境时，最轻量的方式是使用 Docker：

# 启动一个本地 MongoDB 容器 docker run -d \ --name marc-mongo \ -p 27017:27017 \ -e MONGO_INITDB_ROOT_USERNAME=admin \ -e MONGO_INITDB_ROOT_PASSWORD=admin123 \ mongo:7

注意，上面的方式是开发测试用。生产环境请关闭端口映射、设置强密码并启用权限控制，不要把数据库直接暴露到公网。如果已经在本机安装过 MongoDB，直接确认 27017 端口可访问即可，不需要重复运行容器。

5. MARC v1 模型接入与启动流程

模型接入方式取决于你选择本地推理还是 API 调用。MARC 的设计目标是“多 LLM 选项”，所以配置通常会支持通过环境变量或配置文件来指定模型类型、API 地址与 Key。

5.1 方式一：接入 OpenAI 兼容 API

现在大多数模型服务商与本地推理框架都提供 OpenAI 兼容接口，这是最快跑通 MARC 的办法。配置思路如下：

# 设置大模型 API 参数 export OPENAI_API_KEY="你的API Key" export OPENAI_API_BASE="https://api服务地址/v1" export LLM_MODEL_NAME="qwen2.5-72b-instruct" # 设置 MongoDB 连接 export MONGODB_URI="mongodb://admin:admin123@127.0.0.1:27017"

由于不同项目的环境变量命名可能不同，建议在仓库里检查.env.example或config文件，确认实际名称后再设置。API Base 和模型名写错了，框架会启动成功，但一提交任务就报连接错误或返回空值。

5.2 方式二：本地推理

有本地部署条件时，通常会先使用 vLLM 或 LMDeploy 之类的高性能推理框架启动一个 OpenAI 兼容服务，再把 MARC 指向这个本地地址。

# 启动 vLLM 推理服务示例，实际模型路径需要按你下载的权重调整 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-72B-Instruct \ --served-model-name qwen2.5-72b-instruct \ --port 8000 \ --tensor-parallel-size 2

这里--tensor-parallel-size的数量等于本机 GPU 卡数量，如果你的显存无法容纳完整模型，应该先对权重做量化，或者改用 API 方式。启动服务后再回到 MARC 配置：

export OPENAI_API_BASE="http://127.0.0.1:8000/v1" export LLM_MODEL_NAME="qwen2.5-72b-instruct"

从工程角度看，API 模式和本地模式的差别只在模型服务这一层。MARC 后端本身不需要改动，它会以标准 OpenAI 格式请求模型服务，这给开发带来了很大便利：先在 API 模式跑通业务逻辑，再切到本地模型验证效果。

5.3 启动 MARC 服务

依赖、数据库、模型三项都就绪后，启动 MARC 服务。如果仓库提供启动脚本，通常是这样：

python main.py --host 0.0.0.0 --port 8001

启动成功后，日志里会出现访问地址。打开浏览器进入 Web UI，能看到病例提交表单和智能体状态面板。首次打开建议先不做真实推理，先确认界面能正常渲染、MongoDB 中能看到初始化记录，再提交测试数据。

6. MARC v1 功能测试与效果验证流程

下面给出一套不需要预知框架内部细节也能完成的“黑盒验证流程”。这套流程重点不是证明 MARC 输出有多准，而是让你判断这一次部署是否真正跑通了五个智能体协作链路。

6.1 准备最小测试数据

建议准备两条不同复杂度的测试输入。最简单的一条类似普通感冒症状，复杂的一条包含既往病史、用药信息和多种并发症。不要在初始测试阶段直接上传完整真实病历，先只用脱敏的虚构病例。

简单病例： 患者，男，30岁。发热2天，体温最高38.5摄氏度，伴咽痛、鼻塞、流涕。无药物过敏史，既往体健。已自行服用布洛芬两次。 复杂病例： 患者，女，62岁。发热伴咳嗽、咳痰5天。既往有2型糖尿病史，血糖控制不佳。本周出现活动后胸闷气短。目前服用二甲双胍和阿卡波糖。吸烟史20年。

6.2 执行功能测试

以 Web UI 或接口方式提交第一条复杂病例。任务开始后，观察页面是否出现分阶段状态变化：

• 状态一：感知阶段。页面应显示抽取出的结构化症状字段；
• 状态二：计划阶段。出现初步诊疗思路与鉴别诊断；
• 状态三：知识与反思阶段。可能经过多轮修订，中间结果会更新；
• 状态四：验证阶段。输出一致性结论与剩余不确定性描述。

判断成功的标准不是“输出看起来是否专业”，而是以下几个硬指标：

• 是否有独立字段保存感知结果；
• 是否有中间推理轮次记录；
• 是否有验证模块输出；
• MongoDB 中是否保存了结构化任务记录；
• 通过 API 能拿到完整任务状态而不仅是最终文本。

如果某个环节的结果为空或直接跳过，说明对应智能体的 Prompt 没有被正确触发。常见原因是模型指令跟随能力不足或 Prompt 模板与基座模型不兼容。可以优先调高模型温度或替换模型再测试。

6.3 评测输出质量时的注意点

验证 MARC 输出质量时，要特别警惕“听着像回事但实际不可靠”。医学推理和通用问答不同，错误边界很低。建议不要让单个 LLM 判断作为最终评测标准，而是准备一种更客观的方式：

• 把同一批脱敏病例同时交给 MARC 和两名具备临床背景的标注员；
• 比较 MARC 输出的分诊方向、检查建议、鉴别诊断是否与标注员一致；
• 记录不一致点，作为失败样本反馈到 Prompt 模板中；
• 对 MARC 输出中“置信度”的词进行人工复核。框架给出的置信度来自模型自评，不能代表真实统计概率。

6.4 批量临床测试

当单个任务跑通后，可以尝试把多个病例放到目录中批量执行。如果框架支持批量任务，一般会监听一个输入目录或接收一个 JSON 数组。生产实践里建议加上任务管理和审计功能，让每条任务都对应唯一的业务编号。

# 批量处理时建议把输入文件整理成统一的 JSON 格式 # 目录结构示例 inputs/case_001.txt inputs/case_002.txt outputs/case_001_result.json outputs/case_002_result.json logs/batch_20250101.log

运行时先只放两个病例验证；等输出字段和日志确认正常后，再扩大批次数目。避免第一批就跑上千条病例，一旦中断不好定位。

7. MARC v1 接口 API 与审计化批量任务设计

作为一个可以被工程化集成的框架，MARC 的价值主要靠 API 接口体现。虽然仓库的具体接口路径需要以实际文档为准，但从后端服务设计来看，通常会暴露三类接口：提交任务、查询任务状态、获取任务结果。下面给出与这种设计相匹配的通用调用模板，实际路径请按仓库路由修改。

7.1 提交任务示例

import requests import json # 按实际服务地址和接口路径修改 BASE_URL = "http://127.0.0.1:8001/api" payload = { "case_id": "case_001", "input_text": "患者，男，30岁。发热2天伴咽痛、咳嗽。", "meta": { "source": "batch_test", "patient_id_encrypted": "deidentified_hash_12345" } } response = requests.post( f"{BASE_URL}/submit", json=payload, timeout=30 ) print(response.status_code) print(response.json())

接口设计上，case_id必须是业务中可检索的编号。不建议直接使用患者真实 ID 作为 case_id，应先用脱敏规则转换。

7.2 查询结果与轮询

异步任务接口通常不会在 POST 请求里直接返回最终结果，而会先返回task_id，然后由客户端轮询查询。具体实现写法如下：

import time import requests BASE_URL = "http://127.0.0.1:8001/api" def wait_for_result(task_id, timeout=300): start = time.time() while time.time() - start < timeout: r = requests.get( f"{BASE_URL}/task/{task_id}", timeout=10 ) status = r.json().get("status") if status == "completed": return r.json()["result"] elif status == "failed": raise RuntimeError(f"task {task_id} failed") time.sleep(3) raise TimeoutError("task timeout") result = wait_for_result(task_id) print(json.dumps(result, ensure_ascii=False, indent=2))

轮询间隔建议设置成 3 到 10 秒，避免过于频繁请求对服务造成压力。如果预计单个任务推理时长超过一分钟，需要使用更长的超时时间。

7.3 批量任务队列设计

当病例数量比较多时，不建议一个 for 循环同时发上百个并发请求。这样做会把 MARC 后端和大模型 API 同时压垮。合理的批量任务设计是：

• 维护一个待处理列表；
• 设定同时并发数，建议开始时设为 1，通过测试后再逐渐上调；
• 每个任务处理完成后写一条日志；
• 失败任务进入重试队列，最多重试两次；
• 所有任务结束后生成汇总报告。

from concurrent.futures import ThreadPoolExecutor, as_completed case_list = ["case_001", "case_002", "case_003"] results = {} def process_one(case_id): # 省略具体 API 响应逻辑 return case_id, "ok" with ThreadPoolExecutor(max_workers=2) as executor: futures = [executor.submit(process_one, cid) for cid in case_list] for future in as_completed(futures): cid, status = future.result() results[cid] = status print(results)

如果批量任务中出现个别卡死，不必重启全部任务，只需把超过超时时间的任务标记失败，单独重跑即可。这是医疗文本批量处理里最常见的工程改进点。

7.4 审计日志与结果落库

因为是医疗相关任务，审计比结果更重要。MARC 引入 MongoDB 存储本身有利于审计，但业务侧仍需把“谁在什么时间提交了什么输入，输出是什么，由哪个模型生成”完整记录。建议 API 层在入库时增加以下字段：

{ "task_id": "task_001", "case_id": "case_001", "model_name": "qwen2.5-72b-instruct", "temperature": 0.1, "input_hash": "sha256_hash_value", "perception_result": {}, "planning_result": {}, "reflection_result": {}, "knowledge_result": {}, "verification_result": {}, "final_conclusion": "", "status": "completed", "created_at": "2025-01-01T10:00:00Z" }

这些字段既方便后续对结果溯源，也能让监管或审核人员快速复盘某条结论是如何产出的。总之，在医疗场景里，中间过程的可解释性和可追溯性，重要程度不亚于最终输出内容的准确度。

8. MARC v1 资源占用与性能观察方向

由于 MARC 需要的显存和内存完全由你选择的基座模型决定，讨论“到底占用多少显存”必须先选模型。这里给出资源观察的通用方法，你在自己的机器上按步骤操作，就能得到可参考的数字。

8.1 观察指标

启动 MARC 后端后，分别观察三类指标：

• 推理服务侧显存占用：使用nvidia-smi查看单个进程的显存使用；
• MongoDB 的内存占用：任务写入越多，内存增长越明显；
• MARC 后端进程的内存占用：这与多智能体工作流中加载的中间数据量有关。

# 每隔 2 秒刷新一次 GPU 占用 watch -n 2 nvidia-smi # 查看 MARC 后端进程 CPU 和内存占用 top -p $(pgrep -f "main.py" | head -1)

8.2 核心变量对性能的影响

在观察资源时，建议分别修改以下几个变量来做对照测试：

在低资源配置下，优先降低推理轮次和并发数两个指标，比较快地能让任务稳定运行。

8.3 如何判断当前配置是否够用

如果任务提交后长时间没有状态变化，首先看是不是模型推理没有返回。再检查是不是多个智能体并发触发导致显存溢出。正常情况下，每个任务都应在可预期时间内走到验证阶段。如果单个任务一直卡在感知或计划阶段，不要怀疑框架坏了，优先确认模型服务是否正常响应。

9. MARC v1 常见问题与排查方法

下面的排查清单可以覆盖大多数部署和运行场景。其中的现象与对策并非针对 MARC v1 的特定缺陷，而是多智能体临床推理框架与本地大模型部署共性问题。

9.1 启动与依赖问题

9.2 推理结果问题

9.3 批量任务问题

批量任务卡住的概率比单条任务高很多。原因可能有：部分病例文本长度异常，触发超长上下文；API 限流导致请求排队；MongoDB 连接数达到上限。遇到卡住时不要直接终止进程，先看日志中最后一条有效输出的时间点，再做针对性重试。批量队列里建议为每条记录都加大超时和重试机制，保证单条失败不会拖垮整个批次。

10. MARC v1 最佳实践与工程建议

框架部署成功只是开始，要在实际场景里稳定使用 MARC，建议按照下面的工程实践组织代码和数据。

第一，维护一套最小可运行配置。把所有环境变量、模型地址、MongoDB 连接串写进一个.env.example文件，并记录你验证过的一套配置。这样当环境变化或需要二次部署时，可以按这套已验证的配置快速恢复现场，不需要重新排错。

第二，采用病例输入输出目录分离。将原始病例、脱敏后输入、MARC 中间推理结果、人工复核结论分开存放。不要在后端进程的工作目录里随手创建文件，时间久了很难追溯版本。

第三，对 MARC 的输入做必要的数据清洗。如果病例文本中存在乱码、不完整段落、重复字符，感知智能体输出的结构化字段会变差。先做基础清洗并把清洗逻辑沉淀为脚本。

第四，按任务粒度做审计。在一次 MARC 运行中，同一个患者可能被提交多次，那就在业务层记录：第一次提交是什么时间、使用哪个模型、产生什么结论、由谁审核。

第五，显存不足是把任务切成小片段，而不是直接降低模型质量。MARC 的多智能体本身就是以“较短的任务单元”为粒度设计的，如果把大段临床文本一次性塞给模型，大概率会截断和丢失信息。

第六，在正式发布前必须人工复核结果。对涉及患者风险的场景，人工复核不是可选项，而是强制环节。

除了工程实践，这里再强调一遍合规实践：如果你在医疗数据环境中使用 MARC，尽量使用合成数据或经过匿名化处理的文本。项目实践中可以给每个病例生成一个脱敏 ID，替换姓名、身份证、电话等字段后再送入模型。如果隐私数据脱敏不彻底，多智能体框架的中间结果一旦泄露，风险会更大。

11. 总结与下一步建议

回到最开始的问题：MARC v1 值不值得试？

如果你的目标是理解“医疗多智能体推理链路如何工程化”，非常值得。它展示了感知、计划、反思、知识、验证五种角色的分工方式，并且用贝叶斯网络作为协调器解决了“多轮修订什么停止”的问题。这在多数开源 Agent 框架里是少见的：很多项目只是多个 LLM 并行调用，MARC 至少在架构层面给了更完整的递归协调思路。

如果你是临床人员，想直接拿它做一个面向患者的问诊机器人，时机还不成熟。这里最大的坑不在推理效果，而在合规和事实稳定性。MARC 这类框架输出的建议必须经过专业审核才能用于真实诊疗流程。建议第一步先用脱敏的历史病例验证能否帮助医生节省文书整理类工作量，再考虑更复杂的决策支持方向。

对开发者的下一步建议是：

• 先看代码，找到感知、计划、反思、知识、验证五个智能体的 Prompt 文件；
• 用最小模型把工作流跑通；
• 然后替换成更强的 API 模型保存一套基线评测结果；
• 在批量和审计功能稳定后，再考虑叠加 RAG 做医学知识检索。

如果你正在做医疗 AI，MARC v1 是一个值得收藏参考的开源项目；建议部署前把 MARC 的多智能体链路和自身业务场景做一次功能拆解，确认你需要的是推理协调引擎，还是一次性的摘要工具。前者它能帮上大忙，后者它可能显得过重。