什么是AI编码Agent Harness？Stripe、Shopify和Airbnb如何构建可靠的AI工作流

当工程团队首次将AI添加到他们的开发工作流程时，他们通常以相同的方式开始：让开发人员访问编码助手，然后看看会发生什么。

这对个人生产力有效。但当任务复杂时——迁移代码库、审计API接口、为数百个端点生成测试覆盖率——它会迅速崩溃。非结构化的AI编码Agent会产生不一致的输出，在模糊决策上停滞，并以难以追踪的方式静默失败。

这就是Stripe、Shopify和Airbnb的工程团队正在大规模解决的问题。他们构建的有时被称为AI编码Agent Harness：一个结构化工作流引擎，用足够的脚手架包装AI模型，使它们在生产环境中可靠、可审计和可重复。

理解什么是Harness——以及这些公司如何应用这种模式——为你提供了构建类似东西的实用蓝图，无论你的团队有5个工程师还是5000个。

什么是Harness？

“Harness”一词来自软件测试。测试Harness是使代码可测试的基础设施：它提供输入夹具、捕获输出、验证结果并处理设置和清理。被测试的代码对Harness一无所知。它只是运行。

AI编码Agent Harness将相同的思想应用于LLM。 它是围绕AI模型的基础设施层——管理它接收什么上下文、它可以调用什么工具、当它产生错误输出时会发生什么，以及复杂任务如何被分解为模型可以可靠执行的步骤。

没有Harness，AI编码Agent只是聊天窗口后面的模型。有了Harness，它就变成了一个你真正可以部署的确定性工作流组件。

实际区别如下：

没有Harness：你将代码粘贴到聊天界面。模型建议更改。你审查、复制、粘贴并手动测试。如果它错了，你重新开始。
有了Harness：工作流接收任务，将其分解为子任务，在每一步向模型传递结构化上下文，验证每个输出，重试失败，并记录完整跟踪以供审查。

Harness不会让AI更聪明。它让AI在生产系统中可用。

可靠Harness的核心组件

每个严肃的AI编码Agent Harness实现都共享一些结构层。确切的实现各不相同，但这些组件在构建可靠AI工作流的所有团队中一致出现。

结构化上下文管理

改善AI编码输出的最大杠杆是控制模型看到的上下文。给它太少，它会做出假设。给它太多，质量会随着模型失去对重要内容的跟踪而下降。

上下文管理层通过以下方式处理这个问题：

将大型代码库分块为相关片段
注入项目特定的约定——风格指南、类型定义、API合约
根据当前任务动态过滤上下文
在多步骤工作流中管理token预算

团队通常构建检索系统，只为每个任务 surfaced 最相关的代码、文档和架构决策，而不是将整个代码库转储到提示词中。

工具调用基础设施

现代AI编码Agent不仅仅生成文本——它们调用工具。这意味着运行测试、执行linter、读取文件系统、查询数据库或触发CI/CD管道。

Harness定义了可用的工具、强制执行权限、处理速率限制并重试失败的工具调用。这一层将语言模型变成一个可以采取行动和观察结果的Agent——这对任何多步骤任务都至关重要。

输出验证

AI模型生成看起来合理的输出，但有时是错误的。生产Harness不信任模型输出——它验证它。

验证可以是：

语法：代码是否解析？是否编译？
语义：测试是否通过？输出是否符合预期的schema？
领域特定：生成的处理程序是否遵循团队的安全模式？

当验证失败时，Harness要么重试（附加关于失败的上下文），要么升级到人工审查。

编排和子任务路由

复杂的编码任务无法在单个提示词中完成。重构模块、生成全面的测试或迁移API接口需要将任务分解为顺序或并行子任务，并相应地路由每个子任务。

编排层决定：存在哪些子任务、它们按什么顺序运行、哪个模型处理每个子任务（更便宜的模型用于简单分类，更强大的模型用于复杂推理），以及一个步骤的输出如何馈送到下一步。

这是多Agent模式进入的地方：专门的子Agent处理任务的离散部分，由更高级别的编排器协调。

可观察性和审计跟踪

在生产中，当出现问题时你需要知道发生了什么。Harness记录每个提示词、每个工具调用、每个模型输出和每个验证结果。

这有两个目的：调试失败和构建评估数据集以随时间改进系统。

Stripe如何处理AI辅助开发

Stripe是业内最具工程驱动力的公司之一，他们对AI工具的方法反映了这种严谨性。他们的团队始终优先考虑构建范围紧密且可验证的AI系统，而不是广泛且不透明的系统。

文档即合约

Stripe的API以其文档质量著称。在内部，该文档充当AI工作流的真实来源。当编码Agent生成涉及API端点的代码时，Harness会将相关规范作为权威性上下文 surfaced。

这通过为模型提供精确的参考而非依赖训练数据中的回忆来减少幻觉。模型不是在猜测接口——它是在读取它。

验证优先生成

Stripe的工作流模式不是生成代码然后检查它，而是首先建立验证标准。Agent在开始之前就知道成功输出的样子——测试用例、类型签名、集成规范——Harness在每个生成步骤之后立即运行这些检查。

