伴随着 LLM 模型能力的持续突破，智能体（Agent）技术正在迎来爆发式发展。从早期以LangChain、LangGraph、ADK 为代表的智能体开发框架，到近一年广受关注的通用智能体应用（如OpenClaw 等），越来越多的个人开发者与企业组织，都已完成了自己的 AI 智能体「初体验」。然而，如何让智能体从「玩具」走向「生产」，已经成为业内共同关注的首要课题。

在智能体奔向生产级应用的过程中，所承载的任务正从「简单」走向「复杂」。尤其在企业场景下，单一智能体叠加 LLM 的能力边界已经清晰显现——如何让企业内的多个智能体彼此连接、高效协作，并与企业存量的 IT 应用资产、数据资产深度联动，进而真正完成企业生产中的真实业务任务，成为智能体在企业侧规模化落地的关键所在。

本次分享将结合字节跳动火山引擎 ArkClaw 智能体平台的建设实践，系统解析 ArkClaw 基于 Agent Mesh 架构的企业多智能体系统治理方案。内容涵盖架构设计理念、核心治理能力、典型落地场景与踩坑经验，帮助企业推动智能体从「玩具」走向「生产」，从「单点」走向「协同」，从「简单」走向「复杂」。

演讲提纲：

1. 智能体技术与应用现状
   • LLM 驱动下的 Agent 技术演进路径
   • 从开发框架到通用应用：生态全景扫描
   • 企业落地的真实挑战
2. Agent Mesh 设计与落地
   • 为什么企业多智能体系统需要「Mesh」？
   • Agent Mesh 核心机制：连接，注册，安全三大能力域
   • 从企业存量 IT 资产到 AI Native 资产
   • 典型落地场景与常见踩坑
3. ArkClaw 平台落地案例与效果
4. 总结与展望

​听众收益：

• 认知层面：清晰理解企业级智能体落地的核心挑战，以及从单智能体到多智能体协同的演进逻辑
• 方法层面：掌握 Agent Mesh 架构的设计思路与治理要点，包括注册发现、通信协作、安全权限等关键能力
• 实践层面：获取字节跳动火山引擎 ArkClaw 平台一手的建设经验与踩坑总结
• 视野层面：了解多智能体系统与企业存量 IT 资产融合的前沿趋势，把握下一代企业 AI 基础设施的演进方向

智能手机每天承载着用户大量的内容消费与操作行为，但传统 AI 助手仅能被动响应单次唤醒，无法真正"陪伴"用户的手机使用旅程。本次分享介绍的系统，以手机屏幕时序视频流为输入，构建了一个具备持续感知、个性化记忆与主动执行能力的多模态伴随 Agent。

我们将重点分享三个算法核心：一是屏幕多模态意图理解，在用户无需明确表达完整需求的伴随场景中，结合屏幕内容与对话上下文，推断用户真实意图并主动规划最优响应路径；二是时序记忆管理，基于时间窗口与指数衰减的伴随记忆机制，让 Agent 始终"活在当下"并持续积累用户个性化偏好；三是工具执行与结果融合，面向本地生活、知识检索、系统操作等多类任务，多工具并发调用与结果排序的工程实践。

该系统已在 OPPO 手机端规模化落地，历史迭代产品分别在 2024、2025 年开发者大会正式亮相。我们将结合真实踩坑案例，分享陪伴类 Agent 从 0 到 1 落地的完整经验。

演讲提纲：

1. 伴随助手Agent整体设计
   • 范式跃迁：从"唤醒-响应"到"持续感知-陪伴"
   • 三大核心挑战：实时性、时序性、意图模糊性
   • 系统架构全景概览
2. 屏幕多模态意图理解
   • 多维并行意图识别架构设计
   • 意图冲突时的融合决策策略
   • 规则驱动与模型驱动的边界：混合架构的演进与取舍
3. 时序记忆管理
   • 流式多层级多场景 Memory 架构设计
   • 视频流有效信息提取与噪音过滤实践
   • 时间窗口选择困境与时间衰减检索机制
4. 工具执行与结果融合
   • 旅行生活场景的专属子 Agent 设计
   • 多工具并发执行与降级策略
   • 误触发治理与多链路结果融合排序
