自动驾驶公司:Replit如何用AI Agent重塑组织

过去六个月里，Replit 工程师的代码产出接近增长到原来的三倍。代码审查时间保持稳定，回滚和产品事故没有增加，质量指标反而改善，发布节奏也在加快。人们通常预期的那些取舍，并没有出现。

代码只是最容易被看见的部分，真正有意思的变化发生在水面之下。现在，Agent 会调查生产事故、审查 Pull Request、回答内部问题、分析业务数据、分诊客服工单、研究销售账户，还会继续改进驱动 Replit Agent 自身的系统。

我们认为，这代表一种新型组织的开端：自动驾驶公司。

自动驾驶公司并不是没有人的公司。人仍然选择目的地，决定哪些问题值得解决，作出艰难取舍，运用品味，并对最终结果负责。只是越来越多时候，人不再亲自执行抵达目的地所需的每一个步骤。

转折发生在去年年底。和许多从事 AI 的人一样，我们在圣诞假期后回到工作岗位时，都感到某些基础性的东西已经改变：模型可以在更长的时间跨度内持续工作。

过去反复失败的任务，例如告警分诊和根因调查，开始变得可行；AI 甚至开始解决一些最顽固的 Bug。于是，我们不再把 Agent 仅仅视为编辑器或聊天窗口里的工具，而是谨慎地把它编织进公司的运行结构。

工程团队证明价值后，采用过程便有了自己的生命力。一个又一个团队开始把最乏味的工作交给 Agent，把时间还给真正推动业务的战略思考和创意工作。人们没有觉得自己被自动化取代，反而觉得自己被“升职”了。

下面就是 AI 如何彻底改变 Replit 工作方式的故事。

工程团队最先看到影响

1 月下旬，我们扩充了基础设施，以便快速试验内部 Agent 用例。我们复用了自己的 Agent Harness、microVM 和远程文件系统，使任何工程师都能并行编排一群 Agent。随后，又用访问策略、Token 代理、审计日志和 Zero Trust 网络把整个系统保护起来。到这一步，我们才放心让 Agent 访问完成工作所需的系统：GitHub、GCP、Azure、Linear、Notion、Slack、Zendesk 等。

当 Agent 能够跨系统获得上下文后，生产力出现了跃升。过去失败的实验变得容易，最直接的影响首先出现在编码数据中。

今年 3 月 Agent 4 发布前的一周，我们进入冲刺状态。通常这时会议会消失、范围已经明确，工程团队进入纯执行模式，一天有时会工作长达 16 小时。但这一次不同：生产力曲线以从未见过的方式向上弯折，而变化可以追溯到新内部 Agent 系统的普及。从 1 月初到 6 月底，工程师贡献的代码行数增长了 5.8 倍。

每周代码变更量：传统工作方式与新 Agent 工作流对比。

这部分增长当然也来自持续招聘优秀人才，而且新 Agent 能缩短新人达到生产力所需的时间。为了得到更干净的数据，我们剔除招聘影响，只观察固定的一组代码作者，仍然看到代码量达到原来的 2.9 倍。传统上，团队扩张时能保持人均产出不下降就已经很优秀；我们却在团队规模翻倍的同时，把人均产出提高到近三倍。

你可能会问：这么多新代码由谁审查？是不是把瓶颈转移到了代码评审？实际情况是审查延迟基本持平，主要因为我们也让 Agent 参与代码审查。它能够判断风险等级，只在必要时请求第二位人类审查者。目前，人类用于 PR 审查的时间已经减少约 30%，而且这一比例还在增长。

当 Agent 编写并审查更多代码时，我们自然应该担心质量。但从 PR 回滚率和新增事故数量来看，趋势都保持平稳。这意味着，如果以代码规模为分母衡量，质量实际上在改善。

原因之一，是这些流程本身也得到了 Agent 辅助。人类代码评审者拥有 Agent 共同审查，因此更多 Bug 能在上线前被发现；针对真正有影响的 Bug 或生产事故，Agent 会尝试寻找根因，于是平均缓解时间（MTTM）正在下降。

最终检验标准是：更多代码输入是否带来了真实价值输出。工程工作的终点，是为用户交付功能。我们在 Linear 中跟踪项目，让销售和营销团队知道何时可以向用户介绍新功能。数据显示，项目完成速度与代码产出一起显著提升。

“Agent 的 Agent”让循环工程规模化

把镜头拉近，我们能更具体地看到这种工作方式。当工程师找到可以构建循环的任务——把一支 Agent 舰队派出去完成一项能够被验证的工作——变化最为显著。每位员工都可以使用一个“经理 Agent”，由它生成多个子 Agent，代替员工编排在循环中协作的 Agent。

这些循环还产生了一些非常独特的 PR 贡献图谱。

