当 Agent 从单点助手走向真实业务协作,挑战不再是模型是否足够聪明,而是如何让多个 Agent 在企业环境中“分工不失控、协作可追踪、结果可验证、经验能沉淀”。
本次演讲我将分享网易帝王蟹在多 Agent 协作上的实践探索,重点介绍如何进行 Agent 分工与任务编排,如何通过 Skill、上下文、权限和可观测性保障协作质量,以及如何通过评测与复盘让 Agent 能力持续演进。我们希望从实际工程问题出发,回答多 Agent 何时值得使用、如何设计、如何治理,以及如何从一个可运行的 Demo 走向真正可用的生产系统。
演讲提纲
1. 多 Agent 为什么难:从“能协作”到“可交付”
- 从真实业务任务出发,复盘单 Agent 在复杂任务中的问题:上下文膨胀、工具链断裂、任务边界模糊、结果难验证
- 引入多个 Agent 后,新的问题进一步暴露:谁负责什么、如何协同、如何处理依赖、失败后谁接手
- 核心问题从“怎么让 Agent 更聪明”,转向“怎么让多个 Agent 把事情做完”
2. 怎么解决:重新设计 Agent 的分工与协作
- 从真实任务出发设计角色边界:什么由主控 Agent 完成,什么交给领域 Agent,什么场景其实不需要多 Agent
- 将复杂目标拆解为有依赖关系的任务,并明确每项任务的负责人和验收标准
- 将路由、编排、执行、验收分离,分别解决“谁来做、怎么做、做到什么程度”
- 为失败任务设计重试、回滚和人工介入,让协作过程具备可恢复性
3. 让多 Agent 真正跑起来:帝王蟹的工程实践
- 上下文怎么管:共享什么、隔离什么,以及如何通过压缩和按需注入控制上下文成本
- 能力怎么接入:通过 Skill、工具、MCP 和知识库建立统一能力接口
- 任务怎么执行:如何管理任务状态、依赖关系和 Agent 间的交接,保证流程能够持续推进
- 过程怎么观测:记录 Agent 决策、工具调用、任务状态、产物、耗时与成本,让每一次执行都可追踪
- 结果怎么验证:从单纯检查最终结果,扩展到对执行轨迹、证据和过程进行评测
4. 我们踩过哪些坑:从“跑起来”到“跑得稳”
- Agent 并不是越多越好,很多任务用单 Agent 或传统自动化更简单
- 任务也不是拆得越细越好,过度拆分会带来协作、上下文和 Token 成本
- 自主性和可控性需要平衡,高风险任务不能完全交给 Agent 自由执行
- 真正影响效果的往往不是模型本身,而是任务边界、上下文、工具、验收和反馈机制
- 多 Agent 的长期价值不只是完成更多任务,而是把成功经验、失败案例和评测数据持续沉淀下来
5. 未来展望
演讲亮点
- 用“控制面—执行面—能力面—治理面”解释多 Agent 系统,既能讲清技术架构,也能落到企业管理诉求
- 突出网易帝王蟹的核心边界:主控 Agent 负责协调,子 Agent 负责执行;每项任务有唯一负责人、明确输入输出和验收标准
- 不把多 Agent 当作模型能力的简单叠加,而是强调任务图、状态机、上下文工程、权限治理和可观测性这些生产级能力
- 引入“Agent 负责局部智能,Harness 负责全局秩序”的设计理念,建立从 Demo 到生产落地的清晰路径
- 将 Skill、记忆、评测与复盘串成闭环,展示网易帝王蟹如何把一次任务执行转化为组织可复用的能力资产
- 兼顾技术深度与业务表达:既包含路由、编排、状态恢复、轨迹评测,也能回答“为什么值得做、如何衡量价值”
听众收益
- 理解企业多 Agent 的真正难点不在“调用多个模型”,而在协作、治理、验证与持续演进
- 获得一套可迁移的方法论:何时该使用多 Agent、如何拆分角色、如何设计任务图与验收机制
- 掌握帝王蟹在复杂任务中的设计原则:主控协调、子 Agent 专责、Skill 标准接入、状态可恢复、过程可审计
- 能够将多 Agent 能力映射到研发、运维、数据与业务协作等网易内部场景
- 建立一套衡量多 Agent 平台价值的框架:任务成功率、交付时效、人工介入率、Token 成本、安全风险与知识复用率