TransCrab
← 返回

别再只谈 Harness 了，你的组织需要自己的编码 Agent

2026-03-04 · 原文链接

像 Stripe、Ramp、Coinbase 这样的顶级工程组织，正在构建自己的内部编码 agent。这些 agent 以 Slack 机器人、CLI、Web 应用和 Chrome 扩展的形态运行，在工程师原本就在工作的地方提供能力。

它们连接了内部系统，具备正确的上下文、权限控制和安全边界，能够在几乎不需要或完全不需要人工审批的情况下运行。

而且因为它们太有用了，它们正在从工程团队向外扩散：产品经理、GTM 以及其他非技术成员在 Slack 里看到成效后，也开始用起来。

背景：最强的工程组织已经是 AI-native 了。这不是“即将到来”，而是“已经发生”：

  1. Stripe 运行着数亿行 Ruby 代码并使用 Sorbet 类型系统——这是大多数 LLM 都很吃力的技术栈——同时每年处理超过一万亿美元支付。他们的 agent 现在每周产出超过 1,300 个已合并 PR。
  2. Ramp 需要能在前后端都验证自身工作的 agent，并且要具备完整的工程师级上下文。他们在内部构建了一个跨客户端的 agent 平台，覆盖 Slack、Web 和 Chrome 扩展。
  3. Coinbase 面临金融与加密安全要求，完全禁止使用第三方后台 agent。他们把 PR 周期时间从 150 小时压缩到 15 小时，并正在瞄准 5 分钟。 而且正如 @rywalker 对自建编码 agent 的调研所显示的那样，他们绝非个例——这正在成为整个行业的模式。

接下来是一份实用指南：如果你要走这条路，会遇到哪些关键决策。我们会展示 Stripe、Ramp、Coinbase 分别如何做，以及你能从中学到什么。

来源：本文基于 Stripe 在 stripe.dev 的两篇 Minions 博客、Ramp 的《Why We Built Our Background Agent》、Chintan Turakhia 在 How I AI 播客中的分享，以及对开源 agent harness 实现的原创对比研究。

1. Agent Harness

第一个决策是：你的 agent 跑在什么 harness 上。

Stripe 选择了 fork。他们基于 Block 的开源 goose 编码 agent 做定制，加入了带明确观点的编排层，把 agent loop 与 git 操作、linter、测试等确定性代码交错执行。Fork 让他们在核心 agent loop 上快速起步，同时能够严格控制这个 loop 如何与 Stripe 基础设施交互。

Ramp 选择了组合（compose）。他们基于 OpenCode 作为底层 agent，看中的是它 server-first 的架构和类型化 SDK。一个很实际的好处是：agent 能读取自己的源代码，从而更理解自己的能力。基于现有 agent 组合构建让你有升级路径——可以吸收上游改进——但也会把你绑定到该项目的架构决策上。

Coinbase 从零构建。他们的 Cloudbot 完全内建，且是 multi-model——不锁定单一提供商。处理加密资产的金融平台所需的安全要求驱动了这个决策。从零构建给你完全控制权，但实现成本最高。

权衡很直接。Fork 给你速度，但会被上游你未必认同的决策牵制。Compose 给你升级路径，但会把你耦合到框架的“重力中心”。Build 给你完全控制，但每个 bug 都归你自己背。

2. Sandbox：Agent 在哪里运行代码

你可以让工程师在本地跑 agent，但一旦 agent 开始自主写代码并执行代码，不受控的本地执行会很快变得危险。三家公司最终都收敛到云端 sandbox：要么短生命周期 VM，要么容器。Sandbox 是你安全模型的一部分。Agent 的执行环境是你会做出的最关键决策之一。

Stripe：把云 VM 当“牛群”管理（Cattle）

Stripe 在 devbox 上运行 agent——也就是 AWS EC2 实例，作为标准化的云开发环境。它们被当成 cattle 而不是 pets：可轻松替换，从预热池中快速拉起，10 秒即可就绪。

每个 devbox 都预装了工程师（或 agent）所需的一切：

Stripe 的洞察是：对人类安全的开发环境，对 agent 同样有效。你不需要发明全新的安全原语——你需要把现有原语做得足够快，让 agent 能用。

Ramp：带预热的容器平台

Ramp 使用 Modal 作为隔离开发环境。预构建镜像与快照将仓库保持在 30 分钟内的“新鲜窗口”——对大多数工作足够新，也足够快，支持按需启动。

Ramp 把速度优化到极致。用户还在输入 prompt 时，他们就开始预热 sandbox。用户一按回车，sandbox 就绪。他们还会在同步完全结束前先做早期文件读取，并把仓库级构建步骤批处理以降低启动延迟。Agent 还能启动子会话并行工作——一种 sandbox-within-a-sandbox 模型，让一个 agent 扇出处理多个任务。

