human_decomposition_engineering_20260416_deep_research

方法论库 · 引用级 · none

本页是 <code>contexts/methodology/human_decomposition_engineering_20260416_deep_research.md</code> 的逐字投影（仅隐私清洗，零改写）。

name: human_decomposition_engineering_20260416_deep_research
description: 软工/管理史拆解方法
domain: cross
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null
superseded_by: contexts/methodology/task_decomposition_history_methodologies_survey_20260416.md

人类历史上工程与管理学领域的任务分解方法论

调研日期：2026-04-16
调研员：deep-research sub-agent
研究定位：本文聚焦人类工程与管理学历史中成熟的任务分解方法论。LLM agent 编排的潜在同构在文末独立章节单独讨论，主文不强行联系。
字数：约 4800 字中文

1. 引入：为何研究人类的分解史

任何将大问题切成小问题的方法论都要回答三件事：切给谁、切多细、切完之后怎么把它们粘回去。人类在工程与管理领域为此纠缠了一个多世纪，从 1911 年泰勒的秒表，到 1972 年 Parnas 的信息隐藏，再到 2016 年后的微服务反思，主轴始终没有变。每一次大的范式转换，几乎都是因为上一种分解方式在某个维度上过了头。

本文按四个维度展开：软件工程、科学管理与工业分工、项目管理分解技术、分解失败与反思。维度之间存在相互映照：Parnas 1972 的论点本质上是对早期 Fordism 式「按处理阶段切」思维的一次否定；Conway 1968 的 homomorphism 是 Bezos two-pizza team 的理论根。

2. 软件工程维度：从按步骤切到按决策切

2.1 Parnas 1972：信息隐藏作为分解判据

D. L. Parnas 在 CACM Vol. 15, No. 12, Dec 1972, pp. 1053–1058 发表的 On the Criteria To Be Used in Decomposing Systems into Modules，是软件史上最早把「分解依据」本身当作研究对象的论文。该论文用一个具体的 KWIC（Key Word In Context）索引系统对比两种分解方案：

第一种分解（按处理步骤，即当时的「模块化编程」常识）：

1. Input → 2. Circular Shifter → 3. Alphabetizer → 4. Output → 5. Master Control

每个模块对应流水线上的一个处理阶段，直觉自然，但 Parnas 指出这种分解在面对以下任一变化时会同时波及多个模块：

• 输入格式改变
• 内存中行存储表示改变（字符数组 vs 压缩编码）
• 是否预先计算所有 circular shifts（时间换空间的策略选择）
• 字符内部编码改变

第二种分解（按「所隐藏的设计决策」）：

• Line Storage：封装行的内部存储实现
• Input：只负责读入并调 Line Storage
• Circular Shifter：封装 circular shift 的实现策略（可以预计算也可以 on-demand 计算）
• Alphabetizer：封装排序策略
• Output：封装输出格式
• Master Control

原文核心段落（经 Northeastern 的 tech report PDF 抽取）：

Parnas 声称的三个好处：

1. 管理学收益：分离的团队可以独立工作，「与少得多的沟通需要，且之后也很少后悔当初沟通得不够多」。
2. 产品灵活性：可以在一个模块内部做相当大的改动而不波及其他。
3. 可理解性：可以一次只研究一个模块。

失败边界：如果预期的「将来要变的设计决策」与实际变的不一致，信息隐藏反而加重复杂度——模块间的边界画错了地方。Parnas 本人也强调：「The effectiveness of a modularization is dependent upon the criteria used in dividing the system into modules.」

与 agent 编排的潜在同构（留到第 7 章集中讨论，此处不展开）。

来源：

• Parnas, D. L. (1972). "On the Criteria To Be Used in Decomposing Systems into Modules." Communications of the ACM, 15(12), 1053–1058. DOI:10.1145/361598.361623
• Tech report PDF（含完整图表和 KWIC 代码）：https://prl.khoury.northeastern.edu/img/p-tr-1971.pdf
• CMU 课堂 deck：https://www.cs.cmu.edu/~aldrich/courses/654-sp06/slides/23-dsms.pdf