失败的验证作为结构化错误上下文馈送到模型，而非原始堆栈跟踪。这种结构化反馈循环在复杂生成任务上显著提高了成功率。

受控范围

Stripe将AI Agent保持在狭窄的范围内。他们不是构建可以”对代码库做任何事情”的Agent，而是构建能做好特定、有限事情的Agent：为模块生成测试覆盖率、建议类型改进、标记潜在的破坏性更改。

一个狭窄的Agent可以被评估和信任。一个广泛的Agent很难推理。

Shopify如何在商户规模构建AI工作流

Shopify的情况与Stripe不同。他们支持数百万商户，每个商户都有独特的店面、应用和工作流程——并且他们将AI集成作为整个公司的战略优先事项。

CEO Tobi Lütke在2025年初明确表示，AI使用是每个员工和每个团队的基本期望。这不是试点项目——这是一种运营模式。

Sidekick和面向商户的Harness

Shopify的Sidekick产品是面向商户的AI助手。背后是一个将商户请求路由到专门Agent的Harness：一个理解产品目录上下文的Agent、一个知道当前主题结构的Agent、一个可以修改店面逻辑的Agent。

每个子Agent都有狭窄的范围和受限的工具集。编排器路由任务、收集输出并组成连贯的响应或行动。

Hydrogen的开发者工具

在开发者端，Shopify为其基于React的店面框架Hydrogen构建了AI辅助工具。在自定义店面上工作的开发者可以获得理解Hydrogen组件模型、Shopify API和特定项目结构的AI帮助——因为Harness在每次请求之前注入了这个上下文。

没有这个上下文注入，模型会给出通用的React建议。有了它，它会给出真正适合项目的建议。

评估作为一等公民

Shopify更干净的模式之一是以与产品QA相同的严谨性对待AI工作流评估。他们构建自动化评估管道，针对真实情况对AI输出进行评分，在提示词更改时运行回归测试，并在生产中监控输出质量。

没有这个，很容易在一个任务上改进AI工作流而在另一个任务上静默退化。评估基础设施捕捉到了这一点。

Airbnb如何管理全代码库AI任务

Airbnb最公开的AI编码项目也是Harness模式行动最清晰的例证之一：他们使用LLM将JavaScript代码库的部分迁移到TypeScript的大规模努力。

这个项目非常值得研究，因为它解决了一类问题——批量代码库转换——交互式AI工具无法处理。

规模问题

在大型monorepo上手动将JavaScript迁移到TypeScript将需要数百个工程师小时。逐个文件使用编码助手交互式地进行仍然会花费大量时间并产生不一致性。

Harness模式通过将迁移视为批量工作流而非交互式过程来解决这个问题。人力从执行转向监督。

他们的管道方法

Airbnb的迁移工作流遵循清晰的管道：

分类步骤识别了迁移候选的文件
上下文提取拉取相关类型信息、导入链和现有测试
转换步骤将每个文件发送给LLM，附有结构化指令和精选上下文
验证针对每个输出运行TypeScript编译器和现有测试
失败的文件被路由到审查队列，而非静默跳过

结果是一个可以大规模自主运行的系统，人工监督集中在异常而非每个文件上。Airbnb的工程团队已经撰写了关于将LLM工具应用于大规模代码任务的文章，这个迁移工作成为了负责任应用模式的参考点。

结构化错误恢复

一个关键的设计选择是失败如何处理。当TypeScript编译器拒绝生成的输出时，错误被结构化、摘要化并馈送回模型进行第二次尝试。如果第二次尝试失败，文件被标记为人工审查。

这种带上下文的重试模式是可靠AI工作流的基础。没有它，失败率在大批次中会复合。

三家公司出现的共同模式

当你观察Stripe、Shopify和Airbnb构建的内容时，相同的设计决策出现在每个实现中。

狭窄范围，可组合Agent

这些公司都没有构建一个做所有事情的大型Agent。它们构建小型、专注的Agent，具有明确的职责，并将它们组合成更大的工作流。这是多Agent模式最实用的形式。

一个狭窄的Agent可以被测试。它的失败模式是可预测的。当它崩溃时，问题是局部的。

验证循环，而非仅生成

每个生产Harness在每个有意义的步骤都包含验证。代码被编译。测试运行。Schema被检查。模型输出永远不会被盲目信任。

这将心理模型从”AI生成代码”转变为”AI生成候选，系统过滤有效的”。

结构化上下文，而非原始转储

上下文是精选的，而非复制的。这些团队没有发送整个代码库或长对话历史，而是构建上下文管理系统，为当前步骤精确 surfaced 模型需要的内容。

这提高了质量、降低了成本并保持系统可预测。

在定义阈值处人工介入

这些Harness都不是完全自主运行的。有定义的阈值——置信度分数、验证失败次数、范围边界——在这些阈值处工作升级到人工。Harness定义了自动化在哪里停止，审查从哪里开始。

这使系统值得信赖。工程师可以委派任务，而无需担心未检测到的失败静默传播。多Agent系统中负责任AI部署的原则强化了这一点：明确的升级逻辑不是设计的弱点——它是使生产部署可行的特性。