用程序主控让WorkBuddy材料预审落地

把十几份材料交给大模型，让它读完、逐项检查、关联比对并生成报告，演示时很容易让人产生“已经可以自动办理”的感觉。真正连续使用时，问题往往出现在更细的地方：同一句话换个写法，提取结果会不会变；某份文件先处理完，后面的任务会不会及时接上；材料没有写的事情，模型会不会自行推断；换一个模型，整个流程还能不能照常执行。

在一个任职资格材料预审项目中，我们逐步把方案调整为：WorkBuddy承担业务交互和材料理解，本机程序管理案件、任务队列、事实校验、规则执行、进度和报告。 大模型继续处理中文语义，程序负责把每一步接成可检查、可保存的业务流程。

这里的“事实”，指从材料中提取、按统一字段保存，并附有原文出处的信息记录。例如，申请人姓名、拟任岗位、一段经历的起止日期，都可以成为事实；每条记录能够回到对应文件和原文位置核查。材料未记载、含义不明确或相互矛盾的内容，保留相应状态。这些记录反映材料写了什么，相关事项的真实性仍需按业务要求核验。

事实是“材料理解”和“规则审核”两大板块之间的交接数据。 前一板块由WorkBuddy和大模型理解文件，输出带出处的事实；后一板块由程序读取校验后的事实，执行规则并生成报告。例如，模型提取各段经历的日期和岗位，程序再按已确认的口径计算年限、检查是否满足要求。通过这一层交接，材料中的不同中文表达被整理为程序可读取的数据；已有字段满足规则需要时，也可以复用事实重新计算，不必再次阅读全部材料。

两轮完整实测使用同一批13份脱敏材料、四个原生材料助手，分别采用DeepSeek-V4.1-Flash和MiniMax-M3.1-Flash。两轮均保存13份事实JSON及13份表格文档，形成60项检查结果；从“开始审核”到最终回复分别为253.178秒和247.989秒。规则处理及报告生成的累计程序耗时约2秒，规则阶段未调用大模型。两轮仍有1项结论差异，这也提醒我们，流程可控以后，语义质量仍需单独验证。

多材料预审需要完成什么

这类业务的输入是一组围绕同一申请人的文件，例如申请表、申请说明、经历材料、资格证明、承诺文件和联系人材料。文件可能是Word，也可能是PDF；同一类材料可以分散在多个文件中，文件名也未必准确反映内容。

业务人员需要看到的是一份可以继续办理的结果：哪些材料已经提供，哪些文件尚未识别，哪条要求满足了，哪里需要补充，以及这些判断分别依据哪份材料。为了得到这份结果，系统需要逐份识别材料用途、提取事实并保留出处，再执行单材料和跨材料检查。

实际收件通常也不整齐。允许只提交一份或部分材料开始预审，后续在原任务中追加文件；已经保存的事实尽量复用，新增材料到达后更新受影响的规则和报告。另一名申请人的材料则新建任务，使用独立文件夹保存。

这里的“预审”有明确业务范围：证件图片只登记是否提供及材料种类，不识别图片文字或判断真伪；签名、印章和空白落款日期不作为本轮核验对象。需要计算基准日期时采用办理当天。预审结果用于辅助业务人员检查材料和定位问题。

早期问题集中在长流程执行

模型能够提取事实，也能按照提示词输出JSON、绑定证据、写入文件。但这些能力是否在每一次长流程中按约定执行，是另一个问题。早期实现让主专员承担较多安排工作，模型有时会按批次等待，或者在已经明确的操作之外增加读取、核对和解释。

一次历史四并发测试中，第一份材料保存到同一助手领取下一份材料，相隔124.81秒。拆开原生日志后，其中约120.34秒发生在主专员再次派发之前，接到派发后约4.48秒完成领取。另一组接续也出现了类似等待。四个并发名额存在，并不代表它们一直被有效利用。

中文语义也会直接影响规则结果。“材料没有记载某段经历”与“材料明确说明没有这段经历”含义不同；某项意见虽然没有独立标题，但正文可能已作出实质说明。如果为了适配这些变化不断往脚本里加关键词和例外，材料理解就会逐渐变成难以维护的穷举程序。

我们因此重新划分职责：中文内容交给模型理解；案件归属、任务次序、保存状态、规则计算和重试次数由程序管理。历史调度记录用于定位问题，后文两轮数据来自另一冻结版本，不直接用它们计算单一因素的提速比例。

程序主控与WorkBuddy的分工

功能架构与职责分工

图1　当前功能结构。架构示意图由AI辅助绘制，依据实际实现整理。

审核专员是业务入口，技能保存操作约定和事实提取要求，材料助手使用WorkBuddy中所选模型逐份阅读文件。本机程序通过MCP连接器提供收件、选项保存、任务领取、事实提交、进度读取和完成核对等工具。

