AI 编程已告别「选模型」时代：决定 AI 代码可不可信的是 Model、Harness、Loop、Graph、Factory 五层架构

过去两年，开发者最熟悉的问题是「哪个模型写代码最好？」。据 Code Web Không Khó 的一篇文章（作者以个人视角改写，灵感来自 Sumant Thakur 在 Substack 上的原文），这个问题已经过时：模型如今只是一个生成代码的「工人」，代码可不可信，取决于环绕它的五层系统——Model、Harness（运行环境）、Loop（试错—验证循环）、Graph（多智能体协同图）与 Factory（规模化运营层）。智能体负责提议，系统与人类负责决定；作者认为，与其问哪个模型最好，不如问六个问题：上下文、修改权限、证据、决定权与留给人类的环节。

快速回答

• Model 如今只是「创造者」：标准工作流不再以「做这个功能」开头，而是以一份已批准的规格（spec）开头——预期输入输出、安全边界、验收标准、允许修改的范围，以及用什么证据证明任务完成。Planner 把规格拆成小任务，Builder 在隔离的工作区内执行，而且 Builder 不得给自己打分：由自动化检查打分、Evaluator 独立复核，人类保留最终合并权。
• Harness 是「工人」周围的环境：上下文、工具、权限与运行环境，决定模型的多少能力能在真实仓库里「存活」——模型决定能力上限，Harness 决定其中多少能变成产品。文章举例：OpenAI 的一个小团队用 Codex 写出了几乎一整个产品，五个月后达到约 100 万行代码、合并 1,500 个 PR，而团队起步时只有 3 名工程师（数据引自原文）。
• 可用的 Loop 必须有外部证据与停止条件：天真的「试—失败—重试」循环只会产生重复，不会产生可信度；错误必须先分类再决定是否重试，重试必须有上限，预算耗尽或错误超出智能体权限时必须停止或上交人类。Loop 有时最有价值的决定，是让模型根本不要运行。
• Graph 回答「下一步由谁或什么来行动」：多个智能体（研究、后端、基础设施）并行运行并在集成步骤汇合；不同错误走不同路线——代码错误回到 Builder，计划错误回到 Planning，缺少产品决策则停下来等人类。在这种架构里，Loop 成为一个节点，边（edge）成为工程决策。
• Factory 在规模层面运营这一切：当工程师并行运行数十个会话、跨越多种工具、模型、分支与项目时，上下文管理不再是一种提示技巧，而是基础设施。Factory 决定哪个 worker 接哪个任务、配什么上下文、权限与验证方式、人工检查点设在哪——由此 Codex、Claude Code、Kiro 等编程智能体成为更大系统中可互换的 worker。

为什么「哪个模型写代码最好」已经是个过时的问题？

原文的论点是：两年的模型之争遮住了一个简单事实——模型只是生产软件的系统中的一个组件。模型回答「我应该创造什么」，它生成代码；但代码可不可信，由周围的层决定：它被允许做什么、如何被验证、出错时回到哪里、最终由谁拍板。

文章把这个系统拆成五层：Model、Harness、Loop、Graph 与 Factory。模型之上的四层，正是 AI 编程周围正在形成的一门工程学科——工程师的工作从亲手写代码，转向设计让智能体可靠写代码的系统。

第一层 — Model：创造者不得给自己打分

Model 层最大的变化是任务的起点。按原文，如今的标准工作流不以「做这个功能」的指令开头，而以一份已批准的规格开头，其中写明：预期输入与输出、安全边界、验收标准、智能体允许修改的范围，以及需要什么证据才能宣告任务完成。

Planner 据此把工作拆成小块；Builder 在隔离工作区内执行。贯穿始终的原则是创造权与评判权分离：Builder 可以提议、可以执行，但不能宣称自己的成果正确。自动化检查按确定性标准打分，Evaluator 再加一层独立复核，人类保留最终合并权。用作者的话说：智能体提议——系统与人类决定。

第二层 — Harness：环境决定多少能力能「存活」

Harness 回答「智能体被允许、被装备去做什么」。它是模型周围的整个环境：获得的上下文、能用的工具、被授予的权限与运行环境。原文指出，大型团队正在这一层大力投入：