2.2 Brooks 1975：人月神话与外科医生团队

Frederick P. Brooks Jr. 在 IBM OS/360 项目的亲身经历中总结的 The Mythical Man-Month（1975 初版，1995 纪念版增加四章），是软件项目管理思维的基础文本。对「分解」而言它贡献了三条硬规律：

Brooks's Law：「Adding manpower to a late software project makes it later.」原文出处是第二章末尾的归纳。背后的机制是：任务分配本身会产生沟通与培训的开销，这个开销随着人数 n 以 n(n-1)/2 的速率上升，有时会超过新增人力带来的边际产出。

Brooks 在书中明确说：

这段话的工程含义是：分解的并行度被「独立子任务的数量」这个上界硬卡住。把同一个任务再切更细也不会突破这个上界，反而往往让沟通开销吞掉收益。

外科医生团队模型（第 3 章 The Surgical Team）：Brooks 参考 Harlan Mills 的提议，主张大任务不应该交给一支「屠夫队」每人切一块，而应该组建外科医生式团队：一个主刀（chief programmer）负责全部设计与主干代码，其余角色（副手、工具匠、测试员、文档员等）都在支援主刀，确保概念完整性（conceptual integrity）。原文：

第二系统效应（第 5 章 The Second-System Effect）：一个人设计第二个系统往往比第一个危险，因为第一个系统成功带来的自信让他把第一版里克制掉的想法一起塞进来，造成过度工程。这个观察后来被 Joel Spolsky、Butler Lampson 反复引用。原文：

来源：

• Brooks, F. P. (1975, 1995). The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley. ISBN 0-201-83595-9
• PDF 全本：https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf
• 20 周年版 PDF：http://www.cesarkallas.net/arquivos/livros/informatica/Addison.Wesley.The.Mythical.Man-Month.Essays.on.Software.Engineering.20th.Anniversary.Edition.pdf

2.3 Conway 1968：组织结构与系统结构的同胚

Melvin E. Conway 在 Datamation April 1968 发表 How Do Committees Invent? 提出的核心主张：

Conway 给出的并非一句口号，而是一个数学陈述：系统的结构图（把每个子系统当作节点）和设计组织的沟通结构图（把每个设计小组当作节点）之间存在一个 homomorphism（同态/同胚映射）。原文：

Conway 对「项目人数是加法」这个假设提出了明确反驳（早于 Brooks's Law 七年）：

Conway 的推论至今支撑着 Amazon two-pizza team、inverse Conway maneuver（反向 Conway 操作，即为了拿到想要的系统结构，先调整组织结构）等实践。

来源：

• Conway, M. E. (1968). "How Do Committees Invent?" Datamation, 14(5), 28–31.
• 作者主页全文：https://www.melconway.com/research/committees.html
• PDF：https://www.melconway.com/Home/pdf/committees.pdf

2.4 SOLID 的 SRP：从「一件事」到「一个 actor」

Robert C. Martin 提出的 Single Responsibility Principle 最初被表述为 "A class should have only one reason to change." 这句话多年以来被大量误用，Martin 自己在 2014 年的博客和后续演讲中明确澄清：

更精确的表述来自 Martin 本人：「A module should be responsible to one, and only one, actor.」这里的 actor 指请求修改的角色或利益相关方。这个修正把 SRP 从「颗粒度规则」矫正回 Parnas 早已给出的「按变化原因分解」。thevaluable.dev 的 Chris Kaynor 在 2022 年的分析中直接指出 SRP 其实是 Parnas criterion 的一个弱化版本。

来源：

• Wikipedia: https://en.wikipedia.org/wiki/Single-responsibility_principle
• Uncle Bob 原始措辞：http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• Parnas-SRP 关系分析：https://www.sicpers.info/2023/10/ive-vastly-misunderstood-the-single-responsibility-principle/

