会自己写出来的集成

2026 年 8 月 14 日

工程团队在集成这件事上面临一个规模化难题：客户想要的集成，往往比工程团队能靠人工构建和维护的更多。

给合同工办理入职这样一件小事，就足以说明问题。客户希望 Ramp 在批准合同工之前，先通过 Checkr 发起背景调查；但如果这个集成尚不存在，工作流就会停在两个产品的边界上。

最显而易见的答案，是把 Checkr 集成做出来。但 Checkr 之后永远还会有下一个 Checkr。路线图可以覆盖最常见的服务商，却不可能覆盖客户接下来需要的每一种工具、工作流和服务商。于是，我们换了一个问题：如果每增加一个集成都不需要工程师亲手构建，会怎样？

围绕这个想法，我们构建了两套系统。在客户侧，他们只需描述自己的需求，底层便会自动构建集成并完成任务。在我们这一侧，内部的集成工厂会把同样的需求转化为所有人都能使用的第一方集成。我们已经用这种方式交付了 75 个集成，把原本需要数周乃至数月的工作缩短到数小时；对于只想尽快解除阻塞的客户来说，甚至只需几分钟。

如今，客户的需求必须先经过请求渠道和工程排期，最终才能交付。

让用户构建自己的自定义集成

这是方案的前半部分：一套智能体系统会识别客户想要、但我们尚未提供的集成，并在几分钟内自主完成构建，让客户可以顺畅完成原本要做的事。

客户全程不必离开产品。原本需要提交请求的地方，现在会直接构建并使用集成。

用户只需在原本正在构建的工作流中描述任务，例如：“在批准这名合同工之前，先通过 Checkr 运行背景调查。”智能体会识别出当前没有 Checkr 集成可完成这项工作。它会研究 Checkr 的 API，理解到足以正确使用 Checkr 的相关领域知识，向客户索取凭据，构建并测试集成，并在运行时持续修复问题。

一个集成通常只是按正确顺序发起若干次 API 调用，以完成一项任务。因此，我们就以此为基本单元，并定义了几个术语。**配方（recipe）**是一条经过身份验证的调用所需的精确配置：调用哪个端点、如何验证身份，以及预期的输入和输出模式。**配方簿（recipe book）**则是一组有序的配方，以及把它们组合成一个集成的逻辑。

智能体会自行编写配方，并逐一进行隔离测试。随后，它会把这些配方串联起来，将一次调用的输出传入下一次调用的输入，并生成用于执行集成逻辑的脚本。生成只发生一次；此后每次使用该集成时，调用的都是这个确定性脚本。

在底层，智能体会阅读 Checkr 的文档，并理解一次调查需要先创建候选人，再发送邀请，以及这些 API 应该如何使用。它会通过安全组件索取 API 密钥，而不是让客户把密钥粘贴进 LLM 上下文，因此模型永远看不到凭据。随后，它会在集成可用之前完成测试：自动修复 4xx/5xx 错误，并检查成功响应是否真的代表预期结果，因为服务商接受了调用，并不等于调用就是正确的。集成投入使用后，同样的检查还会在后台持续运行。因此，当服务商更改了某些内容时，集成会自行诊断故障并修复，而不是等到有人提交错误报告。短短几分钟内，集成便准备就绪，用户最初请求的工作流也会直接完成，用户根本无需操心集成细节。

这些自定义集成不会被困在创建它们的那段对话里。它们会成为真正的一等集成：可以成为采购工作流中的一个步骤，也可以成为 Ramp 智能体能够调用的工具，供企业内的任何人使用。

现在，我们不仅能满足 Ramp 上每家企业的各种长尾集成需求，还得到了一项更令人兴奋的成果：相比等待客户主动提出需求，这些自定义集成能更准确地告诉我们客户需要哪些集成。

然而，信号的价值取决于我们能用它做什么。如果每个第一方连接器仍然需要 Ramp 工程师花费数周来交付和维护，那么知道客户反复为自己构建哪些服务商的集成，也没有太大帮助。

我们的集成工厂

于是，我们构建了方案的另一半：Ramp 内部的集成工厂。只要给它一个服务商，一个定制的 Inspect 智能体就会研究 API、构建连接器、使用测试凭据完成测试和自动修复，最后创建拉取请求。过去需要我们手工构建的同一个第一方集成，如今不需要工程师参与，便能在数小时内自主完成构建与测试。

现在，两条路径都会汇入同一座自主运行的工厂。工程师不再逐个手工构建集成，而是审查并完善工厂的产出。

我亲眼看着工厂端到端交付了它的第一个集成。我们需要一个用于 AI 检测和内容净化的 Pangram 连接器。工厂研究了 API、完成实现、向我索取测试凭据（通过不会把凭据注入 LLM 上下文的安全链接）、完成测试并创建拉取请求，整个过程的成本不到 15 美元。我唯一的贡献，就是给它一个 API 密钥。几小时内，我们便合并代码，并开始在产品中使用它。

这种工厂真正的价值，在于消除各个阶段的工程瓶颈：构建、测试和审查。我们已经看到，前两项所需的工作量几乎降到了零。那么审查呢？我们改变了审查者所关注的内容。工厂会在 PR 中附上证据：它接触过的每一个端点、发出的请求、真实服务商返回的响应，以及新连接器测试过程的产品级屏幕录像。你不必信任代码，只需信任这些产物。它能够安全地原样合并，还有另一个原因：它没有接触任何共享代码。新服务商拥有自己的独立模块，位于与单体应用隔离的连接器服务中，只是为该服务商增加了一个新工具。代码质量仍然是极其重要的工程支柱。

