软件工厂内部

作为一名在编码代理时代之前拥有七年多经验的软件工程师,我从来不喜欢振动编码的想法。但我知道它与使用编码代理生成干净、可维护的代码之间有明确的界限。好的软件原则与编码代理的结合是由软件定义的 [...]

来源:O'Reilly Media _AI & ML

作为一名在编码代理时代之前拥有七年多经验的软件工程师,我从来不喜欢振动编码的想法。但我知道它与使用编码代理生成干净、可维护的代码之间有明确的界限。好的软件原则与编码代理的结合是由软件工厂定义的。

这就是为什么三个月前,我建立了自己的软件工厂 Squid,以最少的人工干预来交付 Decoding AI 的所有中小型项目。第一个版本过于过度构建,我停止使用它。

与此同时,我不断看到人们痴迷于下一个“_____工程”标签,而不是关注可操作的结果。提示工程,然后是上下文工程,然后是利用工程。到目前为止,一切都很好。但在过去几周(2026 年 7 月,当我写这篇文章时),循环工程和图形工程的事情偏离了轨道,它们读起来更像是营销谈话,而不是解决实际问题的任何东西。自 2024 年 LangGraph 时代开始以来,图工程对团队如何构建 AI 应用程序进行了过度理论化。别误会我的意思。这些术语并没有错(Anthropic 的 Claude Code 负责人 Boris Cherny 说,“我的工作是编写循环”),但我们过度解释了几年前开始做的直观事情。

当您定义什么算作循环时,您并没有考虑实际交付软件的流程。

正确的框架是软件工厂,这是 2026 年人工智能工程师世界博览会的核心主题之一,Tereza Tížková(Factory.ai 的成长)将软件工厂定义为“自主开发软件的整个循环、整个生命周期”。

我打赌您已经对软件工厂是什么有了直观的认识。在本文中,我想进一步将其形式化并将其映射到软件开发生命周期(SDLC)中。我们将探讨您的软件工厂应该有多大,以及何时停止自动化,以免它增加的阻力超过价值。最重要的是,我想强调人类在这个过程中属于哪里,我相信即使在所有代码都是由人工智能生成的世界中,他们仍然属于哪里。

那么……什么值得自动化?人在哪里能带来最大的价值?什么值得建造,什么值得购买?

软件工厂的设计

就像物理工厂一样,软件工厂可以以最少的人力输入实现软件创建的自动化。原始工作(错误报告、功能创意、事件)进入。交付的软件出来。它需要一些高素质的人才做出高杠杆决策,并且需要明确的大门,没有他们,工作就无法通过。

Factory.ai 宣传“软件开发生命周期 (SDLC) 的自我改进系统”。 Addy Osmani 将堆栈定义为循环、线束、工厂:“循环就是原子”;工厂是“由循环组成的组织结构图”。 Warp 的首席执行官扎克·劳埃德 (Zach Lloyd) 表示,“软件工程将成为工厂工程。”

工厂由八个阶段组成,可分为三个部分:

构建什么。分类/接收对传入的工作进行分类、重复数据删除和路由。集思广益通过市场分析、用户数据和技术研究找到高影响力的功能。规划是最重要的阶段,将研究转化为完善的计划,通过让代理询问您来完善它,并在 ADR(架构决策记录)日志和术语表中跟踪决策。此阶段的输出是由代理团队可以实施的文档支持的票据,可以在纯文件或项目管理工具(例如 GitHub Issues、Linear 或 Notion)中进行跟踪。

人类所属的地方

不要过度建造工厂

在此阶段,代理以只读模式进行计划,遍历代码、AGENTS.md 文件,以及最重要的上下文层。

实际构建和检查。实施是由软件工程师和 QA 代理循环完成任务和支持文档。Review 根据产品、架构和代码标准检查 PR 差异。Review-CI 运行测试套件,失败会触发修复代理。Release 通过人工部署检查处理 CD 到暂存/生产。

自我改进。监控/事件响应将生产信号(警报、错误、事件)反馈到分类中,作为下一步构建内容的新输入,从而形成闭环。

