Codex Mobile power user guide: Your phone is a control plane for work running on your Mac / Windows machine / devbox The best workflows: > start threads on the right host workspace > pick branch worktree from mobile run local environment setup before the task starts > use /side for questions without derailing the main thread > use /plan when the change is risky or more involved > use /goal when the outcome needs multiple iterations > attach screenshots / files / photos / voice prompts directly from your phone review diffs, inspect files, leave inline comments > queue or steer follow-ups while away from desk Mental model: - main thread = the work
- side chat = reasoning around the work
- plan = implementation path
- goal = durable end state Essentially, mobile makes Codex useful in all the in-between moments See a bug on your phone → screenshot → send to Codex → review diff → leave comments → keep moving goated guide from @Dimillian 🔥

Reproducing a teammate's dev environment is still a 2 day yak shave. Devbox turns it into a single devbox.json file: - 400k packages from the Nix registry, no Docker overhead - Isolated shells, per project, no global pollution - Same tool versions for every contributor, every machine The dev environment you can actually commit. github.com/jetify-com/devbox

OpenAI Codex Mobile 工程实践指南 @Dimillian 提出了 Codex Mobile 核心心智模型： 手机不只是缩小版终端，它是远程开发机的「控制中心」。 · 代码执行、任务运行仍在 Mac / Windows / devbox 等已连接主机上完成 · 手机提供原生 UI，用于启动、引导、审查、组织工程工作 · 价值不在「在手机上写代码」，而在「离桌时仍能做出关键决策」 # 任务启动：先定边界，再发 prompt 好 agent 工作的前提是正确隔离的执行环境。Codex Mobile 在创建新 thread 时可配置： · 选择主机与工作区：指定在哪台机器、哪个项目跑 · 选择 Git 分支：从正确基线出发，避免事后修 Git 状态 · 创建独立 worktree：隔离变更，不污染当前 checkout · 运行 environment setup 脚本：worktree 创建后自动执行桌面端配置的初始化脚本 三种典型模式： 1. 用当前 checkout → 快速调查 2. 新建 worktree → 需要隔离的改动 3. 从目标 base branch 起步 → 避免后续 merge 混乱 限制：environment 脚本目前不能在 Mobile 上编辑，需在 Desktop 配置。 # Side Chat：主线程做活，旁路线程理解 长线程会积累大量上下文；每个旁路问题都打断主线程，会让 transcript 变噪、agent 偏离目标。 Side chat 的定位：与当前 thread 关联的轻量对话，不抢占主工作流。 · /side 或 /side <prompt> 打开 · 选中 transcript 文本 → Ask in side chat，选中内容成为起始上下文 适合的问题类型： · 为什么选这种架构？ · 这个 error 实际含义？ · 与 desktop 行为是否一致？ · 生成 release note 版说明 · 批准这条命令前应验证什么？ 分工： 主 thread 负责执行；side chat 负责理解与决策辅助。 # Plan 与 Goal：路径 vs 结果 两者解决不同问题： · Plan mode：「怎么实现？」，任务欠规格、风险高、跨多系统 · Goal：「完成标准是什么？」，需多轮迭代的 durable 目标 推荐工作流： 1. 高风险任务 → 先 Plan，审查边界 2. 方案确认后 → 转为 Goal，让 agent 跨实现、测试、review、清理持续推进 3. 实操中常跳过显式 Plan：先与 Codex 讨论细节，满意后让 Codex 自己写 Goal（通常比人工写更好） Goal 写法注意： 设定可验证、不过宽的终态。过于绝对的要求（如「100% 像 X 或 Y」）容易导致过度执行、浪费 token。Mobile 端现已可监控 token 消耗，但仍应控制 Goal 粒度。 Mobile 对 /goal、/plan 支持完整：可见运行时长、编辑、暂停；Plan 工具的问题也会在 UI 中展示。 # Mobile 独有优势：别忘记「你在用手机」 Composer 内置访问本地手机数据的能力，这是桌面端没有的： · 拍照 / 选图 / 浏览文件 · 语音录制 prompt（后台持续录音：切到其他 app 时 dictation 不中断） 典型场景（作者做 ChatGPT iOS 的经验）： · 发现问题 → 直接截图发给 Codex thread → 快速修复，无需回电脑 · 同 Wi-Fi 下 → 在真机构建运行，直接验证 Codex 改动结果 · 边用 app 边口述 10 分钟问题 → 回 Codex 发送，形成「Talk to phone → app appears」闭环 Pinned 长线程： 例如绑定 Linear tracker 的 thread，随手粘贴文本即可按当前上下文正确建 issue、打标签。 # Mobile 代码审查：不必等回工位 Completed turn 可展示变更文件摘要，支持： · 打开 diff、展开/折叠、换行 · 查看带语法高亮的源文件 · 行内评论 → 自动汇入 composer，发回 Codex 分层用法： 1. 变更摘要 → 快速 sanity check 2. 完整 diff / 源文件 → 缺上下文时深入 3. Inline comment → 精确修正 4. review 命令 → 审查本地变更或与分支对比 5. 链接文件回 chat → 让 Codex 针对特定文件推理 关键洞察： 手机不能替代大屏做深度 code reading，但很多 review 卡在一两个决策点——这些决策不必等到回 desk。

