How Coinbase Wallet built an agent-first product development lifecycle

Coinbase Wallet 如何构建以代理为中心的产品开发生命周期 - Arize AI

对于大多数工程团队而言，AI 的采用通常始于 IDE 或 CLI 中。Coinbase Wallet 却选择了一个更具颠覆性的实验。它暂停了将近三周的发布，并要求工程师删除自己的 IDE。

这次暂停旨在强制实施以代理为中心的重置。Coinbase Wallet 产品工程负责人 Chintan Turakhia 在 Arize Observe 2026 上阐述了这项实验。他认为最具挑战的部分是文化层面的。编码代理已经具备生成有意义软件的能力，但团队仍需要替换围绕代码生产成本高昂所构建的流程、基础设施和习惯。

据 Chintan 表示，实验结果非常显著。过去需要 20 到 25 天才能完成的简单移动应用 bug 修复和功能开发，现在仅需约 1.8 天；Slack 中的请求可以在 12 分钟内生成 Pull Request 并完成可测试的构建；原本需要三天的安全审查现在可在五分钟内完成。

然而，最有价值的教训来自后续出现的瓶颈。当代码生成加速后，Pull Request 审查、CI、构建基础设施、验证，最终产品决策成为了新的制约因素。

如何衡量从意图到生产的时间

Chintan 的核心指标是 从意图到生产的时间。

意图始于某人发现 bug、提出功能建议或形成产品假设。当用户能够体验到结果时，计时停止。

这个指标防止团队只庆祝局部优化。即使生成了更多代码、Pull Request 或代理运行，如果变更仍需数天等待构建、审查、测试环境和审批，这些数字本身意义不大。

采用编码代理的团队应测量以下指标：

• 从想法到可执行原型的时间
• 从原型到验证构建的时间
• 等待 CI、基础设施、安全或人工审查所花费的时间
• 实施过程中需要人工干预的频率

在 Coinbase，更快的代码生成立即将压力转移至下游环节。原本需要 30 到 40 分钟的构建被转移到缓存云环境，时间缩短至不到一分钟。当这个瓶颈改善后，团队得以更专注于验证。如今，Chintan 表示，限制因素越来越集中在输入端：决定要构建什么，以及为什么它重要。

Coinbase 产品开发的 AI 代理框架内部解析

为每位工程师配备 AI 编码助手只是第一步。Coinbase Wallet 构建了一个内部代理框架，能够跨规划、实现、审查、测试和发布阶段执行工作。

| 工作流 | 开发循环中的角色 | 人类审查内容 | |--------|------------------|--------------| | Forge | 将 Slack 请求转换为代码、Pull Request 和可测试的移动构建 | 正在运行的产品 | | Sail | 检查安全问题并分配风险等级 | 风险热点和高影响变更 | | Tracer Bullet | 将规范通过实现、模拟器测试、验证和内部发布 | 结果是否符合原始意图 |

这些系统共同构建了一个端到端的反馈循环。代理可以收集上下文、制定计划、跨多个仓库协作、创建拉取请求、启动移动模拟器、将产生的行为与规范进行对比，并将证据返回到Slack。工程师无需从代码差异开始，而是可以从可运行的构建、风险评估、日志以及变更前后的录制视频开始。

尽管如此，对于影响重大的变更，人工审核仍然是核心环节。Coinbase运营在受监管的环境中，任何涉及资金流动的变更仍需经过全面的人工测试和审批。低风险变更可以通过代理审核委员会处理，而工程师则将注意力集中在那些失败影响最大的关键环节。

如何为AI编码代理规划工作

Coinbase Wallet工作流的核心原则很简单：制定计划，而非发出指令。指令要求代理执行任务，而计划则定义了预期结果、约束条件、实现上下文以及证明工作完成所需的证据。

Chintan将计划描述为一份契约。当实现失败时，工程师被鼓励更新这份契约并重新运行工作流，而不是打开IDE手动修补代码。修复计划可以保留学习成果供未来的代理运行使用。

一份有效的实现计划应包含：

• 预期的用户结果。
• 需要变更的当前行为。
• 涉及的仓库、服务或接口。
• 明确的验收标准。
• 已知的边界情况和风险区域。
• 代理必须返回的测试结果、日志、截图或录制视频。

花20分钟明确这些细节，可以避免引导代理处理模糊需求所耗费的数小时时间。它还能创建一个可重复使用的工件，多个代理可以并行执行该工件。

为什么AI编码代理需要上下文、可观测性和快速CI/CD

“让代理自行处理”只有在代理能够观察自身行为时才有效。代理需要访问开发者使用的相同操作证据：应用程序日志、构建输出、测试结果、运行时行为、设计系统组件和生产约束。缺少这些输入，生成的代码将只是一个未经验证的假设。

Coinbase的验证工作流会在不同设备配置上启动大量移动模拟器。代理运行实现、捕获变更前后视频、将行为与原始规范进行对比，并报告哪些用例通过或失败。

当验证失败时，团队会更新规范并重新运行循环。这与评估驱动开发的模式一致：先指定结果，再评估结果，最后修改规范而非手动修补。

这将可观测性和评估直接纳入开发流程本身。代理编写实现、观察其行为、评估结果，并返回人类可以评估的证据。生产团队通常会将这些证据作为追踪记录和评估结果存储在Arize AX中。Chintan表示，构建和验证环境的改进使拉取请求在无需人工实现工作的情况下合并量增加了73%。

以代理为中心的开发模式也迫使Coinbase重新审视软件交付的各个环节。团队取消了冲刺会议、每日站会、项目启动会、传统PRD文档和Figma交接等强制性环节。现在的工作流程从一个想法或规格说明开始，快速进入可运行的原型阶段，并尽可能早地交付给内部用户。

团队内部会试用数百个原型，但只有能证明价值的创意才能获得生产所需的额外工程和设计资源。照搬这一流程会忽略更核心的启示。每个团队都应审查现有工作流程，识别代理机制制造的瓶颈。

针对每个会议、文档、审批或交接环节，请问自己以下问题：

• 这一步是否明确了产品意图？
• 是否为代理提供了必要背景？
• 是否提升了验证效果或降低了实质性风险？
• 是否帮助用户更早评估可运行的软件？

无法满足这些条件的流程可能在维护一个已经不存在的约束。

进行一日版路线图压缩测试

Chintan给工程团队的建议是：从路线图中最雄心勃勃的项目入手，尝试在一天内完成开发。这个练习旨在暴露限制因素，即使最终成果从未进入生产环境。

以下是可遵循的简单流程：

• 选择一个有明确边界但具有挑战性的产品目标
• 撰写包含验收标准和验证要求的详细计划
• 通过代理执行计划，不手动修改生成的代码
• 要求生成可运行的构建版本，并证明其行为符合预期
• 记录所有导致流程变慢或失败的环节

在测试结束时对瓶颈进行分类。可能是代理缺乏背景信息，CI系统过于缓慢，评估标准不够明确，测试环境无法访问，或产品构想本身描述不足。

Coinbase曾进行更极端的测试，要求两名工程师在一周内重建其应用程序。他们完成了约85%的开发，但最后15%的缺失使应用无法投入生产。可靠性、安全性、验证机制和产品判断力仍然决定着工作是否具备上线条件。

以代理为中心的工程方法压缩了实现阶段，使人类能将更多注意力集中在关键决策上。这样，规划本身成为主要工作。有时，最宝贵的起点恰恰是删除那些不再服务于工作闭环的流程。