上一篇文章《AI的第一性原理 | 上下文工程的尽头，是组织学》里，我提了一个观点：Agent系统的scaling，本质上是一个组织问题，不是模型问题。
很多朋友读完之后问了一个很实际的问题：道理我懂了，那具体该怎么设计？
这篇就来回答这个问题。但我要先说一句不太好听的话——如果你期待的是一套标准方案、一个最佳实践、一个拿来就用的架构图，那你会失望。因为这个问题的本质，恰恰在于不存在唯一正确的架构。
不过，虽然没有标准答案，但有一把标准的尺子。这把尺子是一个经济学家在1937年给我们的。
1937年，27岁的罗纳德·科斯（Ronald Coase）发表了一篇论文，问了一个听起来很蠢的问题：
如果市场是高效的，那所有人都应该是自由职业者，每件事都通过市场交易来完成。你需要一个设计师？去市场上找一个，谈价格，签合同，交付。为什么要把设计师雇进公司，每月发工资，用命令让他干活？
科斯的回答是：因为市场交易有成本。
你找一个外部设计师，要花时间搜索、评估、谈判、签约、验收、处理纠纷。这些成本叫做"交易成本"。当交易成本高到一定程度的时候，你还不如把这个人雇过来，用内部命令代替外部交易。
但内部也有成本——管理成本。人多了管不过来，层级多了信息失真，规模大了就会官僚化。
所以企业的边界在哪里？在管理成本和交易成本相等的那个点上。
这就是科斯定理的核心。它在1991年拿到了诺贝尔经济学奖。
你可能会问：这和Agent有什么关系？
关系太大了。因为Agent系统里，存在着一模一样的两种力量。
在Agent架构中，你有两种方式让主Agent完成一个复杂任务：
第一种：工作流（Workflow）。 你预先定义好流程：第一步做什么，第二步做什么，如果条件A就走分支B。这就像企业内部的命令链——SOP写死，按流程执行，不需要每次都"重新想"。
第二种：LLM动态调度。 你给主Agent一堆工具描述，让它自己判断该调用哪个、按什么顺序、传什么参数。这就像去市场上临时找人——灵活、适应性强，但每次都要"重新想"。
这两种方式各有成本：
工作流的成本是僵化。一旦写死，它就只能处理你预见到的情况。遇到新场景就只能改代码，而改代码的成本很高。这对应科斯说的"管理成本"——组织内部的刚性。
LLM调度的成本是不稳定。大模型可能选错工具、传错参数、遗漏步骤、幻觉出不存在的能力。而且每次调度都要消耗上下文窗口和推理token,这对应的就是"交易成本"——每一次动态匹配都有代价。
所以，问题的关键来了——
科斯的尺子直接可以用：比较这两种成本，哪个低选哪个。
让我把这把尺子具体化。
适合写死成工作流的调用，通常长这样：高频出现、路径稳定、很少有例外情况、失败代价高。比如"用户上传了一份PDF → 提取文本 → 存入知识库"这种流程，你让LLM每次重新决策纯粹是浪费——它99%的情况下都会做出完全一样的决定。写死它，一劳永逸。
适合交给LLM调度的调用，通常长这样：低频出现、路径多变、需要根据上下文灵活判断、创造性比稳定性重要。比如"用户问了一个开放式的研究问题，可能需要搜索网页、也可能需要查数据库、也可能需要写代码跑个分析"——你根本没法预判路径，只能让LLM自己想。
但真正有趣的是那些处于中间地带的调用。它们一开始是动态调度的（因为你还不确定最佳路径），但随着系统运行，数据积累，你会发现某些路径反复出现且总是成功。这时候，这条路径就应该从"市场"沉淀为"企业"——从LLM调度固化为工作流。
反过来也成立：当环境变化、某个工作流开始频繁失败的时候，它就应该被"解冻"——从写死的流程退回LLM动态调度，让系统重新探索。
一个成熟的Agent系统，必然是计划经济和市场经济的混合体。 而且它不是静态的混合，是一个持续动态调整的混合——就像真实世界里，哪些事由企业内部做、哪些事交给市场，边界一直在移动。
这是第一个原理。让我们进入第二个。
假设你的Agent系统现在有一万个可用工具（子Agent）。主Agent该怎么从中选出最合适的那一个？
最朴素的方案：把一万个工具的描述全部塞进主Agent的上下文窗口，让它自己选。
这行不通。原因有三：第一，一万个工具描述可能就要消耗掉大部分上下文窗口，留给实际任务的空间就不够了；第二，大模型在候选项太多的时候选择准确率会大幅下降——这个现象和人类面对太多选项时的"选择困难症"如出一辙；第三，即使选对了，每次调用的推理成本也极高。
所以你必须分层。
这不是一个设计偏好，而是一个物理约束，就像上一篇文章说的——管理幅度是有限的。一个管理者能有效管理5到10个直接下属，一个LLM能有效从大约几十个工具里准确选择。超过这个数字，就必须引入中间层。
最顶层是主Agent，它只面对5到8个"大类"——比如"代码类任务""数据分析类任务""文档处理类任务""搜索类任务"等等。每个大类背后是一个二级调度Agent，它又面对5到8个更细的子类别。以此递推，直到最底层是具体的执行Agent。
从一万个里选一个，变成了每一层从几个里选一个。决策质量飙升，上下文消耗骤降。
但这引出一个更深的问题——
在上面的分层架构里，每一个"节点"看起来是一个Agent。但实际上，一个节点可以不是单个Agent，而是一个Agent网络。
什么意思？
比如说，你有一个"代码类任务"的二级节点。最初，它可能就是一个Agent，擅长写Python代码。但随着需求复杂化，你发现它一个Agent搞不定了——有些任务需要先读文档再写代码，有些需要先写代码再跑测试再根据报错修改，有些需要同时写前端和后端然后联调。于是这个"代码节点"内部，自己长出了一个小型Agent网络：一个负责理解需求，一个负责写代码，一个负责测试，一个负责review。
但对外——对上一级的主Agent来说——它仍然只是"代码类任务"这个单一节点。接口没有变，内部结构复杂了。
嵌套的价值在于两个字：封装。
上层不需要知道下层内部发生了什么。主Agent不需要知道"代码节点"内部有几个Agent、它们之间怎么协作。它只需要知道：我把一个代码任务扔给这个节点，它会给我交付结果。就像你叫外卖不需要知道厨房里有几个厨师、谁负责切菜谁负责炒菜。
封装带来了两个极其重要的好处：
第一，复杂度隔离。 每一层只处理自己这一层的复杂度，不会向上泄漏。一万个Agent的系统，主Agent面对的可能只有7个节点——复杂度被逐层消化了。这就是人类组织用层级制度解决规模问题的同构逻辑。
第二，可独立演化。 一个节点内部可以从"单个Agent"成长为"多Agent协作网络"，而不需要修改上层的任何东西。你可以在不动全局架构的情况下，局部升级系统的某一部分。这意味着整个系统可以一块一块地进化，而不是每次升级都要推倒重来。
那嵌套什么时候应该发生？判断原则其实很直觉：当一个节点内部的任务复杂度，已经让单个Agent无法高质量完成，但它对外的接口仍然可以保持简洁的时候——就该嵌套了。
这个判断标准和软件工程里"什么时候该把一个函数拆成一个模块"的标准完全一致。不是巧合——这是复杂系统管理的普遍规律。
现在来回答那个很多人关心的问题：主Agent到底靠什么来选择正确的子Agent？
有人说：靠大模型足够聪明就行了。只要模型能力够强，给它工具描述，它自然能选对。
有人说：靠强化学习。让系统在大量试错中学会最优调度策略。
我的判断是：这两个都对,但都只对了一部分。而且它们适用于不同的阶段。
第一阶段：语义匹配。 这就是目前最主流的做法——给每个工具写一段描述，靠LLM的语义理解来匹配任务和工具。简单、直接、在工具数量不多的时候效果不错。但它有天花板：当工具超过几十个，描述之间的语义区分度下降，LLM的选择准确率就会明显滑坡。
第二阶段：检索增强调度。 这是分层架构的自然延伸——不让LLM从所有工具里选，而是先用embedding检索缩小范围到top-K，再让LLM从K个里精选。把"万里挑一"变成"先缩到十个,再十里挑一"。这一步大幅提升了准确率,也大幅降低了上下文消耗。
第三阶段：经验积累。 系统运行一段时间后，你有了大量历史数据——哪个任务调用了哪个Agent、成功了还是失败了、耗时多少、用户满意度如何。这些数据就是调度系统的"工作经验"。你可以用它来加权排序（成功率高的Agent优先）、用它来发现模式（某种类型的任务总是由某个Agent处理得最好）、用它来预警（某个Agent最近失败率上升,可能需要检修）。
第四阶段：路径沉淀。 当某条调用路径被反复验证成功,它就不应该还停留在"LLM每次重新决策"的状态——应该被固化成工作流。这就是前面说的"从市场沉淀为企业"。而强化学习在这里找到了它真正的位置：不是用来替代LLM的语义理解，而是用来优化"什么时候该固化、什么时候该解冻"这个元决策。
所以完整的答案是：
短期靠模型聪明（语义匹配），中期靠机制设计（分层检索+经验积累），长期靠演化（路径沉淀+RL元优化）。
单独靠任何一种都不够。就像人类社会的运转，不是单靠领导人英明、也不是单靠制度完善、也不是单靠文化积淀——而是三者叠加。
这让我想到一个有趣的类比。
让我们把上面说的调度机制拼在一起看，你会发现一件有意思的事——
工具描述 = 简历。 调用历史 = 工作经验。 成功率 = 绩效考核。 embedding检索 = HR系统帮你筛选候选人。 LLM精选 = 面试官做最终判断。 路径沉淀 = 这个岗位的SOP成熟了，不用每次都重新招人。 失败率上升 = 该培训还是该淘汰？
你发现了吗？一个成熟的Agent调度系统，长到最后，就是一个人力资源管理系统。
这不是我在强行类比。这是两个系统面对同一个问题——"如何在大量专业化个体中为每个任务找到最合适的执行者"——时，必然会收敛到的相似结构。
这也再次印证了上一篇文章的核心观点：Agent系统的架构设计，终将与人类组织学重新交汇。不是因为我们想模仿人类，而是因为问题的结构决定了解法的结构。
最后，我把这篇文章的核心思路浓缩成一个简单的决策框架，供实际设计Agent系统时参考：
该走工作流还是LLM调度？问自己：这个调用的路径是否稳定、频繁、且很少有例外？如果是，写死工作流。如果路径多变、需要灵活判断，交给LLM调度。如果你不确定——先用LLM调度，积累数据，等路径被反复验证后再固化。
该不该分层？问自己：主Agent需要面对多少个直接候选？如果超过15到20个，就该引入中间层。每层保持5到10个候选项是比较健康的区间。
该不该嵌套？问自己：某个节点内部的任务，是否已经复杂到单个Agent处理吃力，但它对外的接口仍然可以保持简洁？如果是，让这个节点内部长成一个小型Agent网络，但对外维持原有的简洁接口。
调度该用什么机制？看系统所处的阶段。刚起步——靠语义匹配。规模上来了——加分层检索。运行一段时间——引入经验加权。路径成熟了——沉淀为工作流。
两篇文章写到这里，有一件事我越来越确信：
它需要AI工程师理解大模型的能力边界，也需要他们理解科斯定理讲的交易成本、西蒙讲的有限理性、管理学讲的管理幅度、软件工程讲的模块化封装。
这不是说每个做Agent的人都要去读经济学博士。但如果你完全不了解这些思想，你大概率会在Agent系统变复杂的过程中反复踩坑——而那些坑，人类组织已经踩过了。
有一句话大概可以作为这两篇文章共同的结尾：
前者是工程问题，后者是设计哲学。当规模的临界点到来的时候，后者会比前者重要得多。
而那个临界点，可能比我们以为的，来得更快。