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

本次分享将介绍飞猪在广告投放场景中建设多 Agent 系统的实践，并以某酒店集团会员增长项目作为落地案例。我们面对的问题不是缺少某个投放工具，而是投放链路被拆散在不同角色和平台中：人群分析、策略制定、素材准备、渠道执行、预算控制、效果回流往往各自为战，阿里妈妈、灯火、小红书、巨量引擎、广点通等投放平台又极度依赖渠道投放经验，整体难以形成稳定闭环。

围绕这个问题，飞猪沉淀了一套端到端的多 Agent 投放系统：把目标理解、人群圈选、策略生成、素材生产、渠道执行、效果复盘等环节拆成相对独立的能力单元，再通过统一的任务 Loop 组织协作。系统既能处理确定流程，也能在真实业务中根据反馈调整下一步动作；同时通过沙箱、权限、日志和评估机制，保证 Agent 在真实投放链路中可控、可追踪、可复盘。

分享还会重点讨论人在系统中的位置。Agent 投放不是让人退出投放，而是把人从重复操作中解放出来，让人更多负责目标设定、策略判断、关键审批、风险控制和跨团队协同。Agent 负责高频执行、过程记录和持续优化，人与 Agent 共同完成从“投出去”到“投得准”的闭环。

演讲提纲

1. 为什么广告投放需要多 Agent 系统 

• 传统投放中的渠道割裂、人工复盘滞后、归因分散 
• 平台视角下的端到端闭环：人群、素材、渠道、预算、回流统一管理 
• 某酒店集团会员增长案例中的落地背景和业务挑战

2. 飞猪多 Agent 投放系统如何设计 

• 将投放链路拆成目标理解、人群、策略、素材、执行、回流等能力单元 
• 通过任务 Loop 串联观察、决策、执行和反馈 
• 用沙箱、权限和观测机制控制真实投放中的风险 
• 从固定流程走向可控的动态协作

3. 企业级落地中遇到的问题 

• 多 Agent 分工不清带来的调度混乱 
• 跨渠道数据回流、归因粒度和隐私限制 
• 预算、配置、投放动作等副作用风险 
• 如何通过实验和评估判断投放效果

4. 人在多 Agent 系统中的新角色 

• 从手动操作转向目标定义和约束设定 
• 从月底复盘转向持续观察和及时干预 
• 从个人经验转向可复用的系统能力 
• 人负责方向和边界，Agent 负责执行和循环

实践痛点

多 Agent 系统落地最大的痛点不是“让 Agent 动起来”，而是让它在真实业务链路中可控地动起来。投放场景里既有策略判断，也有预算、素材、渠道配置等真实副作用，不能简单追求全自动。

实践中首先会遇到 Agent 分工边界的问题：拆得太细，调度和上下文传递成本会上升；拆得太粗，又容易变成一个大模型包打天下，难以治理。其次，从固定编排走向目标驱动 Loop 后，系统具备了更强的动态决策能力，但也带来不确定性，需要通过沙箱、权限、停止条件、日志追踪和人工确认来控制风险。再者，投放效果本身存在归因延迟、跨渠道数据不完整、隐私边界等问题，Agent 的判断不能只看单次输出，而要放到实验、评估和持续回流中验证。

所以这里的 tradeoff 是：自治程度越高，风险治理要求越高；控制越严格，执行效率又会被拉低。我们的实践重点是在“可用”和“可控”之间找到工程平衡。

演讲亮点

• 从固定编排走向可控 Loop，而不是停留在流程自动化。不是把传统投放流程简单串成几个 Agent，而是在真实投放链路里引入“观察、判断、行动、反馈”的任务 Loop，让系统能根据执行结果调整下一步动作。同时通过沙箱、权限、停止条件和可观测机制，把动态决策限制在可治理范围内。
• 把多 Agent 拆解建立在业务能力边界上，而不是模型角色命名上。系统中的 Agent 不是简单按“分析师、文案、运营”这类拟人角色划分，而是围绕目标理解、人群、策略、素材、执行、回流等稳定能力单元设计。这样更容易接入真实工具、沉淀复用能力，也更适合后续做评估、权限控制和问题定位。
• 强调人机协作中的责任边界。不是把目标设成“让 Agent 替代运营”，而是让 Agent 承担高频执行、过程记录和反馈整理，人负责目标、约束、审批和风险判断。

听众收益

• 理解企业级多 Agent 系统为什么要从业务闭环出发，而不是从技术框架出发 
• 学习端到端投放 Agent 的系统拆解方式和工程组织方法 
• 了解 Loop、沙箱、权限、观测、评估在真实 Agent 落地中的作用 
• 获得一套可迁移到营销、增长、运营等复杂业务场景的多 Agent 建设思路

长程复杂优化任务的难点，在于跨轮次保留有效状态、判断反馈是否可信，并在有限资源下持续调整方向。本次分享结合异构芯片算子优化实践，介绍为何将策略调整、候选执行与结果验证适度分离，以及如何衔接任务状态、利用失败记录、决定继续探索或人工介入。通过匿名算子案例呈现不同硬件环境下的优化结果与收益差异，讨论持续执行如何服务于任务进展，以及验证成本、协作开销和局部收益对实际应用的限制。

演讲提纲

1. 场景与问题：复杂优化任务为什么需要持续推进

