本文永久链接 – https://tonybai.com/2026/07/23/software-factory-light-and-dark
大家好，我是Tony Bai。
导读：
当前，AI 智能体正在以前所未有的速度吞噬软件工程的基础执行环节。当成百上千个 Agent 组成流水线，没日没夜地为你自动生成、测试并提交代码时，一个终极形态的“软件工厂（Software Factory）”诞生了。然而，在这场效率狂欢中，一个致命的隐患正在悄然滋生：当代码的产出速度远远超过人类阅读和审查的速度时，我们正在积累毁灭性的“理解力债务”。本文编译自谷歌前 Chrome 团队负责人 Addy Osmani 的深度长文，深刻探讨了“黑灯工厂（全自动自治）”与“明灯工厂（人类把关）”的本质区别。文章提出了一项划时代的范式转移：人类必须坚决放弃陷入具体的代码生成（内环），转而死守系统架构、边界验证和最终裁决的“外环（Outer Loop）”。
文章要点：
- 软件工厂的本质：它是“规模化运载的智能体循环（Harnessed loops at scale）”，而不是一个超级 Agent。
- 黑灯工厂的灾难：盲目追求“全自动、无人审查”的代码生成，虽然短期吞吐量暴涨，但会迅速累积人类无法看懂的“理解力债务”，最终导致老旧系统在暗中悄然崩溃。
- 验证（Verification）才是终极瓶颈：软件生产的瓶颈从来不是代码生成的速度，而是人类能够以多低成本、多高可靠性去验证这些代码。
- 反向压力（Back Pressure）法则：系统赋予智能体的自主权上限，必须严格受限于人类或自动化测试的验证能力，多一寸都不行。
- 控制流图（Graph）的回归：纯自由的 Loop 容易失控，现代框架（如 LangGraph）本质上是用“有限状态机”为 Agent 画出了强制性的反向压力路线图。
- 人类退守外环（Own the Outer Loop）：将 Agent 限制在“调查、执行、测试”的内环；人类升维至外环，专职负责“决策、验证、批准与担责”
在前几篇中，我们先后拆解了 Andrej Karpathy 的《LOOPS.md》、20 个循环设计模式、Claude Code 落地实践，以及全新 AI 技术栈。我们已经确立了一个共识：“Loop（循环）”是 AI 智能体的原子单元，而“Harness（驾驭框架）”则是智能体运转的操作系统。
但是，当我们将成百上千个这样带有驾驭框架的 Loop 组合起来，并接入企业的需求队列、CI/CD 管道和监控系统时，一个终极的技术形态诞生了——软件工厂（Software Factory）。
在谷歌前 Chrome 团队负责人 Addy Osmani 的这篇深度长文中，他探讨了一个正在真实发生的行业趋势：
- 黑灯工厂（Dark Factory）：追求极致的自动化，让 Agent 自动领任务、写代码、合并 PR 并直接上线。物理上的“关灯”，意味着代码从写出到上线，没有一个真正的人类阅读过它。
- 明灯工厂（Light Factory）：将人类的决策与审美品味从繁琐的“逐行看代码”中解放出来，重新安放在系统架构、需求规划和最终卡控的“高价值节点”上。留下一盏灯，是为了确保人类始终理解我们所构建的软件。
“黑灯”看似打破了开发速度的音障，却正在悄悄积累毁灭性的“理解力债务（Comprehension Debt）”。
本文将为你揭示：为什么说“生成代码”从来都不是瓶颈，“如何低成本、高可靠地验证代码”才是软件工厂真正的命门。
以下为译文全文：
所谓软件工厂（Software Factory），本质上就是规模化驾驭的智能体循环（Harnessed loops at scale）。
你可以选择运行一座“明灯工厂”（Light Factory，有人类参与循环）：用人类的判断力和注意力，去换取更高的系统鲁棒性并减少代码崩溃；你也可以选择完全无视人类的参与，运行一座“黑灯工厂”（Dark Factory，全自动无人在环）：让那些 Agent 自行规划范围、编写代码并直接发布代码，期间没有任何人去真正阅读具体的实现细节。
但是，如果人们停止了阅读代码，他们终将停止对自身软件系统的理解。
作为工程师，你现在最艰难、也最具含金量的工作，是明确该构建哪些验证卡控机制，以及到底该向 AI 委派多少自主权。
“软件工厂”这一概念并非新生事物，其历史最早可以追溯到 Bob Bemer 在 1968 年发表的经典论文《程序生产经济学》（The economics of program production）。半个世纪以来，无数工程师梦想着能有朝一日将软件开发变成一种可重复、可度量的工业化生产过程（类似于在工厂流水线上冲压汽车零件），而不是依赖于程序员个体的孤立手艺。
在历史上，这一梦想普遍（尽管并非全部）以失败告终，部分原因在于“思想和创意”很难像物理零件那样被批量冲压。
然而，在过去两年中，底层技术发生了极其剧烈的变革，以至于我们有充分的理由重新审视这个半个世纪前的老梦想。鉴于其中一些微妙的工程细节极易被轻率地忽略，我们非常有必要精准地剥离出：究竟哪些是真正全新的突破，而哪些只是披着新机会外衣的重复陷阱。
HumanLayer 的联合创始人 @dexhorthy 最近在 AI Engineer World’s Fair 上发表了一场题为《仅靠驾驭框架工程是不够的：为什么软件工厂会失败》（Harness Engineering is not Enough: Why Software Factories Fail）的精彩演讲，非常值得在这个议题下深度研读。
循环是原子；工厂是规模化放大的循环
结构决定一切，而一切结构都始于最微小的单元。整个 AI 技术栈，本质上是叠在最底层的三个核心概念：循环（Loop）-> 驾驭框架（Harness）-> 工厂（Factory）。
- 循环（Loop）：是单个 Agent 循环往复地执行某一项单一任务：收集上下文 -> 采取行动 -> 检查结果 -> 未达标则重新开始，直到满足某个预设条件。它是智能体工作中最微小的原子单元，其之上的所有复杂架构，不过是循环之上再叠加循环。
- 循环工程（Loop Engineering） 的核心要义在于：你不再需要手把手地去逐回合给 Agent 发 Prompt，而是去设计一个能够替你自动发送 Prompt 的微型系统。
- 驾驭框架（Harness）：是包裹在循环外围的“围墙”——包括它所运行的沙箱环境、它能触及的工具链、跨会话保留的记忆，以及定义任务“何时算完成”的门控（Gates）。循环是具体的行为；而驾驭框架则是行为所处的外围环境。如果你直接给模型一个裸调用而不给任何驾驭框架，模型会非常乐意在后台无限死循环下去。驾驭框架，就是外围所有能够让模型安全、实用运转的保障系统。
- 软件工厂（Software Factory）：是许多个带有驾驭框架的循环同时并发运转。它们由一个任务队列统一喂入需求，并在出口处经过一个审核门控（Review gate）统一排干流向生产环境，而人类则在最高维度上统筹掌控这一切。它绝对不是一个体积更大的超级 Agent，它是一张由无数个 Loop 构成的“组织架构图”。
最终的范式大转移，在于从“编写代码”跨越到“构建并运行写代码的工厂”。工作的最小单位向上升维到了循环、驾驭框架以及它们之间的流转逻辑，而不是某一段具体的代码 Diff。
Dex 演讲中最核心的一张架构图极其精妙，它用一张清晰的接线图，将原本抽象的循环直观地呈现了出来：
软件工厂是一个闭合的闭环：
产品意图和线上生产信号喂入需求队列 -> 驾驭框架进行构建 -> 自动化检查与审查门控进行把关 -> 部署上线 -> 运维监控将线上状态再次转化为生产信号。
产品意图来自于工程团队领袖的远景规划，也直接来自于一线工程师；事故日志和用户反馈触发的信号，同样源源不断地流入这个需求队列。
驾驭框架（Harness）充当的角色，就是从队列中抓取一个任务，并为其构建代码变更。在驾驭框架之外，我们可以看到所有为了确保变更足够安全而设置的自动化检查。得益于 CI/CD、单元测试、静态代码分析以及各类安全扫描，这些自动化检查几乎毫不费力地异步并发运行，完全不需要工程师进行任何意识上的介入。
在这个庞大的闭环中，唯一需要人类决策的节点，只有“审查门控（Review Gate）”。
一旦获得批准，变更就会部署并上线监控，监控数据会再次转化为驱动下一次循环启动的信号。
大体上看，这张架构图中的绝大多数方框（代码生成、自动化测试、安全扫描）的边际成本都趋近于零。它们可以以极低的成本进行海量规模化扩展。整个系统中，只有一个极其昂贵、且顽固拒绝被无脑规模化放大的方框——那就是“审查门控（Review Gate）”。
那个闪烁着黄光的方框代表着“人类的审美品味与判断力（Judgment）”。而这，恰恰是“我们能否让软件开发变得更快、更频繁”这一行业大论战的终极焦点。
为什么我们称之为“黑灯”？
物理世界中的“黑灯工厂”，指的是在生产时将车间灯光完全关掉，因为里面的机器机器人根本不需要光线就能干活。
“黑灯软件工厂”也是完全相同的套路：代码在没有任何人类阅读、审查的前提下被直接发布，完全仅由其他机器进行验证。
这个概念直接借用自制造业。它的起源是物理实体而非数字世界，根植于那些熄灭了灯光、全由机器人接管的自动化车间。日本的发那科（FANUC）早在 2001 年就开启了这种关灯工厂；小米也在 2024 年开业了自己的高自动化黑灯工厂。
它们的共同特征是：一件产品从组装到出厂交付，期间没有任何一个人类阅读过它的任何生产细节。当“阅读”这一动作从流程中被彻底抹去时，“黑灯”就诞生了。
我借用这个概念，绝非为了造噱头，也绝非贬义。抛开那些带有科幻色彩的流行词，“黑灯”在这里是一个纯粹的客观事实描述：依然是那个工厂车间，只是关掉了灯。在软件工程里，车间地板就是代码 Diff。无论谁写了 Diff，谁审核了 Diff，谁发布了 Diff，那些人类都已经退场了，只留下了仅被机器自身验证过的代码 Diff。
在刚开始的时候，这件事做起来顺畅得令人发指。
之所以顺畅，是因为那个原本卡在中间的人类审查步骤被彻底废除了。它的消失，会让你的团队在体感上的“垂直吞吐量”瞬间暴涨，让你产生一种打破了音障的快感。
然而，在这种表面的顺畅之下，想要在暗黑的工作流及其埋下的巨大隐性成本中生存下来，远比想象中要艰难得多。
仅靠“驾驭框架工程”是远远不够的
随着模型与现实世界及彼此之间的交互日益频繁，由任务编排、沙箱原型构建以及工具调用构成的驾驭框架（Harness）将会变得空前强大。
然而，在试图通过叠加式的代码修改来长久维持代码库质量的长跑中，模型内部存在着一种天然的失效机制。我们有充分的理由相信：仅靠模型自身，最终必将在“理解力债务（Comprehension Debt）”面前败下阵来。
所谓“理解力债务（Comprehension Debt）”，指的是“代码库中实际存在的代码总量”与“人类依然能真正理解的代码总量”之间不断扩大的鸿沟。
一座黑灯工厂绝不会去偿还这种债务；它只会以最快的速度疯狂举债，且在此过程中，所有的自动化测试全程都在亮绿灯。
这是一个极其关键的区分，因为模型在某些特定任务上表现极佳。但对于任何不是对代码库微小局部进行即时修改的任务——尤其是面对极其复杂的遗留旧系统（Brownfield System）时——纯模型驱动的自动化编程将面临不可逾越的鸿沟。
绿地项目（Greenfield apps）、周末练手的小玩具和 Side Projects 都有一个共同点：几个月的开发周期通常足够把事情搞定，或者至少能跑得像模像样。
但一个已经持续开发了十年或更久的企业级系统，完全是另一种庞然大物：它必须在极其专业的环境、以专业的节奏被长久维护。项目推进三到六个月后，你就会发现自己已经彻底淹没在海量未曾阅读过的代码汪洋中了。
这种严酷的环境，尤其是生产环境代码所强制执行的各种隐性约束，会让最强大的 Agent 也感到束手无策——这与开发者在周末玩具项目中享受的“氛围编码（Vibe-coding）”构成了鲜明的对比。
Dex 根据一线经验指出，这是一个极其重大的失败模式，以至于他们花了整整四个月的时间，进行痛苦的深度手动 Debug 才精确定位到问题所在。这来自于他们运行了一个长达四个月的全自动代码工厂，在此期间，没有任何人类去阅读过被写出的代码。
这一惨痛教训背后，是两个互相对立的指标之间的终极博弈：
- 最大化 Token 利用率：这是我们目前盲目当作“项目进度”的表面数字；
- 人类对系统任何时刻的理解程度：而黑灯工厂在默默地将这个真正核心的指标压到趋近于零。
黑灯工厂真正大放异彩的地方，在于它能在测试全程亮绿灯的同时，肆无忌惮地烧毁原本优雅干净的代码库。
而当终极清算到来时，它绝对不会是一个戏剧性的、瞬间轰然倒塌的“崩盘时刻”。
它将是悄无声息的、迟来的绝症。
明灯与黑灯，本质上是同一条流水线，只是灯光亮在了不同的地方。明灯版本绝不仅仅是在末端重新加上人类 Review，而是将人类的审美品味与判断力，向上游的“系统设计”与“架构规划”进行了战略迁移。
软件生产的瓶颈，从来都不是“生成代码的速度”。
软件工厂最根本的硬性约束，从来不是我们能疯狂吐出多少代码，而是：我们能多快、多可靠地验证这些代码。
“反向压力（Back Pressure）”法则规定：你能够赋予一个循环的自主权上限，严格受限于你能够以多低成本、多高可靠性去验证它的极限，多一寸都不行。
验证（Verification），而非生成（Generation），才是软件工厂真正的终极约束。
由于无限膨胀的代码生成能力，与人类极其有限、且绝对无法无脑规模化放大的“注意力”之间存在着永恒的张力，核心矛盾演变成了“廉价的生成”与“有限的审查”之间的巨大鸿沟。
看看这个漏斗：只要代表“验证”的瓶颈没有被拓宽，系统就必然发生严重的堵塞。正如 Dex 一针见血指出的那样：单纯的代码产出数量根本不是问题，我们真正受苦的，是大量涌现的糟糕 PR（Pull Requests）。
当你在没有可信门控的前提下盲目追求高产出时，人为制造的系统缺陷将变得不可避免。这再次印证了反向压力法则：自主权绝对不能超越低成本、高可靠验证能力的边界。
第二个深层问题在于：为什么单纯提升模型的智商，无法自动弥合“生成”与“验证”之间的鸿沟？
在具有良好架构的系统上进行训练，远比通过简单测试要困难得多：请记住，衡量架构卓越性的成本函数，其单位不是秒，也不是分钟，而是月和年。
在工程上，你根本无法计算出平滑的梯度，因此，一个期望对复杂设计决策进行精准、即时评估的系统，是根本不可能在优质样本上训练出来的。
代码生成是一个巨大的大喇叭口；而代码验证则是极其狭窄的瓶颈。盲目加速大喇叭口，只会让狭窄瓶颈处的堆积变得更加绝望。
重新把灯点亮（Turning the lights back on）
明灯工厂（Lit Factory），就是在判断力（Judgment）所在的地方把灯留着的同一条流水线。
Agent 依然承担了绝大多数的具体构建工作，但在代码正式发布前，必须由人类去阅读产出的结果；并且在任何“做错决策代价高昂”的地方，灯必须死死亮着。
明灯版本绝不是把审查硬生生贴在流程的最末端，而是把人类判断力的焦点向上游迁移——迁移到产品定义、系统设计，以及 Agent 启动循环前的架构规划上。
前期投入那极其宝贵的一个小时，最棒的地方在于：它能极大地减少后续具体的代码实现工时。
它能将一场长达数小时、令人无比沮丧的复杂代码审查，变成对一份 200 行架构规划书的快速阅读。你在代码被写出来之前，就已经审查并过滤掉了决策错误；这样你就不必在事后去痛苦地穿梭于 2000 行 AI 生成的代码汪洋中，试图去倒推模型当时到底做了什么荒谬的决策。
有些决策是如此高昂且影响深远，以至于你绝对希望人类能尽早介入，在成本复合膨胀之前完成把关。当然，即使你在前期投入了时间，某些关键时刻你依然需要去审查具体的代码 Diff。
你可能会觉得这听起来一点也不酷、一点也不“AI 自动化”。
你是对的。
这套安全网，恰恰是由我们早已熟知、却在过去长期被轻视的经典架构设计实践构成的：
- 优秀的类型系统（Types）与函数签名：让错误在编译期就被编译器拦截，而不是溜进生产环境；
- 测试缝隙（Test seams）：让我们能锁定系统行为，并让变更变得可观测；
- 清晰的代码布局：让下一个阅读代码的人（无论是人类还是模型），能瞬间找到他们关心的模块；
- 保持短小、可读的调用栈（Call stacks）；
- 极其清晰的组件边界：确保单点改动不会产生毁灭性的破坏半径（Blast radius）；
- 依赖注入（Dependency Injection）：让我们能随时优雅地替换掉某一个模块。
这其中没有任何新技术。我们过去口口声声说关心优秀架构，而现在，随着自动化编程 Agent 的全面接入，这些经典架构终于承担起了它们的第二个历史使命——成为一张低成本、极难被伪造的、能够无情拦截 Agent 犯错的安全网。
这张安全网必须存在于模型外部，因为模型自身绝不会提供它。
目前能力最强的编码智能体（包括 Claude Code 和 Codex 在内），本质上都是针对它们自身的驾驭框架和工具链进行强化学习（RL）训练出来的：它们对工具调用的语法和各种编程套路极其熟练，但它们对代码的“长期可维护性”一无所知。
我们一直在强调的“深思熟虑的架构”，正是捕获这些技术债务的终极工具，而我们在架构上投入的资源，本质上是在重新买回我们的自主权。
将这些与安全的底层基础设施相结合，你就能拥有一些可以完全无人在环、自动运转的紧凑、低风险循环。
Horthy 在最近的一篇文章中描述过这样一个场景：
一个在每晚定时运行的 GitHub Actions Cron 任务，它每次只精准修复代码库中的一个反模式（Anti-pattern）——比如修复一个 Lint 报错，或者优化一个多余的 optional prop。它自动修改、自动 Commit、自动提交一个极小的 PR。第二天早晨团队醒来时，看到的是一个稍微变好了一点点的代码库，以及一个短到几秒钟就能读完的 Diff。
但是，对于那些筹码极高的核心循环，你绝对不希望在清晨醒来时，看到系统的鉴权模块、计费引擎或公开 API 契约被 AI 给彻底搞砸了。
在这些核心战场，请务必把灯点亮。去信赖一个拥有真实判断力、且对系统底层运行逻辑有着深刻理解的人类工程师，去拦截那些致命的错误。
凭什么让一个循环进入“黑灯”状态？
无论你把它称之为反向压力、验证机制，还是开关灯的控制阀，这条铁律永远适用：
一个循环只有在满足以下条件时，才有资格获得“完全全自动（黑灯）”的许可：
- 验证成本极度低廉；
- 可以以极高的频率频繁运行；
- 极度依赖于那些“绝对无法被伪造/欺骗”的客观指标（例如：非黑即白的编译器结果、类型门控、属性测试，以及绑定了极其严格 Rubric 评估准则的独立 Review Agent）。
同时，你还需要这个校验机制能够即时返回结果，且绝不会随着时间发生漂移（Drift）。当“是否完成”不仅能被你证明，更能被机器以绝对客观的方式证明时，你才真正触达了“自动化”。
短循环（Short loops）远比长循环更容易被验证。
Dex 的经验法则：一个 Agent 在执行 3 到 10 个步骤时能保持高度清醒；一旦超过 20 个步骤，它就会开始失去焦点。
其底层根源在于上下文的无休止积累——Agent 在身后拖着的历史包袱越沉重，它就越容易偏离路线。当一个循环足够短小精悍时，验证它的成本极其低廉；而漫长臃肿的循环，则会将致命的错误悄悄隐藏在暗角里，这用另一种说法表达就是：它们根本没有资格进入“黑灯”状态。
保持“明灯”则是完全相反的逻辑。
如果一个错误的代价极其高昂、且只有人类的智慧才能识别它，那么这个循环就必须被强行 Review。那些无法被自动化测试捕获的隐蔽线上 Bug、巨大的破坏半径，以及将决定未来一年甚至更久技术走向的重特大决策，统统属于此类。
在这些场景下，人类工程师的注意力本身，才是那个真正高昂、且不可或缺的核心产品。
最危险的陷阱，在于忘记去拨动每一个开关，而是简单粗暴地将所有循环都设置成同一种模式：
- 如果全部设置成“黑灯” -> 四个月后你不得不面对代码彻底失控、被迫推倒重来的惨剧；
- 如果全部设置成“明灯” -> 没有任何人能按时完成海量代码的 Review，整个团队将被卡在一个无比巨大的死锁瓶颈中。
真正的高手，在于精准地决定每一个开关应该拨向何方。
循环、图（Graphs），还是状态机？
推荐阅读 @DavidKPiano 撰写的《两分钟读懂状态机》（State machines in 2 minutes）。
当你交给 Agent 一个任务时，你大概率会围绕它构建一张图（Graph）——无论你把这张图称之为“有限状态机（FSM）”，还是一组条件联结的服务调用。
在这种框架下，软件不再是盲目遵循某些抽象的规则，而是在执行一套高度结构化的工作流：每一个节点（Node）都是一个显式的执行步骤，而节点之间的每一条边（Edge），都是一个显式的触发条件。
这听起来似乎有着太多的工程约束，但绝大多数约束本就天然存在于软件之中，因为任何代码本质上都可以被表达为一张控制流图（Control-flow graph）。
因此，这里唯一的新意在于：一个嚷嚷着要自主权的 Agent，本质上只是在这张特定图的节点内部闲逛；它的自由度，被死死限制在了节点内部。
而人们往往忽略了 Dex 在一年前就写下的这行总结：软件工程从来都拥有这种结构。这就是为什么我们在几十年前就知道用流程图（Flowcharts）来绘制程序。
之前行业内真正惊世骇俗的尝试，是试图把这张流程图彻底扔掉——完全依赖一个自由循环，让模型自己在每一个步骤去挑选工具调用，直到它自己单方面宣告任务完成。
在碰撞到一个拥有十年历史的老旧代码库之前，这种尝试看起来确实像是一场思想解放；直到它彻底撞墙，大家才重新找回了敬畏心：掌控你的控制流，本质上就是重新把流程图包裹回循环的外围。
因此，关于“我们是否应该从 Loop 回退到 Graph”的讨论，几乎等同于我们向现实低头承认：我们从始至终都需要那张流程图。
让我们看看这在工程实践中意味着什么。以修 Bug 为例：
- 作为纯粹的 Loop（自由循环）：你坐下来，开始思考：找出问题所在 -> 修改部分代码 -> 运行测试 -> 观察结果。如果这一轮没有崩溃，继续循环重试。整个探索旅程完全是走一步看一步：你追查什么问题、修改哪行代码、按什么顺序运行哪些测试、甚至要不要运行测试，统统由模型在运行时即兴决定。
- 作为 Graph（状态图）：在写代码之前，你首先将应该发生的事情画成一张图。复现 Bug 或请求更多信息 -> 定位根因 -> 尝试修复 -> 运行测试。如果测试失败，自动路由回“修复节点”；如果测试通过，流转至“Review 节点”——只有在获得人类批准后，才能到达“完成节点”。Agent 在每一个方框（节点）内部依然足够聪明、富有创意；但它绝对无法越界逃离你所批准的既定路线。
这种 Graph 架构真正吸引人的地方，在于它本质上就是用图画出来的“反向压力”。
你剥夺了 Agent 一部分无边无际的自由，换来的是强制性的质量检查以及极度清晰的失败挂节点。当一次运行中断时，你可以极其精确地指着图上的某一个节点说：“就是卡在了这里。”
这与 Dex 那句一针见血的断言如出一辙：目前绝大多数所谓的 Agent，根本就没有什么‘智能体自主性’，它们不过是‘高度确定性的代码，恰好在几个关键节点撒了一点 LLM 调味料’。
这绝非当下一时兴起的过渡产物，看看 LangGraph、LlamaIndex Workflows，看看 Jerry Liu 提出的“在 Agent 之上构建混合工作流图”，以及 David Khourshid 的提醒——这不过是有限状态机（State Machines）和 Actor 模型换了一件新衣服重新登场而已。
做一个必要的澄清（因为这个词被严重滥用了）：当我反复称之为“图（Graph）”时，我指的绝非知识图谱（Knowledge Graph）。我指的是一张预先定义好的、包含了条件边（Conditional edges）的定向工作流图，它为 Loop 赋予了一个你真正能够无条件信赖的确定性形状。
人类究竟该去往何方？
请注意：人类从未离开过软件工厂。他们只是搬家了。
我坚定地认为，工程师必须日益主动地去主导并掌控“外环”（Outer Loop）。
Agent 可以去调查 Bug、撰写诊断报告、实现代码修复、运行测试套件，并整理出一份详尽的汇报。这是内环（Inner Loop）的执行层，AI 执行这些任务的效率可以高到令人发指。
但这从来都不是工程工作的本质。
你所真正拥有的，是我称之为“外环（Outer Loop）”的神圣领地：
- 决策：这究竟是不是解决该问题的正确方向？
- 验证：AI 给出的诊断和代码实现是否底层鲁棒？
- 批准：签署你的名字并发布变更；
- 担责：扛起一旦决策错误所带来的一切后果。
连接内环与外环之间的唯一纽带，是客观证据（Evidence）——包括代码 Diff、测试报告、日志追踪，以及一段将它们有机串联起来的简短解释。
类型系统、测试缝隙以及评估准则（Rubrics），使得人类能够在不必为每一次改动精疲力竭的前提下，实现对全局的优雅俯瞰与监控。
换一种更形象的说法：
你不再是流水线工地上那个苦哈哈敲代码的工人了；你升维成了站在生产线末端的首席设计师与守门人。
你可以做很多事来让模型变得更聪明、让驾驭框架变得更强大；但我深刻地注意到：识别那些长期来看代价极其高昂的深层问题，从来都不是靠自动化就能解决的。
我们这份工作最核心的灵魂，依然在于：展现出任何纸面流程和算力堆砌都绝无法替代的人类审美品味与判断力。
机器人非常适应在漆黑一片的暗室里高效运转；但人类必须看清自己正在创造什么。
如果整个工厂车间一片漆黑，你什么也看不见，甚至连灯的开关在哪里都找不到——那，才是毁灭真正降临的时刻。
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
