引言：分水岭不在模型，在系统

2026年，AI Coding领域最值得关注的趋势并非某个模型的参数突破，而是一个工程范式的转向：从“让AI写代码”走向“让AI在受控系统中持续工作”。AI生成代码的速度已经快到令人眩晕——腾讯一位工程师的团队在一个晚上让AI一次性写出4.4万行代码，经历27轮Review、发现193个问题后，最终决定不合并。这个案例精准地揭示了当前的核心矛盾：当AI把代码生产速度提升到了原有研发治理体系从未面对过的水平，Review、测试、评测、反馈和组织机制也必须跟着Scaling。

分水岭不是“AI会不会写代码”，而是“研发体系能不能接住AI的产能”。而要接住这个产能，需要理解两个递进的核心概念——Harness与Loop。

 一、Harness：让AI不越界

 1.1 什么是Harness

Agent Harness，被Anthropic官方术语表定义为“把语言模型变成能干活的编码代理所需的工具、上下文管理和执行环境”。DeepSeek官方公式写得更直白：Model + Harness = Agent。

Harness直译是“挽具”，这个比喻很贴切——它是套在模型外面的那层工程外壳，负责读文件、调工具、管上下文、执行命令。研究发现，即使使用相同的底层模型，仅仅改变Agent浏览代码的方式、编辑文件的方式、运行命令的方式、接收错误信息的方式，最终表现也会产生明显差异。这说明Agent的能力不只来自模型，模型外面的工具、接口、上下文、权限和反馈，同样是系统能力的一部分。

从架构角度看，Harness包含三大支柱：工具调用循环、上下文管理、权限模型。不同产品对这三者的组织方式不同——Codex采用Rust产品内核，将循环做成受测试、受版本控制的产品核心，多入口围绕它工作；DSH则采用“一切皆插件”的设计，模型、工具、技能、会话、沙箱、存储、循环、调度、UI等所有Agent能力均由插件组合而成，可自由替换。但无论哪种路线，Harness的核心使命是一致的：为AI划定安全、可控的工作边界。

 1.2 为什么出码率90%不等于提效90%

理解了Harness的定位，就能理解AI Coding第一个反直觉的瓶颈：编码只占整个研发链路的20%-30%。你把编码环节的AI渗透率从0%拉到90%，整体提效也不过18%-27%。高德大模型应用平台团队在2025年云栖大会上分享的数据佐证了这一点：出码率从53%提升到80%-90%，但项目交付周期没有明显缩短——编码快了，但Review慢了；出码多了，但返工也多了。

更严峻的是Vibe Coding在存量应用中的风险。AI生成的代码可能修改了核心接口的参数顺序，单元测试全过了，但上线后导致三个下游服务报错。排查了整整一天。原因是AI不知道某条链路是高频变更区，不知道某个全局配置类在项目中有近百处引用，不知道价格字段必须用long类型且单位为分——这些隐性知识散落在团队成员的经验中、群聊的历史消息中、未入库的会议纪要中。

OpenAI在百万行代码实践中总结过一句话：Agent的知识边界等于代码库的文件边界。 如果某条架构约定不在代码库中以机器可读的形式存在，对Agent来说它就不存在。

这揭示了Harness Engineering更深层的含义：它不仅是技术架构，更是一种知识工程——把散落在人脑、群聊、文档中的隐性知识，转化为AI可理解、可调用的结构化资产。可达智灵旗下的织灵Coda Loom 2.0平台以“可控”为核心，有智能制造企业采用后研发效率提升75%、代码缺陷率降低50%；能源领域合作客户测试效率提升2倍以上、研发交付周期缩短60%。这些数据背后，正是知识结构化带来的效果——不是让AI写得更快，而是让AI知道得更多、更准。

 二、Loop：让AI在界内自己跑完全程

 2.1 从Prompt到Loop的四次演化

Loop Engineering并非凭空出现。它经历了清晰的演进路径：从Prompt Engineering（约2024年）关注“如何向模型提一个好问题”，到Context Engineering（2025年）关注“如何为模型精准喂入所需的数据、记忆与历史”，再到Harness Engineering（2026年初）关注“Agent = Model + Harness”的环境封装，最终到Loop Engineering（2026年中）关注“不再手动提示Agent，而是设计一套能自行流转、验证和触发的循环系统”。