至此，我们闭合了循环：自定义集成本身就是一份详细规格。工厂可以接手它，将其作为第一方集成交付给所有人。

很快，某个客户的自定义集成就会成为所有客户开箱即用的功能；而作为第一方集成，它还能变得复杂得多。

安全

安全是 Ramp 的另一项重要工程支柱。自定义集成意味着 Ramp 要向客户提供的 URL 发起经过身份验证的调用，因此我们在设计上假定请求可能是恶意的。

任何数据发出之前，系统都会先检查目标地址。配方中的 URL 必须使用 HTTPS，主机名也必须与该配方所记录的允许列表匹配：要么完全一致，要么是合法的子域名。因此，evil-checkr.com 无法冒充 checkr.com。我们还会解析主机名，并拒绝任何指向私有或内部地址空间的目标。配方创建时，目标地址就会固定下来；运行时输入只能填充请求体和查询参数，用户之后传入的任何内容都无法重定向调用目标。

随后，调用会通过隔离的出口路径发出，因此运行生成脚本的沙箱无法连接我们的其他任何系统；返回的响应也会受到大小和时间限制。该出口路径是无状态的，既不保存数据库，也不保存密钥。抵达服务商的数据，仅限于配方声明的输入模式所携带的内容。一切都限定在创建该集成的企业范围内：配方不可变，并按企业分别进行版本管理；沙箱也在对应企业的作用域下执行。当工厂测试新连接器时，它使用的是测试凭据和合成数据，而非客户数据。

无论是自定义集成还是集成工厂，都绝不会把凭据直接放进 LLM。客户侧的密钥通过安全组件输入；工厂需要测试凭据时，则会发送一条安全链接。无论哪种方式，凭据都会在不进入智能体上下文的情况下写入加密存储，并在运行时嵌入，LLM 无法访问。

成效

这项工作仍处于早期阶段，但我们已经看到了巨大的价值。工程师的职责从逐个构建集成，转变为构建并完善那台能够构建集成的机器。

经验

• 让模型参与构建时，而非运行时。 智能体只需研究、编写并测试一次配方簿，真正交付的是确定性脚本。把模型排除在执行路径之外，才让自定义集成真正可靠。
• 只把无法确定性处理的部分交给模型。 身份验证、模式、端点、重试和验证都可以一次定义，再由代码强制执行。真正需要模型的，是阅读服务商文档并弄清 API 的含义。
• 自主性的边界由验证决定，而不是由代码生成决定。 编写连接器从来不是难点。让我们能够合并工厂代码的，是随代码附上的证据，也就是针对真实服务商每个端点的实际运行记录。只有当智能体的工作能够以足够低的成本接受检查时，它才值得信任。
• 权宜之计就是规格。 理解客户的最佳方式，是观察他们如何使用你的产品，而不是等他们提出请求。当客户构建自己的集成时，他们已经准确告诉了我们需要什么，还附带了一个可工作的示例。这比他们可能提交的任何需求文档都更好。

愿景

我们只是最先在集成上看到了这种变化。真正的转变，是软件能够看见客户想做什么、识别缺失的部分，并当场把它构建出来。

这正是人们开始称为软件工厂的形态：系统不只是帮助工程师写代码，还会闭合“决定构建什么”与“真正构建出来”之间的循环。人们开始负责设定方向和标准，而不再把注意力集中在实现上。我们的工厂碰巧生产的是集成，但其中的机制没有任何一部分只适用于集成。

这就是 Ramp 前进的方向，也是整个行业前进的方向。最先抵达那里的团队，不会是让智能体写出最多代码的团队，而会是工厂能够在规模化运行中获得信任的团队：他们验证智能体产出的速度，能和智能体生产的速度一样快。

致谢

过去 12 周，我在 Ramp 构建这些系统的经历非常精彩。在这里，我不断获得快速成长、从零构建并交付产品的机会。我相信，任何时刻的我，都是那些曾经投入心力帮助我、挑战我并信任我的人的总和。每一周、每一个月、每一个新版本的自己，都由身边的人塑造。因此，我想感谢几位让过去 12 周如此意义非凡的人。

感谢我的经理 Vishal。你不断推动我成为更好的工程师，也支持我完成参与的每一个项目。在过去 12 周里，我接触了各种领域、团队和问题空间。无论挑战多么不同，你总能在兼顾自身职责的同时，为我提供指导、背景和支持。我由衷感谢你在整个实习期间给予我的信任。

感谢 Ilay。在我逐渐“ramped”起来的过程中，你一直是我的导师。经历集成工作的种种起伏时，你在如何构建 Ramp 的生产级功能方面，是一位出色的老师。

感谢负责采购业务的 Kevin，感谢你愿意给我机会，也感谢你始终如此平易近人、谦逊友善。神奇的是，你总能准确知道我正在做什么、遇到了什么障碍，也总能在我尚未开口时给出恰到好处的建议。

感谢团队里的另一位实习生 Daniel。你每天都把标准提得更高，也不断推动我做得更好。

最后，特别感谢采购团队，感谢 Vincent、Helen、Yev，以及我一路结识的所有朋友 :)