我们开始看到当一家公司学会自我运营时会发生什么。
过去六个月里，Replit 的工程师代码产出几乎翻了三倍。审查时间保持稳定。回退率和产品事故数持平。质量指标有所改善，发布速度加快。所有你可能预期的典型权衡都没有发生。
虽然代码是可见的部分，但表面之下发生的事情要有趣得多。
现在，Agent 会调查生产事故、审查拉取请求、回答问题、分析业务数据、分类支持工单、研究销售账户，并改进驱动 Replit Agent 本身的系统。
感觉就像有一个主智能贯穿于每个员工，尽管事实并非如此。它是一个不断扩展的 Agent 系统，在公司内运作：从人类那里获取目标、收集背景信息、执行工作、检查结果，并在需要人类判断时升级处理。
我们认为这代表了一种新型组织的开始：自我驱动的公司。
自我驱动的公司并非没有人类。人类仍然选择目的地。他们决定哪些问题重要、做出艰难的权衡、运用审美品味，并对结果承担责任。
但越来越多地，他们不再执行到达那里所需的每一步。
这一转变始于去年年底。像许多从事 AI 工作的人一样，我们圣诞节假期回来后感觉一些根本性的东西已经改变。模型可以维持更长周期的工作。
那些反复失败的任务，比如告警分类和根本原因调查，开始奏效。AI 开始解决我们一些最顽固的 bug。所以我们不再把 Agent 当作存在于编辑器或聊天窗口中的工具。我们小心翼翼地将它们编织进公司本身的架构中。
一旦工程团队证明了其价值，采用就变得自然而然。团队接二连三地开始卸载他们最繁琐的工作，将时间重新投入到真正推动业务的战略性和创造性思考中。人们并不觉得自己被自动化了。他们觉得自己被升职了。
这就是 AI 如何彻底改变我们在 Replit 工作方式的故事。
工程团队首先看到了影响
一月底，我们启动了基础设施，以便快速实验内部 Agent 用例。我们利用了自己的 Agent 框架、微虚拟机和远程文件系统基础设施，这样任何工程师都可以并行编排 Agent 集群。然后我们将整个系统锁定在访问策略、令牌代理、审计日志和我们的零信任网络之后。那时我们觉得可以安全地让 Agent 访问我们完成工作所需的所有东西：GitHub、GCP、Azure、Linear、Notion、Slack、ZenDesk 等等。
有了跨系统的上下文，我们看到了生产力的飞跃。以前失败的实验变得容易。最直接的影响体现在编码统计数据上。
当时正值三月份 Agent 4 发布前的冲刺周，通常我们会看到一个大高峰。会议消失，范围确定，工程团队进入纯粹的执行模式（通常每天长达 16 小时）。但这次不同。我们的生产力曲线以一种我们从未见过的方式向上弯曲，这可以追溯到我们新的内部 Agent 系统的采用。从一月初到六月底，贡献的代码行数增加了 5.8 倍。
每周变更的代码行数，现有工作流与新 Agent 工作流对比
这一增长的部分原因可以归功于良好的招聘。我们的新 Agent 加速了达到生产力的时间，这很好，但我们可以去除招聘的影响以获得更干净的数据。保持一致的作者群体，我们看到代码量是之前的 2.9 倍。传统上，在扩展团队时保持每个工程师的产出持平被认为是优秀的。我们却在团队规模翻倍的同时，将每个工程师的产出率提高了三倍。
你可能会想知道是谁在审查所有这些新代码，以及我们是否在审查过程中创造了新的瓶颈。我们的代码审查延迟保持平稳，很大程度上是因为我们让 Agent 参与代码审查。它现在能够评估风险级别，并仅在必要时才引入第二位人类审查员。这意味着 30%（并且还在增长）的人类 PR 审查时间被节省了下来。
随着我们的 Agent 编写和审查更多代码，我们应该担心质量问题。如果我们查看 PR 回退率（左）和打开的事故数，趋势是平稳的。这意味着我们实际上是在相对基础上有所改进。
一个原因是这些过程也由 Agent 辅助。人类代码审查得益于 Agent 联合审查员，因此更多 bug 被捕获。事故调查（有意义的 bug 或实际事故）由 Agent 辅助，它试图找到根本原因，因此平均缓解时间（MTTM）正在下降。
最后的考验是额外的代码输入是否代表真正的价值输出。归根结底，工程团队是为用户交付功能。我们在 Linear 中跟踪项目，以便销售和营销团队知道何时与用户沟通新功能。你可以看到项目完成率随着我们的编码量急剧上升。
一个自我驱动的工程团队能够交付更多，同时提高质量。
我们的 Agent 的 Agent 正在实现大规模循环工程
放大来看，我们就能了解这具体是什么样子。当工程师找到生成循环的方法，派遣一队 Agent 去完成一项可验证的任务时，我们看到了最显著的变化。每个员工都能访问一个管理 Agent，它可以生成多个 Agent，从而让你能够编排 Agent 代表你以循环方式工作。循环产生了一些非常独特的 PR 图，比如这些：
一位工程师完成了我们 CSS 系统长期停滞的迁移，并分享了他的经验。另一位工程师自动化了一项迁移，使我们能够本地化产品。还有一位工程师实现了不稳定测试维护的自动化。我们的 CTO 最终用一队 Agent 攻克了与 PSC 和 fd 关闭相关的最棘手的网络 bug。我们所有关于可能性的假设都改变了。
最令人兴奋的自我驱动例子来自我们的 AI 团队。他们构建了一个持续学习系统，该系统分析用户反馈、提出改进建议，并使用基准测试和 A/B 测试的组合来验证成果。Replit Agent 正在自我改进！
自建与购买的讨论已经改变
我们新的内部 Agent 也改变了关于我们自建还是购买软件的讨论。我们定期试用新的 AI 工具。购买解决方案可以帮助我们更快前进，同时我们也在不断评估市场。但我们自建得越多，需要做的购买就越少。我们的内部 Agent 现在胜过我们测试的一些被视为市场领先的产品。我们刚刚取消了一个七位数的 SaaS 解决方案，因为我们的内部应用完全在 Replit 上构建，并且员工已经迁移过去了。
突然间，工具感觉像是为我们量身定做的。与我们知识库的深度集成以及我们所做的定制化，使得其他解决方案相形见绌。
更让我们惊讶的是，我们的内部 Agent 也胜过我们评估的垂直特定产品。一个帮助工程师对告警进行排序和根本原因调查的工具，质量相当，但成本是我们在 Agent 上运行的 10 倍。一个运行自动化渗透测试的工具发现的漏洞比我们内部版本少，但成本却高出 10 倍。我们两个版本都轻松投入生产，减少了事故的 MTTM，并加强了对攻击的关键系统。
鉴于我们仍在学习如此之多，并且模型在不断改进，很明显这仅仅是个开始。
超越工程，进入整个业务
自我驱动的公司不会止步于工程。Replit 的每个职能都在发生变化。
使用很快从工程团队扩散开来，主要是因为 Slack 界面。公司其他部门注意到工程师用任务标记我们的 Agent，并自己也尝试了。最初，最流行的用例是提问。通过将我们的知识库与代码库状态相结合，任何人都可以在不等待工程输入的情况下澄清产品期望。然后这些员工可以跟进修复文案或文档。这立即提升了更快响应用户的能力。
但这只是开始。从那以后，来自公司各个部门的新技能和集成贡献开始涌入。
第一个重大突破来自我们的数据团队。他们为 Agent 提供了数据仓库的语义层，使其知道哪些表是事实来源以及它们之间如何关联。
现在，Replit 的任何人都可以提出商业智能问题并得到可靠答案。他们可以根据实时数据构建图表和演示文稿（包括本文中的所有图表）。数据团队将时间花在深入研究最困难的问题上，而不是处理请求。最近，一位产品经理能够自助完成复杂的发布分析，因为我们的 Agent 理解代码库中的事件、它们如何出现在我们的客户数据平台中，以及如何与复杂的订阅状态进行关联。
销售部门也发现了同样的杠杆效应。销售开发团队使用 Agent 来寻找和丰富产品合格的潜在客户，利用更通用的工具看不到的内部知识，从而让外展活动更有背景。客户经理使用它来准备客户对话，了解谁获得了最大价值、哪些项目最活跃以及信用使用情况如何跟踪合同。然后所有这些都被打包成针对账户定制的品牌幻灯片。一个自我驱动的销售团队与客户有更多、更高质量的接触点。
我们的营销团队可以使用 Agent，仅凭一个提示，基于工程和产品团队之间的对话和文档，从零开始起草产品规格。这让他们能够更快地开始发布工作并保持最新状态，而无需参加每一个会议。他们有更多时间进行规划和创意，这将确保我们的发布在推向世界时产生更大影响。
我们的支持团队为 Agent 赋予了调查问题并遵循标准操作手册的技能。它可以选择以我们标准的客户服务语气回复，或者将问题连同工单摘要和调查结果一起升级给工程团队。一个自我驱动的支持团队关闭最难的工单（那些升级给人类的）的速度快了 60%。用户能更快地回到构建工作中。
在每个例子中，人类并没有被自动化掉。他们被升职了。自我驱动将执行者变成了主管，而蓬勃发展的人是那些以结果为导向、设定方向的人。这正是现在最有价值的工作。
—
接下来去哪里？
提高我们自己的生产力令人兴奋，但真正激励 Replit 员工的是技术民主化。
我们希望将这种新的工作方式带给所有用户。我们正在努力确保能够以大规模部署所需的策略、权限、安全性和成本控制来实现这一点。Replit 最活跃的用户是企业家和企业用户，他们正在构建真正的业务。自我驱动需要能够扩展以满足这些用户的安全措施。
我们正在努力构建这一点。
鉴于上面的所有图表，你不需要等太久。
