最近在梳理一个办公 Agent 的文件验收流程，翻着翻着发现一个特别有意思的现象：模型在很多测试用例上已经答得相当漂亮，字段抽得又准又全，可一旦放进真实业务链路里，任务照样被判失败。不是模型不聪明，是验收这一关把任务卡在了“完成”之外。
这件事让我想了很久。做文件类 Agent 的朋友应该都有同感：模型说对了，和任务做完了，中间隔着一条巨大的沟。沟里有什么？有格式校验、字段边界、文件命名、类型转换、业务规则、人工复核、异常兜底……模型只负责其中一小段，而验收流程负责把整条链路兜住。今天就把我读这套验收流程时拆出来的东西，原原本本写下来。
1. 先搞清楚：文件验收到底在“验”什么
办公 Agent 最常见的落地场景，是处理结构化的业务文件：发票信息抽取、合同要素归档、报销单据录入、客户资料整理。用户上传一份 PDF 或照片，Agent 把里面的关键字段识别出来，填进表单或写入数据库，任务就算完成。听起来很简单，对吧？难点恰恰在“任务完成”这四个字上。
我见过不少初版实现，把验收逻辑简单写成“模型抽取结果和标注答案对不对”。字段比对了、准确率算出来了，上线却发现大量任务在真实用户手里根本跑不通。原因在于，验收的从来不是“模型回答的质量”，而是“交付物能不能被下游业务直接消费”。
文件验收的本质，是回答三个问题：文件有没有被正确处理？输出字段是否完整且合规？结果放进业务系统里是否安全可用？这三个问题分别对应三层校验：输入层、内容层和业务层。
输入层管的是“文件本身能不能读”。扫描件清不清楚、PDF 有没有乱码、多页文档有没有被截断、表格线识别是否完整。这一层如果出问题，模型再强也是白搭。
内容层管的是“抽取出来的字段对不对”。字段有没有抽全、值是否符合目标类型、日期格式是否统一、金额精度是否合理。这一层是大家最熟悉的部分，也最容易产生“模型答对了”的错觉。
业务层管的是“结果能不能直接落地”。字段之间有没有互相矛盾、主键是否重复、权限字段是否越权、单据状态是否允许当前操作。这层往往被忽略，却是真实业务场景里最容易被判失败的地方。
一句话总结：文件验收不是考试，是质检。模型负责把答案写出来，验收流程负责判断这张答卷能不能进档案袋。只盯着“答对”，本质上跳过了一半流程。
2. “模型答对”的三个层次：内容、结构、业务
把“答对”这件事掰开揉碎了看，其实有三种完全不同的层次。大多数团队卡在“感觉自己做完了”，就是因为只验证了第一层，却误以为三层全部通过了。
2.1 内容层：语义是对的，但字段边界错了
内容层出问题最典型的形态，是“模型提取出了一段包含正确答案的文本，但字段边界切错了”。举个例子，某项目要做证件信息抽取，模型在“住址”字段里输出了“北京市朝阳区某街道”，看起来没问题，但实际业务系统里地址字段需要拆省份、城市、区县三级结构，街道应放在详细地址字段。模型答的内容没错，但字段归属错了，下游数据统计直接乱套。
这种问题在初版效果评测里几乎显不出来。测试集标注往往只关心“关键词有没有被抽到”，很少关心“抽取字段是否与业务字段一一对应”。等数据进了数仓，分析师问“北京用户有多少”，结果发现一半用户的省份字段里存了“北京市朝阳区”，一半的区县字段存了“北京市朝阳区某街道”，数据彻底报废。
2.2 结构层：值是对的，但格式不合规
第二层更隐蔽：模型抽取的值在语义上完全正确，但格式上不符合系统要求。我用通讯录导入场景举过例子——模型把手机号抽出来了，看起来是“138****5678”，但业务字段定义的是整数类型，模型输出的是带空格的字符串“138 5678 5678”，入库直接抛异常。
类似的情况还包括：金额字段需要精确到分，模型输出“100.0”导致精度丢失；日期字段要求 yyyy-MM-dd，模型输出了“2024年3月1日”；性别字段枚举只有男/女，模型输出“M”；表格采集场景里，数值列混入文本描述“约500元”。每一个单独看都是小问题，但叠加在一起，就变成“模型自认为答对了，任务却被系统拒绝执行”。
结构层校验的核心思路，是把“值合法”和“值合规”分开判断。合法是模型侧的逻辑，存储在类型、长度、非空层面；合规是业务侧的逻辑，附加在格式、枚举、范围、精度层面。这两层校验必须各过各的，不能混在一段规则里写死。
2.3 业务层：格式是合规的，但业务规则不通过
最让人头疼的业务层问题，是格式挑不出毛病、字段也都齐整，但整份数据在业务语境里说不通。举几个我做过的项目里实际碰到的类型：
- 同一单据里“报销事由”写着“出差”，但“城市”字段填的是本地城市，业务规则要求出差城市必须是外埠。
- 合同编号字段唯一性校验失败，两条记录主键冲突，典型原因是模型把旧合同里的编号重复抽取了过来。
- 金额校验失败，明细行累加总额和发票总金额对不上，差值恰好是税额。
- 状态流转非法，模型抽取的单据状态是“已审核”，但系统对该用户只开放了“待提交”权限模板。
这类问题的特征很一致：任何单个字段都合规，字段之间的依赖关系或权限上下文不满足。模型在语义理解上没犯“错”，却在业务逻辑上没做“对”。这也是为什么验收流程必须有业务规则层，不能只看抽取效果。
| 层次 | 校验重点 | 典型失败例子 |
|---|---|---|
| 内容层 | 字段边界、语义归属 | 地址字段拆分错误 |
| 结构层 | 类型、格式、枚举约束 | 日期格式不统一 |
| 业务层 | 字段依赖、权限、唯一性 | 明细金额与总额不平 |
3. 一套可落地的文件验收流程，应该怎么拆
明白了“验”什么，下一步就是设计流程本身。我读到的这套流程很有意思，它把整个验收拆成了四个连续的环节：前处理验收、解析层验收、输出层验收、闭环验收。每个环节对应不同的检查项和不同的失败处理策略。
3.1 前处理验收：文件能读、能解析、不乱码
第一步永远不是让模型去抽。先把文件本身过一遍质检。前处理验收关注几个硬性指标：
- 文件格式是否符合约定（pdf、jpg、png，有没有发成 docx 或压缩包）
- 文件大小是否在允许范围（太大可能截断，太小可能空文件）
- 页数是否与业务预期一致，多页文件是否完整接收
- 扫描件是否清晰到可供 OCR，图像分辨率是否达标
- 编码是否正确，中文 PDF 是否出现乱码或字体缺失
这一步的原理很简单：Agent 识别结果的质量上限，取决于输入图像/文本的质量下限。一个模糊到人眼都看不清的扫描件，模型能抽出内容纯属运气，不能作为验收依据。所以前处理有问题，直接走“重新上传”的分支，而不是进入模型环节。
我做过一个项目，某批单据的照片有些是用手机斜着拍的，透视变形严重。前期没加前处理校验，模型识别率惨不忍睹，后来加了“清晰度检测+方向校正+自动裁边”的预处理链路，识别率直接提升了近二十个百分点。前处理这关不是可选项，是必须项。
3.2 解析层验收：字段抽取的完整性与可枚举校验
文件过完前处理，才轮到模型介入。解析层验收的核心，是保证抽取结果“完整且自洽”。完整性检查包括：必填字段是否都有值、选填字段是否符合条件出现在该出现的位置、多页文件是否有字段被漏抽。
可枚举校验则要求：凡是业务上枚举值固定的字段，必须校验模型输出是否属于定义好的枚举集合。比如证件类型必须是身份证、护照、驾驶证三选一；优先级字段必须落在高、中、低三档内。这一招能挡住大量“模型自由发挥”的问题。
还有一个细节，模型往往会输出额外的解释性文本。真正做文件抽取时，必须让模型按照固定 schema 返回，不能带任何废话。我在验收规则里见过一个很实用的配置：不仅校验字段值，还校验输出 key 是否严格匹配目标 schema，多一个 key、少一个 key 都判定为解析失败。这种方式牺牲了一点点灵活性，换来的却是下游消费绝不会踩到“多字段”的坑。
3.3 输出层验收：模板渲染、字段映射与文件命名
解析没问题，后面还有一个大坑：输出。输出层验收的是 Agent 生成的成品文件是否合规。我遇到过的真实案例包括：
- 模板渲染错位，字段值插到了错误的位置，表格行错位
- 导出的文件命名不符合约定，含非法字符，或缺少业务单号
- 多字段拼接错误，比如姓名和身份证号被拼到一个单元格
- 编码问题，导出的 CSV 用 excel 打开乱码
很多开发同学以为“模型把字段抽对了，任务就成功了”，其实对于办公场景来说，真正交给用户的是一条完整交付物，文件本身不合格，字段再对也没用。输出层验收应包含：模板渲染结果抽样检查、文件名规则校验、编码转换验证、分页与打印效果检查。
3.4 闭环验收：提交回执、人工复核队列与失败重试
最后一个环节，是验证整个任务是否真正“闭环”。这里的检查点包括：任务状态是否从处理中变为已完成、提交回执是否生成并写回系统、失败路径是否进入了人工复核队列、重试机制是否生效。
闭环验收里有个容易被忽略的点：失败重试不能无限循环。通常做法是设置最大重试次数，比如三次，超过之后强制转入人工复核。三级重试加上人工兜底，既保证系统有一定自动化容灾能力，又不会让异常任务无限挂起占用资源。我见过有项目没做这个限制，某个失败任务在队列里重试了上百次，既浪费算力，又让真实用户苦等，体验极差。
4. 实测踩坑记录：模型答对了却依然翻车的真实场景
光讲框架有点虚。把我在实际项目中踩过、以及从这套验收流程里拆解出的典型问题，一个个列出来，每个都是“模型答对但任务失败”的活教材。
场景一：多页扫描件里，字段被抽到了错误的页码
多页合同场景。模型识别总金额时，把第二页“费用明细”里的分项金额当成了总金额，字段值本身合法，格式也对，但业务上明显不合理。单机评测不会暴露这种问题，因为测试集多半是单页或已切片的数据。真实上传的多页扫描件没有切片，模型要自己决定从哪一段取数。结果就是：答对了“某一处金额”，但答错了“业务上要的那个金额”。
解决方案是解析层增加“页码定位校验”，让模型输出来源页码，与业务规则约定的字段所在页码区间做比对。页码不匹配直接降级为低置信度，进入人工复核。
场景二：同一个字段在文档中出现多次，模型取错了实例
表格型单据最典型。一张表里有“上期余额”“本期余额”“期末余额”三列，模型抽“期末余额”时，因为表头识别错位，取成了“本期余额”。值单独看是合规的，但语义完全错误。这种错误的关键在于，模型可能把概念理解对了，但落到具体表格坐标时发生了偏移。
解法是在验收规则里加入交叉校验，比如期末余额是否等于本期余额加减发生额。一旦等式不成立，直接判定业务层失败。规则比模型更可靠，能用规则校验的地方就不要依赖模型自我纠错。
场景三：数字识别正确，但类型映射错了，下游直接炸
某个项目里，模型正确识别了“金额”字段为 1200.50，但输出类型是“含千分位逗号的字符串”，类似“1,200.50”。入库时，下游系统按数值类型解析失败，任务在最后一公里被拦下。你问模型答对了吗？内容对，格式错。
修复方式很简单，在解析层做严格的类型转换和类型校验。定义该字段为 decimal，那么值必须能够被转换，且转换后满足精度要求。转换失败的字段直接判失败，不要用正则强行清理，因为不同业务场景下的清理规则不一样，写死了反而误杀。
场景四：日期格式五花八门，入库校验被拒
单据上的日期形态太多样：有的“2024年3月1日”，有的“2024-03-01”，有的“2024.03.01”，还有的是“3/1/2024”。模型每次都不同方式抽取，格式校验怎么可能通过？
这块我的体感是：必须在提示词里就强制输出标准化格式，而不是靠验收阶段硬转。提示词里明确写“日期必须输出为 YYYY-MM-DD”，同时在解析层校验正则。两道坎下来，格式问题基本绝迹。验收流程再完备，也不如把约束前置到模型输入阶段来得省事。
这些坑背后的共性，是“只验收模型输出，不验收交付物”。一旦把视野从“答得对不对”扩展到“任务跑不跑得通”，很多问题其实是可以预判和前置规避的。
5. 把“答对”推进到“完成”的验收设计经验
最后这部分，把我从这套流程里总结出来的设计经验，以及实际操作中沉淀的有效做法，一次性写清楚。
5.1 验收规则分级：必查项与警告项
不要把所有校验项一视同仁。一套合理的验收规则应该分两级：必查项和警告项。必查项包括必填字段完整性、类型可转换性、枚举合法性、业务主键唯一性。这些项一旦失败，任务直接终止，进人工复核。警告项包括置信度偏低、抽取来源页码非预期、文本长度偏离常见范围等。警告项不阻断任务，但会在结果里打标记，便于下游必要时做人工抽检。
分级的价值在于，避免用“一刀切”的严格性把近乎正确的任务废弃，也避免用宽松规则放过真正的问题。还可以减少对模型不必要的降级处理，保证自动化率。
5.2 置信度阈值与验收失败要联动
很多文件抽取 Agent 会给每个字段输出置信度。但只输出不行动，等于没做。设计时要让置信度参与验收决策：高置信度但业务校验失败，重点查规则配置是否有冲突；低置信度但规则全过，不要直接放行，建议加入人工抽检队列。
我常用的做法是设置双阈值：高阈值以上直接通过，低阈值以下直接进人工，区间内以规则校验结果为准。实测这种方式能有效平衡自动化率和准确率。但要注意，阈值调节需要基于真实业务数据分布，不能凭感觉拍。
5.3 失败要快，兜底要稳
验收最忌讳的是把失败任务挂在队里迟迟不处理。正确姿势是 fail fast：前处理失败立即返回重新上传，解析失败立即转人工，重试超过次数立即告警。快失败可以节省算力和用户等待时间。
兜底机制同样重要。人工复核队列要设计得轻量清晰：展示失败原因、原始文件切片、模型抽取结果、差异对比，复核员一眼就能判断。这个界面做得好不好，直接影响人工介入的效率和准确率。很多项目忽略了这个环节，结果复核员还得开原始文件自己找字段，效率极低。
5.4 验收日志必须能解释“差在哪一步”
一个经常被低估的工程细节：验收流程要留下结构化日志。记录每个任务在哪个环节失败、命中了哪条规则、当时的置信度是多少、重试了几次。没有日志，后续调优就是盲人摸象。
日志粒度最好到字段级。比如“金额字段抽取值 1200.50 违反 decimal 精度校验”，比“任务失败”有用一百倍。基于字段级失败日志，可以快速统计哪些字段最容易出问题，然后针对性优化提示词或规则，而不是面对一堆模糊的任务失败记录发呆。
5.5 给验收流程留“逃生口”
再完备的规则也会有疏漏。所以验收流程要设计逃生口：当任务反复失败但人工复核确认结果是正确的，允许操作人员强制通过，并记录原因到日志。这个操作要留痕、要可审计，但不能因噎废食。强制通过机制本质上是对验收规则一种“在业务运行中自我修正”的补充。
5.6 验收流程本身要迭代评测
验收规则不是写一次就完事。它和模型一样需要迭代，需要评测。我在实际项目里会留一个“规则回归集”：选取一批典型业务文件和对应的正确验收结果，每次改动验收规则之后，先跑回归集，确认改动不会增加误杀或漏放，再上线。
这个动作很像测试里的回归测试。没有它，验收规则会越改越乱，要么过于宽松，要么过于苛刻。拿到一份好的验收流程，先别急着跑模型，先跑规则回归集，确认规则本身可靠，再谈业务自动化。
回到最初那个标题。我读完后最大的感受是，做办公 Agent，永远要把“任务完成”定义在“交付物可用”而不是“模型答对”上。模型是整个流程里最聪明也最不稳定的元件，而验收流程是给它兜底的管线。聪明的模型加上稳的验收，任务才能真正完成，并且是稳定地完成。
如果你做的是类似的文档类 Agent，建议现在就把验收流程画出来，逐个环节确认：文件能不能读、字段有没有漏、格式合不合规、业务通不通。你会发现，堵住这些环节的漏洞，比单纯优化模型效果监督指标，带来的实际提升要明显得多。
