智能体在每个步骤上单独测试都表现不错，不能说明它能把一条跨系统流程从头走到尾。单步测试检查的是“这一步做得对不对”，完整流程还要求前一步得到的信息、文件和结论被准确带到后一步，并在系统里真正执行。后者恰好是单步测试最少覆盖的部分。
因此，企业做跨系统流程试点时，验收不能停留在逐项打分；范围要按交接点多少来定，交接本身也要被单独设计和检查。
一组基准数据：同一个模型子任务大多通过，完整任务多数没完成
斯坦福大学以人为本人工智能研究院（Stanford HAI）在2026年10月19日发布了文章《Measuring What Medical AI Can Actually Do》。这篇文章以构建这些基准的研究团队口吻写成，介绍了他们三年来陆续构建的几项医疗AI基准，其中两项专门测试智能体能否完成多步骤工作。
HealthAdminBench模拟医疗行政工作：135项任务覆盖事前授权、申诉与拒付处理、耐用医疗设备订单，智能体要在四个模拟环境之间操作——一个电子病历系统（EHR）、两个保险支付方门户和一个传真系统，共设置1,698个可验证的子任务检查。HAI文章写道，GPT-5.4（计算机操作模式）通过了82.8%的子任务，却只完成了26.7%的完整任务。这组数字和下面的36.3%都来自论文的主评测设置（只给屏幕截图观察，提示中附门户操作指引）：在这一设置下，端到端完成率最高的是Claude Opus 4.6（计算机操作模式），为36.3%；论文换用其他观察方式和提示做的对比实验中，数字会不同。
PhysicianBench测试医生类工作：100项长流程任务、21个专科，平均每项需要27次工具调用，共670个检查点。表现最好的GPT-5.5单次运行完成46%的任务，而在三次独立运行中都完成的只有28%。
读这些数字时有三条边界：
- 两项基准都运行在沙盒环境里：HealthAdminBench的患者数据为合成数据；PhysicianBench使用的病历在HAI文章中称为“合成重建”，论文说明是经去标识化和扰动处理的临床记录。它们都不是医院真实系统中的运行结果。
- 作者明确说明，46%和36%不能直接比较，因为环境、模型集合、操作接口和评分方式不同，能成立的只是方向一致。
- 这些是医疗场景、特定任务和特定模型版本下的结果，不能换算成“企业智能体能完成多少工作”，也不应当作模型选型排名。
这组数据对企业有用的，不是某个百分比，而是同一个模型在“子任务”和“完整任务”两种口径下的落差。
行政基准的落差主要出在交接，临床基准的失败更分散
HealthAdminBench论文对“完整任务成功”的定义是：一项任务里的子任务要逐个通过，有一个没过就不算成功，而许多任务包含15个以上子任务。子任务通过率按检查项统计通过比例，只要每项任务里有一两处断点，完整任务就会失败，而检查项的通过比例依然好看。论文的失败分析指向跨步骤、跨系统的交接，HAI文章称之为“协调失败”：
- 查到的信息没带到后面。 HealthAdminBench的许多任务需要先在EHR里收集信息，之后在支付方门户或传真系统里使用。论文观察到，即使环境提供了可持久保存的记录区，智能体也常常没有记下关键细节，导致后续步骤出错。
- 文件操作被跳过。 论文对Claude Opus 4.6运行轨迹的分析发现，环境支持下载和上传，智能体却经常回避或忽略这些动作，相关子任务因此失败。
- 前面错了不回头。 人发现问题会回到前面的步骤修正，智能体很少这样做，往往直到耗尽步数预算。
PhysicianBench的失败更分散。论文把失败的检查点分为数据获取、临床推理、动作执行和文档四类，其中临床推理是最大的一类（GPT-5.5的失败检查点中占42.5%，Claude Opus 4.6占50.4%；HAI文章概括为“约一半”），论文据此认为多步临床判断才是主要瓶颈，而不是工具操作或数据获取。这类错误多是推理不完整，或方向对了却漏掉剂量、监测计划、安全提示等具体要素，明显的错误结论很少。动作执行类失败约占两成（GPT-5.5为19.4%），但以一种情况为主：写了，却没执行——智能体在笔记里写对了该下的医嘱，却没有在EHR系统里真正下单。
放到企业流程里，例如“CRM查客户信息 → 填内部表单 → 发起审批 → 到外部平台提交”，对应的表现可能是：CRM里查到的合同编号没进表单；审批需要的附件没上传；审批退回后，前面填错的字段没人回头改；智能体在对话里回复“已提交”，外部平台上却没有这条记录。这一映射是我们的类比判断，医疗基准本身没有测试这些企业场景。
作者的改进方向是推论，不是定论
HAI文章的作者认为，两项基准的主要失败都来自信息没能跨就诊、文档和系统传递，这“指向”改进智能体的架构和记忆（即更好的运行框架，harness），其作用至少不亚于换用更大的模型。
这是作者根据失败分析作出的判断，文章没有提供对照实验来证明改进架构与记忆的作用不亚于换用更大的模型。而且PhysicianBench论文自己的失败统计把临床推理列为最大类别，所以“主要失败来自信息传递”应看作作者对两项基准的综合判断，不是两项研究各自测出的共同结论。对企业来说，更实际的推论是：在决定“换一个更强的模型”之前，先检查流程中的交接是否被设计过。模型由厂商提供，交接怎样记录、动作怎样确认、出错怎样回退，则是企业和实施方能够直接控制的部分。
试点范围：按交接点数量收窄
很多企业的第一个智能体试点，会直接选一条横跨四五个系统的完整流程，理由是“这样才看得出价值”。按上面的失败机制，交接点越多，单步表现好也越难换来完整任务的成功，试点失败后也很难判断断在哪里。
选择首个跨系统试点时，可以先数清楚三样东西：
- 交接点：信息、文件或决定从一个系统、一个步骤传到下一个的位置；
- 每个交接点要带走的内容：能否列成一张明确的字段和文件清单；
- 结果在哪里可查：完成后能否在目标系统里看到记录、单号或状态变化。
首个试点宜选交接点少、清单列得出、结果查得到的一段流程，先让这一段端到端稳定跑通，再接上下一段。外部门户还要单独评估：HealthAdminBench论文说明，基准省略了多因素认证、验证码、会话超时等真实部署中的限制，真实平台上的操作条件通常比基准更复杂。
验收口径：完整任务为主，子任务分数用来找断点
跨系统流程的验收，可以把两类指标分开使用：
- 主要口径是完整任务完成率，并且以目标系统里的实际状态为准——单据是否生成、附件是否上传、状态是否变化，不以智能体自己的文字汇报为准。
- 同一批任务多跑几次。 PhysicianBench中单次完成46%、三次都完成28%的差距说明，跑通一次不等于稳定。试点验收应看同类任务重复运行时的完成情况。
- 子任务通过率用于诊断。 每个失败案例都标注断在哪个交接点、属于哪类失败（信息丢失、文件遗漏、未回头修正、写了没执行），据此决定改流程、改交接还是改权限。
样本怎样分为调试、保留和回归三类，以及谁有权放行和停止，已在智能体自主试错后怎样做评测与监督中说明，这里不重复。
中间交接怎样设计：让信息和动作都留下凭据
针对基准暴露的几类失败，跨系统流程中的每个交接点可以设计成四个显式环节：
- 交接记录：智能体从来源系统取得的关键信息，写入一份结构化的中间记录，写明字段、取值、来源系统和下一步用途。后面步骤从这份记录取值，而不是依赖智能体在长流程中“记住”。写入这份记录是流程强制的一步，下一步开始前先核对必填字段是否齐全；只给智能体一个可选的记录位置不够，HealthAdminBench已经提供了记录区，智能体仍常常不记。
- 文件清单：下一步需要的附件逐项列出，上传或下载被设为必须完成的步骤，完成后核对文件是否真的到位。
- 执行回读：每个“写入、提交、下单”类动作执行后，回到目标系统读取结果，拿到记录编号或状态才算完成。只写在笔记或回复里的计划，不计为已执行。
- 回退规则：后续步骤发现前面的信息不一致时，写清可以回到哪一步、最多重试几次；超出范围就停下，交给人处理。
前三项解决系统之间、步骤之间的信息传递；第四项涉及何时停下交给人。哪些判断必须由人做、转人工时交接包应包含什么，见企业把工作交给AI智能体，哪些判断必须留给人。
这些设计不保证流程跑通，但能让每次失败留下可定位的证据：是信息没进交接记录、文件没到位、动作没执行，还是规则没覆盖到例外。
远恒AI能协助什么
跨系统流程试点的难点，通常不在单个智能体的配置，而在于摸清现场的交接点：信息在哪里产生、被谁使用、靠什么确认。远恒AI的FDE企业AI落地陪跑进入企业具体部门，与业务负责人一起梳理流程、选定首个试点段落、部署知识与智能体，并在真实运行中记录错误、人工修改和断点，再决定是否扩展到更多环节和系统。任务只在一个岗位内闭环时，从单个AI智能体定制入手即可；两者的区别可参考FDE是什么，和咨询、培训、外包开发有什么区别。
涉及业务系统接口、私有化部署或特殊数据要求的项目，可根据项目组织联合评估与交付。试点进度和效果受流程复杂度、系统条件和团队投入影响，远恒AI不对完成率或见效时间作固定承诺。
准备试点一条跨系统流程的企业，可以预约企业诊断，并带上这几项信息：想先跑通的流程段落、涉及的系统、每个交接点需要传递的信息和文件，以及目前流程通常卡在哪一步。