#IT那些事儿# 大规模并行 agent 开发的实战经验和踩的坑

太逗了，目标是从零开始构建浏览器的多 Agent 大型开发管理实验却暴露了人类社会各种怪现象：

第一个实验：元老院平等参政议政模式
如图一所示，他们让处于同一层级的各个 Agent 使用一个共享状态文件，查看其他 Agent 在做什么，决定自己要做什么，并将更新写回该文件。尽量少规定该怎么做，而是让各个 agent 自行摸索如何自我协作。
结果：一个是这些议员们的吞吐量会降到 1–3 个的水平，大部分时间都在等待锁。二一个是没有任何单个 agent 会接手大型、复杂的任务，它们会刻意回避争用和冲突，选择更小、更安全的修改，而不是对整个项目负起整体责任。

第二个实验：人类公司常见管理模式
如图二所示，他们设计了三个 agent 角色：
规划者——相当于人类中的老板
执行者——相当于人类中的“牛马”
裁决者——相当于人类中的HRBP
规划器会先制定出明确的方案和交付物，推动用户指令不断向前推进。然后这会交给执行者，由执行者作为唯一的主导代理，全权负责确保计划被完整落实。在执行者完成后会有一个独立的裁决者介入，判断执行是否已经完成，以及是否需要再进行一轮迭代。
结果：规划者在一开始就把所有规划都做完了，相当于年初订了战略规划直接下发“牛马”，这会让系统在发现新问题时很难动态调整。这种南辕北辙直到循环的下一次迭代才能自我纠正。

第三个：不要HRBP了
如图三所示，因为发现 agent 执行力足够强，有一个裁决者反而增加了系统复杂度，所以移除了这位 HRBP[允悲]
并且他们在 system prompts 中加入了自我反思和目标对齐提醒。
鼓励 agents 随时调整方向并质疑既有假设。
系统现在高度动态且灵活！！！

小结一下：
当“牛马”足够强的时候，不要为它们本来就会的事情下指令，而只针对它们“不知道的东西”（例如多智能体协作），或者与你的领域强相关的内容（例如如何运行测试、你的部署流水线）。你要把“牛马”们当成一位极其聪明但刚入职的工程师：懂工程，但还不熟悉你的代码库和流程。因为约束往往比指令更有效。“牛马”们在默认情况下通常会做正确的事，而约束是在划定它们的边界。

#昀哥推荐阅读# http://t.cn/AXcIXTUu