一页合同先抽 5 个字段:腾讯云文档抽取 Agent 的首测流程

合同、票据、运单最磨人的地方，往往不是“看不懂”，而是每次都要把同样的信息抄进表格：合同编号、甲乙方、金额、日期、收款信息。把文件直接扔给 AI，最怕的也不是它慢，而是某个金额、日期或主体抽错后悄悄进了台账，等对账时才发现整批要返工。

腾讯云文档抽取 Agent 版提供实时和异步两条接口，产品页标注 0.19 元/页起，并支持用字段级 Prompt 调整抽取方式。第一次不要拿几十份正式合同验证“它准不准”。拿一份脱敏样本，只抽 5 个能人工核对的字段，先跑出一条提交—查询—复核的闭环。

这篇按文档和 API 示例整理的是 L2 Documented 首测流程：操作路径以当前官方文档为准，未在本文环境中调用真实付费接口；合同和票据里的敏感数据也不应直接拿来做公共演示。

这次只完成一件事：把一页样本变成一张可复核记录

准备材料不要复杂：一份已脱敏、最多一两页的 PDF 或图片；一张空白表格；以及 5 个字段的验收清单。以合同为例，可以用：合同编号、甲方名称、乙方名称、含税金额、签署日期。

为什么先选 5 个？因为你能在一分钟内人工对完，也能看出错误属于哪一类：没识别到、识别到了但字段归错、金额小数点错、日期格式不一致，还是模型把相近文本猜成了答案。先把错误分出来，之后才知道该改字段提示词、换样本，还是回到人工录入。

脱敏并不只是把公司名打码。合同号、手机号、地址、银行账号、身份证号、印章、签名和完整金额都应替换成测试值或遮挡；保留版式、表格、页眉页脚、金额位置等影响识别的元素。这样测到的是流程，而不是把真实业务资料暴露给一次试用。

第 1 步：选对接口，不把长文档当成即时问答

如果样本是长文本、输入输出预计较长，或者可以接受超过 30 秒返回，使用异步文档抽取 Agent 的流程更合适。它不是“点上传马上得到答案”的交互：先提交任务 SubmitExtractDocAgentJob，再用 DescribeExtractDocAgentJob 查询结果。

开始前准备腾讯云账号和文字识别服务的调用权限。接口请求域名是 ocr.tencentcloudapi.com；官方还给出了 API Explorer，可用于在线调试、查看请求和返回结构。第一次可优先在 Explorer 中填参数，不必先写业务脚本。

文件可以用 ImageBase64 传入，也可以提供 ImageUrl。文档中列出的格式包括 PNG、JPG、JPEG、BMP、PDF；Base64 编码后不超过 10MB。若用 URL，先确保链接可访问，下载时间不超过 3 秒。样本先控制在一页，别在文件上传环节就引入网络和分页变量。

第 2 步：把字段写成“名称 + 解释”，而不是一句“帮我提取合同信息”

接口的 ItemNames 用来传自定义字段名称、字段类型和字段提示词。字段名不是越多越好，提示词也不必写成长篇说明；关键是把容易混淆的含义说清楚。

可以先按下面的逻辑配置，字段值仅是示意：

这里有一个很实际的费用边界：异步接口文档说明，自适应价格在抽取字段大于 10 个时记两次费用，小于或等于 10 个记一次。首测只放 5 个字段，既方便人工复核，也不会因为一次“想多拿一点数据”把试验变量和计费变量同时放大。

字段提示词的作用不是替你判断合同真假，而是告诉系统“同一页上多个数字、多个日期、多个主体时，哪一个才是你要的”。如果样本里有付款日期、到期日期、签署日期，不要统称“日期”；给每个字段单独描述。

第 3 步：提交后先保存 JobId，不要把“已发送”当成“已抽完”

调用 SubmitExtractDocAgentJob 后，返回中会有 JobId 和 RequestId。把两者连同样本名称、提交时间、字段版本写进测试表。JobId 用来查询任务，RequestId 则是在异常时定位一次请求的线索。

建议测试表只有六列：样本名、字段版本、JobId、提交时间、结果状态、人工复核结论。此时先不讨论准确率，也不急着上传第二份文件。你只需要确认一件事：任务是否被创建，能否在后续查询中拿到可读结果。

第 4 步：查询结果时，用原件逐格比，不要只看“看起来像对的”

用查询接口取回任务结果后，打开原始脱敏样本，把 5 个字段逐格对照。每个字段只能填三种状态：正确、缺失、错误。不要用“差不多”通过金额、主体和日期。

金额重点看币种、小数点、含税与未税的表述；日期重点看是哪一种日期；主体名称要看是否少了分公司、括号或关键限定词。哪怕这次只是练流程，也应把错误原文和返回值并排记下，方便下一轮只改一个变量。

如果 5 个字段都正确，再拿第二份不同版式的脱敏样本复跑一次；如果只有一个字段错误，优先改这一项的 KeyPrompt，不要立刻增加十几个字段或更换整个模型。两份样本都通过，才说明这套字段定义值得进入小批量验证。

复跑时保留上一版字段提示词，不要覆盖。给每一版加上 v1、v2 这样的内部标记，测试表里同时写下“改了什么、为什么改、结果是否变好”。这样遇到结果回退时，能立刻回到上一个可用版本，而不是凭记忆重写一遍提示词。

第 5 步：把“成功”定义成可交接，而不只是接口有返回

首测成功，不是屏幕里出现了一段 JSON，而是同时满足四个条件：任务能提交；能凭 JobId 查到结果；5 个字段可在原件上逐项核对；错误能被明确记录和复现。

达到这四项后，再把输出接进表格或业务系统。第一批仍建议保留人工复核列，不要直接用抽取结果覆盖原数据。接口的价值是把反复抄写变成“机器先填、人只核关键项”，不是把责任一起转走。

若两份样本的关键字段都稳定，再扩到 10 份；仍只保留相同 5 个字段。此时可统计每个字段的正确、缺失和错误次数，并记录每页实际费用。等字段定义和版式范围稳定后，才有资格讨论批量跑多少、是否用异步接口、是否扩充字段。

遇到这些情况，停在小样本阶段

样本包含未脱敏的合同、票据或个人资料；金额和主体等关键字段无法人工核对；同一个字段在两份样本中反复错但原因不明；或者你还没核实计费方式就准备一口气上传大量文件——这些都不适合继续放量。

先退回到一页、5 字段、两份样本。把字段提示词和原件对照修清楚，再复跑。对合同、票据、运单这类资料来说，最省时间的路径不是最快批量，而是先把“机器填什么、人核什么、错了怎么留痕”做成一张固定表。