It’s annoying how when accessing my Mac mini devbox from my iPhone or MacBook, it’ll often not be able to use thread controls. Randomly stops working until I retouch via sending a Codex command directly from the mini.

聞き流しちゃってたから DevBox の waitlist に入ってみた、これであたしも Satya と同じ列にうふふ #azurewaigaya Surface RTX Spark Dev Box: The new dev box | Microsoft Surface Microsoft.com/DevBox

エンジニアのための Codex Mobile 活用術 スマホを「Codexのコントロールセンター」にする方法 Codex Mobileを初めて見ると、「スマホからCodexの作業状況を確認するためのアプリ」のように見えるかもしれません。 もちろん、それだけでも便利です。外出中に進捗を見たり、完了したタスクを確認したりできるからです。 しかし、Codex Mobileの本当の価値はそこではありません。 重要なのは、スマホを小さなターミナルのように無理やり使うのではなく、開発マシン上で動いているCodexの作業を、スマホから開始し、指示し、レビューし、整理できることです。 つまり、スマホが開発作業そのものをする場所になるのではなく、開発作業を動かすためのコントロールセンターになるのです。 ここ1か月ほどで、この一連の開発ループにはかなり多くの機能が追加されました。worktree、goal、side chat、インラインコードレビュー、キューに入れたプロンプト、途中で方向修正するためのプロンプト、添付ファイル、skillsやplugins、アーカイブされたスレッドなどです。 細かい改善も多く、Codex Mobileは単なる補助ツールではなく、本格的な開発作業に使えるものになってきています。 この記事は、これからCodex Mobileを本格的に使いたい人に向けた実践ガイドです。OpenAIでの2か月間で集めたメモやコツ、そして私自身がCodex、特にCodex Mobileをどう使っているかをまとめています。 正しい考え方：スマホはコントロールセンターである まず大事なのは、考え方です。 タスクやcodex run、実際のコードは、これまで通り適切な場所で動きます。Mac、Windowsマシン、devbox、あるいはその他の接続された開発ホストです。 Codex Mobileは、その作業をスマホから操作するためのネイティブなインターフェースです。 スマホ自体を開発マシンにしようとする必要はありません。スマホは、開発マシンで動いている作業に対して、指示を出し、確認し、判断するための場所です。 Codex DesktopアプリやCodex CLIを実行できるmacOSまたはWindowsマシンであれば、ホストとしてセットアップできます。詳しい接続方法は、CodexのRemote Connectionsドキュメントで確認できます。 最初に作業の境界を正しく決める よいエージェント作業は、正しく範囲設定された環境から始まります。 Codex Mobileでは、最初のプロンプトを送る前に、接続先のホストとワークスペースを選べます。新しいスレッドを作るときには、ブランチを選んだり、別のworktreeを作成したり、そのworktreeに紐づいた環境セットアップを実行したりできます。 これにより、スマホからでも次のような使い方ができます。 現在のチェックアウトを使って、すばやく調査する。 既存の作業に影響を与えたくない変更は、新しいworktreeで分離して試す。 あとからGitの状態を直すのではなく、最初から意図したベースブランチを選んで作業を始める。 Codexにビルドやテストを頼む前に、環境セットアップを走らせる。 最新バージョンでは、デスクトップ版Codexアプリで設定している環境スクリプトを、モバイルからも利用できます。worktreeを作成すると、その環境が表示され、worktree作成後にセットアップスクリプトが実行されます。 この「Environments」はCodex Desktopアプリの強力な機能です。依存関係のインストールやビルド準備などを、作業開始時に自動化できます。 ただし、現時点ではCodex Mobileからそのスクリプト自体を編集することはできません。 side chatを「思考の分岐」として使う 長く続くコーディングスレッドには、多くの文脈が蓄積されます。 しかし、その本筋のスレッドに細かな質問を何度も割り込ませると、メインの会話が散らかります。場合によっては、Codexが本来の目的から外れてしまうこともあります。 そこで役立つのがside chatです。 /side を使うと、現在のスレッドにつながった軽量な会話を開けます。/side <prompt> と入力すれば、最初の質問を入れた状態でside chatを始められます。 さらに便利なのは、会話中のテキストを選択して「Ask in side chat」を選べることです。選択した部分が、新しいside chatの開始コンテキストになります。 私はside chatを、たとえば次のような質問に使っています。 なぜCodexはこのアーキテクチャを選んだのか。 このエラーは実際には何を意味しているのか。 この挙動はデスクトップアプリと一致しているのか。 この実装内容をリリースノート風に説明するとどうなるか。 このコマンドを承認する前に、何を確認すべきか。 この区別はかなり重要です。 メインスレッドは作業を進める場所です。 side chatは、その作業を理解するための場所です。 side chatはデスクトップ版とモバイル版の両方で動作します。UXについては、実際の使われ方を見ながら現在も改善が続いています。 Planは道筋、Goalは到達点 Codex Mobileは、/goal と /plan にも対応しています。 モバイルアプリ上でPlanツールの質問が表示され、/goal のUIでは、goalがどれくらい実行されているかを確認したり、編集したり、一時停止したりできます。 Plan modeとgoalは、似ているようで解決する問題が違います。 Plan modeは、コードを変更する前に、Codexに実装方針を提案させるためのものです。タスクが曖昧なとき、リスクがあるとき、複数のシステムに影響しそうなときに役立ちます。 一方でgoalは、より継続的なものです。Codexに対して、複数ターンにわたって追い続けるべき成果を伝えます。モバイルでは/goalを使ってその目的を作成・管理でき、作業が続いている間も進捗を確認できます。 実践的には、次の流れが使いやすいです。 リスクのある変更は、まずPlan modeで始める。 提案された作業範囲を確認する。 その内容に納得したら、複数回のやり取りが必要な作業をgoalにする。 あとは、実装、テスト、レビュー対応、仕上げまで、毎回目的を言い直さなくてもCodexに進めてもらう。 ただ正直なところ、多くの場合は、最初から明示的にPlan modeを使わなくてもよいことが多いです。 まずCodexと問題についてしばらく会話し、実装方針に納得できたところで、「これをgoalにして」と頼めば十分です。 Codexは、人間よりうまくgoalを書けることがよくあります。なので、goalの文章はCodexに作らせるのも良い方法です。 Planは「どう進めるべきか」に答えます。 Goalは「何が達成されたら完了なのか」に答えます。 goalを使うときに大事なのは、検証可能な完了状態を設定することです。そして、広げすぎないことです。 たとえば「XやYと100%同じように作って」といった目標を与えると、Codexは必要以上に広く作業しようとして、トークンを無駄に使うことがあります。 もっとも、スマホからトークン使用状況を確認できるようになったので、それも以前ほど大きな問題ではないかもしれません。 これはあなたのスマホである 意外と忘れがちですが、Codex Mobileを使っているとき、あなたはスマホを持っています。 そしてCodex Mobileの入力欄には、スマホ内のデータへアクセスするための道具が揃っています。 写真を添付できます。 その場で写真を撮れます。 ファイルを選べます。 音声でプロンプトを録音できます。 こう書くと当たり前に見えるかもしれません。しかし、自分がスマホ上で作業していることを意識すると、かなり強力な使い方が見えてきます。特に、モバイルアプリやWebアプリを開発している場合には有効です。 たとえばChatGPT iOSの開発中に問題を見つけたとします。その場でスクリーンショットを撮り、Codexのタスクに送って「ここを直して」と頼めます。わざわざPCの前に戻る必要はありません。 さらに、自宅で同じWi-Fiにつながっているなら、アプリを自分の端末上でビルドして実行し、Codexスレッドの成果をそのままスマホで確認することもできます。 もうひとつ便利なのが、プロンプトの録音です。Codexアプリで録音を開始し、その後アプリをバックグラウンドにしても録音を続けられます。 たとえば次のような流れです。 Codexアプリを開く。 Dictationを開始する。 作業中のiOSアプリに切り替える。 そのアプリを触りながら、気づいたことを10分ほど話し続ける。 Codexアプリに戻って、その録音内容をメッセージとして送る。 これはかなり自然な開発ループです。 スマホに話しかける。 アプリを操作する。 気づいた問題や改善点をそのままCodexに渡す。 Codexが作業を進める。 また、私はいくつか長期間使い続けているピン留めスレッドも持っています。たとえばLinearのトラッカー用スレッドでは、任意のテキストを送るだけで、現在の文脈に基づいて適切なプロジェクトやラベルを付けてissueを追加できます。 このように、スレッドに文脈を持たせておくと、単なるチャット以上の使い方ができます。 会話から離れずにコードレビューする Codexの作業が完了すると、変更されたファイルの概要が表示されることがあります。 そこからdiffを開き、個別のファイルを確認できます。変更箇所を展開したり折りたたんだり、長い行を折り返したり、構文ハイライト付きでソースファイルを開いたりできます。 さらに、該当する行にインラインコメントを付け、そのレビュー内容をCodexに送り返せます。 つまり、スマホ上の会話から離れずに、コードの確認、指摘、再修正の依頼まで行えるということです。 まとめ Codex Mobileは、スマホで無理に開発作業をするためのものではありません。 本質は、開発マシンで動くCodexの作業を、スマホから操作することにあります。 スマホは小さなターミナルではありません。 スマホは、Codexのコントロールセンターです。 作業を始める。 環境を選ぶ。 ブランチやworktreeを切る。 計画を確認する。 goalを設定する。 side chatで理解を深める。 スクリーンショットや音声を渡す。 diffを確認し、コメントし、再修正を依頼する。 これらをスマホからできるようになると、開発の進め方はかなり変わります。 Codex Mobileの価値は、スマホを開発マシンに変えることではありません。 スマホを、AIが動く開発環境の司令室に変えることです。

