Damian Galarza 的终端里现在常驻着三个 agent：Codex 修单点的 bug，Pi 跑要多步派发的活，Claude Code 调前端视觉。三个各占一个 worktree，herdr 把它们收在一个面板里，标出哪个在干、哪个卡住、哪个闲着。他人离开桌子的时候用 Termius 连回那台不睡眠的 MacBook，接着用同一个会话，他博客里就有一张坐在沙发上用手机接 agent 的照片。

这是他 10 月 21 日发的第二篇工作流复盘。一年前他写过一篇 Claude Code 工作流，那时候只有一个工具、一套配置、一条路。现在他每天在三个 harness 之间切，外加一个 herdr 把它们串起来，还顺手写了三套自己用的 skill。

他给的结论有点反直觉：先搭流水线，再挑工具。顺序反了，挑工具就是在给自己找活。

三个工具怎么分家#

Codex 接单点的小活。 2026 年 5 月，他的 Claude Max 撞了周限额，这个偶然事件逼他去认真用 Codex。用下来他判断 Codex 那套 harness 当时比 Claude Code 强，桌面端和手机端让他从手机上接活比 Claude Code 的远程控制顺。GPT-5.6 那一代出来后，他觉得 Sol 比 Opus 4.6 更省。内置浏览器加上原生的多 agent 派发，让他第一次把多 agent 编排跑通，往 worktree 里派 agent 变得很顺手。

不过他也补了一句：最近几周他又回 Claude Code 用得多了。工具排位这件事本身在漂。

Pi 接要多步派发的长活。 Pi 是个极简的开源 agent harness，口号是 “primitives, not features”，默认不带 sub-agent、plan mode、权限提示，全靠扩展和包自己加。他在 August Health 时用它接公司那套 Amazon Bedrock 模型，后来上 herdr 才用得勤。还有个很现实的原因：Codex 在 herdr 里开 pane、管 agent 不太稳，Pi 补了这个洞。

Claude Code 守门面和调度。 设计和前端还是 Claude 的地盘，Claude Design 好用，Fable 和 Opus 做前端体验更强。GPT-6 Astra 和 Sol 追近了距离，但 artifact 和设计系统这套东西上，他觉得 Claude 仍然领先。真正把他拉回来的还有多 agent 工具：ultracode 把计划直接写成 workflow 脚本，后台铺开一队 agent，主会话照样能回话；/advisor 在关键节点让主模型去问一个更强的模型，比如定方案之前、宣布任务完成之前。

这三个分工其实承认了一件事：没有一个工具在所有维度上赢。Codex 赢在活小、边界清；Pi 赢在能拆能接；Claude Code 赢在审美和调度。

herdr 和那间"AI 棚子"#

herdr 是专门给 agent 做的终端复用器。装了它的 agent skill 之后，agent 自己能建 worktree、在里面起另一个 agent、给它发 prompt，全走 herdr CLI。所有 agent 收在一个面板里显示状态，需要人时通知你。它跑在后台服务上，关终端不丢东西，还能 SSH 连回去。

DHH 管这个叫 “AI shed”：一台常开的机器挂在 Tailscale 上，大部分 agent 在那儿跑。Galarza 的棚子是台不睡眠的 MacBook Pro，旁边一台 DGX Spark 跑本地模型 qwen3.8-flash-next，把一部分活卸到本地。出门就 Termius 连回去，接着用同一个会话。

这段值得多看两眼。多 agent 编排的底层需求其实是寻址，每个 agent 都要能被另一个 agent 找到、起出来、喂指令。worktree 给隔离，herdr 给寻址。缺一个，编排就退化成人在中间复制粘贴。

上下文从哪来#

代码库是第一个来源。 Lauren Tan 的说法被他直接引了：代码库是 agent 最好的记忆，因为 agent 会照着已有的模式长。代码里全是 workaround，agent 就复制 workaround。所以纠错要尽量往代码那一层推，先用架构让这个错误写不出来，再用静态检查抓，最后才退回规则和 skill。顺序反了，就是在给人写说明书。

