Day 144 · 上线后的反馈闭环:点赞、改写、badcase 到测试集的数据飞轮
测试集是上线前写的,线上的问题它不认识。这一课把客服点踩、草稿被改了多少、转人工、客户追问这些信号收进一张表,每周算一遍健康报表,把可疑回复去重成组交给人审,审过的变成 Day 31 格式的测试用例,知识缺失的起草成帮助中心文章,最后同步到 Langfuse。代码全部可跑,用一周模拟数据实测。
Day 143 · 自动优化提示词:DSPy、GEPA 与 ACE
手调 prompt 的那套「看错例、猜规则、改一句、再跑一遍」可以交给程序做。用 60 条 CloudLedger 工单实测三种做法:60 行自己写的反思循环、DSPy 的 GEPA、ACE 式的增量规则手册,看它们各自把分数提了多少、在哪里过拟合、花了多少钱。
Day 74 · W11 复习:给 AgentOps 设计评测平台
W11 的六天写了一堆零件:用例户口本、统计模块、评审监控、线上实验、红队流水线、benchmark 自检。今天把它们串成一份 AgentOps 评测平台的设计文档:目标和非目标、架构、数据模型、关键取舍、风险和上线计划;再写一个对比报告工具,让每个 MR 都能看到「变化有多大、区间多宽、这个评测集看不看得出来」。最后是这一周的资深面试题和坑清单。
Day 73 · 设计自己的 benchmark:从 τ-bench、SWE-bench 学方法
评测集和 benchmark 的区别,在于后者要让别人也能复现、也信得过。今天拆解 τ-bench 和 SWE-bench 是怎么造出来的,再看 2025 年那篇 benchmark 体检论文发现的问题:τ-bench 里一个只会回空话的 Agent,在不可能完成的航空任务上拿了 38%,比 GPT-4o 还高。然后给 SupportPilot 设计 CloudLedger-Bench:环境快照、按最终数据库状态判分、参考解和空 Agent 双重自检、防污染金丝雀串、版本规则,并用代码抓出两个藏着 bug 的任务。
Day 72 · 自动化红队:用 Agent 攻击 Agent
Day 39 和 Day 53 我们手写过一批注入用例。手写的用例几十条就到头了,攻击者却有无穷多种说法。今天把红队变成一条流水线:种子攻击 × 变形策略 × 投放位置自动组合出用例,只看「实际发生了什么」的检测器判定成败,攻击成功率带区间汇报,打穿的用例自动进回归集;再写一个会根据失败改写攻击的自适应攻击者,最后看 promptfoo、garak、PyRIT 怎么接进来。
Day 71 · 线上评测:A/B 实验、灰度、隐式反馈
离线评测说新 prompt 更好,线上就一定更好吗?不一定。今天给 AgentOps 写一个最小可用的实验框架:按客户稳定分流、SRM 检查、用 delta 方法算按客户聚合的比率指标、一个主指标加护栏的决策规则。再用模拟数据跑出三个教训:转人工率降了 3 个点但成本涨了 16% 时该不该上线;按会话算方差会把标准误低估一半;每天偷看一次结果,假阳性率从 5% 变成 22%。
Day 70 · 大规模 LLM 评审:校准、一致性、成本
SupportPilot 每天三千张工单,想每天看一次回复质量,只能靠 LLM 评审。规模上来以后,Day 32 那套校准不够用了:校准集里差评样本太少、校正后的通过率自己也有误差、三个评审投票照样会一起犯错、评审模型一升级就悄悄变宽松。今天用模拟数据把这些问题一个个跑出来,写一个带区间的校正、投票分流和漂移报警模块,再算清楚评审的钱和人工各花多少。
Day 69 · 评测里的统计学:样本量、置信区间、显著性
v2 在 180 条用例上比 v1 高了 1.1 个点,能合并吗?今天用 SupportPilot 那种「场景 × 说法」的评测数据,把 Wilson 区间、聚类标准误、配对比较、McNemar、按簇 bootstrap、重复采样和功效分析全部写成代码跑一遍。跑完你会发现,这 1.1 个点在统计上什么也说明不了,而这个评测集连 6 个点以下的提升都看不出来。
Day 68 · 评测是产品:评测体系的组织、流程和所有权
基础篇里评测是你一个人的事:自己写用例、自己跑、自己看分数。到了一个五六个人、两三条产品线的团队,评测会烂掉,原因几乎都不是技术。今天讲评测在团队里怎么分工、用例从哪来、谁来评审、能力集和回归集怎么流转、什么时候该退役,再写一个给用例上户口的小工具。
Day 35 · W5 复习 + 小项目:给工单 Agent 加评测集和 CI 回归门禁
把这一周的 adapter、测试集、判题器、评分器、轨迹检查和 tracing 组装成一个评测系统:一条命令跑完三层检查,多进程并发,输出带基线对比的报告(哪些用例新挂了、哪些新修好了),再接进 GitHub Actions,合并请求自动跑,关键检查失败或分数明显下降就拦住。最后是 W5 的面试题和坑清单。
Day 33 · 评估 Agent 的轨迹:工具选对没、步数多不多、任务成没成
只看最终结果会漏掉一半问题:查错了客户、重复调用、先退款后查发票。今天把 Agent 的工具调用序列当成评测对象,写顺序约束、参数校验、越权检查、冗余调用和预算检查;再写一个「模拟客户」和 Agent 多轮对话,照 τ-bench 的思路用数据库最终状态判定任务成没成。
Day 32 · LLM-as-judge:写评分 prompt、与人工对齐、偏差校准
代码断言查不了「回复有没有讲清楚政策」「有没有编造」。今天写一个只判一件事、只给 pass/fail 的 LLM 评分器,用你的人工标注去校准它:算 TPR、TNR 和 Cohen kappa,而不是只看准确率;再用这两个数修正评分器报出来的通过率,最后过一遍位置、冗长、自我偏好这些偏差。
Day 31 · 建测试集:黄金集、合成数据、边界用例
把昨天错误分析的结果变成一份正式的测试集:每条用例有可机器检查的期望,期望值尽量用代码从业务数据里算出来而不是让大模型猜;用「维度组合 → 自然语言」两步法批量合成工单,补上边界和对抗用例,划分开发集和留出集,再算清楚测试集要多大才能分辨 85% 和 90%。
Day 30 · 错误分析:读 100 条 trace,给失败分类
评测的第一步不是写评分器,而是看数据。今天批量生成 100 张工单跑一遍 W4 的 Agent,用一个几十行的 Streamlit 小工具逐条读 trace、写失败笔记,再把笔记归成几类、计数、排优先级,最后决定哪些问题直接修、哪些问题值得写成评测。
Day 29 · 为什么 Eval 是分水岭:没有评测的 Agent 只是 demo
W4 做出来的工单 Agent 能跑了,但你改一句 prompt,它是变好了还是变坏了?今天建立评测的整套概念:评测金字塔、离线和在线、能力评测和回归评测、pass@k 和 pass^k,并给 W4 的 Agent 写第一个只有 10 条用例的冒烟评测。