原文作者：Itamar Friedman (@itamar_mar) | 编译整理：Hermes

通往 L4 级软件工程之路

智能体驱动的软件生命周期（Agentic SDLC）本身并不等同于“软件工厂”（Software Factory）。工程团队必须对此保持深刻认知，并明确掌控二者之间的本质分野。

在工程师专注于其他事务时，智能体已经能够独立编写代码、执行测试套件、响应审查意见并提交拉取请求（Pull Request）。将多个此类智能体串联协同，便能覆盖软件开发生命周期的绝大部分环节（若架构设计或沙箱隔离不当，甚至可能意外孕育出一个数字文明）。规划环节实现了智能体化；代码实现实现了智能体化；审查与测试同样实现了智能体化。

这无疑是一场意义深远的范式转变。但我们或许过于草率地从“智能体全面介入 SDLC 各环节”，直接跃迁至“我们已经拥有了软件工厂”的结论。

这两个论断之间的鸿沟，恰恰是当前软件工程核心工作沉淀（或正在转移）的关键阵地。这也正是工程团队构建最持久竞争壁垒的核心所在——即便工厂的大部分基础设施直接采购自第三方商业供应商，亦是如此。

软件工厂无疑是我们所有人都应瞄准的技术演进方向。随着代码实现成本的急剧降低，真正的系统级机遇在于升级整个交付体系：将一个原始设想，端到端地转化为可发布、具备完备监控指标且高品质的生产级软件。至关重要的是，具备实际工程价值的终局形态是有界自主性（Bounded Autonomy）：一个能够自主完成限定类别工作、产出充分事实证据以证明其满足规格要求，并在遭遇失败时具备内生处理能力、无需工程师对每次执行都介入救援的自动化工厂。

这一终局，即是我所定义的 L4 级软件工程。

Why the factory is the right unit of improvement

为什么“工厂”是正确的改进单元

更快的代码实现重塑了软件开发的经济学逻辑，但这绝不意味着交付效率会随之自动提升。如果生成一处代码变更仅需数分钟，而厘清其波及影响却要耗费数小时，那么生成技术仅仅是加速了一个宏观闭环中的局部切片。在此之外，依然横亘着大量核心工作：裁定系统究竟应当发生何种变更、恪守既定的架构约束、核验下游依赖的级联效应，以及最终判定产出成果是否切实为用户创造价值。

软件工厂范式使我们得以对这一更为宏观的完整生命周期展开主动、严谨的工程化设计。我们能够系统性地优化多项底层机制：业务需求如何被编译为确定性的可执行检查，组织级知识如何精准流转至目标智能体，代码变更如何被全方位验证，以及执行失败如何结构化地沉淀为后续运行的演进经验。对这套底层系统做出的任何一次迭代，都将使未来成千上万次的代码变更持续受益。

这一演进方向在当前行业最前沿的工程落地报告中已清晰可见。OpenAI 关于 Harness 工程的实践分析 揭示了工程师的精力投入重心地：围绕编程智能体构建确定性执行环境、代码库先验知识、架构约束框架以及高频反馈回路。这一关键转向决定了工程投入究竟在何处沉淀为长期的复利效应。

核心架构优先级的裁定准则是：系统 (System) > 智能体 (Agents) > 大语言模型 (LLMs)。基座模型的能力至关重要，智能体的系统设计同样不可或缺。但唯有上层系统，才能最终裁定：这些能力被派发何种工程任务、能够消费何种上下文信息、被授权触发何种动作空间，以及在其输出进入生产环境之前，必须强制提交何种事实证据。

更强大的基座模型固然能显著放大该系统的效能，但它本身绝无法替企业组织裁定其可接受的风险边界。

Agentic SDLC describes participation. A factory defines responsibility.

智能体驱动的 SDLC 描述参与，软件工厂定义责任

在智能体驱动的 SDLC（软件生命周期）中，智能体可以渗透到每一个阶段，但整个系统依然依赖人类来串联各个环节，并在每一个关键节点提供复杂的工程裁决。工程师依然需要澄清需求、修正实现方案、排查失败的测试、确认下游依赖，并最终拍板变更是否就绪。

这种工作流确实能够大幅提升生产力，甚至产出的代码也几乎完全由智能体编写。但这两种表象都无法反映交付系统本身的自主运行水平。