这属于平台支持的扩展方式。WorkBuddy官方文档提供MCP与Skill接入方案，也支持专家声明所需MCP服务或连接器依赖。MCP解决应用与工具之间的通信，具体如何安排任务、使用模型和保存状态，仍由应用实现。WorkBuddy连接器文档、专家文档、MCP架构说明

“程序主控”也需要说明到执行层面：当前由程序决定待处理队列、可启动的执行位以及后续规则动作；WorkBuddy中的主专员依照技能启动原生材料助手，助手再持续调用领取和提交工具。程序并没有绕过平台直接调用所选模型或创建原生助手。因此，模型是否遵循工具操作约定仍会影响运行，程序主要把业务状态和关键决策从自由规划中固定下来。

业务人员只需按一条收件流程操作

业务操作以“一个案件一个文件夹、一个案件一个任务”为原则。业务人员收集材料后，在WorkBuddy中新建任务，选择预审专员、模型及推理程度，将材料文件夹选为工作空间，上传本次文件并发送“开始审核”。选择工作空间用于确定保存位置，待审核文件仍需明确上传到本次对话中。

机构类别和层级在收到材料、开始审核之后确认。它们会影响适用材料目录和规则，业务人员通常清楚这些信息，脱敏材料中的机构名称却未必足以支持模型判断。因此，程序生成同一张选择卡，由人员点选，程序校验并保存；随后自动继续办理。办理基准日期取当天，不再增加一次问答。

机构信息选择卡脱敏展示

图2　机构信息选择卡的已确认状态。原生界面截图经裁切和AI辅助文字脱敏，类别与层级名称已泛化；13份材料的数量及单选交互保持原意。

事实提取阶段，一个输入文件对应一个材料任务。四个材料助手从程序领取任务，生成候选事实后提交；程序校验并保存，再把下一份可处理材料交给已空闲的助手。各助手持续领取，减少等待整批完成后再由主专员安排下一批的机会。

每份事实保存后，程序执行当前信息已经满足的规则，更新本件结果和已有材料范围内的关联检查。缺少相关材料时显示等待或缺件原因，不把尚未执行的规则计作已经通过。最后一份材料完成后，核对实际保存数量并生成当前版本报告。

同一任务后续补入材料时，沿用已经确认的机构信息。程序保留原事实，按输入变化重新执行相关规则组，报告递增版本；一类材料需要多份文件时，逐份保留来源，并在材料提供情况中汇总对应文件。

固定流程需要固定的状态和校验

事实先成为可检查的数据

事实输出同时服务程序和业务人员：JSON用于规则读取，以表格为主的Markdown用于回查。每份结果绑定输入文件，事实记录保留字段、值及原文出处。模型不明确的内容保持未知，材料明确否定的内容才记录为否定。

程序校验集中在可以确定判断的部分，例如JSON能否解析、字段和类型是否符合约定、事实是否属于当前文件、引用能否对应本件材料，以及本次提交是否仍是所领取的任务。格式校验通过，表示数据可以按约定进入后续处理，不代表其中文含义已经被程序证明正确。

发现可修正问题时，程序返回具体错误，由当前助手定点修正一次；仍不满足要求则记录失败，保留候选和原因。语义不清楚时保留未知或冲突，不通过补关键词、填默认文本来制造完整结果。

规则读取事实，直接运行已有逻辑

规则阶段复用已有的确定性规则函数，直接读取现在保存的事实JSON，不调用原业务应用。材料齐全性、字段完整性、跨材料一致性以及已经确定的计算条件，由程序按版本执行。需要理解材料原意的部分，在事实阶段完成并保留依据。

报告展示规则编号、检查要求、当前事实及出处、结论和处理要求。业务人员可以从问题回到对应材料，维护人员也可以定位究竟是事实提取发生变化，还是规则实现需要修改。

历史业务口径允许部分信息不明确的事项默认通过时，结果单列为“按原规则通过，未核实”，与有完整事实支持的通过分开。这一分类在后文两轮统计中均保留。

进度直接来自程序状态

十几份材料需要处理几分钟，业务人员不能一直等待最后一句回复。程序记录每份文件的待处理、处理中、已完成或异常状态，右侧工作台读取这些状态，逐项展示发现和处理要求。已完成显示绿色，处理中显示蓝色，待处理显示灰色，异常显示红色；状态文字同时保留。

进度与结果控制面板

图3　第二轮完成后的工作台回读画面。原生界面截图经AI辅助裁切，展示13行材料及47／4／7／2的原统计；这是完成后视图，不能替代运行中逐项更新的日志证据。

