
InfluxDB作者打造软件工厂,实现软件自我改进
来源标题:The Software Factory: The Rise of Self-Improving Software
InfluxDB 作者正为其打造“软件工厂”,即一个能持续为产品自动生成修复、功能和性能改进的软件系统。目前重点放在构建供 agent 验证代码变更的测试与验证基础设施上。他认为递归自我改进不只属于超级 AI,任何由软件工厂产出的软件系统都可受益。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
今年我一直在努力为 InfluxDB 打造一座软件工厂,这是我过去 13 年一直在开发的时间序列数据库。我把这项软件工厂的工作称为“建造造机器的机器”。如果你不熟悉“软件工厂”这个说法,我指的是一个持续运转的软件系统,它为我们卖给客户的产品(也就是 InfluxDB)不断产出改进(bug 修复、新功能、性能提升)。到目前为止,我的大部分精力都放在构建精细的测试与验证基础设施上,让 agent 能够用它来验证软件变更。我想,这跟大多数人想象中的软件工厂并不一样。然而,没有恰当的验证,软件工厂就无法运转(不过这是以后文章的话题了)。
随着我进入我认为更传统的软件工厂建设阶段(即创建工作流并让 agent 来运行它们),我有一个顿悟,事后看来相当显然,但当时让我觉得颇为激进。递归自我改进(recursive self-improvement,简称 RSI)并不只是用来创造某种超级智能 AI 的。任何由软件工厂产出的软件系统,都有潜力变成递归自我改进的系统。要理解为什么,我们得深入看看软件工厂可能是什么样子。
(注:整篇文章都是我本人亲手用爱写就,没有借助 AI,但下面的可视化图是在我的指导下由 Opus 5.5 生成的)
在工厂的顶端是输入(例如来自人类、生产监控和 agent 的输入),底部则是输出,比如软件制品、云服务、发给第三方的消息和输出、报告、文档,以及反馈回工厂的工作,还有工厂自身的系统。中间则是一条工作流,包含通往这些输出的各个步骤。你 already 能看出它是递归的,因为它的输出可以反馈回工厂,或者用于更新工厂,或者更新面向用户软件的生产系统。
输入可以来自多种来源,下面是一个简短的清单:
这些输入会导向我们所说的“任务”(mission),工厂真正接管就是从这儿开始的。一个任务可以是这样的:
这些显然还会有更多细节,但你明白意思。
对于 Slack 消息或支持请求这类输入,agent 会接手,然后创建一个复现用例,或者做一次调查,接着要么回复,要么升级给人类处理,要么为更大的工厂创建一个任务去解决。
一旦工厂接手一个任务,它就会实现、评审、细化和测试。这就是工作流,它可以由 agent 驱动的步骤、通过执行代码完成的确定性步骤,以及决策点组成。
要做真正的工作,最好的结果出现在你能够验证结果、然后让 agent 基于可验证的反馈进行迭代的时候。这会在不同维度上以不同规模发生,比如时间、token 消耗和基础设施开销。人类的注意力跨度也是一个成本因素。按成本递增顺序:
可能会有很多修复、评审、分诊的循环,每个循环都可以运行上面一个或全部验证步骤。有了验证,你就想挑最便宜的方式,来获得真实的经验性证据,证明某个变更有效并且是你想要的。
让人类检查任何东西,都是你能做的最慢、最贵的事。
还有很多实现细节我没有在这张流程里画出来。工厂的内部部分(也就是工作流)这里并没有真正定义,它依赖于各种工具和系统。我认为这些主要是测试、验证和数据库方面的问题(不是 InfluxDB,而是你的工厂数据库),但就本文的论点而言,并不值得深入探讨:
你可以把一座软件工厂变成你产品的 RSI 系统。
如果你看看这张图的各个部分,这就是显而易见的终局。至少我希望到现在它已经显而易见了。它已经是递归的,因为你的输入包括客户、支持、生产系统,而它可以输出回自身。而“改进”这部分之所以成立,是因为其中两个输出就是对工厂本身和软件产品的改进。
它如何变成自我改进的?很简单,你只需把工作流上的人类节点替换掉,让 agent 来接管。你可以设定规则或容差,决定什么时候让 agent 来做工作,或者交给人类检查。但如果你有一个调度器来启动 agent(上面的系统就有),而且它能向工厂输出任务,那就没有理由不能让其中包含任意数量通向 RSI 的事情。
我认为,你把根级 prompt 留得越通用(也就是给 agent 的自主空间越大),随着更好的模型被使用,RSI 就会变得越强大。如果你的工厂能在新模型发布时就把它们接入,你就把软件工厂的交付改进周期,绑定到了前沿 AI 公司向公众发布的 RSI 节奏上。
我不确定一年前是否可能有一座真正、优秀的软件工厂。也许用 Opus 4.5 和 GPT 5.2(这两个都还不到一年!)可以,但我真的认为 Fable 和 Astra(以及现在的 Opus 5.5)才让它变得可能且真实。我的猜测是,一旦我们这些平民拿到了目前 OpenAI 和 Anthropic 内部团队可用的模型,我们就能把任何软件工厂变成我们所交付软件产品的 RSI 系统。
6 个月前的模型,能力远不及今天的模型。很可能 6 个月后的模型也会同样更强。事实上,这个差距可能还会更大,因为改进的速度似乎在加快。
现在就把交付这类软件的工具链建好,能让你在模型进步时顺势起飞。这是一个令人兴奋的构建时代。
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。