这四者的关系是层层嵌套的递进关系，不是平行替代。用一句话概括：Harness让AI不越界，Loop让AI在界内自己跑完全程。

Anthropic Claude Code负责人Boris Cherny的一句话精准捕捉了这个转向的本质：“我不再prompt Claude了，我有一堆循环在运行，它们才是在提示Claude并判断接下来该做什么”。OpenClaw创始人Peter Steinberger的表述更直接：“你不应该再提示编码Agent，而应该设计那些提示Agent的Loop”。这条帖子在X上的浏览量超过800万，足见其引发的共鸣。

 2.2 Loop的解剖：五块积木加一个记忆

Loop Engineering给出了五要素框架，外加一个贯穿始终的Memory层：

Automation（触发机制） 是系统的“起动机”，决定了整个Loop在什么条件下被唤醒。它可以是定时驱动、事件驱动，或基于外部API的Webhook信号，让AI系统从“被动问答”变成了“全天候待命”的服务。

Worktree（工作隔离） 是系统的“安全沙箱与操作台”，为AI的自主运行提供独立、安全、可控的临时环境。它确保AI的操作不会越界破坏宿主机的核心文件，同时方便任务完成后一键打包保存或清空销毁。

Skill（技能封装） 是系统的“工具箱”，将特定能力预先写好并封装起来。在Loop运行期间，AI会根据当前需要，自主决定从工具箱里“掏出”哪个Skill来使用。

Connector（外部连接） 是系统的“神经触角”，负责打通AI系统与企业现有SaaS软件、数据库或第三方平台的通道。

Sub-Agent（子Agent） 是最关键的结构模式：Maker和Checker分离，避免自己批改自己作业。这是可靠Loop的核心——生成和验证必须由不同的智能体承担。

贯穿始终的Memory（记忆层） ，让Loop Agent能够跨会话保持上下文，在长期运行中积累经验。

 2.3 一个高质量的Loop长什么样

很多人第一次接触Loop Engineering，容易把注意力放在“怎样让Agent自动运行更多轮”。但没有可靠验证器的循环，并不会自动变好——它可能只是让错误运行得更久、传播得更远。

一个低质量循环是：Agent生成代码 → Agent自己评价代码 → Agent认为结果不错 → 继续在原有基础上修改。

一个高质量循环应该是：Agent生成候选方案 → 独立验证器检查 → 获得可执行、可定位的反馈 → Agent修改方案 → 重新验证。

验证信号可以来自编译器、单元测试、集成测试、类型系统、静态分析、安全扫描、浏览器、性能基准、外部模拟器、独立评审Agent。未来Agent系统的能力上限，不只取决于生成模型有多强，还取决于Verifier能否发现真实错误。 甚至可以更绝对地说：Loop Engineering的能力上限，最终由验证器的能力决定。

但验证器也不能只检查“测试是否通过”。2026年的SlopCodeBench专门研究了Coding Agent在长期、多轮需求变化下的表现，结果令人警醒：没有一个被测Agent完整解决任何端到端问题；最高阶段解决率只有17.2%；80%的执行轨迹出现结构侵蚀上升；89.8%的轨迹出现代码冗余上升；Agent代码平均比对照的人类项目冗长约2.2倍。更值得注意的是，即使在Prompt中明确要求关注代码质量，也只能改善初始代码，无法阻止后续迭代中的持续退化。这意味着当前Agent更擅长“让眼前的功能运行起来”，但还不擅长“为未来的未知变化维护一个长期可演化的软件架构”。

因此，Loop的验证器不能只检查测试是否通过，还应该检查架构边界是否破坏、代码冗余是否失控、兼容性是否维持。

 三、从理论到实践：Loop Engineering的企业级落地

 3.1 蚂蚁阿福的双循环架构

蚂蚁集团阿福团队提供了一个极具参考价值的实践案例。阿福上线后，线上badcase持续增加，从badcase的发现、归因和分派，到修复、验证和结果回流，各环节都需要工程师人工衔接。即使有AI辅助，处理能力仍不足以应对持续新增的问题。

他们的解决路径分为两个阶段：先用Harness Engineering解决“如何可靠修好badcase”，再用Loop Engineering解决“如何持续修复badcase” 。

