先看证据
从模型回答，转向应用接口
Simon Willison 于 2026 年 10 月 18 日发布了 llm-echo 0.5。它是 LLM 命令行工具的调试插件，提供一个名为 echo 的“模型”：不调用外部 API，也不运行本地 LLM，而是把应用交给模型的内容回显出来。插件面向的不是生成更好的回答，而是检查应用实际发送了什么。
这次更新来自一个很具体的开发场景：Willison 正在准备新的 LLM 版本，测试 PR 时重新检查了这个插件。0.5 将模拟用量统计扩展到 system prompt、工具调用和推理文本。变化的重点不是回答能力，而是让测试能够覆盖更多模型集成接口，而不必每次都把真实模型拉进来。
回显让输入成为可检查的对象
echo 把 prompt、system prompt、附件和对话历史等信息以 JSON 形式回显。这样，测试关注点可以从“模型是不是给了好答案”挪到更基础、也更容易定位的问题：客户端是否把预期内容传对了，历史记录和附件有没有进入请求，system prompt 是否在调用中保留。由于没有真实模型参与，模型输出波动也不会遮住这些接口问题。
插件还提供了测试工具调用的入口：可以在输入 JSON 中指定 tool_calls，检查应用如何处理工具调用流程，而不依赖模型现场生成一次调用。对于正在改客户端或提示词组装逻辑的团队，这种固定输入的方式有助于把回归测试的对象缩小到应用行为本身。它不能替代真实模型上的端到端验证，但能减少把接口接错误认为模型表现不稳定的机会。
用量字段也进入测试范围
0.5 的另一项变化，是模拟 token 用量现在会考虑工具调用、system prompt 和推理文本。作者给出的命令是 `uvx --with llm-echo llm -m echo 'hi there' -o thinking 1 --usage`。其中 `-o thinking 1` 会输出两段预设的推理文本，随后回显输入内容并显示用量：示例报告为 2 个 input tokens、24 个 output tokens。
这个例子说明，测试可以同时经过提示词、推理输出和用量报告这些环节，而不只检查一段普通文本是否原样返回。对应用开发者来说，能否正确读取和展示 usage、能否在工具调用或 system prompt 存在时仍走通相关代码，都可以成为自动化测试的一部分。0.5 要求 LLM 0.36 或更高版本，因而也需要把插件与命令行工具的版本兼容性纳入测试环境。
模拟计数不是账单预测
这里最容易误读的是示例中的数字。2 个输入 token 和 24 个输出 token 是插件给出的模拟统计值，不是真实模型调用的账单，也不能据此推断它和某个模型的 tokenizer 一致。公开说明没有提供具体计算公式，也没有给出模拟值与真实用量之间的误差范围。
因此，0.5 扩大的是可测试场景，不是计量精度。它可以证明应用在测试条件下接收到了用量字段、执行了相应处理，却不能证明生产环境的 token 统计准确，更不能单凭它估算成本。若工程目标是验证预算或账单，就仍需要真实模型调用和相应的用量数据作为依据。
把它放在回归测试的位置
对技术负责人而言，llm-echo 更像一个面向模型接口的测试替身。可以把它放进 PR 或自动化测试中，检查 prompt 组装、工具调用流程、推理文本及 usage 字段的处理是否因改动而回归。由于它不访问外部 API，也不运行本地模型，这类测试能把客户端集成问题与模型输出差异隔离开来。
但测试替身验证的是约定和流程，不是模型行为。它不能说明真实模型会不会选择调用工具、推理输出是否符合预期，也不能替代对真实服务的延迟、成本和响应质量检查。实际做法应是分层：用 echo 快速、稳定地覆盖应用接口，再用真实模型测试那些只有真实模型才能回答的问题。这样，llm-echo 0.5 的位置就很清楚：它让集成测试少依赖模型，却没有让模型测试变得可有可无。