# Stripe Minions 第二部分：底层是怎么搭建的 本文是 Stripe 编码 Agent 系列的第二篇。回顾一下第一篇：Minions 是 Stripe 自研的无人值守 Agent 编码流程。**每周有超过 1,300 个 Stripe Pull Request（第一篇发布时还是 1,000）完全由 Minion 生成**，经过人类审查，但不包含任何人类编写的代码。 如果你还没读第一篇，建议先看一下，了解 Minions 的开发者体验。本文深入探讨构建细节，聚焦 Minion 流程中 Stripe 特有的部分。 ### Devbox：热乎的，准备好了 为了在大规模下实现最高效率，无人值守 Agent 编码需要一个可并行、可预测、隔离的云端开发环境。人类应该能够给多个 Agent 分配逻辑上独立的工作。Agent 应该有干净的环境和工作目录：如果 Agent 之间互相干扰对方的改动，就会白白浪费 token 在冲突解决上。完全自主还要求 Agent 在系统层面与特权或敏感机器隔离开，尤其不能使用人类的个人凭据。 要让 Agent 在开发者的笔记本电脑上满足所有这些条件，非常困难。容器化或 git worktree 可以帮上忙，但很难组合使用，而且从根本上说，要构建一个既拥有开发者 shell 的全部能力、又被适当约束的本地 Agent，是极具挑战的。 不过，Stripe 的 Minions 天然具备这些特性，因为它们运行在 Stripe 工程师使用的标准开发环境上：**devbox**。 一个 Stripe devbox 是一台 AWS EC2 实例，包含我们的源代码并运行正在开发中的服务。大多数人类编写的 Stripe 代码，本身就是在通过 SSH 远程连接到 devbox 的 IDE 中产生的。用 DevOps 的话说，devbox 是"牲口，不是宠物"：它们是标准化的、易于替换的，而不是定制的、长期存活的。 许多工程师每个任务用一个 devbox，一个 Stripe 工程师可能同时开着半打。 > 一张工程师活跃 devbox 列表截图，包含 Minion 运行 我们希望启动新 devbox 毫不费力，因此目标是 10 秒内就绪。为了达到这个"热乎且就绪"的标准，我们主动预配和预热一个 devbox 池子，让它们在开发者需要时处于待命状态。这包括克隆巨大的 git 仓库、预热 Bazel 和类型检查缓存、启动在 devbox 上持续运行的代码生成服务等等。10 秒后，devbox 的所有者就拥有了一台检出了 Stripe 所有主仓库最新 master 分支的机器，可以立即打开 REPL、运行测试、修改代码并做类型检查，或者启动一个 Web 服务。 devbox 是为人类工程师的需求而构建的，远在 LLM 编码 Agent 出现之前。事实证明，**并行、可预测、隔离**这些特性也正是 Stripe 工程师高效工作所需要的。对人好的，对 Agent 也好。建立在这个基础设施原语之上，为 LLM Agent 提供了一个天然的归宿，产生了复利式的回报。 ### Agent 本身 与早已服务于人类开发的 devbox 不同，我们的 Agent 框架是专门为 Minions 这个场景定制构建的。 2024 年底，随着编码 Agent 在行业中兴起，我们内部 fork 了 [Block 的 goose](github.com/block/goose)，这是最早被广泛使用的编码 Agent 之一。我们定制它以适配 Stripe 的 LLM 基础设施。随着时间推移，我们把 goose 的功能开发聚焦于 Minions 的需求，而非人类监督工具的需求：后者已经被 Cursor 和 Claude Code 等第三方工具很好地满足了，我们的工程师已经在使用它们。 事实上，**Minions 最独特的特征是没有人监督。** 现成的本地编码 Agent 通常被优化为工程师的搭档，工作时工程师基本上"在旁看着"。但 Minions 是完全无人值守的，因此我们的 Agent 框架不能使用面向人类的功能，比如可打断性或人类触发的命令来启动或引导 Agent 运行。 另一方面，隔离的 devbox 环境意味着 Agent 不需要确认提示；任何 Agent 可能犯的错误，都被限制在一个 devbox 的有限爆炸半径内，因此我们可以安全地以完整权限运行 Agent，跳过确认提示。 我们还可以精确调校优化，完全适配 Stripe 的开发流程。我们基于 Stripe 系统的特性做了许多小的优化。一个更大的优化，事实证明对 Minions 的实现更为根本，是**蓝图（blueprint）** 的概念。 ### 蓝图 编排 LLM 流程最常用的原语是[工作流和 Agent](anthropic.com/engineering/bu…)。工作流是一种通过固定的步骤图来运行的 LLM 系统，图中的每个节点负责整体目标中一个窄范围的部分，预定义的边控制着这些离散节点之间的执行流程。 而 Agent 通常是一种更简单的"循环加工具"的编排模式，LLM 依靠自己的判断反复调用手中的工具，并根据工具调用的结果决定下一步该做什么。 Minions 用我们称之为"蓝图"的原语来编排。**蓝图是在代码中定义的工作流，用来指挥一次 Minion 运行。** 蓝图结合了工作流的确定性和 Agent 在面对未知时的灵活性：一个给定的节点可以运行确定性代码，也可以运行一个专注于特定任务的 Agent 循环。本质上，蓝图就像一组 Agent 技能与确定性代码的交织编排，让每个子任务都能以最合适的方式处理。 比如，在驱动 Minions 的蓝图中，有标签为"实现任务"或"修复 CI 失败"的 Agent 式节点。这些 Agent 节点被给予很大的自由度，可以根据输入自己做决定。然而，蓝图中也有标签为"运行配置的 linter"或"推送更改"的节点，它们是**完全确定性**的：这些节点根本不调用 LLM——它们只是运行代码。 因此，蓝图是一种在 Agent 运行中保证某些子任务被确定性完成的方式。Minion 的蓝图最终看起来像一个状态机，交织着确定性代码节点和自由流动的 Agent 节点。 > 示例蓝图。确定性节点用矩形表示，Agent 子任务用云形表示。 根据我们的经验，**用代码确定性完成那些我们可以预见的小决策**——比如"在运行结束时总是 lint 修改"——在大规模下节省了 token（和 CI 成本），也让 Agent 少了一些出错的机率。总体而言，我们发现"把 LLM 放进围起来的盒子里"，会累积成系统级的可靠性提升。蓝图机制让这些子 Agent 的上下文工程变得容易，无论是约束工具、修改系统提示，还是根据需要简化对话上下文。 各个团队也可以设置针对自己特定需求优化的蓝图。例如，有团队构建了自定义蓝图，用来在代码库中运行棘手的、LLM 辅助的迁移，而这种迁移无法用简单的全确定性 codemod 完成。 ### 上下文收集：规则文件 在像 Stripe 这样的大型代码库中，一个毫无指引的 Agent 可能会在遵循最佳实践或使用正确库方面遇到麻烦，即使有好的 linter 也无济于事。为了解决这个问题，各种 Agent 规则格式——比如 CLAUDE.md 或 AGENTS.md——允许 Agent 在遍历目录结构时自动"了解"代码库。 由于我们仓库的规模，我们对无条件全局规则的使用非常克制，否则 Agent 的整个上下文窗口还没开始就会被规则填满。相反，**我们几乎完全让 Minions 从限定在特定子目录或文件模式下的文件中获取上下文**，这些文件在 Agent 遍历文件系统时自动附加。 从我们的角度看，最好避免规则文件的重复，让我们的 Agent 读取与人类导向的 Agent 相同的上下文。基于此，我们标准化了支持这些功能的主流规则格式——[Cursor 的规则格式](cursor.com/docs/context/rule…)——并修改了我们的框架，使 Minions 既能读取这些规则，也能读取之前的自研格式。 我们现在还将 Cursor 规则同步为 Claude Code 也能读取的格式，这样我们三个最流行的编码 Agent（Minions、Cursor 和 Claude Code）都能从 Stripe 工程师在代码库中搭建的规则文件中受益。 ### 上下文收集：MCP 从文件系统读取对静态上下文收集很有效，但 Agent 经常需要通过联网工具调用动态获取信息。特别是，为了充分充实用户请求，Minions 需要检索内部文档、工单详情、构建状态、代码智能等信息。MCP（Model Context Protocol）发布后迅速成为联网工具调用的行业标准，我们将 Minions 与之集成。 Stripe 已经构建或集成了大量运行在不同框架上的 Agent：无代码内部 Agent 构建器、在专用服务上运行的自定义 Agent、第三方现成 Agent、命令行 Agent 工具和其他编码 Agent，以及 Agent Slack 机器人。所有这些 Agent（不仅仅是 Minions）都需要 MCP 能力，而且常常包含重叠的工具集。 为了支持所有这些，**我们构建了一个中心化内部 MCP 服务器，叫做 Toolshed**，它让 Stripe 工程师可以轻松编写新工具，并使其自动被我们的 Agent 系统发现。我们所有的 Agent 系统都能够将 Toolshed 作为一个共享能力层来使用；向 Toolshed 添加一个工具，就立即赋予了我们整个由数百个不同 Agent 组成的舰队新的能力。 Toolshed 目前包含近 **500 个 MCP 工具**，涵盖内部系统和我们使用的 SaaS 平台。Agent 在被给予一个"更小的盒子"和精心筛选的工具集时表现最佳，因此我们配置不同的 Agent 只请求与它们任务相关的 Toolshed 工具子集。Minions 也不例外，默认只提供一个有意缩小范围的工具子集，但每个用户可自定义，允许工程师为自己的 Minions 配置额外的按主题分组的工具集。 由于 Minions 完全自主运行，可以自由调用其 MCP 工具，我们还有一个内部安全控制框架，确保它们不能使用工具执行破坏性操作。不过，作为第一道防线，我们的 devbox 本身就运行在 QA 环境中，因此 Minions 无法访问真实用户数据、Stripe 的生产服务或任意外部网络。这不是巧合：我们有意构建了隔离的 devbox，让人类有一个可以安全实验的环境。而正如其他很多事情一样，**对人类安全的开发环境，对 Minions 同样有用。** ### ……然后迭代 虽然我们构建 Minions 的目标是一次性完成任务，但给 Agent 提供可以迭代对抗的自动化反馈，是推动进展的关键。Stripe 庞大的既有测试库——超过 300 万个测试——可以提供这种反馈。然而，虽然推送的分支会在 CI 中运行所有相关测试，但我们不想过度依赖 CI 来获取所有代码反馈。 在考虑开发者生产力时，我们尽量遵循"反馈左移"的原则。这个说法意味着，如果我们知道某个自动化检查会在 CI 中失败，最好让它在 IDE 中也被强制执行，并立即呈现给工程师，因为这是向用户提供反馈的最快方式。 例如，我们有 pre-push 钩子来修复最常见的 lint 问题。一个后台守护进程会预计算适用于某次改动的 lint 规则启发式，并缓存运行这些 lint 的结果，因此开发者在推送时通常可以在远少于一秒的时间内获得 lint 修复。 Minions 自然也融入了这个框架，因此它们不必浪费 token 或 CI 时间在与自动格式化工具之类的反复交互上。我们在 Agent 的开发循环蓝图中将一组 linter 作为确定性节点运行，并在推送 Agent 分支之前在本地对该 lint 节点进行循环，这样分支在第一次跑 CI 时就有较大机率通过。 在本地运行所有测试是不可行的，因此我们也在标准 Minion 蓝图中包含了一轮针对完整 CI 套件的迭代。在 Minion 推送更改后，我们运行 CI，并自动应用任何针对失败测试的自动修复。如果有无法自动修复的失败，我们将失败信息返回给蓝图中的 Agent 节点，给 Minion 一次在本地修复失败测试的机会。在第二次推送和 CI 运行之后，我们将分支交还给人类操作员，由人工审查。 为什么只有一到两轮 CI？在速度和完整性之间需要平衡；CI 运行消耗 token、算力和时间，我们认为让 LLM 无限运行多轮完整 CI 循环，边际收益递减。我们认为这个策略在各方考量之间取得了很好的平衡。 ### 总结 Minions 只是 Stripe 使用 AI 加速工程师工作的方式之一，但我们认为它是如何将行业标准概念——如 Agent 框架和 MCP——与我们自己的内部工具和基础设施融合的一个很好的范例。这些工具和基础设施是 Stripe 工程师多年来为最大化开发者生产力而不懈调校的成果。 无论是通过改进文档、开发者环境，还是迭代循环，我们一次又一次地发现，**这些年来在人类开发者生产力上的投入，在 Agent 的世界里产生了复利式的回报。** Minions 已经改变了 Stripe 软件工程的格局。我们持续改进它们，融入行业内最新最好的成果，并适配 Stripe 的规模。结合我们在人类开发者体验的硬仗中获得的口味和专业知识，我们会将 Minions 打造到最好的水平。 有兴趣使用 Minions 或参与 Minions 的开发？[Stripe 正在招聘](stripe.com/jobs)。 --- 原文：stripe.dev/blog/minions-stri… #Stripe #AI编码 #Agent #MCP #软件工程

