那笔0.0211元扣费：免费Agent的自校验误判与静默成本

如果你也在自养Agent我建议你养成一个习惯定期翻一遍账单别只看大头支出专门盯着那些几毛几分的小额扣费。上周我就翻出一笔0.0211元的扣费第一反应是“不是都用的免费模型吗哪里来的钱”顺藤摸瓜查了一圈日志最后发现了一个特别值得写下来的事实免费模型在这一轮任务里明明答对了是我自己写的判定代码把它判成了“失败”然后系统一声不吭地启动重试链让付费模型兜了一次底。任务最终是成功的监控面板全绿只有账单悄悄漏了底。这个标题就是那起小事故的完整记录。这篇文章不会有那种“教你零成本搭建Agent”的漂亮话我会把这笔0.0211元的来龙去脉、误判代码长什么样、日志里是怎么还原出整条真相的全部摊开讲清楚。搞Agent开发的朋友尤其是喜欢用免费/低成本模型当主力的人这篇应该能帮你避开同一个坑。1. Agent任务里的“判分环节”质检逻辑是怎么工作的1.1 我养的这个Agent每天在干什么先交代一下项目背景。我维护的小Agent核心功能并不复杂每天定时跑几轮任务输入是一些非结构化文本比如订房确认邮件、酒店客服回复、行程变更通知输出是结构化字段比如入住日期、离店日期、房型、入住人数、价格区间最后写入下游数据表。主力模型用的是某家云厂商的免费层模型付费模型作为兜底。之所以敢让免费模型挑大梁是因为抽字段这类任务容错性相对高模型哪怕措辞绕一点最终产出的JSON基本能用。免费模型不是没有缺点它输出风格波动大偶尔会答非所问所以我让它后面挂了一个自校验模块也就是常说的validator/judge。这个judge专门检查模型输出是否符合预期字段齐不齐、类型对不对、数值合不合理。我标题里说的“我的代码判它失败”指的就是这个judge模块。我贴一段运行时日志结构方便你理解整个链路{ ts: 2025-01-16T14:02:31.18208:00, level: INFO, request_id: req_20250116_140231_8f3a, stage: model_invoke, model: free-llm, verdict: PENDING }每轮任务都会有这样一个入口日志之后每个环节都带着同一个request_id往下走。这看起来是小事但到了排查事故的时候它就是你唯一的线索。1.2 验证器为什么存在又为什么容易成为薄弱点模型生成内容是概率性的同一个prompt十次可能有十一种写法。验证器存在的意义不是替模型把答案重答一遍而是用一套确定性的规则去约束不确定性的输出。你可以把模型想象成一个性格跳脱、偶尔喜欢发挥的实习生。实习生交上来的东西你不能百分百信任所以需要一个质检员在入库之前把一道关。质检员通常不应该出问题因为它的逻辑是写死的规则是确定的。但规则确定不代表规则正确。质检员的标准如果写错了就只有两种结果把坏品放出去或者把好品全部打回。前一种误判会污染下游数据大家多少都遇到过后一种误判的危害往往被严重低估。因为“打回”不是一个终止动作它牵一发动全身——重试、换模型、回退分支一连串更贵的路径会被触发。我这次的0.0211元本质上就是“质检员的标准写错”把一个合格品扔进了回料堆然后整个生产线为了返工多花了一笔钱。1.3 判定结果与后续动作的对应关系我把Agent内部对判定结果的响应规则梳理成了一张表这也是我这次事故里最关键的一张表判定结果后续动作成本特征PASS直接提交入库零额外成本FAIL同模型重试1次携带上次失败上下文消耗免费配额FAIL第二次切换到付费模型兜底产生真实计费FAIL第三次触发告警并暂停该任务人工介入注意看PASS只有一条路而FAIL有三个分支越往下越贵。judge的一秒钟误判影响的根本不是那一次调用而是整条代价递增的链路。所以后来我把一条原则刻进了开发流程里所有会产生成本的失败分支都必须有日志、有告警、有熔断。这次事故恰恰是三条全没做到。2. 我的验证器如何把正确结果误判成失败2.1 出事的代码长什么样先看坏掉的judge片段。这是它最早的简化版REQUIRED_KEYS [room_type, check_in, check_out, guests, price_band] def judge(parsed: dict) - str: missing [k for k in REQUIRED_KEYS if k not in parsed] if missing: logger.warning(judgeFAIL reasonmissing_keys request_id%s missing%s, task.request_id, ,.join(missing)) return FAIL if not isinstance(parsed.get(guests), int): logger.warning(judgeFAIL reasonbad_type request_id%s, task.request_id) return FAIL return PASS再看它对应的prompt版本新旧两版我都贴出来旧版promptv3.2要求模型输出英文key请提取以下邮件中的预订信息输出JSON 字段包括 room_type, check_in, check_out, guests, price_band新版promptv4.0已经改成中文key因为运营同事反馈中文字段更好读请提取以下邮件中的预订信息输出JSON 字段包括 房型, 入住日期, 离店日期, 入住人数, 价格区间发现问题了吗prompt在2024年12月就升到了4.0中间还迭代过一次输出示例。但judge文件里的REQUIRED_KEYS始终是旧版英文key。这就是典型的“改了一半”模型端升级了输出schema消费端judge没有跟着升级两边各跑各的谁也没报错直到账单出卖了真相。2.2 模型“答对”的证据那天14:02那轮任务模型实际输出是这样的{ 房型: 大床房, 入住日期: 2025-01-20, 离店日期: 2025-01-23, 入住人数: 2, 价格区间: 200-300元 }这条输出放到业务里看完全正确房型、日期、人数、价格区间全覆盖只要做个简单的字段映射就能入库。但我的judge接收到的parsed dict是这组中文key它拿着旧清单逐个比对发现“room_type”不在里面、“check_in”不在里面于是当场返回FAIL。日志里清清楚楚记着那行warning[2025-01-16 14:02:31] WARN judgeFAIL reasonmissing_keys request_idreq_20250116_140231_8f3a missingroom_type,check_in,check_out,guests,price_band这就是“免费模型答对了我的代码判它失败”的完整物证。模型没错prompt没错错的是我埋在judge里那五个过期的key名。2.3 三类常见误判都是格式偏执把这次经历和之前踩过的坑放一起我发现Agent的validator误判大致有三类全是“格式偏执”误判类型典型表现触发原因schema漂移模型输出新字段名validator还检查旧字段名prompt升级检查逻辑没同步包裹与前后缀模型在JSON外加了说明文字或markdown代码块解析正则写得太死没做宽松提取类型边界过严人数写成2而非2价格写成200-300元而非字符串validator要求强类型模型按人类习惯输出免费模型更容易触发这几类问题因为它的输出风格比付费模型更不稳定今天老老实实按示例来明天可能就在JSON前面加一句“好的这是您需要的结构化数据”。这导致解析层和校验层都容易出幺蛾子。有意思的是我以前处理过“模型输出包裹在markdown里导致json.loads失败”的问题当时修了正则但没过问为什么模型会加外包装。现在回头看免费模型的问题是信号不是干扰——它恰恰说明prompt对输出格式的约束不够强硬只是当时我没把这件事上升到“格式鲁棒性”来对待。3. 两条账本一次误判如何触发真实扣费0.0211元3.1 免费模型、配额和fallback链很多人对“免费模型”的理解是零成本其实不准确。免费模型本质是配额制每分钟有请求数上限每天有token额度超过后要么限流要么按量计费。这就意味着免费额度也是一种隐形成本它被无效重试消耗掉之后后面真正需要它的任务就只能走付费通道。我的重试链设计是第一轮调用免费模型免费模型judge返回FAILsleep 3秒后携带失败上下文重试仍然是免费模型还需要再消耗一轮免费配额若再次FAIL触发fallback切换到付费模型兜底。这套链路平时跑得挺顺我也没想过里面藏着什么炸弹。炸弹的引信就是那个过期的judge它会把“语义正确但key名变了”的输出反复判成FAIL于是免费模型一遍一遍被冤枉重试链一遍一遍往下推。3.2 0.0211元的费用拆解账单里的0.0211元精确拆开是这样几笔成本项金额元说明付费模型fallback调用0.0174携带两轮历史上下文输入约7195 token输出约375 token重试调度与消息队列0.0021同时间窗内多出的两轮调度、消息推送计费日志存储与采集计量0.0016多出的两轮日志写入与30天存储分摊总计0.0211元。为什么fallback这次调用花了0.0174元因为重试不是从头重来而是把上一轮的模型输出、judge判定结果、用户原始输入全部代入对话历史让模型自己纠错。我算了算每多一轮重试输入token大概膨胀20%到30%。等到fallback真正出场时输入已经从第一轮的2800 token膨胀到7195 token。按付费模型输入0.002元/千token、输出0.008元/千token的单价累计就是这个数。3.3 静默失败的本质任务成功掩盖了系统缺陷这一节才是整篇文章我最想说的东西。0.0211元不是重点“静默”才是重点。这轮任务最后的结果是成功的——付费模型兜底成功结构化字段入库第二天早上数据报表一切正常。监控面板上没有任何异常任务失败率为零。如果我没有去翻账单这笔钱就会永远躺在那这个bug就会永远潜伏在代码里直到哪天免费配额被无效重试耗光或者付费模型额度被刷爆事情才可能暴露。这就是静默失败的可怕之处它不吵不闹用任务表面的成功掩盖了系统内部的缺陷。Agent系统里显式失败反而安全因为你会去处理它静默失败才是最危险的因为你根本不会去复盘一个“看起来成功”的任务。再算一笔放大账。一次误判0.0211元看着微不足道。但如果这个Agent一天跑288次五分钟一轮误判率5%一天就是14次误判光fallback就是每天0.3元、一个月9元、一年过百元。这还只是单Agent单任务的账还没算免费配额被无效消耗后真实任务被迫高频走付费通道的连锁反应。一旦业务量大起来这种“静默的浪费”会从零钱变成成本黑洞。4. 排查复盘从账单到日志再到一行业务代码4.1 第一步账单反查锁定时间窗发现那笔0.0211元扣费后我没有直接去改代码而是先把账单打开看明细。账单里的计费项写的很清楚某云模型推理按量计费时间戳落在01-16 14:02到14:03之间请求数一次token消耗总共约7570。看到时间窗和模型名我就知道这大概率不是正常的免费模型调用于是去Agent日志里捞这个时段的所有相关记录。这里有个基础操作值得多说一句查日志前先确定时间窗并且尽量精确到分钟。别拿着大半天的时间范围去捞日志量一大检索效率和准确率都会下降。4.2 第二步用request_id串起整条链路幸好我从第一天就给每轮任务生成了request_id每次模型调用、每次judge判定都打上同一个id。没有这个id今天要还原这条链路会痛苦十倍。我用的是日志平台自带检索等价于在采集端做了过滤。如果你本地排查可以参考这条命令grep req_20250116_140231_8f3a /var/log/agent/agent.log | jq {ts, stage, model, verdict}输出结果很直观{ts:14:02:31.182,stage:model_invoke,model:free-llm,verdict:PENDING} {ts:14:02:33.046,stage:judge_result,model:free-llm,verdict:FAIL,reason:missing_keys} {ts:14:02:36.210,stage:model_invoke,model:free-llm,verdict:PENDING,retry:1} {ts:14:02:38.734,stage:judge_result,model:free-llm,verdict:FAIL,reason:missing_keys} {ts:14:02:41.583,stage:model_invoke,model:paid-llm,verdict:PENDING,fallback:true} {ts:14:02:48.201,stage:judge_result,model:paid-llm,verdict:PASS}三行关键日志直接把事故链摆在了眼前免费模型第一次调用judge FAIL免费模型第二次重试judge还是FAIL切换到付费模型一次就PASS。付费模型答得也不比免费模型神圣它能PASS的唯一原因是当时fallback分支里临时加了一行“trusted_model_skip_judgeTrue”直接跳过了校验。也就是说只要切了付费模型不管输出啥都放进来了。这个判断本身也是有问题的只是当时代码写得匆忙把“兜底”写成了“放水”。4.3 第三步从日志翻出模型原话和我的误判拿到judge的FAIL记录后我直接去翻了同request_id下模型原始输出字段的存储。日志里其实保存了agent_reply的预览快照{agent_reply_preview: {\房型\: \大床房\, \入住日期\: \2025-01-20\, \离店日期\: \2025-01-23\, \入住人数\: 2, \价格区间\: \200-300元\}}把模型原始输出和judge的missing_keys对照着看结论立刻清晰模型输出的五个字段全部信息完整只是key名从英文变成了中文。judge检查的是room_type、check_in而输出里是房型、入住日期——不是信息缺失是schema变了校验清单没跟上。这一刻的感受挺复杂的。一方面庆幸日志够了能还原真相另一方面有点恼火因为这个问题从头到尾只需要改一行配置。模型在免费层勤勤恳恳干对了活儿被我这段代码硬生生打了两个“不合格”的标签最后还浪费了一次付费调用。4.4 关于日志采集的题外话这次能这么快定位有个前提是日志不是散落在各台机器上而是统一采集到日志平台。我在Agent所在的宿主机上部署了filebeat做日志采集输入指向Agent的运行日志目录输出写到集中日志系统。配置文件非常短核心就这些filebeat.inputs: - type: filestream id: agent-log paths: - /var/log/agent/*.log output.elasticsearch: hosts: [http://logging.internal:9200]具体采集组件用什么不强求但有一个原则必须守住Agent日志的采集管道要独立于业务系统。业务系统挂了日志采集不能跟着挂反过来日志采集抖动也不能拖垮正常业务。这起事故能翻出来靠的是日常采集管道稳定运行哪一环断了这张账单就会变成无头悬案。5. 修完代码之后做的三处加固5.1 验证器改造从格式校验走向语义校验第一件事就是把judge里的REQUIRED_KEYS换掉但这只是止血。真正的修复是让校验逻辑不再只认一套key名而是先做语义对齐FIELD_ALIASES { room_type: [room_type, 房型, 房间类型], check_in: [check_in, 入住日期, 到店日期], check_out: [check_out, 离店日期, 退房日期], guests: [guests, 入住人数, 客人数量], price_band: [price_band, 价格区间, 预算范围], } def judge(parsed: dict) - str: missing [] for canonical_key, aliases in FIELD_ALIASES.items(): if not any(alias in parsed for alias in aliases): missing.append(canonical_key) if missing: logger.warning(judgeFAIL reasonmissing_keys missing%s, ,.join(missing)) return FAIL ...这套改造的核心思路是校验器应该校验“信息是否齐全”而不是“字段名是否和我想的一样”。字段名是模型的输出表现层今天叫room_type明天叫房型后天可能叫“房间数量与类别”语义没变就不该被打回。以后prompt再改schemajudge这边只需要在别名表里加一行不需要改判断逻辑。5.2 重试链加固熔断、重试预算与语义反馈第二件事是给重试链上保险。之前的设计是“失败就重试重试失败就切换”现在改成了judge的FAIL消息必须带失败原因没有原因的FAIL直接记WARN并视为系统异常免费模型重试最多2次第三次无论结果直接走告警并暂停该任务fallback当天累计触发超过3次自动熔断防止失控重试历史作为上下文喂给模型时要把“缺了哪个字段”这种原因带回去而不是甩一句“请重新生成”。以前模型被要求“请改正后重新输出”却不知道自己错在哪就得全靠猜。现在judge会把具体缺失字段写进重试上下文模型纠错的成功率会明显提高无效重试自然减少。5.3 日志补全judge决策过程必须完整落盘第三件事也是和我这个标题关系最直接的一件把judge的决策过程完整落盘。以前只记录结论FAIL或PASS不记录依据出了问题还得翻模型原始输出人工对照。现在每行judge日志都补齐了verdict_reason、schema_version、check_item、judge_input_preview四个字段{ ts: 2025-01-17T10:00:01.00108:00, request_id: req_20250117_100001_a1b2, stage: judge_result, verdict: PASS, schema_version: v5, check_item: required_field_check, judge_input_preview: {\房型\:\大床房\,\入住日期\:\2025-01-20\} }一句话总结这次加固的体会日志不能只记录“我判你失败”更要记录“我为什么判你失败”。没有原因日志只能看到现象看不到故障根因有了原因日志下次再出问题至少能少走半个小时弯路。5.4 用历史样本做了一次回归最后我把过去一个月存下来的200条真实模型输出重新跑了一遍新judge。结果很说明问题旧judge的误判率是3.5%新judge降到0.2%而那0.2%全部是真正缺字段的输出。也就是说之前每100条正确输出里就有3到4条因为字段名变化被误杀而我完全不知道。这次回归也暴露了另一个数字200条样本里schema漂移导致的误判占到了七成以上远比模型本身答错的概率高。这让我调整了后续的优先级——与其频繁优化模型prompt不如先把judge的语义校验能力写好。模型偶尔犯错成本是单次调用judge系统性误判成本是整个Agent链条上的连锁放大。最后补一刀账单是最诚实的监控修复上线到今天我又跑了三周固定每天看一眼账单。可以负责任地说类似的小额异常扣费没有再出现过。但真正让我改变的不是那0.0211元而是这起事故逼我回答了两个问题我的代码有没有在某个分支里反复执行“我知道会失败但依然选择重试”的无效动作那些执行了但没人看的日志到底是浪费磁盘还是沉默的哨兵我现在养成的习惯是每个Agent项目上线先不看模型效果先看一遍重试链和judge链路有没有完整日志每次想起来就顺手翻一遍账单不是抠那两分钱而是确认那些“静默的分支”还没有在某个角落里背离设计预期。免费模型不是没有成本judge也不是越严格越好——它们的成本都藏在你看不见的分支里。希望这篇日志能帮你少踩一次同样的坑。