作者文章归档：daxiahy
导读：这篇讲 Agent 开放平台上高敏感技能的对话隐私掩码设计：论证了为什么不能只按技能标记判断（五类泄露场景会漏掉四类，名单内用户、记忆回显等都挡不住），并给出三份名单叠加（技能/知识库/用户）、逐轮判定、命中轮整轮占位符 + 后续轮「小纸条」值级打码 + 敏感词句级打码的三层机制。关键取舍是 fail-closed（宁可多掩不漏掩）、打码不可逆且无人可豁免、主管确认才生效，并演进到「命中轮永锁 + 延续 2 轮窗口」的按轮判定。适合做 Agent 平台安全、隐私保护或对话记录审计的工程师读。
分类：AI安全 ｜ 标签：AI安全、
导读：一篇用 4 条 trace 逐条证伪平台结论的方法复盘：某纯编排型 Agent 技能被打成健康度 41/100「不健康」，但拉明细后发现 P99 长尾（149.4s、最长 317.6s）来自跨业务定时任务混入采样的噪音，83.8%（150/179）的「中断」大多是业务写成功后收尾轮被平台切掉、并非用户流失。核心结论是分数失真源于采样口径污染 + 中断语义错位，真正可动的是把 read_file 从 4-5 次/trace 压到 ≤1、成功后立即终止这类纯编排优化，零业务改动。适合做 Agent 评测、健康度指标治理的工程师
导读：本文分析一个「本地校验全部通过、线上最后一步保存失败」的接口问题：根因不是后端，而是发送给保存接口的 config 参数被传成了 Python 字典对象（单引号、None、True/False）而非 JSON 字符串，表单编码后服务端解析失败并返回兜底错误。核心洞见是「本地文件正确 ≠ 实际发送体正确」，校验对象错位让校验再严格也拦不住；修法是新增「提交前 wire 自检」——在接受校验之后、真正发出之前校验实际请求体，并在工具层做序列化加固与请求原文回显。适合排查 LLM 工具调用参数序列化、接口契约与兜底文
导读：本文诊断一句「服务暂时异常」背后两条完全不同的成因链路：一是长任务占住会话并发锁，新消息毫秒级被 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）证实根因是「护栏假设与任务形态不匹配」，并给出心跳续期、区
导读：本文分享 Agent 技能平台（技能市场）AI 质量治理的设计与落地，用覆盖全生命周期的三条治理线——上架门禁（静态扫描 + 对话质检 + 自动修复引导）、发布审核与质检（分享超阈值自动触发人工审核）、运行期健康度（观测采样 + 四维评分 + 报告触达），并守住两条红线：机器结论永远只当审核输入、不当裁决，基础设施抖动不误伤作者内容。核心认知是把 LLM 当作"可编程、可约束、可验证"的推理组件，工程本质是"数据喂养、规则驯化、测试兜底"；案例包括把 LLM 门禁从发布关键路径改为"放行 + 异步质检 + 通知"以平衡
导读：本文复盘一个 Agent 评测失败案例：用户只问"我接的订单在哪里看，给我链接"，Agent 却走了 109 步、调用 82 次工具（其中 44 次盲猜 API 路径），最终仍没查出订单数据，而正常路径只需 5～10 步、10～30 秒。归因得出五层系统性叠加的问题——技能路由失败致订单查询技能从未进入主路径、身份与技能可见范围配置错误（服务者身份下暴露的是员工端技能）、RAG 泛化替代（20 次知识库检索兜底）、会话旧记忆干扰（翻历史会话"考古"旧技能名）、无约束的暴力盲探（44 次猜 URL），
导读：本文对比同一套 Agent 服务走 A2A 协议通道与 HTTP 会话通道两种接入方式的阶梯压测结果，核心教训是"跨协议对比之前必须先对齐指标口径"：A2A 的 TTFT 指 task 帧到达（P50 约 1～2s，仅为服务端受理信号），HTTP 的 TTFT 指"首字"到达（P50 约 4～8s），两者直接比数字会得出"HTTP 慢三四倍"的假结论；真正可比的是完整时延，实测同阶梯下 HTTP 路径中位系统性快约 6s（约 -30%～-40%），且断连需区分 client 主动断与超时断，帧间隔要说明是相邻哪类帧。适合做跨
导读：本文解决"服务商只给 RPM/TPM 限流配额，业务却想知道能支撑多少用户与对话"的容量估算问题。核心方法是先用观测数据统计每轮对话的平均调用次数与 token 消耗，再按"容量 = min(RPM/每轮调用数, TPM/每轮token)"两个维度各除一次、取较小者；关键结论是长 prompt 场景下 token 维度几乎总是先撞墙（示意示例中 token 上限约 250 轮/分 vs 请求上限 2,500 轮/分），只看 RPM 会严重高估容量、上线后提早吃到 429。适合所有接入第三方 LLM API、需要做配额容