• OpenAI：一个小团队用 Codex 写出了几乎一整个产品；按原文，五个月后该产品达到约 100 万行代码、合并 1,500 个 PR，而团队起步时只有 3 名工程师。值得注意的不是代码量，而是工程师的工作变了：把意图写清楚、把仓库组织得让智能体能可靠地在其中「行走」、建立架构约束与检查机制。
• Anthropic：明确拆分 Planner – Generator – Evaluator 三个角色，原则是写出代码的人不得宣称该代码正确。

作者在这一层的结论令人印象深刻：模型决定能力上限，Harness 决定多少能力能在真实仓库里存活。同一个模型放进两个不同的 Harness——一边上下文混乱、权限泛滥、没有验证；另一边规格清晰、仓库为智能体优化、自动化检查齐全——产出的可信度天差地别。

第三层 — Loop：何时停止与何时重试同样重要

Loop 回答「还要继续吗」。原文区分两种 Loop。天真的 Loop 是无条件的试—失败—重试：它只产生重复，不产生可信度，因为智能体可能以不断增长的成本重复同一个错误。

可用的 Loop 需要两样来自其外部的东西：做决定用的证据，以及明确的停止条件。具体而言：错误必须先分类，再决定是否重试；重试次数必须有上限；预算耗尽或错误超出智能体权限时，Loop 必须停止或把决定上交人类。

原文举的例子是 Atlan 的 Sherlock 系统：每月约 11,000 条告警；加上一层「准入」（admission）过滤、在调用模型之前就拦下 85% 以上的告警后，调查时间从 10 分钟以上降到约 2 分钟（数据引自原文）。教训是：Loop 有时最有价值的决定就是模型不应该运行——在入口处滤掉不需要 AI 的工作，既省成本，也让真正需要模型的工作更快。

第四层 — Graph：不同的错误必须走不同的路线

Graph 回答「下一步由谁或什么行动」。图、DAG、工作流本身并不新；按原文，新的东西在节点内部：一个节点现在可以是规划智能体、编程智能体、集成步骤、策略检查、验证步骤、修复循环，或一个等待人工审批的点。

在这个图景里，专职智能体并行运行——比如一个智能体研究依赖、一个做后端、一个管基础设施——然后在集成步骤汇合。最重要的是错误的路由方式：代码错误回到 Builder，计划错误回到 Planning 步骤，而当缺少一个属于产品的决策时，图会停下来等待人类。

作者用两个观点收束这一层：在图架构中，Loop 成为一个节点，边成为工程决策——那些边正是过去只存在于资深开发者脑中的判断，如今被写成系统的显式结构。

第五层 — Factory：当上下文管理成为基础设施

Factory 回答「如何大规模运营并持续改进以上一切」。原文提到这一层正在形成的几个方向：Xirp 专注于会话、隔离工作区与可携带的上下文；Kiro Crew 增加了持久化执行、重试、重规划与长生命周期任务的协调；Warp Factories 则更进一步，协调整个软件开发生命周期。

所举例子是 Spotify：那里的工程师不再在一个仓库里运行一个助手，而是跨工具、模型、分支与项目并行运行许多会话；据原文，Xirp 平台已运行超过 36,000 个会话，设计目标是协调 50 个以上并行会话（数据引自原文）。到了这个规模，上下文管理不再是提示工程的一个小技巧——它是基础设施。

按原文所引 Warp 的区分，最上两层的边界变得清晰：Harness 运行 worker，Factory 决定哪个 worker 接哪个任务——配什么上下文、权限、验证方式，人工检查点设在哪里。其结果是，具体的编程智能体——Codex、Claude Code、Kiro——成为更大系统中可互换的 worker；Factory 才是选择并治理这些编程智能体的系统。

五层各自回答什么问题？

层	它回答的问题	核心内容
Model	我应该创造什么？	从已批准的规格生成代码；Planner 拆分，Builder 在隔离工作区执行，Builder 不给自己打分
Harness	智能体被允许、被装备去做什么？	上下文、工具、权限、运行环境；为智能体组织的仓库；架构约束与验证机制
Loop	还要继续吗？	基于证据重试、错误分类、重试有上限、明确的停止条件与上交人类的通道
Graph	下一步由谁或什么行动？	多个智能体/步骤并行并汇合；每类错误路由到正确的步骤；人工审批点位于图中
Factory	如何大规模运营并改进这一切？	在组织规模上编排会话、工作区、上下文与 worker；把编程智能体当作可互换 worker 来选择与治理