5. 总结与展望
   • 效果呈现与已知边界
   • 从被动响应到主动陪伴
   • 从会话记忆到用户心智模型

听众收益：

• 全面了解OPPO从0到1搭建的多模态Agent架构设计和落地经验
   

大模型的爆发式演进，在自然语言理解、生成和推理能力上取得突破，赋予 Agent 动态决策、多任务协同和拟人化交互能力，推动其从"工具"向"自主助手"演进。本演讲结合了得物智能客服从传统 workflow 向 AI Agent 端到端解决方案落地过程中的痛点和成功实践经验。阐述了在高准确率要求和高复杂性的背景下，算法如何通过模型训练、PE 自动化、人类经验对齐、以及对话消息流控制，打造高可控的智能客服 Agent 系统，并拿到了超越当前配置型工作流的效果，在解决能力和回复多样性上达到了和 Top5 人类客服对齐的水平，达到了人力成本降低、用户体验提升的双正向效果。

演讲提纲：

1. 背景与挑战：智能客服领域Agent落地的必然性与挑战
2. 客服Agent多轮协商优化-高可控性PE自动化
3. 客服Agent出话决策-RL决策训练实践
4. 客服Agent情感温度-人类经验对齐模型蒸馏
5. 多轮会话消息流控制-半双工对话逻辑设计
6. 总结与展望

听众收益：

• 从 PE 自动化 → RL 决策训练 → 经验蒸馏 → 消息流控制，可获得完整的客服 Agent 建设方法论
• 了解在真实业务约束下如何设计 Reward 模型、采集训练数据，并将决策能力内化至 LLM 底座，避免在 RL 落地中踩坑
• 理解如何将难以结构化的优秀客服经验通过模型蒸馏方式传递给 LLM，在保持专业度的同时引入情感温度，对需要构建人格化 Agent 的团队可以参考
• 在情绪化用户与严格业务规则并存的场景下，掌握 Agent 进行多轮协商的设计策略，解决"让 Agent 既不得罪用户、又不违反平台规则"这一难题

随着大模型进入教育核心链路，AI 系统不再只是若干模型和工具的串接，而逐步演变为一个持续感知、决策、执行、反馈的闭环控制系统。在教育业务核心场景中，面对 500+ 引擎、单应用上百节点、流式/非流式混合交互、跨云弹性扩缩和授权一致性等挑战，我们自研了WISH平台，将 Agent 调度、FaaS、引擎托管、权限管理、监控与扩缩容整合为统一运行时。

演讲将重点分享：如何用图灵完备的编排平台承接复杂 DAG、如何用节点状态机和消息驱动调度支撑混合交互、如何在工程上平衡“稳定流水线”与“局部闭环纠偏”、如何借助 CRDT、Distro 和 P2P 镜像分发解决分布式授权、水平扩展与大模型快速部署问题。我们也会讨论一个核心判断：在 Agent 系统里，决定上限的不只是模型能力，调度、工具、权限、记忆与监控这些 harness 设计同样关键。

演讲摘要：

1. 为什么 AI 平台必须从”能力串联”升级为”自闭环系统”
   • AI 应用从”单能力、短链路、短会话”演变为”多能力、复杂 DAG、长会话”
   • 大模型并没有消灭系统工程，反而把 Observe / Orient / Act 的工程问题全部暴露出来
   • 在复杂业务里，决定系统表现的往往不只是模型，而是整个运行时如何让系统更快感知、更快纠偏、更快恢复
2. WISH平台的核心定位：不是一个画布，而是 Agent 时代的运行时底座
   • 对标编程语言与 IDE 的设计思路：变量、分支、循环、子工作流、异常处理
   • 为什么“harness 和模型同等重要”：调度、工具、权限、记忆、监控共同决定系统上限
   • 不是所有问题都应该交给自由 Agent：教育场景更需要“稳定流水线 + 局部闭环纠偏”的混合架构
