多款编程 Agent 并用后的环境治理

同时开着 Claude Code、Codex 和 Cursor，真正拖慢工作的，可能是藏在窗口后面的审批、不断膨胀的 worktree，以及忘记关掉的开发服务器。作者的 MacBook Air 因为 512 GB 磁盘塞满而频繁重启，这让他开始整理多 Agent 开发的外围流程。

他的结论是：多开几个 Agent 之前，先管好上下文、人工决策和机器资源。文章给出了一套个人工作流，也介绍了由这些需求催生的 3 款 Mac 应用。方法可以借鉴，产品效果则需要和作者的使用经验分开看。

三个 Agent 怎么遵守同一套规则

作者给每个仓库放一份简短的 AGENTS.md，Claude Code 则通过以 @AGENTS.md 开头的 CLAUDE.md 读取它。规则采用命令句，因为这些文字会进入每次会话，写得越长，重复占用的上下文就越多。

下面这段负责明确代码与提交要求：

## Universal
- TypeScript `strict` on, no `any`, named exports only.
- Conventional Commits for every message.
- No new dependency without a one-line justification in the PR description.
- Errors: fail loud in dev, structured + logged in prod. No swallowed exceptions.

留意最后一行：它要求开发环境直接暴露错误、生产环境记录结构化日志，却没有附上长篇理由。Agent 执行规则时，不必每次都阅读规则的形成过程。

理由另存在 Obsidian。作者为每项约定建立实践笔记，记录在哪些仓库使用过，从想法进入试用，再经过多个仓库的应用，才升级为强制规则。目前有 910 条实践笔记，其中 92 条进入强制执行状态。

开源项目 second-brain-workflow 将这些规则生成到 AGENTS.md、CLAUDE.md 和 Cursor rules，让 3 个工具读取一致要求。这里可借鉴的是规则的筛选过程：先验证，再写入每次必读的文件。

其余信息按用途存放。每日笔记记录本次完成事项和遗留问题，下次会话再读回；反复解释的流程做成 Skills，需要时加载；MCP servers 按项目配置，让同时运行的两个产品会话分别使用自己的分析和托管账户。

这解决的是三种不同需求：长期约束、短期进度、外部服务访问。全塞进 AGENTS.md，文件很快就会失去重点。

审批要减少，也要让人及时看见

作者曾把 Codex 窗口留在 Claude 后面，结果一个待确认请求卡了整整 4 小时。并行会话再多，停在审批上的 Agent 也不会继续工作。

他的第一步是减少重复提问：为项目内的只读命令配置允许规则，在 Claude Code 中对应项目设置里的 permissions.allow。剩下需要人判断的请求，再集中展示。

作者为此开发了 AgentNod。Claude Code 和 Codex 可以发送权限请求、问题与计划，Cursor 的 shell 和 MCP 审批也能进入同一个 Mac 队列，展示具体命令或 diff。按 ⌘Y 允许，按 ⌘N 拒绝；force push 等破坏性命令标红，并要求确认。

选择 Always 会为该项目保存对应命令的规则，对 Claude Code 还会写入 permissions.allow。文中给出的价格是免费使用 48 小时，此后每台 Mac €12.99。

审批的价值在于保留真正需要判断的决策，同时让这些决策及时到达人。

不过，文章没有解释命令匹配规则有多精细，也没有给出减少了多少次提示的统计。不能据此把某个宽泛的 shell 入口直接设成永久允许，更不能把集中审批理解为取消审批。

清理 worktree 看分支，排查占用看项目

作者让每个并行会话创建独立的 git worktree，避免两个 Agent 修改同一份检出目录。代价是各自的 node_modules、.venv，以及 Xcode 为不同目录产生的 DerivedData 会一起增长。

他的一次统计发现，35 个 Agent worktree 占用 46.77 GB，其中 19 个已经合并且工作区干净。最大的目录有 13.32 GB，但存在未提交修改；第三大的 4.65 GB 也一样。夹在中间的 9.1 GB 目录，反而已经合并且干净。

所以，按大小或最后使用时间排序，并不能回答「删哪个不会丢工作」。

DevSweeper 将 Xcode、模拟器、包缓存、Docker images 与 build cache、构建目录和 Agent worktree 放在一起扫描，再按清理对当前工作的影响分级。已合并且推送的 worktree 可以移除，扫描结果可能标为 Safe now 或 Expect a slowdown；有未推送提交的标为 Expect a slowdown；有未提交修改或被 Agent 锁定的标为 Affects active work，不会移除。

这里必须分清清理对象：默认只删除 node_modules 或 .venv，保留 worktree 和分支。扫描免费，应用内清理一次性收费 €14.99，最多用于 3 台 Mac。

磁盘之外，还有后台进程。作者的 Activity Monitor 显示约 900 个进程，但他真正想知道的是哪个项目在消耗资源。

为此开发的 Overhead 按进程所在的 git checkout 汇总 CPU 和内存，将 node、xcodebuild、开发服务器和 Agent 会话归到对应项目与 worktree。它还列出监听端口的开发服务器，提供 Stop；列出已启动的 iOS 模拟器，提供 Shut Down；Auto 保持唤醒模式则在长任务期间阻止休眠，结束后允许休眠。

Overhead 免费，以 MIT 协议开源，安装命令如下：

brew install --cask dimeloper/tap/overhead

注意 --cask 后面包含完整的 tap 路径。作者称它安装后会自行更新，唯一的网络请求是每日更新检查；原文没有提供独立验证结果。

我的判断

最值得借鉴的是，作者把多 Agent 的问题落到了可检查的状态上：规则有没有经过验证，审批有没有人在等，分支有没有未保存的工作，进程属于哪个项目。这些比单纯比较谁生成代码更快，更接近日常开发中的实际阻力。

但这仍是一套个人经验。文章没有对照实验，不能据此认定三个 Agent 并行一定更高效，也不能量化这些应用节省了多少时间。应用截图还标注了演示请求或演示项目，不能当作实测性能数据。

清理分级尤其需要谨慎。未推送提交被归入 Expect a slowdown，只有结合默认清理依赖目录来理解才合理；如果把整个 worktree 删除，风险就完全不同。分支状态也是检查依据，不能替代对具体删除范围的确认。

对一般前端团队，现有规则文件、审批配置、Git 命令和端口排查工具，已经能实现其中不少做法。这 3 款应用主要提供集中展示和操作入口，是否付费取决于并行任务规模与维护成本。

作者还准备把 second-brain-workflow 的脚本与 Skills 做成 Hindbrain，从会话中整理持续更新的项目简报，再附加到已有 AI 工具中，免费 beta 已开放申请。原文没有给出它降低上下文整理成本的实测结果，暂时把它当作后续方向更合适。

能拿来做什么

• 给前端或 Node 仓库保留一份短 AGENTS.md，只放已经验证、需要反复遵守的规则；约定的理由另存文档，重复流程做成 Skills。
• 检查 AI 编程工具里反复出现的审批，为确认安全的项目只读命令配置允许规则，并保留会修改数据、历史或远端状态的人工判断。
• 清理并行开发产生的 worktree 前，同时检查未提交修改、未推送提交和合并状态；先清理可重建的依赖目录，明确每次操作会删除什么。
• 遇到风扇转动、内存紧张或端口冲突时，先追查进程所属项目与 worktree，再停止遗留服务器；同时运行多个产品时，将 MCP 配置和账户按仓库区分。