我的 Coding Agent 工作流

AI Coding 一路改变着我的编程习惯。最早是 VSCode 里手写代码，后来是 Copilot 补全，再后来是 Cursor 的 Apply。到 Claude Code / Codex 这一代全托管 Agent 后，协作方式又变了一次。

以前写代码更像单线程工作：打开一个仓库，盯着一个需求，做完再切下一个。现在任务可以交给 Agent 跑，人反而变成了调度者：把需求拆开，给不同 Agent 分配上下文，再回来验收结果。

笔者探索出一套工作流是：远程 / 云端的 Devbox 开发机 + tmux + worktrunk。它没有让模型变得更聪明，但解决了两个更现实的问题：多任务并行，终端不断线。

早期焦虑

只在本机跑 Agent 时，我经常不敢合盖。任务跑到一半，人在通勤路上，还要开着电脑连热点，看它有没有卡住。

后来看到“Keep your agents running 7x24”这类产品文案，第一反应是当段子，第二反应是它确实戳中了我的痛点。

另一个麻烦点是同一个 git 仓库里的多需求并行。以前我会把仓库 clone 好几份，每份切不同分支。时间一长，目录和分支就开始互相污染，经常要先确认自己到底在哪个仓库、哪个分支里。

真正缓解这个问题的不是更强的模型，而是三个简单的开发工具：

worktrunk：同一个仓库里，每个任务开一个独立 worktree。Agent 的主要改动都落在自己的目录里，不会和另一个任务混在一起。我不用手写 git worktree 命令，主要是因为 worktrunk 的目录命名、切换、状态查看更顺手。我的习惯是 git-repo/ 放主干分支，git-repo-worktree/{branch}/ 放任务分支。还有一个意外收获：Claude Code / Codex 的历史会话跟工作目录绑定得更清楚，--resume 恢复会话时不容易选错上下文。
Devbox：Agent 跑在一台常驻机器上，本机只是入口。笔记本断网、合盖、换地方，都不会影响远程任务。
tmux：终端会话常驻在后台。SSH 断开后，远程窗口、日志、交互状态都还在；回来重新连上，就能接着看输出、发下一条指令。

~/.tmux.conf 里只开了鼠标：

set -g mouse on

本机 shell 里放一个 devbox 命令，连上远程机器后自动进入同一个 tmux session：

alias devbox='ssh -t host "tmux new -A -s agents"'

这里的 host 提前放在 ~/.ssh/config 里。tmux new -A -s agents 的意思是：如果 agents 这个 session 已经存在，就直接 attach；如果不存在，就创建一个。

worktrunk 的目录规则放在 ~/.config/worktrunk/config.toml：

worktree-path = "{{ repo_path }}/../{{ repo }}-worktree/{{ branch | sanitize }}"

我的日常流程基本是这样：

这套流程的重点不是“睡觉时让 Agent 自己干完一切”，而是让任务状态不要因为人的设备状态而中断。它把本机从执行环境变成了控制台。

我也试过一些社区工具。很多方案会把事情变复杂：要把内网机器接到公共网关，要适应新的 GUI，要接受一套新的项目管理模型。对我来说，这些都没有直接复用 SSH、tmux、git worktree 来得自然。

例如：

当然我当前的工作流也有未解决的问题：

我对有个手机能操作 Coding Agent 这件事没有太多需求，想清楚让 Agent 做什么、/goal 验收标准（达到预期结果）比为了 7x24 空转消耗 token 产生代码垃圾更有意义。Agent 能不停地写，但写出来的，最后合进了主干，还是进了回收站？