3. 编排与调度：如何支撑复杂 DAG 的高效执行与调试
   • 调度器内核：节点状态机设计（未调度→预备→就绪→执行→已执行）
   • 基于消息驱动的数据传递：统一处理流式与非流式混合场景
   • FaaS 落地：代码执行与调度解耦、命名空间隔离、字节码缓存、依赖管理
   • 一个关键经验：循环速度比单次“完美决策”更重要，系统必须优先保证可观测、可调试、可回退
4. 服务托管与治理：如何把数百个引擎纳入统一框架
   • 统一托管框架：一次编写、无限次托管，启动自检 + 崩溃现场自动收集
   • 结构化 action space 的工程价值：节点、工具、工作流比“代码即动作”更适合权限控制、审计和治理
   • 负载均衡基础假设失效时的应对：基于授权限流的最大空闲调度策略
   • 分布式授权精准控制：基于 CRDT PN-Counter 的无冲突并发解决方案
   • 基于 Distro 协议的自组织集群：让水平扩展真正具备工程可行性
   • 高并发下再小概率的事件也一定会发生：记一次高并发复杂场景下的踩坑经历——内存复用导致的请求串乱
   • 高性能基础上的又一次性能飞跃：如何让服务发现性能翻倍
5. 混合云弹性与线上稳定性：Agent 系统不能只会做题，还要能活在生产环境里
   • 多云自动化构建、发布与扩缩容系统设计
   • 基于 P2P 的高速镜像分发（提速 20 倍以上）
   • 精准监控与应急三板斧：重启、迁移、扩容
   • 从“人工盯系统”到“系统自我感知和自我恢复”的演进
6. 未来规划：从运行时走向更严格的 Agent 基础设施
   • 以整个AI链路为单位的整体弹性伸缩
   • 工作流描述语言WDL的形式化与严格化验证
   • “拉”模式大展身手，跳出复杂分布式授权的天花板

听众收益：

• 对于教育超复杂场景下，Agent运行与调度的清晰认知
• 对于Agent的能力边界认知
• 对于Agent时代下，对于底层AI基础设施超高要求的复杂度认知

AI Agent 和代码沙箱正在成为云上最危险的工作负载——它们执行 LLM 生成的代码、调用任意外部工具、访问未知 API，天然不可信。传统 Kubernetes NetworkPolicy 面对这类场景几乎失效：无法控制域名、无法应对大规模沙箱的策略爆炸、更无法感知 HTTP 层的 Token 和内容。

本演讲以阿里云 ACK 在生产环境的实践为主线，分三个层次展开：首先分析 Agent 沙箱场景独特的网络安全威胁模型；其次介绍我们自研的 TrafficPolicy CRD，如何通过 FQDN 域名白名单、优先级策略叠加和多链路规模化下发，解决当前生产中的隔离问题；最后介绍的计划上线的 L7 策略层——SandboxSecurityProfile，从流量隔离走向 Token 替换、内容审计、LLM 流量治理的完整安全管道。

演讲提纲：

1. Agent 沙箱为什么是个网络安全难题
   • 沙箱工作负载的特殊性：执行不可信代码、工具调用目标运行时才确定、每个租户独立隔离
   • 三类核心威胁：
     • 横向渗透（沙箱访问集群内其他服务）
     • 数据外泄（带着平台凭证访问任意外部 API）
     • 凭证滥用（Agent 直接使用 AK/Token 调用云 API，无法审计）
   • 为什么 NetworkPolicy 不够用：只有 IP/Port、无法做域名白名单、策略数量随沙箱规模线性爆炸
   • 为什么 Envoy sidecar 又太重：数千沙箱并发时资源开销不可接受
2. TrafficPolicy：今天在生产中如何做
   • API 设计理念：声明式、优先级叠加、Namespace 级与集群级双模型
     • GlobalTrafficPolicy 设置平台安全基线，TrafficPolicy 让租户叠加工具白名单
   • 三类访问目标：CIDR / Service（含 Endpoint 展开）/ FQDN
     • FQDN 的挑战：DNS TTL 竞态、IP 动态变化、多租户 DNS 归属难以区分
     • 解法：DNS 拦截 + IP 集合动态追踪 + TTL 陈旧缓存兜底
   • 规模化挑战与下发链路设计：
     • 数千沙箱并发 → nftables 规则集线性膨胀，编译和写入耗时直接影响启动时间
     • 三种部署形态并存（普通节点 / Kata 安全沙箱 / ECI 无节点），无法用同一条链路覆盖
     • 三条差异化路径：gRPC server-streaming 推增量、Shim 在进程启动前预置数据面保证首包前策略就绪、unix socket 旁路 API 处理 ECI 场景