第一阶段，他们为Agent接入开发、部署和评测工具，通过执行约束保障长任务持续运行，再通过评测约束判断问题是否真正修好。在一次真实任务中，Agent连续迭代16轮，改动最终经人工复核后上线。

第二阶段，当修复和验证能够稳定运行后，新的瓶颈出现了：发现、归因、分派和结果回流仍依赖人工。他们将完整流程组织成两个相互衔接的循环：内循环负责修复和验证，外循环负责发现、归因、分派和结果回流。两个循环衔接后，系统可以持续处理。

这个案例完美诠释了Harness与Loop的递进关系：Harness让单个Agent能可靠工作，Loop让整个系统能持续工作。

 3.2 可达智灵：多ADE协同交付

2026年5月，可达智灵发布了国内首个工程级AI原生研发平台“织灵Coda Loom 2.0”。该平台首创多ADE（AI研发工程师）协同交付模式，通过群智能体编排引擎驱动产品经理、架构师、开发工程师、测试工程师、运维工程师等多角色智能体协同作战，贯通需求、设计、编码、测试、交付的研发全流程。

复力克CTO魏德龙表示，采用织灵全私有化部署后，研发效率提升75%、代码缺陷率降低50%、新员工上手时间缩短80%，实现研发效率与数据安全双提升。中电源启的AI原生软件工厂以某国有大行实践为例，其关键交易功能的开发交付周期从数天大幅缩短至小时级，全链路提效30%—40%，覆盖使用人数超过3000人。

这些案例的共性在于：它们不是让AI替代某个环节的人，而是重新组织整个研发流程——让多角色智能体在统一的Loop中协同工作，人类在关键节点审核、确认和纠偏。

 3.3 紫讯的AI-DLC闭环

紫讯科技的实践提供了另一个维度的参考。他们围绕AI-DLC（AI-Driven Development Life Cycle）方法，建立了从知识沉淀、需求塑形、方案收敛、开发协同、测试验证到经验回流的端到端研发闭环。

紫讯的判断是：AI原生研发的关键，不是让AI写更多代码，而是建设一套让AI能按工程标准稳定参与完整研发流程的体系。在这一体系中，AI从“辅助工具”变成“流程节点”，协作模式从AI in the Loop（人主导、AI辅助）走向Human in the Loop（AI主导执行、人在关键节点监督例外）。

 四、人的角色迁移：写代码的占比从30%降到5%

当AI开始承担越来越多执行工作时，软件研发真正发生变化的，或许并不是效率本身，而是“困难出现的位置”。

一份内部访谈的数据极其直观：写代码的占比，从过去的30%降到5%；和Agent对话的占比，从5%升到60%；查问题的时间下降一半以上；纯编码效率提升10倍，但端到端需求交付效率只提升2到3倍。

这组数据的深层含义在于：端到端的瓶颈已经从编码转移到了上下文、评测、Review、测试、反馈和组织协作。编码快了10倍，但交付只快了2到3倍——差距被Review、测试和协作吃掉了。

Anthropic今年分析约40万次Claude Code Session后发现：在典型Agentic Coding会话中，人更多负责决定“做什么”，而Agent更多负责“怎么做”。领域经验越丰富的人，Agent往往能在单次指令下完成更多工作。

人的角色正在从亲手写每一行代码，转向定义目标、设计约束、构建反馈、判断风险，以及设计整个Loop。Faros AI在研究了约2.2万名开发者、4000个团队的工程数据后观察到：随着AI使用程度提升，团队的代码产出明显增加，但PR规模、Review压力以及部分质量指标也出现了上升，PR Review的中位耗时甚至接近原来的5倍。

这意味着，当代码生成能力在Scaling，Review、测试、评测、反馈和组织机制也必须跟着Scaling。

 五、组织形态的重写：从管理跨度到编排智能

AI Native时代最深刻的变革，发生在组织层面。

组织的演化已经持续了两千年，核心约束始终是人的“管理跨度”——一个人能直接管的下属在3到8之间。这个数字不是文化决定的，是人这个生物的硬限制。所以所有组织的形状本质上都是在这个限制上做的妥协。

