Gall 定律：复杂系统，先从一个能工作的简单系统开始

做一个项目时，很容易先想到它最终应该拥有的样子：功能齐全、架构清晰、能够扩展，最好还能提前解决所有可能出现的问题。

于是，设计图越来越完整，模块越来越多。但有一个问题常常被推迟：这些东西连在一起，真的能完成一件有用的事吗？

Gall 定律提醒我们，把这个问题提前。

一、这条定律在说什么

John Gall 在《Systemantics》系列中提出了一个后来被称为 Gall 定律的观点：能正常工作的复杂系统，往往是从已经能工作的简单系统演化而来的。该书初版《General Systemantics》出版于 1975 年。初版书目

原文的措辞更强烈：

“A complex system that works is invariably found to have evolved from a simple system that worked.”

随后，Gall 对从零一次性设计复杂系统发出了近乎绝对的警告。这种表达适合作为工程上的提醒，而不是用来判定每个项目成败的数学定理。原书也提到：简单系统本身，同样可能无法工作。原书第三版，第 11 章

二、为什么“先跑起来”这么重要

设计时，我们依靠已有经验和对需求的理解。运行时，系统开始接受真实输入，也开始暴露这些理解中的漏洞。

一个接口单独测试没有问题，接入另一个模块后，可能发现双方对数据的理解不同。一次操作顺利完成，看起来很简单；遇到超时，再试一次，却可能产生重复结果。使用者真正关心的，也可能不是设计时投入最多精力的功能。

这些问题并不都会在设计图上显现。

如果同时引入许多未经验证的机制，出了问题，就很难判断究竟是哪一层出了错。先让一个范围有限的系统工作起来，可以更早获得反馈，也更容易定位错误。

这里有一个区别：先写好十个模块，最后再把它们接起来，与先让一条完整流程跑通，再逐步扩展，并不是同一种开发方式。

前者虽然也在分步推进，却可能把最重要的验证留到了最后。后者则不断回答：到目前为止，整个系统是否仍然能完成它承诺的事情？

三、放到 Agent 开发里，会是什么样

假设要做一个能够查阅资料并回答问题的 Agent。

一开始，很容易列出一长串功能：规划器、多 Agent 协作、长期记忆、工具路由、反思机制、任务恢复。每一项似乎都有道理，但把它们全部实现，并不能自动证明系统更好用。

可以先限定一个任务：接收问题，调用一个只读检索工具，根据结果回答，并保留调用记录。为它设置明确的终止条件，再选一些问题检查结果。

这样，就有了一个能够被观察、比较和修改的起点。

如果回答不准，先检查检索内容、工具说明和提示词。如果任务确实需要跨多次运行保留状态，再设计持久化。如果中断恢复是必要需求，就加入恢复机制，并测试中断之后的行为。如果准备引入多个 Agent，就比较它与单 Agent 在质量、耗时和成本上的差异。

每增加一种机制，都有一个具体问题作为理由，也有一种验证方法判断它是否有效。

这与 Anthropic 在《Building effective agents》中的建议相近：从简单方案开始，只有当增加复杂度能够改善结果时，才继续增加。Anthropic 原文

四、逐步演化，也需要认真设计

“先简单后复杂”很容易被误解成先随便写，等以后再整理。

但随意堆积的代码，可能很快失去继续演化的空间。接口含义混乱、状态分散、缺少测试时，每一次修改都可能破坏别处。

Brooks 在《No Silver Bullet》中提出，让软件从可运行的骨架逐步生长；同时，他明确强调这种方式需要自顶向下的设计。整体方向与增量验证，可以同时存在。原论文，第 5.3 节

Fowler 也指出，测试、持续集成和有纪律的重构，是演化式设计能够成立的重要条件。它们让开发者有能力根据新认识修改系统，而不至于每次都承担失控的风险。《Is Design Dead?》

演化也不意味着只增不减。有时，删掉一个用不上的机制，替换一个不合适的抽象，才是系统向前走的一步。

五、AI 写代码越快，越需要及时验证

把这个思路放到 AI 编程里，一个值得警惕的变化是：实现许多功能变得很快，理解这些功能如何共同工作，却未必同样快。

模型可以迅速生成一套看起来完整的架构，也可以在原来的代码上继续添加新层次。如果我们只检查“有没有写出来”，就可能在还没理解问题时，已经积累了大量实现。

更稳妥的做法，是把验证穿插在开发过程中。让 AI 完成一段范围明确的改动，运行它，检查结果，再决定下一步。这样，后续工作依据的是实际反馈，而不仅是生成出来的解释。

在这里，Gall 定律可以转化成三个很具体的问题：

• 现在这个系统，已经被验证能完成什么？

• 下一层复杂度，要解决哪个明确的问题？

• 加上它之后，怎样判断系统真的变好了？

能回答这些问题，系统就有了继续发展的依据。答不上来时，继续添加功能，往往只会让判断变得更困难。