为什么代码 Agent 已经会测试，还要做 LingTest CLI？

代码 Agent 让开发变快了，也让“谁来独立验收”这个问题变得更明显。LingTest 想做的不是另一个写代码的 Agent，而是让不同 Agent 都能调用的一套测试方法、受控执行器和证据报告。

起因：写代码的 Agent，也在给自己的代码打分

Codex、Hermes、OpenCode、Cursor 等工具已经能读需求、改代码、运行测试。对没有专职 QA 的小团队来说，一个 Agent 从需求做到功能上线，越来越常见。

问题不在于 Agent 不会测试，而在于实现和验收往往来自同一段上下文：Agent 先根据需求补全假设，再按自己的实现方式编写测试。测试可能覆盖了代码“现在怎么做”，却没有发现需求中遗漏的场景、错误的业务假设，或根本没有被实现的行为。测试通过了，说明这些断言通过了，不自动代表产品符合用户预期。

另一个实际问题是测试结论不容易复核。有人说“接口测过了”，但没有说明测了哪个版本、用了什么账号和数据、预期从哪里来、失败时返回了什么。401 未登录究竟是产品权限 Bug，还是测试根本没拿到 token？一个红色状态无法回答这些问题。

所以，AI 开发需要的不是单纯增加测试数量，而是让验收依据、执行过程和结果证据独立于代码生成过程，并且能交给人和 CI 复查。

为什么不只写一个 Skill？

测试经验很适合做成 Skill：告诉 Agent 先读项目约定和需求，选择有价值的场景，检查鉴权与数据条件，谨慎执行会改数据的操作，并用证据报告结果。Skill 是开放、轻量的，也可以不依赖 LingTest CLI，直接配合项目已有测试工具使用。

但仅靠自然语言指令，很难保证每次执行的输入格式、HTTP 行为、鉴权门禁和报告结构都一致。不同 Agent 可能用不同方式执行同一套测试，CI 也不适合解析一段自由文本来判断通过或失败。

因此 LingTest 采用两部分组合：

• 公开 Skill 负责跨 Agent 复用测试经验，说明如何规划、审阅、执行和解释测试。
• LingTest CLI 负责结构化用例、确定性 API 执行、安全门禁、暂停恢复和机器可读报告。

代码 Agent 仍然负责理解项目、调用工具和处理后续修改；LingTest 给它一条可重复的验收路径。两者通过命令行和文件交互，不绑定某一家模型或 Agent。只想使用测试方法时可以只用 Skill；需要统一的 API 回归和证据格式时再安装 CLI。

LingTest CLI 目前能做什么

LingTest 从 PRD、OpenAPI 和项目测试说明中整理测试风险与候选场景。测试用例可以先保存成普通文件，由开发者或 Agent 检查预期、账号角色、数据前置条件和请求内容，再决定是否执行。OpenAPI 提供的结构约束可以用于生成确定性 API 用例；需要补充业务场景或分析失败时，也可以配置模型 Provider。

鉴权是接口验收的前置条件，而不是失败后再猜的原因。LingTest 可以结合 OpenAPI 和项目提供的登录说明生成可审阅的鉴权计划：登录请求从本机配置读取测试凭据，取得 token 后传给下游受保护接口。密码、token 等秘密不应进入用例、检查点、事件和报告。缺少鉴权方案或有效凭据时，工作流会阻塞；没有计划的 401/403 也按鉴权问题处理，避免误报成产品 Bug。

测试数据同样要先说明来源和准备方式。需要补充角色、测试数据或审批时，工作流可以暂停，用户补充后从保存的检查点恢复。LingTest v1.0 不要求用户交出数据库账号，也不会让模型自动生成或执行 SQL、存储过程来造数。优先复用项目已有 fixture、factory 或有文档的测试 API；缺少安全的数据准备方式时，把相关场景标记为阻塞并说明原因。

默认验收路径是黑盒 API 测试。如果用户授权查看源码，Agent 还可以启用代码感知诊断，结合失败证据和相关代码提出 Bug 根因候选，并给出可能代码位置、依据、置信度和下一步验证建议。对于合适的失败用例，lingtest suggest-tests 能生成单文件单元测试 diff。默认只生成建议，不直接改项目文件或运行项目命令；是否应用和执行由用户或上游 Agent 明确决定。

报告提供 JSON、HTML 和 JUnit XML，工作流还提供可供 Agent/CI 使用的 JSONL 事件。报告除了通过或失败，也会保留目标、需求引用、请求响应证据、阻塞原因和可选根因候选。代码诊断给出的是待验证假设，不是模型替团队确认的 Bug。