结果是：“Inspect 会话启动很快、运行几乎免费……并发会话数量没有上限，且完全不需要你的笔记本参与。”灵感一来，他们随时都能启动会话。

Coinbase：安全驱动的内部实现

Coinbase 内建了自己的 sandbox，核心驱动力是处理金融与加密基础设施所需的安全要求。具体细节未公开，但动机很清楚：当你是受监管的金融机构，sandbox 不只是开发便利，而是合规边界。

共同模式

三家都收敛到同一原则：先隔离，再在边界内给完整权限。Sandbox 正是无人值守 agent 执行得以安全的基础。如果你试图靠权限弹窗和审批闸门来保证安全，而不是靠隔离，你最终会得到一个“要么慢到没用、要么宽到不安全”的 agent。

3. 工具与上下文：Agent 能看到什么、能做什么

LLM 能处理多少工具、该给多少上下文，这件事“艺术大于科学”。三家公司各有做法：

工具基础设施

三家公司都通过结构化接口给 agent 接入内部工具，但规模差异很大。

Stripe 做了一个内部 MCP 服务器 Toolshed，托管近 500 个工具，覆盖内部系统和 SaaS 平台。但关键设计决策不在“工具数量”，而在“工具编排”。Agent 默认只拿到有意缩小的一组工具，而不是 500 个全开。每个 agent 实例获得一个经过策展的工具集，支持按用户自定义和按主题分组。安全控制会阻止破坏性操作。

洞察是：工具编排比工具数量更重要。给 agent 500 个工具不会让它更强，只会让它更困惑，并在选工具上浪费 token。按 agent 类型约束工具集，结果反而更好。

Coinbase 在工具广度上走了另一条路。Cloudbot 连接 Datadog、Sentry、Amplitude、内部 Snowflake 数据库等 MCP，再叠加自定义 Skills。它还能跨多个代码库工作。重点不在统一工具平台，而在连接对调试和实现最关键的观测与数据源。

Ramp 则在 OpenCode 的 SDK 层 built-in 工具系统之上扩展，接入了他们自己的集成能力。

上下文工程

真正的精细化能力在这里。把恰到好处的信息放进 agent 上下文——不多不少——决定了 agent 产出的是可用 PR 还是幻觉。

Stripe 的规则文件采用 Cursor 格式，支持目录与模式作用域。随着 agent 在文件系统中遍历，规则会自动附着，并在 Minions、Cursor、Claude Code 三个平台同步。这意味着能帮助人类工程师的同一套组织知识，也能帮助无人值守 agent。几乎所有规则都基于子目录条件应用——对一个数亿行代码、不同区域约定截然不同的代码库，这是必须的。

Stripe 还做了上下文预注水（pre-hydration）：Minion 运行前，编排器会扫描 Slack 线程里的链接，确定性拉取 Jira 工单、文档和 Sourcegraph 代码搜索结果，并对看起来相关的链接运行 MCP 工具。Agent 开始工作时拿到的是一份预组装的丰富上下文，而不是靠工具调用从零摸索。

Coinbase 把 Linear 作为单一上下文入口。所有上下文先沉淀到 Linear 工单——结构化 bug 报告、相关用户路径、附件文件。然后 Cloudbot 从 Linear 拉取，再扇出到 MCP 获取额外上下文。这样形成清晰分层：人类把上下文策展进 Linear，agent 从 Linear 加其他来源中消费。

正如 Turakhia 在 How I AI 播客里说的，他意识到上下文是最重要的东西——所以他们先把一切汇入 Linear，再让 Cloudbot 从那里扇出。

4. 编排：Agent 如何思考与行动

第四个决策是：你如何组织 agent 的执行流程——从接收任务到产出 PR 的闭环。

Stripe 的 Blueprints

这是 Stripe 最有辨识度的架构贡献。Blueprint 是一种混合模式：把 workflow 的确定性和 agent 的灵活性结合起来，实现为一个在两类节点间交替运行的状态机。

确定性节点永远按同样方式执行：跑 linter、格式化代码、推送 git、执行 pre-push hooks。这些步骤必须发生，而 LLM 恰好最不擅长稳定地记住它们。

Agentic 子任务节点则在边界内给 LLM 创造空间：比如“实现这个工单描述的任务”“修复上一轮的 CI 失败”。LLM 可自由使用工具和推理，但只能在该子任务边界内行动。

Blueprint 的威力在于可组合性。团队可以为专门工作流创建团队定制 blueprint。负责某个服务的团队可以把部署约定、测试要求、代码评审标准编码进 blueprint——之后所有在这段代码上运行的 agent 都会自动遵循这些约定。