与八个阶段正交的是上下文层。该层在队伍的前面尤其重要。头脑风暴仅限于它看到的数据:用户分析、竞争对手分析、研究、记录和文档。在这个阶段,糟糕的上下文层直接限制了你可以探索的可能性空间。它对规划也有类似的影响,将原始想法转化为技术规范和任务在很大程度上取决于上下文层中的示例有多好。如果你想实现一个新的产品推荐功能,并且你的例子为零,那么法学硕士只会预测最常见的事情,这通常不是适合你的产品的最佳解决方案。

上下文层可以采用多种形式。一种越来越流行的策略是 LLM Wiki,该术语由 Andrej Karpathy 创造。它基本上是一种将数据转换为结构化知识库的策略,只需使用文件而不是数据库。 Factory 通过其 AutoWiki 功能,将流行的代码库转换为结构化知识库,代理可以查询该知识库,而不是解析代码库本身。 LangChain最近发布了OpenWiki,这是一个用于管理代理内存wiki的CLI工具。如果您好奇,在本文中,我将详细介绍如何通过 LLM wiki 将 Obsidian、Readwise 和 Google Drive 中的数据转换为代理内存。

要了解人类所属的位置,让我们通过一个端到端的示例来浏览一下工厂。我们将在类似于亚马逊的电子商务平台上为购物助理代理构建一个功能。这种情况是,使用数据表明用户没有参与其建议,我们必须进行改进。

头脑风暴是品味的所在。代理负责繁重的工作:他们分析用户活动,扫描竞争对手的助手,并将研究结果纳入知识库。然后,技术人员开始查看数据,了解人们不接受建议的原因,探索竞争对手如何实施他们的解决方案,并提出修复方案作为功能规范。在此阶段,规范解决了业务问题。目前还不需要规定技术解决方案。

计划是人们在软件工厂的帮助下将功能规范转换为实施计划的地方。假设我们想要更改推荐引擎算法。人类与知识库交谈,弄清楚它是否可行,并思考架构、接口、数据流、成本和延迟。然后,他们让代理扫描代码库并进行审查,直到计划被适当地细化为适合代码库的内容。输出是一堆票证以及解释算法更改的 ADR 和术语表的更新。

代理可以通过快速扫描大量数据并改进计划来在这两个阶段提供帮助,但人仍然是核心。

从这里开始,我们进入“循环”和“图形”工程领域。

构建与购买

下一步是什么

使用最强模型(寓言)进行头脑风暴和规划。这些阶段消耗的代币比实现本身要少,但下游的一切都取决于它们。一个精心编写的计划可以让更便宜的模型(Opus、Sonnet)执行,而无需推理出死胡同。一个薄弱的计划会让他们重试,直到额外的代币消除价格差距。

由于计划薄弱,我在同一任务上看过 Sonnet 的高推理成本 Opus:较小的模型需要更多尝试才能达到相同的目标。总成本是代币×价格,而不是模型等级。因此,更多的失败意味着更多的推理、更多的代币和更多的成本。

Implement 运行一个软件工程师代理来获取每张准备好的票证。由于循环的范围仅限于某个功能,因此它只需要关联的票证。每张票证实施后,QA 代理都会尝试通过对应用程序进行压力测试来查找错误。由于代理往往对自己的工作抱有积极的偏见,因此软件工程师和 QA 代理之间的分歧很重要。正如 Addy Osmani 所说,编写代码的模型“对自己的作业进行评分太棒了”。在单独规模上,这个循环可以像一堆终端拉票一样简单。在更大规模的情况下,它运行在 24/7 工作的远程代理上。

仅当代理可以与应用程序交互时,循环才有效。 QA 代理需要一个命令来可重复地启动整个堆栈。从那里,它在浏览器中驱动应用程序,调用数据或微调管道,或者访问服务器的 API。无论您的应用程序的界面是什么,代理都需要访问它,就像人类用户一样。

关键思想是尽可能将反馈循环集成到您的软件工厂中。理想情况下,您需要多个级别,具体取决于运行它们的成本:linting、单元测试、集成测试和端到端测试。当循环不断失败时,根本原因几乎总是缺少管道,而不是代理。