这个方案的优点

1. 不依赖特定代码 Agent。 Hermes、Codex、OpenCode 等只要能运行本机命令、读写文件，就能调用 CLI；测试方法可通过公开 Skill 复用。
2. 测试结果可重复、可复查。 用例和报告是结构化文件，确定性执行不必调用大模型，方便本地重跑或接入 CI。
3. 把常见前置问题显式化。 鉴权、测试角色和数据准备不足时先阻塞，减少把环境问题当成产品缺陷的情况。
4. 兼顾黑盒验收和可选白盒诊断。 默认按需求和接口观察外部行为；获准后再看相关代码，帮助缩小根因范围、设计回归测试。
5. 人能在关键步骤介入。 计划可以审阅，缺少输入时可以暂停，修改测试文件或运行项目命令也需要明确选择。

它的局限也很明确

• LingTest 不能替代清晰的需求、项目维护者和人工判断。如果没有可靠的业务预期，OpenAPI 通常只能说明接口形状和状态码，不能推断完整业务规则。
• 当前主要解决 API 验收与回归，尚未提供 Playwright 浏览器 UI 自动化。页面交互、视觉布局和跨浏览器行为仍需使用项目现有工具。
• LingTest 不会自动连接任意业务数据库造测试数据。团队需要提供安全的 fixture、测试工厂或测试 API；否则依赖该数据的用例只能等待准备。
• AI 根因分析和测试建议可能出错。根因候选要用需求、代码和复现结果验证；生成但未执行的单测不能算通过。
• 真实环境、有效账号和允许的副作用仍由项目方负责。使用前要确认目标环境，不能把生产账号或秘密写入 Prompt、仓库或报告。
• CLI 和 Skill 让测试流程更一致，但不会自动保证覆盖充分。仍需要团队选择高风险场景并持续维护需求和测试数据。

直接让 Hermes 等 Agent 安装并调用

目前可以从 GitHub 安装 CLI。确保运行 Agent 的环境已安装 uv，然后让 Hermes、Codex 或 OpenCode 在项目终端执行：

uv tool install "lingtest-cli @ git+https://github.com/sunweitest/lingtest-cli.git@main"
lingtest --help

公开 Skill 与使用说明在仓库的 skills/lingtest-testing/。把 Skill 安装到所用 Agent 支持的目录，或让 Agent 直接读取其中的 SKILL.md。然后可以这样交代任务：

请按 LingTest Testing Skill 验收当前项目。
先检查项目说明、PRD、OpenAPI、鉴权文档和现有测试数据准备方式；
生成并审阅 API 用例后再执行。缺少登录配置或测试数据时先暂停并告诉我，
不要猜测凭据或连接数据库造数。报告保存为 JSON、HTML 和 JUnit。
如果需要读取源码做根因诊断，先确认授权，并只查看与失败相关的文件。

如果当前项目还没有有效的测试账号、登录文档或可复用数据，Agent 应先向开发者询问并等待配置，而不是把 401、空数据或环境错误报成应用 Bug。CLI 的安装状态、命令和配置细节以仓库 README为准。

下一步：Playwright UI 自动化

目前的 API 测试不能回答“用户能否在浏览器里完成整个操作”。后续可以考虑让 LingTest 生成并管理 Playwright UI 场景，覆盖登录、表单提交、关键页面跳转和重要状态变化，并把截图、浏览器 trace、控制台错误及断言结果纳入同一份验收证据。

这项能力需要沿用现有原则：使用项目认可的测试账号和数据准备方法；执行前明确目标环境及会产生的副作用；失败时区分选择器或浏览器环境问题与产品缺陷；源码或页面对象辅助诊断仍是可选项。具体接口和工作流要在需求明确后设计，当前版本不应被误认为已经具备 UI 自动化。

结语

LingTest CLI 的前因，是代码 Agent 把实现和自测都变得很容易，却没有自动解决验收标准、测试前置条件和结果可信度的问题。它的做法是把测试经验开放为 Skill，把重复执行和证据交给轻量 CLI，并允许不同 Agent 使用同一套验收流程。

它不是万能 QA，也不是要替换 Hermes 等代码 Agent。让 Agent 继续构建产品，让 LingTest 帮忙把“看起来能用”变成有依据、可复现、可交接的验收结果。

项目仓库：GitHub: sunweitest/lingtest-cli