Stripe 的 Minions 系统让这种界线变得清晰具象。Stripe 描述了一种无人值守智能体，它能够自主推进任务完成编码实现并通过 CI，最终生成等待人工审查的 Pull Request。这固然是实质性的自动化跃升，但人工审查环节被明确保留。

本文所界定的“软件工厂”，是指围绕这一系列研发活动构建的完整生产系统：包括输入、上下文、执行环境、确定性验证、权限控制、交付机制以及反馈闭环。工厂可以以不同的自主化程度运行。在软件生命周期的各个阶段引入智能体，是构建软件工厂的重要一步，但它并未确立该工厂究竟能够承担哪些工程责任。

真正的核心问题在于：系统能否在无需人类反复补足缺失判断的前提下，自主驱动一项既定变更走完其被授权的全部生命周期。

The useful lesson from autonomous driving

自动驾驶领域的有益借鉴

软件自主性分级模型并非全新概念，@DanShapiro 关于五级演进的文章便是一例。这一类比极具参考价值，前提是我们必须明确：下文所探讨的软件自主性分级仅为一个前瞻性架构框架，而非已成型的行业标准。

自动驾驶分级中最具启发性的界限在于 L3 与 L4 之间。在 SAE 标准框架下，L3 级自动驾驶在限定条件下运行，但仍需人类作为动态接管兜底；L4 级同样在限定条件下运行，但无需人类介入即可自主化解风险、规避失效；L5 级则将这种自主能力扩展至人类驾驶员所能应对的全部场景。

因此，L4 绝不意味着“随时随地无所不能”。明确的运行边界，恰恰是其自主能力的根本基石。

将这一逻辑映射至软件工程领域：
* L0 级表现为人类主导执行并辅以传统自动化手段。
* L1 级表现为工程师主导开发全程，AI 仅在离散任务上提供局部辅助。
* L2 级阶段，智能体（Agent）已能执行实质性任务，但工程师仍需主动监督、逐项核验并串联最终产出。
* L3 级（智能体驱动的软件生命周期，Agentic SDLC）中，系统已能在限定条件下闭环驱动交付工作流，但人类依然是关键审批或异常恢复中不可或缺的依赖项。
* L4 级（“开灯”软件工厂，Lights-on Software Factory）下，系统针对有界（Bounded）的变更类别，能够自主完成获授权的全生命周期流转——涵盖确定性验证、受控发布操作以及安全回退机制，且无需依赖人类的实时干预来控制故障影响面。“开灯”的本质，在于工程师始终牢固掌握对软件工厂运行边界与系统演进的责任归属（Ownership）。
* L5 级（“黑灯”软件工厂，Dark Software Factory）则试图将这种全自主性推向软件工程的全域场景。这是一个边界极其宽泛的命题，即便能够实现，它也依然需要人类明确的目标输入、权限授予与最终责任归属。

这些自主性等级必须严格限定在具体的工作流与运行设计域（ODD）中进行评估。一个团队完全可以在某个架构认知清晰的内部服务常规变更上率先实现 L4，同时在涉及核心支付鉴权的链路中维持严密的纯人工管控。抛开具体的运行边界而将整个组织笼统地冠以“L4”之名，只会彻底掩盖真正具有工程意义的技术界限。

The extra step is engineering the boundary

进阶的关键一步：工程化定义系统边界

从智能体驱动的软件生命周期（Agentic SDLC）迈向 L4 级软件工程，要求我们必须明确界定自主执行获得授权的前提条件。

一切始于工作任务本身。涵盖哪些代码仓库、变更类型、依赖项和运行环境？适用何种权限与成本预算上限？哪些特征会导致任务失去准入资格？例行的依赖升级与核心鉴权模型的变更，绝不能仅仅因为同一个智能体都能处理，就继承相同的执行权限。

其次，必须以系统可评估的形式定义成功。工单（Ticket）极少能构成一份完整的技术规格说明。相关的工程需求往往散落在架构决策记录、故障历史、客户承诺乃至工程师的隐性记忆之中。软件工厂必须能够访问这些上下文，并具备在实现阶段将“主观假设”固化为“代码行为”之前，主动暴露歧义的能力。

