夜雨聆风正文
写在前面
上一篇，我写了我在AI时代找到不焦虑方式的过程。
很多朋友留言说："我也焦虑，但我的问题不是跑得慢，是越跑越乱。"
这一篇，我想认真回答这个问题。
一、那段"工具越来越多、效率越来越低"的日子
2024年底，我的工作流里已经塞进了一堆AI工具。
用A写项目文档，用B做数据分析，用C处理邮件，用D搜集信息……
每一个单独拿出来，都挺好用的。
但我很快发现一件事——
我的大量时间，开始消耗在工具之间的"搬运"上。
从A拿到输出，重新喂给B说背景； B做完了，再手动整合到C里； 每次新开一个对话，都得重新解释一遍上下文。
这种感觉，我太熟悉了。
这不是AI的问题。这是我在企业里见过一百次的组织问题：
有一批很能干的人，但没有协作架构。 每个人单打独斗，内耗就是瓶颈。
做了多年项目管理，我第一次意识到：
AI工具的使用困境，和团队管理的失效困境，本质是同一个问题。
二、我们通常怎么划分AI的"分工"——以及为什么都有问题
意识到这是组织问题之后，我开始认真研究： 那大家一般是怎么给多个AI划分职责的？
我梳理了三种主流方式。
方式一：按模型能力划分
最直觉的做法—— 代码能力强的模型负责技术任务， 中文理解强的负责内容创作， 长上下文模型负责文档分析。
听起来很合理，对吗？
但有一个根本缺陷：
你把整个组织架构，绑定在了一个三个月就会变化一次的技术参数上。
今天这个模型代码最强，半年后呢？ 如果分工是基于"谁现在最擅长什么"， 那每次模型迭代，你就要重新设计一遍"组织架构"。
在企业管理里，这叫一个反面教材：部门划分依赖个人能力，不是依赖角色职责。一旦那个关键人离职，整个部门瘫痪。
好的组织设计是角色驱动，不是人员驱动的。 AI团队也一样。
方式二：按任务类型划分
搜索专用Agent、写作专用Agent、执行代码专用Agent……
分工明确，看起来很清晰。
但现实是：真实的任务，几乎没有只属于一种类型的。
举个例子—— "生成一份项目健康度周报"这一个任务， 需要从内网收集数据（信息获取）、 分析数据趋势（推理分析）、 生成格式化文档（内容创作）、 上传知识库（系统操作）。
四个步骤，四种类型。
如果每种类型对应一个独立Agent， 协调这四个Agent完成一件事的成本， 可能比一个通用Agent独自完成还要高。
这是典型的"部门墙"问题：过度专业化，导致协作摩擦大于协作收益。
方式三：按工具访问权限划分
这种方式有一个真正的优点：稳定。
能访问内网的Agent处理内网任务， 能访问本地文件系统的处理本地任务， 这个边界不会因为模型迭代而改变。
但它的问题是：它只解决了"边界在哪里"，没有解决"职责是什么"。
一个能访问内网的Agent， 可以负责信息收集，也可以负责任务执行，还可以负责结果汇报。 权限维度告诉你它能接触什么， 但没有告诉你它应该负责什么。
三、我开始向管理学要答案
三种方式都有局限之后， 我做了一件对工程师来说可能有点奇怪的事：
我去看了管理学里关于组织设计的经典理论。
不是因为我是管理背景（虽然我确实是）， 而是因为我越来越相信一件事：
Multi-Agent系统，本质上是一个既是技术系统、又是组织系统的东西。
纯技术视角和纯管理视角都是片面的。
而管理者在设计组织时问的那些问题—— 职责边界清不清晰？ 信息流动顺不顺畅？ 出了问题能不能快速定位责任方？ 系统扩张时架构能不能撑住？
这些问题，在Multi-Agent设计里，一个都没有少。
四、一个让我重新理解Multi-Agent的框架
管理学里有两种经典组织结构：
职能型（按专业能力分部门：研发、市场、运营） → 优点：专业能力强 → 缺点：横向协作成本高
流程型（按业务阶段分团队：售前、交付、售后） → 优点：端到端流程清晰 → 缺点：相同技能在多个团队重复，资源浪费
大多数成熟的公司，最终都走向了矩阵型—— 横轴是职能，纵轴是流程阶段，两者叠加。
把这个逻辑映射到Multi-Agent，我得到了一个二维框架：
Text
第一维：环境与权限（对应"职能"）
→ 本地环境的Agent：持有最敏感信息，是系统"主脑"
→ 内网环境的Agent：处理内部系统，数据不出内网
→ 公有云环境的Agent：处理公开内容，脱敏数据
第二维：任务阶段（对应"流程"）
→ 感知 → 规划 → 执行 → 评估 → 记忆
两个维度叠加，形成一个矩阵。
不是所有格子都要填满，但这个框架给了我一个系统性思考的基础——而不是走一步看一步，遇到问题才想怎么填补。
五、一个让我豁然开朗的认知
写到这里，我想说一件也许有点冒犯的事：
在Multi-Agent的组织设计这个问题上，管理背景的人，可能天然比工程背景的人有优势。
这不是说工程师不擅长系统设计——他们当然擅长，技术实现层面远比我专业。
但工程师在设计系统时，出发点是技术约束：什么是可行的，什么是高效的，什么是可维护的。
管理者在设计组织时，出发点是协作效率：职责边界清不清晰，信息流动是否顺畅，出了问题能不能快速定位责任方。
Multi-Agent系统需要的，恰好是两个视角的结合。
而这，是我作为一个非技术背景的管理者， 在这个时代第一次感受到：我过去积累的那些东西，真的有用。
写在最后
这篇写的是"为什么传统的AI分工方式都有局限"，以及"管理学给了我什么新视角"。
下一篇，我会写得更具体：
我是怎么一步步搭起自己的Multi-Agent系统的——四个阶段，走了哪些弯路，用了什么管理框架解决协作问题。
如果你也在用AI工具，却总觉得"越用越乱"， 也许下一篇对你有用。
不用懂技术。但要懂组织。
