一个容易被划过去的细节

千问Go! 在 2026 年 10 月 13 日官宣时，官方给的能力清单里有这么几项：查询航班延误信息并与平台客服交涉、提交理赔申请；翻查符合价保条件的订单、申请退还差价；此外还有演出场次与场馆预约、餐厅筛选预订、汽车保养预约、商品比价下单、求职投递。

演示金额是两个很小的数字：一笔 70 元的航班理赔款，一笔 52 元的淘宝价保退款。

我第一次读到时没当回事。后来把国内外十几家的首发场景排成一列看，才反应过来这个选择有多不寻常。

所有厂商都在演示「把钱要回来」，而不是「把钱花出去」。

OpenAI 的 Agent 能做购物，但它的招牌演示是研究、报表、跨应用协作；Manus 的招牌是信息型任务。真正把理赔、价保、退差价当成第一枪来打的，是中国区这一批。

为什么？我的答案是：因为正向交易已经没有技术含量了。

一、正向交易与逆向交易，差的不是难度，是系统性质

下单是什么？标准化的正向流程。意图明确、参数固定、对手方有强烈动机让你成功。这种流程任何一家平台都会做成 API，因为它自己也要用。

退款和理赔是什么？

• 对手方有明确的拒付动机。航空公司不想赔，商家不想退差价。
• 判定依据是条款解释，不是数据字段。同样一段延误，能不能赔、赔多少，取决于条款怎么读、你怎么主张。
• 通道没有标准接口。你不会看到哪家航司开放一个 `POST /refund/approve` 给第三方 Agent 调用。
• 结果需要事后核验。对方说「已为您提交」和钱真的到账，是两件事。

所以这不是自动化问题，是博弈问题。

这个区分对架构的影响很大。自动化系统的正确抽象是工作流引擎：状态确定、动作幂等、失败可重试。博弈系统的正确抽象是带对手模型的状态机：每一步的输入来自一个可能撒谎、可能敷衍、可能给你设话术陷阱的对象，而且你的动作会改变对方的策略。

用一个更工程的说法：逆向履约的每一步都是不可信输入下的部分可观测决策。 你熟悉这个句式的话，就知道它跟 RPA 完全不是一类问题。

图 4  逆向履约任务的有限状态机与多通道降级

二、把它建模成状态机：七个状态，两个必须显式标注的点

我给这类任务画了一版参考状态机。先说清楚：这不是任何厂商披露过的实现，是我按公开描述的能力清单反推出来的合理结构，你要拿去用可以，但请当成讨论稿。

S1 意图确认。 这一步最容易被跳过，但它是整个系统的安全阀。必须在这里固化三个参数：单笔金额上限、日累计上限、可接受结果区间。

「可接受结果区间」这个词值得单独讲。用户说「帮我把这笔差价要回来」，那么退 52 元算成功，退 30 元代金券算不算？要不到怎么办，走不走投诉渠道？这些必须在任务创建时定死，作为参数传给执行器。

绝对不能让模型在执行过程中自行放宽这个区间。 后面第五节我会讲为什么这条是红线。

S2 证据采集。 订单号、支付时间戳、条款快照、延误证明、降价截图。注意「条款快照」这四个字——你必须把当时看到的政策原文连同抓取时间一起存下来。因为政策会改，三天后商家说「你引用的是旧版条款」，你没有快照就说不清。

S3 条款匹配。 把用户的口语诉求映射到可引用的条款编号，产出谈判依据清单。这一步本质是检索增强，但它的输出不是给人看的段落，是给下一个状态用的弹药表：主张什么、依据哪一条、对方可能的反驳是什么、反驳的依据又是什么。

S4 交涉执行。 真正的博弈。见第三节。

S5 结果核验。 见第四节。

S6 结案并归档证据链。

S7 升级人工 / 触发熔断。 核验不通过时回退到 S3 重规划，连续 N 次不通过则熔断。

两个必须显式标注的点：

第一，幂等点与不可回滚点。 提交理赔申请、撤销订单、发送正式投诉函，这些都是不可回滚动作。进入前必须强制人工确认。这一条不是可选项——它对应的是 OWASP LLM Top 10 里的 LLM06 过度代理。

第二，状态机必须持久化到外部存储，不能只活在模型上下文里。 一次理赔交涉可能跨几个小时甚至跨天（客服说「三个工作日内回复」）。进程重启后必须能从 S4 恢复，而不是从 S1 重来。这决定了你的架构里必须有一个真正的 workflow state store，而不是把状态塞在 prompt 里。

顺带一提，重规划频率应该进 SLO。每百次任务里需要调整执行路径的次数，我倾向于控制在 15 次以内。这个指标往上走，通常不是模型变笨了，是上游页面改版或者接口变了——它是个很好的漂移预警信号。

