发布前先聊聊：把对话质检做成 Agent 技能分享门禁

导读：这篇讲把对话质检从「上线后异步评测」前置成 Skill 发布/分享前的硬门禁——「上传成功 ≠ 可分享」。核心是一套 L1 路由/能力命中、L2 工具调用/业务执行、L3 语义判定的三层门禁，收敛为 passed = solved ∧ confidence（默认 ≥0.7）∧ not leaked ∧ not evidence_blocker，并用四态状态机把 error（没测成）和 degraded（证据不足）与 failed 分开处理，配合 eval overlay 独占挂载和稳定 seed 保证可复现。适合做 Agent 平台评测、技能分发治理的工程师读，落地顺序建议先 L1+L2 再 L3。 分类：AI评测 ｜ 标签：Agent、事前质检、对话质检、技能门禁

为什么要把对话质检前置为分享门禁

做 Agent 技能（Skill）平台的团队几乎都会配一套对话质检：技能上线后异步跑评测、算分、出报告、隔天修问题。这套「发布后异步质检」管的是「已上线的技能别太差」，但管不住一件更要命的事——还没上线的技能，可能正在把第一批真实用户带沟里。

我们做的是事前质检：不走「上线后回归」这条老路，而是把对话质检做成 Skill 发布/分享之前的对话级质量闸门。核心就一句话：

上传成功 ≠ 可分享。

对话质检卡的不是「能不能写入」，而是「能不能对外分发」。它是一道硬门禁：过不了，技能连分享的资格都没有。

架构上我们严格分工：

• 评测侧只回 gate（通过/不通过）+ reasons（为什么，带证据）；
• 状态机、排队、限流、正式上架，全部由 Agent 平台编排，两边职责边界清晰。

质量分我们分成 L0~L3 四层：分享门禁默认卡到 L0+L1（单段点检），L2 是「分享出去也不丢人」的底线，L3 走评分/徽章体系，不做默认硬拦。

实践中我们用三套 gate 覆盖不同场景：

一次事前质检是怎么流转的

整条链路从用户提交草稿包开始：

1. 提交：用户在开放平台 / 控制台上传草稿 zip。
2. 解析环境：按所选的测试环境 / 评测环境 / 生产环境，解析出 Agent 运行时（对话地址）、网关（登录鉴权）、身份服务（短信登录）等连接参数。
3. 装评测包（eval overlay）：把草稿 zip 以「评测独占应用」身份挂载到运行时，不推送在线路由注册中心——详见下文「评测包隔离」。
4. 抽选开场：用 seed = sha256(包指纹 | 场景 | slug) 生成稳定开场；开场库为空时由 AI/模板生成并写回，再经主题过滤，防止跨 Skill「串台」。
5. 规划验收口径：产出 GoalPlan(goal, success_criteria, skill_deliverables, evidence_checklist)，这是后续 Judge 的「判题灵魂」，详见「Judge 口径纪律」。
6. 对话执行：自动质检与人工质检（HITL）两条路径，最终都汇入同一个 gate 构建逻辑。
7. 三层门禁：对会话 trace 做 L1/L2/L3 判定，产出 gate。
8. 输出：平台侧「可分享（canShare）= 静态检查通过 ∧ gate.passed ∧ 包指纹未过期（TTL）」，才真正放行分发。

三层门禁结构

判断「这个对话到底成没成」，我们拆成三层，每层都有明确的证据来源，全部收敛在评测工程目录的 gate 构建函数里。

L1 路由/能力命中：主路径真走到对应子 Skill 了吗

• subskill_observed：子 Skill 的 slug 是否出现在会话 trace 线索中；
• workflow_routed：workflow 主干是否命中；
• 评测独占应用通常拿不到技能的流式事件，因此有成功的业务 HTTP 调用也视为「已触达」（http_success_exclusive_proxy）；
• 未命中 → evidence_blocker → 状态降级为 degraded，拦发布。

这一层防的是「口头跳过」：用户问 A 技能，Agent 用通用话术含糊带过，根本没走技能主路径——这种对话放出去，等于技能白装了。

L2 工具调用/业务执行：真调了业务接口，且没全挂

• http_any_success / http_all_failed：看业务 HTTP 工具（含 MCP 类工具）的真实调用结果，请求全挂就是没干活；
• sensitive_leak：扫描助手回复里是否出现未脱敏的手机号、身份证号等敏感信息——必现则强制 solved=False：质量再高，把用户隐私打出去也是事故。