一位工程师完成了停滞已久的 CSS 系统迁移，并把自己的经验分享给团队；另一位工程师自动化了一次迁移，使产品能够推进本地化；还有人把不稳定测试的维护自动化。我们的 CTO 则通过一群 Agent，终于攻克了一个与 PSC 和文件描述符关闭有关、极难处理的网络 Bug。过去关于“什么事情做得到”的假设，已经全部改变。

最令人兴奋的自动驾驶案例来自 AI 团队。他们建立了一套持续学习系统：分析用户反馈、提出改进方案，再结合基准测试和 A/B 测试验证收益。换句话说，Replit Agent 正在自我改进。

“自研还是购买”的讨论已经改变

新的内部 Agent 也改变了我们关于软件应该自研还是购买的讨论。我们经常尝试新的 AI 工具；购买现成方案有时能让团队更快前进，我们也会持续评估市场。但随着内部建设能力增强，我们需要购买的工具会越来越少。

现在，内部 Agent 已经能超过一些被视为市场领先的产品。我们刚刚停止续约一套金额达到七位数的 SaaS 方案，因为完全用 Replit 构建的内部应用表现更好，而且员工早已主动迁移过去。

突然之间，工具像是专门为我们量身打造的。内部 Agent 与公司知识库深度整合，加上各种定制，使其他解决方案显得逊色。

更令人意外的是，内部 Agent 也击败了我们评估过的垂直领域产品。一款帮助工程师分诊告警和调查事故根因的工具，质量相近，但成本是内部 Agent 的 10 倍；另一款自动化渗透测试工具发现的漏洞更少，成本同样高出 10 倍。我们的两个内部版本都很容易投入生产，既降低了事故 MTTM，也增强了关键系统抵御攻击的能力。

考虑到我们仍在快速学习、模型能力也还在提升，很明显，这一切才刚刚开始。

从工程团队扩展到整个业务

自动驾驶公司不会停在工程部门。Replit 的每一个职能都在改变。

Agent 很快从工程团队扩散出去，Slack 界面是最重要的推动因素。其他员工看到工程师在 Slack 中给 Agent 分配任务，便开始自己尝试。最初，最常见的用途是提问：把知识库与代码库当前状态结合后，任何人都能澄清产品预期，而不必等待工程师回复。得到答案后，他们还能让 Agent 直接修正文案或文档，响应用户的速度立刻得到提升。

但这只是起点。很快，来自公司各个部门的新 Skill 和集成开始不断涌现。

数据团队：让每个人都能可靠地分析业务

第一个重大突破来自数据团队。他们在数据仓库之上为 Agent 构建了语义层，使它知道哪些表是真实数据源，以及各张表之间如何关联。

现在，Replit 的任何员工都可以提出商业智能问题并得到可靠答案，也可以从实时数据生成图表和演示文稿——包括本文中的每一张数据图。数据团队因此能够专注于最难的问题，而不是不断处理临时取数请求。

最近，一位产品经理自己完成了一项复杂的发布分析，因为 Agent 理解代码库中的事件、这些事件如何进入客户数据平台，以及怎样把它们与复杂的订阅状态关联起来。

销售团队：更有质量的客户触点

销售也找到了相同的杠杆。销售开发团队用 Agent 发现并丰富产品合格线索；它能够利用通用工具看不到的内部知识，因此外联内容拥有更多上下文。

客户经理在会前用 Agent 了解哪些人获得了最大价值、哪些项目最活跃，以及客户的额度使用是否与合同匹配。随后，Agent 会把信息打包成针对该账户定制、符合品牌规范的演示文稿。自动驾驶销售团队可以与客户建立更多、也更高质量的触点。

营销团队：更早开始准备发布

营销团队只需一句 Prompt，就能让 Agent 根据工程和产品团队的对话、文档与产品信息，从零起草产品规格。这使营销人员不必参加每一场会议，也能更早开始准备发布并持续同步最新进展。省下的时间可以用于规划和创意，让产品正式进入市场时产生更大影响。

客服团队：最难工单的处理速度提高 60%

客服团队为 Agent 增加了调查问题和执行标准 Playbook 的 Skill。Agent 可以选择以统一的客服口吻提出回复，也可以把工单升级给工程团队，并附上工单摘要和完整调查结果。

自动驾驶客服团队处理最困难、需要升级到人工的工单时，速度提升了 60%。用户因此能更快回到自己的构建工作中。

接下来去哪里？

提高自身生产力令人兴奋，但真正激励 Replit 团队的，是让技术变得更加民主化。

我们希望把这种新的工作方式带给所有用户。团队正在努力确保系统具备大规模部署所需的策略、权限、安全和成本控制。Replit 最活跃的用户，是正在构建真实业务的创业者和企业客户；自动驾驶能力需要能够随这些用户一起扩展的安全措施。

这正是我们现在全力构建的东西。