分类标签归档：Agent
导读：这篇文章系统讲述如何从零设计一个"用 AI 测 AI"的 Agent 评测平台，覆盖五类用户角色、十大核心模块与"一个 Agent 一个 Project"的架构定位，并给出了从技术选型到 MVP 路径的完整落地参考。最有价值的设计是分层断言体系——L1 请求级（Tool 调用、参数、副作用）、L2 行为级（结构、业务规则）、L3 结果级语义判定，原则是"能不用 LLM 判的就不用 LLM"；同时强调 AI Judge 必须配人工校准闭环（与 Golden Set 人工标注的一致率 ≥85% 作为发布门禁）。适合要搭建
导读：这篇文章提出了一套 Agent 测试的 L0–L4 分层方案——从 L0 平台自检（先证明测量工具可信）、L1 单 Skill 冒烟、L2 单 Skill 批量放行门禁（L1 通过率 ≥80% 才允许用例入库）、L3 跨 Skill 全量回归对比 baseline，到 L4 稳定性回归筛掉 Flaky，核心理念是把"平台问题"和"Agent 质量问题"分开记账，让每次 FAIL 都能下钻到具体环节。文中还给了两个反复踩出来的实战经验：记忆按用户持久化（如 mem0）会导致二次跑"假 FAIL"，需用新会话/fresh_us
导读：本文基于线上全量 trace 对两个 Agent 技能做「运行时体检」，起因是一次空转 12 分 20 秒被强制中断的提问（模型逐人查 149 人、撞递归上限 350 步）。核心结论：模型升级并没有变慢（同源同日 A/B 下单次生成与首 token 反而更快），慢在编排与工具——一轮问答平均 14～16 次模型调用加 20～23 次工具调用，沙箱脚本约占工具耗时 76%，且平台「0% 错误率」只是流未断的假象，真实异常（递归越界）从 9/14 起明显上升。给出的方向是「Proxy 化下沉＋SKILL.md
导读：本文用一次完整实践回答 LLM/Agent 服务压测最常被问的三个问题——同时能撑多少人聊、瓶颈在哪、容量承诺怎么给。核心方法是 JMeter 阶梯加压逐档找软拐点（P95 抬头、稳定仍绿）与硬拐点（错误率抬头、连接层开始拒绝），并强调 SSE 流式接口"HTTP 200 但无可用 content 一律记失败"的判定口径（本次实测曾出现 3 并发档的空心 200）；关键结论是共享 LLM 配额下不能按节点数线性扩容（"10×3=30"仅在瓶颈全在本机时成立），最终以"常态 ≤10 并发/单实例、发版门禁错误率 ≤1%、
最近学习了一套 Agent 评测体系的完整框架，从思维导图整理成这篇笔记。它回答了一个很现实的问题：当 Agent 从 Demo 走向生产，我们拿什么保证它"既聪明又稳定"？
传统测试那一套在这里几乎失效——Agent 不是"输入 A 必然输出 B"的函数，而是一条概率性、多步、依赖上下文的执行轨迹。这篇笔记沿着"为什么要评 → 怎么可观测 → 离线怎么保 → 线上怎么兜"的主线，把这些年做质量保障的经验和这套体系对照着梳理一遍。
导读：这篇讲把对话质检从「上线后异步评测」前置成 Skill 发布/分享前的硬门禁——「上传成功 ≠ 可分享」。核心是一套 L1 路由/能力命中、L2 工具调用/业务执行、L3 语义判定的三层门禁，收敛为 passed = solved ∧ confidence（默认 ≥0.7）∧ not leaked ∧ not evidence_blocker，并用四态状态机把 error（没测成）和 degraded（证据不足）与 failed 分开处理，配合 eval overlay 独占挂载和稳定 seed 保证可复现。适合做 Agent 平台
导读：一篇用 4 条 trace 逐条证伪平台结论的方法复盘：某纯编排型 Agent 技能被打成健康度 41/100「不健康」，但拉明细后发现 P99 长尾（149.4s、最长 317.6s）来自跨业务定时任务混入采样的噪音，83.8%（150/179）的「中断」大多是业务写成功后收尾轮被平台切掉、并非用户流失。核心结论是分数失真源于采样口径污染 + 中断语义错位，真正可动的是把 read_file 从 4-5 次/trace 压到 ≤1、成功后立即终止这类纯编排优化，零业务改动。适合做 Agent 评测、健康度指标治理的工程师
导读：本文诊断一句「服务暂时异常」背后两条完全不同的成因链路：一是长任务占住会话并发锁，新消息毫秒级被 409 拒绝并反复重排（24 小时撞锁约 4279 行、涉及 315 个会话、占同期请求约一成）；二是答案已生成约 17KB（reason=ok）却在渲染层提前收场被判空答（answer_len=0），约 84% 的空答集中在渲染超 600 秒的长任务上，指向一条隐性截止线。核心教训是兜底文案语义与真实原因错配会误导用户与排查方向，沉淀了「文案-链路双向定位」「跨渠道对比」「时长分桶找隐性截止线」等可迁移方法。适合排查 LLM
质量工程实战 · 2026-07 · betae 环境
我们的 Agent 服务要接入千问开放平台。对方给了一份性能验收模板，列了 17 项指标，分五大类：OAuth 授权、SSE 流式输出、对话性能、H5 页面、事件回调。不达标不接。
这份模板最大的价值不是"考试"，而是它把"一个 Agent 在第三方平台上会被用户怎么用、哪些环节会卡"拆成了可测的原子指标——这正是我们平时容易漏测的地方：多数团队自测 Agent 只测"回答正不正确、快不快
导读：本文复盘一次 Agent 长任务撞碎短问答护栏的线上缺陷：批量作业型查询单轮动辄半小时到两小时，而 run 缓冲 TTL（600 秒）只按帧数续期、直播流与续传共用一个读口，导致缓冲过期被误记为「正常结束」、接回 404、锁又被生产者长期占用，用户卡在「接回中」20 分钟到 1 小时 40 分且发不出新消息。作者用可证伪假设表（H1–H5）与精确到秒的时间指纹（602.4/601.5/600.7 秒对 TTL 600 秒、from_seq 均小于 50）证实根因是「护栏假设与任务形态不匹配」，并给出心跳续期、区