验证机制还必须能抵御生成过程本身的投机倾向。StrongDM 的软件工厂实践报告提出了两条极具冲击力的准则：“代码不得由人类编写”以及“代码不得由人类评审”。而更具工程启发意义的，是围绕这些准则构建的基础设施：测试场景、验证测试框架（Validation Harnesses）以及外部依赖的行为级副本。StrongDM 将测试场景隔离在代码库之外，以防止智能体通过投机取巧来“刷通”测试，却并未真正交付预期行为。

这揭示了一个更宏观的架构诉求：生成变更的智能体，绝不能拥有暗中重新定义变更通过条件的权力。

独立的确定性验证体系依赖于受保护的验收准则、隔离的控制权限，以及立足于可观测行为的检查机制。仅仅赋予第二个智能体“评审者”的头衔并不能确立真正的独立性——两个智能体完全可能陷入同一种认知盲区，共享相同的错误假设。

Anthropic 关于生成器与评估器测试框架的研究在此处极具参考价值：解耦评估层确实有所助益，但评估器本身依然需要校准，且存在固有限制。验证机制本身就是一个需要被持续评估的工程系统。

@DexHorthy 在其演讲 《Harness Engineering is not Enough》 中提出了一个发人深省的命题：通过短周期的微观任务，与在数月维度上维持代码库的可维护性，完全是两个维度的目标。绝不能将当下全绿的测试用例，误视作工厂在未来依然具备系统演进能力的事实证据。架构与程序设计必须施加显式约束，而连续变更带来的累积效应，必须置于时间跨度下进行长效观测。

Evidence > Confidence claims

事实证据 > 置信度主张

软件工厂应当生成一份可供审查的完整记录，阐明为何允许某项变更继续推进：它解决了什么需求、通过了哪些校验、受控于何种边界约束、部署结果如何，以及仍存在哪些未消除的不确定性。

部分事实证据来自于确定性检查；部分则源于仿真模拟、对抗测试、模型辅助审查以及生产环境观测。没有任何单一手段能够提供普适的正确性证明。但它们结合在一起，应当能够在特定边界内为特定决策提供坚实支撑。

这一严谨的工程准则同样适用于对软件工厂自身能力的评估。智能体数量、生成的代码行数、无人值守的运行工时，这些指标仅仅描述了系统的活跃度。工程架构上真正需要明确的是：符合准入条件的工作被正确完成的概率有多高、仍需消耗多少人工精力、有哪些缺陷逃逸出了验证体系，以及单次故障的代价几何。被拒绝的任务与紧急人工介入必须一并计入该核算体系。

当运行发生异常时，事实证据还必须指导并支撑软件工厂的自适应响应机制。这正是 L4 级类比中我认为最具工程价值的部分。

在软件工程语境下，安全降级回退（Safe Fallback）可能意味着阻止发布、终止灰度推演、熔断特定功能，或是回滚至历史版本。但回滚并非总是可用；破坏性的数据迁移可能会让回滚完全失效。因此，软件工厂在启动执行之前，其运行边界就必须将此类约束纳入考量。

系统可以在达到安全状态之后请求人工协助。而让该工作流真正具备 L4 级意义的核心在于：遏制并收敛故障，绝不依赖人类专家立即重构运行链路并被迫接管。

与仅仅“让智能体通宵跑任务”相比，这显然是一个要求苛刻得多的工程标准。

责任掌控权 > 具体实现

如果这就是演进方向，工程团队就必须对自身的软件工厂拥有完整的责任掌控权（Ownership）。

所谓责任掌控权，是指团队能够决定工厂生产什么、以及何时产出达到合格标准的决策控制力，涵盖：组织上下文（Organizational Context）、系统架构、验收标准、权限策略、事实证据（Evidence）以及运行边界（Operating Boundaries）。同时，团队还必须具备故障根因诊断能力，并有权对产生该故障的系统本身进行迭代重构。

一个真正落地的实用型软件工厂，必然是团队自有工作流与专用智能体及外部平台的深度结合。例如，一个专用的代码审查智能体（Code Review Agent），必须为其配备专为缺陷发现而设计的上下文、工具链与评估基准。选用这类智能体，意味着要评估它根据全局系统架构与组织工程标准对变更发起质疑（Challenge）的能力。审查质量本身就是一项需要持续投入与量化评估的核心工程能力。