代码库外的信息靠接口。 Linear 用 MCP 连，做 issue 时把编号丢给 agent，让它自己去捞上下文；agent 干完把进度写回 ticket，下一个 agent 接得上。Sentry 用 CLI，能拉完整的 stack trace，比 MCP 轻，而且在每个 agent 里行为一致。会议记录用 Fireflies 或 Granola，两家都有官方 MCP。Notion MCP 通团队的第二大脑，个人那部分放在本地 Obsidian 库，在各家的全局指令文件里写一行路径就够了：

  • Codex: ~/.codex/AGENTS.md
  • Claude Code: ~/.claude/CLAUDE.md
  • Pi: ~/.pi/agent/AGENTS.md
My Obsidian vault is located in ~/vault

这一段读起来不像技巧，像基建。他列的东西没有一个是 Codex 独有的，全是能换供应商的接口。工具会换，接口不容易换。

四段流水线#

整条工作流是个循环：shape（把活理清楚）→ build（实现）→ review（评审）→ ship（发布），发完回到下一轮 shape。

Shape：让活能被 agent 接住#

他把相当一部分时间花在这一步。shaping 和 plan mode 不是一回事：plan mode 解决"怎么实现"，shaping 解决"我们到底在解什么问题"。活 shape 好了，他很少再开 plan mode。

用的 skill 来自 Matt Pocock：grill-me 揪着一个方案不停追问，适合非编码问题；grill-with-docs 同样追问，但边问边写文档，决策记成 ADR，术语进词表；domain-modeling 打磨领域模型；codebase-design 给 agent 一套描述深模块的共用词汇。一条 npx skills add mattpocock/skills 全局装完。

追问完，spec-writer 负责把已经谈定的东西整理成短 spec，不再重新采访你，内容包括问题、方案、编号规则、决策、开放问题、怎么测、不做什么，然后通过 Linear MCP 存成 Linear 文档。issue-writer 再把 spec 切成小的纵向切片，切片之间标阻塞关系，每张票写清做什么、怎么算做完、别碰什么，规则用 ID 引用而不复制，这样每条规则只活在一个地方。

他贴了一段 spec 片段，是个代码评审 agent 的重试逻辑：

## Rules

R1 - Retry only recognized transient provider failures. Overload,
temporary rate limits, retryable server responses, and network interruptions.

R2 - Keep permanent and ambiguous failures terminal. Authentication
failures, exhausted quota, invalid responses, cancellation, and unclassified
errors are never retried automatically.

R3 - Use bounded exponential backoff. Retry after 30 seconds, 2 minutes,
and 8 minutes, with ±20% jitter. Three automatic retries, four attempts total.

R4 - Preserve one logical job. Retries keep the same job ID and target
commit. Duplicate webhook deliveries neither create a new job nor reset the
retry budget.

这四条规则里，R3 可以直接写成测试，R4 能写成幂等断言。这就是规格和提示词的区别：提示词是对话，说过就散；规格是文件，能被引用、能被 diff、能被下一个 agent 读到。R1 和 R2 划的边界尤其值钱，它把"什么错该重试"这个最容易让 agent 自作主张的地方钉死了。

Build：换干净会话干活#

实现不在 shaping 的会话里接着做，重开一个干净上下文的 agent。用 herdr 建 worktree，按活的形状挑人：Codex 干简单一次性的，Pi 干要多步派发的，Claude Code 干前端视觉或者需要 agent 自己调度复杂活的。

实现用 Lauren 的 pstack。他明说自己对大而全的 skill 包很怀疑，多数加的流程比省的多，pstack 是例外。pstack 分三层：/poteto-mode 是入口，按任务匹配 23 个 playbook（修 bug、加功能、重构、原型、性能、发布），把步骤抄成 todo 再开工；下面一层是情境 skill，/how 讲某个子系统怎么跑，/why 翻 git 历史和 PR 评论解释为什么这么写，/architect 先定类型和调用点，/interrogate 让不同模型来拆你的 diff；最下面是 24 条原则，一条一句，比如能删就删用最小改动解决问题、先做减法再加、把活做成杠杆（写 codemod 或生成器让人能重跑）、修根因、拿真东西证明、可逆的决定自己下别卡在人身上。