三、通道降级链：为什么电话还在链条里

S4 里最核心的设计是通道策略。同一目标，我按「成本与可观测性」排了个降级顺序：

通道	形态	可观测性	现实可用性
A	平台标准接口	有幂等键、有服务端日志	逆向场景几乎不开放
B	自助流程 / 网页表单	可提交、可截图取证	结果判定依赖页面文案
C	图文在线客服	有对话记录可回溯	需要人设一致性与话术约束
D	语音电话客服	触达率最高、证据最难留	必须转写并落时间戳
E	工单 / 监管投诉渠道	周期长但强制力强	终局升级手段

正常工程直觉会说：优先走 A，A 不通就 B、C，D 和 E 是异常处理。

问题在于，逆向履约场景里 A 基本不存在。没有哪家平台会开放「给你退款」的接口——那等于把资金决策权交给外部程序。

于是链条自然滑到 C 和 D。

这解释了一个我在官方材料里觉得突兀、后来觉得必然的表述。千问Go! 的官方说明里写了：必要时通过电话或图文客服与服务方沟通；客服电话无法接通时，会转而通过图文客服继续沟通；面对代金券方案，会进一步争取现金赔偿。

第一次读我以为这是营销话术。现在我认为这是三条真实的工程降级规则，只不过被写在了产品发布稿里。

语音通道要能进生产，至少要解决四件事：

1. ASR 与 TTS 管道的时延与错字率。 客服报一串工单号，你转错了后面全崩。号码、金额、日期这些实体需要单独的识别与校验策略（比如要求逐位复述确认）。

2. 时间戳对齐的转写落盘。 通话录音和转写文本必须同一时间轴归档，否则证据链断掉。

3. 人设一致性。 Agent 在电话里的表述必须与它在 App 界面上给用户看的执行日志一致。不能出现「对用户说已提交、对客服说还没提交」。

4. 打断与等待的处理。 客服查系统沉默 20 秒，你的 Agent 是挂断还是等？这类超时的语义跟 HTTP 超时完全不一样，得单独设计。

安全注脚：这里有个绕不过去的问题——Agent 在电话里要不要表明自己是 AI？ 我的立场是必须表明，而且这应该是产品默认行为而不是可配置项。理由有三层：多数司法辖区对自动化外呼与身份披露有要求；冒充用户本人主张权利，一旦对方事后主张「这不是本人真实意思」，理赔本身可能被撤销；以及最现实的，一个不披露身份的 Agent 被客服识破，整条通道的可用性就废了。

图 5  高影响 Agent 的四阶段落地闸门

四、结果核验：别让模型自己宣布成功

这是我认为最容易出事、也最少被公开讨论的一环。

大模型有一个非常稳定的行为倾向：倾向于把任务判定为已完成。 对方说「我帮您记录一下」，模型很容易记成「已受理，成功」。

所以 S5 必须是一个与语言模型解耦的判定环节。我的建议是三选二：

• 到账核验：查支付账户流水，金额与时间匹配。这是唯一硬证据。
• 工单号核验：拿到可查询的受理编号，并回查一次该编号确实存在。
• 承诺时效核验：对方给出的处理时限被结构化记录，并挂上定时回查任务。

三项里至少满足两项才判定完成。只满足「对方口头答应了」的，一律进 pending 状态并挂回查，不计入成功。

这一条对指标体系的影响很大：如果成功率的分母里把「对方口头答应」算成成功，你的 TSR 会虚高，而且虚高在演示时完全看不出来，只在三个月后的投诉里暴露出来。

五、四阶段落地：别用「灰度 10%」糊过去

这类会直接动钱和合同的能力，上线节奏比模型选型重要。我参考了企业级智能体治理里常见的四阶段路径，改写成个人智能体场景：

Phase 1 影子运行（2-4 周）。 AI 生成完整执行计划，但不写入任何外部系统。同时记录人工方案与 AI 方案的差异集。这一阶段零风险，产出是差异率基线——它会告诉你模型在哪些条款上系统性地想错。

Phase 2 受控写入（2-4 周）。 只开放白名单动作，每次操作留审计日志与回滚入口。白名单按幂等性筛：含支付与不可回滚动作的一律不进白名单。

Phase 3 小范围闭环（1-2 月）。 单场景端到端自动执行，含多通道降级与人工接管。准入条件很硬：接管阈值可量化、可复现，证据链自动归档通过验收。

Phase 4 扩面复制（持续）。 模板化推广到新场景与新合作方。但有一条铁律：新场景不得跳过 Phase 1。 你以为是把已验证能力复制到理赔，其实换了对手方、换了条款体系，等于全新问题。