2.5 Domain-Driven Design：bounded context 与 aggregate

Eric Evans 2003 年出版的 Domain-Driven Design: Tackling Complexity in the Heart of Software 提供了一套以业务领域为分解依据的方法。核心概念：

• Bounded Context：特定术语和规则一致生效的范围。跨 context 的同名术语（比如「账户」在支付 context 和风控 context 里含义不同）必须显式翻译。
• Aggregate：一组必须一起变更的实体，由一个根（aggregate root）统一对外交互。
• Ubiquitous Language：模型和代码共用同一套领域术语。

DDD 的分解依据是「业务语义一致性」，与 Parnas 的「设计决策」、SRP 的「变化原因」殊途同归——都是试图让变化局部化，但 DDD 把「变化源」定位在业务领域的演化而不是技术决策。

Evans 在 2019 DDD Europe keynote 中补充：subdomain 是业务视角的分解，bounded context 是技术视角的分解，两者理想情况重合但常常错位。重新组织业务后 subdomain 会变，bounded context 却可能滞后。

来源：

• Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley.
• Fowler's overview: https://martinfowler.com/bliki/DomainDrivenDesign.html
• DDD Reference PDF: https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf
• Evans DDD Europe 2019 report: https://www.infoq.com/news/2019/06/bounded-context-eric-evans/

2.6 Bezos two-pizza team 与微服务

Amazon 2001 年前后从单体迁到微服务，团队尺寸被 Jeff Bezos 约束为「两个 pizza 吃得饱」。AWS 自己的白皮书说明了动机：

Fowler 在其 TwoPizzaTeam bliki 中强调两个 pizza team 的关键属性不是 size，而是 outcome-oriented（按业务产出组织）而非 activity-oriented（按职能组织）。Conway 的 homomorphism 在这里直接生效：要想让微服务之间耦合松，组织之间的沟通就必须对称地松。

来源：

• AWS whitepaper: https://d1.awsstatic.com/executive-insights/en_US/two_pizza_teams_eBook.pdf
• Fowler: https://martinfowler.com/bliki/TwoPizzaTeam.html

2.7 Strangler Fig 与 Saga：分解的过渡工具

Strangler Fig Pattern（Fowler 2004）：不做一次性重写，而是在旧系统旁边逐步建立新模块，通过 facade 逐步把流量切过去，像绞杀榕树慢慢替代宿主树。这是对 Brooks second-system effect 的直接回应：避免一次性推倒重来。

Saga Pattern（Garcia-Molina & Salem, 1987）：针对跨服务长事务提出，把一个大事务拆成一系列本地事务，每步都有对应的 compensating transaction。当某步失败，按逆序执行补偿事务回滚。orchestration 模式有中央协调器，choreography 模式则通过事件链驱动。

来源：

• Azure Strangler Fig 文档：https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
• Garcia-Molina, H., & Salem, K. (1987). "Sagas." ACM SIGMOD.
• 综述：https://orkes.io/blog/compensation-transaction-patterns/

3. 科学管理与工业分工维度

3.1 Taylor 1911：把动作切到原子

Frederick Winslow Taylor The Principles of Scientific Management (1911) 是人类历史上第一次系统地把「任务如何被分解」当作研究对象。Taylor 的核心主张：

Taylor 的四原则：

1. 科学任务分配：每个工作元素都应该有科学依据
2. 人员筛选与培训：科学选人
3. 管理与工人协作
4. 分工：管理者和工人各负其责，管理层承担规划、工人承担执行

Taylor 本人的案例（Bethlehem Steel 搬运生铁）：通过时间动作研究把搬运动作的每一个分解步骤重新设计，日产量从 12.5 吨提升到 47 吨。

副作用：Taylorism 把判断权从工人移到管理层，产生了「异化」（alienation）问题——工人只执行被分解好的原子动作，不再掌握工作整体。这个副作用在后来 Fordism 的流水线上被放大。

