最近有个账号在各种 harness 相关的评论里推广他的 skill ，recursive-mode ，做法主要是上下文持久化，流水线，闭环验证。前天还有篇论文方案类似，更系统些。AI 模型能写一次性软件了，但 AI 写不好需要长期持续运行与运维的软件基础设施。论文提出了 meta-engineering harness ，是个七层架构：
层级 (Layer) 核心模块 (Core Module) 包含内容与机制 (Components & Mechanisms) Layer 7 (第 7 层) Calibration (校准) 回顾、回归升级、契约模板更新 Layer 6 (第 6 层) Verification (验证) 对抗性测试、审查网关、QA 、CI Layer 5 (第 5 层) Execution (执行) coding agents, migration agents, UI agents Layer 4 (第 4 层) Context / memory (上下文/记忆) AGENTS.md, markdown brain, spec 记录 Layer 3 (第 3 层) Contract (契约) two-pass compilation, invariants(两遍编译、不变量) Layer 2 (第 2 层) Role / orchestration (角色/编排) builder, verifier, reviewer, arbiter Layer 1 (第 1 层) Model (模型) Claude, Codex, Gemini
第三层契约 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 个环节：
-
接收契约（实现端）： 实现代理（ Implementation agent ）接收通过预流水线阶段编译好的结构化契约 。
-
接收契约（测试端）： 测试代理（ Test agent ）同步接收同一份编译好的结构化契约 。
-
编写代码： 实现代理根据契约规范开始编写具体的业务代码 。
-
编写测试： 测试代理根据契约规范独立编写对抗性测试用例 。
-
CI： 系统运行上述对抗性测试，对实现代理编写的代码进行行为检验 。
-
失败路由： 测试未通过，相关的失败结果会被自动路由至仲裁器（ Arbiter ） 。
-
分类与决策： 仲裁器将收集到的失败结果分类为代码漏洞（ 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 ）。