人月神话：第 7-12 章
7. 为什么巴比伦塔会失败？（Why Did the Tower of Babel Fail?）
观点
Brooks 把巴比伦塔当成一个工程失败案例看：目标、人力、材料、时间、技术都不缺，真正缺的是交流，以及交流之后形成的组织。大型软件项目也是这样失败的：一个小组悄悄改变输入输出约定，另一个小组还在按旧假设设计，系统级灾难就从这些细小误解里长出来。
例子
一个 coding agent 系统里，planner 让 coder 改 API，coder 把返回字段从 source 改成 uri，test agent 只测了本模块，docs agent 还在生成旧字段文档。每个 agent 都完成了自己的局部任务，但下游调用全部断掉。问题不是 agent 不聪明，而是系统没有共享语言和变更传播机制。
对当下时代的启发
Agent orchestration 首先是 communication design。多 agent 不应该只靠自然语言互相喊话，而应该有 schema、typed tool contract、接口版本、变更日志、trace 和 ownership。Agent 越多，越需要减少无效通信、明确职责边界，并让关键决策能被所有相关 agent 检索和验证。
-
非正式：DM
-
项目会议
-
工作手册
组织架构的必要性
“大型编程项目的组织架构
如果项目有n个工作人员，则有（n2 - n）/ 2个相互交流的接口，有将近2n个必须合作的潜在团队。团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。”
“减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。
事实上，树状组织架构是作为权力和责任的结构出现。其基本原理—管理角色的非重复性—导致了管理结构是树状的。但是交流的结构并未限制得如此严格，树状结构几乎不能用来描述交流沟通，因为交流是通过网状结构进行的。在很多工程活动领域，树状模拟结构不能很精确地用于描述一般团队、特别工作组、委员会，甚至是矩阵结构组织。
让我们考虑一下树状编程队伍，以及要使它行之有效，每棵子树所必须具备的基本要素。它们是：
- 任务（a mission）
- 产品负责人（a producer）
- 技术主管和结构师（a technical director or architect）
- 进度（a schedule）
- 人力的划分（a division of labor）
- 各部分之间的接口定义（interface definitions among the parts）”
8. 胸有成竹（Calling the Shot）
观点
这一章谈估算。Brooks 反对把小程序经验直接外推到大型系统，因为编码只是总工作的一小部分，计划、文档、测试、集成、培训和沟通都会吞掉大量时间。更重要的是，系统规模和复杂度上升时，工作量不是线性增长，交互越多，生产率越低。
例子
让 agent 写一个 demo API 可能只要十分钟，但把它交付到生产环境要算上：鉴权、错误处理、日志、监控、迁移、测试数据、CI、回滚、prompt/tool 失败、benchmark drift、安全审查和人工 review。只估“生成代码的时间”，就像只估跑 100 米的速度然后推断马拉松成绩。
对当下时代的启发
Agent coding 需要新的估算单位。不要用生成了多少行代码衡量进度，而要看 accepted diff、passing eval、regression risk、review cost 和线上故障率。越跨服务、跨数据、跨权限的任务，越要乘上复杂度系数。Agent 提高的是局部吞吐，不保证系统交付周期同比例缩短。
9. 削足适履（Ten Pounds in a Five-Pound Sack）
观点
Brooks 讨论的是程序空间：空间本身不是坏事，但不必要的空间是成本。真正的问题不只是“模块有没有超预算”，而是有没有把总空间、访问次数、功能边界和用户体验一起纳入预算。局部满足指标，可能导致整体更慢、更大、更脆弱。
例子
一个 agent 产品里，每个模块都只加一点点：retriever 多塞 5 条上下文，planner 多跑一轮 self-check，coder 多调用一次 lint，memory 多存一份摘要，logger 多写一段 trace。单看都合理，合起来就是 30 秒延迟、巨额 token 成本、上下文噪声和难以复现的行为。
对当下时代的启发
今天的“五磅袋子”不只是内存，而是 context window、token budget、latency、工具调用次数、用户注意力和维护复杂度。优化 agent 系统时，不能只改 prompt，要重新设计数据表示、上下文压缩、缓存策略、调用边界和失败路径。预算必须是系统级的，而不是每个 agent 各自报喜。
10. 提纲挈领（The Documentary Hypothesis）
观点
Brooks 说，项目文档海量，但真正支撑管理的是少数关键文档：目标、技术说明、进度、预算、组织、空间和人员分配。文档不是形式主义。写下来会迫使含糊决策变清楚，让分歧暴露，也让项目经理拥有沟通、检查和调整项目的支点。
例子
做一个 coding agent 平台，最重要的文档可能不是长 wiki，而是几份短而硬的文件：产品目标、architecture contract、tool registry、eval plan、release checklist、cost budget、owner map。如果这些不存在，agent 只能从 issue、README、旧代码和聊天记录里拼上下文，最后把猜测当事实。
对当下时代的启发
Agent 时代更需要“少数关键文档”，而不是更多文档。好文档应该能同时给人和 agent 使用：短、结构化、可检索、可版本化，最好能和 schema、测试、lint、CI、eval 连接。文档的价值不在于写得完整，而在于它能成为系统决策的控制面。
11. 未雨绸缪（Plan to Throw One Away）
观点
本章最著名的判断是：第一个系统通常应该被丢掉。因为只有做过一版之后，团队才真正理解问题、用户和技术边界。危险不在于写原型，而在于把原型伪装成产品发布，然后被坏抽象、坏接口和支持成本绑住。
例子
第一版 coding agent 往往会把 prompt、工具调用、状态机、错误处理和评估逻辑写死在一起。跑了几周后才发现：planner 总是过度拆任务，retriever 引入噪声，test agent 不会覆盖真实失败，memory 还会污染上下文。这个时候继续 patch 可能比重写 core loop 更贵。
对当下时代的启发
Agent 产品的 MVP 应该显式标注哪些是 throwaway。prompt、memory schema、tool protocol、eval set、trace format 都要能版本化和替换。不要把探索期的 prompt 当架构，也不要把 demo 的 happy path 当产品。真正成熟的 agent workflow，必须预留迁移、回滚、重放和重构空间。
12. 干将莫邪（Sharp Tools）
观点
Brooks 反对每个程序员维护一套私人工具箱。大型项目的核心问题是沟通，工具不统一会增加误解和摩擦。团队需要公共工具，也需要为专业需求配置工具管理者；同时，目标机器、仿真器、程序库、文档系统、高级语言和交互式编程都会显著影响生产率。
例子
如果每个工程师都用自己的 prompt、IDE、脚本、测试命令和本地记忆，agent 生成的 diff 很快会不可比较。一个共享 agent toolchain 应该包含稳定 sandbox、统一 test runner、repo 权限、依赖扫描、trace viewer、eval dashboard、fixture library 和可复现的 replay 机制。
对当下时代的启发
Agent 的能力上限很大程度由工具链决定，而不是只由模型决定。最重要的基础设施不是“再接一个大模型”，而是让 agent 能安全读写、确定性运行、复现失败、比较方案、回滚变更、记录 trace。未来团队里 toolsmith 的重要性会上升：他不是辅助角色，而是在定义 agent 能做什么、不能做什么、怎么被验证。
总结
《人月神话》前十二章里，过时的是机器价格、组织称谓和具体工具形态；没有过时的是大型软件的系统约束。Agent coding 让实现更快，但它没有取消沟通、估算、预算、文档、原型和工具链问题，只是把它们换了表现形式：
programmer coordination → agent orchestration
manual review → eval / CI / trace
architecture handbook → executable spec
late manpower → late agent swarm
second-system effect → prompt-away feature creep
project workbook → versioned context / schema / ADR
space budget → token / latency / context budget
pilot system → throwaway agent prototype
tool room → shared sandbox / replay / eval harness所以这十二章对今天的启发不是“照搬 Brooks 的管理方式”，而是：不要把代码生成速度误认为系统交付速度。Agent 时代真正稀缺的不是更多代码，而是更清楚的接口、更强的验证、更克制的资源预算、更短更硬的文档，以及一套能让 agent 行为可复现、可审计、可回滚的工具链。