同时开了两个 Agent：冲突与隔离

你在同一个项目上启动了两个 Agent。一个负责支付模块，一个负责账单模块。两个 Agent 各自开始工作，各自修改代码。几分钟后你发现：Agent A 修改了一个共享的工具函数来适配支付逻辑，Agent B 同时修改了同一个函数来适配账单逻辑。两个修改互相覆盖。或者更隐蔽的情况：Agent A 修改了数据库 schema，Agent B 还在基于旧 schema 写查询。两个 Agent 各自的产出在隔离状态下都能通过测试，但它们基于的是同一个代码库的不同快照。

这是分布式并行开发中最基本的问题：共享状态的并发修改。人类团队用分支策略和代码所有权来管理这个问题。多 Agent 场景需要同样的机制，但更显式。

每个 Agent 需要独立的工作空间。最基本的形式是独立的 git 分支：每个 Agent 在自己的分支上工作，完成后通过 merge 集成。更严格的隔离是目录或模块级别的：Agent A 只能修改 payments/ 目录下的文件，Agent B 只能修改 billing/ 目录下的文件。

第四章引入的 Skill 卡片在这里承担了新角色。从一个 Agent 的个人备忘录，变成了多 Agent 团队的岗位说明书。Skill 卡片中的 trust_boundaries 字段明确定义了每个 Agent 可以碰什么、禁止碰什么。"不更改数据库 schema"、"不修改外部 API 契约"这些约束从建议变成了硬边界。当多个 Agent 并行工作时，职责边界的清晰度直接决定了冲突的概率。

隔离的粒度需要根据项目架构决定。微服务架构天然适合 Agent 级别的隔离：每个 Agent 负责一个服务。单体架构需要更精心的模块划分。原则是：Agent 之间的工作范围尽量正交，交集越小，冲突越少。