task_decomposition_history_methodologies_survey_20260416

方法论库 · 引用级 · none

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

name: task_decomposition_history_methodologies_survey_20260416
description: 军事/软工/组织史任务拆解横向综合
domain: cross
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

人类历史上的任务分解方法论综合调研

调研日期: 2026-04-16
调研方法: Round 2 双 sub-agent 并行 (工程管理学 + 军事组织) + 跨域同构整合
Reader Mode: Internal (读者是 NightCode 作者,关注跨域同构与信息论视角)
定位: 本 session 是三份关联调研中的第三份,聚焦人类历史上成熟的任务分解方法论。能力边界见 human_llm_capability_boundary_survey_20260416.md,资源容量见 llm_context_multi_topic_capacity_survey_20260416.md。本 session 不要求与 LLM 强相关,以人类经验为主,末尾独立章节讨论对 agent 编排的启示。

一、结论

人类用两个多世纪打磨了从拿破仑军团到 two-pizza team 的分解方法论。穿透所有成功案例的共识相当少却异常一致:意图要明确但细节要留白;span 要受认知约束;边界要按"预期会变的决策"切而不是按流程切;冗余但不浪费的拓扑。失败模式也高度同构:指令过度规定、span 突破上限、信息隐藏边界被暴露、autonomy 和 alignment 失衡、过程分解冒充结构分解。

最被低估的单一原则是 Parnas 1972 年提出的信息隐藏。它不是一种软件工程技巧,它是一个可以直接迁移到军团制、Two-pizza team、分布式认知的底层结构。Parnas 对比了 KWIC 索引系统的两种分解方式:按处理步骤分解 (Decomposition 1) 在需求变化时必然波及所有模块,按"隐藏可能变化的设计决策"分解 (Decomposition 2) 让变化局部化。这个区分的跨域投影极其深远。Napoleon 军团隐藏了战术决策让军团指挥官自主应对;Auftragstaktik 的下级对"怎么做"的决策对上级透明但不被接管;Mintzberg Professional Bureaucracy 通过标准化专业技能让管理层不需要了解内部;Two-pizza team 通过 single-threaded ownership 把 API 作为唯一接口。失败案例的共同反模式是信息隐藏边界被暴露:Healthcare.gov 的 55 家承包商之间没有明确信息边界、NHS NPfIT 的全国统一软件强迫所有 Trust 暴露内部流程、Matrix dual reporting 让员工的任务暴露到两套政治结构。

第二个被低估的原则是 Span of Control 的 3-7 数字在跨域上异常一致。Hamilton 1921 (英军) 3-6、Graicunas 1933 数学上限 4-6、Miller 1956 工作记忆 7±2、Cowan 2001 修正 4±1、OPNAVINST 海军规章 3-7、美军基层单位 2-7 (高层 7-10)、Amazon two-pizza 5-10、Spotify squad 8-10、Dunbar inner circle 5 / sympathy group 15。四条独立证据链 (军事、组织、认知、工作记忆) 指向同一数字,背后是三重锚点:工作记忆容量、关系复杂度 n(n-1)/2、注意力经济。这不是巧合而是硬约束。

第三个原则是 Commander's Intent / Auftragstaktik 的决定性作用。Moltke 1869 年《高级指挥官指令》的核心论断:"The higher the authority, the shorter and more general will the orders be. The next lower command adds what further precision appears necessary." 顶层设定 what + why,越往下越补充 how。这是一种认识论而非 management style:战场的不确定性随时间和层级指数增长,所以命令的精确度应该随层级下降而增加。Auftragstaktik 的关键约束也清晰:它依赖军官共享教育背景,没有共享教育会退化为放任。普鲁士军事学院体系是 Auftragstaktik 得以运作的物理基础设施,Moltke 标准化的参谋部和情报传递是第二层基础设施。

失败案例贡献了同样重要的洞察。Waterfall 被误读是文档认知失败的教科书:Royce 1970 原文明确警告 "I believe in this concept, but the implementation described above is risky and invites failure",但后续者只引用了 Figure 2 的严格线性版本,剥离了警告和五项迭代修改建议。Healthcare.gov 和 NHS NPfIT 两个价值数百亿美元的公共 IT 项目失败原因高度同构:缺失 commander's intent、span of control 被突破、信息隐藏边界被集中化破坏。Spotify model 是 autonomy without alignment 的经典反例:白皮书说的是 Aligned Autonomy,但 Spotify 只交付了前半部分,Anders Ivarsson 后来承认原计划的 autonomy/alignment/accountability 三篇系列只写了第一篇。

对 agent 编排的启示在第八章集中讨论,这里仅给出最精炼的一条:Auftragstaktik 的成功依赖军官共享教育背景。没有共享教育的 Mission Command 会退化为放任。这直接对应"sub-agent 在缺少 rules 文件注入时的 40% 合规率"问题。解法不是写更详细的任务 prompt,而是确保每个 sub-agent 先读 SOUL.md / USER.md / COMMUNICATION.md 建立 shared understanding。这是普鲁士传统最值得移植的一面。

二、软件工程方法论:从按步骤切到按决策切

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

D. L. Parnas 在 Communications of the ACM 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) 索引系统对比两种分解方案。

第一种分解按处理步骤 (当时的模块化编程常识):Input → Circular Shifter → Alphabetizer → Output → Master Control。每个模块对应流水线一个阶段,直觉自然,但 Parnas 指出这种分解在面对以下任一变化时会同时波及多个模块:输入格式改变;内存中行存储表示改变 (字符数组 vs 压缩编码);是否预先计算所有 circular shifts (时间换空间策略);字符内部编码改变。

第二种分解按所隐藏的设计决策:Line Storage 封装行的内部存储实现;Input 只负责读入并调 Line Storage;Circular Shifter 封装 circular shift 的实现策略 (可预计算也可 on-demand 计算);Alphabetizer 封装排序策略;Output 封装输出格式。

原文核心段落 (经 Northeastern tech report PDF 抽取):

Parnas 声称的三个好处:管理学收益 (分离的团队独立工作,沟通需求少且事后也很少后悔当初沟通得不够多);产品灵活性 (可以在一个模块内部做相当大的改动而不波及其他);可理解性 (可以一次只研究一个模块)。失败边界:如果预期的将来要变的设计决策与实际变的不一致,信息隐藏反而加重复杂度——模块间的边界画错了地方。Parnas 本人强调 "The effectiveness of a modularization is dependent upon the criteria used in dividing the system into modules."

来源:Parnas, D. L. (1972). CACM 15(12): 1053–1058. DOI:10.1145/361598.361623。完整 PDF: Northeastern tech report

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。原文:"[...] each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity."

