Harness Engineering

目的：走出了“大模型玩具”的阶段，开始面对 AI 辅助研发真正的深水区。

大厂（比如 Google 内部的自动化代码生成中台、字节跳动的 AI 研发效能团队）在真正把 AI 生成的代码接入生产流水线时，有一个绝对的底线共识：“绝对不能只依靠 LLM 来验证 LLM 生成的代码。” 大语言模型存在固有幻觉，用“左脚踩右脚”的方式（比如让另一个 Agent 去 Review 代码）只能检查出明显的逻辑漏洞或代码规范问题，根本无法保证代码在物理机上能跑通。

切实可行的落地方案，核心逻辑是：将 AI 接入“确定性验证环境（Deterministic Execution）”，用机器语言和编译器来约束自然语言。

结合MetaGPT + Spec-kit 架构，以下是真正能在生产环境中落地的 4 道验证防线：

第一道防线：将 Spec 转化为“可执行的契约”（TDD 前置）

既然你已经用 Spec-kit 丰富并校验了业务需求，那么这个 Spec 的终点绝对不能只是一堆完美的 Markdown 文本。大厂的做法是让 Spec 直接映射为测试用例或接口契约。

• 落地手段 1：BDD（行为驱动开发）框架对接。 让 Spec-kit 的最后一环，强制输出 Cucumber/Gherkin 格式的自然语言测试用例（如 Given... When... Then...）。在 Harness 的流水线中，通过现成的测试框架（如 Pytest-bdd, Cucumber.js）去读取这些文件。
• 落地手段 2：OpenAPI/Swagger 强校验。 如果生成的是后端 API，Spec 必须先固化成 OpenAPI JSON/YAML 文件。生成的代码启动后，第一步就是用类似 Dredd 或 Prism 这样的契约测试工具，去向生成的接口发请求，验证返回的格式、字段类型是否与 Spec 100% 严丝合缝。

第二道防线：AST 语法树与静态代码分析（剔除低级幻觉）

AI 生成的代码经常会出现使用了未导入的包、类型不匹配、或者调用了废弃 API 的情况。这部分不需要跑起来，用传统的静态工具就能扫出来。

• 落地手段：集成工业级 Linter 和静态扫描。
• 如果是 Python，强制通过 mypy (严格类型检查) 和 flake8。
• 如果是 Java/Go，在 Harness 加上 SonarQube 或 Semgrep 步骤。
• 核心逻辑：一旦静态扫描报 Error，直接截断流水线。把报错的 Stack Trace（堆栈信息）作为 System Message 原封不动地扔回给 MetaGPT 的 Coder Agent，让它基于真实的报错信息进行修改，而不是凭空让它“再检查一遍”。

第三道防线：动态沙箱隔离执行（核心真理环境）

这是大厂验证 AI 代码最重、也是最有效的一环。代码必须在真实的 Runtime 中跑起来。

• 落地手段：轻量级容器化自动化测试。
• 在你的 Harness Pipeline 中，拉起一个纯净的 Docker 容器（或者更底层的 Firecracker 微型虚拟机，防止 AI 生成恶意代码破坏宿主机）。
• 将生成的代码和第一步生成的测试代码一起扔进去编译执行。
• 不仅要看 Exit Code 是否为 0，还要强制要求测试覆盖率（Test Coverage）必须达到设定阈值（比如 80%）。因为 AI 很聪明，它有时会生成空的测试用例来骗过流水线。你可以集成 Jacoco 或 Coverage.py，覆盖率不达标直接判定生成失败。

第四道防线：属性测试与模糊测试（防御 AI 的边界黑洞）

AI 写代码最大的问题是“Happy Path（理想情况）”写得极好，但一遇到边界条件（如空指针、极大值、并发冲突）就容易崩溃。

• 落地手段：引入 Property-Based Testing（属性测试）。
• 不要指望 AI 能穷举所有极端的测试输入。你可以使用类似 Python 的 Hypothesis 或者 Java 的 jqwik 库。
• 你只需要在测试框架中定义“这个函数接收一个整数”，模糊测试框架会自动生成成百上千个极其诡异的整数（负数、0、MAX_INT）去轰炸 AI 生成的代码。只要大批量随机轰炸不抛出异常，这段代码的健壮性基本就达到了生产可用级别。

---

总结：你的 Harness Pipeline 终极形态

一个大厂级别的、以验证为核心的 AI 研发工作流，映射到你的 Harness 平台上应该是这样的流转机制：

1. 需求分析节点：MetaGPT 分析需求 -> Spec-kit 输出需求文档 + API 契约 (JSON) + 行为测试用例 (BDD)。
2. 代码生成节点：MetaGPT Implement 产出业务代码。
3. Harness CI 节点 (验证引擎)：

• Step 1：静态代码检查 (Semgrep / SonarQube)。(失败则将报错回传生成节点)
• Step 2：动态沙箱运行单元测试与契约测试。(失败则将 stderr 回传生成节点)
• Step 3：模糊测试边界验证。(失败则回传)

4. 人工/终态确认节点：只有经过机器编译器验证、覆盖率达标的代码，才会生成最终的 Merge Request (PR)，交由人类做最后的业务逻辑 Review 或直接部署上线。

这条路径的本质是把“人类审查 AI”变成了“编译器和测试用例审查 AI”。

在实践这条链路时，你的 MetaGPT 和 Spec-kit 产出的中间态数据结构是什么样的？是纯文本的 Markdown，还是带有结构化的 JSON？