当 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 成本、安全风险与知识复用率