智能体去代缴水电燃气：公用事业这类任务的失败面与对账
一、识别已经不是难点，收尾才是
据公开报道，有对话类应用被用户反馈可以通过语音或文字发起水、电、燃气等生活缴费指令，也有接近该厂商的说法提到其正在逐步建设出行服务、生活缴费等生活场景下的办事能力，此前已上线机票预订、火车票购买、打车出行与路线导航，用户用自然语言描述需求即可。产品名称、其底层接口、支付通路与资金安排，我们一律不做推断，也不在这里断言任何一家厂商已经具备或尚未具备某种能力。我们只把”缴费这件事被放进了代办入口”当成一个工程前提来讨论，因为它带来一类此前在对话式应用里不太常见的责任形态。
出行类任务失败了，代价是一趟改签；缴费类任务失败了，代价是一笔钱的去向说不清。差别不在金额而在状态的可解释权：账单有没有销掉、这笔钱缴给了哪一户、什么时候能退回来，这些事实全部记在对方系统里，本方看不到全貌，用户也看不到全貌。所以这类任务的真正难度，不在识别那句”帮我交一下电费”，而在失败之后钱和状态能不能对得上。我们把代办型任务的设计重心从”能不能理解并调用”移到”能不能收尾”上，下面讲的四类失败和对应的对账机制，就是按这个轴展开的。
二、四类失败，每一类都要落到具体动作
第一类，提交成功但外部系统未入账。表现为本方收到了成功回执、用户扣款完成，而账单状态没变。这类是最常见的，也是唯一一类不能靠”重试提交”来处置的——再提交一次就变成第二类。处置动作是查而不是发：按业务键去查询外部侧的入账状态，设一个查询窗口，窗口内保持”处理中”这一档对外说法，窗口结束仍未入账才转为异常单并走人工核实。这里的工程要点是”处理中”必须是一个真实存在的任务状态，而不是界面上的一句安慰文案。
第二类，同笔缴费被提交两次。来源有两条：用户重复发起（第一句没得到明确回应又说了一遍），网络或网关重试（同一次请求在链路上被送了两遍）。处置动作是在提交前建立唯一业务键约束，而不是在提交后靠对账发现。业务键的构成下面第三节说。这一类还要额外注意”发起”和”扣款”是两回事：用户在会话里改主意是常事，所以从发起到实际提交的这段窗口必须允许取消，且取消之后不能再有任何自动重试。
第三类，户号归属错误。用户口述的户号、历史缴费记录里的户号、以及当前实际居住的户号，三者可能不一致，智能体按”上次交过的那个”理解，钱就缴给了别家。这一类的处置动作是前置确认而不是事后追回，因为追回周期取决于对方流程，本方无法承诺时限。落到界面上就是一行硬约束：金额确认之前必须回显户名或户号的可辨识部分，让用户看一眼再提交。这一条会牺牲流畅度，但它是唯一把这类失败变便宜的方法。
第四类，金额构成不一致。余额抵扣、优惠活动、补贴、代扣渠道混用之后，实付金额、应缴金额与优惠金额三个数字之间的关系变得难解释。出问题时说不清”到底优惠了没生效还是渠道扣错了”。处置动作是把构成拆开记账：一笔记录里同时留应缴本金、各项优惠或补贴、手续费、实际到账渠道与实付金额，任何一项为空也要显式留空而不是合并成一个总数。
三、给每次代办建一张本地任务单
外部系统不给你台账，就得自己有一张。这张任务单是后面所有对账、追回、纠纷处置的唯一依据，它不是日志，是一份有终态的业务记录。字段我们按用途分三组。
标识与来源一组：任务标识、发起会话标识、指令原文（保留用户那句话本身，不做改写）、发起时间、发起人身份。指令原文这一项经常被当成调试信息而事后清理掉，但在争议处置时它是唯一能回答”用户当时到底说的是哪一户”的东西，保留周期要按业务需要单独定。
目标与金额一组：目标户号、户号来源（本次口述、历史记录还是常用列表）、账单期次、应缴金额、金额构成明细、优惠与补贴项、手续费、支付渠道与实付金额。期次这一项最容易被省略，但它是判定”这笔钱该不该销这张账单”的关键，缺了它，同户号不同月份的记录会互相污染。
结果与凭证一组：外部单号、终态、终态确认时间、留证材料（回执页截图或账单状态快照）、异常时的处置记录与人工接手的对话。终态要收敛到有限的几个值，并且规定哪些是”可对外承诺”的：钱已扣但外部未确认这一档，不能写成成功。
四、幂等与金额构成的记账口径
幂等的关键不在”防重复提交”这个口号，而在业务键选什么。缴费这类任务的天然键是户号加期次，但只有这两项还不够，因为同一期次可以分两次缴，于是再补上金额档位或用户确认序号。我们的做法是把用户的一次确认动作单独编号，业务键由户号、期次、本次确认序号三项组成，这样”同一句话重复发”会被压掉，而”用户确实改了主意再交一次”仍然放行。
提交前置占位是另一半。占位记录在真正调用外部接口之前写入，带一个明确的”已占位未确认”状态；外部调用返回后回填外部单号与终态。这样即使进程在调用中途崩溃，重启后也有一条待清理的记录，而不是凭空多出一笔没人认领的扣款。失败后的处置顺序固定为三步：先按业务键查外部状态，查到了入账就补记终态，查到未入账才决定是否重发，查不到就把这笔转为待核实并挂人工，绝不做”失败了就直接再发一次”。
金额构成要按四栏记账：本金、优惠或补贴、手续费、到账渠道。这四栏的意义在于它们各自对应不同的追索对象——优惠没生效要找活动方或渠道，手续费异常要找回支付通道，本金错缴要找公用事业方。合成一个总数，出问题时就只能整体挂起人工核。
五、对账节奏与三方口径
单靠一次实时回执是不够的，因为外部系统的账单销账有延迟，回执上的成功和账单上的成功不是同一个时刻。对账要按节奏来，而且要接受”有些笔当天就是核不平”这个事实。
| 节奏 | 核对内容 | 不平时的动作 |
|---|---|---|
| 当日核对 | 本方任务单与支付通道流水逐笔配对，检查已占位未回填的记录 | 差集挂为待核实，停止该户号的自动重发 |
| 次日补核 | 按业务键查外部账单入账状态，回填终态 | 仍未入账转异常单，通知用户实际状态 |
| 超期挂起 | 超过约定观察窗口仍未确认的记录集中处理 | 冻结同户号后续代办，走人工通道与留证提交 |
三方口径要提前写清楚，因为三方对同一个词的用法不同。本方看任务单的终态，支付通道看扣款流水，公用事业方看账单是否销账。这三样在时间上必然不同步，所以差异记录要有一张固定的比对表：同一笔钱在三个来源里各自的状态与时刻，缺哪一侧就标缺，而不是等出事时临时拉数据。这里有一条纪律值得单说：对账差异不能用”金额相同就算同一笔”来收敛，金额相同的两笔缴费在实务里并不罕见，必须靠业务键来配对。
六、责任告知与两份交付物
代办型任务的授权范围要写明白，不能靠用户在一段同意文本里点一次。哪些动作必须人工确认才执行——我们建议把首次出现的户号、金额超出历史区间、以及任何带抵扣或退款含义的操作都放进这一档；代扣授权的范围边界与撤销入口要能被用户自己找到，找不到就是埋雷。凭证留存期限要按业务需要说明：留得太短，追索时没有依据；留得太长，指令原文与户号这类个人信息留在系统里的风险敞口变大。这两侧的取舍要显式写在设计文档里，而不是默认继承某个日志保留策略。
核心交付物是两张表。第一张是代办型任务的本地任务单字段表，按上面第三节的三组字段展开，标出必填项、终态取值集合与保留期限，它是这张单子能否被用来对账的前提。第二张是四类失败的处置与对账节奏表，也就是第二节四类失败乘以第五节三档节奏的交叉表，每一格写”谁去做、做什么、多久内做完”，它决定异常发生时团队是按表执行还是临时开会。
这两张表在洹拓的事务型代办项目里是同一个用途：让智能体的能力边界由对账能力决定，而不是由调用成功率决定。调用能不能发出去是接口问题，钱和状态对不对得上才是代办问题。一个入口如果只能给出”我已经帮您提交”这句话，却给不出这笔钱现在在哪个系统的哪个状态里，那它做得再顺手也只是把纠纷发生的位置从界面挪到了客服。