团队里第一次讨论要不要上 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 的最小闭环跑通，验证清楚效果和成本，再逐步扩展。框架抄得来，但踩坑的体感、对业务的理解、对模型边界的把控，才是这套架构能不能真正落地生根的关键。
