Quadient推出应收邮件Agent：一封邮件涉及多张发票，怎样分拆处理？

Quadient于2026年10月14日宣布推出AR邮件Agent，公告称可分拣邮件与工单，分类付款承诺、发票问题和争议，并在其AR平台准备相应动作。开放范围为现有Quadient AR客户全球可选启用；组织决定启用哪些动作和人工介入位置。公告与发布事件日期均为10月14日，本次核验为10月15日。

公告没有给出任意多意图、多发票识别的验证结果，也没有说明来信即可完成银行对账或核销。本文的候选表、混合来信与故障演练均为本站设计，不是对产品的实测成绩。

对负责企业AI试点的人，可从来信中最容易混淆的对象关系开始：一句话指向哪位客户、哪张发票、什么请求，以及能从哪段原文确认。先把这些关系查清，再决定是否接入后续执行。

以Microsoft Graph v1.0的邮件资源为字段例子，bodyPreview只包含正文前255个字符；body是正文，uniqueBody表示本条邮件独有的正文部分且默认不返回，需要显式获取。只用列表摘要做分类，长邮件尾部的第二、第三个意图可能根本没有进入输入。这里引用的是邮件资源文档，不是在说明Quadient的底层实现。

本站建议保留接收记录标识、邮件版本、本次正文位置、被引用邮件的来源和附件读取状态。uniqueBody等字段可以辅助定位，仍要能回查完整原文；自动提取出的正文边界需要用自己的邮件格式验证。

教学输入：客户C-017的当前正文写道：“F-101预计10月20日安排付款；F-102数量和我们的记录不一致，请核查；请补发F-103对应的发票PDF。”下方引用一封10月8日的旧邮件：“F-101已提交付款申请。”客户、编号、日期和文字均为虚构样本。

本轮只读取允许的测试资料、形成内部草稿，不发信、不改收款或争议状态。为三项分别保存原文位置，形成以下候选表。

三条记录至少包含候选标识、客户与发票定位、意图、原文位置、条件、当前核对结果和拟议下一步。字段名称由团队定义。邮件接收成功只说明拿到这封信；候选提取完整、对象定位正确与业务处理完成分别记录。

不要让“客户付款意向”成为覆盖全部发票的状态。某张发票的争议是否影响催收、如何影响，应交给相应业务规则核对；本例只保留争议范围，不自动对整位客户作统一变更。

本篇只演练逐项解析。需要接入实际写操作时，复用现有审批、幂等与状态合同；缺少这些条件时保持草稿用途。这样可以先判断信息是否被正确理解，再决定扩大能力。

每个场景从独立的虚构邮件和测试对象开始，固定同一配置。下面是预期检查点，需填写实际候选项、原文位置和对象记录；本网站没有运行这些产品测试。

演练结束后逐项数清该保留的意图，而不是只看邮件大类命中。检查原文依据、对象归属、时间和限制是否对应。模型输出更多条目也不自动更好：无原文支持的新增动作同样是错误。

客户可能在下一封邮件修正日期或补充发票号。把修正关联到原候选项，并记录新旧依据；不能用线程里最后一段文字批量覆盖所有项目。历史引文、转发内容和当前更正的来源分别保留，无法判断时列出需要确认的片段。

同一封邮件重复交付时，先找原接收记录与候选项；重复文本和客户后来改变意图是两种情况。后续若已有业务提交但响应丢失，查询原动作的权威状态，不因为邮件再次出现就重做。具体幂等与未知结果处理见延伸指南。

先准备几封虚构混合来信与测试客户、发票映射，完成三项拆分和六个反例。验收记录至少说明哪项漏了、串到了哪个对象、依据是否来自本次正文，以及实际输出仍缺什么。若中文表达、邮件格式或附件类型未覆盖，就保留限制，不用厂商公告替代自己的样本结果。

需要梳理企业AI／FDE试点时，可以带上脱敏来信、对象关联方式和只允许内部草稿的动作清单，与AI随心创沟通。不要提供真实客户发票、私密邮箱凭证或支付资料。