来源：

• Taylor, F. W. (1911). The Principles of Scientific Management, Harper & Brothers.
• Wikipedia 页面 + 原文节选：https://en.wikipedia.org/wiki/The_Principles_of_Scientific_Management
• Saylor PDF 节选：https://resources.saylor.org/wwwresources/archived/site/wp-content/uploads/2011/08/HIST363-7.1.3-Frederick-W-Taylor.pdf

3.2 Fordism：流水线分工的极限

Henry Ford 把 Taylor 的动作分解嵌入到机械化流水线：工件在传送带上移动，每个工位只做一个固定动作。Highland Park 工厂的 Model T 装配时间从 12 小时降到 93 分钟。但社会学层面的副作用严重：

UMich Auto-Life 的 Degradation of Work 档案记录：

Fordism 的失败点是过度分解：工人丧失全局视角，质量问题只在下游被发现，返工成本极高。1920s–1960s 美国汽车业的高缺勤率、罢工频发都与此相关。

来源：https://www.autolife.umd.umich.edu/Labor/L_Overview/L_Overview3.htm

3.3 Toyota Production System：分解的反思与回调

Taiichi Ohno 与 Eiji Toyoda 在 1948–1975 间发展出的 Toyota Production System（TPS）对 Fordism 做了关键回调：

• Jidoka（自働化）：机器/工人有权随时停下线。Type-G 自动织机 1924 年就能在线断时自动停机——让问题立即可见，而不是流到下游。
• Takt Time：根据客户需求节拍而非机器极限来设定产线速度，把节拍从「能跑多快」改为「需要多快」。
• Kaizen（改善）：持续改进每个工位的工作方式，让工人参与分工设计，而不是只做被分配的动作。
• Poka-Yoke（防错设计）：让做错变得物理上不可能。

TPS 的分解哲学是：动作仍然要细，但「谁来决定动作怎么切」这个权力要部分还给工人，并且要留下「整体就地止血」的机制。这是对 Taylorism 的一次结构性修正，而不是推翻。

来源：

• Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production.
• Art of Lean Basic Handbook：https://artoflean.com/wp-content/uploads/2019/01/Basic_TPS_Handbook.pdf
• Toyota Forklift blog：https://www.toyotaforklift.com/resource-library/blog/toyota-solutions/valuing-the-toyota-production-system-and-lean-manufacturing

3.4 Theory of Constraints：分解之外的瓶颈思维

Eliyahu M. Goldratt The Goal (1984) 提出 Theory of Constraints，核心论断：每个系统都有一个约束，系统的整体吞吐由这个约束决定，对其他环节的优化都不会提升整体吞吐——甚至可能让事情变糟。Five Focusing Steps：

1. Identify the constraint
2. Exploit it
3. Subordinate everything else to it
4. Elevate the constraint
5. Repeat

这个思想对任务分解的直接启发是：局部最优 ≠ 整体最优。把每个子任务都切得再精美，如果瓶颈环节没被处理，整体进度不变。这也解释了为什么 Brooks's Law 在工程中反复生效——加人只在非瓶颈环节增加了供给。

来源：

• Goldratt, E. M. (1984). The Goal.
• TOC Institute: https://www.tocinstitute.org/theory-of-constraints.html
• Splunk 综述：https://www.splunk.com/en_us/blog/learn/theory-of-constraints.html

4. 项目管理的分解方法

4.1 Work Breakdown Structure (WBS)

WBS 源自 1960 年代美国国防部 DSARC 程序，PMI PMBOK 把它定义为：

两条核心规则：

• 100% Rule：每一层分解必须覆盖父节点 100% 的工作量——不能有遗漏也不能有重复。
• 8/80 Rule：最底层 work package 的工作量应在 8–80 工时之间。<8 说明切得太碎，>80 说明还要继续分。

WBS 是 deliverable-oriented 而非 activity-oriented：优先按交付物分，而非按活动分。这与 Fowler 对 two-pizza team「outcome-oriented」的强调是同一逻辑的延伸。