第二系统效应 (第 5 章):一个人设计第二个系统往往比第一个危险,因为第一个系统成功带来的自信让他把第一版里克制掉的想法一起塞进来,造成过度工程。原文:"This second is the most dangerous system a man ever designs."

来源: Brooks, F. P. (1975, 1995). The Mythical Man-Month, Addison-Wesley. Michigan PDF

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

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

Conway 给出的不是口号而是数学陈述:系统的结构图 (把每个子系统当作节点) 和设计组织的沟通结构图 (把每个设计小组当作节点) 之间存在一个 homomorphism (同态映射)。原文:"This kind of a structure-preserving relationship between two sets of things is called a homomorphism. Speaking as a mathematician might, we would say that there is a homomorphism from the linear graph of a system to the linear graph of its design organization."

Conway 对"项目人数是加法"这个假设明确反驳 (早于 Brooks's Law 七年):"Assuming that two men and one hundred men cannot work in the same organizational structure [...] our homomorphism says that they will not design similar systems; therefore the value of their efforts may not even be comparable. [...] Assumptions which may be adequate for peeling potatoes and erecting brick walls fail for designing systems."

Conway 的推论至今支撑 Amazon two-pizza team、inverse Conway maneuver (为拿到想要的系统结构先调整组织结构) 等实践。来源:Mel Conway 个人主页 PDF

2.4 SOLID 的 SRP 与 DDD

Robert C. Martin 的 Single Responsibility Principle 最初被表述为 "A class should have only one reason to change." 这句话被大量误用,Martin 在 2014 年的博客澄清:"Gather together the things that change for the same reasons. Separate those things that change for different reasons." 更精确的表述:"A module should be responsible to one, and only one, actor." 这里的 actor 指请求修改的角色或利益相关方。这个修正把 SRP 从"颗粒度规则"矫正回 Parnas 早已给出的"按变化原因分解"。thevaluable.dev 2022 年的分析直接指出 SRP 是 Parnas criterion 的一个弱化版本。

Eric Evans 2003 年的 Domain-Driven Design 提供了以业务领域为分解依据的方法。核心概念:Bounded Context 是特定术语和规则一致生效的范围 (跨 context 的同名术语必须显式翻译);Aggregate 是一组必须一起变更的实体,由 aggregate root 统一对外交互;Ubiquitous Language 让模型和代码共用同一套领域术语。DDD 的分解依据是业务语义一致性,与 Parnas 的设计决策、SRP 的变化原因殊途同归——都是让变化局部化,但 DDD 把变化源定位在业务领域演化而不是技术决策。Evans 在 DDD Europe 2019 keynote 补充:subdomain 是业务视角的分解,bounded context 是技术视角的分解,两者理想情况重合但常常错位。

2.5 Bezos two-pizza team 与微服务

Amazon 2001 年前后从单体迁到微服务,团队尺寸被 Jeff Bezos 约束为"两个 pizza 吃得饱"。AWS 自己的白皮书:"We decoupled our monolithic architecture into a vast network of single, standalone services. [...] This allows two-pizza teams to spend more time focusing on their customers, and constantly experimenting and innovating on their behalf." Fowler 的 TwoPizzaTeam bliki 强调两个 pizza team 的关键属性不是 size 而是 outcome-oriented (按业务产出组织) 而非 activity-oriented (按职能组织)。Conway 的 homomorphism 在此直接生效:要让微服务之间耦合松,组织之间的沟通就必须对称地松。

Two-pizza 的完整设计不只是规模,还包括 single-threaded ownership:一个团队只管一个服务或产品线,不跨多个服务。配合 Bezos 的 API 强制令 (任何内部团队之间只能通过明确的 API 交互,不允许绕过),Amazon 把公司变成了"一台制造机器的机器" (a machine that makes the machine)。

背后的认知科学三层依据:Ringelmann 效应 (社交懒散) 显示个体贡献随团队规模增加而下降 (Latané 蒙眼戴耳机喊叫实验,6 人组只发出相当于个体 36% 能力的音量,控制协调损失后仍只有 74%);Hackman 的沟通通道研究 (n(n-1)/2 增长);Bezos 的反直觉观点:"Communication is a sign of dysfunction. It means people aren't working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more."

2.6 Strangler Fig 与 Saga:分解的过渡工具

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

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

三、科学管理与工业分工

3.1 Taylor 1911:把动作切到原子

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

Taylor 四原则:科学任务分配 (每个工作元素有科学依据);人员筛选与培训 (科学选人);管理与工人协作;分工 (管理者和工人各负其责,管理层承担规划、工人承担执行)。Taylor 本人的案例 (Bethlehem Steel 搬运生铁):通过时间动作研究把搬运动作的每一个分解步骤重新设计,日产量从 12.5 吨提升到 47 吨。

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

3.2 Fordism 与 TPS:流水线分工的极限与回调

Henry Ford 把 Taylor 的动作分解嵌入机械化流水线:Highland Park 工厂的 Model T 装配时间从 12 小时降到 93 分钟。但社会学副作用严重,UMich Auto-Life 的 Degradation of Work 档案:"[The Ford system] completely transformed the various work tasks and work routines of Ford workers and created the repetitive, monotonous, and alienating work of the modern industrial world." Fordism 的失败点是过度分解:工人丧失全局视角,质量问题只在下游被发现,返工成本极高。

Taiichi Ohno 与 Eiji Toyoda 1948-1975 间发展的 Toyota Production System (TPS) 对 Fordism 做了关键回调:Jidoka (自働化) 机器/工人有权随时停下线,Type-G 自动织机 1924 年就能在线断时自动停机,让问题立即可见而不是流到下游;Takt Time 根据客户需求节拍而非机器极限来设定产线速度;Kaizen (改善) 持续改进每个工位的工作方式,让工人参与分工设计;Poka-Yoke (防错设计) 让做错变得物理上不可能。TPS 的分解哲学是动作仍然要细,但"谁来决定动作怎么切"这个权力要部分还给工人,并且要留下整体就地止血的机制。这是对 Taylorism 的一次结构性修正而不是推翻。

3.3 Theory of Constraints:分解之外的瓶颈思维

Eliyahu M. Goldratt The Goal (1984) 核心论断:每个系统都有一个约束,系统整体吞吐由这个约束决定,对其他环节的优化都不会提升整体吞吐——甚至可能让事情变糟。Five Focusing Steps:Identify the constraint / Exploit it / Subordinate everything else to it / Elevate the constraint / Repeat。

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

四、项目管理的分解方法

4.1 Work Breakdown Structure (WBS)

WBS 源自 1960 年代美国国防部 DSARC 程序,PMI PMBOK 定义为 "a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables."

两条核心规则:100% Rule 每一层分解必须覆盖父节点 100% 的工作量 (不能有遗漏也不能有重复);8/80 Rule 最底层 work package 的工作量应在 8-80 工时之间 (<8 说明切得太碎,>80 说明还要继续分)。WBS 是 deliverable-oriented 而非 activity-oriented:优先按交付物分,而非按活动分。这与 Fowler 对 two-pizza team "outcome-oriented"的强调是同一逻辑。

4.2 INVEST:story 粒度的经验规则

Bill Wake 2003 年在 XP Magazine 提出的 INVEST 约束 user story 的写法:Independent (story 间尽量无依赖);Negotiable (对话起点而非契约);Valuable;Estimable;Small (小到一个 sprint 内能完成);Testable。INVEST 的本质是给分解粒度提供六个互相制约的维度。

4.3 Critical Path Method

CPM 由 DuPont 的 M. R. Walker 与 Remington Rand 的 J. E. Kelly 1957 年前后发展;PERT 同期由美国海军 Polaris 导弹项目与 Booz-Allen 合作开发。两者都把项目建模为有向图:节点是任务,边是依赖关系。CPM 核心贡献是给分解后的子任务补上缺失的一环——它们之间的时间依赖关系。关键路径 (critical path) 是从起点到终点的最长路径,决定项目的最短工期。非关键路径任务有 float (浮动时间),可以在不影响整体工期的前提下挪动。

4.4 Waterfall 被误读的原始论文

Winston W. Royce 1970 年在 IEEE WESCON 发表的 Managing the Development of Large Software Systems 常被当作 waterfall 鼻祖,但读原文会发现 Royce 明确批评了 Figure 2 的流水线结构:

Royce 后面给出五条补救:Do it twice (Prototype);Plan, control and monitor testing;Involve the customer;迭代而非一次过;文档化的验证。PMWorld Journal 2018 年 Johnny Morgan 的重读引用 Girvan & Paul:"Unfortunately, Royce's paper was widely misunderstood. He presented the above model as 'risky and invites failure' and was proposing modifications to make it much more iterative and incremental. However, that element of his work is largely forgotten, and his waterfall picture remains in common use."

这个历史本身就是文档认知失败案例:原作者明确标注了警告,但后继者从插图中抽取了结构而丢弃了警告。对文档与 agent 编排的启示都是:任何设计文档都会被后续读者简化,所以警告必须嵌入结构本身而不是注释。

来源:Royce 1970 原论文 PDF

五、军事指挥链与任务分权

5.1 拿破仑军团制 (Corps d'Armée):决策权的前移

拿破仑不是军团制的发明者 (Bourcet、Guibert 18 世纪末已提出类似构想),但他是第一个把军团变成常设编制并贯通指挥、情报、后勤的人。Saber and Scroll Journal 的分析:"Each Corps was essentially a miniature army; each possessed cavalry, artillery and infantry and each was large enough that it could fight independently until another Corps could come to its support."

核心设计原则四条:

每个军团都是自足的小型军队,包含步兵、骑兵、炮兵、参谋,一个典型军团约 28,000 人。这意味着任何一个军团在等待援军的一天之内不会被完整消灭。

军团之间保持不超过一天行军距离,形成可相互支援的网络。这是弹性耦合的拓扑:既不是集中兵力也不是散落兵力。

centralized control with decentralized operations。Napoleon 在整体上保持指挥权 (选取目标、决定主力方向),但把战术执行下放给军团指挥官,让他们根据本地情报自己决定走哪条路、何时投入战斗。

信息系统层面。Napoleon 建立了以 Berthier 为核心的参谋部,标准化了情报传递与命令格式。这是 Auftragstaktik 得以运作的物理基础设施:没有标准化的消息通道,再好的放权理念也不能落地。

来源:Naval Postgraduate School Calhoun

5.2 Auftragstaktik:普鲁士-德意志传统

Auftragstaktik 字面意思是任务战术 (Auftrag = 任务, Taktik = 战术)。一个关键事实:Moltke 本人从来没用过 Auftragstaktik 这个词,这个术语首次出现在德意志军队正式文件中是在二战前后。Moltke 只区分两种命令:Befehl (详细指令) 和 Weisung (指示/意图)。

Moltke 1869 年《高级指挥官指令》(Instructions for Large Unit Commanders) 的核心段落:

这段话的深刻之处在于它不是在讲 management style,它是在讲一种认识论:战场的不确定性随时间和层级指数增长,所以命令的精确度应该随层级下降而增加而不是相反。顶层设定 what 和 why,越往下越补充 how。

Wikipedia 对 Mission-type tactics 的描述捕获了另一个关键约束:"Building a high level of trust, competency and understanding is crucial for the success of such a doctrine." Auftragstaktik 不是一个可以即插即用的方法,它依赖漫长的军官教育投资。Moltke 同时代做的另一件重要事情是建立普鲁士军事学院体系,让军官之间形成共同的战术语言。失去这层公共认知,放权会直接变成混乱。

5.3 现代美军 ADP 6-0 的 Mission Command

美军 1986 年 FM 100-5 首次正式纳入 mission orders,2012 年 ADP 6-0 正式命名为 Mission Command。2019 年修订版的七条原则:Competence (能力)、Mutual trust (相互信任)、Shared understanding (共享理解)、Commander's intent (指挥官意图)、Mission orders (任务式命令)、Disciplined initiative (守纪的主动性)、Risk acceptance (风险接纳)。

ADP 6-0 对 mission orders 的定义:"Mission orders are directives that convey the commander's desired end state, but not the method by which to achieve them. In other words, these orders are not prescriptive in nature."

National Defense University Press 的 "Beyond Auftragstaktik: The Case Against Hyper-Decentralized Command" 指出,把 mission command 等同于极度去中心化是危险的误读。真正的 Moltke 传统是一种有节制的去中心化。

来源:ADP 6-0 原文

5.4 Boyd 的 OODA Loop 与 Organic Design

John Boyd 1970 年代研究朝鲜战争 F-86 vs MiG-15 交战记录 (F-86 胜率 10:1),发现优势不在飞机性能而在飞行员能更快 Observe-Orient-Decide-Act 的能力。Boyd 推广为普遍冲突理论:能够进入对手 OODA 循环内部、比对手更快完成一个周期的一方,就能制造混乱并取得优势。

Boyd 的 Organic Design for Command and Control (1987) 比 OODA 更深刻的地方是 Orientation = Schwerpunkt 这个论断:"Orientation is the Schwerpunkt. It shapes the way we interact with the environment—hence orientation shapes the way we observe, the way we decide, the way we act." Orientation (方向感) 不是简单的情境感知,而是基因遗传、文化传统、过往经验、当前情境的交互投射。Boyd 认为它是决定性环节。Observe 只是采集原始数据,Decide 和 Act 只是下游结果,真正的胜负在于你如何 orient。

5.5 Span of Control 的军事来源

Span of control 概念由英国将军 Sir Ian Hamilton 1921 年的《The Soul and Body of an Army》首次提出。Hamilton 基于对英军指挥官的观察总结:"leaders could not effectively control more than three to six people." Graicunas 1930 年代从数学上深化:relationships 复杂度不是线性增长而是指数增长。一个主管管 4 个下属有 44 种关系,管 6 个下属则有 222 种关系。

美军现代实际编制的数据:

• Infantry Squad Leader (9 人) → 2 个直接下属
• Infantry Platoon Leader (38 人) → 6 个直接下属
• Infantry Company Commander (130 人) → 7 个直接下属
• Infantry Battalion Commander (700 人) → 9 个直接下属
• Brigade Commander (3,000 人) → 10 个直接下属

一线战斗单位 (班、排) 的 span 最窄 (2-6),因为需要高度的战场协调;越往上走 span 可以扩大到 9-10,因为协调性质从实时战术转为策略规划。

美国海军 OPNAVINST 3120.32D 直接写入规章:"Ordinarily, a supervisor should be immediately responsible for not less than three or more than seven subordinates."

六、组织理论

6.1 Mintzberg 的五种组织配置

Mintzberg (1979-1983) 提出五种结构原型:

Mintzberg 的核心洞察:协调机制决定了结构。Simple Structure 通过人直接看着人来协调;Machine Bureaucracy 通过标准化流程;Professional Bureaucracy 通过标准化技能 (医生不需要老板盯着,他们的医学院训练已把流程内化);Adhocracy 通过面对面相互调适。你不能选了一个松散的 agent 网络结构,却期望它像 Machine Bureaucracy 一样通过标准化流程自动协调。每种结构带来自己的失败模式。

6.2 Matrix Organization 的失败案例

矩阵组织 (同时按功能和项目分工) 在 1970-1990 年代被 Philips、ABB、Digital Equipment 等跨国公司广泛采用。Eric Viardot 的评估:"Matrix structure usually ends in failure because it accrues more disadvantages than advantages when compared to divisional and functional models."

具体失败模式 (Leadership Edge 研究):

双重汇报链 (dual reporting):一个员工同时向项目经理和职能经理汇报,两人指示冲突时员工陷入瘫痪。研究显示 87% 的中层经理和 23% 的高层经理把"角色与责任不清"列为矩阵组织的核心问题。

责任与权力错位:HR 可能有全球政策的责任,但没有在各区域实施的权力。这种结构天然制造政治斗争。

绩效评估困难:员工参与多个项目、向多个经理汇报,没有哪个经理能独立评估其表现。

矩阵组织失败的根因是它违反了 Fayol 从军事中继承的 unity of command 原则:一个下属不应同时向多个上级汇报。现代解法通常是让一条链硬、另一条链软 (dotted line),或者引入 matrix guardian 这样的制度化协调角色。

6.3 Spotify Model:从神话到自我批判

2012 年 Spotify 的 Henrik Kniberg 和 Anders Ivarsson 发表的白皮书介绍 Squad / Tribe / Chapter / Guild 四层结构:Squad 8-10 人跨职能自组织团队负责一个产品切片;Tribe 相关 squad 集合约 100-150 人 (Dunbar 上限);Chapter 同一职能域的横向社区;Guild 跨部落兴趣社群。

2020 年前 Spotify 产品经理 Jeremiah Lee 发表 "Spotify's Failed #SquadGoals",系统揭示这个模型根本没按白皮书描述的方式运作过。核心摘录:

失败原因 (Lee 和后续分析):

Autonomy 没有对应的 alignment。白皮书说的是 Aligned Autonomy,但 Spotify 实际只交付了前半部分。Anders Ivarsson 后来承认原计划的 autonomy/alignment/accountability 三篇系列只写了第一篇。

Chapter Lead 同时要做技术导师和人员经理。这两个角色本质矛盾:技术导师关心代码,人员经理关心人的成长。一个 Chapter Lead 要管理分布在多个 squad 的工程师,不共事的情况下根本没有依据评估绩效。

协调成本随 squad 数量指数增长。10 个 squad 时最小化依赖可能,到 100 个 squad 时一切相互依赖。

Cool-sounding names 的诅咒。Squad / Tribe / Chapter / Guild 看起来像《权力的游戏》,但对试图复制的公司把本来可以用 team/department/functional area/interest group 这些标准词汇理解的东西神秘化了。结果是公司复制了结构没复制文化。

Jeremiah Lee 的尖锐总结:"It was not really agile. It was just not waterfall." 去掉旧的控制结构如果没有新的协调机制填入,组织会陷入结构性混乱。

来源:Jeremiah Lee 原文

6.4 Coase 的公司边界理论

Ronald Coase 1937 年《The Nature of the Firm》提出的根本问题:如果市场通过价格机制就能协调经济活动,为什么还需要公司这种内部协调的组织存在?他的答案是 transaction cost:市场有发现价格、谈判合同、执行合同的成本,公司内部则有信息流、激励、监督、绩效评估的成本。公司的边界由这两类成本的边际相等决定。

Williamson 1975 年的扩展:当资产专用性 (asset specificity) 高、契约不完备时,市场交易容易遭遇 hold-up 问题,这时纳入公司内部更优。

七、认知科学中的分解

7.1 Sweller 的认知负荷理论

John Sweller 1988 年提出的 CLT 把工作记忆的负荷分为三类:Intrinsic load 任务本身的内在复杂度,由元素交互度决定,只能通过学习者专业化程度来缓解;Extraneous load 由不良教学或呈现方式引入的额外负荷,纯粹有害应被削减;Germane load 用于把新信息整合进长期记忆中的 schema 的有效认知努力。2010 年 Sweller 的修订把 germane load 重新定义为 intrinsic load 的一部分,不是独立来源。

CLT 对任务分解的直接启示:工作记忆容量是硬约束。Miller 的 7±2 或 Cowan 的 4±1 都说明人类同时持有的元素数量极有限。任务分解的目的不仅是把工作切小,更是降低每一步的 element interactivity,让专家可以通过 schema 识别快速处理。

7.2 Chase-Simon 的 Chunking 实验

1973 年 Chase 和 Simon 的经典棋盘实验:让象棋大师、熟练棋手和新手分别观察 5 秒棋局然后复盘。合法残局:大师可复盘约 20-25 颗棋,熟练者 10-15 颗,新手 4-6 颗。随机摆放:三组表现几乎一样,都在 4-6 颗。

解释:大师并没有更好的短期记忆容量,他们记忆的是 chunk (有意义的模式团)。Simon 和 Gilmartin 估计一个象棋大师在长期记忆中持有 10,000 到 100,000 个 chunks (文献常引 50,000)。识别出一个 chunk 后,大师会用一个指针在工作记忆中代替整块内容,从而突破了 7±2 的限制。

这个实验对任务分解的启示非常深:专家和新手面对同一个任务时,适合的分解粒度是不同的。对专家合适的一步可能包含几十个新手需要独立处理的细节。把一个任务切到原子级别其实可能会破坏专家的 chunk 识别能力,反而让他更慢。这是为什么好的工程组织会区分 junior 和 senior 的 ticket 粒度。

7.3 Hutchins 的分布式认知

Edwin Hutchins 1995 年《Cognition in the Wild》记录了他在美国海军 USS Palau 上观察导航团队的民族志研究。核心论点:"the navigation team can be seen as a cognitive and computational system... cultural activity systems have cognitive properties of their own that are different from the cognitive properties of the individuals who participate in them."

Hutchins 提出认知过程的三种分布:分布于社会群体成员之间;分布于内部心智与外部结构之间 (人与工具/环境的耦合);分布于时间中 (早期事件的产物改变后期事件的性质)。在 Palau 的实际案例中,没有任何一个船员掌握导航的全部知识。海图、罗盘、三角板、通话线路、笔记本、记录员、观察员、舵手、船长,是一个整体的认知系统。即使船长临时退出,这个系统仍能完成导航——因为知识和计算已经被嵌入到工具和程序中,不依赖任何单一头脑。

7.4 Hierarchical Task Analysis (HTA)

HTA 是人因工程和 HCI 领域的经典任务分析方法 (Annett & Duncan, 1967 起源)。核心步骤:识别主任务目标;把主目标分解为 sub-operations,附带 plan 说明执行的条件与顺序;对每个 sub-operation 决定是否进一步分解;迭代;分析分解以发现任务操作的低效;建议改进。

HTA 的停止规则是 P × C:在某一粒度上,继续分解的代价 C 超过从中获益的概率 P 乘以获益大小时,应停止。示例:

0. 清洁房子
1. 取出吸尘器
2. 装上合适的吸头
3. 清洁房间
   3.1 清洁走廊
   3.2 清洁起居室
   3.3 清洁卧室
4. 清空集尘袋
5. 收起吸尘器

Plan 0: 依次做 1,2,3,5; 集尘袋满时做 4
Plan 3: 按需做 3.1, 3.2, 3.3 任意顺序

Plan 0 的"集尘袋满时做 4"是一个条件触发,这是把状态监测耦合到分解中的经典做法,在 agent 编排中高度相关。

八、分解失败的 Post-Mortem

8.1 Healthcare.gov 的崩溃 (2013)

2013 年 10 月 1 日 Healthcare.gov 启动当天只有 6 人成功注册。到问题修复,美国政府花费超过 6.3 亿美元。GAO 和多个独立审计报告揭示的失败模式:

契约碎片化。总承包商 CGI 下有 16 个官方子承包商,加起来 55 个以上的契约方,"no focal point for project responsibility and accountability"。

压缩测试窗口以保政治截止日期。内部 CMS 报告和 McKinsey 外部咨询都警告需求仍在变化、测试时间不足。管理层把必要的 7 个月端到端测试压缩到 1 个月。

权力分裂。Forbes 报道:"three different parts of the bureaucracy contending for control—the IT shop, the policy shop, and the communications shop—key decisions were often delayed, guidance to contractors was inconsistent, and nobody was truly in charge."

不现实的需求工程。75 屏幕的流程、1000+ 屏幕的完整系统、5 个联邦机构 + 36 个州 + 300 家保险商 + 4000+ 保险计划。没有分层的信息隐藏,一个用户请求要穿透整个协作矩阵。

Anthopoulos 等人在 Government Information Quarterly 的学术分析把失败归因到 PMBOK 九大知识域的每一个都出了问题,其中 scope management 和 communications management 是重灾区。根因诊断:Healthcare.gov 把 55 个团队组织在一起,但缺乏军事 Auftragstaktik 式的"共享意图 + 明确接口"。CMS 既不扮演 commander 也没有确立 commander's intent,于是每个承包商按自己的理解工作,最后集成阶段发现互不兼容。

8.2 UK NHS NPfIT / Connecting for Health (2002-2011)

英国 National Programme for IT 预算 60 亿英镑,最终花费超过 100 亿英镑,是公共部门 IT 项目史上最昂贵的失败之一。英国下议院 PAC 委员会 2013 年定性为 "one of the worst and most expensive contracting fiascos in the history of the public sector"。

剑桥大学 Ross Anderson 等人 2014 年 post-mortem 论文记录的多层失败:

中心化集采破坏既有系统。NPfIT 只资助两个主要软件供应商 (Cerner Millennium 和 Lorenzo) 的新软件,不资助各医院 Trust 自己既有软件的维护。很多医院被迫停止自己能正常运作的系统去等待 NPfIT 交付,而 NPfIT 迟迟不来。

强势项目总监模式的反噬。项目总监 Richard Granger 有强烈个性,可以说既是优势也是诅咒。强势领导在项目初期推动决策,但一旦项目出问题后没有足够的 check and balance 能力挑战他的判断。

忽视一线用户。医生和 GP 从项目启动就表达担忧,认为系统不符合临床工作流,但这些反馈在集中化决策中被屏蔽。最终上线的系统 "slow, cumbersome, insufficiently explained and poorly implemented"。

供应商之间的互联失败。NPfIT 架构假设供应商会顺利集成,但 Fujitsu 退出、CSC 陷入合同纠纷、Accenture 持续性能问题。

PAC 委员会的总结:"it was a failure of management for the NHS to have got itself in that mess with its supplier." NPfIT 和 Healthcare.gov 高度相似。核心都是 over-centralization without commander's intent:架构上试图统一,但没有建立统一所需的共享认知、信任和接口标准。

8.3 SAFe 的结构性批评

Scaled Agile Framework (SAFe) 是全球最流行的规模化敏捷框架 (State of Agile 2020 报告中 37% 采用率),但在敏捷专家社区中广受批评。Steve Denning 在 Forbes 2019 年的文章直接定性:

Willem-Jan Ageling 的系统性批评提出 SAFe 的结构性问题:类瀑布式的 PI (Program Increment) 8-10 周的计划周期远长于 Scrum 的 2 周 sprint,已经失去 agile 的短反馈特性;角色过度规定 (Release Train Engineer、Product Manager、Business Owner、System Architect、Release Management、Portfolio Manager 多层角色) 本质是 Machine Bureaucracy 的敏捷包装;客户缺席违反了敏捷宣言的 "customer collaboration over contract negotiation"。

SAFe 流行的真正原因:它让企业管理层能同时保留现有的集中化控制结构又能声称自己敏捷。这是现代的 Mission Command 失败案例——用程序语言取代了意图语言。

8.4 Netscape 大重写与 Microsoft Longhorn

Netscape 6.0 (1998-2000):1998 年 Netscape 决定从头重写 Navigator。Joel Spolsky 2000 年《Things You Should Never Do, Part I》:"They [Netscape] did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." Joel 的核心洞察:"It's harder to read code than to write it." 那些看起来难看的边角代码往往是针对真实 bug 的硬解,扔掉就意味着把所有 bug 重发现一遍。Netscape 3 年没出 5.0,6.0 发布时 IE 已经吃掉市场,公司随后被收购。这是 Brooks Second-System Effect 在商业层面的完整演绎。

Microsoft Longhorn (2001-2007):原计划在 XP 和未来 Windows 之间做跨代跳跃 (WinFS 新文件系统、Avalon 新 UI、Indigo 新通信子系统)。2004 年 8 月微软宣布 reset,用 Windows Server 2003 SP1 代码作为新基线重启,最终在 2007 年交付大幅削减的 Vista。失败原因:scope creep (各组件目标不断增加);codebase Frankenstein (新功能叠在旧代码上,文档缺失);组织结构与系统结构冲突 (各组各自加东西,Conway's Law 体现为团队边界把设计撕碎);中层管理阻断反馈。

8.5 Brooks No Silver Bullet:本质复杂度不可消除

Brooks 1986 年的 No Silver Bullet 把软件复杂度分为:Essential (本质) 问题本身的复杂度,包括 complexity、conformity、changeability、invisibility 四个属性;Accidental (偶然) 来自当前实现手段的复杂度 (语言、工具、调试流程等)。

Brooks 原文:"The essence of a software entity is a construct of interlocking concepts [...] The complexity of software is an essential property, not an accidental one. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence."

分解可以降低 accidental complexity (把大模块切成易管理的小模块),但无法降低 essential complexity。任何声称"只要分得好就能让一切变简单"的方法论都会在 essential complexity 面前破产。

8.6 Distributed Monolith:微服务过度分解

2010 年代后期大量企业采纳微服务后出现 distributed monolith 反模式:服务数量急剧增加但耦合度没变,只是把原来的内存调用换成网络调用,延迟和故障率双双上升。2025 年 CNCF 调查显示 42% 采纳微服务的组织正在整合回来 (此数据仅见 LinkedIn 单方引用,原始调查报告未交叉验证)。AWS 自身某个视频处理管线从 Step Functions + Lambda + S3 的分布式架构回到单 ECS task 的单体,成本下降 90%。失败的共同模式:共享数据库导致服务间紧耦合;跨服务事务频繁被迫引入 Saga 等复杂补偿机制;服务过细 (chatty microservices) 让网络开销吞掉业务时间;运维复杂度超过团队承载力。

九、跨域同构:共同的成功与失败模式

从前述所有维度的材料中,可以提炼出贯穿军事、组织、认知、软件的共同模式。这些模式既解释了为什么成功实践彼此相似,也预测了分解失败的共同触发条件。

9.1 Parnas Information Hiding 作为万能原则

信息隐藏原则的跨域投影:

失败案例的共同反模式:Healthcare.gov 55 个承包商之间没有明确的信息边界;NHS NPfIT 全国统一软件强迫所有 Trust 暴露内部流程;Matrix org 双重汇报链暴露员工的任务到两套政治结构;SAFe 规定的程序语言强迫团队暴露执行细节到程序层面。

9.2 Span of Control 3-7 的跨域一致性

背后的三重锚点:工作记忆容量 (Miller 7±2 或 Cowan 4 chunks);关系复杂度 n(n-1)/2 的组合爆炸;注意力经济 (人类总时间有限,每个关系都需要维护)。跨领域一致的范围 3-7 正好对应单个指挥者同时实时跟踪的硬上限。7-10 出现在更高层级,因为协调由中层做了大量处理。Dunbar 15 是亲密关系上限,150 是认知网络上限。

9.3 人类分解失败的五大模式

从 Spotify、Healthcare.gov、NHS NPfIT、SAFe、瀑布模型误读等案例中提炼的共同反模式:

模式 F1:过程分解冒充结构分解。Royce 1970 论文 Figure 2 按时间阶段分解被误读为按模块分解;Parnas 的一生工作都在反对这种做法。分解依据应该是"预期会变的决策"而非"处理流程步骤"。

模式 F2:缺失 Commander's Intent。Healthcare.gov 的 55 个承包商没有共同的 desired end state;NHS NPfIT 的中心化供应商之间缺乏意图层面的对齐;Spotify 的 squad 各自优化本地目标,丢失全局目标。

模式 F3:Autonomy 与 Alignment 失衡。Spotify 把白皮书的 Aligned Autonomy 砍半;Matrix org 给员工多重自由度但没对应的协调结构;SAFe 相反 alignment 过度而 autonomy 被稀释。

模式 F4:Span of Control 被突破。Healthcare.gov 的 CMS 直接协调 55 个承包商;NPfIT 项目总监一人承担了本应分层的信任结构;Spotify 的 Chapter Lead 跨 squad 管理让信任链断裂。

模式 F5:信息隐藏边界被暴露。Matrix dual reporting 让员工的任务对多方透明;NPfIT 的全国统一软件让每个 Trust 暴露内部流程;Healthcare.gov 的屏幕流把五个联邦机构的协调暴露给终端用户。

9.4 成功分解的四个共同条件

从 Napoleonic corps、Auftragstaktik、Two-pizza、HTA、Parnas 抽象的共同成功条件:

意图透明,细节隐藏:上层明确 what + why,下层自主决定 how。

Span of control 受认知容量约束:3-7 范围内保持决策者有效,超过引入中层协调者。

标准化的接口而非过程:协调机制是 API/protocol 而非工作流程。

冗余但不浪费的拓扑:军团之间互相支援但不重复执行。

这四条构成任何跨域任务分解系统的必要条件,缺一即触发某类失败模式。

十、方法论对比总览

整合前述所有方法论的对比表:

十一、对 Agent 编排的启示

本章用户关注的跨域同构焦点。以下映射经过审慎对照,不强行拉扯。

11.1 Commander's Intent 是唯一可跨层级传递的东西

从 Moltke 到 ADP 6-0 到 Bezos,所有成功分解的共同特征是高层只传达 what + why + desired end state,不传达 how。执行细节必然在下层动态确定,因为只有下层掌握本地信息。对 agent 编排的直接映射:给 sub-agent 的 prompt 应该用 2-3 句话说清楚任务目标、成功标准、约束边界,剩下的交给 sub-agent 的自主工具调用决定。把 prompt 写成 50 步 checklist 等于把 Mission Command 退化回 Jominian centralization,同时损失速度和适应性。

11.2 Span of Control 的 3-7 数字是认知硬约束

军事、管理、认知科学、工作记忆研究四条独立证据链都指向 3-7。对 agent 编排的直接映射:一个 orchestrator agent 应该同时管理不超过 7 个 worker sub-agent,超过必须先做二级分解——不是线性增加 sub-agent,而是引入 middle-manager agent 做二层调度。Healthcare.gov 的 55 承包商和 NPfIT 的集中供应商网络都是这一原则的失败案例。

11.3 Information Hiding 是所有成功分解的底层结构

Parnas 1972 年的观察:按流程分解 (decomposition 1) 脆弱,按"隐藏可能变化的决策"分解 (decomposition 2) 稳健。对 agent 编排的直接映射:sub-agent 的中间思考、工具调用顺序、内部尝试不应被主 agent 或其他 sub-agent 窥视,只应传递最终结论和未决不确定性。否则沟通通道爆炸会触发 Brooks 定律的 n(n-1)/2 沟通开销。

Information Hiding 在 agent 编排中的边界与风险:Parnas 前提是"接口比实现稳定"。在 LLM 场景中 prompt 本身常常不稳定 (模型升级会让相同 prompt 行为变化),可能需要用结构化输出 (JSON schema) 作为更硬的接口。Conway's Law 在多 agent 系统中依然生效:orchestrator 的任务分配结构与问题的天然结构不匹配,最终产出会反映 orchestrator 的分配结构而不是问题本身。

11.4 Auftragstaktik 的前提是共享教育

Auftragstaktik 成功依赖军官共享教育背景,没有共享教育会退化为放任。Moltke 同时代建立普鲁士军事学院体系,让军官之间形成共同的战术语言,是 Auftragstaktik 的物理基础设施。

对 agent 编排的直接映射:在派出 sub-agent 前必须让其读 rules/SOUL.md、rules/USER.md、rules/COMMUNICATION.md 等文件,建立 shared understanding。这不是形式主义,相当于普鲁士军事学院建立的共同战术语言。sub-agent 的 40% 合规率问题不是 prompt 不够详细的问题,是 shared education 缺失的问题。解法不是写更长的 prompt 而是系统级 --append-system-prompt 注入根基。

11.5 Spotify 失败对 agent 自主度的警示

Spotify 失败的根因是 autonomy without alignment。给 sub-agent 自由度前必须先建立 alignment 机制。如果不读取 rules/ 文件就派出 sub-agent,等于在给一个陌生士兵发战场自主权。

ADP 6-0 的七条原则中,四条直接对应 agent 编排的成功条件:Competence → sub-agent 的模型能力必须匹配任务复杂度 (Haiku 不适合做架构决策);Shared understanding → sub-agent 必须读过 workspace rules;Commander's intent → 任务 prompt 应明确 why 和 desired end state;Mission orders → 任务 prompt 应避免过度规定 how。

11.6 HTA 模板直接可用

HTA 的结构对 agent 编排是范本:顶层目标 → 分步子目标 → 元计划 (plan) 说明依赖和触发条件。Plan 0 的"集尘袋满时做 4"是一个条件触发,把状态监测耦合到分解中。sub-agent 的任务描述可以直接套 HTA 格式:目标 + sub-operation 列表 + plan (条件和顺序)。P × C 停止规则也适用:继续分解的代价超过从中获益时应停止。

11.7 Brooks 定律对并行度的硬约束

Brooks "The maximum number of men depends upon the number of independent subtasks." 并行度被独立子任务数硬卡住。Eric Raymond 对 Brooks 定律的部分反驳 (开源项目如 Linux 能有效地接受大量贡献者) 的解释是:开源项目的贡献通常是高度解耦的,不会触发沟通爆炸。这强化了信息隐藏的价值:只有在模块化良好的前提下,加更多 sub-agent 才能线性扩展产出,否则越加越慢。

11.8 TOC 对多 agent 系统瓶颈的提醒

TOC 五步的现代变种:多 agent 系统中的瓶颈经常是 orchestrator 的 context window、某个工具的 rate limit、或某个关键 sub-agent 的可靠性。不要对非瓶颈环节过度优化。Brooks 定律的本质在 agent 系统中仍适用:加 sub-agent 只在非瓶颈环节增加了供给。

11.9 分解失败的五大模式在 agent 系统中同构

• F1 过程分解冒充结构分解 → sub-agent 按"先搜索再总结再写报告"切分,需求变化时全部 agent 都要改
• F2 缺失 Commander's Intent → 未给 sub-agent 说明为什么做,只给 how
• F3 Autonomy 与 Alignment 失衡 → 给 sub-agent 大 prompt 但没给 rules 文件
• F4 Span of Control 被突破 → 主 agent 直接管太多 sub-agent 不引入中层
• F5 信息隐藏边界被暴露 → 让多个 sub-agent 读取彼此的中间工作文件

这些模式在 agent 系统中完全同构,而且比人类组织更快显现 (因为 agent 迭代速度快几个数量级)。

十二、Claim 验证状态表

十三、URL 来源索引

软件工程原文

• Parnas 1972 CACM 原文 — Northeastern tech report
• Brooks Mythical Man-Month PDF — Michigan
• Brooks No Silver Bullet PDF — worrydream
• Conway How Do Committees Invent PDF — 作者主页
• Fowler Domain Driven Design
• Fowler Two Pizza Team
• Fowler Waterfall Process
• DDD Reference PDF
• Uncle Bob Principles of OOD
• SRP Parnas 关系分析
• Azure Strangler Fig
• AWS Two-Pizza eBook

管理学

• Taylor Scientific Management Saylor PDF
• Ford Degradation of Work — UMich Auto-Life
• TPS Basic Handbook — Art of Lean
• Valuing TPS
• TOC Institute

项目管理

• PMI WBS Practice Standard
• INVEST LogRocket
• PMI CPM Origins
• Royce 1970 原论文 — Praxis Framework
• Morgan 2018 重读 — PMWorld

军事指挥

• DTIC Auftragstaktik — The Basis for Modern Military Command
• DTIC Initiative Within Auftragstaktik
• DTIC Moltke's Mission Command
• Mission-type tactics Wikipedia
• Beyond Auftragstaktik NDU
• ADP 6-0 Mission Command
• DTIC Historical Roots of Mission Command

拿破仑战略

• Naval Postgraduate School Grand Armée
• Saber and Scroll Journal
• eARMOR Napoleon Contributions

OODA Loop

• OODA loop Wikipedia
• John Boyd Organic Design
• Team One Network OODA

Span of Control

• Fivecoat Consulting Span of Control
• OPNAVINST 3120.32D
• CGSC Span of Control

组织理论

• Mintzberg Configurations Umbrex
• Two-Pizza Teams Science Nuclino
• Jeremiah Lee Failed SquadGoals
• Matrix Org Challenges Leadership Edge
• Coase Nature of Firm Strategic Management Review

认知科学

• Sweller 2010 Element Interactivity
• Chase-Simon Chunking PubMed
• Hutchins Cognition in the Wild MIT Press
• HTA Human Reliability

失败案例

• Joel Spolsky Things You Should Never Do
• Potapov Why Rewrites Fail
• The Register Longhorn
• Agile Federation Longhorn
• Healthcare.gov Medium 6.3B Lesson
• Forbes Healthcare.gov Diagnosis
• Anthopoulos Healthcare.gov 分析
• Dolfing NHS NPfIT 10B Disaster
• Anderson NPfIT Case History
• BBC NPfIT 2013
• Steve Denning Fake Agile
• DesignGurus Microservices Anti-patterns
• Microservices.io Anti-patterns
• Effectiviology Brooks Law

并行 Session

• methodology/human_decomposition_engineering_20260416_deep_research.md (Round 2 工程管理学原始产出)
• methodology/human_decomposition_military_org_20260416_deep_research.md (Round 2 军事组织原始产出)
• methodology/human_llm_capability_boundary_survey_20260416.md (并行 session)
• contexts/methodology/llm_context_multi_topic_capacity_survey_20260416.md (并行 session)

十四、与其他两份 Session 的关联

本 session 聚焦分解方法论。与两份并行 session 的关系:

Span of Control 3-7 与 items 预算 5-8 (Session 2) 的同构。Hamilton 3-6 (军事)、OPNAVINST 3-7 (海军规章)、Miller 7±2 (工作记忆)、Cowan 4±1 (重估)、Amazon two-pizza 5-10、Dunbar inner circle 5 跨领域一致性指向同一认知容量,LLM 的并发 items 上限 5-8 是同一认知约束在另一个载体上的体现。

Auftragstaktik 与 agent 元认知弱点 (Session 1) 的关联。Auftragstaktik 成功依赖军官共享教育背景。Session 1 发现 sub-agent 的 metacognition 是弱信号 (Anthropic 20% introspection 成功率),sycophancy 在所有前沿模型上存在。两者合起来的推论:给 agent 建立 shared understanding (通过读 rules 文件) 比给它们"自由度"更重要,因为 agent 的自我校准能力不可靠,alignment 必须从外部注入。

Brooks 定律与 Session 2 的沟通成本。Brooks 的 n(n-1)/2 沟通爆炸在 agent 系统中对应多 agent prompt 相互引用时的 context 爆炸。Information hiding 让 sub-agent 只返回 distilled summary (1-2K token) 而不是全部中间产出,是对 Brooks 定律的工程落地。Anthropic 90.2% multi-agent gain 的底层机制就是 information hiding:每个 sub-agent maintain own context,只返回关键信息。

三份 session 共同构成"能力边界 (Session 1) → 资源容量 (Session 2) → 分解策略 (Session 3)"的完整逻辑链,但各自独立成立。

十五、未验证与待扩张

未完全验证的 claim:

• CNCF 42% 微服务回迁数据 (仅单源)
• Chase-Simon 50,000 chunks 估计 (后续修订争议)
• Dunbar 150 跨文化稳定性 (Bayesian 重新分析给出 69-109 范围)

Round 3 推荐扩张方向:

1. 认知科学与生物学的分解:Fodor 1983《The Modularity of Mind》、免疫系统、蜂群蚁群、进化算法的 niche 分化。独特价值是自组织和容错。
2. Simon 1962《The Architecture of Complexity》:near-decomposability (几乎可分解) 系统的概念——子系统内部联系强、子系统之间联系弱但非零——比 Parnas 的 strict hiding 更现实。建议 Round 3 专题化。
3. 军事与应急管理:Stanley McChrystal《Team of Teams》(2015) 关于 JSOC 如何把 Mission Command 升级到反恐作战;Incident Command System 的 span-of-control 在高时间压力场景下的设计。
4. 失败模式的量化研究:Standish Group CHAOS Report、McKinsey-Oxford 2012 大型 IT 项目研究,提取失败率随项目规模的量化关系,验证 Brooks 定律在组织层的形式。
5. Span of Control 在 AI 多 agent 系统中的实证:当 orchestrator agent 要管理 5、7、10、15 个 worker agent 时,成功率/幻觉率/输出质量的变化曲线。这个研究会首次把人类 span of control 数字迁移到 AI 并独立验证。
6. 东亚军事与组织学传统:中国八旗制度、日本战国家臣团、Toyota hoshin kanri (方针管理) 是 Auftragstaktik 与东方层级文化的融合。对理解普适 vs 文化特定很有价值。
7. Parnas Information Hiding 在 LLM 时代的变奏:传统 Information Hiding 假设模块边界稳定。LLM 的能力决定了一个 agent 可以动态"学习"另一个 agent 的内部实现 (通过 few-shot examples)。是否应该在 agent 系统中引入比 Parnas 更强的隔离机制?

结语

人类用了两个世纪打磨从拿破仑军团到 two-pizza team 的分解方法论,核心共识相当少:意图要明确但细节要留白;span 要受认知约束;边界要隐藏实现;冗余但不浪费的拓扑。失败也惊人一致:指令过度规定、span 突破上限、信息隐藏边界被暴露、autonomy 和 alignment 失衡。

这些原则对 agent 编排不是类比,它们是结构同构——同样的信息论约束和同样的认知容量限制,驱动着人类和 AI 在多主体协调中的边界。NightCode 作者面对的 sub-agent 协调问题,本质上是 Auftragstaktik 作者 Moltke 面对的步兵师协调问题的另一个载体。Moltke 的答案是:不要给下级更详细的命令,而是建立共同的战术语言。这条答案在 agent 编排中的形式是:不要给 sub-agent 更长的 prompt,而是确保它们读过共同的 rules 文件。

本 session 字数: 约 10500 中文字 (不含 URL 列表、表格数字和代码片段)
基于的 sub-agent 原始产出: human_decomposition_engineering_20260416_deep_research.md + human_decomposition_military_org_20260416_deep_research.md
与 Round 1 的关系: 本 session 不融合 Round 1 内容 (Round 1 聚焦 LLM 内部分解,本 session 聚焦人类历史方法论),但在"对 agent 编排的启示"章节与 Round 1 的 MAKER、LLM-Modulo 形成对比参考