一份保险单传进Box后，AI怎么把它分给对的人？

一份保险证明（COI）以PDF形式通过文件请求传进Box，项目的保险要求却躺在另一个文件夹里。系统要做的，是把两份文档里的关键字段都抽出来，判断这份材料该走哪条审核路径。

Box AI负责从两份文档中提取字段，应用把这些值存成上传文件的元数据，再把提取结果和文件名一起交给OpenAI Decisions API。后者回答一个封闭式问题：三套预设流程里，哪一套最符合现有证据？应用拿到选中的路径，并在路由规则里返回一个置信度。

上传一进入收件文件夹，Box V2 webhook就启动整个流程。应用创建一条带证据和理由的Box任务，指派给配置好的审核人，必要时把保险专员加为文件协作者。文档到达的地方和人来审核的地方，都是Box。

三条路径，每条都留一条审核任务

审核人由应用配置里的Box用户ID指定。走“请求批注”和“专员审核”这两条路径时，保险专员还会被加为上传文件的协作者。

Box AI提取的字段包括项目完成日期、要求的责任限额、记名被保险人、保单到期时间，以及附加被保险人证明。应用把这些字段和上传文件名作为共享上下文传给Decisions，固定的选项让应用能创建一条解释“这份文件为什么需要审核”的任务。

• 请求批注：创建审核任务，说明似乎缺少一份单独的附加被保险人批注；把专员加为文件协作者。
• 专员审核：针对证据缺失、不清晰或相互冲突的情况创建审核任务；把专员加为文件协作者。
• 可直接人工审核：创建一条供人工核对证据的审核任务。

如果路径不明确、不受支持，或者置信度低于应用设定的阈值，代码会把案件送到“专员审核”。任务里带着项目要求和提取出的COI字段值，给审核人一个可用的起点。

两个API各管一段

Box AI Extract把每份源文档变成一小组指定字段，Decisions API评估这些上下文并选出下一条工作流路径。Box SDK先调用结构化提取接口，请求里指明一个Box文件，并给出带提示词的字段定义。

数据同时来自项目要求和传进来的COI文档：前者从参考文档里提取，后者从上传文件里提取。接着应用拼出一段紧凑的文本输入，包含上传文件名和两份带键的提取结果，把这份证据连同选择题和三个允许值发给Decisions API。

选项里带着描述，说明每条路径何时适用。API返回的是一个带类型的选项，而不是一段需要应用自己解析的文字。应用先检查答案是否可用，套用置信度策略，然后才执行对应的Box动作。

应用核对完Decisions的结果，把最终路径映射成Box动作。每条路径都会创建审核任务；“请求批注”和“专员审核”还会把预设的保险专员加为文件协作者。任务消息给审核人提供打开源文档时的上下文。应用同时用企业元数据模板，把提取值和决策置信度写回上传文件。

跑起来需要什么

演示项目里包含几份虚构PDF：项目要求、一份不完整的COI、一份到期时间不清的COI、一份单独批注示例，以及一份完整的提交包。

运行这个示例应用需要：免费的Box开发者账号；在开发者控制台创建的服务器认证应用；应用中启用管理webhook权限；从开发者控制台生成的开发者令牌；从Box管理控制台复制的审核人和专员用户ID；一个OpenAI API密钥。Decisions API的模型默认是gpt-6-luna，配置演示时要查一下当前的OpenAI API指南，确认模型可用性和测试状态。

设置步骤是：克隆仓库，复制.env.example并填入值，包括Box开发者令牌、OpenAI API密钥、模型名、审核人和专员的用户ID。webhook处理是可选的，脚本可以手动触发，也可以由webhook处理器触发。本地跑webhook接收器时，要用公共HTTPS隧道把端口暴露出去，比如ngrok，并把BOX_WEBHOOK_ADDRESS设成以/box-webhook结尾的隧道地址。

还需要在Box网页应用里创建一个文件请求模板，它给用户一个简单的上传页面，把提交内容直接放进收件文件夹。这是唯一需要手动配置的步骤，因为Box API要求先有现成模板才能用程序创建新模板。想收集提交者联系方式的话，可以加一个邮箱字段。保存项目，从文件请求构建器URL里复制链接，填进.env的BOX_FILE_REQUEST_TEMPLATE_ID。

然后在终端启动虚拟环境、安装依赖，运行python seed.py。它会创建文件夹并上传演示项目的保险要求，创建新的webhook，创建元数据模板，创建新的文件请求并在终端返回链接，还会检查.env里定义用户的协作关系。

另开一个终端跑ngrok http 8000并保持运行。把BOX_WEBHOOK_ADDRESS设成隧道的HTTPS地址后再跑一次seed。如果文件请求是在第一次seed之后创建的，填上它的构建器ID再跑一次seed。用python demo.py启动接收器。

通过文件请求链接上传一份示例COI，Box发出上传事件，接收器把文件排队，依次执行提取、决策、元数据和审核动作。想在配置webhook投递之前走同一条处理路径，可以用手动触发并传入已上传文件的ID。终端里能看到提取字段和决策日志；在Box里打开上传文件，可以查看它的COI Intake Review元数据、活动面板、审核任务和专员协作关系。

示例PDF是虚构的，COI版式参考了常见的保险证明字段和得克萨斯州保险局的样例，但这些材料不是官方表单，也不构成实际保险的证据。

还能往哪扩

这个演示聚焦从收件到审核的路径，可以作为多种场景的样板，但它不是生产级工作流软件。真正部署前，要把事件和处理状态挪到持久存储，让重试变得安全，并加上监控，让失败或延迟的提交可见。

往下的扩展方向有几个：用Box搜索API查找现有的证书、批注或项目文档，只把相关匹配加入审核上下文，并在创建新的跟进任务前标记可能的重复；处理多文件提交，把一份COI和它的单独批注关联到同一项目和提交者，一起评估而不是每次上传都当成独立案件；把提取置信度当作另一个审核信号，与Decisions的路径置信度分开记录，关键日期或限额提取置信度低时就送审；记录审核人是确认还是改动了路径，用这些带标签的结果反过来打磨字段提示词、路径描述和置信度阈值；把“请求批注”接到邮件服务上，向文件请求收集到的地址发送一条经过审核的消息，附上补交缺失文档的说明。