如何用 Codex、CI 和 Apifox 接口测试搭建自己的 Software Factory

Gergely Orosz 画的 OpenAI 内部 software factory 这周到处在传：builder 提交一个 outcome，Codex 写代码，一队专科 review Agent 争论风险，再由一个 Agent 看着它自己搭的 dashboard 盯发布。对 OpenAI 自己的工程师来说，这张图里最关键的那些部分，描述的是你装不上的内部工具。

Perf Factory、Sevbot，以及带着自建 dashboard 的 agentic deploy，跑在 OpenAI 自己的可观测性栈上，并不包含在你能买到的 Codex 产品里。你这周能搭起来的，是一个更小、但仍能做实事的闭环：builder 把 outcome 写成 issue，Codex 在分支上干活，CI 检查这次改动是否真的按预期工作，一两个 reviewer Agent 看一眼，风险较高的改动由人签字，再放到 flag 后面发布。整件事卡在原图轻轻带过的一个细节：“CI passes” 只有在 CI 检查了该检查的东西时才有意义。对 API 来说，这意味着要测 API 本身，而不只是调用它的代码。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

这张图说对了什么（以及你复制不了什么）

The Pragmatic Engineer 那篇的公开部分描述了一个核心循环：Codex “makes a series of code changes until it reaches its goal, and then verifies that the software works as it should.” 低风险区域可以自动批准；更高风险的改动会多一轮 AI review，或强制过人。提出、验证、按风险分层审查，这套结构是可迁移的。团队用 PR bot 和 CI 闸门近似它已经很多年了；Agent 只是让这个循环更快、更少人盯着。

不可迁移的是周围的内部机械。Perf Factory 筛告警和 dashboard，找延迟回退并提议修复。Sevbot 调查事故、在 Slack 回答问题，但它自己不执行缓解。Agentic deploy 把改动送进生产，并用 OpenAI 内部遥测栈给自己搭监控。这三样都不在对外的 Codex 产品里。真正交出去的是桌面应用、用于长任务的 /goal 命令，以及你自己配置的 role plugin 和 skill。OpenAI 的 Codex 产品页写的才是实际能拿到的东西。

本周就能跑的五步闭环

缩小版大致是这样：

Builder 把 outcome 写成 issue。 不是任务清单，而是终态描述：“订单可以带一个可选折扣码，用来减少总额。”把同一个 GitHub issue 交给 Sharkly 里的 Agent，就是已经交付的集成：issue 变成 Task，run 回来是 PR，而不是另一张需要对齐的工单。目前对 10 人及以下的组织免费。
Codex 用 /goal 在分支上干活。 正如 how the /goal command drives autonomous Codex and Claude Code runs 所写：你给 Agent 一个目标，让它自己迭代直到目标达成。
CI 跑 build、单元测试和接口测试场景。 这是大多数团队跳过或只做一半的一步。
一两个 reviewer Agent 看 diff，高于低风险的改动由人审查。 AI code review tools 能在人打开 PR 之前拦住不少问题。在 Sharkly 里，Ready for Release 承担这件事：必须由人把任务移出这个状态，才能到 Done；另一个 reviewer Agent 可以和写代码的那个待在同一个 Crew。
放到 feature flag 后面发布，这样一次糟糕的 merge 只是一次开关，而不是一次事故。

第 3 步决定这个闭环是真的在工作，还是在骗你。

为什么 CI 必须测 API，而不只是测代码

Codex 自己的 review 功能（how Codex code review works 里讲过）会读 diff、标出明显问题。它不会把你的服务跑起来，检查实际返回什么。单元测试——如果 Agent 写了或留着——大多验证代码做了代码想做的事，这并不等于验证 API 做了契约承诺的事。Agent 改一个 handler，可以让所有单元测试都过，同时悄悄弄坏每个客户端都依赖的响应。

假设你跑一套 orders API。POST /api/orders 创建订单并返回记录；GET /api/orders/{id} 按 ID 取一条。两边都有 OpenAPI spec，你也用 Apifox 对着它建了测试场景：创建订单、再取回来，并检查单元测试通常不会查的四件事：

Status codes。 POST /api/orders 返回 201，而不是 200，也不是校验边界上静默的 500。
对照 OpenAPI spec 的响应 schema。 total_amount 仍然是 number，status 仍然是你定义的枚举值之一，客户端依赖的字段不会悄悄消失或被改名。
Auth 失败。 没有有效 token 的请求返回 401，而不是 200 加空 body——这种回归出奇地常见。
延迟阈值。 场景断言响应必须在设定时限内回来，这样 handler 里多一次未批量的数据库调用，会在客户察觉之前被抓住。

这些恰恰是 handler 级重构能在所有单元测试仍通过时悄悄弄坏的检查，因为单元测试通常会 mock 掉接口场景真正在锻炼的那条边界。

