Offrun 那个工作区示例里躺着 12 个代理：8 个在跑，3 个在等用户，2 条未读回复。列表长得像值班表——Claude 在 billing-svc 上跑 Retry backoff，状态 Working；Codex 卡在同一项目的 Fix flaky upload test，Needs you；AGY 在处理 api-gateway 的 Rate limits；还有个 Claude 在 offrun-site 的 Pricing copy 上闲着（Offrun 页面）。
单看这一屏，像个玩具。
把它跟旁边那份额度面板摆一起，性质就变了：Claude Work 的 session 已用 82%、week 64%，Claude Personal 的 session 12%，Codex pro plan 的 week 5%，Agy 的 5 小时窗口 1%（同上）。一个人在同一个下午调度四种语义完全不同的配额窗口、五个登录、四种代理 CLI，跑在同一个仓库上。
这块地图我要给它一个名字：编程代理的编排层——代理本体下面那一层，负责把多个代理、多个账号、多份隔离副本、多份上下文塞进一个可操作的工作区里。过去一年多，这一层从"每个人的 dotfiles 加 tmux 加几个 shell 函数"长成了有独立产品形态的东西。但公开讨论基本还黏在上面一层：Claude Code 和 Codex 谁强、Antigravity 的 agy 好不好用。
这篇往下走一层。主线三条：隔离、账号与额度路由、审查与记忆。按惯例先给骨架，再逐支梳，最后落判断。
骨架：这套栈纵切成四层
把现在跑在开发者 Mac 上的东西按层切开：
编程代理栈（纵切）
├─ L1 代理本体 Claude Code / Codex / AGY / Grok Build /（Pi、OpenCode 待接）
├─ L2 隔离层 每代理独立文件夹 + 独立 git worktree / 分支
├─ L3 编排层 工作区、任务分配、多账号、额度路由、审查调度
└─ L4 上下文与边界 项目记忆文件、预览回路、本机听写、Mac 即边界
| 层 | 在解决什么 | 代表形态 | 成熟度 |
|---|---|---|---|
| L1 本体 | 让模型会写代码 | Claude Code、Codex、AGY、Grok Build（Offrun 页面） | 已打成一团，能力差异按月收敛 |
| L2 隔离 | 让多个代理不互相踩 | git worktree / 分支，每代理一个文件夹 | 基本定型，没有第二候选 |
| L3 编排 | 让一个人管得过来 | 单一工作区、多账号、额度切换、代理互审 | 刚成形，语义各家不一 |
| L4 上下文边界 | 让上下文活得比会话久，让数据不出机器 | 仓库内记忆文件、本机听写、预览回路 | 最碎，分歧最大 |
这个切法有个便宜可占：它把"哪个代理更强"挤到 L1，把这篇真正想说的东西留在 L2 往下。L1 的竞争我不关心——那是模型公司的战场，谁这个季度领先半个身位，下个季度就被追平。L2 往下才是工程问题，工程问题的解法一旦定了，很难再被模型能力推翻。
L1：代理本体已收敛成"CLI + 你自己的订阅"
先花两段把 L1 交代掉，它决定了下三层能不能立住。
Offrun 的 FAQ 里有一句态度很明确：它不替代 Claude Code 或 Codex，它运行它们，用户保留自己的账号和订阅（Offrun FAQ）。同一份页面还有一句更硬的：用你本机已装好的代理 CLI，以你自己的身份登录，不要新账号或 API key，也不碰你的密码（Offrun 页面）。
摆在一起，这是整层商业模式的前提。翻译成判断：编排层的价值跟它支持的模型数量成正比，跟任何单一模型的能力成反比。壳层绑定一个模型，它就变成那个模型的附属 UI；只有它同时跑 Claude Code、Codex、AGY、Grok Build，而且 Pi 和 OpenCode 还在排队（Offrun 页面），壳层才是一个独立坐标。
一个细节值得单拎：AGY 是 Google 那条线，用 Google 账号登录，和 Claude Code、Codex 并列（Offrun FAQ）。2025 年之前，一个人同时用三家模型公司的编程代理，意味着一套极度别扭的终端配置；现在它只是工作区列表里的三行。
我持保留的一点：Pi 和 OpenCode 还是"即将推出"（Offrun 页面），所以我现在判断不了这层抽象够不够通用。接一个新代理如果要改壳层代码，那这份"模型中立"就只是当下四家的巧合，不是架构。等它真接上再看。
隔离层：worktree 是唯一走通的那条，代价是它堵死了一整块
这块地图画得最干净，答案收敛得毫无悬念。
| 方案 | 怎么隔离 | 代价 | 现状 |
|---|---|---|---|
| 多开终端同一目录 | 不隔离 | 两代理改同一文件，互相覆盖，diff 没法看 | 只在单代理时用 |
| 容器 / VM | 文件系统级 | 干净但重，代理要访问宿主 git 状态、凭据、CLI 反而更麻烦 | 少数派 |
| 每代理独立文件夹 | 目录级 | 源文件要复制或软链，仓库状态容易漂 | 过渡形态 |
| 每代理独立 git worktree | 分支级 | 同一 worktree 内不能并行；环境依赖要自己管 | 事实标准 |
Offrun 是把后两个叠起来：每个代理在独立文件夹里跑，同一项目里每个代理拿到独立 git worktree，两个代理处理同一仓库时不会改到相同文件（Offrun 页面）。有了这一条，用户可以同时开一个重构和一个 bug 修复，然后按自己节奏合并（同上）；FAQ 也确认 Claude Code 和 Codex 能同时处理同一仓库，因为各自用独立 worktree 和分支（Offrun FAQ）。
这一支走通的原因，我认为不是 worktree 比容器"轻"，而是它不发明新抽象。worktree 是 git 自带的东西，branch 是开发者已经在用的心智模型，代理干完活留下的就是一个普通分支，合并路径跟人写的分支完全一样，不需要任何新工具来读它。容器那一路输在要求人接受一套新的生命周期管理。
代价得说清：worktree 隔离的是文件，不是语义。两个代理在各自分支上把同一个函数改成不同签名，合并时一样炸，只是炸在 merge 那一步而不是写文件那一步。这一层真正解决的是"改乱了看不出改了什么"，不是"自动帮你协调"。把隔离当协作，是这块地图上最常见的误读。
额度路由：又脏又值钱，而且没人愿意讲
我本来以为这块是配角。梳完发现它是整张图里信息量最大的一格。
先看那几个数字。同一个工作区的额度面板上：Claude Work 的 session 窗口 82%、week 窗口 64%；Claude Personal 的 session 12%；Codex pro plan 的 week 5%；Agy 的 5 小时窗口 1%（Offrun 页面）。五个登录，三种窗口语义——Claude 是 session 和 week 双窗口，Codex 按周，AGY 按 5 小时。
这就是订阅制的真实形态：你把成本从一个连续量（token 数）换成了几个离散的时间窗。这个转变直接决定编排层要干什么活。API 计费时代，调度问题叫"怎么少花钱"，是模型侧和 prompt 侧的事；订阅制时代，调度问题叫"怎么别在下午三点撞上窗口上限"——纯壳层的活。
Offrun 的处理是把账号变成可路由资源：不同代理可以用不同登录账号，某个账号达到限额时，它把聊天转移到仍有额度的登录并告知用户（Offrun 页面）。用户重新发一条消息，新的登录接续整个对话；如果一个可用的登录都没有，它会建议换用另一个代理（同上）。FAQ 里把 Claude Code 这条讲得更细：可以加多个 Claude Code 账号，限额切换时聊天移到下一个登录，重发消息继续（Offrun FAQ）。
页面给的例子是凌晨 3 点：Claude Code 在那个时刻重置，Codex 可以接手该聊天并拿到完整对话（Offrun 页面）。
这个动作的分量，我怀疑大多数人第一遍看会漏掉。它不是"切换账号"，它是跨账号、跨提供商的会话状态转移。难点不在文件层面——对话上下文在本地，好办；难点在提供商的 session 绑在登录身份上，你把同一个对话从 Claude Work 挪到 Claude Personal，对面看到的是一段没有历史的新会话，所以需要用户重发那条消息把上下文重新灌进去。这里的"用户重新发送"不是偷懒，是绕开一个壳层拿不到的接口权。
我的判断：额度路由是这一层最不可能被上游吃掉的活。模型公司没有动机帮你调度竞争对手的配额，每家的窗口语义还不一样，任何通用方案都得为每一家写一遍适配。它脏、不性感、没有论文可发，但它是这类产品真正的护城河。至于这条线会不会收敛——如果哪天几家统一了额度语义（比如都按 token 而不是按时间窗），这一层的工作量会掉一半，产品的差异化也跟着掉一半。这个可能性我持保留态度，但值得记在地图边上。
审查者代理：它被故意做成了"第二意见"，不是一道闸门
代码审查这一支最容易被看成"AI 帮你看 PR"。实际路线选择完全不是这么回事。
Offrun 的机制是：第二个代理可以在你之前审查 diff，并在工作尚未提交时把发现发到聊天里（Offrun 页面）；你可以要求代理修复审查发现的问题，修复内容会先进入消息框供你阅读，之后才发送（同上）。FAQ 补了两条边界——审查只读 diff 并发布发现，不能改代码，后续决定由用户做出；审查运行在你自己的某个代理账号上，模型在模型选择器里指定（Offrun FAQ）。还有一条：代码审查不自动合并任何内容，它用你自己的代理账号，不额外订阅，也不在 pull request 上放机器人（Offrun 页面）。
不自动合并、不装 bot、不碰 PR——三条加起来，等于明确放弃"团队流程工具"这条路，只做"你写代码时旁边那个嘴碎但靠谱的同事"。
为什么？我认为因为闸门位置的成本结构完全不同。放在 PR 上，你就得处理 bot 身份、权限、审计留痕、CI 集成，每一样都是团队协同的活；放在提交前，你面对的只有一个问题：这个 diff 里有没有人眼会漏的东西。
页面给的那个例子正好命中这一类。审查者指出：30 秒的重试上限超过了网关的 25 秒超时，导致最后一次重试被截断（Offrun 页面）。这种 bug 的特征很典型——两个数字分别看都没错，30 秒合理，25 秒也合理，只有放在一起才错；linter 检测不到，类型检查检测不到，单元测试如果不专门构造超时场景也检测不到。它不是能力问题，是"没人同时看着这两个数字"的问题。让一个刚读完 diff 的模型去盯它，投入产出比高得离谱。
我持保留的地方：这条线的价值高度依赖审查模型和主代理是不是有相同的盲区。两边都是同一家模型、同一个上下文窗口，一个犯的错另一个很可能也犯。Offrun 允许在模型选择器里指定审查者（Offrun FAQ），这是必要的接口，但"用不同家的模型互相审"在实践中会不会变成默认，我不知道。如果不会，这一支的上限就被卡住了。
预览回路：被低估了，它决定代理的迭代速度
审查解决"改得对不对"，预览解决"改完什么样"。这两件事我本来想合成一段，梳完分开了，成本结构不一样。
Offrun 的预览让用户不离开聊天就能看到改动文件、带行号的 diff、渲染后的 Markdown 和表格、图片、PDF，还有一个带地址栏的小型浏览器（Offrun 页面）。那个小型浏览器是这段里最有意思的东西——它不是"渲染一个 HTML 文件"，它是有一个地址栏的窗口。本地起了一个跑着的服务时，代理改完可以直接在那儿点，不用切到 Chrome。
页面用上传器修复那个例子说明这件事：修复让 src/uploader.js 等待所有上传完成，测试改成检查文件是否到达而不是检查顺序；修复前 50 次跑过 41 次，修复后 50 次全过（Offrun 页面）。
我要在这个例子上多停一下，因为它不只是"测试通过了"。41/50 说明它是个 flaky test，病根不是上传逻辑慢，是断言写错了对象——它断言的是到达顺序，真正该断言的是到达这件事。这类测试在 CI 上会随机红，然后所有人学会重跑它，然后它就永远烂在那儿。修法是把断言从"顺序"改成"到达"，同时让代码等所有上传完成，两处一起改才成立。
代理能自己跑 50 次、看分布、定位到断言对象而不是断言强度，这个回路没有预览基本做不成——你得反复在编辑器和测试输出之间跳。预览在这里的作用不是"好看"，是把观察成本压到零，而观察成本直接决定迭代次数。
项目记忆：这一支我持保留，但有一步走对了
记忆这块地图上堆的东西最多，也最容易做成一锅粥。Offrun 的切法是两条线并行：仓库级约定集中存放，同时为每个代理分别保存目标、计划和失败尝试（Offrun 页面）。代理开始会话时读这些上下文，工作过程中写回，让后续会话知道此前试过什么（同上）。落地成普通文件放在项目文件夹里，可以打开、编辑、提交（同上）。页面上列出来的文件包括 conventions.md、plan.md 和 dead-ends.md（同上）。FAQ 确认这套东西能纳入版本控制（Offrun FAQ）。
三个文件里，dead-ends.md 是全篇最值得抄的一个设计。绝大多数"给代理加记忆"的方案记的是"做了什么"——改过哪些文件、跑过哪些命令、结论是什么。这些信息有检索价值，复用价值很低，因为成功的路径已经写在代码里了。真正会丢、丢了最贵的是失败经验：上次为什么改用另一种连接池、上次为什么把重试次数降回来、上次那个看起来很自然的方案卡在哪一步。
人在同一个项目上待三个月会自然长出这份记忆，代理不会——它每次会话都是新的。把"此路不通"写成一个可提交的文件，等于把这部分隐性成本搬到仓库里，而且跨工具、跨厂商，因为它就是普通文本，Claude Code 读它和 Codex 读它没有区别。
持保留的地方在并发。文件方案在单代理下没问题，多个代理同时往 dead-ends.md 里写就会冲突——这是 git 层面的冲突，不是产品层面的，任何"用文件当数据库"的方案都会撞上。他们选文件而不是数据库，我认为是清醒的取舍：文件能 diff、能 review、能回滚、能跟仓库一起演进，代价是没有检索和并发控制。在这个场景下人的可读性确实比机器的检索效率重要，但这条线到"十个代理同时写"的规模上会不会先撞墙，我不知道。这是我在这块地图上还没画清的一格。
边界层：本机听写是小功能，"服务器不在路径里"是句大话
听写这块，功能描述两句话能说完：按住按键说出提示词，Offrun 在本机转写，然后把文本放到光标位置（Offrun 页面）；完全在 Mac 上跑，不留录音，不上传（同上）。除了设置阶段需要网络，之后都在本机（Offrun FAQ）。
真正体现设计水平的是词汇表那个细节：把听写成 "mac book" 的纠正成 MacBook，把 "jason" 纠正成 JSON（Offrun 页面）。这个细节说明做的人天天用它写代码——通用听写模型在自然语言上表现很好，一到标识符就崩，因为它没见过 JSON 这种全大写、MacBook 这种驼峰。听写对编程场景的价值恰恰在长提示词上：一句话讲清"把 uploader 里那个等待逻辑改成等所有上传完成"，比手打快得多。拼不对标识符，这功能就是废的。
隐私那部分，我想把两句常被混为一谈的话分开。Offrun 的说法是：Mac 是边界，语音留在本机；聊天、记忆和 worktree 作为仓库内的 .offrun 和 .worktrees 文件夹存在，Offrun 不保留副本（Offrun 页面）。提示词直接从用户的 Mac 发往用户所选提供商，代理以用户自己的身份登录，代码流向 Anthropic、OpenAI、Google 或 xAI，Offrun 的服务器不在该路径中，也不处理密钥（同上；FAQ 里的说法一致）。
"我们不上传你的代码"和"我们不在代码的路径里"是两种强度完全不同的承诺。前者是可以被内部改掉的政策，后者是架构事实——只要服务器不在通路上，它就没有能力做那件事，哪怕是恶意或者被收购之后。这家产品把自己放在后者的位置上，代价是它拿不到任何可以拿来做训练、做分析、做增值服务的数据，也就少了一大半后续想象力。这是个真实的选择，不是营销话术。
把前面梳的压成一张图
| 分支 | 核心机制 | 关键取舍 | 当前状态 |
|---|---|---|---|
| L1 代理本体 | 本机 CLI，以用户身份登录，不新建账号 | 壳层不绑定单一模型 | 已收敛，模型中立是前提 |
| L2 隔离 | 每代理独立文件夹 + 独立 git worktree | 复用 git 分支，不发明新抽象 | 事实标准，无第二候选 |
| L3 额度路由 | 多账号、限额检测、跨登录会话转移 | 用户重发消息补上下文 | 刚成形，语义各家不一 |
| L3 审查调度 | 第二个代理读 diff，发到聊天，不改代码 | 不做 PR bot，不做闸门，只做第二意见 | 路线已定，效果待验证 |
| L4 记忆 | 仓库内 conventions / plan / dead-ends 文件 | 文件优先于数据库，可读性优先 | 单机可行，并发未解 |
| L4 边界 | 本机听写；服务器不在代码路径里 | 放弃数据增值换架构承诺 | 设计已定 |
横向一条规律，我觉得是这张图里最要紧的线索：四层里，越往下越不依赖模型能力。L1 每个月都在变，L2 三年没变过，L3 的难点全是接口和语义，L4 的难点是并发和可读性。编排层这类产品的迭代节奏，会越来越不像 AI 产品，越来越像基础设施产品——没有一个新模型发布能让 worktree 隔离变好一点。
纵向看另一条：这四层里唯一被完整做出来的产品形态是"单机 + 自带订阅"这一格。Offrun 的定价说明把这条钉死了：免费且不限量，0 美元，不设席位数，不需要信用卡，用户自带代理订阅（Offrun 页面）。免费版包的东西摊开是：不限量代理与项目、不限量本机听写、不限量连接的编程代理账号、面向 100 多个连接器的免费额度、不限量代理监控与审查（同上）。连接器这块，代理可以查邮件、提交 GitHub issue、发到 Slack，用户可以选哪些聊天用哪个账号（同上）。
这个定价不是慷慨，是结构决定的：价值锚点在用户的订阅里，壳层想收钱只能往团队协作那半边挪，而那半边要处理权限和审计，是另一个产品。
和 Conductor 那条线比一下
同一层里，Conductor 是绕不开的对照。共同点：都在 Mac 上跑，都用用户自己的订阅，都在 git worktree 里跑代理（Offrun 对比页）。分岔有三处。
Conductor 侧重 pull request、检查和团队功能；Offrun 侧重每个代理的多个登录以应对限额、从用户自己的代理账号里选审查者、把 Antigravity 和 Claude Code、Codex 并列，而且免费（同上）。
这三处正好对应我前面判断的三条分支：额度路由、审查者选择权、模型中立。它们都是"个人侧"的能力，不是"团队侧"的。我的读法是，这不是两个产品的功能差异，是同一层里两条分岔的路——一条往团队协作走，要收席位费，就得处理谁有权合并、谁看得见什么；一条往个人多账号走，收不到席位费，只能靠着"你已经有订阅了"立足。
Offrun 选了后者。这个选择意味着它必须把个人侧的体验做到团队工具做不到的细，因为那是它唯一能站的地方——比如凌晨三点那个额度重置的瞬间有没有人接住你的对话，比如审查者能不能换一个模型，比如接不接第四家代理。
落子
摊开这张地图，我的落子是这样：编程代理的编排层现在站在"单机格局定型、协议层一片空白"的位置上。
定型的那部分已经没什么可争。隔离用 worktree、代理本体以用户身份调用本机 CLI、上下文以文件形式放进仓库、敏感数据不出机器——这四条在过去一年多里从各家做法收敛成了共识，而且我认为它们不会因为模型换代而改变。一个 2026 年写的地图，这几格可以画成实线。
空着的那块大的，是代理之间到底怎么说话。现在这层里唯一被实现的代理间交互是"审查者读 diff、把发现发到聊天"（Offrun 页面），浅得只有一厘米。没有任务交接格式，没有代理之间互相提问的通道，没有"代理 A 卡住了、把上下文移交给代理 B"的标准做法——额度切换那套转移机制（同上）已经证明会话状态可以跨账号搬，但那是产品内部实现的，不是协议。
我为什么觉得这块最值钱：只要代理间没有协议，编排层的上限就永远是"一个人能同时管几个窗口"。有了协议，才可能出现"一个代理发现自己不擅长这件事，主动把任务交出去"这种真正意义上的复用。谁先定这个格式，谁就占了下一格坐标。
第二块空着的是跨机器。现在整张图都锁在一台 Apple Silicon 的 Mac 上，要求 macOS 14 Sonoma 或更高，外加至少一个你已经在用的代理 CLI（Offrun 页面；FAQ 同）。worktree 是本地的，额度是本地的，记忆在仓库里但并发也没解。代理池能不能跑在别的机器上、能不能在团队之间共享，这块地图完全没有内容——它可能是下一年的战场，也可能根本不需要存在，因为本地机器的算力够用。这个我不确定，先留白。
按规矩得交代这张图哪儿没画全。第一，我只读了公开页面，没装过，上面所有关于体验的判断都是从描述反推的——比如"用户重发消息才能续上对话"这个设计，实际用起来手不手感，我说不了。第二，Pi 和 OpenCode 还挂着"即将推出"（Offrun 页面），接上之后这层抽象够不够通用，等它接上再看。第三，Windows 和 Linux 那半边我整块略过了，清单里没有，我也不猜。
最后摆一个可以被打脸的地方：如果未来一年里没有任何代理间的交接约定跑出来，不管是文件约定还是 API，那说明这块需求是我想多了，编排层就永远停在"多开终端 plus 一点点"。真到那天，这张图我会重画——地图画错了不可怕，可怕的是拿着一张错图还觉得自己在看全景。