15个AI代理同时干活，最容易撞车的地方不是模型

Addy Osmani在X上写了句话：“Delegate the task, never the judgment”。Viv Trivedy转发时补了自己正在用的五条设置，主题是怎么让一直在线、主动干活的多代理系统真正跑起来。

原文在这里：Viv Trivedy的推文。Addy的文章在这里，引用推文在这里。

回复区比主贴更值得看，因为大家都在补同一个问题：代理可以并行，判断力带宽不够。

Viv列出的五条

降低理解代理工作、给代理反馈的摩擦。Viv说今天很多操作从iPhone完成。入口要短，看结果和给反馈别绕。
用拥有独立工作切片的代理并行。Adam Wright在回复里说，他跑大约15个代理，每个只保留一个任务加一份很短的never-list，否则会在同一批文件和登录上撞车。他问Viv怎么切，才能让两个代理不共用工具。这个问题比“多代理架构”更实际。
给代理自管理工具：和其他代理的owner沟通、自验证、必要时采购有限额外基础设施。关键词是有限。
用swarm扩计算，但结果受限于目标能否被清楚指定、能否自验证。Viv说swarm里很多魔法和混乱，来自能朝一个范围明确、可验证、超难的任务扩展，比如Lean证明。可以把Lean证明理解成机器能逐步检查的数学证明。
上下文要容易取。前沿模型今天很大程度上受上下文和人类判断限制。上下文碎片化，代理更难做对的事。用集中存储，比如GitHub、中心化drive、Slack，让代理不管从什么设备开始都能取到上下文。

Franze M说，委派代码不消除定义done。有用工单要可观察行为、约束、检查结果的方法。代理让缺失需求出现得更快。

Mister SnowCrash给bug修复加了一个工件要求：新回归测试在旧代码失败，在修复后通过。这样能防止测试只是同意实现。他问这是在harness里强制，还是留给review。

pasandida(:)aura建议给claude.md里每个workaround加一个小测试，判断何时能移除。否则升级模型后，还在管理旧模型犯的错。

Aayan说自己更像supervisor，不是manager。Mahir Şentürk说选IC track是为了避免当经理，代理没收到备忘录。Ryan Wong说，过去在编译器CPU之上操作，假设它们会完成；代理和harness足够好时，该放手。

这些讨论把AI代理管理拉回工程问题：工作切片、完成定义、验证工件、上下文存储、反馈入口。普通用户不用搭15个代理，也可以先做一件事：把任务写清楚，把完成标准写出来，把验证方式留下。开发者要小心，代理越多，冲突越多，判断力越稀缺。Addy那句话的重点在别把判断也外包。