写程序，越来越像治理一个组织

以前写程序，我们关心的是函数怎么设计，模块怎么划分，数据如何流动，错误怎样处理。

后来有了 AI Coding，我们开始把需求交给 Agent，让它写代码、调试、测试、提交 PR。自己则更多地负责技术方案、工作拆分、Code Review，以及解决几个 Agent 之间的冲突。

这已经很像一名 Tech Lead 的日常工作了。

但最近，我又往前走了一步。

我开始让 Agent 管 Agent。

我不再亲自给每个执行者安排任务，也不再逐一追问进度。它们有自己的负责人，有任务分配和验收规则，可以根据情况增加执行者、调整方案，处理大部分日常问题。

而我在做的事情，开始有点像治理一个组织。

Leader 的 Leader 在做什么？

传统软件工程里，一个 Tech Lead 可能需要带着几名工程师完成项目。他要理解需求，确定架构，分配任务，协调依赖，解决技术争议，并最终保证交付质量。

那么，Tech Lead 的 Leader 呢？

一个管理着几个技术团队的人，不可能每天阅读所有人的代码。他甚至不一定知道某个工程师今天具体修改了哪个文件。再往上，一个大型组织的技术负责人管理着数百甚至数千名工程师，更不可能亲自审查每一个 PR。

但这不意味着他什么都不做。

某个团队进度失控，他需要知道原因；几个团队反复发生协作冲突，他需要修改协作方式；事故重复出现，他不能满足于每次都有人把服务重新启动。越往上，管理者越不直接处理工作本身，而是维护一套能够让工作持续进行的机制。

为什么高层管理者不看具体代码，组织依然能朝着正确的方向运转？

最近翻传统管理学的书，我发现赫伯特·西蒙在《管理行为》里早就聊透了这件事。西蒙认为，无论是人还是机器，算力和注意力都是有限的。面对复杂系统，高层管理的核心从来不是替下属做每一个具体决定，而是控制他们做决定时的前提。你给它设定什么样的价值优先级，让它看到什么样的环境事实，决定了它会推导出什么样的动作。

这和《不拘一格》里推崇的管理哲学如出一辙：管理高密度的聪明人，靠的不是死板的指令控制，而是高信噪比的上下文。

优秀的管理者并不是永远站在每个人身后，告诉他们下一步该做什么。相反，他需要让自己不在场的时候，事情依然能够正常推进。

从写代码，到制定机制

我发现，AI Coding 正在让我们经历一个极其相似的过程。

最初，我让 Agent 写代码。后来，我让一个 Agent 管理另外几个 Agent。现在，我开始关心它们应该怎样组织工作。

比如，一个任务究竟应该交给一个 Agent，还是拆给多个 Agent？

不是人越多越好。并行可以缩短执行时间，但也会带来依赖、冲突和沟通成本。詹姆斯·汤普森在《行动中的组织》里算过这笔账：如果几个执行者必须边干边聊、实时互相影响，这种互惠性依赖的协调成本是最高的。想把成本降下来，就得在它们之间建立缓冲层——通过清晰的模块边界和隔离的分支，把高频拉扯的任务拆成按工序交接的流水线，或者干脆让它们各自独立作业，最后再做汇总。

因此，我更倾向于根据任务的实际情况动态组织执行者，而不是预先设置一整套产品经理、架构师、前后端的固定岗位。明茨伯格在《卓有成效的组织》里把这种僵化的科层制批得很透。面对复杂多变的研发任务，最高效的组织形态根本不是固定编制，而是随时聚散的特别小组——平时沉淀好高度标准化的原子技能，任务来了动态拉起几个执行者，干完活就地解散。

再比如，怎样才算完成任务？

明茨伯格在书里提到，当你不去微操具体的工作流程时，粘合整个组织的唯一方式就是把产出标准化。在我的系统里，Agent 说自己写完了不算，代码通过本地测试也未必算，因为它很容易为了迎合指令而走捷径。它必须提供与实际版本对应的验证证据。PR 准备好审查、通过审查、合并和部署，是几件完全不同的事，必须靠铁板钉钉的验收契约来作数。

还有，什么事情可以自主决定，什么事情必须交给人？

