预计字数：3500 字 阅读时间：9 分钟 难度等级：⭐⭐（用过 AI 工具即可，不用会写代码）

核心价值：学会用"任务边界"和"物理隔离"两个方法，让多个 AI Agent 同时给你干活却不互相打架

---

前几天，我的 Hermes 系统跑飞了。

不是模型报错，也不是对话崩掉。

是早上起来发现，昨晚发的日报里写了一段完全不通的话——"执行 cron: write_file 到 17-工作项目/xxxx 目录……错误：文件被占用"。

我翻了半天日志才发现：前一天晚上我手动开了一个 Codex 任务，让它改 Agent 路由配置。

同时 Hermes 的定时 cron 也醒了一次，在同一个目录写日报。

两个 Agent 同时对同一个目录做写操作，互相覆盖了。

本来一个自动化日报和一个手动改配置的任务，应该井水不犯河水。

但因为它们都在同一台机器、同一个 Hermes 系统、同一个项目目录里干活，它们的"手"撞在一起了。

这不是孤立事件。

如果你同时用多个 AI 工具——Codex 写文章、Claude Code 写代码、Hermes 跑自动化。

你也一定遇到过：一个任务改的内容，被另一个任务覆盖了。

那时候我才意识到一个问题：

多 Agent 并行这件事，真正的瓶颈不是 AI 的能力，而是你能不能给每个任务划清楚边界。

---

先判断：什么时候可以并行？

不是所有任务都能并行。

AI Agent 做一件事就像你请了一个新员工干活。

你不可能同时让两个新员工在同一张桌上改同一份文档——谁动哪一段都不知道。

那什么时候可以？

总结了一个很实用的四条判断标准。

我把它们做成了一个清单，每次开新任务之前过一遍：

  

目标清楚：一句话能说清让 Agent 做什么？
修改范围有限：只涉及少数几个文件/领域？
低耦合：不改其他任务正在动的东西？
有可检查的完成条件：做完没做完，一眼能判断？

四条都打勾，可以并行。

缺一条，串行。

我自己的标签是：写文章的任务和跑系统巡检的任务，同时跑完全没问题

一个只在 17-工作项目/content/ 目录里写文件，一个只在 cron 调度日志里写记录，根本不会有交集。

但改配置和改 schema？我就不敢并行。两个任务都可能改同一个 yaml 文件，谁先改完谁后改完，最后存盘的那个会覆盖前一个的修改。

---

按"改什么"拆任务，别按"项目"拆

最常见的并行错误是：把同一个项目的任务拆成两条线就开跑。

比如你让第一个 Agent"帮我重构登录模块"，让第二个 Agent"帮我加一个新的用户资料页"。

听起来是两件不同的事。

但如果它们都在同一个前端项目里改代码，改到状态管理、API 调用、路由注册时，一定会撞上。

更好的拆分方式，是按修改的对象来分类。

AFei 给出的四类任务划分很清晰：

任务类型	修改范围	适合并行？
内容型	只动 content / 文档目录	✅ 可以和其他类型并行
系统型	只动 config / 系统配置	✅ 可以和其他类型并行
代码型	只动 skills / 脚本目录	✅ 可以和其他类型并行
查询型	只读不写	✅ 随时随地

定律：同一条目录链的任务串行，不同目录链的任务并行。

在我自己的系统里就是这样分的：

• Hermes cron 任务写 ~/Hermes-agent/00-Agent-Core/ 和 ~/Hermes-agent/15-运营/
• Codex 写文章写到 ~/Hermes-agent/17-工作项目/文章项目/
• Claude Code 改代码在 ~/Hermes-agent/03-Skills/

三条线，各自一个目录范围，永远不会互相踩脚。

---

给每个任务划施工区：两个方法

方法一：物理隔离（worktree / 独立目录）

如果你在用的 AI 编程工具支持 worktree（比如 Codex App 内置了多 Agent + 隔离 worktree 功能），每个 Agent 的工作会被自动隔开：

  

# Codex 的 worktree 原理：每个 Agent 在自己的分支副本里改代码
# 这个命令是 git worktree 的标准用法
git worktree add ../feature-xx feature-branch
# Agent 在 feature-xx 目录里改代码
# 改完后你审 diff，选择保留还是丢弃

即使你不用 Codex，这个思路完全可以用到自己的文件系统上：给每个任务一个独立的目录。

我的做法很简单：