审核分为三个步骤。第一步根据票据和 ADR 检查产品和架构要求。任何差异都会成为传递回实施循环的新票证。第二步确保代码质量(模块化、命名)并防止 AI 溢出,例如冗长的注释或神秘的函数名称。第三步着眼于 CI/CD 管道。在每一步中,任何失败都会自动创建由软件代理拾取的任务。

并非每个项目都需要全部三个步骤。 “工厂”以一个 PR 结束,您作为人类需要审查和合并它。但实际上,如果您花费足够的时间制定一个强有力的计划,那么到达您手中的 PR 通常已准备好按原样发布。

那么人类属于哪里?在集思广益和计划中你是不可或缺的,你回来进行最后的检查。代理拥有介于两者之间的一切。OpenAI 将这一点发挥到了极致:五个月内约 100 万行和约 1,500 个合并 PR,且零手写行。他们的框架是“人类掌舵。特工执行”。

在我的第一个 Squid 版本(我自己的软件工厂)中,我变得贪婪并追求完全的自治:大型远程工作流程、并行代理和端到端运行的大型管道。它奏效了,直到出现了一些不合时宜的情况。它通常会这样做。我无法调试它,无法在运行中停止它,也无法在不放弃运行的情况下重定向它。这是一个巨大的庞然大物,让我脱离了循环,我无法控制它。

底线。您需要能够介入、停止、重定向和中断它,同时仍然可以选择完全自主。

还有其他现成的“软件工厂”仅由 .md 文件中定义的技能和代理提供支持,例如 Matt Pocock 的技能存储库或 BMad 方法。

探索下一个

我意识到你需要两个选择。第一个是细粒度命令,可让您审视计划、实施特定任务或查看一个特定步骤。第二个,当您愿意给予代理 24/7 自主权时,是一个端到端命令,将所有较小的命令链接到一个完全自治的图中,例如一个大/计划和/实施-审查-所有命令。基本上,每个步骤都是一个“循环”,而整个管道是软件工厂的“图”。不过,请注意规划和其余部分如何分为两个不同的命令,因为规划始终是人类驱动的(至少如果您希望结果与您实际想要的保持一致)。

瓶颈是我,这是设计使然。老实说,自从 AI 编码代理热潮以来,我大部分时间都是独自工作,而且我不明白并行交付 100 个功能的人是谁。我的大多数功能(每个项目)都是相互构建的,这使得它们不可能并行化。随着项目的发展,你可以发现越来越多的可以并行实现的独立功能,但我仍然认为数量是有限的。

这就是为什么,当我并行化时,我只使用本地代理,每个代理通过工作树在隔离的代码库中运行。到目前为止,我从未感觉到需要 24/7 远程代理,或者想要管理它们的开销。

一个大团队可以证明更多的自动化是合理的,但它必须赢得它。因此,与任何其他软件产品一样,从小处开始,从自动化最耗时的瓶颈开始,并随着人们对系统的适应而逐渐增加复杂性。不要像我一样进行鱿鱼实验。

在所有场景中,您都将从预构建的编码工具开始。最流行的供应商锁定是 Claude Code 和 Codex。或者使用 OpenCode 或 Pi 进行开源,它的成功得益于其极简、可扩展的架构,让您可以轻松地在其之上进行构建。

但是选择一个工具并不等同于了解如何配置它并将其连接到您的软件工厂。这就是为什么每个人都需要知道,至少直观地知道编码代理在幕后是如何工作的:在终端中运行的代理循环,远程运行时会发生什么变化,如何评估它,以及哪些上下文工程策略可以使其便宜而不使其变得更加愚蠢。如果您想了解有关从头开始构建编码代理的更多信息,请考虑探索我在 GitHub 上的开源课程。即使您从未计划构建自己的安全带,这种直觉也能让您成为高级用户。

对于一个小团队,只需定义一组技能和代理,在编码工具(也称为您的软件工厂)之上对您的流程进行编码,您就能走得更远。为了简单起见,这就是我使用 Squid 所做的,我用它来实现我的所有项目。

但请记住,工厂主要是关于流程,而不是工具:不适合团队现有工作方式的工厂会增加摩擦,永远不会被采用,并且最终毫无用处。

