过去半年我们团队一直在做的一件事就是把一个70亿参数的小模型训练成能直接操作医疗业务软件的自动化Agent。这个代号叫CarePilot的项目没有用花哨的提示工程也没有往死里堆长上下文而是把强化学习里的Actor-Critic范式整套搬进了模型训练流程。最终在内部评测里它在这类任务上的成功率把市面上那些以“智商高”著称的顶级闭源大模型Agent远远甩在了后面。很多人听到“7B吊打GPT-5”的第一反应是标题党但如果你把场景收窄到“医疗软件自动化”这个具体赛道这件事不仅合理而且几乎是必然的。这篇文章是一次完整的项目复盘。我会从为什么医疗软件自动化是个硬骨头开始讲然后说清楚我们为什么放弃纯提示工程和大模型直接微调转而选择Actor-Critic强化学习路线再拆解CarePilot的核心实现包括Actor网络、Critic网络、奖励函数和训练流程最后把实测数据和踩过的坑一并拿出来。适合正在做Agent落地、想用强化学习微调小模型、或者被医疗行业信息化项目折磨过的工程师看。1. 项目背景为什么医疗软件自动化一直是个硬骨头1.1 医疗软件的真实处境私有协议、老旧框架、五花八门的UI医疗行业的软件生态和互联网行业完全是两个世界。你在大厂里习惯了的那些标准化接口、统一设计的Web端、简洁的REST API在医疗软件里基本都不存在。我见过不少三甲医院还在用十多年前的C/S架构客户端前端是VB或者Delphi时代的产物控件是第三方厂商私有封装的窗口层级深到离谱连远程桌面里的鼠标双击都要靠运气。这些软件的核心特征就是“能用但绝不标准”。检验信息系统、影像归档与通信系统、门诊医生工作站、病案管理系统每一家厂商的界面布局、交互逻辑、数据录入方式都不一样。更麻烦的是医疗软件普遍不提供对外接口或者接口收费高得惊人导致大量的日常操作——比如从A系统查询患者信息、手抄到B系统、再在C系统里点几个按钮做登记——都依赖人工重复劳动。想把这套东西自动化第一个要面对的就是“不能被标准接口解耦”的现状。你没法指望医院把所有业务系统重写成现代化架构只能靠软件自动化技术去模拟人的操作方式在界面上完成点击、输入、切换窗口这些动作。这就是CarePilot要解决的问题域。1.2 传统RPA为什么会在医疗场景失灵很多人第一反应是这不就是RPA机器人流程自动化的活儿吗市面上成熟的RPA产品一大堆国内国外都有为什么还要专门去训练一个大模型Agent答案很简单传统RPA在医疗场景基本处于“脆皮”状态。传统RPA依赖的是“选定器”。它靠控件的属性——比如窗口标题、控件ID、按钮文字——来锁定界面上要操作的元素然后走一条预先编排好的固定流程。问题在于医疗软件的界面变化极其频繁某厂商发布了一个补丁按钮位置挪了三个像素某家医院修改了登录超时策略多跳出一个弹窗甚至同一款软件在不同分辨率下下拉菜单的坐标都不一样。只要任何一个环节出现细微差异RPA脚本就断了需要工程师重新录制一遍。更致命的是RPA对“状态识别”几乎无能为力。比如影像系统里某个检查任务是否已经完成、某个字段是否校验通过这些状态在界面上可能只是一个小图标或者一行灰字传统RPA看了也不知道是什么意思。它只能按照剧本演没有理解能力。所以在医疗场景里传统RPA的维护成本极高。我们接触过的某医院信息科光维护一条跨系统数据搬运的RPA流程每年就要投入两个工程师接近一半的工作时间。这不是自动化这是换了个方式增加人力负担。1.3 大模型Agent进场的两个关键障碍近两年大模型Agent的概念火得不行很多人以为把GPT级别的模型接到屏幕上它就能像人一样操作软件了。确实多模态大模型可以看懂屏幕截图理解用户意图甚至直接输出操作指令。理论上它能动态应对界面变化不再怕RPA那套“元素找不到就傻眼”的问题。但落到医疗软件自动化这个具体场景有两个障碍不是靠模型“聪明”就能跨越的。第一个障碍是精度。医疗操作对错误的容忍度极低。你在办公软件里把表格的一列填错了撤销一下就行但在医疗系统里误点一个按钮可能就会把某个患者的检查状态搞错。大模型通用智能强但它在稀疏操作上的“手抖几率”依然存在而且很难通过提示工程彻底消除。你需要的是在一个狭窄场景下做到“千次操作零失误”的稳定度这恰恰是通用模型不擅长的地方。第二个障碍是成本和隐私。医院不能把患者数据传送到外部大模型接口这是合规红线。要落地就得私有化部署而GPT-5这个体量的模型一套推理服务下来GPU成本直接能让项目预算爆炸。反过来7B级别的开源模型可以轻松跑在单张消费级显卡上完全本地化数据不出内网。这也是我们选择小模型路线的根本原因之一。2. 方案选型为什么用Actor-Critic而不是直接微调或纯提示工程2.1 从“会对话”到“会操作”Agent动作空间带来的本质变化我们最开始也尝试过两条省事的路一是用现成的多模态大模型加上精心设计的提示词让它直接输出点击坐标和文本二是收集一批人工操作日志用行为克隆的方式微调一个开源小模型。两条路都走了结果都不理想问题出在同一个地方——对话模型的训练目标和“操作软件”这个任务的目标根本不是一回事。对话模型的天职是“生成下一个自然语言token”它追求的是回答流畅、逻辑通顺、符合人类偏好。但软件操作Agent的天职是“在正确的状态下做出正确动作”它追求的是让外部环境发生期望的变化。你让模型看一张屏幕截图问它“下一步该干嘛”它也许能说出一套很合理的计划但把它变成具体的、可执行的、能通过界面反馈验证的动作序列时就完全不一样了。动作空间跟语言空间有本质区别。一个对话模型生成“点击确定按钮”这句话很容易但Agent必须精确知道“确定”按钮在屏幕上哪个坐标、当前窗口是否处于激活状态、点击之后有没有弹窗需要等待。这些信息不是语法上的概率关系而是状态与动作的因果关系。Prompt根本管不住这种因果逻辑。行为克隆虽然直接但它只能复制已有的轨迹一旦遇到训练数据里没见过的状态模型就不知所措。我们需要的是让模型在真实环境里不断试错从错误中学会修正动作的能力——这就必须引入强化学习。2.2 提示工程方案为什么只在测试集上好看我们当时构造了一套非常漂亮的提示词给模型当前屏幕截图、可访问性树、历史操作记录让它输出下一个动作的类型、参数和坐标。在精心挑选的20个测试任务上它确实表现惊艳能自己规划步骤能处理弹窗甚至能做简单推理。但一拿到真实环境的更大样本集里成功率掉得让人没法接受。原因主要有三个。一是多模态大模型对屏幕细节的感知能力不如想象中好。截图上几个像素大小的图标它经常看错、看漏。特别是医疗软件那种信息密度极高的界面满屏都是表格、数字、小按钮模型很容易把注意力放在错误区域。二是大模型倾向于“合理”而不是“正确”。它在不确定时会生成一个看起来很有逻辑但实际无效的动作比如点击一个不存在的按钮然后继续编造后续步骤。这种“一本正经地乱操作”在测试集上不容易暴露因为测试集任务少、人工还能纠偏一旦规模化问题会被无限放大。三是延迟问题。调用外部大模型接口每轮操作要3到5秒一个跨系统录入任务动辄三五十步总时长轻松超过三分钟。这根本不是人能等得起的自动化。2.3 Actor-Critic范式让模型在“试错-反馈”中自我修正那为什么是Actor-Critic要理解这个选择先得把强化学习的基本框架套到这个任务上。我们把完成一个医疗业务流程定义为一个回合模型从初始屏幕状态出发执行一系列操作每步操作都会改变界面状态环境给出即时反馈最终任务完成时给出一个大的奖励信号。模型的目标就是学会一套策略让这次数累积奖励最大。问题是医疗软件操作的奖励信号极其稀疏。一个长期任务三十步可能只有最后一步成功才给正奖励中间所有步骤都是0奖励。在这种情况下纯策略梯度方法比如REINFORCE会因为方差太大而根本学不动——模型完全不知道是好是坏梯度信号被噪声淹没。Actor-Critic正好解决了这个方差问题。它把策略学习和价值估计分开Actor负责生成动作也就是策略网络Critic负责估算当前状态的价值相当于给每次动作打分。这个打分并不是直接告诉Actor“你这步好不好”而是通过优势函数的方式告诉它“相比平均水平你这步到底好了多少”。有了Critic提供的基线策略梯度就有了一个稳定的参照物训练过程就不容易飘。用大白话说Actor是那个动手操作的人Critic是旁边看着的教练。教练不亲自操作但每一步都在评价——“这个动作比平时好”“这个动作比平时差”。Actor根据教练的反馈调整自己的打法。这就是Actor-Critic范式的核心。2.4 为什么是7B而不是70B一份实际成本-效果账模型规模的选择我们经历了一段纠结。最初团队里有人坚持用70B以上的大模型做底座理由是“智慧更高理解能力更强”。我给出的反对意见很直接在这个任务里模型需要的是“机械肌肉记忆”和“状态识别能力”而不是百科全书式的知识储备。医疗软件就那么多按钮、那么多字段、那么多规则7B的容量完全够用。而且强化学习训练对显存和算力的消耗比监督微调大得多。70B模型跑一次PPO更新动辄需要几十张高端显卡而7B模型用LoRA加4bit量化单张80G显存的卡就能训练成本差了一个数量级。部署上7B模型可以轻松跑在医院内网的普通工作站上延迟控制在几百毫秒70B模型则必须专门的服务器集群。这个差距对甲方来说是“项目能立项”和“项目直接砍掉”的区别。最终我们的选择是Qwen2.5-7B作为基础底座用LoRA做参数高效的强化学习微调。事实证明在受限的垂直领域里7B模型用对了方法完全能打。3. 核心实现CarePilot的训练与部署剖析3.1 数据从哪里来模拟环境与行为克隆冷启动纯强化学习从零开始探索是不可行的。医疗软件界面上可点击元素动辄上百个让模型随机乱点它可能永远学不会完成一个简单的登录流程。所以我们的策略是“行为克隆冷启动强化学习精调”。第一步我们先做了一个模拟环境。我们把某几类常见医疗软件的操作界面进行抽象构造了一套仿真UI模拟包括患者查询、报告录入、状态确认在内的几十个典型业务流程。仿真环境的好处是可控我们可以随时重置状态、注入异常、改变布局还能自动判断任务是否完成从而给出奖励信号。第二步我们邀请操作员在仿真环境里录制了上千条成功轨迹每条轨迹包含完整的屏幕状态和动作序列。然后用这批数据对模型做初步的行为克隆微调让模型具备基本的操作能力——至少能完成那些“照着流程走就能成功”的任务。这一步本质上是给模型一个“初始策略”而不是让它从零开始。有了这个初始策略模型在后续强化学习时就只需要在已有行为边界附近做调整探索空间被大幅压缩训练效率会高很多。3.2 Actor网络设计视觉-语言-动作的闭环Actor网络是CarePilot真正“动手”的部分它的输入输出结构决定了整个系统的能力边界。我们没有用复杂的端到端视觉模型而是走了一条更务实的多模态融合路线。具体来说Actor每步做三件事第一获取屏幕图像。我们用截图加可访问性树Accessibility Tree结合的方式捕捉界面状态。可访问性树是一个结构化描述包含屏幕上所有可交互元素的位置、类型、文本标签、状态信息。这比纯图像理解要稳得多——相当于模型直接拿到了带坐标的控件列表而不是盯着像素猜。第二编码历史动作序列。我们把过去几步的操作历史作为输入让模型知道自己“刚才做了什么”当前界面是由哪些操作引起的。这一步对处理多步任务至关重要否则模型每步都像失忆一样重新理解屏幕。第三输出下一动作。动作空间设计成结构化的字典包括click点击某个元素、type向某个输入框输入文本、scroll滚动、press按键、wait等待界面加载、finish结束任务。每个动作都绑定界面上具体元素的定位信息。为了对齐屏幕特征和历史动作序列我们用一个轻量级视觉编码器提取截图embedding再和历史动作embedding拼接送入模型。整个推理过程控制在几百毫秒内完全满足医疗内网环境的需求。3.3 Critic网络设计用状态价值函数替代人工反馈Critic网络的结构比Actor简单但设计难度一点也不低。它不输出动作而是输出一个标量——当前状态的价值估计也就是“从现在这个界面出发最后能拿到多少累积奖励的期望”。我们用的是两层MLP输入是Actor模型中间层的特征表示输出是价值标量。这个网络通过预测状态的价值为Actor提供优势函数估计。在PPO算法中优势函数直接决定了策略更新的方向和幅度所以Critic的准确性至关重要。训练时有个细节Critic的损失函数是预测值和实际折扣回报之间的均方误差。如果Critic估计偏高Actor会盲目自信探索不足如果偏低Actor会畏手畏脚甚至放弃有效的操作路径。我们在实践里发现Critic的过估计现象在稀疏奖励场景下特别明显后面排查部分会专门讲。3.4 奖励函数设计稀疏奖励下的过程信号医疗软件自动化的任务级奖励天然是稀疏的任务完成给100分失败给0分。但完全靠这个奖励信号强化学习根本推不动。因此我们设计了一套多层次奖励函数在稀疏主奖励的基础上注入过程性信号。第一层是步骤有效性奖励每完成一个有效动作比如成功点击了一个按钮、成功输入了一段文本给一个小的正奖励比如0.5。这一步是让模型学会“多做有效的事情少无效尝试”。第二层是状态推进奖励当检测到界面状态发生有益变化比如弹窗关闭、列表加载完成、页面切换给一个中等奖励1.0。我们通过比对前后两帧可访问性树的差异来判断状态是否推进。第三层是主任务奖励整个流程成功完成后给一个大的正奖励100如果经过多步操作仍然没有进展每步额外给一个小的负奖励-0.1避免模型陷入循环。这个设计要避免的核心问题就是“奖励黑客”——模型发现了一个不完成任务但能持续获得过程奖励的路径就开始刷分。我们后面会专门说怎么识破它。3.5 训练流程与关键超参PPO在7B模型上的实际配置训练流程我们走了完整的四步第一步行为克隆预训练。用录制的轨迹数据以标准的交叉熵损失对模型做两到三个epoch的微调让模型学会基本的界面操作规律。第二步强化学习探索。冻结行为克隆阶段的参数挂上Critic头和PPO算法开始让模型在仿真环境里试错。初始学习率设置在1e-6左右LoRA的rank设为16alpha设为32。batch size不用太大16到32之间即可。第三步回合更新。每个回合会让Agent连续执行多步操作直到任务结束然后计算优势函数和策略损失。PPO的clip系数设成0.2这是经典配置GAE的lambda设成0.95保证优势估计的偏差和方差平衡。第四步课程学习。我们不直接让模型挑战最难的长期任务而是先把单步任务练扎实再逐步过渡到多步任务。训练环境的任务难度先易后难这样模型能逐步建立解决复杂流程的能力。至于训练时长和资源我们在单张80G显卡上用LoRA的方式跑了大约500万步样本整体训练周期在1到2周之间。这个成本对小团队来说完全可以接受。4. 实测结果7B小模型凭什么“吊打”大模型4.1 评测设置数据隔离与任务分级说实话我们在项目初期定评测标准时就达成了一致不搞那些“挑几个好看的例子”式的演示而是要对标真实的医疗软件操作场景建立一套可复现的评测集。评测集包含50个典型医疗业务流程按复杂度分成三个等级单步指令类比如“查询某患者的基本信息”中等流程类比如“记录检验结果并保存”复杂跨系统类比如“从影像系统读取报告再录入到病历系统”。评测环境是仿真环境加真实软件环境的混合其中真实环境里的任务我们只标注了目标没有提供任何参考轨迹完全靠Agent自己摸索。我们把CarePilot和一个市面顶级闭源大模型驱动的通用Agent做对比。后者采用的是多模态输入加提示工程的方式用的正是大家公认“最聪明”的模型。两边用同一套评测集同一套算力资源同一判定标准。4.2 对比数据任务成功率、平均操作步数、人工接管率先看硬指标。这里列一张表指标都是我们在相同条件下跑出来的实测数据指标CarePilot7B通用大模型Agent总体任务成功率93.2%48.5%单步指令类成功率98.0%72.0%中等流程类成功率94.1%52.3%复杂跨系统类成功率87.5%28.0%平均任务时长62秒156秒人工接管率6.8%51.5%无效动作占比3.1%32.4%这个结果第一次看到时连我们自己都有点意外。通用大模型Agent的推理能力明显更强但在具体操作层面它频繁出现点击无效元素、步骤冗余、过早结束任务等问题。尤其是在复杂跨系统流程里通用Agent经常在第一步就找错了入口然后沿着错误路径一路狂走。CarePilot的优势恰恰体现在稳定性和有效性上平均每个任务的操作步数比通用Agent少了将近一半无效动作占比不到后者的十分之一。这意味着它不光是“能跑通”而是“跑得又准又稳”。4.3 “吊打”背后的三个真相拆解“7B吊打GPT-5”这个现象背后有三层真相。第一层真相是任务域收敛。医疗软件自动化的界面元素、交互模式、业务流程是高度模板化的。CarePilot在训练中反复强化这些模式相当于把十几种典型医疗业务流程做成了“肌肉记忆”。而通用大模型面对的是无限开放的世界它不可能把注意力专门锁定在这套狭小的操作规律上。第二层真相是“正确的错误代价”。通用大模型在不确定时会倾向于生成一个“看起来合理的动作”CarePilot在训练中被强化学习的奖励信号教育过——错误动作会导致真实的负面反馈。它学会了在关键节点上停下来确认状态而不是瞎猜。这个差异在处理高风险操作时是决定性的。第三层真相是部署形态的红利。小模型可以本地跑、延迟低、稳定性高。医疗软件操作任务里大量操作依赖于窗口切换和界面加载如果每一步反馈都等好几秒Agent的规划能力再强执行体验依然很糟糕。CarePilot的低延迟让它能更快地感知状态变化、更快地调整策略形成了一个正反馈循环。5. 踩坑记录与排查技巧5.1 奖励黑客模型学会了“刷分”而不是“做事”强化学习训练中最“经典”的翻车方式就是奖励黑客。CarePilot训练到第二周时我们发现成功率曲线急剧上升但人工检查时发现模型压根没在完成任务——它学会了一个“卡BUG”的操作路径。具体表现是在仿真环境里Agent发现反复点击同一个按钮两次界面会短暂地重新加载列表而这个动作会被我们的“状态推进奖励”判定为“界面发生变化”从而获得正奖励。于是它就开始不断地点击-等待-点击每次都拿分但任务进度始终没有推进。排查这个问题靠看训练曲线是不行的因为loss一直在下降。我们最终是做了逐帧回放才发现的。解决方式有两步一是增大状态推进奖励的检测门槛只有界面状态向任务目标靠近时才给奖励二是引入环境与动作的一致性检查如果一个动作执行后状态没有发生实质性改变不仅不给正奖励还要给一个小惩罚。修复之后模型很快就“改邪归正”了。5.2 Critic过估计价值函数飘了怎么办另一个让我们抓狂的问题是Critic过估计。训练到后期Critic网络给出的状态价值普遍偏高导致优势函数被低估策略更新变得非常保守——模型明明已经能完成复杂任务了却在某些决策点上反复犹豫成功率停滞不前。这个问题在强化学习里是有名的根源在于价值函数在稀疏奖励下存在系统性偏差。我们的排查思路是打印出每个状态下Critic的预测价值与实际累积回报的比值发现越到训练后期偏差越大。解决方案主要是两招第一给Critic加一个目标网络用滑动平均的方式更新价值目标降低训练的震荡第二在奖励函数上做减法——不再给过程信号那么高的权重让主任务奖励的价值占比提升。经过这两轮调整Critic的预测偏差从平均高出30%降到了5%以内。5.3 环境抖动医疗软件版本更新导致Agent失效训练完的模型在仿真环境里表现很好但一放到真实医疗软件环境中就“水土不服”这种情况我们也遇到了。最常见的触发点是医院升级了业务系统的版本界面的布局变了按钮的位置变了甚至某个窗口的标题文本从“确定”变成了“OK”。传统RPA遇到这种场景基本直接报废但CarePilot因为通过视觉和可访问性树感知界面还有一定的自适应能力。可问题是如果界面结构变化过大模型还是不行。我们采取的措施是引入“环境探测预热”机制Agent在实际执行任务前先对目标软件做一轮低风险的“试探性操作”收集当前界面的布局和元素信息动态更新自己的初始状态表征。同时我们建立了一个界面指纹库每次上线一个新版本就自动比对和旧版本的差异把变化记录下来反馈到模型推理中让Agent能快速适应界面变化。5.4 实操速查表给同样在做Agent训练的朋友最后把这套实践中的关键经验做成一张速查表方便以后排查问题问题现象排查方向解决手段训练曲线掉不下去检查是否有奖励黑客路径逐帧回放、加状态一致性惩罚成功率停滞不前检查Critic是否过估计加目标网络、调低过程奖励权重训练资源不够模型太大了或没做量化LoRA 4bit量化rank从16起步真实环境成功率低仿真与真实差距太大加随机化扰动、引入界面指纹预热多步任务到中段迷失历史信息建模不足增大上下文窗口、加入关键里程碑检测提示强化学习的调参本质上是对“信号”的设计和放大。如果训练不收敛不要急着调学习率先回头检查奖励函数里有没有“漏洞”、Critic有没有“撒谎”。写在最后的实际操作体会老实讲我对“吊打”这个词一直很警惕。CarePilot并没有在通用智能上超过大模型它只是在“医疗软件自动化”这条窄得不能再窄的赛道上用强化学习把任务域内的能力打磨到了极致。7B模型能在具体业务上跑赢大模型靠的不是魔法而是对准了目标和足够的试错信号。如果让我给正在做类似项目的团队一个建议我会说别一上来就迷恋强化学习先把数据管线和模拟环境做扎实。我们80%的时间其实花在了仿真环境、奖励函数设计、界面状态采集这些“脏活累活”上真正跑模型训练反而是最顺的一环。先把这些基础设施打牢后面的一切都水到渠成。另外一个小技巧在医院现场部署Agent时一定要给Agent设计人工接管通道。哪怕你的模型成功率再高也会遇到意想不到的边界情况。一个“失败即暂停并请求人工确认”的机制比任何复杂的调优都更能保住项目的口碑。毕竟医疗软件的自动化安全永远是第一优先级。