拿着 Day 127 的评测结果做错误分析：先把失败自动分桶，再逐桶读样例。冒烟的 15 次运行全对，唯一的「失败」是厂商排队超时，但读成功的运行时发现了真问题：重复开票时贷记单开在哪张，取决于模型列发票号的顺序。写一个不调模型的组件级评测把它量出来(160 次判断开错 7 次),在 recompute_invoice 的返回结构上加 overpaid 和 duplicate_of 两个字段后降到 0。再讲一次只改一处、用 McNemar 判断提升、模型对比，以及怎么切留出集防止对评测集过拟合。
给 BillSleuth 建一套能复现的评测:Day 122 造的 100 个场景(12 类根因 80 个，四种「账其实没错」20 个),一个会着急、会记错数字、会追问的 LLM 模拟客户，一组纯规则的判分(根因、多收金额、发票号、动作、数字幻觉、误冲正、漏冲正、转人工),每次试验在独立进程里从干净的库副本开始，结果带置信区间和 pass^k。顺便回答 Day 124 留下的问题：结论多写了原发票号算不算对。
结论要冲正时，由代码(不是模型)起草贷记单，调查图在审批节点用 interrupt 暂停，主管在命令行或网页上批准或驳回，图从磁盘上的 checkpoint 恢复。给 Day 123 的 draft_credit_note 加显式幂等键和 BEGIN IMMEDIATE,补上 approved、issued、rejected 三个状态，两人审批门槛，签发前再查一次额度，驳回后改写给客户的话。11 个测试把权限边界钉死，其中一个证明了 Day 123 的「已有草稿就返回」挡不住批准之后的重放。
把调查结论写成两份解释:给客户的大白话版和给同事的带证据编号版。写一个数字溯源校验器,检查回答里每个金额和百分比能不能在证据链里找到出处,不过就把问题清单交回模型重写,三次不行用模板兜底。附真实运行里校验器误伤、漏网和抓到问题的几个案例。
用 LangGraph 把调查流程搭起来:先用结构化输出读懂客户在抱怨什么,用代码定位候选发票,再进入「提出假设、调工具验证」的循环,最后通过 SubmitFindings 提交结构化结论。工具结果由代码自动抽成带编号的证据链。用 DeepSeek 实跑 16 个场景,覆盖全部 12 类根因和 4 种「账没错」。
把计费库和参考引擎包成 Agent 能用的 MCP 工具:6 个只读查询工具、1 个复算工具 recompute_invoice、1 个只能写草稿的 draft_credit_note。讲清楚工具粒度、返回结构、写给模型看的报错、读写分离和审计日志,最后用测试证明 100 个场景的差额都能被复算工具找出来。
把昨天手算的计费规则写成一个参考引擎:Decimal 金额、按天折算、计费锚点、优惠券和税率有效期,用单元测试一条条钉死;再写 12 个模仿真实 bug 的故障注入函数,一次生成 100 个带标准答案的争议场景,并用测试证明每个标准答案都是对的。
第二个作品换一个方向:做一个能查清「为什么多扣了钱」的计费争议调查 Agent。今天先补订阅计费的基本功(计费周期、锚点日、按天折算、优惠券、税、贷记单),再把 PRD、非目标、架构、十天排期和验收指标定下来。