当工程师您不亲自监督运行代理时,您就跨越了购买线。可观察性、追踪、成本追踪和按代币计费不再是可选的,而是成为某人的全职工作。跨分布式基础设施连接到 Linear、Slack 和 CI 的代理群是一个后勤地狱,这不是您的产品。这时就需要考虑现成的解决方案,例如 Factory.ai(随 Droid 代理一起提供)或 Warp 的 Oz。用 Warp 首席执行官扎克·劳埃德 (Zach Lloyd) 的话来说,“工厂的大部分不一定是新界面。它是对人们现有工作流程的集成。”

最小的构建,中间的购买,以及最大的构建。

但这是我想知道的:

另一方面,正如 OpenAI 关于其 Codex 构建产品的报告所示,当平台的限制成本超过了替换平台所需的团队成本时,你就会重新开始构建。

就在我们说话的时候,已经有人创造了下季度的“_____ 工程”术语。但用于输出真实代码的软件工程流程不会经常改变。这就是为什么你应该保持开放的态度,但同时关注可操作的结果,而不是过度思考如何给事物贴上标签。

正如扎克·劳埃德(Zach Lloyd)建议的那样:找到一个“工作中烦人的部分”并构建处理它的最小循环。

残酷的现实是,软件工厂才刚刚起步。它们远非完美,尤其远非完全“自治”。通常,当有人声称他们已经解决了软件工厂问题时,他们要么没有充分测试这个想法,要么试图将其卖给你。我相信我们将达到几乎整个软件开发生命周期都是自动化的程度(集思广益和规划除外),但目前我们仍在解决问题。

你们工厂的哪个阶段还最需要你?我不断地实现我的自动化,而瓶颈却顽固地停留在计划上。

  • 奥斯马尼,A.(2025)。 “循环工程。”十、
  • https://x.com/addyosmani/status/2064127981161959567
  • MacManus, R. (2026)。 “AIEWF 每日调度:循环、软件工厂和前沿部署工程师。”潜在空间。
  • https://www.latent.space/p/aiewf-daily-dispatch-loops
  • Factory.ai。 (日期不详)。 Agent-Native软件开发平台。https://factory.ai
  • 奥斯马尼,A.(2025)。 “软件工厂,光明与黑暗。”十、
  • https://x.com/addyosmani/status/2079442194449232227
  • Karpathy, A.(日期不详)。法学硕士-维基百科。 GitHub。
  • https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
  • Abboud, M.(日期不详)。 “编码代理实际上是如何工作的:OpenCode 内部。”
  • https://cefboud.com/posts/coding-agents-internals-opencode-deepdive/
  • 卡普尔,S.(日期不详)。 “构建和评估人工智能代理。”人工智能工程师。
  • https://youtube.com/watch?v=d5EltXhbcfA
  • OpenAI。 (日期不详)。 “利用工程:在代理优先的世界中利用 Codex。”
  • https://openai.com/index/harness-engineering/
  • 帕森斯 (Parsons),C.(日期不详)。 “Ralph Loops:构建可发送的愚蠢 AI 循环。”AI 工程师。
  • https://www.youtube.com/watch?v=2TLXsxkz0zI
  • Pocock, M.(日期不详)。 “软件基础知识比以往任何时候都更重要。”人工智能工程师。
  • https://www.youtube.com/watch?v=v4F1gFy-hqg
  • MacManus, R. (2026)。 “Warp 首席执行官扎克·劳埃德 (Zach Lloyd) 阐述为什么软件工厂是编码的下一阶段。”潜在空间。
  • https://www.latent.space/p/software-factories
  • Iusztin, P. (2026)。 “从头开始构建编码代理:利用架构。”解码人工智能。
  • https://www.decodingai.com/p/building-a-coding-agent-from-scratch-system-design
  • Iusztin, P. (2026)。从头开始构建编码代理课程。 GitHub。
  • https://github.com/decodingai-magazine/building-a-coding-agent-from-scratch-course
  • Iusztin, P. 和 Bouchard, L.-F. (2026)。 “LLM Wikis 作为人工智能代理的活记忆。”解码人工智能。
  • https://www.decodingai.com/p/llm-wiki-agent-memory
  • 订阅 Decoding AI 杂志,与 44,000 多名渴望学习如何构建自己的软件工厂的工程师一起加入!