我最早接触 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, audiencecustomer) internal_ticket notify_agent.render(candidate_plan, audienceoperations) 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 没有先建立人工基线上线后差点背锅这是最狼狈的一次。当时我们给一个客户的法务团队做合同风险预审 agentPOC 阶段自己觉得效果不错准确率也挺高在客户内部试运行时反馈也积极。结果要写效果报告时客户问了一句“你们说的准确率跟人工审核的准确率比怎么样”我们愣住了因为我们压根没有拉过人工审核的历史结果数据。后来补了半个月数据才发现人工审核对某类风险的召回率其实非常高agent 的优势根本没有那么大。这件事教会我一个铁律任何效果声明都必须有一个“对照组基线”。没有参考系的高准确率没有意义尤其当客户已经在用某个基准工作的时候。5.5 无限轮次协作的魔鬼藏在 token 账单里成本问题前面讲过这里补充一个具体的教训。某次给客户做多语言客服工单分类设计时用了两个 agent 来回协作一个做意图识别一个做情感分析最后还有个聚合 agent。逻辑正常但真实数据里有大量噪音和歧义。有的工单触发 retryagent 之间会反复就同一个问题多次确认。月底看账单token 消耗超出预估的 4 倍多客户险些叫停项目。从那以后我所有项目都强制设置硬性上限单个任务的协作轮数不超过两轮超出直接转人工或者走保底规则每个 agent 的工具调用次数单独计数上线前做一次基于真实语料数据的成本模拟。大模型能力再强也抵不过无节制地空转。写在最后的一点体会从通用工具转向垂直行业解决方案回头看并不是一个“降维”的过程反而是对 Multi-Agent 认知的一次升级。通用工具让人看见技术的可能性垂直方案才让人真的可以把技术变成利润表上的数字。我现在做新项目很少再问“这里能不能塞一个 agent”而是先问“这个环节的业务规则是什么、数据在哪、失败了下限是否可以被接受”。如果这三个问题没有答案再强的多智能体架构也只是空中楼阁。如果你正打算在这个方向推产品我的建议很简单别贪多选一个足够痛、足够窄的场景把流程剧本、知识底座、评测基线三件事做扎实然后用一个真实的业务指标证明给客户看。初期的几个成功案例比任何架构理念都更有说服力。Multi-Agent 本身不是产品产品是它在某个业务里交付的明确结果。 Multi-Agent产品化落地指南：从通用工具到垂直行业方案的实践思考
我最早接触 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, audiencecustomer) internal_ticket notify_agent.render(candidate_plan, audienceoperations) 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 没有先建立人工基线上线后差点背锅这是最狼狈的一次。当时我们给一个客户的法务团队做合同风险预审 agentPOC 阶段自己觉得效果不错准确率也挺高在客户内部试运行时反馈也积极。结果要写效果报告时客户问了一句“你们说的准确率跟人工审核的准确率比怎么样”我们愣住了因为我们压根没有拉过人工审核的历史结果数据。后来补了半个月数据才发现人工审核对某类风险的召回率其实非常高agent 的优势根本没有那么大。这件事教会我一个铁律任何效果声明都必须有一个“对照组基线”。没有参考系的高准确率没有意义尤其当客户已经在用某个基准工作的时候。5.5 无限轮次协作的魔鬼藏在 token 账单里成本问题前面讲过这里补充一个具体的教训。某次给客户做多语言客服工单分类设计时用了两个 agent 来回协作一个做意图识别一个做情感分析最后还有个聚合 agent。逻辑正常但真实数据里有大量噪音和歧义。有的工单触发 retryagent 之间会反复就同一个问题多次确认。月底看账单token 消耗超出预估的 4 倍多客户险些叫停项目。从那以后我所有项目都强制设置硬性上限单个任务的协作轮数不超过两轮超出直接转人工或者走保底规则每个 agent 的工具调用次数单独计数上线前做一次基于真实语料数据的成本模拟。大模型能力再强也抵不过无节制地空转。写在最后的一点体会从通用工具转向垂直行业解决方案回头看并不是一个“降维”的过程反而是对 Multi-Agent 认知的一次升级。通用工具让人看见技术的可能性垂直方案才让人真的可以把技术变成利润表上的数字。我现在做新项目很少再问“这里能不能塞一个 agent”而是先问“这个环节的业务规则是什么、数据在哪、失败了下限是否可以被接受”。如果这三个问题没有答案再强的多智能体架构也只是空中楼阁。如果你正打算在这个方向推产品我的建议很简单别贪多选一个足够痛、足够窄的场景把流程剧本、知识底座、评测基线三件事做扎实然后用一个真实的业务指标证明给客户看。初期的几个成功案例比任何架构理念都更有说服力。Multi-Agent 本身不是产品产品是它在某个业务里交付的明确结果。