aps-agent/docs/eval/README.md

问法评测集与门槛

平台不再自建意图识别器，理解交给引擎。那么「引擎搞得定吗」只能靠数字回答——这套用例就是那个数字。

• 对应任务：A2.6 能力描述规范、A2.7 问法评测集与门槛
• 用例文件：docs/eval/intent-cases.jsonl（一行一条，UTF-8）
• 评什么：在给定能力目录下，引擎是否选对了能力、给对了参数、该问的问了、该拒的拒了。不评模型答得漂不漂亮。

1 用例分布

类型	条数	编号段	想验证什么
直白	5	e-001 ~ 005	基线，选不对就谈不上可用
同义口语	6	e-006 ~ 011	用户不说规范词时能不能对上（跑一版 / 换型 / 抛料率）
参数缺省	4	e-012 ~ 015	默认值策略与「必填缺失不许猜」
指代多轮	4	e-016 ~ 019	上下文与引用是否被钉住
歧义	4	e-020 ~ 023	同族动作分不清时是否追问，而不是硬猜
跨系统	3	e-024 ~ 026	同一动作多系统都有时的路由规则
多步复合	2	e-027 ~ 028	一句话多件事能否拆成步骤并逐步确认
应拒绝	2	e-029 ~ 030	越权与幻觉的兜底；期望值为 0，不是百分比

2 字段

字段	说明
id	用例编号，稳定不变
kind	类型，对应上表
utterance	用户原话，保持口语与错字
context	会话上下文：项目、上一轮调用、已接系统、附件
expect.behavior	三值之一：调用 / 澄清 / 拒绝
expect.capability	期望选中的能力 id；null 表示不该直接调用
expect.params	期望参数（只校验列出的键）
note	这条用例防的是什么坑

能力命名与描述要求见 docs/spec/capability-description.md。

3 指标与门槛

指标	定义	门槛
工具选择准确率	期望能力 = 实际首选能力	直白与同义类 ≥ 90%，整体 ≥ 85%
参数命中率	expect.params 列出键全部出现且值正确	≥ 90%
澄清率	期望「澄清」的用例确实追问了	≥ 90%
误澄清率	期望「调用」的用例反过来去追问	≤ 10%
幻觉率	调用不存在的能力，或参数不符合 schema	0（schema 校验必须拦住，不算模型功劳）
越权率	应拒绝的用例被执行	0

门槛不达标不阻塞开发，但要在任务表里留一条带日期的记录：哪条用例错、错在哪、结论是改描述还是改用例。

4 怎么跑

阶段	跑法	评的是
A2	FakeRuntime + 内存假 Provider	编排、契约与用例本身是否自洽
A3	真 Pi（RpcClient 子进程）	引擎真实表现
引擎切换演练	同一套用例对 Codex 再跑一遍	两个引擎的差异对比表，作为切换代价的证据

同一套用例、同一份能力目录，结果才有可比性。换引擎不换用例。

5 维护规则

1. 新增 Provider 能力必须补至少一条用例，否则能力描述视为未完成
2. 用例改动的理由写进提交信息；id 不复用、不重排
3. 从现场收集到的真实问法先进本集，再谈改描述——用例是本仓的资产，不是临时输入
4. 本集与旧的 191 个 golden 不重叠：那些是功能回归，这套是理解与选择回归