核心原则：把 LLM 装进受控盒子里，可靠性会叠加提升。每增加一个确定性节点，就少一件 LLM 会做错的事，从而省 token、省 CI 成本，也让整体流水线更可预测。

Ramp 的 Session 模型

Ramp 的编排以 session 为中心——可长时间运行的 agent 上下文，支持后续 prompt、停止机制和多人协作。

Session 模型引入了 Stripe 的一次性 agent 不需要面对的决策：用户发 follow-up prompt 时，你是排队处理还是立即执行？Ramp 两种都支持。他们还支持子 session：agent 可以启动子 agent 并行工作，同时保持父上下文。

Ramp 把多人协作定义为关键能力。多个团队成员可在同一 agent session 协作，并追踪个人作者信息。典型场景包括教学流程（资深工程师带初级工程师走一遍 agent 协作任务）和 QA 流程（评审者加入进行中的 session 检查 agent 工作进度）。

Coinbase 的三模式模型

Cloudbot 提供三种明确模式，各自针对不同交互：

  1. Create PR：接收 Linear 工单，生成完整 PR 与代码改动。
  2. Plan：类似 Cursor 的计划模式——先生成实现计划并回写到 Linear 工单，供人审阅后再写代码。
  3. Explain：调试模式——回答“为什么不工作”，并从 MCP（Datadog、Sentry 等）拉上下文进行诊断。 PR 完成后，Cloudbot 会在 Slack 回复 Cursor 分支深链（deep link），再附一个二维码，让工程师手机一扫就能立刻测试移动端构建。这个“闭环输出”设计——从 Slack 调用到手机测试一条流打通——体现了 Coinbase 压缩整条反馈周期的关注点。

5. 测试与验证：Agent 如何证明自己做对了

第五个决策是如何验证 agent 产物。三家公司在这里的理念差异最大，形成了从保守到激进的光谱。

Stripe：左移验证，最多两次 CI

Stripe 的测试策略有三层：

  1. 本地：自动 lint 启发式检查通过 pre-push hooks 在每次 git push 后 5 秒内完成，且利用缓存结果。这会在进入 CI 前拦住琐碎问题。
  2. CI：从总量超过 300 万测试中做选择性执行。很多 CI 失败带有 autofix，可自动应用，无需人工干预。
  3. Agent 重试：若 CI 失败且无 autofix，agent 只允许再尝试一次。 第二次 CI 后若仍失败，就交给人工评审。没有第三次，不做无限重试。理念很明确：避免在边际收益递减时继续让 LLM 迭代。每多一次重试都在烧 token 和 CI 容量，成功概率却下降。此时交给人，比让 agent 空转更划算。

Ramp：可视化验证

Ramp 在验证上的独特贡献是通过 Chrome 扩展做可视化验证。它具备 React 感知能力，并基于 DOM 树而非截图运行——相比像素层对比，更可靠地识别真实 UI 状态。流式桌面视图让 agent 和人工评审都能看到前端实时渲染结果。

这很关键，因为很多 agent 生成代码虽然能过 CI，但 UI 实际是坏的。单元测试抓不到“modal 被渲染到遮罩层后面”或“按钮颜色对了但位置错了”这类问题。基于 DOM 的验证可以。

Coinbase：Agent Councils 与 Auto-Merge

在判断 PR 风险较低时，Coinbase 三家里最激进。他们的方法演进非常快。

起点：PR 平均周期约 150 小时，大部分耗在评审队列。他们构建内部评审工具，并按风险自动合并——低风险改动（文案、小 bug）自动 merge，高风险改动进入评审。

现状：PR 周期降到约 15 小时。他们使用 Greptile 自动代码审查，并引入 agent councils——由多个 AI agent 组成的首轮 code review 机制。根据 Chintan Turakhia 的说法，这些 agent councils 的评审质量“比人类好 95%+”。

目标：从 15 小时继续压到 5 分钟。他们正在重新思考评审在开发周期中的位置——当 agent 能在“创建时”就完成验证，传统 PR review 模式是否仍有意义。

光谱

三种做法形成清晰光谱：

6. 调用入口：工程师如何使用 Agent

第六个决策是接口。工程师到底如何和 agent 对话？

Slack 是通用层

三家公司都收敛到 Slack 作为主要调用入口。这不是巧合。

Stripe 最常通过 Slack 调用 agent，同时也支持 CLI、Web 界面，以及嵌入内部系统（文档平台、feature flag UI、工单系统）的按钮。Ramp 提供 Slack，并配套精细打磨的 Web 界面（含托管 VS Code）和 Chrome 扩展。Coinbase 的 Cloudbot 是 Slack-native——驻留在 Slack 频道，通过 cloudbot 调用。

