最近在帮一家做供应链管理的企业梳理内部 AI 工作流的时候对方负责人问了我一个问题我们单独跑一个智能体、做一个问答机器人效果已经挺惊艳了为什么一旦要它接进真实的业务流程比如订单异常处理、售后工单审核立刻就变得不可靠这个问题我几乎在每家客户那里都听到过。单个 Agent 在演示环境里表现得像模像样一上生产环境就原形毕露状态记不住、工具调错、中间结果没人复核、出了错也不知道去哪个环节排查。原因很简单真实的企业流程从来不是“一段连续对话”而是多个岗位、多个系统、多次交接组成的长链路。你要让 AI 真正跑起来就不能只关注单个 Agent 强不强而是要关心一群 Agent 在一起协作时背后的技术架构能不能撑住。这就是“从 Agent 到 Agentic Collaboration”这条路上最容易被忽视、也最决定成败的地方。这篇文章我想结合这段时间的落地经验把企业 AI 工作流背后的架构分层、关键实现、踩坑记录完整拆一遍。不管你是技术负责人、架构师还是正在把 AI 接进业务的应用开发者应该都能拿走一些可以直接用的东西。1. 先从“一串工具”到“一支队伍”Agent 协作的问题本质很多团队对 Agent 协作的第一反应是多接几个大模型服务让它们互相调用不就行了理论上是这样但实际跑起来完全不是一回事。1.1 单体 Agent 为什么撑不起企业流程单体 Agent 的优势很明显上下文集中、工具调用灵活、部署简单。你给它一个复杂的任务它可以自己规划步骤调一堆外部 API最后给你一个结果。这套模式适合处理“单次交互型”场景比如合同风险初筛、政策问答、技术咨询。它的能力上限在于所有状态都堆积在同一个上下文窗口里一旦流程拉长前边的判断错误会把后边的决策全部带偏。举一个真实的订单异常处理场景用户发起售后工单系统需要先查订单状态、再查库存、再查物流、然后判断是退款还是补发、最后调用财务或仓储接口。单体 Agent 可以串行完成这些步骤但它把所有中间结果都揉在一个上下文里自己在“脑子里”维护状态。一旦中间有一次工具返回格式异常或者某个步骤需要回头修正它很容易把自己绕晕。而且整个过程没有复核环节错了一路错到底等用户投诉、财务对账才发现损失已经造成。说到底企业流程有两个单体 Agent 天然搞不定的特征其一是多步骤、多分支每一步的失败都可能触发补偿逻辑其二是需要多人协作式的校验关键决策不能只靠模型拍板。一个人再能干也替代不了一个有着明确分工、交接和复核机制的团队。1.2 协作不只是“让两个 Agent 聊天”我见过不少团队把两个 Agent 接在一起对话就声称实现了“多智能体协作”。坦白说这基本是伪协作。你让一个 Agent 把任务丢给另一个对方答不上来又丢回来来回几轮上下文膨胀了好几倍钱烧完了活没干成。真正有意义的 Agentic Collaboration本质是“组织分工”不是“多人聊天”。企业内部一个工作小组怎么运转不同角色各有职责范围每个角色只关心自己那部分工作做完产出一个标准化的交付物交给下一个环节。下一个环节不需要知道你内部思考了多久、调用了哪些工具只需要接收一个合格输入再产出合格输出。Agent 协作也应该照这个逻辑来设计。用订单异常处理来说最合理的分工不是让一个 Agent 从头包到尾而是分开成信息采集、根因判断、行动决策、执行操作、结果审计几个角色。“信息采集 Agent”只负责查数据“决策 Agent”只看经过整理的数据出策略“执行 Agent”负责调接口但是自己不做判断“审计 Agent”负责盯结果。每个 Agent 的上下文是独立且精简的消息通过明确结构传递出问题可以按交接记录回放。这样才是企业级协作。1.3 企业落地最需要的能力可控、可管、可复盘我为什么一直强调“企业级”三个字因为个人开发者做 Demo不需要对结果负责企业不行。企业流程涉及钱、合同、用户数据系统的每一次决策都得说得清楚为什么这样判断、调用过哪些系统、花了多少成本、有没有超过阈值需要人工介入。这要求架构不仅是“能把事办成”更得是“可控、可管、可复盘”。可控指的是关键路径上的行为是确定的该查库存一定查库存该转人工一定转人工不能每次运行跑出不同的路线。可管指的是每个 Agent 的角色边界清晰权限可控工具调用有审批。可复盘指的是每次执行都有完整链路记录出了问题能往回追溯。想满足这三点靠“一个巨大 Prompt 全功能 Agent”是做不出来的必须回到分层架构上去解决问题。2. 企业 AI 工作流的架构分层把智能关进“笼子”里我第一次给团队讲分层架构的时候有人问把逻辑写进 Prompt 不也是架构吗短平快确实可以但它扛不住生产环境。我把一个企业级 AI 工作流拆成三层来看基础设施层、编排层、应用层。核心思想就一句话稳定性靠架构智能靠模型确定性靠代码。2.1 为什么不能把一切逻辑都写进 Prompt很多早期项目长这样一个上万字的系统 Prompt里面对话风格、业务流程、工具使用、输出格式全写了。Demo 阶段跑得挺漂亮但上线后就是灾难第一结果不可测。大模型对 Prompt 的理解是概率性的稍微措辞调整输出就变了流程会走出不同的分支。第二权限难控制。如果一个 Agent 什么工具都能调只要 Prompt 里有一句话引导错误它就可能调用不该调的接口。第三成本难优化。全部消息都塞在一个上下文里token 消耗随对话轮次线性上涨。第四问题难定位。所有行为纠缠在一个模型调用里出了问题你不知道是 Prompt 的问题、还是工具返回的问题、还是上下文被污染的问题。我在实际项目里的原则很简单凡是可以用代码写清楚的逻辑比如状态流转、权限校验、超时重试、金额上限判断绝对不丢给大模型决策。大模型只做它擅长的事语义理解、信息抽取、方案生成、自然语言润色。流程骨架是确定的Agent 只是骨架节点上的“智能执行器”。2.2 基础设施层模型网关、向量库与工具注册中心这一层是整个架构的地基很多团队忽略它直接写业务逻辑后面才来补课。模型网关解决的是“接入混乱”问题。企业内部往往同时测试多个模型服务不同产品线的需求也不一样有的要便宜有的要回复快有的要复杂推理强。没有统一网关每次换模型要改代码成本记录也散在各处。我做模型网关的时候至少会封装这几个能力统一调用接口、路由策略按任务类型分发到不同模型、限流与重试、token 成本统计。网关层把大模型当成可替换的组件业务代码不直接依赖具体供应商。向量库在企业 AI 工作流里扮演“长期记忆”的角色用来存放企业私有知识和历史沉淀比如政策文档、历史工单、过去的协作记录。它的作用不是替代数据库而是提供一种语义检索能力。多 Agent 系统里向量库同时也是共享记忆的落点后续上下文管理那一节我会重点展开。工具注册中心是我最想强调的部分。很多团队把工具描述写在 Prompt 里让大模型自己发现并用 JSON 去调用。Demo 可以生产不行。我建议把企业系统的每个能力封装成标准工具注册到中心每个工具包含名称、用途、输入 Schema、输出 Schema、调用地址、权限范围、超时时间、频控限制。注册中心同时也暴露给编排层做路由判断而不是每次都靠模型自己发挥。2.3 编排层确定性状态机与动态路由的取舍编排层处理的是“下一步干什么”。业界有两种风格确定性工作流和智能动态路由。确定性工作流就是预先画好流程图第一步做什么、条件分支怎么走、异常怎么处理。适合稳定且可穷举的流程比如工单分类、订单查询、退款审核。优点是可控、可调试、可审计缺点是不够灵活业务流程一变代码就要跟着改而且对没预见过的场景毫无办法。智能动态路由则是让 Agent 自己决定下一步调用什么工具、交给哪个 Agent。这种方式灵活能处理开放性问题比如“帮我分析这个季度的销售异动原因”但不可控Agent 可能走出一条谁也想不到的路径也可能陷入死循环成本还波动很大。我在企业落地时强烈推荐“确定性为主、动态决策为辅”的混合模式。主流程用状态机固定住每个状态内部保留模型的决策空间。类比就是流水线固定不变但工位上的工人可以自己选择用什么工具把活干完。以退款流程为例是先审计还是先执行这是流程规定不能用模型来决定但“该客户的退款理由是否合理”“风险等级高不高”这种判断可以交给模型。固定的是框架智能的是决策节点。2.4 应用层任务分解、上下文传播与结果聚合应用层是和业务最贴近的一层直接接收用户请求负责拆解任务、分配 Agent、收集结果。任务分解的质量决定了协作的成败。有两个核心点一是要识别依赖关系二是要控制拆分粒度。拿“客户投诉物流慢并要求补偿”这个请求来说你不能简单切成“查物流”和“给补偿”两个并行任务因为“是否补偿、补多少”依赖查物流的结果。拆任务时必须保留依赖拓扑有的要串行、有的可以并行。拆分粒度也不要太细一个 Agent 能完成的事情硬拆成三步只会增加通信和交接成本还会放大出错概率。上下文传播是应用层另一个关键职责。不是每个 Agent 都需要看全量对话历史。我通常设计一个上下文构建器每个 Agent 执行前临时组装它需要的背景信息用户原始输入的部分片段、前置 Agent 输出的结构化数据、向量库检索到的相关知识。只投喂必要信息既省 token也让 Agent 不容易被无关信息干扰。结果聚合则是把各个 Agent 的产出合并成用户能看懂的最终答复同时保留结构化中间结果方便后续审计和二次处理。3. 多 Agent 协作的几个关键技术细节架构分层定下来之后真正决定项目能不能稳定跑的是几个细节。这些细节在原理文章里经常被一笔带过但落地时每一个都能让你折腾一周。3.1 通信协议先定义好消息信封再谈协作Agent 之间传递的消息不能是“一段自然语言聊天记录”必须是结构化消息。我的做法是统一信封格式至少包含以下字段{ task_id: T20240501001, trace_id: TR_8fd2k3, message_id: M_001, from_agent: analysis, to_agent: execution, message_type: decision_result, priority: normal, deadline: 2024-05-01T10:00:00Z, payload: { action: refund, amount: 199.0, reason: item_damaged, order_id: ORD123456 }, schema_version: 1.0 }task_id 是业务实例 ID属于哪个工单一目了然。trace_id 用于链路追踪一次完整协作里所有 Agent 调用共享同一个 trace_id。from/to 明确消息方向message_type 约定语义类型。payload 是具体业务数据不夹杂任何自然语言。这套消息结构有三个直接好处支持可靠重试执行 Agent 收到消息后即使中途挂了重放消息还能恢复现场支持链路追踪每个消息在哪个环节耗时多少都能记录支持权限控制目标 Agent 只需要校验 message_type不用去解析自然语言过滤非预期消息。我在带团队时要求所有 Agent 之间的通信都必须走这个信封一旦有人图省事直接传字符串后面排障就会非常痛苦。3.2 上下文管理别把所有对话历史到处塞多 Agent 系统里最常见的技术债是把所有历史记录塞给每个 Agent 做“记忆增强”结果上下文越滚越大token 成本直线上升模型注意力被无关信息稀释输出质量反而下降。解决思路是“上下文按需投递”。每个 Agent 只维护自己的最小上下文并且在入口处用一个 context builder 来组装。我通常会写一个这样的逻辑def build_minimal_context(agent_role, task_meta, historical_events, knowledge_base_client): context [] # 只附加与当前任务直接相关的背景信息 if agent_role decision: # 决策 Agent 只需要订单摘要、物流状态、风险提示不需要原始聊天记录 context.append(fOrder summary: {task_meta[order_summary]}) context.append(fLogistics status: {task_meta[logistics_status]}) if task_meta[risk_hit]: context.append(fRisk alert: {task_meta[risk_reason]}) elif agent_role execution: # 执行 Agent 只需要决策结论不需要知道为什么这么决策 context.append(fExecution instruction: {task_meta[decision]}) # 按需检索知识库不要全量灌给模型 if task_meta.get(need_knowledge): hit_chunks knowledge_base_client.search(task_meta[query], top_k3) context.extend([f[Knowledge] {c} for c in hit_chunks]) return \n.join(context)这里的核心思想是上下文不是“越多越好”而是“够用就好”。决策 Agent 需要知道采购原因和成本数据执行 Agent 只需要知道执行动作和参数。如果没有这种隔离一个 Agent 的错误输出很容易污染另一个 Agent 的判断。共享记忆的处理也值得单独说。我把跨 Agent 的共享记忆放到外部存储里比如向量库存放语义化的历史记录KV 存储存放短期业务状态。每个 Agent 读取记忆的时候都有权限范围和维度限制不是谁都能访问全部记忆。这样既保证信息共享又避免“群体幻觉”某个 Agent 产出了一个错误中间结论其他 Agent 拿不到或者能识别出来不会盲目跟着走。3.3 可观测性从“黑盒”到可追踪多 Agent 系统的排障难度远大于单体应用。单体应用一个栈堆打出来就定位了多 Agent 是一条链路问题可能发生在任意节点而且每个节点还有模型调用输出是概率性的同一段输入两次运行结果都可能不一样。所以可观测性在设计阶段就要考虑。我在项目里至少给每次 Agent 调用记录五类信息输入摘要、输出摘要、使用的工具与参数、token 消耗与耗时、置信度评分。记住这五类数据按 trace_id 汇总成一个完整链路画出来才能回答“系统今天这笔订单为什么处理错了”。落到实现上我会在消息信封里带 trace_id并在公共调用入口埋点。简单点可以直接打结构化日志再装一个轻量日志面板规模大了再接链路追踪中间件。生产环境里还有一个很实用的策略让每个 Agent 返回结构化的“处理摘要”而不是一段自然语言总结比如“已确认订单存在、库存充足、物流延迟2天、建议补发”。这样排障时可以直接在日志面板里扫这些字段快速判断是信息采集错了、决策错了还是执行错了。3.4 幂等与容错生产环境的底线这一条很朴素但是绝大多数从 Demo 走向生产的项目都栽在这里工具调用没有幂等设计。Agent 调用退款接口时网络超时了它会重试如果每次都生成同一个 request_id服务端还能去重如果没有 request_id同一次业务动作可能被执行两次客户收到两笔退款事故级别的错误。我的规则是所有会对外部系统产生副作用的工具调用必须携带幂等键。在前面的消息信封里message_id 就是天然的幂等键。执行 Agent 调用工具时把这个 message_id 传过去外部系统记录并识别重复调用。容错策略也不能靠运气。要在编排层设置明确的兜底动作重试两次还是三次、每次退避多久、失败之后是转人工还是降级到另一条路径。我的建议是重要的资金类操作宁可慢一点也要配置“失败转人工”信息类查询可以多做几次自动重试。系统里要有全局超时和最大协作轮次防止 Agent 之间无限循环把预算打爆。4. 一个客服工单系统的完整落地拆解前面讲了那么多架构和原理接下来我用一个完全虚构但高度还原的“客服工单自动处理”场景把落地过程完整串一遍。用到的企业名称都是代称代码思路可以直接参考。4.1 场景需求与 Agent 划分某电商企业的客服部门每天接到大量售后工单人工处理成本高、响应慢。需求是用户提交工单后系统自动完成问题分类、信息核验、方案决策、自动执行或转人工并生成处理摘要。我按职责边界把任务划分为五个 AgentAgent 名称职责输入输出入站解析 Agent识别工单意图、抽取实体用户原始留言结构化工单要素信息核验 Agent查询订单、物流、库存工单要素核验报告决策 Agent判断处理方案、评估风险核验报告决策结论与置信度执行 Agent调用退款/补发接口决策结论执行结果审计 Agent复核结果、生成摘要执行结果与全过程审计意见与工单摘要这五个角色不是随意划分的。它们对应了企业客服后台真实岗位录入员、查单员、主管、操作员、质检员。每个 Agent 都只做一类事输出有明确格式边界清晰即使某一个 Agent 升级换代其他 Agent 完全不受影响。4.2 数据流与状态机设计这个系统的主流程可以用一个状态机描述。工单状态依次经过待解析、核验中、待决策、待执行、待审计、已完成。如果任一环节出现低置信度或超时状态跳转到待人工复核。分支其实只有两条自动处理与转人工。从“待决策”到“待执行”需要满足前置条件决策置信度高于 0.85且金额在 500 元以内。否则转人工。数据流遵循“上一环节的输出就是下一环节的输入”原则。入站解析 Agent 输出一个 JSON 对象包含 intent、order_id、product、issue_type、user_description信息核验 Agent 拿到这个 JSON 仓库查数据返回 inventory_status、logistics_status、payment_status。决策 Agent 不接触原始用户评论只看核验报告避免被无关情绪化语言干扰。这样就实现了信息隔离每一层拿到的都是“经过整理的事实”。这个阶段我特别提醒状态机一定要把“转人工”设计成一个明确状态而不是异常分支。因为转人工不是失败是系统主动做的风险规避。人工处理完以后还需要一条路径把结果回流到系统更新工单状态。如果这个细节没设计人工处理完的信息在系统里就断了后边审计和数据分析都会缺一块。4.3 核心代码与配置示例状态机我这里用一个简化的状态定义来示意重点看每个节点如何调用对应 Agent# 简化版状态流转定义 state_machine { PENDING_PARSE: { action: invoke_agent, agent: parse, next_on_success: VERIFYING, next_on_error: HUMAN_REVIEW }, VERIFYING: { action: invoke_agent, agent: verifier, next_on_success: DECIDING, next_on_error: HUMAN_REVIEW, max_retry: 2 }, DECIDING: { action: invoke_agent, agent: decision, next_on_success: EXECUTING, next_on_low_confidence: HUMAN_REVIEW, next_on_error: HUMAN_REVIEW, confidence_threshold: 0.85 }, EXECUTING: { action: invoke_agent, agent: executor, next_on_success: AUDITING, next_on_error: HUMAN_REVIEW, idempotent_key: message_id, max_retry: 1 }, AUDITING: { action: invoke_agent, agent: auditor, next_on_success: COMPLETED, next_on_error: HUMAN_REVIEW } }决策 Agent 的 Prompt 我会刻意写得收敛不让它自由发挥太多。它只有一个核心任务根据传入的核验报告输出以下结构的 JSONaction、reason、amount、confidence。同时给它一个风险规则清单比如“高价值订单必须转人工”“用户历史投诉超过3次的标记风险”。这些规则里相当一部分用代码在编排层做前置检查剩下语义判断的部分才交给模型。执行 Agent 的代码里有一个关键点所有工具调用必须带幂等键def execute_tool(tool_name, payload, message_id, executor_client): # 将 message_id 作为幂等键传给外部系统 result executor_client.call( tooltool_name, params{**payload, request_id: message_id} ) return result外部系统在接口层用 request_id 做幂等判断如果之前已经处理过同一个请求直接返回历史结果不重复执行。这一行代码能挡掉生产环境里最危险的那一类事故。4.4 成本控制和效果调优系统上线之后我先做了一轮成本观察。最初所有环节都调用同一种高级推理模型一个工单全链路大概消耗几万 token成本很高。后来我把每个 Agent 的任务难度做了区分入站解析和信息核验这种模式化任务切换到低成本快速模型决策和审计保留高级模型。只做这一个分流整体成本大约降了一半。从延迟角度看并行化收益明显。信息核验本来要查订单、物流、库存三个地方如果按顺序查要串行 3 次接口调用延迟累加。我把它们改成并发查询等所有子结果返回后再组装核验报告整体耗时降了大约三分之一。但要注意只有相互独立的信息查询才能这样并行有依赖关系的步骤绝不能为了省时间盲目并发。调优过程中另一个重要指标是“自动执行率”。一开始系统非常保守动不动就转人工操作员都在吐槽加了套新系统活没变少。后来我不是简单调低置信度阈值而是去看决策 Agent 被拒绝的案例发现很多是因为数据字段缺失导致判断不了。补上缺失字段后自动执行率明显提升。置信度阈值从 0.85 往下调每调一档都要对照误处理率成本节约和风险之间要做平衡。5. 实战中遇到的典型问题与排查手册这部分是我真正想分享的干货。前面是方法下面全是坑。每一个都是真金白银换出来的经验。5.1 Agent 互相“踢皮球”与死循环现象是系统日志里出现同一对 Agent 反复互发消息A 说该 B 处理B 说该 A 处理直到触发最大轮次限制才停既浪费时间又烧钱。根因Prompt 里的职责边界描述不够刚性。模型在模糊语境下会把任务推给“看起来更专业”的其他 Agent或者说一句“这不是我的职责范围”就试图结束任务。对策有三层第一层在编排层设置最大协作轮数和全局超时这是保底必须有。第二层在 Prompt 里写硬约束明确“你收到的任务已经在编排层确认属于你你必须产出结果不得移交其他 Agent除非满足特定条件”。第三层也是最有效的尽量让 Agent 之间不要直接对话所有传话都经过编排层。A 想传消息给 B先把消息发给编排层编排层按预设路由决定是否转发。这样职责边界就从 Prompt 约束变成了代码约束可靠性直接上一个台阶。5.2 上下文爆炸与 Token 成本失控有一次我发现一个工单的链路追踪里最后一个 Agent 的输入上下文里居然包含了前面所有的对话历史连用户最早的原始留言都完整躺在里面。这个工单本身处理逻辑没问题但 token 消耗是正常情况的 5 倍而且随着协作轮次增加还在涨。这种情况基本都是因为共享变量的滥用为了图省事把一份“全局上下文”传给了所有 Agent。模型效果不会因为信息全而变好反而会因为被无关信息干扰而变差。解决方法是严格执行“按需投递”。我后来给上下文构建器加了一个白名单机制每个 Agent 声明自己需要哪些字段构建器只允许透传白名单内的数据。同时引入摘要机制对于长流程不再存全量历史而是用一个“阶段性摘要”替代中间过程。比如决策 Agent 不再关心信息核验 Agent 内部查了几个表只需要接收一条精炼的核验结论。这个机制上线后整体成本明显回落准确率还稳中有升。5.3 幻觉被放大如何建立校验和复核机制多 Agent 系统有个隐蔽风险单一 Agent 的幻觉会在协作链路上被放大后续 Agent 把它当成既定事实继续推导。比如决策 Agent 在核验报告里“脑补”出一个仓库缺货的判断执行 Agent 就真的去生成补发指令。等到审计 Agent 发现不对流程已经走到一半不得不回滚。这种问题不能靠“提示模型别幻觉”来解决要建立程序化屏障。三个做法叠加第一关键节点用结构化输出约束靠 JSON Schema 强制模型输出固定字段和合法取值从格式上过滤掉了大部分胡说八道。第二建立跨 Agent 交叉验证决策结论必须过一遍审计 Agent两者结论一致才算通过。第三引入外部事实校验比如决策 Agent 说“库存不足”编排层可以顺手调一次库存查询接口做实际比对用数据库事实纠正模型幻觉。这三层叠加之后系统整体可信度才谈得上企业级。5.4 排查工具与调试流程多 Agent 系统出问题时第一件事不是看 Prompt而是先拉链路。我会先按 trace_id 把一次完整处理的日志全捞出来按照消息信封里的 from_agent、to_agent 还原协作路径看它实际上走出了哪条路和设计的状态机路径比对偏差点就是问题所在。如果是信息采集环节出错很好判断看核验报告字段值对不对就行。如果是决策环节不合理对比决策 Agent 的 Prompt 和当时输入的行向量看是不是上下文少传了关键字段。如果模型老是输出不合法 JSON优先检查输出 Schema 定义以及是否缺少“必须返回合法 JSON不要解释”的约束。如果偶尔超时去看是外部系统慢还是模型响应慢然后针对性重试策略。调试流程我总结成一句口诀先看链路对不对再看数据准不准最后才调模型和提示词。顺序反了只能闻到烟味找不到火源。写到这里我发现这类项目做得越多越发觉得 Agent 本身没那么神秘难点一直在工程组织上。把一个复杂流程拆成职责清晰的小模块把通信、状态、容错、审计这些基础设计做好比追求单个模型的“聪明程度”重要得多。我现在接新的落地项目第一周基本不碰 Prompt全部时间花在梳理流程边界和消息协议上。这块地基打稳了后面接什么模型都能跑得顺畅。