上一篇文章里，我写过一个 AI 转型中很危险的现象：团队里某一个人借助 AI 跑得特别快，周围的人却接不住。一个齿轮突然提速五倍，不一定能带动整台机器，反而可能把原来的协作关系顶散。
但这里还有一个问题没有展开。
如果这个人不是普通执行者，而是公司里真正懂业务的领域专家呢？
他可能恰好是一个中层。向上，他能理解公司为什么做这件事；向下，他知道一线流程里哪些规则能改、哪些风险不能碰。客户遇到例外会找他，团队拿不准方案会找他，系统出了一个从未见过的问题，最后还是要他做判断。
现在很多关于 AI 组织变革的叙事，都在说基层员工有了穿透职责边界的能力，所以公司可以裁掉中层、压平层级。这句话只说对了一半。
AI 确实会削弱传话型中层，但它也会放大专家型中层。
真正的问题不是要不要保留中层，而是能不能把藏在某个中层身上的业务判断力，从个人能力变成一套可扩张的组织能力。
传话型角色的价值会被压缩；围绕业务专家建立 Agent 生态，才能把个人判断变成组织能力。
同样叫中层，其实是两种完全不同的人
组织架构图上，他们都叫经理、主管、负责人。但从业务价值看，至少存在两类中层。
第一类是传话型中层。他的主要工作是接收信息、拆任务、催进度、汇总结果，再把结果往上报。AI 可以直接完成大量信息整理和任务协调，这一层的价值确实会快速下降。
第二类是专家型中层。他真正值钱的不是信息经过他，而是他能识别信息里哪一处不对。他知道 SOP 为什么这样设计，见过规则失效时的例外，也能在客户诉求、交付成本和合规风险之间做取舍。
前一种角色依赖信息差，后一种角色依赖判断力。AI 会消除很多信息差，却不会自动长出公司内部积累了十年的判断力。
如果企业把这两类人一起裁掉，看起来组织变扁平了，实际上很可能把业务的异常处理能力也一起切掉。正常流程还能跑，一旦遇到边界情况，所有人都开始在群里找那个已经离职的老师傅。
所以 AI 时代真正应该被重做的，不只是组织层级，而是业务专家的能力接口。
不要训练专家学 AI，要让 AI 生态适应专家
企业内部常见的做法，是给业务专家发一个通用 AI 工具，再组织几次提示词培训，希望他主动把几十年的经验整理进去。
这个顺序反了。
业务专家之所以稀缺，就是因为他的时间应该花在复杂判断上，而不是研究模型参数、配置知识库、调试 Agent。你让一个最懂供应链的人先学会怎么写 system prompt，才能放大他的供应链经验，本质上是让他先转行半个 AI 工程师。
更合理的做法，是围绕这个专家量身设计一套 Agent 生态。专家继续用他熟悉的语言讲业务、处理案例、做判断；AI 团队负责把这些判断变成 Agent 可以使用的规则、案例、工具和反馈回路。
不是给专家一把更快的锤子，而是围绕专家重建一条生产线。
这套生态至少应该有五个部分。
1. 入口 Agent：先把问题问完整
大量业务问题之所以反复找专家，不是因为它们有多难，而是提问者连必要信息都没带齐。
入口 Agent 先识别问题类型，追问缺失条件，补齐客户、场景、历史记录和约束，再判断是进入标准流程还是直接升级给专家。专家看到的不再是十条零散聊天记录，而是一份已经整理好的问题包。
2. 知识 Agent：找到相关规则和历史案例
企业知识不是把所有文档塞进向量库就结束了。真正有用的知识，往往是“这个规则在什么条件下成立”“上一次类似情况为什么破例”“这个客户有哪些不能公开写进 SOP 的特殊约束”。
知识 Agent 的任务，是根据当前问题提取最相关的规则、案例和证据，并明确标出来源。它不替专家做结论，但先把专家做判断需要的上下文准备好。
3. 执行 Agent：把确定的部分跑完
凡是规则稳定、输入明确、结果可验证的部分，都不该继续消耗专家时间。
执行 Agent 可以生成方案、填写表单、检查配置、跑诊断流程、产出交付物。非专家员工不必从零开始，只要检查结果、补充现场信息，并对照验收标准完成收口。
4. 质检 Agent：守住业务质量线
Agent 最大的风险不是偶尔犯错，而是把同一种错误高速复制出去。
所以专家生态里必须有独立的质检环节。它检查规则是否引用正确、证据是否充分、结果是否触碰风险边界。置信度不足、规则冲突或涉及高风险决策时，系统必须停止自动流转，把问题升级给专家。
5. 学习 Agent：把每次例外变成系统升级
专家真正稀缺的产出，不是回答了某一个问题，而是他为什么否决系统的答案。
学习 Agent 应该记录专家修改了什么、依据是什么、这是不是一个新的例外。经过专家确认后，再把它更新为案例、规则或新的评审条件。这样专家每处理一个新问题，后面一批人就少问一次同类问题。
这五个部分形成的不是一个“专家分身”，而是一套围绕专家运转的业务系统：
问题进入 → 信息补齐 → 知识检索 → 自动执行 → 质量检查 → 必要时升级专家 → 反馈沉淀
专家不再卡在每一次流程里，但他的判断仍然控制着整套系统的边界。
业务专家负责规则、例外和方向；五类 Agent 负责入口、知识、执行、质检与学习，让内部经验持续流动。
一个真实案例：GM 散热仿真平台
我们在为 GM 规划散热仿真平台的产品化升级时，遇到的正是这种典型场景。
散热优化不是一个适合让 Agent 全自动拍板的问题。一次仿真不达标，可能要调整风扇、材料、TIM、散热片、风道或功耗。不同动作会牵涉成本、结构限制和工程风险。Agent 可以快速搜索可能性，但哪一个方向值得进入下一轮求解，仍然需要散热业务专家判断。
因此我们没有把目标定成“让 Agent 替代工程师自动调优”，而是把流程设计成一个人机协同闭环：
提交任务 → 基线求解 → 规则判断 → Agent 生成 2 至 4 个候选方案 → 专家选择或驳回 → 应用选中方案 → 下一轮求解
Agent 做可能性搜索，专家做方向判断，系统做执行与追溯。
候选方案来自 GM 内部专家经验与仿真证据，业务专家保留优化方向的最终决定权。
这里有一个容易被误解的地方：散热 Agent 的判断依据不是通用大模型临时生成的“行业常识”，而是 GM 内部经验的持续沉淀。风扇、材料、TIM、散热片和风道应该在什么条件下调整，过去哪些动作有效、哪些方案失败、哪些边界不能碰，这些经验多数来自 GM 内部的散热业务专家。
我们要做的，是把专家长期积累的判断依据整理成可检索的知识、结构化规则和历史案例。Agent 在具体任务中负责召回、组合和比对这些经验。它给出的每一项诊断和候选建议，都必须能够回到 GM 内部经验和当前仿真证据，而不是只依赖模型自己的置信度。
系统先冻结任务输入、模型文件、验收指标和允许调整的范围，再调用 Icepak 完成基线求解。确定性规则负责判断结果是通过、不通过还是异常。只有结果未达标时，Agent 才会结合当前指标、专家经验库和历史调优效果，形成 2 至 4 个结构化候选方案。
每个方案不只给一个结论，还必须说明建议动作、判断证据、潜在风险和预期影响。业务专家不再从一张白纸开始排查，而是在已经展开的几个方向中进行对比，选择一个进入下一轮，也可以全部驳回。
专家确认之前，Agent 不能直接修改工程模型，不能自行放宽验收指标，也不能绕过预算和安全边界。专家选定方向后，系统只修改模型的工作副本，生成一个新版本，重新执行求解，并保留每一轮候选方案、人工决策和仿真结果。
这个设计放大的不是 Agent 的自主权，而是专家的决策带宽。
过去，专家要亲自完成“看结果、找原因、想方向、比较方案、决定下一步”的整条链路。现在 Agent 负责搜索、整理和展开可能性，专家集中处理最有价值的一步：确定优化方向。
同时，非专家工程师也能在系统帮助下完成规范建单、指标检查和常规流程，不必每一步都找专家。业务专家选择和驳回方案时留下的原因，又会回流到经验库、历史案例和方案评估里，继续提高下一轮建议的质量。
这就是业务专家的能力放大：不是复制一个“数字工程师”去冒充专家，而是让一套 Agent 生态替专家扩大搜索空间、准备决策材料、执行确定动作，同时把关键判断权留在人手里。
这不是把员工蒸馏掉
表面上看，这套方法也在提取专家经验、沉淀 SOP、制作 Skill，很像在“蒸馏员工”。两者真正的区别，不在技术，而在目标和利益结构。
| 员工蒸馏 | 专家放大 | |
|---|---|---|
| 目标 | 提取知识后替代这个人 | 扩大专家能覆盖的业务范围 |
| 专家角色 | 临时知识提供者 | 长期规则制定者和升级节点 |
| 知识更新 | 一次性抽取 | 在真实案例中持续演进 |
| 价值归属 | 组织拿走，个人议价能力下降 | 专家的影响力、收益和话语权同步增加 |
| 系统边界 | 尽量减少人的介入 | 明确哪些问题必须由专家判断 |
如果专家把经验交出来之后，得到的结果是岗位被替代、奖金没变化、责任反而更大，他一定会保留最关键的隐性知识。这不是态度问题，而是理性选择。
要让专家愿意参与，企业必须把新增价值的一部分还给他。可以是更高的职级和奖金，也可以是这套业务规则的所有权、团队资源和决策权。核心是让专家看到：系统覆盖得越广，我的价值越大，而不是我越容易被替代。
放大的不是专家产量，而是组织的质量底线
“把一个人放大十倍甚至一百倍”听起来很吸引人，但这个说法很容易把方向带偏。
如果只是让专家一天处理的工单从 20 个变成 200 个，这仍然是在加速一个齿轮。专家更忙了，组织对他的依赖也更深了。一旦他离开，200 个工单一起停摆。
真正应该放大的，是两件事。
第一是专家的覆盖半径。过去他只能亲自带五个人，现在一百个人都可以通过 Agent 生态获得他的规则、案例和检查标准。
第二是组织的质量底线。普通员工不一定能达到专家水平，但他处理常规业务时，不再只靠个人经验临场发挥。系统会帮他补齐输入、调用正确流程、检查明显风险，让大多数产出稳定达到及格线以上。
这时专家的工作也会发生变化。重复答疑和标准审批逐渐减少，他把时间集中在三类事情上：处理新例外、修正规则、探索更优解。
所以衡量这套生态是否有效，不能只看生成了多少内容、自动化了多少步骤。更值得看的指标是：
- 有多少业务在不需要专家亲自介入的情况下，仍然达到质量标准
- 非专家员工的一次通过率提高了多少
- 系统应该升级的问题，有没有准确送到专家面前
- 专家花在重复问题上的时间是否下降
- 一个新例外从被发现到变成组织能力，需要多长时间
十倍、百倍可以是方向，但不该是承诺。真正有意义的放大，是专家投入一小时，能够让更多人在更长时间里做出接近正确的判断。
怎么从一个专家开始搭这套生态
这件事不需要先建一个巨大的企业级 Agent 平台。最稳妥的办法，仍然是从一个专家、一个高频场景、一个闭环开始。
第一步：找到真正的业务专家
不要只看职级和工龄。真正的专家通常有三个特征：大家遇到例外会找他；他能解释判断依据，而不只是说“凭经验”；他的判断结果可以在后续业务中被验证。
第二步：收集决策案例，不是泛泛整理知识
不要一上来让专家写一本业务百科。直接拿最近 20 个真实问题，记录输入、判断、依据、动作和结果。尤其关注专家在哪些地方否决了标准答案，因为例外最能暴露真正的业务边界。
第三步：画出三色决策边界
- 绿色：规则明确、风险低，Agent 可以自动执行
- 黄色：Agent 准备方案和证据，员工或专家确认
- 红色：高风险、强例外、规则冲突，必须由专家决策
这个边界比“自动化率要达到多少”重要得多。它决定了系统在哪里提效，在哪里保持克制。
第四步：只做最小闭环
先做一个入口 Agent、一条执行 Skill 和一个升级机制，跑通真实业务。不要一开始就追求五层架构全部齐全，更不要先做一个覆盖全公司的通用平台。生态是从真实例外里长出来的，不是从架构图里设计出来的。
第五步：让专家的每次修改都能回流
如果专家今天改完答案，明天系统还犯同样的错，这就不是生态，只是一个需要反复返工的 AI 工具。每次人工接管都应该留下原因，并进入规则、案例或评测集，成为下一轮迭代的输入。
AI 时代，不是消灭中层，而是重新给中层定价
AI 会继续压缩组织层级。只做信息搬运、任务转发和过程汇报的岗位，很难维持原来的价值。这件事没有必要回避。
但业务专家不应该因为恰好坐在中层的位置上，就被当成同一种成本一起处理。他脑子里装的往往不是几份文档，而是一家公司在无数次项目、事故、客户博弈和流程修正里形成的业务判断。
过去，这种判断只能通过他本人缓慢地向外输出，所以他既是核心资产，也是组织瓶颈。Agent 生态真正值得做的事，就是拆掉这个瓶颈，但保留并强化这个核心。
基层员工借助 AI 穿透职责边界，专家借助 Agent 生态扩大判断边界。前者让组织变平，后者保证组织变平之后不会失去深度。
所以在讨论“有了 AI 还要不要中层”之前，企业应该先问另一个问题：
这个人是在传递信息，还是在生产判断？如果他生产的是关键判断，我们有没有为他造好一套可以放大这种判断的 Agent 生态？
这可能比直接裁掉一层人，更接近 AI 组织转型真正的答案。
我们正在实践的，也是这种围绕具体业务专家做定制化设计的方式。不是先卖给全公司一套通用工具，再要求每个人自己摸索怎么用；而是进入一家公司的真实业务，找到最关键的专家、决策和例外，再围绕他设计知识、执行、质检、审批和学习机制。
如果你的公司也有少数几位“所有复杂问题最后都要找他”的业务专家，真正值得讨论的，可能不是再给他开一个 AI 账号，而是从一个高频场景开始，为他搭一套完整的 Agent 生态。把专家从重复劳动中释放出来，也让更多普通员工能够稳定站到业务及格线以上。