今年 6 月我写过一篇 agent-next 的文章，讲怎么把测试 Agent 接进流水线。文章发出去以后，后台有人留言问，这套东西什么时候能开源。

当时开不了。它还是从一个具体项目里长出来的内部工具，能跑，但目录、知识、Skill 全带着原项目的痕迹，别人拿到手也没法用。我在那篇文章结尾留了一句话，换领域不换骨架，换模型不必重搭流程。这句话要能兑现，得先把长在原项目里的部分拆干净。

过去几个月，我们补的正是这句话后面的工程。补完之后它有了正式名字，Riqor，仓库也已经放到 GitHub 上，地址 https://github.com/phoenine/riqor。

1. 测试 Agent 的坎，在演示之后

丢一份 PRD 进去，几分钟出来需求分析、测试点和测试用例，这一步现在不难演示。真正接进团队流程以后，问题落在别处。

  • 已有的用例能不能复用，还是每次都重新生成
  • 需求改了一版，哪些下游产物已经过期
  • 一条风险结论到底来自 PRD、来自代码 Diff，还是模型自己脑补的
  • 用例格式不合格，流程能不能真的停下来
  • 执行测试、改共享数据、往禅道写入之前，谁来确认过

这些问题靠加长 Prompt 解决不了。它们要的是稳定的资产模型、运行状态、证据链和机器门禁。Riqor 做的，就是把这一层做成一套 Harness，能放进 Git、能跑测试、能按项目替换配置。Agent 负责理解和分析，CLI 负责记账、查依赖、裁决能不能进入下一阶段。

2. 把项目从 Core 里拆出去

从 agent-next 到 Riqor，最花力气的是把项目差异从 Core 里真正拿出去。改个名字反而是里面最轻的活。

现在项目、Track、仓库、知识目录、环境策略都由 Project Profile 描述。Feature、Bug、Release 的阶段顺序和 Gate 规则，放在声明式的 Workflow Pack 里。需求分析、风险分析、用例设计、自动化、执行、报告，由各自的 Skill 承担。具体产品的字段、接口和数据规则，不再是 Core 里的枚举或默认值。仓库自带的三套 Workflow 是 feature-quality、bug-regression 和 release-acceptance，分别对应特性测试、Bug 回归和发布验收。

新项目不用再复制一份引擎回去改。一条命令就能初始化。

1
2
3
4
5
6
agent-next init \
  --project-id my-product \
  --name "My Product" \
  --track web \
  --track backend \
  --default-track backend

命令行入口还叫 agent-next，跟仓库名对不上，看到命令别奇怪。

如果手里已经有 PRD、Bug、发布基线或者旧的测试用例，也不用从第一阶段重新来。Riqor 会先把现有资产盘一遍，再照着目标补齐缺的依赖。

1
2
3
4
5
6
7
agent-next inventory --project config/projects/my-product.yaml

agent-next plan \
  --project config/projects/my-product.yaml \
  --workflow feature-quality \
  --scope checkout \
  --goal test_cases

用户说的是「我要 checkout 的测试用例」，系统内部才需要回答该复用什么、补什么、先过哪一道 Gate。阶段顺序是系统的责任，不该变成用户的学习成本。

3. outputs 给人看，runs 给系统记账

早期实践里有个绕不开的矛盾。交付物既要方便人直接评审，又要带上 Artifact ID、修订版本、来源和 Gate 结果。全塞进 Markdown，文件会越来越像数据库；全藏起来，又丢了追溯能力。

Riqor 把两件事拆开。

1
2
outputs/<project-id>/features/<scope>/test-cases.md
runs/<run-id>/artifacts/<artifact-id>.json

outputs 里只放需求说明、风险分析、测试点、测试用例和报告这些读得懂的产物。runs 里记身份、版本、内容哈希、来源关系、证据和 Gate 状态。

上游需求从 REQ-001@1 更新到 REQ-001@2，下游用例不会继续假装自己是最新的。内容在 Gate 通过之后又被改过，哈希对不上也会被标出来。这套东西不指望 Agent 记得回头检查，状态和校验链自己会查。

4. 门禁会真的拦下来

Riqor 保留了最初那条原则。规则尽量写进工具和 Gate，文档里只留人需要看的部分。

一份测试产物要变成 ready，模板、内容、前置产物、证据、当前阶段规则得同时满足。模板里还有占位符、测试步骤和预期数量对不上、缺代码证据、上游已经过期，都会得到明确的 blocker。

1
2
3
4
5
6
agent-next status --run-id checkout-test-design
agent-next explain --run-id checkout-test-design
agent-next gate \
  --project config/projects/my-product.yaml \
  --run-id checkout-test-design \
  --mark-ready

远程写入、共享环境执行、共享数据修改、部署这几类动作，保留显式确认的边界。Riqor 可以把执行计划准备好，但不会把「用户让我分析一下」理解成「可以顺手改远端数据」。

5. 仓库里有一条能自己跑完的流程

仓库带了一个 shop-platform 示例，用 checkout 功能把 PRD、需求说明、风险、测试点、测试用例串起来，也准备了 Release 验收材料。克隆下来可以先做两件事。

1
2
3
4
5
6
python3 -m venv .venv
source .venv/bin/activate
pip install -e .

agent-next doctor --project examples/shop-platform/project.yaml
agent-next inventory --project examples/shop-platform/project.yaml

doctor 跑完会报四行 OK，项目、知识索引、18 个 Capability、16 个 Artifact Template 都在里面。仓库全量单测 232 项，全部通过。完整操作步骤在仓库 docs 的快速入门文档里，通用化过程中的取舍单独记了一份设计文档，链接都放在文末。

Riqor 现在还是 0.1.0.dev0。可运行的工作流、产物注册表、Stage Gate、模板和校验器都有了，也带面向 Codex 和 Hermes Agent 的 Skill 入口。它离点一下按钮就能替团队把测试全跑完的一体化平台还很远。真实项目要配自己的 Profile、知识目录和集成，自动化执行也受环境和授权限制。

这个边界值得写清楚。开源能起作用的前提，是这套做法可以被检查、被修改、被继续验证。直接照着 Demo 的预期来用，会失望的。

6. 写在最后

把一份测试用例写出来，现在越来越容易。难的是这份用例从哪来、经过了什么检查，需求变过之后还算不算数，下一步动作会不会越界。

之前那篇文章总结过一句话，Riqor 把这套骨架留了下来。

Router 指路，Workflow 定阶段，Skill 承载专长，Knowledge 解释领域，Tool 执行门禁。

开源版把具体项目从骨架里剥了出去。你可以只从一份 PRD 开始，也可以带着已有用例和代码变更进来，用仓库自带的三套 Workflow，或者按 Schema 加自己的流程。

如果你也在把测试 Agent 往真实工程里接，建议从 shop-platform 那条流程跑起。跑完想看看它为什么拒绝一份看起来写完了的用例，可以直接拆 Gate 的代码，也可以提 Issue 把场景丢过来。这种拒绝理由，往往就是下一步要补规则的地方。

仓库 https://github.com/phoenine/riqor

快速入门 https://github.com/phoenine/riqor/blob/dev/docs/quickstart-shop-platform.md

v0.1 设计文档 https://github.com/phoenine/riqor/blob/dev/docs/agent-next-generalization-v0.1.md

当前接口测试框架和web测试框架以及对应的skills还在调试中，着急的同学可以先试试鲜，也可以贡献一些建议和issue，谢谢。