来源：

• PMI Practice Standard: https://www.pmi.org/learning/library/practice-standard-work-breakdown-structures-8063
• PMI WBS Basics: https://www.pmi.org/learning/library/work-breakdown-structure-basics-5919

4.2 Agile / INVEST：story 粒度的经验规则

Bill Wake 2003 年在 XP Magazine 提出的 INVEST 用于约束 user story 的写法：

• Independent：story 之间尽量无依赖
• Negotiable：story 是对话的起点而非契约
• Valuable：对用户或业务有价值
• Estimable：团队能估出工作量
• Small：小到一个 sprint 内能完成
• Testable：有明确验收标准

INVEST 的本质是给「分解粒度」提供六个互相制约的维度——Independent 和 Small 是分解维度，Valuable 和 Testable 是验证维度，Negotiable 和 Estimable 是协作维度。这比 WBS 的 8/80 rule 更贴近知识工作的特性。

来源：

• LogRocket: https://blog.logrocket.com/product-management/writing-meaningful-user-stories-invest-principle/
• Scrum-Master.org: https://scrum-master.org/en/creating-the-perfect-user-story-with-invest-criteria/

4.3 Critical Path Method：依赖关系管理

CPM 由 DuPont 的 M. R. Walker 与 Remington Rand 的 J. E. Kelly 在 1957 年前后发展；PERT 同期由美国海军 Polaris 导弹项目与 Booz-Allen 合作开发。两者都把项目建模为有向图：节点是任务，边是依赖关系。

CPM 的核心贡献是给「分解后的子任务」补上了缺失的一环——它们之间的时间依赖关系。关键路径（critical path）是从起点到终点的最长路径，它决定项目的最短工期。任何非关键路径上的任务都有 float（浮动时间），可以在不影响整体工期的前提下挪动。

来源：

• PMI Origins of CPM: https://www.pmi.org/learning/library/origins-cpm-personal-history-3762
• Smartsheet: https://www.smartsheet.com/critical-path-method

4.4 Waterfall：被误读的原始论文

Winston W. Royce 1970 年在 IEEE WESCON 发表的 Managing the Development of Large Software Systems 常被当作 waterfall 鼻祖，但读原文会发现 Royce 用 Figure 2 展示的流水线结构其实是他明确批评的对象：

Royce 在后面给出了五条补救：

1. Do it twice（Prototype）
2. Plan, control and monitor testing
3. Involve the customer
4. 迭代而非一次过
5. 文档化的验证

Waterfall 成为一个问题不是因为 Royce 推荐它，而是因为行业只引用了 Figure 2 忽略了后面的补救。这个案例本身就是「分解后忘了把它粘回去」的教科书例子。

来源：

• Royce 原文 PDF：https://www.praxisframework.org/files/royce1970.pdf
• Fowler 解读：https://martinfowler.com/bliki/WaterfallProcess.html
• 另一份深度解读：https://mosaicprojects.com.au/PDF-Gen/The_Myth_of_Waterfall.pdf

5. 分解失败与反思

5.1 Brooks "No Silver Bullet"：本质复杂度不可消除

Brooks 1986 年的 No Silver Bullet 把软件复杂度分为：

• Essential（本质）：问题本身的复杂度，包括 complexity、conformity、changeability、invisibility 四个属性。
• Accidental（偶然）：来自当前实现手段的复杂度（语言、工具、调试流程等）。

Brooks 原文：

分解可以降低 accidental complexity（把大模块切成易管理的小模块），但无法降低 essential complexity。任何声称「只要分得好就能让一切变简单」的方法论都会在 essential complexity 面前破产。Brooks 的结论是：过去 9/10 的效率提升来自消除 accidental 障碍，未来再消除剩下的 accidental 也不会带来数量级提升——本质难题必须直接面对。

来源：Brooks, F. P. (1986). "No Silver Bullet—Essence and Accident in Software Engineering." IEEE Computer. PDF：https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf

