人月神话：第 1-6 章
核心问题：Agent 可以写代码之后，《人月神话》还值得读吗？
我的判断：更值得。Brooks 讨论的不是“人类打字太慢”，而是大型软件如何从个人程序变成可交付、可维护、概念一致的系统。Agent coding 降低了局部实现成本，但把真正的瓶颈暴露得更清楚：接口、测试、上下文、规范、评审、集成和责任边界。
1. 焦油坑（The Tar Pit）
观点
Brooks 第一章真正区分的不是“会不会写程序”，而是四个层级：program、programming product、programming system、programming systems product。车库里的小程序可以很快，但可被别人运行、测试、扩展、组合、长期维护的系统产品，成本会被文档、接口、兼容性和集成测试成倍放大。
例子
一个 agent 今天可以几分钟写出脚本：读 CSV、调用 API、画图。这只是 program。要变成团队可用的 data pipeline，它还需要参数校验、错误处理、日志、权限、重试、CI、文档、兼容不同输入和稳定运行。最难的部分不是第一版代码，而是把它放进真实系统后不制造隐性债务。
对当下时代的启发
Agent coding 没有消灭焦油坑，只是把焦油坑从“写不出代码”移动到“无法判断这段代码是否该进系统”。Prompt 降低了局部实现成本，但产品化成本仍然存在。更好的工作流不是让 agent 多写，而是让 agent 更早进入测试、文档、接口检查和运行约束。
2. 人月神话（The Mythical Man-Month）
观点
本章的核心是：进度和工作量不能简单互换。人月这个单位危险，是因为它暗示“多加人就能少花时间”。但软件任务有顺序依赖、培训成本、沟通成本和系统测试成本。项目越晚，新增人手越可能制造额外同步负担。
例子
一个延迟的重构任务，本来需要先理解边界、补测试、再改实现。如果临时拉五个 agent 同时修改同一个服务，看起来吞吐量上升，实际可能出现五套抽象、五种命名、互相覆盖的 patch，以及一个更痛苦的 merge/review bottleneck。
对当下时代的启发
Agent 时代也有“人月神话”的新版本：agent-call myth。更多 agent、更多模型、更多并行分支，不等于更短的交付时间。可并行的是边界清楚的任务，不是概念纠缠的系统。真正有用的是把任务切到稳定接口上，并为测试、集成、回滚和评审预留预算。
3. 外科手术队伍（The Surgical Team）
观点
Brooks 不是简单赞美小团队，而是在回答一个矛盾：大型系统需要足够多人手，但概念完整性又要求很少的人真正决定设计。外科手术队伍的关键是“一个主刀 + 专业支持”，而不是每个人平等切一块代码。
例子
在 agent coding 工作流里，可以有一个 owner 负责设计和最终 diff；一个 test agent 生成回归测试；一个 docs agent 更新用法；一个 review agent 检查边界条件；一个 tool agent 维护脚本和 sandbox。它们都在提高主刀效率，但不能同时争夺架构决策权。
对当下时代的启发
Agent swarm 不应该默认做成多人聊天室。更有效的结构往往是 role registry：谁负责设计，谁负责验证，谁负责检索，谁负责重构，谁负责记录。Agent 最有价值的位置未必是“更多 coder”，而可能是 tester、clerk、editor、toolsmith 和 reviewer。
4. 贵族专制、民主政治和系统设计（Aristocracy, Democracy, and System Design）
观点
本章最重要的词是 conceptual integrity。系统易用性不来自功能堆叠，而来自用户看到的是同一套设计思想。Brooks 把 architecture 定义成用户可见的外部说明，把 implementation 留给实现者创造。少数人控制架构，不是为了压制创造力，而是为了让产品像一个整体。
例子
让多个 agent 独立给 CLI 加功能，很容易出现 --file、--path、inputPath、source 混用；错误信息有的抛异常，有的返回 null，有的打印 warning。每个局部 patch 都可能“合理”，但合在一起就是一个难用的系统。
对当下时代的启发
Agent coding 时代更需要“架构上的贵族制，实现上的民主制”。命名规则、API 语义、错误处理、配置格式、兼容策略必须有明确的 architecture contract；在这个边界内，agent 可以自由探索实现方案。没有统一外部设计，agent 生成速度越快，系统不一致性积累越快。
5. 画蛇添足（The Second-System Effect）
观点
第二个系统最危险。第一个系统里被克制住的想法，会在第二个系统里集中爆发；设计者因为刚获得经验，容易把“我终于懂了”误判成“我可以全都加上”。结果不是成熟，而是过度设计。
例子
一个最小 coding agent 已经能完成：read files → edit → run tests → report diff。做第二版时，团队很容易一次性加上 multi-agent、长期记忆、向量库、planner、browser、GUI、self-evolution、policy engine 和 marketplace。每个功能都能讲出理由，但核心 loop 的可靠性可能没有变好。
对当下时代的启发
Agent coding 会放大 second-system effect，因为每个新功能看起来都只是“再写一个 prompt”。但 AI 降低的是代码生成的边际成本，不是系统复杂度的边际成本。更好的策略是给功能设预算：latency、token、状态数量、失败模式、可观测性和维护成本。没有通过 eval 的功能，不应该因为“能生成”就进入系统。
6. 贯彻执行（Passing the Word）
观点
架构决策不会因为被说出口就自动进入系统。Brooks 在这一章讨论的是 decision propagation：手册、形式化定义、直接整合、会议、电话日志、多重实现、产品测试。文档必要但不充分，真正关键是让决策可以被传播、查询、执行和验证。
例子
一个 agent 接到任务时，会同时看到 README、issue、旧代码、测试失败、用户补充说明和自己的上下文摘要。如果这些信息冲突，它只能猜。相反，如果 API schema、类型、测试、ADR、CI 和变更日志共同指向同一个规则，agent 的行为会稳定得多。
对当下时代的启发
Agent coding 需要 executable specification。文档不再只是给人看的附件，而是 agent 的 operating context。最好的规范应该同时存在于自然语言、类型系统、测试、lint、schema、eval 和 trace log 里。一个规则如果不能被 agent 检索、不能被 CI 检查、不能在 review 中定位，就还没有真正被“贯彻执行”。
总结
《人月神话》前六章里，部分组织形态已经老了，但核心问题没有老。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所以这六章对今天的启发不是“照搬 Brooks 的管理方式”，而是：不要把代码生成速度误认为系统交付速度。Agent 时代真正稀缺的不是更多代码，而是更清楚的边界、更强的验证、更少但更一致的架构决策。