3. SandboxSecurityProfile：L7 治理的下一步
   • 为什么需要 L7：光有"能不能访问"不够，还需要"访问时做什么"
   • 展示 API 设计，逐段解释每个 action 的动机：
     • CloudSecurityCheck：接入云安全中心，实时检测恶意域名
     • IdentityInjection：每个沙箱注入身份标识，流量全程可溯源
     • TokenTransformation：AK/Token 不下发给 Agent，由平台在流量层透明替换
     • LLMAudit：LLM 请求/响应内容审计，满足合规要求
     • Forwarding：强制走内部 LLM 网关，防止绕过管控直接访问外部模型 API
   • 技术实现路径：TLS 拦截（MITM CA）+ Envoy ext_proc 作为可插拔执行引擎
   • 与 TrafficPolicy 的关系：L4 是门，L7 是门里的检查站，两层叠加互补
4. 总结

听众收益：

• 建立 AI Agent/沙箱场景网络安全的完整威胁模型认知
• 了解大规模沙箱场景下网络策略的工程挑战与解法
• 看到一个面向 AI Agent 的 L7 安全策略的完整实现方案

在长程 Agent 场景中，系统瓶颈正从“模型单步能力”转向“能否在有限上下文、缓存窗口和持续工具交互约束下长期稳定运行”。现有工作大多聚焦上下文接近上限后的最终 compaction，但对进入重压缩之前的前序整理层，以及压缩过程与 Prompt Cache 的协同考虑仍然不足。

本次分享将介绍我们在企业内部办公智能体 OpenClaw 上探索的 Self-GC 方案：借鉴 Java GC 对运行时对象持续管理的思想，将多轮 Session 上下文对象化，并通过显式寻址、低损 prune/mask/fold、plan/commit 解耦、cache-aware delayed commit 等机制，把上下文治理前置到运行过程。 实践中，当前场景平均 input 约 70k tokens，平均 TPM 约 1 亿 tokens。结合收益模型，我们将 Self-GC 视为一种模型无关的 harness 能力，而不是某个模型特定技巧。按当前业务规模粗估，线上对 user / tool / skill 三实体采取 GC，净 input TPM 大盘下降 15%。分享将重点展开对象模型设计、前缀缓存协同、幂等恢复、离线效果评估与工程落地路径。

演讲提纲：

1. 问题背景：为什么长程 Agent 需要新的上下文治理方式
   • 长历史、多工具调用、长周期任务的真实系统压力 为什么“快爆窗了再 summary”不够 compaction 为什么正在成为 harness 的核心组成部分
2. 现有方案的不足
   • 常规 self-summary：更像最后阶段集中压缩
   • Tool-result pruning：更偏局部优化 retrieval memory：更像后置外存机制 为什么现有方案大多缺少前序整理层和 cache-aware 设计
3. Self-GC 核心设计
   • 上下文对象化：user turn span / tool object 显式注入 turn id，让模型具备上下文寻址能力 低损整理动作：prune / mask / fold fold 后的幂等恢复：本地文件 / 旁路存储 / read 恢复
4. 把整理前置到运行过程
   • 阈值触发而不是每轮强制执行 after-turn self-review 为什么 fork 完整上下文 + 尾部追加 planning prompt 有利于复用 prefix cache
