评测的是整个系统
原文内容整理
插件在受控测试中得分很高，放进实际产品后仍可能失败。原因之一是运行框架（harness）决定模型收到什么提示、能访问哪些工具，以及工具调用、执行轮次和沙箱如何运作。模型与运行框架共同决定最终行为。
文章以美国劳工统计局（BLS）数据插件为例。BLS API 需要数据序列 ID，插件先将用户的问题解析为候选序列，再获取数据。演示使用合成数据和五个测试用例；后面的生产插件实验使用另一个独立数据集，不要混淆两者。
同一组问题，分三层测试
原文内容整理
第一层：直接工具测试。把结构化输入直接交给解析器，不调用模型，速度快、结果确定，适合定位工具本身的错误，但不能检验自然语言理解或工具选择。
第二层：独立函数调用循环。模型接收 MCP 工具并自行选择调用，适合迭代工具描述、提示词和模型，但无法完整复现产品运行框架。
第三层：产品运行框架。在安装插件的 Codex 中运行相同问题，更接近交付环境，成本较高。文章的 Codex SDK 评测仍不能完全代替目标桌面客户端的抽查。
三层共享测试语料，便于对照差异；独立循环和 Codex 的轨迹经规范化后共用工具调用评分逻辑。
测试默认值、歧义和数据缺口
原文内容整理
示例中，失业率有惯例默认值：季节性调整后的序列；笼统的就业人数则对应两个不同指标，且没有默认选项，应询问用户；消费者价格指数（CPI）不在示例目录内，应报告不可用，不能自行补出序列。
测试用例除了问题和预期结果，还用 mechanism 标注测试机制，用 expected_type 标注预期答案类型。这些标签用于报告筛选，不参与示例评分。
工具轨迹和答案需要分别检查
原文内容整理
示例评分器检查预期工具是否运行、预期序列是否返回、是否获取了额外序列，以及运行是否结束并给出非空回答。对于有歧义的就业问题，它检查是否避免获取候选数据。
但这些条件不能证明答案正确：评分器无法判断回答是否真正请求澄清，也不能确保回答准确陈述了检索结果。实际评测还需要答案层面的检查，文章生产实验使用独立的 LLM 评分标准。
同样的问题，不同框架得到不同结果
原文内容整理
演示记录中，独立循环通过五个用例，未提供服务器指导的 Codex 通过三个。一个失败是解析器没有返回 CPI 候选时，Codex 自行提供了一个 ID；另一个是就业指标存在歧义时，它获取候选数据而没有先澄清。
作者通过 MCP 服务器初始化时提供指导：先解析、不自行创造 ID、无候选时说明不可用、最佳候选并列时先询问。添加指导后的记录中五个用例均通过，工具逻辑没有改变。这是少量记录的示例，新运行可能不同。
生产实验与稳定性
原文内容整理
生产实验覆盖 56 项 BLS 调查的 108 个单轮问题，使用 LLM 对最终答案评分。文章比较不同模型和两种运行框架，观察到模型间差距会随框架变化。不同框架的提示词、工具以及执行步数等不同，因此不能把某个差距简单归因于单一因素。
三次重复实验中，总通过率为 86%–89%，但 108 个问题中有 23 个至少一次在通过和失败之间切换。总体分数稳定，不代表单题稳定；工具调用量也会波动。
可以带走的实践
原文内容整理
修改工具逻辑时先跑直接测试；迭代提示词和工具描述时使用独立循环；更换模型及发布前使用实际产品框架验证。构造看似合理却应当澄清或拒绝猜测的案例，并为用例标记测试机制。
关闭缓存重复测试，检查单题波动、工具调用和推理成本，并抽样人工审阅最终回答。对比评测轨迹与生产轨迹，确认提示、工具和运行时配置一致。本文是与 AI 讨论后整理的阅读笔记，具体实现和完整细节请参见原文。