团队里第一次讨论要不要上 MultiAgent 的时候争议其实挺大的。单 Agent 配合工程化工具已经能解决不少问题再引入一套“多个智能体互相协作”的框架听起来很酷但落地起来像在给自己挖坑任务怎么拆上下文怎么传模型之间互相干扰怎么办出了问题怎么排查这些都是在 PPT 上看不到的问题。得物这边在商品信息治理、售后纠纷处理和商家入驻审核几个场景里确实遇到了单 Agent 天花板——不是模型能力不够而是单个 Agent 没法同时扮演好几个角色既要理解全局意图又要执行细粒度动作提示词写到后面几乎没法维护。所以我们最终选择了一条更工程化的路线用 Plan 模式让 Agent “先想后做”用主子 Agent 的协作结构把职责彻底分开。这篇文章就把这套方案的设计思路、核心机制和落地过程中踩过的坑完整写出来希望对正在评估 MultiAgent 的同学有实际帮助。1. 为什么企业级场景需要“Plan 模式 主子 Agent”1.1 单 Agent 在企业场景里的三个天花板先聊聊我们为什么要换架构。单 Agent 做原型demo很快丢一个任务进去它自己思考、调用工具、输出结果看起来很完美。一旦放到企业真实业务流里问题就一点点暴露出来了。第一个问题是提示词越来越臃肿。一个 Agent 要处理商品信息校验又要处理图片审核还要对接售后策略库所有指令、约束、工具说明全部塞进同一个 system prompt很快提示词就到了几千字。模型面对这么长的上下文指令遵循能力会肉眼可见地下降经常出现“前面的规则记住了、后面的规则忘了”的诡异情况。第二个问题是职责边界模糊。企业场景对权限和审计有硬性要求比如售后仲裁 Agent 只能读取订单数据、不能修改价格商品审核 Agent 只能输出审核结果、不能直接下架商品。单 Agent 把所有能力都揉在一起权限控制很难做得干净基本靠提示词约束万一被诱导越权后果很严重。第三个问题是排查困难。单 Agent 内部推理链路是个黑盒出了问题你不知道是意图理解错了、工具调用错了、还是模型自己幻觉了。线上告警来了只能看日志猜效率特别低。1.2 Plan 模式把“想”和“做”分开Plan 模式的核心理念很简单让 Agent 先输出一份完整的执行计划再按照计划逐步执行而不是拿到任务就开始自由发挥。我们参考了类似 BabyAGI 和 HuggingGPT 的思路但做了不少工程化改造。在得物这套方案里Plan 不再只是模型输出的一段“想法”而是一个结构化的任务列表包含任务ID、任务目标、依赖关系、预期产出、调用哪个子 Agent。这份计划要经过格式校验和业务规则校验校验通过之后才真正进入执行阶段。这样做的好处非常明显。第一计划可审核业务方可以在任务执行之前就看到 Agent 打算怎么做相当于给 AI 加了一道人工审批的闸门。第二执行可追踪每个子任务对应一条独立日志卡在哪一步一目了然。第三中途可干预如果计划有问题可以直接调整某几个子任务而不是整个任务推倒重来。1.3 主子 Agent让专业的人干专业的事主 Agent 在得物这套架构里相当于“项目经理”负责理解用户目标、拆解任务、调度资源、汇总结果但它自己不去执行具体业务动作。子 Agent 则是“一线员工”每个只负责一个狭窄的领域比如图片审核 Agent 只处理图片售后策略 Agent 只查询售后规则库商品信息 Agent 只负责比对商品详情。这种协作结构本质上是一种职责隔离。主 Agent 的提示词可以控制在合理长度专注于“规划”这一件事子 Agent 的提示词也能保持精简专注于“执行”这一件事。两边互不干扰各自迭代升级都不影响对面。我在实际落地中最直观的感受是以前单 Agent 调优改一个场景的规则要反复测好几个相关场景怕影响别的功能。现在主子 Agent 结构下改子 Agent 的提示词只需要回归它自己的测试集主 Agent 的规划逻辑完全不受影响。这个维护成本的优势在项目进入长尾优化阶段后会越来越明显。2. 整体方案设计与技术选型2.1 得物业务场景下的任务类型梳理动手设计之前我们先把候选场景过了一遍发现适合 MultiAgent 的业务任务大致可以分成三类。第一类是“流程编排型”比如商家入驻审核需要依次完成资质核验、经营类目识别、风险规则匹配、人工复核工单生成每一步依赖上一步的输出。这类任务天然适合 Plan 模式因为流程相对固定计划的质量直接决定最终效果。第二类是“多源信息聚合型”比如商品信息治理需要同时比对用户提交的信息、历史商品库、外部品牌数据库、图片识别结果最后给出置信度判断。这类任务适合主子 Agent 并行处理各个子 Agent 互不依赖主 Agent 只需要做结果汇总和冲突消解。第三类是“决策推理型”比如售后纠纷仲裁需要结合订单状态、物流信息、用户描述、平台规则综合判断责任归属。这类任务对上下文的完整性要求很高需要主 Agent 在拆解任务时就把关键信息分发给对应子 Agent避免某个子 Agent 因为信息缺失而误判。2.2 主 Agent 与子 Agent 的角色边界定义角色边界是这套架构里最重要的设计决策。我们一开始犯过模糊边界的错误后来用一张 RACI 表把职责彻底理清了。主 Agent 的职责范围包括接收原始任务、判断任务类型、生成执行计划、调度子 Agent、收集结果、处理部分失败、生成最终回复。主 Agent 明确不做的事包括直接调用业务工具、访问业务数据库、做细粒度的内容判断。这些动作必须由子 Agent 完成。子 Agent 的职责范围包括接收主 Agent 下发的单个子任务、调用自己领域内的工具、返回结构化结果。子 Agent 不做的事包括拆分任务、调整执行顺序、决定其他子 Agent 的行为。这个边界定义的好处体现在权限管控上。每个子 Agent 绑定一组最小权限的工具集合主 Agent 即使被恶意提示词攻击它手上也没有业务工具可用最多就是发出错误的调度指令而这些指令在子 Agent 侧还会再做一次合法性校验。权限和安全不是靠提示词约束而是靠系统架构约束。2.3 技术选型自研编排层还是直接用编排框架技术选型阶段我们对比过 LangGraph、AutoGen、CrewAI 这些开源框架也认真考虑过完全自研。LangGraph 在状态机编排上确实很灵活支持循环、条件分支、并行节点Python 生态也成熟。AutoGen 的多 Agent 对话模式在做“讨论型任务”时很有优势。CrewAI 的上手成本最低角色定义和任务分配都很直观。但最终我们选择自研编排层核心原因有两个。第一得物的业务系统主要走内部服务化架构编排层需要深度对接内部 RPC、消息队列、权限中心、审计系统开源框架在这层的扩展成本反而比自研更高。第二多 Agent 编排的复杂逻辑其实不在“怎么把多个模型串起来”而在于状态管理、重试策略、人工审批节点、可观测性这些工程能力这些恰恰是开源框架最薄弱的地方。结论就是如果你的场景以快速验证为主CrewAI 是个不错的起点如果要上生产且深度绑定企业基础设施自研编排层是值得投入的。3. Plan 模式与主子 Agent 协作的核心机制拆解3.1 执行计划的数据结构与生成策略先看数据模型。我们用一个 Pydantic 模型来约束执行计划的结构字段设计如下class SubTask(BaseModel): task_id: str agent_type: str objective: str input_data: dict dependencies: list[str] [] timeout_seconds: int 60 max_retries: int 2 class ExecutionPlan(BaseModel): plan_id: str goal: str subtasks: list[SubTask] fallback_strategy: str terminate选择 Pydantic 而不是自由 JSON 格式是为了让模型输出严格遵循 schema解析阶段能尽早发现格式错误。实际测试下来强推理模型在给定明确 schema 之后生成格式错误的概率大概在 3% 左右我们会在解析失败时重试一次把错误信息回传给模型让它自己修正。生成策略上我们先试过“一次性生成全量计划”后来改成“先生成一级计划、执行过程中再动态展开二级计划”。原因是电商场景的任务变数很大比如售后纠纷处理到中途突然发现需要额外调取聊天记录一级计划的子任务里根本没预留这一步硬要一次规划完整就只能重新生成全部计划浪费大量 token。现在采用的是混合策略主 Agent 首先生成粗粒度的一级计划每个子任务执行前再由对应的子 Agent 自己生成细粒度的动作序列。这样既保证了全局方向可控又给执行阶段留了灵活调整的空间。3.2 状态机驱动的执行循环执行循环是整个编排层的心脏。我们没有用“主 Agent 一杆子插到底”的方式而是实现了一个有限状态机每个任务实例在状态机里流转。任务实例的状态包括PLANNING规划中、WAITING_APPROVAL等待人工审批、READY就绪、IN_PROGRESS执行中、WAITING_DEPENDENCY等待依赖任务、SUCCEEDED成功、FAILED失败、TERMINATED终止。每个状态转移都有明确触发条件。比如子任务依赖全部完成后状态从 WAITING_DEPENDENCY 自动迁移到 READY调度器扫描到 READY 状态的任务就分发给对应子 Agent子 Agent 返回结构化结果后任务迁移到 SUCCEEDED。状态机的好处是任何时刻系统都知道任务处于什么位置出现异常时可以精确判断是卡在等待依赖、还是子 Agent 超时、还是结果校验失败。配合上埋点日志线上问题定位从“大海捞针”变成了“看状态转移记录”排查效率提升非常明显。3.3 子 Agent 的上下文隔离与关键信息传递这是我在整个项目里觉得最核心、也最容易踩坑的环节。第一版实现里我们天真地把主 Agent 接收到的完整上下文一股脑传给每个子 Agent结果子 Agent 效果反而变差甚至出现幻觉。原因很好理解子 Agent 专注单一领域它的提示词是围绕这个领域优化的。当上下文中混入大量无关信息时模型注意力被干扰反而忽略了真正重要的业务字段。我们的解决方案是“最小上下文原则”主 Agent 在拆解任务时不传原始上下文而是从原始数据里抽取与子任务相关的字段组装成一个精简的输入包。比如售后策略子 Agent 只需要订单编号、商品类别、用户诉求、争议类型它不需要知道商品的具体品牌和价格。这套机制落到代码上就是一个上下文过滤函数def build_agent_input(subtask: SubTask, raw_context: dict) - dict: required_fields SUBTASK_FIELD_MAP.get(subtask.agent_type, []) filtered {field: raw_context.get(field) for field in required_fields if field in raw_context} return {task: subtask.objective, data: filtered}字段映射表 SUBTASK_FIELD_MAP 放在配置中心业务方可以随时调整每个子 Agent 需要哪些字段不用改代码。3.4 结果归约与冲突消解子 Agent 各自执行完任务后主 Agent 要做结果归约。这里也有一个反直觉的教训不要让主 Agent 直接面对所有子 Agent 的原始输出否则上下文会迅速膨胀而且细节太多反而干扰最终判断。我们的方案是分层归约。第一步每个子 Agent 输出统一格式的结构化结果包含结论、置信度、关键证据置信度低的结论要附上原因。第二步主 Agent 只读取这些结构化摘要不再读取子 Agent 的完整推理过程。第三步遇到冲突结论时主 Agent 会将冲突项再次下发到相关子 Agent 做二次确认。比如商品信息治理场景里图片识别子 Agent 判断商品疑似高仿商品信息子 Agent 判断用户提交的字段完整且匹配。两个结论冲突主 Agent 不会自己拍板而是把图片识别结果和字段对比明细打包发给一个专门的“风险复核子 Agent”由它做综合判断。这个机制实际上是一种最小化的人工干预策略只有在二次确认仍然无法消解冲突时才会生成人工审核工单。4. 从 POC 到生产环境的实战过程4.1 阶段一用灰度场景验证可行性我们选的第一个试点场景是售后纠纷的“责任归属预判”。选择这个场景是因为它有明确的规则库、清晰的历史仲裁结果、以及相对完整的结构化数据非常适合评估 MultiAgent 的效果上限。POC 阶段我们只搭了一个最小闭环主 Agent 接一个任务拆成“订单信息抽取、物流轨迹分析、售后规则匹配、历史案例检索”四个子任务四个子 Agent 并行执行最后主 Agent 汇总生成预判结论。评估指标用了三个结论准确率、处理时长、人工介入率。跑了大概两周用历史工单回放的方式持续验证准确率从最初的 78% 提升到 91%处理时长平均 12 秒和之前单 Agent 方案持平。最让我惊喜的是人工介入率降到了 15% 以下说明架构本身不会引入额外的决策不确定性。4.2 阶段二补齐企业级能力上生产POC 通过之后真正的考验才刚开始。生产环境要求的事项远比模型提示词调优要多列举几个关键项。权限管控方面每个子 Agent 注册到内部权限中心时需要申请独立的服务账号通过角色绑定限制可调用的 API。子 Agent 在运行时可以拿到服务账号凭据但主 Agent 没有。这意味着即使主 Agent 被诱导要求“直接修改订单状态”它在系统层面也做不到只能下发给子 Agent子 Agent 又会因为服务账号没有对应权限而拒绝执行。审计日志方面所有 Agent 的输入、输出、计划、执行结果、失败原因全部写到统一日志平台字段包括任务ID、Agent类型、模型版本、耗时、token消耗。这些数据一方面用于业务审计另一方面也是后续评测集构建的数据来源。灰度发布方面我们做了双链路对照老的单 Agent 方案处理 50% 流量新的 MultiAgent 方案处理 50% 流量每天对比准确率、处理时长、告警数量。灰度周期跑了一周确认新方案核心指标全面不劣于旧方案后才逐步切到全量。4.3 阶段三效果评估与持续优化上线之后我们建立了一套离线回归测试机制。每周从线上抽取 500 条真实任务人工标注预期结果然后用最新模型跑一遍全流程计算与人工标注的匹配率。这个数字每周同步给业务方用来判断模型迭代和提示词调整是否带来了真实提升。优化方向上我们发现两个高收益点。第一个是子 Agent 的模型选型不用统一图片分析用视觉模型文本分类用中等规模模型只有主 Agent 用最强推理模型。这样整体成本相比“所有环节都用大模型”能下降约 40%。第二个是计划生成阶段的重试机制我们引入了“计划校验 Agent”专门检查主 Agent 生成的计划里有没有明显错误比如依赖关系矛盾、子任务目标和主目标偏离等。单次校验耗时不到 2 秒但能拦截约 8% 的坏计划避免坏计划执行到一半才发现节省大量 token 和下游资源。5. 常见问题与排查技巧实录5.1 子 Agent 返回结果不稳定格式突然乱掉这个问题在切换模型版本后最容易出现。现象是子 Agent 偶尔不按 JSON Schema 返回直接输出一段自然语言导致解析器报错。排查思路分三步走第一步看是不是提示词里 schema 描述不够清晰第二步看是不是模型版本更新后行为漂移第三步看是不是输入数据里出现了提示词里没有覆盖到的边缘情况。我们最终的兜底方案是三层防线解析失败后先自动重试一次并带上错误信息让模型自行修正重试仍然失败就走“人工接管”分支把原始结果推给人工处理同时把这类失败案例自动沉淀到回归测试集里确保后续版本修复后能自动回归验证。5.2 主 Agent 决策链路过长导致 Token 消耗飙升这个问题出现在一些特别复杂的任务上比如高风险商家入驻审核计划里可能包含 20 多个子任务。主 Agent 在每个子任务完成后都要重新阅读一遍当前进度token 消耗呈指数级增长。优化方案是引入进度压缩机制。每当子任务数量超过 10 个时主 Agent 不再读取每个子任务的完整输出而是维护一个进度摘要器每隔几个任务就生成一份精简的进度摘要。摘要里只包含已完成子任务的结论和关键指标不包含细节过程。这个改造让长任务的 token 消耗降低了 55%同时主 Agent 的决策准确率没有明显下降。5.3 子 Agent 超时导致整个任务卡死第一版我们给子 Agent 设了 60 秒超时超时后直接重试。后来遇到一个问题子 Agent 内部在等待一个外部接口响应超时后重试外部接口还在慢连续重试三次全部超时任务最终标记为失败。问题的关键在于没有区分“可重试超时”和“不可重试超时”。排查后发现外部接口慢导致的超时重试只会加重下游压力应该直接走降级方案。我们在超时策略里增加了一个前置判断子 Agent 在发起外部调用时先记录当前耗时如果检测到外部接口平均响应时间已经超过阈值就跳过重试直接标记为“依赖异常”由主 Agent 决定是继续等待还是切换备用方案。5.4 踩坑清单值得记住的几条教训第一条子 Agent 的提示词不要写太长保持在 800 字以内效果最好。超过这个长度后子 Agent 反而会忽略关键指令尤其是当输入数据里包含和任务无关的字段时。第二条不要试图在编排层完全消除模型的不确定性这在当前技术水平下做不到。设计时要接受“部分失败是常态”把精力放在失败如何快速恢复、如何最小化影响上。第三条上线前一定要建好回归测试集。我们第一次切全量之前就是因为没有完整的回归集某次提示词调整影响了三个关联场景而不自知。现在每次改动都要过一遍回归耗时多但心里踏实。第四条日志里一定要记录 token 消耗。很多同学只关心任务成功率和延迟忽略了 token 成本。AI 应用的成本和业务量是线性关系没有准确的 token 监控预算超了都找不到原因。写在最后的体会整个项目从调研到全量上线花了大概两个半月。回过头看MultiAgent 真正解决的并不是模型能力的问题而是工程复杂度的管理问题。Plan 模式让 AI 的行为变得可预期、可审核、可干预主子 Agent 结构让权限边界和职责边界都变得清晰。这套思路不只适用于得物的电商场景任何有明确业务流程、有权限管控要求、有审计需求的企业级 AI 应用都可以参考同样架构。如果让我给准备上 MultiAgent 的团队一个建议我会说别一上来就追求架构的复杂度。先用一个边界清晰的业务场景把 Plan 模式和主子 Agent 的最小闭环跑通验证清楚效果和成本再逐步扩展。框架抄得来但踩坑的体感、对业务的理解、对模型边界的把控才是这套架构能不能真正落地生根的关键。