最近有个账号在各种 harness 相关的评论里推广他的 skill ，recursive-mode ，做法主要是上下文持久化，流水线，闭环验证。前天还有篇论文方案类似，更系统些。AI 模型能写一次性软件了，但 AI 写不好需要长期持续运行与运维的软件基础设施。论文提出了 meta-engineering harness ，是个七层架构：

第三层契约 Contract ，代码质量取决于契约的完备性。论文里给了契约的例子.

{
  "module": "NGPayments",
  "version": "1.0.0",
  "api": {
    "base_path": "/ng/payments",
    "auth": "Supabase Bearer token; JWT identity authoritative",
    "endpoints": [
      {
        "method": "POST",
        "path": "/ng/payments/intent/:invoiceId",
        "returns": [
          "client_secret",
          "payment_intent_id",
          "payment_type",
          "amount_cents"
        ],
        "side_effects": [
          "store payment_intent_id on invoice",
          "set invoice.payment_status = processing"
        ],
        "errors": [
          "403",
          "404",
          "409",
          "422",
          "502"
        ]
      },
      {
        "method": "POST",
        "path": "/ng/payments/confirm/:invoiceId",
        "stripe_verification": "retrieve PaymentIntent and assert status == succeeded before DB write",
        "side_effects_on_success": [
          "set invoice payment status",
          "set service request status",
          "set paid_at",
          "clear payment_intent_id"
        ],
        "side_effects_on_failure": [
          "reset invoice.payment_status to unpaid",
          "clear payment_intent_id"
        ]
      },
      {
        "method": "GET",
        "path": "/ng/payments/status/:invoiceId",
        "returns": [
          "payment_status",
          "payment_type",
          "amount_cents",
          "currency",
          "paid_at"
        ]
      }
    ]
  },
  "invariants": [
    "PaymentIntent uses transfer_data.destination",
    "no platform fee",
    "server verifies Stripe success before DB write",
    "paid is terminal",
    "processing blocks duplicate intents",
    "amount derived from quote_data.total"
  ],
  "known_gap_identified_after_deployment": [
    "final invoice calculation omitted offline deposits",
    "discount calculation not encoded in original contract"
  ]
}

第二层不同的角色：

• 构建器 (Builder / Implementation Agent)： 负责干活的 AI 。它拿到编译好的契约后，负责编写实际的业务代码。它无权干涉测试。

• 验证器 (Verifier / Test Agent)： 负责挑刺的 AI 。它拿到同一份契约后，独立编写对抗性测试用例。为了保证客观，它被物理隔离，完全看不到构建器写的代码，只针对契约写测试。

• 审查员 (Reviewer)： 负责多维度走查的 AI 。它可以分身为“产品审查员”、“安全审查员”、“架构审查员”等，从不同专业视角静态检查系统是否存在漏洞或体验问题。

• 仲裁器 (Arbiter)： 负责定责的 AI 。当测试不通过（即 CI 报错）时，仲裁器负责判定这是谁的责任：是构建器写了 Bug ？是契约遗漏了规范？是测试环境的噪音？还是契约本身有歧义？

另外有个回顾代理（ Retro agent ）在第七层，不负责执行单次编程任务，是审查历史失败记录（回顾，retros ）来进行系统级的反馈与改进。人类工程师负责最终审批与治理。

核心的流水线（ Pipeline ）有 7 个环节：

1. 接收契约（实现端）： 实现代理（ Implementation agent ）接收通过预流水线阶段编译好的结构化契约 。

2. 接收契约（测试端）： 测试代理（ Test agent ）同步接收同一份编译好的结构化契约 。

3. 编写代码： 实现代理根据契约规范开始编写具体的业务代码 。

4. 编写测试： 测试代理根据契约规范独立编写对抗性测试用例 。

5. CI： 系统运行上述对抗性测试，对实现代理编写的代码进行行为检验 。

6. 失败路由： 测试未通过，相关的失败结果会被自动路由至仲裁器（ Arbiter ） 。

7. 分类与决策： 仲裁器将收集到的失败结果分类为代码漏洞（ Bug ）、规范缺失（ Spec gap ）、环境噪音（ Noise ）或契约歧义（ Contract ambiguity ），并由该分类结果直接决定下一步采取何种纠正措施 。

提到 Over-specification （过度规定）可能导致下游的 AI 代理（实现代理和验证代理）会将契约中所有的需求视为强制性（ mandatory ）命令 。如果契约中包含了系统环境不支持、或者业务根本不需要的复杂需求，AI 代理会强行尝试实现和测试这些幻觉需求，导致开发周期浪费、代码冗余，或由于无法通过自动化测试而陷入死循环。还举了失败例子，代码完全符合契约，也不代表代码满足了真实的业务需求。

高质量的 AI 代码是一个不断自我完善的闭环。AI 代码质量的保障已经从模型层面的能力问题，演变为系统工程层面的验证与治理问题。人类工程师的角色也从编写代码转为“设计契约、处理异常、并监督/改进这个自动编写和测试代码的生产系统”。

论文总结的缺陷和现在 AI vibe coding 遇到的问题类似：

• 契约不完整（ Contract Incompleteness ）：表现完全取决于契约的好坏。契约完备性是系统内杠杆率最高、尚未解决的问题。将“编写完美代码”的难题转移成了“编写完美需求规范”。

• 共享的模型盲点（ Shared Model Blind Spots ）：独立的代理可能仍然具有共同的偏见，如果构建代理和验证代理底层都调用相同的大语言模型，可能在面对同样的逻辑漏洞时产生相同的幻觉或盲区。

• 人力瓶颈（ Human Bottlenecks ）：某些决策需要人工判断，包括产品意图、信任边界、模棱两可的权衡取舍以及故障分类。在大规模运作时，人工干预必须变为仅基于异常情况的处理。这表明该系统目前无法实现完全的自治，其扩展性受限于高级工程师或产品经理的人力投入。

• 上下文与记忆漂移（ Context Drift ）： 记忆可能会变得陈旧、臃肿或相互矛盾。压缩降低了这种风险，但并未消除它。当软件系统长期演进，早期的架构决策或记忆文件如果不被彻底清理，会导致 AI 提取到冲突的上下文，进而产生执行混乱。

• 验证覆盖范围的局限（ Verification Coverage ）和 成本、延迟与安全性（ Cost, Latency, and Security ）。