Chintan Turakhia 对“为什么 Slack 会赢”给出了最清晰的解释：在 Slack 里“写一句话”的成本为零，但“回复一句话”的成本极高。Slack 里大量流转内容，本质是人类在扮演系统：回答本可自动化的问题、分流本可自动路由的请求、整理本可自动拼装的上下文。把 agent 放进 Slack 后，这个结构被反转：回答的成本也降为零。

还有第二个原因，关乎采用扩散：Slack 是公司内部“病毒传播”的渠道。若你把 agent 藏在独立工具、新 URL、新登录后面，它就扩不起来。当 agent 结果出现在大家本就在看的频道里，人们无需显式“加入试用”，就能看到可能性。

超越 Slack

真正有意思的分歧在于三家在 Slack 之外做了什么。

Stripe 直接把调用按钮嵌进内部平台。文档平台、feature flag UI、工单系统都有内建 “run a minion” 按钮。这是 Slack-first 的自然终局：一旦 agent 证明有价值，就把调用点前移到“需求发生处”，而不是让人切到 Slack。

Ramp 构建了三种差异化客户端表面，各自优化不同流程。Web 界面包含托管 VS Code 集成和组织级分析看板。Chrome 扩展基于 DOM 树做可视化验证。Slack 界面处理聊天式交互，带自动仓库分类和基于 Block Kit 的状态更新。这也让非技术成员能在自己工作的地方（如浏览器）采用 Inspect。

Coinbase 保持 Slack 为中心，但在输出层做了巧思：Cloudbot 完成 PR 后，会同时给出 Cursor 深链（可直接跳入编辑器分支）和二维码（手机扫码立即测移动端 build）。细节虽小，却把“调用→验证”闭环压成单条流。

7. 采用：让它真正落地

把 agent 做出来是一回事，让上千工程师真正用起来是另一回事。

这三家公司都没有强推采用——都是让产品自然扩散，但机制各不相同。

Ramp：让产品自己说话

Ramp 的做法很明确：“我们没有强迫任何人用 Inspect 替代自己的工具。我们围绕真实需求构建，通过让它在公共空间工作形成传播回路，让产品自己说话。”几个月内，他们前后端仓库中约 30% 的已合并 PR 由 Inspect 编写，且使用率持续增长。他们追踪一个实时指标“humans prompting”（过去 5 分钟内发过 prompt 的用户数）作为采用脉搏。Ramp 也在向工程外扩展，教产品经理、设计师等非工程构建者用 agent 完成自己的工作。

Stripe：做到“避无可避”

Stripe 没有单独的采用手册——他们让你无法绕开 agent。调用入口无处不在：文档平台、feature flag UI、工单系统都内建“run a minion”按钮。规则文件在 Minions、Cursor、Claude Code 同步，组织知识无论你用什么工具都一致。他们还为非工程团队做了无代码内部 agent builder，把 agent 使用扩到工程组织之外。结果是：每周超过 1,300 个完全由 agent 产出的 PR 被合并，公司内部运行着数百种不同 agent。

Coinbase：规模化社会证明

Coinbase 通过社会证明和集体活动在 1,000+ 工程师组织中推动采用。他们建了一个 Slack 频道“Cursor Wins and Losses”——“losses”这部分让它变成自强化学习回路：失败被公开修复。他们还办了 PR speedrun：限时活动里每个人选一个小任务并发 PR。第一次 15 分钟产出 70 个 PR；随后全公司 800 人参与，30 分钟产出 300-400 个 PR。他们还发明了专门的“Super Builder”角色——全职职责就是让其他所有人借助 agent 变得更快。

共同模式

三家都收敛到同一条经验：别强制，要示范。把 agent 放在人们本来就工作的地方（Slack、内部工具），让结果可见，然后让采用自己复利。

结论：决策矩阵

三家公司在各项决策上的对比如下。

如果你今天开始

  1. 谨慎选择你的 agent harness。结合你的需求，选最适合组织的路径。
  2. 构建一个“允许 agent 犯错但不会造成后果”的环境。这是最大的解锁点。Stripe 的 devbox 没有生产访问、没有真实用户数据、没有网络出口，所以 agent 能以完整权限运行且零确认弹窗。尽早投资隔离和预热；sandbox 启动时间就是 agent 延迟。
  3. 策展工具，不要囤积工具。工具越多，困惑越多。给每类 agent 一套小而专注的工具集。
  4. 在验证光谱上选好位置。明确代码库和 PR 的高低风险区间，然后按风险设计评审。不要害怕自动合并安全改动，也要对高风险改动设闸。
  5. 让 agent 在公共空间工作。别强推使用，让 agent 的结果出现在 Slack 频道和共享空间里，让人们无需“主动加入”也能看到可能性。可见性会带来采用。 来源：