接到流水线里

如果你跟过 how to use the Apifox CLI in Codex，这些场景的 CLI 版本你本地已经在跑。同一条命令可以进 CI。一个先 build、跑单元测试、再跑 Apifox 场景的 GitHub Actions job 大概长这样：

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  build-test-verify:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Build and run unit tests
        run: npm run build && npm test

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run orders API test scenario
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
        run: |
          apidog run \
            --access-token $APIDOG_ACCESS_TOKEN \
            -t 88214 \
            -e 3301 \
            -r cli,junit

      - name: Upload Apidog reports
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-reports
          path: apidog-reports/

-t 和 -e 的值是你在 Apifox 里真实的场景和环境 ID，不是自己编的占位符。apidog run command reference 覆盖每个 flag，Apifox CLI test reports 解释 job 上传的 JUnit 输出。apidog run 在任何断言失败时以非零退出，所以 GitHub Actions 会像单元测试失败一样把 job 标红。

Agent 的 prompt 长什么样

/goal 的要点是：你描述 outcome 和退出条件，Codex 迭代时不必每一步都等你批准。对折扣码这个例子，比较合理的 prompt 是：

/goal Add an optional `discount_code` field to POST /api/orders. Validate it
against the promotions service and apply the discount to `total_amount` in
the response. Do not rename or remove any existing response field. Run
`npm test` and `apidog run --access-token $APIDOG_ACCESS_TOKEN -t 88214 -e 3301
-r cli` before you finish. Both must exit 0. If the Apidog run fails, read the
failing assertion and fix the handler, not the test.

最后一句很关键。Agent 在压力下要把检查变绿时，有时会去改断言而不是改 bug。明确告诉它该修闭环的哪一侧，测试场景才会继续当 source of truth，而不是绕过去的障碍。

当 Agent 弄坏契约

Codex 加上了折扣字段，过程中却把 total_amount 改成了 totalAmount，因为附近某个文件用的是这个约定。单元测试仍然通过：它们查的是折扣算术，不是字段名。Build 成功。然后 Apifox 场景在 CI 里跑，对照 OpenAPI spec 校验响应，失败了：spec 写的是 total_amount，响应现在是 totalAmount，schema 断言立刻抓住它。

CI 报告非零退出，并指向 JUnit 输出里失败的 schema 断言。Codex 读到失败，看出原因是改名，于是撤回改名、保留折扣逻辑。场景通过，build 变绿，PR 进入 review 时，“passing” 这个词后面才有实际保证。没有接口级检查，这次改名会直接上线，所有解析 total_amount 的客户端都会在下一版炸掉。

可以用 spec 落地的风险分层

与其凭感觉判断什么算低风险，不如把风险分类绑到 OpenAPI diff 上。增加一个带默认值的可选字段，测试通过后可以考虑自动合并。删除字段、改名，或改 status code，无论 diff 其余部分看起来多小，都绝不是低风险。这一条规则已经能拦住专科 review Agent 多半会标出来的问题。规则标红的改动，在 merge 前交给人审，或再过一遍 AI code review tool。

放到 flag 后面发布，而不是直接冲进虚空

改动过了 CI 和 review 之后，放到 feature flag 后面发布，而不是直接给所有用户。这是 OpenAI agentic deploy 那一步的廉价替代：没有 Agent 盯着 rollout，也没有自建 dashboard。flag 从 5% 流量开始，由人看过错误率再打到 100%，就能拿到大部分安全，而不需要那套内部工具。出了问题，关掉 flag，而不是在压力下回滚一次 merge。

已经有一份脚手架

五步不必从零接线。orchflows 是 Orosz 帖子回复里冒出来的开源项目：一份 MIT 许可的 /software-factory 命令，给 Claude Code 和 Codex 用，围绕少量可复用 skill。它是起点脚手架，不是上面 CI 和 review 步骤的替代；你仍然要把它指向自己的测试场景和风险规则。

哪些不要去造

不要试图复刻 Perf Factory、Sevbot，或带着自建 dashboard 的 agentic deploy。它们是接到大多数团队并没有的遥测上的 OpenAI 内部系统。OpenAI 里仍然由人定义 outcome、批准高风险改动、授权事故缓解、值班 oncall；用他们的话说，“oncall duty is not a thing of the past.” 复制的是工程纪律本身：merge 前先验证，按实际改动分层风险，对显然不安全的事情留一个人。

先把闭环跑起来

从 CI 这一步开始；它让后面每一步都可信。在 Apifox 里给 orders API 建测试场景，覆盖 status codes、schema、auth 和延迟预算。用 CLI 接到流水线，把 /goal 指向一个真实 issue，让 Codex 对着真正断言 API 行为的检查迭代，而不是信 Agent 自己说的。先把第一个场景建起来，闭环证明自己之后，再加 reviewer 和 flag 步骤。