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

MARC v1 是字节跳动开源的一个面向临床场景的多智能体协作框架。多数医疗 AI 开源项目只做单模型推理输入一段主诉直接输出判断中间过程不可控。MARC 的思路不太一样它把诊断推理拆成感知、计划、反思、知识、验证五个环节让不同智能体分别负责信息抽取、初步判断、复核修正、知识补充和结论一致性检查再用贝叶斯网络做多轮递归协调。你可以把它理解成一个“能分工、能开会、能复查”的临床 AI 工作流骨架而不是又一个模型权重。这个项目最值得关注的不是单点模型能力而是“临床多智能体怎么协作、怎么验证、怎么落地区别于演示级应用”。对于正在做医疗 NLP、临床决策支持、Agent 工作流编排或想了解企业级框架如何设计“可控 Agent”的人来说MARC v1 是一个能直接看代码、能改配置、能跑通的框架。不过要提前说清楚两件事第一它不是医疗器械输出的分诊建议和治疗方向只能用于研究、测试、辅助决策素材不能直接替代医生诊断第二默认基座模型定位偏 Qwen2.5-72B 这个体量本地完整推理门槛不低大多数场景会走 API 推理或小模型验证。本文会按“能不能用、怎么部署、怎么验证、怎么接入工程”的顺序拆解这个框架。1. MARC v1 核心能力速览能力项说明项目类型开源临床推理多智能体框架核心建模感知智能体 计划智能体 反思智能体 知识智能体 验证智能体配合贝叶斯网络做多智能体递归协调主要功能症状信息抽取、分诊方向判断、诊疗建议复核、知识检索补充、结论一致性验证基座模型默认基于 Qwen2.5-72B 规格具体版本已仓库模型配置为准模型运行方式支持接入 API 形式的大模型服务也支持本地推理具体看部署模式数据存储引入 MongoDB 保存结构化记录便于保留中间过程与审计日志批量能力从框架设计来看支持批量输入与队列化处理建议部署后验证实际吞吐接口能力提供后端服务应用可调用 HTTP 接口提交任务详细路径以仓库 API 文档为准前端界面带交互界面适合快速查看各个智能体角色的中间推理结果适用场景医疗 AI 研究、临床数据整理、分诊预实验、Agent 编排学习、医疗文档摘要这张表里的信息是给读者快速判断用的。是不是所有字段都值得做不是。如果你只是要一个“症状输入 - 疾病可能性输出”的问答工具MARC 的架构对你来说太重了直接调一个通用大模型 API 更快。如果你的场景要求推理过程可控、分角色复核、中间结果可审计MARC 这种设计才有优势。2. 多智能体角色分工与临床协调逻辑MARC v1 最大的特色在于它把临床推理过程显式建模成“多智能体递归协调”。不要把它想成五个 LLM 并行跑然后投票更接近一条有明确质检节点的工作流。2.1 核心智能体角色框架里存在五个方向的智能体命名上可以直接对应临床推理链路智能体角色解决的问题类比临床工作感知智能体Perception从主诉、现病史、生命体征等非结构化文本中抽取关键临床信息医生接诊时的病史采集与信息归纳计划智能体Planning基于当前信息形成初步评估、检查方向或处理方案初步判断与诊疗计划拟定反思智能体Reflection审视前面给出的判断是否存在遗漏、矛盾或过度推理上级医生查房复核知识智能体Knowledge调用医学知识完成补充说明、鉴别诊断扩展查阅指南、文献或药品说明验证智能体Verification检查最终结论与前置证据是否一致是否在不确定性范围内质控与最终审签从工作流上看感知智能体先输出“结构化病历摘要”计划智能体再出“初步意见”知识智能体会补入更多鉴别诊断反思智能体对这些结论提异议最后验证智能体给出“一致性评分”和“剩余不确定性”。整个过程不是一次性生成而是多轮递归每一轮结果会反馈给上一步做修正。2.2 贝叶斯网络在其中的作用这里容易出现一种误解贝叶斯网络不是用来做词嵌入或者语义匹配的。它在 MARC 里更接近“结构化协调器”把不同智能体给出的结论转化为带概率依赖的变量通过条件概率来估计“当前证据下这个结论是否可靠”从而决定是否需要触发下一轮修正。换句话说贝叶斯网络给多智能体协作提供了一个“停止条件”。不是所有病例都需要反复讨论简单病例一轮就能收敛复杂病例则会因为节点间置信度不统一触发更多轮次。这种设计的工程价值很明显既保证复杂病例被深挖又不让小病小痛消耗过多推理资源。2.3 建议验证的推理链路部署完成后建议先跑一组包含明确症状描述的中文测试输入观察五个智能体各自的输出字段。判断标准如下感知智能体是否把症状、持续时间、既往史拆开计划智能体是否给出了带鉴别诊断方向的中间判断知识智能体是否补充了超越原始输入的医学信息反思智能体是否对置信度偏高的结论提出反例验证智能体是否输出最终一致性结论。任一层缺失说明配置的基座模型对指令的服从性不足应优先考虑换成规模更大的模型或调整 Prompt 模板。适合读这篇博客的读者包括医疗 AI 方向的研究人员、正在设计多智能体工作流的后端工程师、需要把临床数据做结构化整理的算法工程师以及想在企业内部搭一套“多角色协作 审计日志”Agent 框架的架构师。3. MARC v1 适用边界与合规使用要求MARC v1 并不适合直接对真实患者提供服务。这不是项目代码问题而是医疗 AI 监管层面的基本要求。不要因为开源项目宣称 Clinical 就默认它已经通过医疗器械审批。绝大多数开源临床推理框架属于研究性质可以在模拟数据、内部测试、医生辅助预实验中使用但不能以“自动诊断工具”的身份面向患者发布。实际使用时建议明确以下边界只能处理获得授权或已脱敏的临床文本禁止直接上传含完整姓名、身份证号、联系方式、家庭住址的原始病历输出结果必须标注“辅助参考需专业人士审核”涉及药物剂量、过敏原、手术建议等内容一律由具备资质的临床人员人工复核人脸、声音等生物识别信息如果与病例数据绑定需额外遵守当地个人信息保护要求如果你要把输出结果用于发表论文或商业产品需要重新评估模型合规性与数据来源授权。对于国内开发者还需要考虑医疗数据不出院、数据分级分类管理等问题。这里不展开法规细节但原则上应做到开发环境全脱敏测试环境用合成数据生产环境单独论证合规性。4. MARC v1 本地部署环境准备在动手之前先明确硬件和软件条件。因为框架默认基座模型依 Qwen2.5-72B 这一档开源模型展开它的部署路径会明显分成两类完整的本地推理和有 API 模型可接入的轻量部署。4.1 硬件要求部署模式硬件建议说明本地推理完整模型多卡 GPU 或 64GB 以上显存的专业卡72B 级别 FP16 需要极多显存常见做法是 2 到 4 张消费级卡并行或用量化权重本地推理量化模型24GB 显存起步可用 GGUF/AWQ/GPTQ 量化后的权重实际占用以量化位数为准24GB 才能获得相对可用的上下文长度纯 API 模式普通开发机 至少 16GB 内存不需要本地承担模型计算部署负担大幅下降仅跑代码逻辑验证8GB 显存 24GB 内存可用小模型测试工作流框架不追求医学结论质量关键点在于MARC 的智能体角色是写在框架代码里的模型可以通过配置切换。也就是说如果你只是为了验证工作流能不能跑通不需要一上来就上 72B先用一个 7B 到 14B 的模型把链路跑起来确认日志输出和 API 返回结构正常再到靠谱的 API 服务或高性能机器上做正式推理这样排错成本最低。4.2 基础依赖环境通用依赖检查原则如下操作系统建议 LinuxUbuntu 22.04 或更新版本兼容性最好Python3.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_USERNAMEadmin \ -e MONGO_INITDB_ROOT_PASSWORDadmin123 \ 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_BASEhttps://api服务地址/v1 export LLM_MODEL_NAMEqwen2.5-72b-instruct # 设置 MongoDB 连接 export MONGODB_URImongodb://admin:admin123127.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_BASEhttp://127.0.0.1:8000/v1 export LLM_MODEL_NAMEqwen2.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, jsonpayload, timeout30 ) 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, timeout300): start time.time() while time.time() - start timeout: r requests.get( f{BASE_URL}/task/{task_id}, timeout10 ) status r.json().get(status) if status completed: return r.json()[result] elif status failed: raise RuntimeError(ftask {task_id} failed) time.sleep(3) raise TimeoutError(task timeout) result wait_for_result(task_id) print(json.dumps(result, ensure_asciiFalse, indent2))轮询间隔建议设置成 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_workers2) 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 核心变量对性能的影响在观察资源时建议分别修改以下几个变量来做对照测试变量资源影响建议测试方式输入病例长度输入越长感知阶段占用越多推理时间越长分别提交 100 字和 800 字病例多智能体递归轮次每多一轮模型相对增多一次调用比较同一病例是否触发多次反思并发任务数并发越高显存和 API 请求压力越大从并发 1 开始逐步增加MongoDB 写入频率高频写库会增加磁盘 IO 和内存占用检查任务落盘速度模型上下文长度上下文越长KV Cache 占用显存越大对比长窗口和短窗口模型在低资源配置下优先降低推理轮次和并发数两个指标比较快地能让任务稳定运行。8.3 如何判断当前配置是否够用如果任务提交后长时间没有状态变化首先看是不是模型推理没有返回。再检查是不是多个智能体并发触发导致显存溢出。正常情况下每个任务都应在可预期时间内走到验证阶段。如果单个任务一直卡在感知或计划阶段不要怀疑框架坏了优先确认模型服务是否正常响应。9. MARC v1 常见问题与排查方法下面的排查清单可以覆盖大多数部署和运行场景。其中的现象与对策并非针对 MARC v1 的特定缺陷而是多智能体临床推理框架与本地大模型部署共性问题。9.1 启动与依赖问题问题现象可能原因排查方式解决方案启动时提示找不到 Python 包虚拟环境未激活或依赖未装完检查pip list中缺少哪些包重新执行pip install -r requirements.txt启动时报 MongoDB 连接失败未启动 MongoDB 或连接串错误检查 27017 端口是否开放启动 MongoDB或修改 MONGODB_URI页面打开但无法提交任务后端与前端端口不一致查看前端请求的后端地址统一服务端口配置模型接口返回 404API Base 地址或模型名错误用 curl 测试模型服务地址修改 OPENAI_API_BASE 或模型名CUDA 不可用显卡驱动与 PyTorch 版本不匹配执行python -c import torch; print(torch.cuda.is_available())重装匹配的 PyTorch 版本显存溢出模型权重超出 GPU 容量观察nvidia-smi显存占用降低 batch size切换量化模型或增加并行卡数结果一致但效果差基座模型不够强无法完成复杂临床推理检查简单病例是否可用换更大参数量模型或改善中文医学 Prompt9.2 推理结果问题问题现象可能原因排查方式解决方案五个智能体只有两三个有输出LLM 没有正确返回 JSON打印原始模型输出调整 Prompt强制要求 JSON 输出并降低温度结果自相矛盾反思或验证阶段未生效检查递归轮次日志增加最大递归轮数或让反思智能体更显式地引用矛盾点所有病例给出的结论都相似模型失去对输入的敏感性比较模板提示与输入内容检查是否输入长度被截断或 prompt 占位符写错输出中存在虚构医学知识基座模型幻觉结果落库并人工复核接入知识库检索增加“无法确定时明确说不确定”的指令API 调用超时任务推理时间过长查看日志耗时增加请求超时时间或拆分为多个小任务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 做医学知识检索。如果你正在做医疗 AIMARC v1 是一个值得收藏参考的开源项目建议部署前把 MARC 的多智能体链路和自身业务场景做一次功能拆解确认你需要的是推理协调引擎还是一次性的摘要工具。前者它能帮上大忙后者它可能显得过重。