L3 语义层：主目标在限定轮次内办成了吗

• final.solved：LLM Judge 对照 SKILL.md 中的 success_criteria，判定「问题有没有被解决」；
• final.confidence ≥ min_confidence（默认 0.7）：判定结论要有足够把握，不允许含糊过关。

最终结论收敛成一个布尔表达式：

passed = solved ∧ confidence_ok ∧ not leaked ∧ not evidence_blocker

四态状态机与降级

gate 输出不是简单的 pass/fail，我们维护一个四态状态机：

两个容易踩的坑，各用一个状态解决：

• error ≠ failed：基础设施抖动、调度失败是「没测成」，不是「测不过」。error 不记业务不合格、允许重试，否则一次网络抖动就能把合格技能打出局。
• degraded 单独成态：证据不足（没走到主路径、接口全挂）与「主目标确实没办成」（failed）必须分开。很多「聊得挺好」的对话其实是 Agent 在口头引导用户、绕过了技能本体，这种必须降级拦截，防止「软通过」。

评测包隔离与可复现

评测包独占（eval overlay）

草稿包在过审之前，绝不允许碰正式路由。做法是：

1. 本地解压 zip，读 SKILL.md 抽取验收口径；
2. 调用运行时的评测包接口，把草稿以评测独占应用（eval_exclusive_app）身份临时挂载；
3. 对话一律走独占应用，不经在线路由注册中心，不污染正式路由；
4. 装包与对话必须在同一环境槽位（任务级环境覆盖）；
5. finally / 取消时必卸 overlay，防止临时应用泄漏成常驻资源。

同包同场景可复现

• 开场抽选用 seed = sha256(包指纹 | 场景 | slug)，同一份包、同一个场景，每次跑开场稳定一致；
• 需要重测时 reroll 只换盐（salt），不改变种子结构，便于对账与复现；
• 产出 package_fingerprint 透传并随终态回写，历史任务里若存在同指纹曾通过（TTL 未过期）的记录，分享侧可直接幂等放行，避免重复烧评测资源。

Judge 口径纪律

对话质检里最容易被「调坏」的不是执行框架，而是判定标准本身。

• 验收标准必须来自 SKILL.md，不允许臆想：Judge 的 system prompt 强制要求 success_criteria / deliverables 必须出自技能文档；
• 禁止抬高标准：文档没要求的字段（比如某个订单号）不得拿来当 FAIL 理由；
• 也禁止放水：文档里写了的验收点，不能因为「太严」而悄悄降级；
• 文档虚则 gate 软：SKILL.md 本身写得含糊、缺验收标准时，missing_success_criteria 进 warnings 而非硬扣——文档质地决定门禁硬度。

另一条纪律是口径统一：人工质检（HITL）与自动质检走同一个 gate 构建函数，人工测试会发现的问题不会被自动评测漏掉，反之亦然。差别的只是执行方式：自动会主动追问（默认 smoke，≤3 轮），HITL 不自动多轮，由人把控节奏。提交后先把 gate + transcript 落库尽快返回（防网关超时），蒸馏、入库、卸 overlay 在后台线程完成。

落地建议

从零搭这样一套事前质检门禁，我的建议按这个顺序来：

1. 先上 L1 + L2，再上 L3：路由命中和工具调用都是结构化证据，好实现、好解释；语义判定放在后面，先把「证据链」底座立住。
2. 三套 gate 分级配置，别一把尺子量到底：单段点检（spotcheck）用 2~3 轮智聊快速查主路径；批量分享门禁（share_gate）强制 CORE + EMPTY + 固定开场的场景组合；项级策略上区分硬拦（FAIL 即拦）与软放行（warn 不拦）。
3. 后台执行 + 尽快返回：评测异步跑；HITL 提交后先落库再返回（防网关 504），后续处理放后台线程——用户等得越久，门禁越容易被绕过去。
4. 把证据交给技能作者：gate 里带 headline（一句话结论）+ reasons + warnings + evidence + 报告链接，让作者知道「为什么不过、卡在哪一层」，修起来才有抓手。
5. 监控门禁自身：记录通过率、degraded 率、error 重试率等指标（文中数值已做脱敏示意），degraded 率异常升高往往意味着测试用例和真实用户场景脱节，比 failed 率更值得关注。

事前质检的本质，是把「质量」从事后追责变成分发前置条件。对话质检一旦成为对外分发权的硬门禁，每一个分享出去的技能都自带一次真实对话的验收记录——这比任何打分报表都更有说服力。