• 每篇新文章新建一个项目目录：17-工作项目/文章项目/2026-07-18-任务边界与低耦合并行/
• 配图放到单独的配图空间：21-配图空间/2026-07-18-任务边界与低耦合并行/
• 两个目录里的文件互不相干

这样做的好处是：任何时候我可以同时开一个 Agent 写文章、一个 Agent 做配图、一个 Agent 跑系统巡检，它们永远不会修改同一个文件。

方法二：逻辑隔离（把边界写在提示词里）

物理隔离做不到的时候——比如两个任务都在同一个项目里改不同的模块——就把边界写到提示词里。

AFei 建议每个任务至少写清四件事：

  

做什么：重构登录模块的 API 层
可以改什么：只改 /api/login 目录下的文件
不能改什么：不要动数据库 schema，不要改用户资料页
怎样算完成：API 层重构完 + 测试通过 + 旧接口保留兼容

我就是这样给 delegate_task 写 context 的。

派子任务时加一句"你只能动 /xxx 目录，不要碰 /yyyy"，子 Agent 就不会越界。

有一次我派了一个 Agent 去"整理 10-已蒸馏 目录下的文件分类"，它在 context 里写了"只读 10-已蒸馏 目录，不做任何写操作"。

结果它真的只读不写，老老实实输出一份分类报告就停了。

这就是边界写清楚了的效果。

---

跑起来了，然后怎么验收？

两个任务并行跑完了，或三个。然后呢？

合并的时候按风险排序：

  

✅ 低风险 → 优先验收
   文档修改、小 Bug 修复、测试补充、内容补充
   这些改动范围小、影响有限，可以快速通过

⚠️ 中风险 → 正常验收
   功能增强、样式调整、配置微调
   看一眼改动范围，确认没有越界

🔴 高风险 → 放慢节奏
   架构重构、依赖升级、状态管理调整、数据迁移
   每次合并前仔细检查三件事：

每次合并前问自己三个问题：

1. 1. 它有没有越过我的任务范围？
2. 2. 它有没有删除我已有的功能或内容？
3. 3. 它有没有引入新的依赖或新的风险？

三个都答"没有"，再合并。

---

一人公司的并行原则

说到底，同时用三个 Agent 的体验跟同时带三个实习生的体验很像

你不能什么都不管，但也不用什么事都管。

以下是我自己总结的四条原则：

1. 默认串行，确认低耦合再并行

• 不要为了"快"强行多开。并行不是为了秀技术，是为了让不冲突的事情同时推进。
• 如果你不确定两个任务会不会冲突，让它们一个接一个跑。

2. 先跑起来，再优化并行

• 先学会跟一个 Agent 好好配合，再考虑两个。
• 如果你连一个任务的方向都经常跑偏，开两个只会更快累死自己。

3. 分叉不是多任务

• Codex 的分叉功能很强大——它让你从当前位置尝试另一条路线，保留原路线的进度。
• 但分叉不等于让你同时推进两条线。分叉是"试另一条路，不喜欢还能回来"。

4. 验收条件写清楚，让 Agent 自己报完成

• 不要盯着 Agent 的每步执行。
• 把验收条件写清楚，让它跑完自己告诉你做完了没。你只在关键节点看一眼。

---

多 Agent 并行这件事，本质上不是在考验 AI 的能力有多强，而是在考验你能不能把工作拆清楚。

拆清楚了，一个 Agent 和十个 Agent 的区别不大。

拆不清楚，十个 Agent 十个方向，只会更乱。

下一次再开一个新的 Agent 任务之前，先问自己那四个问题。

• 目标清楚吗？
• 范围有限吗？
• 不和其他任务耦合吗？
• 做完怎么知道？

四个都答"是"，再开。

今天就试试：打开你现在用的 AI 工具，看看同时运行的任务有没有在改同一个文件。如果有，至少先分两个目录。

既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果可以给我个星标⭐，将不胜感激～谢谢你看我的文章，我们，下次再见。

---

#AI并行 #Agent任务管理 #Codex #Hermes #大象AI共学

作者：大象-推动 AI 共学，让普通人轻松上手AI

相关阅读：

• Codex App 官方介绍（多 Agent + worktree） — https://openai.com/index/introducing-the-codex-app/
• Git Worktree 官方文档 — Git - git-worktree Documentation
• 社群站：https://daxiangnaoyang.github.io/daxiang-ai-gongxue/