Nubank客服 Agent：一笔补卡任务怎样连接上下文、工具与评测

把客服换成更强的模型，并不保证原有行为继续成立。在该客服配置中，Nubank 从 GPT-4.1 迁到 GPT-5 时，曾遇到模型没有先调用所需的上下文工具就开始回答；团队在行为指令中明确“需要客户特定事实时先调用工具”，才恢复预期行为。另一处失败发生在评测端：客户只查物流，评分器却因助手没收地址而扣分。

这两件事说明，客服的可靠性不只取决于回答能力。系统要把业务步骤、客户事实和允许动作接起来；评测也要理解同样的业务条件。Nubank 的公开论文给出了足够具体的工程线索：上下文怎样独立选版，工具封装什么，地址评分怎样改，以及离线评价与线上结果怎样共同推动迭代。论文v2，§4–6与附录A

从“卡没收到”进入一项有结果的工作

卡片配送助手处理的是客户自己的订单。它先取得物流与预计时间，再按地址类型调查：公寓入口、门卫代收、邮政信箱，需要的问题不同。问题仍未解决时，才进入补卡路径。这套顺序来自人工标准作业程序，论文称转换后的有序步骤为 Routine，即供模型遵循的处理例程。

例程不替模型预写每句对话。模型读取客户新回答与工具结果，再选择回复、追问或调用下一项能力；工具执行结束，结果回到会话与工作状态，继续影响下一步。固定工作步骤与按事实分支因此可以同时存在。论文采用的是这种工具结果不断回流的 Agent 循环。§3.1、§4.2、§5.1

该卡片案例披露了三项领域工具：

查询状态、发起补卡与带上下文转人工，是不同的服务结束方式。一次查询没有补卡并不天然失败；工具返回“已签收”，也不能直接等于客户拿到了卡。任务应停在哪里，取决于本次诉求和调查事实，而不是对话是否已经生成一段满意的结尾。

每轮上下文，不是一份越来越长的总提示词

Nubank 将模型输入拆成能分别维护的组件，再为一个客服配置选定各自版本。论文图4的说明例中，Agent v3 采用 Instructions v3、Routines v2、Macros v1、Tools Usage v2，以及各自选版的两个工具说明；不是把所有历史版本一起放进窗口。§4.2、图4

这种划分给修改提供了位置。新增调查分支，应检查例程与相关工具；已有事实没有进入回答，要检查当前状态及调用规则；事实正确但回复太长，则要检查行为指令和模板。它并不消除组件依赖：例程新增一次调查，工具返回、回复模板和评分规则也可能需要一起调整。

可横向查看，点击打开原尺寸 ↗

图据论文v2 §4.2、图4重组：示例版本仅说明独立组合，不代表完整生产配置。

论文将工作状态称为持久状态对象，并说明它可以支持长期个性化；它保存的参数、工具结果与例程进度也承接当前任务。但具体存储方式、完整字段、跨会话生命周期与失效规则没有公开，不能照着组件名还原一套未公开的客户记忆平台。

固定后台依赖交给代码，业务分支留给模型

如果查物流必须结合承运商信息与内部订单系统，让模型逐次安排这些固定调用，会额外增加顺序错误、中间结果遗漏和延迟。论文将这类确定依赖封装为复合工具：模型决定需要哪项事实，代码完成既定联查与整合。§4.3.2

工具边界也不能无限扩大。把每个底层接口都交给模型，模型要承担不必要的组合；把所有业务判断都藏进一个大工具，模型又可能失去决定调查方向所需的信息。可复用的原则是：固定顺序由代码保证，返回内容保留下一次判断所需事实。

因此，工具说明本身也是上下文。除了名字，Nubank 要求类型化输入、返回格式、调用例子和何时不要调用；上游几十个内部字段不应原样塞回模型。查询工具要让事实含义清楚，写工具还要让成功与失败可辨。跨工具规则明确要求：只有执行结果明确成功，助手才能确认完成。

