我最早接触 Multi-Agent 产品化，是从一个被客户问住的瞬间开始的。当时我们做了一套通用的多智能体演示平台：几个 agent 分角色讨论、协作写方案、自动拆解任务，跑起来特别唬人。跟一个做供应链履约的客户聊，对方看完 demo 点了点头，然后问了一句：“挺酷，但我们仓库里那套十年前的报单系统，它怎么接？你们能让它自己查库存、自己校验合同、自己回邮件，还不出错吗？”
我一下子意识到，通用工具和垂直行业解决方案之间，隔着的不是几行 prompt，而是一整套关于业务理解、系统边界、评测标准和交付方式的重新设计。这篇文章就把我从通用 Multi-Agent 工具转向垂直行业方案的完整思考写出来：包括底层机制、通用工具为什么落地难、垂直化改造到底改什么、从调研到上线的四步流程，以及我踩过的几个印象深刻的坑。打算做 Multi-Agent 产品化，或者正纠结“套个通用框架能不能直接交付”的朋友，这篇应该能帮上忙。
1. 先看清楚Multi-Agent为什么火：技术本意与产品化初期的错配
1.1 多智能体解决的是“分工”，不是“更聪明”
很多人第一次接触 Multi-Agent 时，最直观的感受是“多个 AI 一起干活，肯定比一个强”。这个直觉方向对，但机制理解经常偏。单 Agent 模型哪怕是参数规模再大，本质上还是一个上下文窗口里处理全部任务：既要理解用户意图，又要检索知识，还要调用工具，最后还得保证输出风格统一。一旦任务链条变长，上下文会迅速膨胀，模型很容易在中间环节丢失对原始目标的对齐。
Multi-Agent 的核心价值在于把一个大问题拆成几个小问题，交给不同角色各自处理，再用消息机制把结果串起来。这跟公司里不同岗位协作是一个逻辑：客服接单、运营查库存、法务审条款、财务做结算，没有人会要求一个岗位从接单干到对账。多智能体的意义不是让模型“变聪明”，而是让每个 agent 的职责边界变得清晰，上下文相对独立，提示词可以针对单一职责反复优化，出了问题也知道该去查哪一个环节。
1.2 三种协作模式，决定了产品形态的上限
我在实际项目里看到的多智能体协作模式，基本可以归成三类：
- 对话式协作：几个 agent 围绕一个议题来回讨论，像开头脑风暴会。适合创意生成、方案发散，但产出不稳定，过程不可控。
- 工作流式协作：任务被预先编排成有向图，每个节点由一个 agent 执行，执行完把结果交给下一个节点。可控性强，适合流程确定的业务场景。
- 自主式协作：一个“主导 agent”动态决定何时调用哪个“执行 agent”，没有固定流程，灵活但难调试、难评测。
早期大家做通用工具，倾向于把三种模式都塞进一个平台，让用户自己选。看起来是大而全，实际上对行业客户来说，这是把复杂度全踢给了用户。真正到了垂直场景里，我们后来基本只用“工作流式 + 有限自主”的组合：主流程固定，局部环节允许 agent 做小范围决策。
1.3 为什么第一波产品都选择做“通用工具”
回头看，第一波 Multi-Agent 产品普遍偏“通用工具”，不是偶然的。
从供给端看，做通用编排框架的成本最低。搭一个角色管理模块、一套消息路由、几个内置工具，再配个可视化编排界面，技术上确实不难。加上那一时期市面上大量开源的通用编排项目提供了现成底座，团队可以用很小的成本快速拼出一个能演示的东西。从需求端看，Multi-Agent 的想象力太大，几乎每个行业都有“多角色协作”的叙事可讲，资本和市场也愿意为这种想象力买单。
但供给端的“做出来容易”和需求端的“用得起来”完全是两回事。通用工具追求的是抽象能力，把流程、角色、工具都参数化，理论上什么都能配，实际上什么都要客户自己配。而行业客户要的是特定场景里“开箱即用、看得见指标”的解决方案。这个错配，就是通用工具热闹一阵后集体转向垂直化的根本原因。
2. 通用工具的失速点：为什么demo惊艳、上线即翻车
2.1 行业知识不在模型脑子里，也不在通用框架里
我最开始犯的错，是低估了行业知识的重要性。通用 Multi-Agent 框架里，agent 的能力完全依赖模型预训练时积累的公开知识。拿来处理泛化的文字任务，比如写新闻稿、做摘要、翻译，问题不大。但一旦进入具体行业，模型的知识就是“听过很多行业，但真不懂你家业务”。
举一个真实例子。某家做合同审核的客户希望 agent 能判断条款是否有风险。通用框架里的“法务 agent”可以背出法律常识，但当客户问“这条逾期违约金上限是否符合我们集团内部‘单笔不超过合同总额8%’的规定”时，模型根本不知道这家集团有这个内部标准。它不是能力不够，而是没有连接企业内部的规则库。
这个差距在 demo 阶段看不出来，因为你演示的是“通用常识”，一到真实数据上跑，准确率马上崩。行业客户付费买的从来不是“AI 常识”，而是“行业知识 + 企业私有规则 + 业务系统的实时数据”。
2.2 评估方式存在系统性偏差
通用工具时代，对 Multi-Agent 的评估基本停留在“内容质量”层面：回答是否有逻辑、是否全面、语气是否自然。这种评估方式有一个前提假设——任务的终态是“生成一段文字”。但行业业务里，任务的终态往往是“完成一个动作并且结果正确”：库存是否扣对、工单是否派给正确的人、报表数字是否和对账系统一致。
有一个客户项目让我印象很深。某个用通用框架搭的客服问答 agent，在演示时对答如流，客户满意度测试也很高。但我们把线上真实对话导入后，发现 agent 在无法处理的时候会“一本正经地编造解决方案”。从 NLP 角度看它生成的内容很流畅，从业务角度看它在制造事故。根本问题就是评测指标设计错了——只看了“生成了什么”，没有看“做的事情对不对”。
垂直行业方案在这一点上有本质区别：必须在产品定义阶段就明确业务指标，比如异常处理率、平均处理时长、人工复核率、误判成本，而且这些指标要有历史基线做对照。没有基线，就没有“更好”，只有“感觉看起来不错”。
| 对比维度 | 通用工具思路 | 垂直行业解决方案 |
|---|---|---|
| 知识来源 | 模型预训练知识为主 | 企业知识库+私有规则+实时数据为主 |
| 任务边界 | 开放域，什么都能聊 | 明确流程节点，只处理约定场景 |
| 评测方式 | 文本质量、内容相关性 | 业务结果、成本节约、时效提升 |
| 系统对接 | 通用API，演示级 | 企业老系统适配，权限与审计全打通 |
| 交付模式 | 平台+自助配置 | 解决方案+持续运营 |
2.3 系统集成的复杂度被严重低估
第三个失速点是技术层面的：把 agent 接入客户的真实系统，难度远超“调个 API”。大多数行业客户的业务系统不是为新工具准备的，有的是老掉牙的本地部署系统，数据库表结构混乱得让人怀疑人生，接口文档过时，字段含义要靠问老员工才知道。通用工具通常在架构上只考虑了“标准化的数据接入方式”，一旦遇到真实系统，集成时间会远超预想。
这个坑我后来有一个比较务实的应对思路：不要一上来就追求“全系统的 agent 化”，而是先画清楚客户的系统地图、数据流和关键操作点，然后选取与流程最相关、数据质量最高的两三个节点先做。用一个细分的工具连接器去适配一个具体的系统操作，比做一个“万能连接器”靠谱得多。系统集成不是技术活，是梳理业务脉络的过程。
2.4 成本与延迟，是通用方案最容易爆掉的隐形雷
还有一个容易被 demo 阶段忽略的问题，就是成本和延迟。多智能体天然比单模型调用更贵、更慢。每个 agent 都要独立的上下文，agent 之间来回通信，一次完整任务下来，token 消耗可能是单轮问答的几十倍。通用工具对成本的控制手段无非是设上限或者限制轮数，但业务场景里，任务复杂度往往不可控。
我在一个电商场景里遇到过极端情况：一个简单问题，四个 agent 来回串了十几轮，最后给了一个其实可以一句话回答的结论。技术上没错，但放在真实环境里既慢又贵，客户看完说“这还不如人工”。后来我们所有垂直项目都强制加入轮次上限和降级逻辑：默认最多两轮协作，解决不了就直接转人工，把关键决策交给确定性规则，而不是让 agent 无限发散。成本意识必须从产品第一天就建立，晚了就变成事故。
3. 垂直化的关键改造：把行业规则做进agent的工作流
3.1 让“流程剧本”替代码替 promp 兜底
通用工具习惯让 agent 拥有很高的自由度——任务来了自己拆解自己执行。垂直方案要反过来：先定义好流程剧本，再让 agent 在剧本框架内做事。
我举一个实际做过的供应链订单异常处理场景。客户的业务是：订单进来后，需要检查库存是否充足、合同条款是否允许分批交货、账期是否正常，然后决定是正常履约还是走异常审批。如果用通用 agent 来处理，prompt 会把所有情况都语义化地写在提示词里，让模型自己判断。现实情况是模型容易漏分支，而且出了错很难定位。
我们后来的设计是三段式剧本：
- 数据采集阶段：由一个固定的工具 agent 调用订单、库存、合同、客户信用四个数据源，把结果整理成统一字段。
- 规则判定阶段：这条路径不经过模型，走确定性规则引擎，用 if-else 判断订单是否异常、异常类型是什么。
- 协同处理阶段：只有触发“合同补助”“信用预警告”这种需要解释和沟通的场景，才启动多个 agent 协作。
这个结构的好处非常明显：把所有能用规则完成的部分从模型那里拿回来，agent 只处理真正需要语义理解和沟通的部分。模型的不可控性被压缩到最小，系统整体可解释性大幅提高。流程剧本的本质是把业务专家脑子里的经验显式画出来，而不是指望模型隐式学会。
3.2 行业知识底座的“三层结构”
垂直化必然要解决行业知识注入问题。我的做法是把知识体系拆成三层：
第一层是企业规则库。这是最核心的，也是最高优先级的。比如审核规则、折扣规则、风险红线、合规要求。它们有明确的逻辑表达式，适合做成结构化规则，放进规则引擎或作为检索底库里的高权重文档。在 agent 做任何决策时，规则库要先于模型知识生效。
第二层是行业语料库。包括行业内的标准术语、操作手册、历史案例、常见问题解决方案。这些通常是非结构化的文本，通过向量化后做成检索增强库，供 agent 在需要时按语义检索。这里需要特别注意版本管理——行业条款和政策会变，语料库必须做时间戳和生效标记，不能把废止的规则喂给 agent。
第三层才是模型通用知识。它只是兜底的，处理那些规则库和语料库都没有覆盖到的边界问题。设计原则很简单：模型的能力用在对规则的解读和解释上，而不是用来创造新的业务规则。
3.3 用最小协作模型跑通闭环
垂直化改造最容易失败的方法，是一上来就铺一个大而全的架构。我建议先选一条价值最明确、数据条件最好的真实业务线，用最小协作模型跑通端到端闭环。
以订单异常处理的场景为例，我当时定义的 agent 集合特别克制，就三个角色：
- 订单识别 agent：负责读取订单信息和客户资料，完成目标识别、标签提取，不决策，只产出结构化描述。
- 方案 agent：根据规则引擎给出的异常类型，从历史类似案例库中检索最优处理路径，给出一个带置信度的建议方案。
- 通知 agent：把建议方案翻译成不同对象能看懂的文本，比如给客服的完整说明、给客户的简短解释、给法务的风险提示。
三个 agent 之间只通过结构化 JSON 消息通信，每个 agent 的工具调用范围也被严格限定。
# 简化示意：最小协作模型的执行骨架 def run_order_exception_pipeline(order_id): order_data = call_data_source("order", order_id) exception_code = rules_engine.check(order_data) # 确定性规则引擎判定 if not exception_code: return {"action": "normal_fulfill", "reason": "no rule triggered"} candidate_plan = plan_agent.search_cases(exception_code, order_data) user_notice = notify_agent.render(candidate_plan, audience="customer") internal_ticket = notify_agent.render(candidate_plan, audience="operations") return { "action": "exception_review", "plan_id": candidate_plan.id, "needs_human_approval": candidate_plan.confidence < 0.85 }这套设计的关键点在于，真正的主流程是规则引擎控制的，agent 只负责“理解并丰富”它经手的那一小块内容。这既发挥了模型的理解与生成优势，又把决策可靠性交给确定性逻辑，客户最终能接受，正是因为这个边界清晰。
3.4 指标必须从“回答得好”换成“业务向好”
垂直行业方案上线后，衡量的标准完全不同。通用工具看的是内容质量分，垂直方案看的是三类业务指标：
- 时效类：平均处理时长从多少小时降到多少分钟。
- 准确类：判定准确率、漏报率、重做率、合规通过率。
- 成本类：单位处理成本、人工介入率、人力节省。
每类指标都必须有上线前的历史基线，并且要有一个“如果新系统不如基线就回滚”的保护机制。有一次客户问我们：“这个 agent 准确率到底多少算好？”我的回答是：“不要问绝对数，问相比人工基线的提升。人工处理同一批异常订单的正确率是多少，你的方案要能比这个基线高，否则 AI 就没有存在价值。”
只有把评测语言换成业务方听得懂、算得清的口径，垂直方案才不再是技术展示，而真正变成可以谈预算的产品。
4. 从调研到上线的四步落地法：场景选择决定生死
4.1 第一步：流程盘点，找“高频、高痛、规则可表达”的切入点
垂直方案的第一步不是画架构，而是做流程盘点。我通常会跟客户的运营负责人、一线执行员工各聊一轮，收集他们日常工作中的高频操作、等候时间、出错点，然后整理成一张流程清单。一个容易踩的误区是只听管理层的描述，管理层往往描述的是“流程应当怎样”，一线员工说的才是“流程实际怎样”。两者之间的差距，通常正是垂直方案能创造价值的地方。
拿到流程清单后，要做一轮初步筛选，把范围缩小到两三个候选场景。筛选的核心标准是三句话：业务频率高不高，人工痛点大不大，规则能不能被表达成可编程的判定逻辑。第三个标准特别关键，如果一个流程非常依赖人的直觉判断，短期内就不要硬做 agent，先做知识辅助类功能可能更稳妥。
4.2 第二步：场景打分，用表格把决策逼到墙角
筛选完就是场景打分。我用的表格很简单，四个维度，每项 1-5 分：
| 维度 | 说明 | 权重 |
|---|---|---|
| 流程确定性 | 是否有明确规则和分支 | 30% |
| 数据可得性 | 所需数据是否已有结构化存储且质量可靠 | 25% |
| 效益可量化 | 处理量、耗时、成本是否有历史统计 | 25% |
| 风险可控性 | 出错下限是造成不便还是重大损失 | 20% |
打分表的作用很直接：避免团队凭感觉选一个“技术上有意思”但“业务上没用”的场景。我们有一次在物流客户那里同时评估了“运单信息补录”和“异常配送协商”两个场景，前者的流程确定性接近满分，后者需要大量临场沟通。公司内部有人倾向后者，觉得更有挑战性，但打分表明确显示前者风险低、见效快。最终先做了前者，上线三个月后积累了足够数据和客户信任，才推动后者。先赢一次，比什么都重要。
4.3 第三步：POC设计，先定义“赢了”再说
POC 不是 demo，不是拿真实数据跑一遍给领导看。一份合格的 POC 设计要先写清楚三个东西。
一是“现有人工基线”的量化数据：过去一个月这个场景的平均处理时长、正确率、人工成本。没有这些，后续任何效果数据都没有参照物。二是“POC 成功指标”，比如异常处理自动率要超过 40%、平均处理时长要降低 30%、人工复核率要低于 20%。三是“边界清单”，明确 agent 在什么情况下必须转人工、什么事情绝不允许 agent 自动决定。边界清单比能力说明更重要，因为它定义了兜底安全网。
POC 的周期我建议控制在四周以内。第一周做数据抽取和基线复核，第二周搭最小协作模型，第三周在前两周基础上做规则补全和 prompt 调优，第四周并行试运行、收集反馈并冻结效果数据。拖得越久，业务方越容易失去耐心，产品口碑越难建立。
4.4 第四步：规模化部署，从“跑通”走向“能养”
POC 通过后，规模化部署面对的是另一批问题：权限管理、审计日志、监控告警、持续迭代机制。权限和审计在垂直行业里不是“加分项”，而是入场券。agent 调用哪些数据、做了哪些操作、给谁发了通知，必须有完整记录，这既是合规要求，也是出错后有据可查的基础。
监控方面，我比较看重两类告警：一类是效果类告警，比如人工复核率突然升高，说明 agent 的输出质量在下降，可能是上游数据变化导致的。另一类是流程类告警，比如某类请求在规则引擎里大量触发“未匹配分支”，说明业务出现了新情况，规则库需要及时更新。
持续迭代机制是垂直方案区别于普通软件项目的关键。行业规则、业务数据、客户需求都会变，固定版本的部署模式不适用于 Multi-Agent 产品。我在项目里会预留一个轻量级的“规则更新”运营流程，由业务方代表每周审核一次新增/变更规则，确认后由产品团队实施更新。这样产品既灵活又有边界，不会变成无人维护的一次性项目。
5. 我踩过的五个坑：角色、协议、评测与成本
5.1 以为 agent 能当“流程专家”，实际它只适合做“流程演员”
最早在某个项目里，我试图让一个“主导 agent”来动态判断流程路径，想着这样更智能。结果发现它经常在自己不确定的时候自作主张地跳到某个分支，而且跳错之后没有任何容错机制。后来我很后悔——当时太迷信模型的推理能力。
纠正后，所有决定流程走向的逻辑都搬回确定性代码和规则引擎，agent 只负责把指定步骤演好。如果你的垂直场景里发现 agent 经常需要判断“下一步该干嘛”，说明你的流程剧本还没写好。好的剧本不会给演员太多临场发挥的发挥空间。
5.2 职责过宽的 agent，是系统最大的不稳定性来源
另一个典型错误是角色设计贪大。一开始我设计过一个“全流程协调 agent”，让它同时负责意图识别、数据检查、方案生成、结果解释。逻辑上觉得自己少写了好几个 agent，实际上这个 agent 的 prompt 极其臃肿，每次任务要携带的上下文巨大，回答风格在不同任务间漂移，调试时完全不知道该改哪里。
后来我把这个 agent 拆成四个职责非常单一的小 agent：识别只做识别，检索只做检索，决策只做决策，表达只做表达。看起来数量变多了，但每个都很稳定，测试用例可以覆盖完整，性能总和反而提升。多智能体的正确用法是“能力足够小，边界足够清”。
5.3 过早把 agent 间的通信协议“标准化”，导致后期返工
做通用工具时，留存下来的一个习惯是把 agent 之间的通信协议设计得特别超前。比如我早期就定义了完整的消息总线、事件溯源、历史回溯机制。听起来很高级，但实际上在业务还不稳定时，这些机制反而拖慢迭代。
在垂直方案里，agent 通信协议第一步只要约定好最简单的 JSON 格式就够了，关键字段、调用方、任务 ID、数据载荷。等流程跑通、理解了真实的数据流之后，再决定哪些信息需要持久化、哪些需要事件机制、哪些可以做重试。过早的架构抽象在大模型时代是浪费时间，因为产品形态演进得太快，前期定义得再完美，后期大概率都要推翻。
5.4 没有先建立人工基线，上线后差点背锅
这是最狼狈的一次。当时我们给一个客户的法务团队做合同风险预审 agent，POC 阶段自己觉得效果不错，准确率也挺高，在客户内部试运行时反馈也积极。结果要写效果报告时，客户问了一句：“你们说的准确率，跟人工审核的准确率比怎么样？”
我们愣住了，因为我们压根没有拉过人工审核的历史结果数据。后来补了半个月数据，才发现人工审核对某类风险的召回率其实非常高，agent 的优势根本没有那么大。这件事教会我一个铁律：任何效果声明，都必须有一个“对照组基线”。没有参考系的高准确率没有意义，尤其当客户已经在用某个基准工作的时候。
5.5 无限轮次协作的魔鬼，藏在 token 账单里
成本问题前面讲过，这里补充一个具体的教训。某次给客户做多语言客服工单分类，设计时用了两个 agent 来回协作：一个做意图识别，一个做情感分析，最后还有个聚合 agent。逻辑正常，但真实数据里有大量噪音和歧义。有的工单触发 retry，agent 之间会反复就同一个问题多次确认。月底看账单，token 消耗超出预估的 4 倍多，客户险些叫停项目。
从那以后，我所有项目都强制设置硬性上限：单个任务的协作轮数不超过两轮，超出直接转人工或者走保底规则；每个 agent 的工具调用次数单独计数；上线前做一次基于真实语料数据的成本模拟。大模型能力再强，也抵不过无节制地空转。
写在最后的一点体会
从通用工具转向垂直行业解决方案，回头看并不是一个“降维”的过程，反而是对 Multi-Agent 认知的一次升级。通用工具让人看见技术的可能性，垂直方案才让人真的可以把技术变成利润表上的数字。我现在做新项目，很少再问“这里能不能塞一个 agent”，而是先问“这个环节的业务规则是什么、数据在哪、失败了下限是否可以被接受”。如果这三个问题没有答案，再强的多智能体架构也只是空中楼阁。
如果你正打算在这个方向推产品，我的建议很简单：别贪多，选一个足够痛、足够窄的场景，把流程剧本、知识底座、评测基线三件事做扎实，然后用一个真实的业务指标证明给客户看。初期的几个成功案例，比任何架构理念都更有说服力。Multi-Agent 本身不是产品，产品是它在某个业务里交付的明确结果。