pstack 故意不带 planning skill，README 写得很直白：the best spec is code。设计问题用一次性原型和 /architect 草图解决。这跟 shaping 正好接上：shaping 定下做什么和为什么，pstack 在代码里磨出怎么做。

验证是这套东西的地基。/create-verification-skill 会生成一个项目内的 skill，带一个小 CLI 能驱动应用，还有一张功能地图，写明有哪些功能、怎么到达。有了它 agent 才能自证，编排也才成立，因为编排者只有在每个 agent 都能证明自己改动有效时才敢交接。

Review：六个专科 agent 加一道核实#

team-code-review 把改动分给六个专科 agent，各看一个角度：架构与代码质量、可读性、测试、可维护性、安全、文档。

真正让这套可用的不是六个视角，是后面那道核实。主 agent 在报之前逐条验证，打开引用的代码、看调用方和测试、能复现就复现，猜的和没验证的直接丢掉。所以回到人手上的是短的、带证据的清单，不是一堆似是而非的猜测。

还有个变体 herdr-code-review，在 herdr 里开一个干净会话跑同一套，避免继承实现会话的上下文偏见。发现的问题回到实现那边改，再评审，循环到能开 PR 为止。

Ship：提交规范和叠起来的 PR#

conventional-commits 让每条提交符合 Conventional Commits，他顺手给了理由：历史好扫，agent 回看历史理解旧改动时也更准。stacked-prs 用 gh stack 把大活拆成叠起来的 PR，每个只装一个聚焦改动，避免一个巨型 PR 压在评审人桌上。GitHub 的 stacked PR 还在 public preview，仓库得先开。

不随工具变的部分#

一年前这篇文章讲一个工具，现在讲三个加一个 herdr，他自己的判断是一年后名单大概率又变。

不变的是活的形状。agent 在好上下文下干得最好，所以喂上下文的那些接口跨 harness 通用；shaping 永远排第一，问题搞清楚了 agent 才敢自己跑；验证决定你能交出去多少，agent 自证、六个 reviewer 的发现先被核实、一叠人能读完的小 PR，是同一件事的三个面。

他的建议是先搭循环，别先挑工具。找你今天最弱的那一段，通常是 shaping 或者 verification，先往那儿投。问题清楚、agent 能自证之后，循环剩下的部分会自己变顺。

看完之后的几点#

这套东西的成本不在订阅费，在 shaping。把一个设计追问到每个分支都有结论，比写代码慢得多，他自己也承认相当一部分时间花在这儿。这也解释了他为什么很少用 plan mode：他把"想清楚"这一步提到了 agent 之前，由人和 agent 用问答一起完成。plan mode 是让 agent 替你想，shaping 是你和 agent 一起想，后者的结论能落到文件里。

另一个值得抄的做法是"让纠错尽量往左走"。同一个错误，能靠架构挡住的别靠 skill，能靠静态检查挡住的别靠 AGENTS.md。skill 和指令是最后一道，不是第一道。这条跟 OpenAI 那个百万行无手写代码团队的结论是一致的，他们也是把规则往上提到 linter 和结构测试里，让 agent 想犯都犯不了。

还有一点要提醒：这条流水线有六七个组件，herdr、pstack、四个 shaping skill、两个 writer、两个 review skill、两个 ship skill。跑得顺的前提是他每天都在用，肌肉记忆已经形成。新手照抄，多半会卡在装 skill 和写全局指令文件这两步上，然后得出结论说这套没用。真要抄，先抄 spec 和 issue 那一步、还有 review 里的核实那一步。这两步不依赖任何工具，今天就能做。

参考来源：Agentic Coding Workflow: Claude Code, Codex, Pi，Damian Galarza，2026 年 10 月 21 日。