5. Cache-aware 的关键设计
   • plan first, commit later delayed commit 避免频繁打断前缀一致性 收益函数： Award ≈ N_future × (C - C') - L_cache_break - L_GC 该函数如何同时服务工程评估和后续训练优化
6. 效果评估方法
   • 从真实触发重压缩的 session 中取样 在 25% / 50% / 75% 切点做前序整理模拟 用后续真实对话轨迹做离线评估 如何判断 Self-GC 是否有效、是否值得
   • 工程收益粗估与适用边界
   • 当前业务规模下的 10%–30% 净 TPM 收益区间 哪些场景适合 Self-GC 哪些场景更适合 memory / retrieval / tool pruning
7. 未来工作
   • 模型原生寻址能力 模型自主触发能力 模型原生整理能力

听众收益：

• 获得一套更适合长程 Agent 的上下文治理思路，理解为什么仅靠最终 summary / compaction 不足以支撑真实多轮任务
• 学到一套可落地的 Self-GC 设计框架，包括对象建模、显式寻址、低损整理、幂等恢复、plan/commit 解耦与 cache-aware delayed commit
• 带走一套可复用的工程评估方法，知道如何用真实 session、真实后续轨迹和收益模型来判断一个上下文治理方案是否真的有效、是否值得上线

实践痛点：

• 传统 compaction 大多发生在上下文已经接近上限时，这更像一种最后阶段的集中处理。它虽然能缓解爆窗，但往往介入时机较晚，容易一次性丢失较多结构信息，也难以回答“在进入重压缩之前，系统还能做什么”
• 真实 Agent 的上下文并不是纯文本，而是 user / assistant、多轮工具调用、冗长工具结果、中间计划、失败重试等混合对象。如果缺少对象化表示和显式寻址，模型只能对整段模糊历史做 summary，很难像 GC 一样精确标记和清理具体对象
• 很多压缩方案忽视了 prefix cache。工程上，如果每轮都改写历史前缀，虽然 token 可能变少，但 cache 命中率也可能显著下降，最终吞掉压缩收益
• 低损整理如果没有恢复语义，就很难真正落地。很多被 fold 的工具结果虽然不应继续长期留在主上下文里，但后续又可能需要稳定恢复，因此工程上必须同时解决“如何整理”和“如何幂等恢复”

随着大模型能力的持续突破，AI Agent 正在重塑内容生产的工作范式。设计生产场景天然具备高度复杂性——多工具协作、意图模糊、流程长链路——这让它成为验证 Agent 工程能力的绝佳试验场。Roboneo 正是在这一背景下诞生：面向真实的设计生产需求，让用户只需表达想法，Agent 即可自动完成从意图理解到图像处理的全流程修图任务。

本次分享将结合 Roboneo 从 0 到 1 的建设历程，系统梳理面向设计生产场景的 Agent 能力编排工程实践，涵盖业务背景、核心挑战、架构设计与演进路径，以及落地过程中的真实踩坑经验。

演讲提纲：

1. 背景与场景
   • 设计生产场景的现状与痛点：工具碎片化、流程重、专业门槛高
   • Agent 范式的机会：从"工具调用者"到"需求表达者"的用户跃迁
   • Roboneo 的目标定义：用户只需有需求，Agent 完成修图全流程
2. 面临的困难与挑战
   • 业务层挑战
     • 设计意图天然模糊：用户描述的"好看一点"背后可能对应数十种操作组合
     • 设计场景的长尾性：修图需求种类繁多，边界难以穷举
     • 用户期望与模型输出之间的对齐难题
   • 技术层挑战
     • 多工具、多步骤的可靠编排：单步失败如何降级与恢复
     • 工具调用的延迟与稳定性：设计生产场景对响应质量敏感
     • Agent 决策的可解释性与可调试性
3. Roboneo 的设计与落地
   • 用户意图理解：从自然语言到结构化设计指令的转化机制
   • 多 Agent 架构：规划 Agent、执行 Agent、校验 Agent 的分工与协作
   • MCP 工具集设计：面向修图场景的工具抽象、注册与动态调用
   • 能力编排的演变：从线性流水线到动态 DAG，随业务复杂度持续演进的编排策略
4. 总结与展望
   • 核心经验沉淀：哪些设计决策真正决定了系统上限
   • 已知边界与改进方向
   • 从设计生产走向更广泛创意生产场景的想象空间

听众收益：

• 理解面向垂直生产场景构建 Agent 系统的完整方法论
• 掌握多 Agent 协作架构与 MCP 工具链的工程设计要点
• 获取从 0 到 1 落地 Agent 系统的一手踩坑经验与演进思路