让 Agent 真正会用你的产品：用 Gauge CLI 测试 Skills、CLI 与文档
你发布了一个 CLI、MCP 服务或 Agent Skill，文档也写得很完整，但用户的编码 Agent 仍可能卡在交互式提示、调用过时命令，或把产品能力说错。传统测试验证程序是否按预期运行，却很少验证另一个模型能否发现并正确使用这些开发者接口。Gauge CLI 正是针对这类“Agent 使用体验”（Agent Experience，AX）提供本地测试循环的开源工具。
Gauge 由 gauge-sh 维护，仓库使用 MIT 许可证。它让 Claude Code、Codex、Pi、OpenCode 等 Agent 实际尝试你的 CLI、SDK、Skill 或文档，记录它们遇到的困惑，再用预发布版本重跑任务，观察修改是否改善结果。重点不是给文档打分，而是用真实交互找出可复现的问题。
从“看文档”转向真实任务
Gauge 的 README 列出的常见发现包括：Agent 被交互式命令卡住、调用旧命令、忽略本应使用的 Skill、误判产品限制，或者无法理解多个命令如何组合成工作流。开发者可以把这些失败当成产品缺陷来修，而不只是继续追加提示词。
本地 CLI 在 Docker 容器中运行 Agent harness；用户使用自己已有的订阅或 API 凭据，不必创建 Gauge 账户即可跑通本地测试。会话事件会规范化为统一 transcript，并在本地与 SQLite 结构化数据一起保存，便于后续分析。托管计算是另一种可选路径，可提供更多并发、团队协作等能力，不应与本地运行混为一谈。
建立一轮可重复的体验测试
项目 README 给出的起点是从 npm 安装 CLI。最低前置条件包括 Docker，以及你要运行的 Agent 工具；不同 harness 的登录与配置仍需按各自说明完成。
npm install -g @withgauge/cli gauge --help
安装后先查看当前版本 CLI 自带的帮助和官方文档，按项目要求配置目标产品与测试任务。不要凭本文猜测子命令或配置字段：CLI 正在迭代，具体选项以对应版本的帮助输出为准。一个有效任务应尽量贴近用户目标，例如“根据快速入门创建一个最小项目并启动开发服务器”，并确保测试环境能安全访问所需资源。
第一轮运行后，重点检查失败轨迹，而非只看 Agent 最终是否成功。若它停在需要键盘确认的命令，优先考虑增加非交互模式；若它持续调用旧参数，检查文档、示例和发布包是否版本一致；若它忽略 Skill，则核对触发描述、安装位置和任务上下文。每次只改一类问题，再用相同任务重跑，避免把偶然成功误当作稳定改善。
用预发布产物验证修复
Gauge 的价值在闭环：把尚未发布的 Skills 或代码产物注入后续测试，让 Agent 在公开发布前试用修订版。这样可以检查修复是否真正消除障碍，也能发现新文档与旧接口之间的冲突。对 SDK 或 CLI，最好将任务拆为安装、发现入口、完成常见操作和处理错误四类，并记录每类的成功条件；对于文档，则让 Agent 从零开始完成一个明确目标，而不是只要求总结页面。
测试边界也要清楚。Agent 的轨迹反映特定模型、版本、提示与环境组合，不等于所有用户都会遇到相同结果；单次跑通也不是正确性的证明。Gauge 可帮助定位 Agent-facing 的摩擦，但不会替代单元测试、安全审查、人工核对或真实用户反馈。涉及私有代码、密钥和生产系统时，应先检查容器与凭据隔离，并使用专门的低权限测试环境。
适合哪些团队
如果你维护的是面向 Agent 的 CLI、MCP、SDK、Skills 或开发者文档，Gauge 提供了一种把“模型到底会不会用”纳入发布前检查的思路。它尤其适合已有可重复任务、能够提供预发布产物的项目。若只是想验证普通函数逻辑，常规测试框架更直接；若没有稳定的测试目标，先写清用户任务与成功标准，比立刻引入自动化更重要。
把 Agent 当成真实用户来测试，不能保证它永远不犯错，却能把许多“文档看似清楚、实际操作卡住”的问题提前暴露。对正在建设 Agent 生态的开发者而言，这是一层有用的产品质量反馈，而不是取代现有测试体系的新魔法。
相关链接