四道闸门的判据我列在这里，不满足就不该进入下一阶段：

1. 任务成功率与人工接管率有连续 4 周数据，且能按场景拆开；

2. 每一次写操作都能回溯到唯一 task_id、发起意图与执行通道；

3. 不可回滚动作 100% 经过人工确认节点，且确认记录留存；

4. 熔断演练通过——注入超时、权限拒绝、页面改版三类故障，系统能自动降级而不是硬失败。

顺便说一句，拿这四道闸门去对照现在市面上的 Personal Agent，会发现一件挺有意思的事：没有一家公布过带样本量的任务成功率与人工接管率。 也就是说，没有一家能公开证明自己过了 Phase 3。

那么 Waiting List 什么时候转正，反而成了判断产品成熟度最诚实的信号。

六、这件事的产业含义

最后跳回技术之外说两句，因为这直接决定了这类系统值不值得投。

逆向履约场景有个反直觉的经济性：它的单位价值远高于正向交易。 帮你省 30 分钟排队拿回 52 元，用户感知到的价值是「这钱本来拿不回来的」。而帮你下单一件商品，价值只是「少点三次屏幕」。

更关键的是，中国服务业的客服、售后、预约、理赔触点人力密集度显著高于欧美。同样一个 Agent 能力，在这里替代的是真实的人工时薪。这也是为什么我判断中国区 Personal Agent 的单任务支付意愿，未来可能反而高于海外同类产品。

还有一个副产品值得注意：谁做了逆向履约，谁就掌握了服务质量的一手数据。 哪些商家习惯性拒赔、哪些条款被滥用、哪类延误最终赔付率最高——这些数据任何平台都拿不到，因为它们只记录自己这一侧。而 Agent 记录了交涉过程。

数据资产这件事，可能比订阅费值钱得多。

下一篇预告

到这里，「怎么动手」和「动手去干什么」都讲完了。但有一个问题我一直悬着：授权这件事本身怎么保证安全？

「操作已授权平台」这句话里，官方其实没交代三件事——授权走的是 OAuth 还是界面模拟点击、权限边界由谁定义、Agent 被注入指令之后会发生什么。

系列第 3 篇讲安全基线：AI 网关与 Guardrail 为什么不能互相代管、间接提示注入在 Agent 场景里的新形态、以及中国侧正在成形的智能体身份与存证要求。

讨论

做过客服系统或者工单自动化的朋友想请教一个具体问题：「对方口头答应」和「系统真正生效」之间的时间差，你们一般怎么处理？ 是挂定时回查，还是只在结案时做一次校验？我目前倾向于前者，但担心回查任务的量级会失控。

参考来源

检索与核验截止 2026 年 10 月 13 日。

1. 千问推出 Personal Agent「千问Go!」：可申请理赔、购物保价．上海证券报·中国证券网，2026-10-13．http://www.cnstock.com/commonDetail/801354

2. 阿里推出个人 AI 助理「千问Go!」：可跨平台代办航班理赔、价保比价等个人事务（含客服交涉、代金券转现金赔偿等执行细节）．AIHub，2026-10-13．https://www.aihub.cn/news/qianwen-go-launch/

3. 阿里千问升级个人 AI 助理，Personal Agent「千问 Go!」即将发布．IT之家，2026-10-13．https://www.ithome.com/1/012/244.htm

4. 千问 App 上线超 400 项 AI 办事功能，打通淘宝、淘宝闪购、支付宝、飞猪、高德．中国日报网，2026-01-15．https://cn.chinadaily.com.cn/a/202601/15/WS69685b39a310942cc499b55d.html

5. OpenAI DevDay 2026：Dots 的高影响动作 Auto-review 与敏感动作交还人机制．Agent Skills 汇编，2026-09-29．https://agentskills.codes/blog/openai-devday-2026-recap-agent-builders

6. 努比亚豆包手机助手二代 NaviX Ultra 的「协议优先、GUI 兜底、人工确认」路线与 SAEP 公示机制．艾媒咨询，2026-10-06．https://www.iimedia.cn/c1104/117830.html

7. OWASP Top 10 for Large Language Model Applications，LLM06 Excessive Agency．https://owasp.org/www-project-top-10-for-large-language-model-applications/

关于 70 元理赔款与 52 元价保退款两个数字，来源为官方发布材料的体验叙述，属单一来源，不构成对成功率或赔付水平的统计结论。

本篇的状态机（S1-S7）、五通道降级链、三选二核验规则、四阶段闸门判据均为作者提出的参考设计，非任何厂商已披露实现。