Harness重建Git仓库以应对AI智能体高并发流量

作为Harness的现场首席技术官之一，马丁·雷诺兹大部分时间都在向工程主管们提出一个没有简单答案的问题。

那就是他们如何跟上编码智能体现在产生的所有拉取请求（pull request）。其中一位主管最近的回答只有两个字："跟不上"，并解释说他团队将代码推送到生产环境的门槛已经降低了，雷诺兹在接受The New Stack采访时表示。

TNS在Harness推出重建后的代码仓库和全新AI代码审查产品几天后，与雷诺兹进行了交流——而就在几周前，GitHub在8月17日经历了近八小时的平台中断。

在此次交谈中，双方讨论了审查瓶颈是如何产生的、Harness为何要为智能体流量重建其Git仓库，以及流水线中哪些部分应该保持确定性。

淹没在拉取请求中

雷诺兹表示，他第一次遇到这个瓶颈是在Harness早期试用GitHub Copilot和亚马逊CodeWhisperer期间。

"我们收到的PR越来越多，但所有PR都卡住了，"他说，"测试团队都在喊，说我们跟不上这些了。"

"想象一下那个测试团队现在的感受。"——马丁·雷诺兹，Harness现场首席技术官

新代码量增加了1.5到2倍，这让测试团队濒临崩溃，他说，而现在，他有时会看到有些团队的代码量达到了10倍，甚至有人声称达到了50倍。"想象一下那个测试团队现在的感受。"

雷诺兹指出，在会议期间与工程主管们的走廊交谈中，被拉取请求淹没是一个反复出现的主题。而他与客户交流时看到的情况往往分为三种：一些人提高了风险容忍度，一些人有积压的工作无法处理，而大多数人处于中间地带。

"我认为处于中间地带的情况最为常见，"雷诺兹说。"我们正在使用某种AI工具来帮助我们应对这个问题，但这并不一定能解决问题。"

审查变化的内容，而非脚手架代码

理想情况下，审查者打开一个拉取请求时，应该首先看到最重要的变更，雷诺兹说，他建议审查者应该来自之前处理过代码库该部分的人，"而不是写提示词或编写代码的人。"

"另外那些东西，比如因为更新了依赖项而改动的30个文件，这些在需要重点关注方面就没那么重要，"他说。审查者应该"真正审查正在发生的变化，而不是一堆围绕它的脚手架内容。"

"这不仅仅是模型本身的事情，"他还指出。Harness在过去12个月中花了"相当大的一部分时间"构建了一个所谓的软件交付知识图谱，这是客户流水线、部署、事件和策略的地图，这样审查者就能"快速获取上下文，而不会消耗大量Token"。

该公司自己举的例子是，一次迁移因为早期事件审查发现一个未加索引的CREATE INDEX语句曾锁定生产表长达14分钟而被标记出来。

据该公司自己统计，其工程师每月节省了超过10000小时的人工审查时间。Harness发布产品的当天，GitHub的Copilot代码审查开始审查由机器人（包括其自身的编码智能体）打开的拉取请求。

智能体不遵循朝九晚五的工作制

最近，Harness在GitHub上的客户"确实经常真的会发给我们GitHub宕机的截图"，雷诺兹说。

他认为GitHub遇到困难的原因是，GitHub"最初是为人类而构建的，团队规模可能最多10到15人，负责修改代码、创建拉取请求。那些拉取请求可能会存在几个小时到几天不等。"但智能体"不会朝九晚五地工作"。

Harness自2023年在其开源Git项目基础上推出Harness Code以来，一直在销售仓库服务，雷诺兹表示公司已将其重建为"一个从零开始构建的、既适用于人类也适用于AI的AI优先仓库"。

他形容这是基于Kubernetes的架构，运行在多个云和地区，经过每秒数千次提交的测试，并在测试阶段被约20家企业客户使用，Harness未公布这些客户的具体名称。

GitHub首席技术官弗拉德·费多罗夫针对8月17日宕机事件的事后分析报告称，"美国中部数据中心的一个关键基础设施组件未能实现扩容"，当时流量达到了新高峰。GitHub目前每月处理29亿次提交，平均每秒略高于1000次。

当然，这与Harness运营的规模不同，但对于其企业用户来说，这或许正是一种优势。

Harness也开始将目光投向传统流程之外。雷诺兹认为，实现自主交付生命周期的能力如今已经具备，但"组织和公司是否已经为此做好准备？我不完全确定。"

无论如何，他表示确定性工具仍需保留，测试结果仍应来自测试运行器。"没有必要把这些东西全部拆除并替换掉。问题在于，你能在哪些地方对它们进行增强？"

审查器是大多数团队会最先接触到的这次发布的部分。它可以处理已经存在于GitHub上的拉取请求，而迁移一个仓库对大多数企业来说是一个长期项目。

那位告诉雷诺兹"我们跟不上"的工程主管，并不需要一个新的Git托管平台来改变这个答案。他需要的是某种工具，能够告诉他的审查者，拉取请求中哪些文件仍然需要人工审查，哪些30个文件只是因为依赖项升级而产生的。

这比自主交付生命周期的承诺要小得多，但就目前而言，这也可能是更实用的那一个。

Q&A

Q1：Harness为什么要重建Git仓库？

A：因为AI编码智能体产生的拉取请求数量激增，传统为人类团队设计的Git平台（如GitHub）难以应对这种高并发、全天候的流量，导致平台不稳定甚至宕机，因此Harness打造了专为AI和人类协作设计的新一代仓库系统。

Q2：AI代码审查产品能解决什么问题？

A：它能帮助审查者快速识别拉取请求中真正需要人工关注的核心代码变更，而不是被依赖项更新等无关紧要的"脚手架"文件淹没，从而节省大量人工审查时间，据称每月可节省超过10000小时。

Q3：GitHub宕机与AI智能体有关系吗？

A：有一定关系。GitHub最初是为人类团队设计的平台，而AI智能体的工作方式与人类不同，它们不遵循朝九晚五的作息，会持续不断地产生代码提交和拉取请求，这种高强度的流量对现有基础设施构成了压力。