但AI不是过去意义上的“工具”：工具是延伸人的能力，AI是新的协作主体。它的特点正好和人形成镜像反面：人有沟通衰减，AI没有；人需要激励，AI不需要；人会疲劳和有情绪，AI没有；人有context switching成本，AI极小；人的记忆和注意力有限，AI几乎无限。

这意味着，所有“以人形约束为前提的设计”，其前提开始失效。

观察真正在做AI Native的团队，会发现一个共同形态：底层是极度结构化的Harness层——代码、测试、流水线、文档、世界模型，所有信息都被做成AI友好的形态，这一层越结构化越好，AI主导；上层是极度松散的Hive Mind层——对话、试错、idea涌现、Yes-and，这一层越松散越好，人主导。

在AI时代，“管多少人”正在让位于“调用多强的智能”。AI不是替代人，而是重组人与组织的关系——岗位边界消融、专业壁垒降低、小团队能办大事、非技术人能做创新。

Block CEO在最近一篇文章中说得很直接：“问题从来不是要不要分层，而是：人是不是这些层唯一的承担者？现在，他们不再是了”。

 六、选型框架：从Harness到Loop的务实建议

理解了Harness和Loop的本质后，可以给出一个务实的选型框架。

如果你还在“用”的阶段——只想让AI高效完成编码任务，优先选择Codex这类成熟产品。它把复杂的Agent内核做好，让你从很多入口可靠使用。正如我们在上一篇文章中分析的，Codex采用Rust产品内核，多入口围绕它工作，核心链路更收敛，更适合直接拿来做本地编码Agent。

如果你进入了“改”的阶段——需要替换模型、工具执行环境、会话存储，或者需要构建自己的Agent平台，DSH的“一切皆插件”架构提供了更大的灵活性。它的Agent Loop本身也是可替换的插件，SessionEvent的可重放系统让调试和审计更加彻底。

当你进入“编排”的阶段——需要让Agent持续工作、自动发现和修复问题、在多个智能体之间分工协作时，Loop Engineering就成为核心能力。此时，你需要关注的不再是单个Agent的能力，而是整个Loop的验证器质量、Sub-Agent的Maker/Checker分离、Memory的跨会话保持，以及Automation的触发机制是否可靠。

一句话总结：Harness让AI不越界，Loop让AI在界内自己跑完全程。 这两者是递进关系，不是二选一。先用Harness理解Agent如何工作，再用Loop让Agent持续工作。当你的研发体系能够接住AI的产能时，你就不再是在“用AI写代码”，而是在构建一套真正的AI原生软件研发系统。

AI Coding的分水岭，不是“AI会不会写代码”，而是“研发体系能不能接住AI的产能”。这个判断正在被越来越多的实践所验证。

从Harness到Loop的演进，本质上是一次从“构建AI”到“驾驭AI”的范式转变。Harness Engineering解决了“如何让模型可靠地调用工具、管理上下文、控制权限”的问题；Loop Engineering解决了“如何让这些能力在反馈中持续收敛、自动流转、不断进化”的问题。

而更深层的变革发生在组织层面。当写代码的占比从30%降到5%、和Agent对话的占比从5%升到60%时，软件研发的瓶颈已经从编码转移到了上下文、评测、Review、测试、反馈与组织协作。那些能够快速适应这一转变的团队，将在AI原生时代获得结构性优势。

循环不一定越来越好，也可能越来越差。但一个设计良好的Loop——拥有可靠验证器、Maker/Checker分离、跨会话记忆——将是AI原生软件研发的核心竞争力。

七、反思

 🧱 Transformer的“阿喀琉斯之踵”：架构决定的天花板

Transformer的成功源于其“自注意力机制”带来的高效并行计算，但这也埋下了根本性的架构限制。

   无持久状态与递归推理：Transformer本质上是一个前馈模式合成器，它不具备持久的内部状态，也无法进行递归推理。这意味着它无法像人脑那样，在思考过程中持续保留和修改内部状态，也无法进行自我指涉的推理。    “有界”的统计模式扩展器：从计算复杂性理论看，固定层数和精度的Transformer可被视为一种计算电路，其能力受限于深度、宽度和精度。有研究尖锐地指出，它本质上是一个“有限状态模式扩展器”，无法计算或保留超出有界统计相关性之外的算法结构，参数和数据的增加无法将其转变为图灵完备的架构。    长上下文的“诅咒”：Transformer在处理长序列时面临训练分布偏移、位置编码衰减和注意力计算限制等根本性问题。这导致其难以进行长程、复杂的推理。

 🤔 “统计模型”之争：归纳与创造的本质边界