5.2 Distributed Monolith：微服务过度分解

2010 年代后期大量企业采纳微服务后出现 distributed monolith 反模式：服务数量急剧增加但耦合度没变，只是把原来的内存调用换成网络调用，延迟和故障率双双上升。2025 年 CNCF 调查显示 42% 采纳微服务的组织正在整合回来。典型案例：AWS 自身某个视频处理管线从 Step Functions + Lambda + S3 的分布式架构回到单 ECS task 的单体，成本下降 90%。

失败的共同模式：

• 共享数据库 → 服务间紧耦合
• 跨服务事务频繁 → 被迫引入 Saga 等复杂补偿机制
• 服务过细（chatty microservices）→ 网络开销吞掉业务时间
• 运维复杂度超过团队承载力

来源：

• DesignGurus: https://www.designgurus.io/blog/10-common-microservices-anti-patterns
• Microservices.io anti-patterns: https://microservices.io/microservices/antipatterns/-/the/series/2019/06/18/microservices-adoption-antipatterns.html

5.3 Netscape 大重写：Second-System 的商业代价

1998 年 Netscape 决定从头重写 Navigator。Joel Spolsky 2000 年的 Things You Should Never Do, Part I：

Joel 的核心洞察：「It's harder to read code than to write it.」那些看起来难看的边角代码往往是针对真实 bug 的硬解，扔掉就意味着把所有 bug 重发现一遍。Netscape 3 年没出 5.0，6.0 发布时 IE 已经吃掉市场，公司随后被收购。

这是 Brooks Second-System Effect 在商业层面的完整演绎：对「第一版乱七八糟」的受挫加上对「第二版能集大成」的自信，共同驱动了致命的推倒重来。

来源：

• Joel Spolsky: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
• Potapov 深度复盘：https://potapov.dev/blog/why-rewrites-fail/

5.4 Microsoft Longhorn：雄心导致的分解混乱

2001 年启动的 Windows Longhorn 项目原计划在 XP 和未来 Windows 之间做跨代跳跃：WinFS 新文件系统、Avalon 新 UI、Indigo 新通信子系统。到 2004 年 8 月微软宣布 reset，用 Windows Server 2003 SP1 代码作为新基线重启，最终在 2007 年交付大幅削减的 Vista。

失败原因（多位内部人事后复盘）：

• scope creep：各组件目标不断增加
• codebase Frankenstein：新功能叠在旧代码上，文档缺失
• 组织结构与系统结构冲突：各组各自加东西，Conway's Law 体现为团队边界把设计撕碎
• 中层管理阻断反馈：一线工程师的 scope 警告被压制

来源：

• Register 回顾：https://www.theregister.com/2025/03/27/looking_back_at_windows_longhorn/
• Agile Federation 分析：https://www.agilefederation.com/post/longhorn-a-tale-of-structure-power-and-organizational-change

6. 方法论对比表

7. Information Hiding 原则的现代延伸：对 agent 编排的潜在同构

用户的兴趣点是跨域同构。下面把 Parnas 1972 的信息隐藏原则与 agent 编排做一次谨慎的对照，不强行拉扯。

Parnas 原则：每个模块封装一个预期会变的设计决策，接口只暴露最小必要信息。

潜在同构：agent 编排中，如果把每个 sub-agent 看作一个模块，sub-agent 的 prompt 可以被视为它的接口契约，其内部 reasoning 过程是实现细节。这个映射下：

• 什么是「预期会变的设计决策」？对应 sub-agent 的内部策略（用什么搜索关键词、用什么 prompt chain、用什么中间存储）。这些策略不应泄露到 orchestrator 层面。
• 什么是 stable interface？对应任务契约：输入需求规格 + 输出格式规格 + 质量标准。这三项一旦确定，sub-agent 内部怎么做都不应影响 orchestrator。
• 什么是模块替换的收益？对应把某个 sub-agent 换成不同模型（Haiku → Sonnet → Opus）或不同实现（WebSearch → Tavily → Firecrawl）时，orchestrator 不用改。