一篇来自 Stripe 关于 Agent 的经典文章，值得一读再读： # Stripe 的 Minions：一次性端到端编码 Agent 在整个行业中，AI Agent 编码已经从新鲜事物变成了基本要求。随着底层模型的持续进步，无人值守的编码 Agent 已经从可能性变成了现实。 Minions 是 Stripe 自研的编码 Agent。它们完全无人值守，专门为一次性（one-shot）完成任务而构建。**Stripe 每周有超过一千个被合并的 Pull Request 完全由 Minion 生成**，虽然经过人类审查，但不包含任何人类编写的代码。 我们的开发者仍然可以规划和与 Claude、Cursor 等 Agent 协作，但在一个开发者注意力是我们最稀缺资源之一的世界里，无人值守的 Agent 允许任务的并行化。 一个典型的 Minion 运行从 Slack 消息开始，以一个通过 CI 并等待人类审查的 Pull Request 结束，中间没有任何人工交互。我们经常看到工程师同时启动多个 Minion，并行完成多个不同的任务。这在值班轮岗期间尤其有用，可以有效解决许多可能同时出现的小问题。 在这篇博客文章系列的第一部分，我们将展示我们的工程师如何使用 Minions 以及它们能做什么。在第二部分，我们将深入探讨底层的实现以及我们是如何构建它们的。 ### 为什么自己造？ 用 vibe coding 从零构建一个原型，和向 Stripe 的代码库贡献代码，是根本不同的事情。 Stripe 的代码库涵盖数亿行代码，分布在少数几个大型仓库中。我们的大部分后端使用 Ruby（不是 Rails）编写，配合 Sorbet 类型系统，这是一个相对少见的技术栈。在代码中，我们使用了大量 Stripe 独有的自研库，因此 LLM 天生不熟悉。 风险很高：这些代码每年在生产环境中处理超过 1 万亿美元的支付交易。同时，Stripe 与金融机构有着许多复杂的现实依赖关系，以及代码必须遵守的监管和合规义务。 LLM Agent 在从零构建软件时表现出色，此时系统的约束相对较少。然而，在任何像 Stripe 这样规模、复杂度和成熟度的代码库上进行迭代，本质上要困难得多。人类必须建立复杂的心理模型才能在我们的仓库中做出有效的改动，而让 Agent 在其上下文窗口的限制内发展出正确的直觉并使用正确的工具，是极具挑战性的。 多年来，Stripe 在开发者生产力基础上持续投入，支持我们在开发生命周期各个阶段的独特约束：源码控制、环境、代码生成、CI 等等。因此我们定制的 Minion 框架与这些工具紧密集成。Minions 使用的开发者工具，与让 Stripe 人类工程师能够在我们的规模上高效工作的工具完全相同：如果对人好，对 LLM 也好。 ### 使用 Minion 是什么体验？ Minions 有多个不同的入口点，设计上尽可能贴合 Stripes 的工作习惯。虽然我们提供了 CLI 和 Web 界面来启动 Minions，但工程师最常从 Slack 启动。通过在 Slack 中 @我们的 Slack 应用，工程师可以直接从讨论某个改动的对话线程中启动一个 Minion，它能够访问整个线程以及其中包含的任何链接作为上下文。 如果你是一个做内部工具的工程师，你可能会用这样一条消息启动一个 Minion： > 一条调用 Minion 运行的 Slack 消息 Minions 也可以从 Stripe 的其他内部应用中调用。我们的内部文档平台、feature flag 平台和内部工单 UI 都与 Minions 集成。例如，当我们的 CI 系统检测到 flaky test 时，我们会自动创建工单，提示用户用 Minion 修复问题。 > 一张 flaky test 工单截图，附带一个启动 Minion 修复它的按钮 在 Minion 工作期间或完成之后，工程师可以在 Web UI 中查看 Minion 所做的决策和行动。 > Minion 运行管理 Web 界面的示例 一旦完成任务，Minion 会创建一个分支，推送到 CI，并按照 Stripe 的 PR 模板准备一个 Pull Request。如果代码看起来没问题，工程师就打开 PR 并请另一位 Stripe 工程师审查。如果不行，他们可以给 Minion 进一步的指示，Minion 完成后会将更新后的代码推送到分支上。 工程师也可以在 Minion 运行完成后手动进行迭代。虽然我们的北极星是完全不包含任何人类代码的 PR，但一个不完全正确的 Minion 运行成果，通常仍然是工程师聚焦工作的绝佳起点。 ### Minions 是如何工作的？ 一个 Minion 运行包含多个阶段，在本系列的**第二部分**中，我们将有更多关于 Minions 如何工作的细节。许多细节是 Stripe 特有的，但我们认为有一些可推广的经验。为了吊一下胃口，这里先做一个简要的时间线概览。 一个 Minion 运行从**隔离的开发者环境**（或称 "devbox"）开始，这和 Stripe 工程师写代码时使用的机器是同一类型。Devbox 是预热的，因此可以在 10 秒内启动，预载了 Stripe 的代码和服务。它们与生产资源和互联网隔离，因此我们可以在不需要人工权限审批的情况下在 devbox 上运行 Minions。这也提供了并行化能力，而没有 git worktree 之类的开销——这在 Stripe 的规模下无法扩展。 核心 Agent 循环运行在 Block 的编码 Agent [goose](github.com/block/goose) 的一个 fork 版本上。这是最早被广泛使用的编码 Agent 之一，我们很早就 fork 了它。我们以一种有主见的方式定制了编排流程，将 Agent 循环和确定性代码交替编排：Agent 负责创造性的推理，确定性代码处理 git 操作、linter、测试等等。这样 Minion 的运行既能融合 Agent 的创造力，又能确保它们始终完成 Stripe 要求的步骤，比如运行 linter。 总体而言，Minions 读取和 Cursor、Claude Code 等人类操作工具相同的编码 Agent 规则文件，兼容多种不同的 Agent 规则文件格式。然而，让 Stripe 拥有大量无条件规则是不现实的，因此 Stripe 几乎所有的 Agent 规则都基于子目录条件性应用。 Minions 连接到 **MCP**（Model Context Protocol），它为网络化的 LLM 函数调用提供了一种通用语言。这就是它们收集上下文的方式——内部文档、工单详情、构建状态、通过 Sourcegraph 搜索的代码智能等等。实际上，**我们会在 Minion 运行开始之前，就确定性地对可能相关的链接预先运行相关的 MCP 工具**，以更好地充实上下文。 由于 MCP 是 Stripe 所有 Agent（不仅仅是 Minions）的通用语言，我们构建了一个中心化内部 MCP 服务器 **Toolshed**，托管了超过 400 个 MCP 工具，涵盖内部系统和我们使用的 SaaS 平台。Minions 和其他 Agent 可以连接到这些工具的可配置但经过筛选的子集。 Minions 的设计目标是一次性完成任务，但如果没做到，给 Agent 反馈就至关重要。我们通过多个自动化的测试层来实现这一点，Minions 可以针对这些测试层进行迭代。第一道防线是一个**自动化的本地可执行文件**，它使用启发式方法在每个 git push 上选择并自动运行选定的 lint。这不到五秒。 在考虑开发者生产力时，我们追求**"反馈左移"**。这意味着，对于人类和 Agent 来说，任何会在 CI 中失败的 lint 步骤都应该在 IDE 或 git push 时就被强制执行，并立即呈现给工程师。 如果本地测试没有发现问题，CI 会在推送时从 Stripe 的测试库中有选择地运行测试——我们有超过三百万个测试。我们的许多测试都有针对失败的自动修复（autofix），我们会自动应用这些修复。如果一个测试失败没有自动修复，我们就把它返回给 Minion 去尝试修复。 由于 CI 运行消耗 token、算力和时间，我们**最多只进行两轮 CI**。如果测试在首次推送后失败，我们会提示 Minion 修复失败的测试并推送第二次，然后就到此为止。在速度和完整性之间需要平衡，让 LLM 运行多轮完整 CI 循环的边际收益递减。我们认为"通常一轮，最多两轮 CI 运行——并且只在我们修复了所有能在本地解决的问题之后"的指导原则，取得了很好的平衡。 简而言之，Minions 配备了与人类工程师相同的工具，以及遵循 Stripe 最佳实践编写代码所需的上下文。工程师在日常工作中就可以顺手调用它们——也确实在这么做。 ### 下一步？ Minions 已经重新定义了在 Stripe 写代码的体验。行业仍在探索 Agent 编码的未来会是什么样子。但我们确信，**无人值守的编码 Agent 用例将始终是 Agent 最激动人心的应用之一。** 在[第二部分](stripe.dev/blog/minions-stri…)中，我们将更深入地探讨我们是如何实现 Minions 的。 --- 原文：stripe.dev/blog/minions-stri… #Stripe #AI编码 #Agent #软件工程