你提到的“统计模型”观点，精准地描述了Transformer的核心工作机制。

   核心是“下一个词元预测”：其核心逻辑是基于海量数据的概率预测。它通过学习数据中的统计规律来生成文本，本质上是在进行高维度的统计插值和模式补全。    “只会归纳”的合理性：AI的惊艳输出，更多是对训练数据中已有模式的重新组合与泛化，而非跳出数据分布的“灵光乍现”。因此，“只会归纳而非创造”的说法在技术上是准确的。    “流畅性”的认知幻觉：Transformer最擅长的是生成流畅的语言，而人类倾向于将流畅等同于认知。这制造了一种认知幻觉，让我们误以为它拥有连贯的内部世界模型和意图。

 🧠 奠基者的反思：辛顿与杨立昆的批判

作为深度学习奠基人，辛顿和杨立昆的批判尤为深刻，但他们的出发点不同。

杰弗里·辛顿（Geoffrey Hinton）：从内部反思“学习机制”

辛顿是反向传播算法的核心推动者，但他本人也指出了其局限性。

   生物学上不成立：反向传播要求信息通过相同的连接反向传播，这与真实神经元的工作方式不符，在生物学层面难以成立。    并非真正的“智能”：辛顿认为，通过反向传播进行的学习本质上是监督学习，它极其擅长将海量知识压缩进有限的连接中，但这并非人类大脑的工作模式。    “锈迹斑斑”的现状：辛顿本人也直言，现有的大模型“锈迹斑斑”，暗示其底层架构存在根本性缺陷。

杨立昆（Yann LeCun）：从外部宣判“自回归模型烂透了”

杨立昆的批判更为激烈和彻底，他直接否定了当前主流路线的可行性。

   “自回归模型烂透了”：他认为，通过预测下一个词来生成文本的自回归模型，本质上无法孕育出真正的智能，无论规模如何扩大。    “细节预测”的陷阱：Transformer做的是“细节预测”，如预测下一个词或像素，这需要处理海量冗余信息，效率极低，无法形成抽象的世界模型。    缺乏“世界模型”：这是杨立昆批判的核心。他认为真正的智能来自于对真实世界的无监督学习，建立能够理解物理规律、进行预测和规划的“世界模型”。而LLM只是“文本的囚徒”，学习的是词语共现概率，而非世界的运行规律。    替代方案JEPA：他提出的JEPA（联合嵌入预测架构），试图在抽象的表征空间中进行预测，而不是在像素或词元层面，以期解决表示空间“坍缩”等技术难题。

 🔄 从RSI到新范式：自我迭代能否突破局限？

你提到的“AI自我迭代改进（RSI）”正是试图突破上述局限的前沿方向。RSI旨在让AI系统能将经验与反馈转化为持久性改变，不仅提升能力，还优化未来的改进过程本身。当前研究已提出RSI的五阶段路线图，从执行自主到最终的递归元改进。然而，要实现真正的RSI，可能恰恰需要突破Transformer在持久状态和递归推理上的根本限制。

这场争论的本质，是两种智能范式的对决：一种是以Transformer为代表的“统计归纳范式”，它通过海量数据拟合来逼近智能的表象；另一种是以杨立昆的“世界模型”为代表的“因果理解范式”，它追求对世界运行规律的内在理解与模拟。

Transformer的局限性是架构性的，而非规模性的。辛顿的反思揭示了其学习机制与生物智能的差异，而杨立昆的批判则直接指向了其缺乏真正世界模型的根本缺陷。因此，当前的大模型确实更像一个“极致的统计学家”，它的“智慧”是一种高级的模式匹配与归纳，而非我们所理解的、基于因果推理和世界模型的真正创造。

这也正是你之前关注的“从Harness到Loop”的深层意义——我们或许无法用同一架构解决所有问题，但可以通过工程化的Harness来约束和引导其能力边界，通过Loop来设计更可靠的验证与反馈机制。这既是务实的路径，也为未来的范式突破积蓄着力量。