头几个月, 我一个人在终端里用 Claude Code, 感觉效率提升很明显。但很快遇到一个问题: 我下班关了电脑, agent 也停了。我需要的东西, 只能在我坐在电脑前的时候才能跑。

如果你的使用场景也是"只有我在的时候才用", 那 Claude Code 完全够用。但当你开始想: 这个 CR 能不能自动帮我 review? 这个依赖更新能不能每周一自动跑? 你就需要想怎么让它离开你的电脑还能干活了。

第一步: 把重复劳动做成脚本

最简单的方式就是把常用的 agent 任务写成脚本。比如我每两周要升级一次项目的依赖:

claude -p "把 package.json 里的依赖升到最新 minor 版本, 跑测试, 有 break 就修"

用 --output-format json 可以拿到结构化的输出。需要流式处理的话用 stream-json, 每行一个 JSON 对象。

再进一步, 把这些脚本扔到 crontab 或者 CI 里:

# 在 GitHub Actions 或 crontab 里跑
claude -p "review 最近变更的代码, 检查安全问题" \
  --output-format json --allowedTools "Edit,Bash(git *)"

--allowedTools 限制了 Claude 只能做什么操作——批量跑的时候尤其重要, 防止它乱搞。

大规模 Fan-out

如果要在几百个文件上执行同一个操作——比如迁移 API 调用方式——可以先生成文件列表, 然后循环调 claude -p 逐个处理:

for file in $(cat files.txt); do
  claude -p "把 $file 从 axios 迁移到 fetch" \
    --allowedTools "Edit,Bash(git commit *)"
done

先在 2-3 个文件上调通 prompt, 再全量跑。--allowedTools 限定了它能用的工具, 无人值守的时候更安全。

第二步: 给团队建共享配置

单人的 CLAUDE.md 和单人的 settings.json, 到团队阶段就不够用了。

团队需要一套共享的 agent 规则——不是每个人都各自维护一份。我见过的方式:

• 把 CLAUDE.md 放到项目仓库里, 所有人都用同一份
• 团队级权限模板, 规定哪些操作必须人工确认
• 一个共享的 skill 目录, 谁写了有用的 skill 就 PR 进去

规则统一之后, 团队里每个人用 agent 的行为是一致的, 不会出现有人能发生产部署、有人连测试都跑不了的混乱情况。

第三步: 引入事情驱动的自动化

定时任务只是开始。真正让 agent 发挥价值的是事件驱动——某个事情发生了, agent 自动响应。

常见的事件和响应:

• PR opened → agent 自动跑代码 review
• 构建失败 → agent 分析日志, 尝试修
• 依赖有安全漏洞 → agent 升级依赖, 开 PR
• 每周一凌晨 → agent 做一次全局的代码健康检查

这些触发器和执行器放到一个平台上统一管理, 就不再依赖任何一个人的终端。

插曲: Worktree 解决并行冲突

做大规模迁移的时候, 一个常见的麻烦是: 一个 Claude 在改代码, 另一个 Claude 也在改同一份代码, 冲突了。

Claude Code 支持 Worktree——每个会话在独立的 git 检出里工作, 互不干扰:

claude --worktree "把 report 组件迁移到新 API"

每个 worktree 是独立的目录, 改完各自提交, 不存在协作冲突的问题。

再进一步: Agent Teams

对于更复杂的任务——比如一个新功能涉及前后端、数据库、测试——可以让多个 Claude 协同工作。一个 lead agent 分配任务, 多个 worker agent 在独立上下文里并行执行, lead 负责合并结果。

不过这个功能还在实验阶段, 默认是关闭的。目前实际项目中用得更多的是前面说的 fan-out 模式。

第五步: 控制层跟上

当团队有几十个 agent 同时在跑不同的事情, 你就需要回答几个问题:

• 谁开的这个 agent?
• 它碰了哪些文件?
• 花了多少钱?
• 如果出问题了怎么追溯?

这就是控制层要做的事——权限、审计、成本、可见性。到这一步, 已经不是配置问题了, 是平台问题。

不过说实话, 大部分团队走到第二步就已经够了。先让个人习惯变好, 再慢慢扩展, 别一开始就想着搭平台。

文章链接：