• 以多种国产芯片上的算子优化为场景，介绍目标明确、路径不确定、实验反馈不断改变后续方向的任务特点
• 梳理持续优化中的主要成本：专业知识获取、反复实现与验证、跨轮次信息交接，以及不同硬件环境下的适配
• 明确系统希望带来的价值：让团队能够持续推进有价值的实验，把专家时间更多用于方向判断、关键问题和结果确认

2. 系统设计：长程任务为什么需要职责分离

• 策略需要根据反馈调整，结果验证则需要保持标准稳定。围绕这一差异，说明为何将探索决策、候选执行与验证适度分离，以及哪些环节无需单独设置 Agent
• 长程探索会积累大量尝试记录，后续决策需要区分已验证结论与待验证假设。讨论如何整理必要上下文，避免过期判断和无效结果持续影响任务。
• 职责分离也会增加交接和验证成本。结合任务依赖、资源约束与专家参与，说明何时值得拆分、何时保留在同一执行单元中。

3. 持续执行：长程任务的状态管理与反馈迭代

• 围绕当前候选、已验证结论和待处理问题保留任务状态，讨论多轮执行、失败后继续及人工接手时，哪些信息需要延续
• 将候选生成与独立验证连接起来，区分验证未通过、结果无改善和出现有效进展等反馈，说明它们如何影响下一轮方向
• 结合收益变化、重复尝试和资源消耗设置停止与转向依据，讨论持续探索的空间和无效循环的成本如何平衡

4. 案例与结果：异构芯片优化的任务过程与收益差异

• 以单个算子优化任务为线索，串联优化目标、候选实现、编译与正确性检查、性能比较及下一轮决策，说明每个环节为后续工作提供什么依据
• 现有记录中，某筛选类算子在 8 组芯片配置下的加速比约为 2.20–7.00 倍；某注意力类算子为 0.317–4.527 倍，部分配置出现性能回退。结合这些差异，讨论收益不足时应重新检查哪些条件
• 面向更普适性的 Infra 层面的推理优化场景，也具备能力的迁移可复用性，在整网模型推理优化在 NV 和异构芯片上均带来了效能的提升

5. 价值与边界：如何判断系统是否值得持续投入

• 结合有效优化结果、达到目标的投入、人工参与和经验复用情况评价系统价值，将算子性能改善与工作方式本身的增益分别讨论
• 说明算子级收益进入真实模型时，还需要考虑调用占比、集成成本和其他系统开销；模型端到端收益是后续验证方向
• 总结适合采用这类系统的任务条件：目标可验证、允许多轮探索、工具能够执行、资源投入可控；讨论其向其他工程优化任务延伸时需要重新验证的部分

实践痛点

• 持续执行与有效进展之间存在距离。长程任务会不断产生新方案和新结果，但更多轮次未必带来更好的结果。系统需要根据已有证据判断是否值得继续，并保留停止和人工调整方向的空间；控制过严可能错失有价值的探索，放开过多又会消耗资源
• 专业分工也会增加协作成本。策略、实现和验证之间需要传递足够的背景与结论。拆分过细容易增加交接负担，信息共享过多又会引入噪声和过期判断。需要围绕真实任务选择合适的分工方式，并明确关键结果由谁确认
• 验证质量决定反馈是否可信。优化结果受输入、运行环境和测量条件影响，局部加速也可能伴随正确性问题或其他代价。验证需要独立于候选生成，避免系统持续沿着错误反馈优化；更充分的验证同时会占用时间和算力
• 跨芯片经验复用存在条件。不同芯片的工具链和运行特征存在差异，同一优化思路的收益也可能不同。可以复用的是问题分析、实验组织和验证方法，具体实现与效果仍需在目标环境中确认，经验整理也需要保留适用条件
• 局部效果与整体价值需要分别衡量。已有实践记录提供了算子级优化的基础，模型端到端收益、相对原有工作方式的投入变化仍需进一步验证。评估时还要计入模型调用、实验算力、专家参与和维护成本，避免仅凭单项最佳结果判断系统价值

演讲亮点

• 围绕长程任务的工程问题展开。以状态延续、反馈可信度和探索成本为主线，结合优化任务说明 Agent 持续执行时需要处理的问题与设计取舍
• 从真实硬件优化任务提炼系统设计。结合多种国产芯片上的算子优化记录，把系统讨论落到可执行、可验证的任务中，呈现环境差异、效果判断与专业知识带来的实际约束
• 解释职责分离的原因。结合探索方向需要变化、验证标准需要稳定这一矛盾，讨论职责分离如何约束错误反馈的累积，以及由此增加的协调和验证成本
• 从小团队的实际使用观察投入价值。结合团队与 Agent 共同推进优化任务的工作方式，讨论专业分工、人工参与和经验积累，帮助听众判断这类系统适合承担什么工作、值得投入到什么程度

听众收益

• 任务选择方法：了解哪些复杂任务适合由多 Agent 持续推进，以及如何从目标可验证性、实验反馈和资源投入判断采用条件
• 系统设计思路：了解长程任务中状态交接、独立验证、反馈更新和停止条件的设计思路，以及职责分离所解决的问题
• 价值评估视角：了解如何结合任务结果、人工投入、资源成本和复用情况评估系统价值，区分局部优化效果与整体交付收益
• 真实场景参考：通过同时包含加速和性能回退的匿名算子案例，理解硬件适配、验证条件和探索取舍对结果的影响