安迪·格鲁夫在《格鲁夫给经理人的第一课》里讲得很实在：把日常生产看作黑盒，根据任务的成熟度动态放权，管理者只在关键的高杠杆节点做抽检。

控制论大师斯塔福德·啤酒在《企业之心》里则提供了一个更妙的视角——把组织当成生物的神经系统。平时内脏怎么运作，大脑根本不管；但系统里必须有直接捅到底层的越级抽检探针，还得有痛觉神经。普通的技术修复可以在授权范围内继续推进；一旦涉及高风险变更、预算超支或产品方向偏离，痛觉信号就会绕过所有中间层的汇报美化，直接触发熔断并把问题推到人面前。

这些东西，已经不太像传统意义上的编程了。它们更像是在设计一套组织的运作制度。

纠偏，而不是永远救火

当然，机制不可能一开始就正确。

Agent 仍然会犯错，会重复工作，会在某个问题上反复修改，甚至陷入两个 Agent 相互审查、相互否定的死循环。

起初，我会亲自介入，把问题解决。但渐渐地，我发现这样并没有真正解决问题。这一次我救了火，下一次还会发生。

《系统之美》里有一条很扎心的规律：在一个复杂系统里，去微调具体的参数，往往是杠杆率最低的做法；真正管用的高杠杆动作，是去改变信息流的结构，或者重写系统的运转规则。

如果同一种错误反复出现，应该检查它为什么能够反复发生：

• 是任务的完成条件不清楚？
• 是不同 Agent 对接口的理解不一致，缺少单一事实来源？
• 还是审查机制缺少西蒙所说的满意阈值，导致它们在不断提出没有实际价值的新问题？

如果问题来自架构，就修改架构；如果可以通过类型系统或测试发现，就让程序自动拦截；如果是任务交接出了问题，就改变交接机制。

而不是在提示词里不断追加一句“以后请注意”。在提示词里打补丁，只是在替某一次失误擦屁股；修改机制，才是在做系统级的纠偏。

这和传统工程管理非常相似。一个好的技术负责人，不应该靠自己每天解决最多的问题来证明价值。他应该让团队越来越少地遇到那些本可以避免的问题。

然后，让系统自己运作

我越来越不希望 AI 系统模仿一家传统组织的全部形式。

不需要给每个 Agent 安排固定职位，也不需要为了显得专业而设计层层汇报和会议。有些事情，一个 Agent 就能完成，没有必要组织一个团队。有些问题，执行者之间直接对齐就能解决，也没有必要让消息经过几层管理者。

管理的目的不是制造更多管理。而是让正确的事情，以尽可能低的协调成本发生。

真正需要继承的，是传统管理经过长期实践建立起来的骨架：明确的目标、清晰的责任、合理的授权、可验证的交付，以及出现偏差时的反馈机制。系统越自主，越需要可靠的事实来源、明确的权限边界，以及发现异常后可以介入和恢复的能力。

但我的注意力确实发生了变化。

从前，我关心一段代码有没有写对。
后来，我关心一项任务有没有交付。
现在，我关心的是：即使我不再参与每一个任务的具体过程，这套系统能不能持续交付正确的结果。

想起来还挺奇妙的。现代管理学鼻祖切斯特·巴纳德在近九十年前写过一句话，放在今天看依然让人起鸡皮疙瘩。他在《经理人员的职能》里说，组织不是一群人，而是有意识地协调起来的活动或力量的系统。当这套系统顺畅运转起来之后，管理者最核心、也最不可替代的职能只剩下一个——定义整个系统的顶层意图。

过去，我们花很多年学习如何组织代码，如何封装复杂性，如何通过接口让不同模块协作。现在，我们开始用类似的思路组织能够自主工作的 Agent。

过去，我们编写程序，让机器按照规则运行。现在，我们制定机制、观察结果、纠正偏差，然后让一群能够编写程序的 Agent 自己运作。

写程序这件事，正在变得越来越像治理一个组织。

而我最期待的，或许不是有一天能够同时指挥几百个 Agent。

是有一天，我不再需要指挥它们。

我只需要想清楚，我们究竟要创造什么。