Anthropic、OpenAI与xAI正在重新设计软件开发生命周期,使编码智能体周围的流程能够跟上AI生成代码的速度。
AI translation, not an official translation. Refer to the original for technical details.
Adapted from @rakeshgohel01# AI原生SDLC:围绕编码智能体的开发循环 Anthropic、OpenAI与xAI如何围绕智能体重建软件开发 Anthropic于2026年8月发布的操作手册提出了一套AI原生SDLC,其核心观察简单明了:编码智能体如今可以在数小时内将定义清晰的任务转化为拉取请求,而审批、审查、安全检查和发布流程往往仍在以人工速度运行。OpenAI正在试验Codex和测试工程框架,xAI也开放了Grok Build背后的部分机制。综合来看,它们的工作指向这样一种开发模式:围绕编码智能体构建的系统,其重要性不亚于编写代码的模型本身。 更深层的转变在于,被重新设计的单元不再是编码任务,而是围绕智能体的开发循环。 ## SDLC是为人工速度的软件开发而生的 代码不再是软件开发中最慢的环节。Anthropic在其AI原生SDLC操作手册中直言不讳地指出了这一问题:团队现在可以使用编码智能体以传统开发流程从未预设处理的速度生产软件。代码的速度加快了,但审批、审查、安全检查和发布流程往往并未跟上。 软件开发生命周期(SDLC)是团队将软件从创意推进到生产环境所遵循的流程。它通常经历规划、设计、构建、测试、部署和维护等阶段,文档、审查与审批将各阶段连接起来。 这一结构形成于实现工作是软件交付中最耗时环节之一的时代。产品经理可以撰写需求,架构师可以设计系统,工程师可以构建,QA可以测试,安全或发布团队可以审查。 如果Claude Code能够在数小时内将一份已批准的方案转化为可运行的变更,那么要求组织其余部分继续按周度审查周期运作,就会产生一种新的排队现象。Anthropic指出,一旦构建速度大幅加快,瓶颈就会转移到规划、审查与测试以及部署等环节。围绕代码的流程也必须随之改变。 ## 从流水线到循环 该操作手册提出了一套六阶段AI原生SDLC——规划、设计、构建、测试、部署和维护——其中各阶段不再那么线性。每个阶段都可以产出一份制品,供下一阶段读取并据此行动,而生产环境的反馈则可以将工作送回同一流程重新处理。 例如,流程可以从一个描述所需变更的intent.md文件开始。一份被接受的意图引出spec.md,进而引出实施计划。经批准的计划产出代码和测试用例。此后,生产环境中出现的问题可以创建新的意图,并将变更再次送入同一循环。 人工不必再将需求从某次会议中取出、重新写成工单、向工程师解释,然后再向审查者解释实现细节。制品本身承载着上下文向前传递。 这并不意味着每个工程团队都可以简单地用Markdown文件替换其现有工作流程。大型团队已经依赖于问题追踪系统、设计工具、审批流程和合规记录等系统。实际挑战在于如何将这些系统与智能体可读的工作流程连接起来,同时不失去它们所提供的管控能力。 Anthropic将这条已提交的制品链描述为审计追踪的组成部分:记录了什么被请求、什么被规划、什么被构建、什么经过审查,以及生产环境中发生了什么。人类仍然负责需要判断力的决策,但他们的注意力转移到了判断力真正发挥作用的节点上。 ## Anthropic、OpenAI 与 xAI 正在围绕智能体层面走向融合 它们发布的研究成果指向一个相似的模式:模型嵌套于一个由上下文、工具、权限、测试与反馈构成的更大系统之中。各家公司的具体实现方式有所不同,但这个围绕模型的外部系统,正在成为构建和使用编程智能体方式的更重要组成部分。 这些概念在不同层面上发挥作用。AI 原生软件开发生命周期描述的是生命周期本身;执行框架描述的是智能体运行的环境;循环工程描述的则是运行如何被触发、状态如何被供给、结果如何被评估,以及流程如何终止。 **Anthropic:将工作转化为已提交的制品** Anthropic 的 AI 原生软件开发生命周期手册提出了一个简洁的理念:将开发工作转化为制品,供智能体读取、更新,并传递至下一阶段。一份 `intent.md` 文件记录需要完成的事项及其原因,进而可演化为规格说明、计划、代码和测试。生产信号最终可再次启动这一循环。 一个相关理念体现在 Claude Code 中,通过 CLAUDE.md、技能(Skills)与钩子(hooks)来实现。代码库的规范约定、命令、架构决策,以及从过往工作中积累的经验,都可以被书面记录下来,供智能体在未来任务中调用。Anthropic 的手册还描述了围绕实现过程的持续评估,以及多层次的智能体审查与人工审查机制。 一条简单的指令可以说明其中的差异:**完成前进行验证** 该指令为智能体设定了一个可验证的条件,只有满足该条件后才能宣告任务完成。测试、代码规范检查规则与评估机制,赋予系统发现错误变更并将智能体重新送入循环的能力。 **OpenAI:围绕智能体构建执行框架** OpenAI 通过其所称的"框架工程"(harness engineering)得出了相似的结论。在一项实验中,一支小团队使用 Codex 构建了一款内部产品,其中代码由智能体生成,而非由工程师手动编写。这一过程并非不需要人类参与:工程师负责设计架构、代码库结构、工具、约束条件,以及使智能体驱动的工作流成为可能的反馈系统。 OpenAI 描述了一个代码库的组织方式,围绕 AGENTS.md、架构文档、计划、安全指导和质量跟踪等文件展开。这些是其实验中的工作流惯例,并非 Codex 所要求的通用文件。 它们让智能体能够获取以下信息:系统应如何运作、变更应如何进行,以及该代码库中质量意味着什么。OpenAI 的核心观察直截了当:当智能体成为主要实现者时,工程师会将更多时间用于设计环境、明确意图和构建反馈循环。 来看一个简单的例子。当智能体被要求添加身份验证功能时,模型或许知道如何实现 OAuth,但代码库需要告诉它:哪个身份提供商是经过批准的、密钥可以存储在哪里、哪些文件不可修改,以及在变更合并之前必须通过哪些测试。这些信息属于执行框架,而非模型本身。 OpenAI将这个运行框架描述为Codex在其网页、CLI、IDE和桌面体验中的底层代理循环。Codex App Server通过双向JSON-RPC接口暴露该底层能力,使不同客户端能够使用相同的代理机制。模型负责编写代码。 运行框架决定该模型如何与代码仓库、工具、用户及周边软件进行交互。 **xAI:开放代理循环** xAI通过Grok Build使这一层级具有异乎寻常的可检视性。当xAI将Grok Build的运行框架开源时,它暴露了其编程代理背后更多的机制,包括上下文组装、模型响应解析和工具调度。该代码仓库还提供了关于代码编辑、命令执行以及代理辅助工具的实现细节。 这一开源实现强化了上述观点。其工具集包括权限控制、计划审批、子代理、MCP、钩子和会话恢复。xAI不仅仅是在开放一个能够编写代码的模型,而是在开放让代理得以运作的整套机制。 **缺失的那一层:模型周边的系统** 当你审视围绕模型运转的部分时,这条共同脉络便愈发清晰。它决定了代理能够看到什么、能够修改什么、被允许做什么、其工作如何被审查,以及出现问题时会发生什么。这套周边系统正日益成为产品本身的重要组成部分。 ## **从AI原生SDLC到ADLC** 随着代理承担起贯穿规划、实现、测试和部署的工作,部分从业者将这一更广泛的转变称为ADLC,即敏捷开发生命周期(Agentic Development Lifecycle)。相关术语尚未统一。Anthropic使用"AI原生SDLC",而ADLC描述的是代理跨越整个开发生命周期运作、而非仅协助某一孤立任务的更宏观理念。关键的区别在于代理承担多大的责任。 代理现在能够检查代码仓库、调用工具、运行测试、评估结果、响应故障,并在无需人工输入下一个提示词的情况下持续工作。一旦代理能够编写代码,验证便成为一个更难解决的工程问题。系统需要可由机器检验的方式来测试工作成果、检测故障,并判断是否需要重新运行。 **从提示代理到工程化循环** 循环工程(Loop Engineering)是描述这一转变的新兴概念:开发者不再在每个步骤手动提示代理,而是由系统定义运行如何触发、接收何种状态,以及由哪些可机器检验的条件决定是否继续或停止。 一位过去需要花一个下午来实现某个功能的开发者,或许会将同样的时间用于决定代理被允许修改哪些内容、如何衡量成功、哪些测试必须通过,以及在哪些节点需要人工介入。 人类的判断转移到了另一个层级。 代理可以处理重复性的执行工作,但仍然需要有人来定义意图、设计约束条件、审查重要结果、管理权限,并决定系统何时可以发布。Anthropic自身的做法是在需要判断力的节点保留人工审查,而非试图将人类完全从开发生命周期中移除。 自动化能验证的内容是有限度的。一个智能体可以运行代码库中的每一项测试,却仍然遗漏那些测试本身未能编码的需求。安全决策和产品决策也可能面临同样的问题。智能体能够在无人干预的情况下执行的工作越多,其约束条件、评估机制和人工审批节点的质量就越重要。 ## 那么,我们现在究竟在构建什么? 这一领域的名称或许最终会定格为 AI 原生 SDLC、ADLC,或其他称谓。但工程问题已经十分明确:构建一套系统,让智能体能够完成有价值的工作、验证其结果,并判断何时需要人工介入。 对于刚开始推进这一转型的团队而言,第一步并不需要打造完整的 AI 原生 SDLC。选取一个工作流,将其输入、成功标准、测试方式和审批节点明确化。然后衡量周期时间、审查延迟、返工情况、逃逸缺陷、人工干预节点,以及无需上报即完成任务的百分比——而不仅仅是代码行数或拉取请求的数量。 软件开发正在从"让智能体写代码",转变为"构建一套系统,使智能体能够在其中安全地完成有价值的工作"。 这正是 AI 原生 SDLC、智能体执行框架与循环工程正在重塑企业软件交付方式的深层逻辑。 👇 如果您正在主导这一转变,您目前最大的瓶颈在哪个环节:规划、评审、测试,还是部署? 我专为真正在构建 AI 智能体的人解读其底层逻辑。如果您正是其中一员,欢迎建立连接 👉 https://www.linkedin.com/in/rakeshgohel01/ 📌 驱动真实业务成果的 AI 智能体。让我们一起构建,预约探索通话:https://juteq.ca/ 订阅新闻通讯:https://rakeshgohel.substack.com/subscribe #AINativeSDLC #ADLC #AgenticAI #AIEngineering #EnterpriseAI #AIAgents #EngineeringLeadership 参考资料 - Anthropic:AI 原生 SDLC 实战手册 – https://claude.com/blog/the-ai-native-sdlc-playbook - OpenAI:执行框架工程 – https://openai.com/index/harness-engineering/ - xAI:Grok Build 现已开源 – https://x.ai/news/grok-build-open-source - OpenAI Codex 关于 AGENTS.md 的文档 – https://developers.openai.com/codex/guides/agents-md.md