边界与风险：

• Parnas 原则的前提是「接口比实现稳定」。在 LLM 场景中，prompt 本身常常不稳定（模型升级会让相同 prompt 行为变化），因此「接口稳定」这个前提需要重新定义——可能要用结构化输出（JSON schema）作为更硬的接口。
• Conway's Law 在多 agent 系统中依然生效：如果 orchestrator 的任务分配结构与问题的天然结构不匹配，最终产出会反映 orchestrator 的分配结构而不是问题本身。这对应用户在 NightCode 中强调的「进程文档」——显式地把 orchestrator 的分配逻辑暴露出来以便审计。
• Brooks's Law 的并行上界在多 agent 系统同样存在：并行度被「独立子任务数」硬限制，再加 sub-agent 不会突破。

不是同构的部分：

• Parnas 考虑的是人类团队的沟通成本，人类的带宽与 LLM 的 context window 不完全可类比。
• 软件模块的接口几乎零误差，LLM 的 prompt 接口本质上是带噪声的。
• TOC 的瓶颈识别在 agent 系统中有新变种：瓶颈可能是某个 sub-agent 的 context window、某个工具的速率限制、或者 orchestrator 本身的推理带宽。

本文仅做到「标出可能的映射与差异」，不声称直接复用。

8. Claim 验证状态

9. 书目与 URL 索引

原文与书目

1. Parnas, D. L. (1972). "On the Criteria To Be Used in Decomposing Systems into Modules." CACM 15(12): 1053–1058. PDF: https://prl.khoury.northeastern.edu/img/p-tr-1971.pdf
2. Brooks, F. P. (1975, 1995). The Mythical Man-Month. Addison-Wesley. PDF: https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf
3. Brooks, F. P. (1986). "No Silver Bullet." IEEE Computer. PDF: https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf
4. Conway, M. E. (1968). "How Do Committees Invent?" Datamation 14(5): 28–31. PDF: https://www.melconway.com/Home/pdf/committees.pdf
5. Taylor, F. W. (1911). The Principles of Scientific Management. PDF 节选: https://resources.saylor.org/wwwresources/archived/site/wp-content/uploads/2011/08/HIST363-7.1.3-Frederick-W-Taylor.pdf
6. Ohno, T. (1988). Toyota Production System. 基础手册 PDF: https://artoflean.com/wp-content/uploads/2019/01/Basic_TPS_Handbook.pdf
7. Goldratt, E. M. (1984). The Goal. 综述: https://www.tocinstitute.org/theory-of-constraints.html
8. Royce, W. W. (1970). "Managing the Development of Large Software Systems." IEEE WESCON. PDF: https://www.praxisframework.org/files/royce1970.pdf
9. Evans, E. (2003). Domain-Driven Design. Reference PDF: https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf
10. Garcia-Molina, H., & Salem, K. (1987). "Sagas." ACM SIGMOD.

重要二手资料

1. Joel Spolsky (2000). "Things You Should Never Do, Part I." https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
2. Fowler, M. "Domain Driven Design." https://martinfowler.com/bliki/DomainDrivenDesign.html
3. Fowler, M. "Two Pizza Team." https://martinfowler.com/bliki/TwoPizzaTeam.html
4. Fowler, M. "Waterfall Process." https://martinfowler.com/bliki/WaterfallProcess.html
5. AWS (2020). "Two-Pizza Teams." https://d1.awsstatic.com/executive-insights/en_US/two_pizza_teams_eBook.pdf
6. PMI. "Work Breakdown Structure Practice Standard." https://www.pmi.org/learning/library/practice-standard-work-breakdown-structures-8063
7. Martin, R. C. "Principles of OOD." http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
8. Wake, B. (2003). "INVEST in Good Stories." 综述: https://blog.logrocket.com/product-management/writing-meaningful-user-stories-invest-principle/