论文将身份认证、事务性且幂等的 Action API、调用审计列为基础设施。幂等的作用是让同一操作在重试时不额外产生一次业务副作用；审计保留输入、输出、延迟与错误，并配合敏感字段遮蔽、访问和保存期限控制。这些责任由业务系统承担，不能靠模型说“我不会重复”实现。§4.3.1、§6.5

公开资料没有给出补卡请求的完整参数、错误码、幂等键或结果查回协议。它确认了这类保证应存在，却不足以复制一个生产补卡接口。超出例程、必要数据取得失败或回答置信不足时，已披露的处理是带完整对话上下文转人工；最大轮数、具体阈值和重试预算并未公开。

地址评测：先判断需不需要，再判断问得对不对

自动评分器通常被称为 LLM Judge，即让另一个模型按规则判断对话。Nubank 的地址输入评测 E2 起初只有约12行：助手问过地址，并问了至少一项配送补充信息，就通过；否则失败。它遗漏了三个业务区别：普通物流咨询不一定补卡，同址配送不一定需要重收字段，“补充信息”也需要地区定义。

优化后的公开节选采用一棵条件树：

核心字段包括街道和门牌、城市、州、邮编；公寓、楼层、楼名、地标或配送说明等可作补充，“住宅／商业地址类型”本身不算。泛泛地问“完整地址”也不等于明确询问必需字段。评分只看用户与 AI 助手，不把人工接手后的补救算到 AI 名下。原文的一条短指令是：

Only evaluate [user]-[assistant] messages; ignore all other roles.

以上来自论文附录A、Listing 1–2及表4；Listing 1 为完整公开初版，Listing 2 本身带省略，不能称取得了约80行的优化全文。原始规则与差异

还要看清它测的是什么：新址分支允许“助手明确请求全部字段与补充信息”，或者“用户已经提供完整信息”通过。第一条路径下，用户尚未回答，也可能满足这项行为评分。因此 E2 不能兼任后台地址验证、补卡授权和执行成功检查。将这几个结果分开，才能避免为了分数收集不必要信息，或把问过字段误当作资料已经就绪。

专家理由怎样变成评分规则，测试集怎样不被用来改规则

论文为补卡失败、输入核验、配送事实、简洁性、解决完整性建立五类评测。数据来自经最小化与假名化处理的真实客服对话；样本量分别为888、90、816、246、90，类别比例不同，也未说明各集合是否包含重叠会话，不能把它们相加当成独立客户人数。§5.2、表1

每条样本由三位熟悉业务的运营分析师给出二分类标签和理由，标签取多数票，文字理由作为后续优化的语义反馈。只给“对／错”，优化器很难知道是缺了业务条件、字段定义还是角色范围；理由提供了可修改的对象。

评分规则优化与客服执行是两件事：

1. 先按类别分层，将标注数据分成40%训练、30%验证、30%测试。
2. GPT-4.1-mini 按候选评分指令给对话分类，结果与专家标签比较。
3. GPT-5.1 作为反思模型，读取错误、专家理由和当前指令，提出新的评分文本；这里使用 DSPy 中的 GEPA 优化器。
4. 训练和验证部分支持候选修订与比较；Pareto 选择保留在不同目标上互有优势的候选，避免只追随单一平均最高者。
5. 候选固定后，才用留出的测试集报告准确率；实验重复五次并报告均值与区间。

反思每批使用3条样本，作者把 auto=light 描述为约500次迭代。这些是论文实验设置，不是客服每次服务的调用预算，也不能推定当前版本工具库始终以同样次数运行。GEPA 在此修改的是 Judge 指令，不是生产客服的权重、业务代码或每笔补卡决定。

在留出测试集上，五次运行的平均结果显示：E2 的初始准确率68.88%，低于恒猜多数类的77.78%；优化后为88.89%。这证明这次规则修订纠正了重要判定缺口，而不只是让提示词更长。其他项的提升较小：E1由77.78%至82.00%，E4由74.00%至76.89%。论文对照的是多数类和简短初版，没有同等预算下持续专家手工修订的对照，因此不宜推出“自动优化普遍胜过人工”。§6.1、表2

