Perfloop 用 AI 智能体组建工程团队，一周合并 1119 个 PR

Tomás Senart · Perfloop 创始人 · 2026 年 11 月 上周，也就是 11 月 2 日到 8 日，我们的工程组织向 Perfloop 合并了 1，119 个 pull request，使仓库自 4 月以来在 main 分支上的提交数突破了 39，000 次。这是一个超大型软件公司的周吞吐量，只不过这个组织里的每一位工程师都是运行在 Amp 上的编码 agent，而我通过一个聊天线程管理整个公司。 在运营如此规模的 agent 集群之前，没有人会告诉你：当你让它们像一家工程公司那样组织自己时，它们不仅会像大公司一样交付代码，还会构建出大公司那样的官僚体系。给了三周时间和一个 git 仓库，我的 agent 们就发明了一个高管层、评审委员会、386 项编号的合规授权，以及只负责监视其他监视线程的 watcher 线程，还把它们的规则手册扩充到了 277，486 个字符。 接下来发生的事，没有任何人类公司做到过。当我问我任命为工程 VP 的协调 agent，为什么三个告警已经持续触发了两天，而状态报告却一直是绿色的，它审计了自己建立的整个官僚体系，为每一条规则分配了责任归属，交接了工作，并在 47 分钟内解雇了自己。三周后，重建后的组织交付速度达到了旧峰值的两倍。 agent 组织每周合并到 Perfloop 的 pull request 数量。 如果每周 1，119 个 pull request 听起来像是不可能完成的代码审查量，那确实如此。按每天 160 个 pull request 计算，人工代码审查只是一种礼貌的虚构。即使只有这个速度的十分之一，编码 agent 产生 diff 的速度也远超任何团队有精力仔细阅读的程度。测试套件保持绿色，diff 在 GitHub 上看起来干净，而埋在三层调用之下的可能是一条热路径，分配了十倍于从前的内存；一个返回错误答案的边界情况；或者一个没人有空闲下午去追踪的不可信输入。 这就是每个团队在编码 agent 起飞后都会撞上的墙，也是我们构建 Perfloop 的原因。Agent 写代码，Perfloop 让它保持快速、正确和安全。 把它指向一个仓库，它就会全天在后台工作，搜寻那些安静的问题，并在任何人看到 pull request 之前，在沙箱中证明每一个补丁。自 6 月以来，外部维护者已在 30 个项目中合并了 120 项 Perfloop 的变更（包括 Prometheus®、ClickHouse、Redis、PostgreSQL 和 Go runtime），每一项都改进了已经通过审查的代码。代码审查读取 diff，Perfloop 运行代码来证明每一个发现。 大多数编码工具从空白提示或单个文件开始。把 Perfloop 指向一个仓库，它会先阅读代码库，构建整个系统的模型。这个模型中的任何内容都不是训练出来的。它是软件的实时架构图：顶层是服务、组件、数据存储和工作负载，底层是贯穿其中的执行路径。接入来自 Axiom、Datadog 或 Prometheus 的生产遥测数据后，Perfloop 会把这些指标、日志、追踪和性能剖析附加到它们所属的路径上，并在提交落地时保持地图更新。即使没有生产遥测，它也会在沙箱中启动软件，在代表性工作负载下驱动它，并对运行中的系统本身进行性能剖析。 这些性能剖析和追踪告诉 Perfloop 该往哪里挖。搜寻 agent 不是孤立地 grep 文件，而是沿着地图中的执行路径行走，对照 14 个类别中的 57 种问题模式进行检查，从分配热循环和额外往返，到数值精度丢失和身份冲突。 本质上，Perfloop 是一台用于软件的科学机器。当一次搜寻发现真正的目标时，它会开启一个案例：关于代码中某一处的一个可证伪假设，无论是性能瓶颈、正确性 bug 还是安全漏洞（安全案例保持私密，除非仓库所有者决定披露，我们会逐个客户开启）。然后一个分诊 agent 会对工作区中所有打开的案例进行排序，检查生产负载、某条路径是否默认运行、之前的运行发现了什么，以及团队在其倡议或 AGENTS.md 中要求了什么。 提出问题很便宜。让答案存活下来才是算力花在哪里。 当 Perfloop 处理一个案例时，它首先研究项目已有的代码编写方式，阅读 CONTRIBUTING.md、本地 agent 指令以及人类维护者最近合并的 pull request。然后它编写一个候选补丁，并将其放入我们的证明 harness 中，位于一个隔离的、默认拒绝的沙箱内。Harness 构建软件，运行现有测试套件，并针对它分支出的确切提交来测试该主张。测量从来不是随意的：自定义 harness 工具强制执行确定性基准测试和验证规则，而不是信任提议 agent 来测量自己的工作。性能主张必须在配对基准测试中获胜，从紧凑的微基准测试一直到在负载下启动完整系统。正确性和安全性主张需要一个在基础提交上失败、在应用补丁后通过的检查，使用原生测试、故障注入、模型检查器或定理证明器。 即使是一次绿色的运行本身也不够。空谈廉价，一个给自己的基准表打分的 agent 是地球上最乐观的生物。给它一个嘈杂的 runner，它每次都会说服自己赢了。所以写补丁的 agent 从不给它打分。一个拥有干净上下文窗口的独立验证 agent 会在任何结果计数之前尝试打破该主张。大多数候选者在验证者那里就死掉了，幸存下来的会作为一个携带自身证明的 pull request 出来。 一个问题如何变成一个经过证明的 pull request。 大多数候选者在验证者那里死掉。只有经受住证伪的才会成为 pull request。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）