右侧展示让业务人员在继续对话时仍能查看进度。报告通过原生文件产物入口查看，历史任务可以重新进入。后续显示修订还完成了应用重启后的回看核对，两轮原事实和报告保持原值。

日志需要同时回答业务和工程问题：文件何时领取、何时保存，哪一步失败，修正几次；采用什么模型、并发多少，规则耗时多少；工具调用、资源采样和平台频率限制是否出现。资源观察按5秒间隔采样，不需要为了刷新进度反复调用大模型。原文证据与诊断记录分开管理，对外分享时只导出必要的脱敏指标。

两种模型的完整实测结果

两轮测试于2026年11月5日在同一台macOS设备上完成，设备为10逻辑核、32GiB内存，WorkBuddy版本为5.9.3。流程与规则包固定为0.9.7，四个原生材料助手，分别使用DeepSeek-V4.1-Flash和MiniMax-M3.1-Flash。模型由WorkBuddy提供调用，设备参数不表示这些模型在本机推理。

样本是同一申请事项的13份真实业务脱敏材料，其中11份Word、2份PDF。每轮使用独立工作空间和新事实结果，未复用另一轮事实。正式计时前原件已放入输入目录，发送的启动要求只有“开始审核”；机构点选属于约定交互，运行中没有再补业务提示词。本次耗时不包含文件上传，测量的是原件就位后的办理流程。

“首次派发至最后保存”衡量事实阶段；“开始审核至最终回复”覆盖更长的用户等待窗口；界面显示值来自平台自身统计，起止口径不同。规则累计时间是每轮32次增量处理记录中的计时字段求和，包含状态核对、结果复用及报告生成，不是一次冷启动重算全部规则的基准成绩。

两轮需要补充的事项相同：一份申请说明缺少某项纪律情况审核意见，一份检查报告缺少已发现问题是否影响本次申请的说明。13份事实都成功保存，说明这两轮处理链路走通；60项形成结果，说明适用规则都得到了相应状态。

但两种模型只有59项结论一致。差异来自一项经历事实：一个模型根据履历中没有出现相关单位，填写为“没有这类经历”；另一个模型保留未知。回看原文，材料没有明确否认语句，因此不能把没有记载直接当作明确没有。

针对这个问题，我们加强了事实字段说明，要求明确区分“未见记载”和“明确否定”。历史结果没有人工改写；该提示修订尚未重新提取验证。这里的59／60表示两轮结论一致情况，不是人工标注集上的准确率。

本次发布资料同时提供脱敏实测数据文件，记录两轮统计、时间口径、32次增量处理的时间戳和耗时、两轮结论差异及验证范围。内部保留原生会话、原件指纹、事实文件、规则结果和报告之间的对应记录；公开资料不包含原始申请材料和个人信息。

模型变化以后仍需检查的部分

程序主控降低了模型在调度和规则执行上的自由度，维护内容也更容易定位：字段语义问题主要修改提取说明，业务口径变化修改规则，展示问题修改页面，案件历史问题修改存储及读取机制。这并没有消除材料解析和模型返回的不确定性。

两轮原生执行日志中，仍出现过把二进制文档直接交给文本读取工具、文本编辑找不到匹配内容等工具错误。助手在原流程中恢复，最终未丢失材料。评价稳定性时，既要检查完成数量，也要检查错误是否被记录、如何恢复以及有没有改错文件。

四并发是当前采用的运行参数。此前一轮六并发测试在保存9／13份事实时遇到平台频率限制而中断，不能作为完整六并发耗时成绩，也不足以证明四并发在所有设备和模型上最优。部署到其他设备后，应结合材料大小、模型等待、工具往返、CPU、内存及限流记录重新测试。

目前整文件替换的正式办理流程仍待专项验证；已经完成的增量补件不能直接等同于任意替换都可正确更新。机构选择、事实保存、规则结果和报告应作为不同环节分别检查，避免一个“任务完成”提示掩盖中间问题。

从这个实践保留下来的方法

对多材料预审这类长流程应用，模型的价值在于理解变化多端的材料；程序的价值在于保存状态、执行固定约束，并让每一次处理都能够检查和接续。两者之间需要清楚的数据约定和工具接口。

这次实践形成了一条可继续迭代的路径：业务人员明确收件范围和少量关键选项，WorkBuddy逐份提取带出处的事实，程序校验后执行规则、更新进度并生成报告。两轮约4分钟的整案处理、约2秒的累计规则处理，以及那1项仍需修正的语义差异，共同说明了这套分工的实际效果与下一步工作。

当大模型还不能稳定包办整条业务链时，应用仍然可以落地。关键是把模型擅长理解的内容交给模型，把必须按约定执行的业务过程交给程序，并用真实记录判断每一步是否做对。