可横向查看，点击打开原尺寸 ↗

图据论文v2 §4.4–5.2及§6重组：留出测试不回流优化；Judge开发不是每笔补卡的在线审批。

换评分模型也需要校准。论文另比较七种模型对 E1 的一致程度，优化后的部分组合明显收敛，但一致性不是对专家的准确率，更不是补卡成功率。读者需要保留“评分规则版本＋评分模型版本＋测试样本”的组合，才知道下一次比较是否仍用同一把尺。

模型升级是一次上下文变更，也可能带来分项退步

在该客服配置中，GPT-4.1 会隐含推断回答个案前需要查资料，GPT-5 的较严格指令遵循却没有稳定保留这项未明说的要求。Nubank 没有重写全部例程，而是在 Instructions 加入工具优先原则：需要客户特定数据时，先调用工具，再组织答复。模块化在这里的价值是能定位修改，而不是承诺新模型自动兼容旧配置。§6.3.2

适配后的 GPT-5 在多数评测项上失败减少，但回复简洁性退步。更好的候选仍有具体短板，不能用综合改善抹掉。论文还披露后续版本加入工具选择层级、挫败感识别、主动交接和简洁性预算；预算的单位与实施方式没有给出，不能把这个名词直接翻成固定字数或 max_tokens。

团队为每个模型保留自己的评价基线，迁移前运行完整评测集。其原因很直接：换模型会改变对全部输入的解释；一次例程局部修改与一次模型替换，影响范围并不相同。

离线修可判定的错误，线上找尚未覆盖的问题

离线快循环先用真实或模拟对话检查候选，将错误追到指令、例程、工具或模型配置，再修改和复测。线上慢循环则观察用户体验与处理方式：某类客户持续不满意、新业务转人工增多，可能需要新增例程、重做工具边界或调整上下文，而不是继续修一个已有评分条目。§4.4–4.5

卡片候选从1%流量开始再逐步扩大；论文的一般策略是1–5%。它同时看单次交互后的客户评价 tNPS，以及无需人工升级解决需求的自助服务率 SSR。二者有取舍：把困难或受挫客户尽早交人，可能改善体验，却降低自动处理比例。

卡片基线 V0 只有知识检索和转人工，后续才加入例程、客户／物流工具和补卡能力。因此作者报告的 tNPS 增加37个百分点、SSR增加29个百分点，属于客服能力与配置组合相对旧方案的变化，不能归功于一次 Prompt 优化，也不能当成纯模型能力提升。样本量、周期、问卷响应及完整成本未公开，无法独立推算投资回报。§6.3、表3

官方博客补充了生产运营的视角：上线前模拟大量对话查看完整调用轨迹，生产中用第二个模型审计正确性、简洁性与市场表达。它是同团队的实践披露，不是独立验证；自动审计也不能替代人工校准。Nubank 工程博客

在自己的客服系统里，沿同一笔任务检查三条链

这套设计可迁移的不是银行卡字段，而是把三个问题接起来：本次允许做什么，工具实际做了什么，评分是否在正确条件下评价它。

可以从获准使用的历史任务中取仅查物流、原址补卡、新址资料未齐和工具失败几类记录。为每条记录保留选中的上下文版本、用户与工具提供的事实、下一步依据、后台结果和人工接续。若行为通过而后台没有动作结果，分别记录；如果只是物流查询，不要求它为地址评分补做无关采集。

再让业务人员复核评分分歧，检查该修改客服还是先修改量尺。恢复写动作以前，还要由后台证明权限、资格、参数和重复请求的行为可控；公开论文没有给出的私有 API 细节，不能用一段更强的 Prompt 补上。这样才有条件判断：问题出在资料、工作步骤、工具、评分，还是自动服务本来就应在此交给人工。