10. 交付清单

10.1 对 agent 编排最有启发的 5 个方法论

按启发度排序：

1. Parnas Information Hiding (1972)：把「预期会变的设计决策」作为分解的唯一判据，这比按步骤、按职能、按数据流等任何其他标准都更稳健。对 agent 编排的延伸是：sub-agent 的接口应隐藏内部 reasoning 和 tool chain 选择，只暴露输入 spec 和输出 spec。
2. Conway's Law (1968)：系统结构同构于设计组织的沟通结构，这个观察在 multi-agent 场景同样生效——orchestrator 的任务分配逻辑会以某种方式刻在最终产出里。
3. Brooks Mythical Man-Month (1975)：并行度上界由独立子任务数决定，加人或加 agent 都突破不了。对 agent 编排的直接警示：不要用「再派几个 sub-agent」当万金油。
4. Theory of Constraints (1984)：系统吞吐由瓶颈决定，局部最优可能伤害整体。多 agent 系统中的瓶颈经常是 orchestrator 的 context window、某个工具的 rate limit，或某个关键 sub-agent 的可靠性。
5. Toyota Production System 的 Jidoka + Kaizen：让问题立即可见（停线）+ 让执行者参与设计改进。对应到 agent 系统是：sub-agent 在 confidence 低时主动停下并汇报，而不是把错误传播到下游；同时保留「让 sub-agent 反过来改进 orchestrator」的机制。

10.2 分解失败的共同模式

观察所有维度的失败案例，抽出四条共同模式：

1. 过度分解（over-decomposition）：Fordism 把动作切到工人丧失全局，distributed monolith 把服务切到网络开销吞掉业务时间，过度小 stories 把需求切到失去业务意义。触发条件是「切得越细越好」这个错误直觉。
2. 粘不回来（failure to reintegrate）：waterfall 被误读（忽略迭代反馈），Netscape 大重写（忘了旧代码里的边角修复），微服务共享数据库（忘了服务独立的前提）。触发条件是只关注切的动作，不关注切完之后的整合机制。
3. 分解边界错位（wrong cleavage plane）：Parnas 第一种分解按处理步骤切，一个需求变化就波及所有模块；DDD subdomain 与 bounded context 错位；Longhorn 团队边界与系统边界冲突。触发条件是用直觉而非变化来源来决定边界。
4. Second-System Effect：Netscape 6、Longhorn、Fordism 的极端分工都是第一次成功后对「下一次做大做全」的冲动推到了失败点。触发条件是过度自信 + 积压了太多「等下次一起做」的想法。

10.3 推荐 Round 3 扩张方向

沿三条主轴扩张：

1. 认知科学与生物学的分解：人脑的模块化（Fodor 1983, The Modularity of Mind）、免疫系统的分工、蜂群与蚁群的任务分配、进化算法的 niche 分化。这些生物学方法论有两个 agent 编排未充分利用的特性——自组织和容错。
2. 复杂系统理论：holarchy（Koestler 1967）、Ashby's Law of Requisite Variety、Simon 1962 The Architecture of Complexity（讲 near-decomposability，即「几乎可分解」系统：子系统内部联系强、子系统之间联系弱但非零）。Simon 的 near-decomposability 比 Parnas 的 strict hiding 更现实，值得深入。
3. 军事与应急管理：NATO Mission Command、Incident Command System (ICS) 的 span-of-control（每个指挥官直辖 5–7 人的 empirical 规则，与 Brooks 外科医生团队的规模呼应）、OODA loop。这些方法论在「高不确定、高时间压力、分布式执行」场景下有专门设计，与 agent 编排面对的 corner case 最相似。

另一个潜在深挖点是 *Simon 1962 The Architecture of Complexity***，它的 near-decomposable system 框架可以为「sub-agent 之间并非完全独立但耦合足够弱」这一现实状态提供更精确的理论语言。建议 Round 3 专题化。