与其问「哪个模型最好」，不如问这六个问题

原文最后建议彻底换一组问题来评估一个 AI 编程系统：

1. 模型获得什么上下文？
2. 它被允许修改什么？
3. 它产出什么证据？
4. 谁决定任务完成？
5. 验证失败时怎么办？
6. 哪些决定仍然属于人类？

这六个问题依次触及全部五层：上下文与修改范围属于 Harness；证据与验证失败的处理属于 Loop 与验证机制；宣告「完成」的权力与留给人类的决定，是 Graph 与 Factory 必须显式设计的治理。一个能清楚回答全部六问的系统，远比一个只炫耀模型强大的系统更可信——这是全文的中心信息。

阅读文中的数字时需注意：有关 OpenAI、Anthropic、Atlan、Spotify 的数据是原文引用的例子（原文灵感来自 Sumant Thakur 的 Substack 文章），此处未作独立核实；文章的主要价值在于五层框架与评估问题本身，而非某一个具体数字。

常见问题

Harness、Loop、Graph、Factory 有何区别？

按原文的五层框架：Harness 是智能体周围的环境（上下文、工具、权限、运行环境），回答「被允许、被装备去做什么」；Loop 是带证据与停止条件的试—验证循环，回答「还要继续吗」；Graph 是跨多个智能体与步骤的协同图、按错误类型路由，回答「下一步由谁或什么行动」；Factory 是在规模层面运营这一切的层，回答「如何运营并改进全部」。Model 位于中心，只负责生成代码。

为什么 Builder 不能给自己的代码打分？

因为当成果的创造者同时是宣称成果正确的人时，系统就失去了独立验证层——按原文，OpenAI 的做法与 Anthropic 的 Planner – Generator – Evaluator 拆分都遵循这一原则。在所述工作流中，Builder 在隔离工作区内提议并执行；自动化检查按确定性标准打分，Evaluator 独立复核，人类保留最终合并权。

一个「好的 Loop」需要哪些条件？

按原文，可用的 Loop 需要：用外部证据做决定，而不是智能体自己的感觉；错误先分类再决定是否重试；重试次数有上限；以及明确的停止条件——预算耗尽或错误超出智能体权限时停止或上交人类。无条件的「试—失败—重试」天真循环只产生重复，不产生可信度。

Factory 与 Harness 有何不同？

按原文所引 Warp 的区分：Harness 运行 worker——是单个智能体执行单个任务的环境。Factory 位于更高层：它在众多会话、仓库与工具之间，决定哪个 worker 接哪个任务、配什么上下文、权限、验证方式与人工检查点。正因有了 Factory 层，Codex、Claude Code、Kiro 等编程智能体才能成为可互换的 worker。

这个框架对还没有「Factory」的小团队有什么意义？

意义很大，因为五层是一个成熟度阶梯，而不是必须一次配齐的要求。小团队可以立即应用较低层的原则：以已批准的规格而非模糊提示启动任务（Model），为智能体组织仓库与权限（Harness），设定重试上限与停止条件（Loop）。当智能体、会话与仓库数量增长时，Graph 与 Factory 才变得必要——而文末的六个问题在任何规模下都是一份可用的清单。

结语

全文的信息可以浓缩成一句话：模型正在成为一个工人，环绕它的架构正在成为一门工程学科。随着编程智能体普及，一个团队的竞争优势不再在于选中那个「最好」的模型，而在于把五层都设计好——给模型的规格清晰，Harness 好到让模型的能力能在真实仓库里存活，Loop 知道何时停止，Graph 把正确的工作路由给正确的执行者，Factory 在规模上运营这一切，并在最重要的节点把最终决定权留在人类手中。

来源：Code Web Không Khó 于 2026 年 11 月 11 日在 Facebook 发布的文章《AI coding đã vượt qua thời kỳ Agent — giờ là thời kỳ của hệ thống quanh Agent》；作者表示该文以个人视角改写，灵感来自 Sumant Thakur 在 Substack 上的原文《AI Coding Is Moving Beyond the Agent》。文中有关 OpenAI、Anthropic、Atlan、Spotify 的数据引自原文，未作独立核实；由 Wotech Electronics 编辑整理。插图：原帖附带图片。