围绕这些智能体构建的基础设施亦是如此。所有的审查发现、修复补丁、异常情况以及发布决策，都必须沉淀为具备可解释性、可审计的记录，并通过遥测指标与报表清晰揭示残留风险与质量演进趋势。关于系统依赖关系、架构决策记录（ADR）以及历史故障的知识库必须保持最新状态，并精准注入给需要它的智能体。维护该记录体系与上下文，是一项持续性的核心工程实践。

对许多团队而言，采购这些专用能力是构建软件工厂的高效路径。一个能够维护上下文、实施标准治理或聚合事实证据的平台，可以作为团队生产系统的重要构件，支撑多种工作流与智能体协同运转。正如采用云服务并不能免除工程职责——工程师依然需要负责架构设计、组件集成、业务逻辑编写以及系统整体运维。软件工厂亦遵循同样的工程逻辑：采购的外部能力只是构建基石，团队仍须亲自设计、集成并掌控整套系统的运行。

工程组织需要亲自设计并实现能够贯通这些能力、动态供给上下文并将分析结果转化为工程行动的工作流。团队必须对完整系统实施端到端测试，在每个阶段清晰定义事实证据与执行权限，并建立健全的监控与自愈恢复机制。业务产品团队注入领域知识并对业务结果负责；平台与安全团队提供通用基础设施与防护管控。各方紧密协同，必须能够审计执行结果、对结论发起质疑，并在工作流未能达到预期标准时果断重构该流程。

这与 Kief Morris 提出的工程师在“控制环之上”（On-the-loop）运作的理念高度契合：工程师的核心职责是改良生产系统的底层机制。当故障发生时，修复眼前的代码变更仅完成了最表层的工作；更深层的价值在于优化上下文供给、强化边界约束、完善确定性验证或重构工作流，从而使系统在后续运行中表现出更高的可靠性。

凡是能够被显式化表达的重复性人工判断，都应当被固化为确定性规则、自动化测试或持久化上下文。如果每一次执行都必须由人工介入来完成相同的架构修正，即证明软件工厂尚未成功吸收团队的工程认知。捕获并沉淀此类判断，本身就是构建现代化生产系统的核心环节。

这些工程认知是组织的战略级资产。它精确沉淀了组织构建软件的独特范式、历次系统故障的经验沉淀，以及组织愿意将自主权让渡给智能体的清晰边界。随着智能体接管越来越多的代码实现细节，对这套核心认知与决策机制的责任掌控权（Ownership），将对工程成败起到决定性的作用。

Build toward bounded L4

迈向有界 L4

建议首先聚焦于某一类高价值场景，其业务需求与潜在风险必须已被充分理解与界定。为其明确准入规则、建立确定性验证体系、收紧其操作权限，并设计完备的兜底回退机制。在人工监督下运行该系统，并精细度量人类必须介入的具体环节。

每一次人工介入，都是系统能力缺失或边界定义不完备的关键事实证据（Evidence）。部分证据将指引我们优化工具链或补全上下文支撑；另一部分证据则表明该类工作仍应被严格排除在自主运行之外。核心目标在于厘清系统在哪些特定边界内，真正凭借其实际表现赢得了更高的自主权。

以此为基石，软件工厂（Software Factory）可依托经受验证的实际表现逐步向外拓展，同时在因影响重大或不确定性过高而需要严格管控的场景中，继续保持收紧的安全边界。每家企业的底层系统、合规义务及对失败的容忍度各不相同，因而在边界界定上也会做出截然不同的工程取舍。

正因如此，相较于空中楼阁式的全自动 L5，我更主张将“有界 L4（Bounded L4）”作为务实的技术演进终点。它为工程团队提供了一个清晰具象的系统建设目标，以及一套明确可度量的工程评估基准。

智能体驱动的软件生命周期（Agentic SDLC）通过将生命周期中的更多环节转化为智能体可执行任务，助我们逼近这一目标；而软件工厂则将这些能力整合为一个具备明确权限边界、事实证据支撑以及故障恢复能力的生产级系统。

工程团队面临的战略机遇，在于确立对该系统的掌控权（Ownership）并驱动其持续演进。未来的核心竞争壁垒将愈发取决于：该系统能否足够可靠地将业务意图转化为软件资产，以及每一次执行所沉淀的结果，能否有效反哺并改进下一次运行。