先说结论

9 月 24 日下午的云栖大会「AI 实时数据智能」论坛，是这场大会里离「Agent 进入生产后到底卡在哪」最近的一场——六场演讲没有停留在口号上，而是各自交出了工程答案。核心矛盾被开场一句话点破：**AI 应用进入规模化生产后，行业焦点正从模型与算力本身，延伸到支撑应用落地的系统能力；当 Agent 的任务从一次问答变成持续十几分钟甚至几小时的长程执行，真正决定它能不能上线生产的，是数据的新鲜度、口径的一致性、任务断点的可恢复性——这些最不性感的基础设施问题。**阿里云消息队列产品专家刘尧把企业 AI 数据链路概括成一个飞轮：业务产生事件、事件形成事实、事实进入检索特征与模型上下文、模型输出再触发下一轮业务动作，「只要其中一段仍依赖 T+1 或人工搬运，整个循环就无法真正实时」。这场论坛的发布恰好构成一条供给线：Kafka 流算湖一体化平台、SLS 的 Agent 原生能力（Session Store、语义层、MCP 与 Skill）、RocketMQ for AI 的 LiteTopic（一个任务一个轻量队列）与 AgentBridge（不搬数据、以逻辑统一构建多元实时上下文），最后由千问办公×AgentBridge 的数据分析专家套件收口成业务界面。震坤行高级架构师田军权与 Qoder 技术专家泮圣伟则从使用方给出同一句潜台词：买的不是功能，是「等得住、接得上」的确定性。本文按官方回放（0—12156 秒、102 段转写全文覆盖）完整复盘；产品能力为官方自述口径，客户数字标「嘉宾自述」，核验说明见文末。

一、Kafka「不止于消息」：流算湖一体，收敛的是链路而不是功能

第一场由阿里云产品专家刘尧与高级技术专家张美平共同完成，讲的是今年云消息队列 Kafka 版最重要的一次转身：从消息队列升级为「流算湖一体的实时数据平台」。刘尧开篇就划清边界——「不止于消息」不是否定 Kafka 最核心的可靠传输，而是要在承重最大的数据入口之上，解决数据到达后如何被计算、被沉淀、被 AI 应用持续使用的问题。

为什么要现在做？他的论证从四个老问题出发：新鲜度（一分钟前的交易、告警、行为数据等到明天才进模型，支撑不了实时决策）、一致性（训练、推理、检索可不用同一数据形态，但必须有统一口径、治理规则和可追溯版本）、持续供给（RAG、推荐、智能体要求数据不断到位）、及时可用（采集后再经多套系统传递、多团队加工，AI 场景就废在链路上）。他随即给出一个易被忽略的澄清：**实时不等于追求更低的毫秒延迟——企业更关心新鲜数据的结构是否正确、权限与版本语义是否完整；数据传得快但口径不一致，或可用但无法追溯，都支撑不了生产级 AI。**过去从实时采集到实时计算再到持续入湖要拼一条长链路：Kafka 做入口、独立流计算引擎做加工、数据工具做处理、再加元数据系统和湖存储，每增一个环节就多一组连接、一套状态、一套故障边界处理，最终落成四个结果——链路长、组件多、运维重、总成本高。他举的排障场景很能说明问题：下游结果晚了十分钟，要依次查消息积压、计算反压、入湖状态、元数据一致性，每一段都有自己的监控、日志和责任团队，「定位时间往往比修复问题的时间还长」。

流算湖一体的答案是一句话定位：消息流入、就地算、原生入湖。流仍是共同入口，一份数据，算和湖可独立也可组合使用：流负责海量采集、缓冲、削峰与多方分发；算提供标准 SQL、实时向量化和模型调用（含 Stream Agent）；湖把原始数据或计算结果以 Iceberg 等开放表格式沉淀为可治理的表资产。刘尧特意强调这不是强串行：合规留存可不经 SQL 直接以原始 topic 入湖，实时风控直接跑 SQL 把结果写回 topic，清洗聚合先算再沉淀——「最大的变化不是多了三个功能，而是同一份实时数据不再需要为不同用途重复建设链路。」

「算」这一侧的三类能力分层暗含一条工程原则。第一类流计算 SQL 面向清洗、转化、窗口聚合，平台负责事件时间乱序、状态一致性和故障恢复，业务开发者只用熟悉的 SQL；第二类向量化把传统「先存下来再离线批量向量化」的滞后模式，改为数据进入 Kafka 后由流计算任务调用千问大模型批量生成向量、持续写入下游向量库，同时治理原文-向量-模型版本-索引的一致性关联；第三类 Stream Agent 处理需要语义理解的事件——工单意图识别、告警归因降噪、内容审核打标——但刘尧的原则是克制而非炫技：能用确定性规则解决的部分优先用 SQL，只有需要语义归纳和复杂判断的才交给模型，既控制延时又控制成本；进模型前做权限脱敏裁剪，返回后保留输入版本与后续动作以便审计回放。「Stream Agent 不只是实时调用一次模型，而是把智能体处理纳入一条有边界、可观测的数据流。」

技术负责人张美平补上了底座故事，最有分量的是无盘化改造：阿里云 Kafka 从三年前开始构建存算分离架构（他称行业最早），Broker 只负责协议处理与读写服务，数据持久化到基于飞天盘古的共享存储；扩缩容无需搬迁历史数据，故障恢复只做所有权切换和极少量热数据重建。避免双主靠三重 fence：meta fence、数据 fence、epoch 机制。他的对标很有信息量：行业 Kafka 在做分层存储但仍需本地副本，社区 KIP-1150 才刚开始规划无盘化，而阿里云版本「已在生产环境稳定运行四年，彻底实现计算存储解耦、秒级故障恢复（RTO）」。原生入湖的关键是把 Kafka 位点推进与 Iceberg/Paimon 快照提交做成原子——文件写出、快照提交、位点推径必须保证正确顺序语义，提交前故障自动重放并重新生成候选文件，最终保证端到端 exactly-once；后台持续 compaction 治理小文件，存储落在客户自己的 OSS Table Bucket，端到端 TCO 最优。

第一条机制链：Agent 生产化（任务长程化、数据依赖实时化）→ 实时链路的复杂度从「拼接多个系统」重新收敛回「入口平台」——Kafka 把采集、计算、入湖收进一个共享底座，用「减少中间环节」直接削减连接数、故障边界和跨团队运维 → 二阶影响：实时数据平台的竞争维度从单点性能（吞吐、延迟）转向端到端 TCO 与故障定位时间，存算分离与云厂商底座（盘古、OSS）的协同成为结构性优势 → 读者启发：评估实时数据平台别看组件单价，算四笔账——同一业务结果要跑多少常驻任务、存多少中间副本、维护多少连接与权限、排障要几个团队参与；自建链路里每多一个系统，就把「定位时间大于修复时间」的概率放大一次。（架构与规模表述为官方自述口径；KIP-1150 为社区编号，张美平口述）

二、SLS：Agent 既是数据的使用者，也是数据的生产者

第二场来自阿里云日志服务产品经理何晓峰，主题是「Agent 时代的实时数据引擎」。开场把一个角色变化讲得很清楚：Agent 出现之前，数据工程师面对海量数据的第一语言是 SQL，「为了一个业务结果跟 SQL 对线的日子」人尽皆知；而现在他本人约 90% 的 SQL 已由 Agent 产出且质量很高——**Agent 对于数据平台来说，已经真正成为使用者；同时 Agent 在使用数据、实现能力的过程中，也在产生新的数据。**这批新数据不是传统应用的状态码和输入输出，而是多轮动态结构必需的轨迹（trace）与会话（session）记录，除了观测排障还要用于评估、审计甚至训练语料——这对数据平台提出了「以任务方式还原多行复杂数据、以事实为基础」的新要求。

SLS 今年在实时数据底座之上构建的 Agent 原生能力有四件：Session Store（以会话视角组织全链路数据并沉淀为资产）、语义层（从海量数据中提取业务语义，供 Agent 和人使用）、MCP Server 与 Skill（平台与 Agent 协同的桥梁）、以及应用层的 SLS Data Agent。何晓峰还预告了次日分论坛发布的两款衍生产品：做观测评估的 Agent Loop 和做智能运维的 StarOps，两者都以 SLS 为数据底座。

Session Store 的三个数据源设计体现「不强造数据、只做还原」的克制：OpenTelemetry Trace 格式（探针或 SDK 均可）、LoongCollector 接入的 eBPF 数据（把 Agent 与内核交互的数据还原成轨迹）、阿里云 AI 网关数据（目前仅支持阿里云网关）。数据进入后由处理任务做字段归一、事件还原、任务事实还原，产出三层视图：轨迹（一次对话一条轨迹）、Session（一轮会话的全部信息）、特征（每步的性能耗时、Token 消费、工具/Skill/Memory 调用）——都以可消费、可过滤的数据资产形式提供。演示案例是游戏礼包排障：用户支付成功但礼包未发，两个 Agent 协作调用五次模型、六次工具，把查订单、定位库存超时错误的整个步骤还原成一条轨迹；三轮催问以 Session 视角合成一条记录，能看出 Agent 回复没有偏移——第三轮看到到账凭证才说「已发放」。这批数据的下游用途很实际：观测（性能、Token 消耗）、审计（是否越权、违规）、风险检测（越权、敏感信息）、质量评估（喂给 Agent Loop 找 good/bad case，变成数据集做优化、实验、回放和后训练）。

语义层是最值得咀嚼的设计。它的原材料不是用户的原始数据（「数据资产属于大家，平台不会碰」），而是平台拥有的使用历史信息：数据结构 schema（索引定义）、历史 query、仪表盘配置、告警配置——用得越多，沉淀的语义越丰富，何晓峰称之为「数据越用越聪明」。在这之上通过模型提取任务生成字段描述、指标口径和业务术语，再由业务模型层圈选跨 project、跨 store 的数据范围，叠加企业自己的指标、术语与示例（他举例：阿里人爱说「颗粒度」「抓手」，Agent 不懂就得教；云栖大会的年度固定规则沉淀下来，Agent 回答相关问题就准确且实时，还能省 token）。SLS Data Agent 是这套语义的最佳实践：还是礼包场景，从增长视角问「有礼包需求却没购买的用户有哪些、优先优化哪个环节」，Agent 基于事实模型+业务模型作答——300 个用户有需求、180 个看到、90 个购买，付费环节流失 50%；再结合客服交互数据发现用户反馈「价格偏高、规格不匹配」，建议尝试更小规格的礼包。

MCP 与 Skill 部分有具体数字：SLS MCP Server 通过 auth 与 CLI profile 认证（不必传 AK/SK，以账号 RAM 权限范围操作，避免越权），目前提供三类共 11 个 tool；Skill 体系提供一个编排 Skill 加六个专家 Skill，其中 Query Skill 是「阿里云官方市场下载量第二大的单产品 skill」，何晓峰本人 90% SQL 由 Agent 闭环正基于它。演示中一条指令跑通采集器部署到查询的全链路，中途报错还能基于 Skill 内置排查建议自修复。发布节奏：Skill 与 MCP 已上线，SLS Data Agent 已在北京等地域发布，Session Store 马上在广州灰度。

第二条机制链：Agent 进入生产 → 数据平台的服务对象从「写 SQL 的人」扩展为「调 MCP 的 Agent」，且 Agent 自身成为最大增速的新数据源（轨迹、会话、Token 消耗、工具调用）→ 平台价值的锚点从存储计算规模转移到「语义沉淀的复利」——使用历史（query、仪表盘、告警配置）成为平台理解企业的新原料，语义层把「口径之争」从会议桌搬进数据资产 → 二阶影响：Agent 的可审计性从合规要求变成工程标配（轨迹即证据），评估-优化-后训练的数据飞轮有了统一底座；「越用越聪明」形成平台锁定——切换成本随语义资产增厚而上升 → 读者启发：把 Agent 轨迹当一等数据资产设计 schema（session ID、span ID、输入输出、版本），别等审计时才补；语义层优先沉淀高频口径与年度固定规则，这是回报最快的部分；平台选型时问一句「语义资产能不能导出」，它在两三年后会比存储单价贵。（产品能力与发布节奏为官方自述口径；SLS 单租户 EB 级存储、日 PB 级写入、千亿级记录秒级检索见阿里云官网技术方案页，与何晓峰「EB 规模水平」口述互证）

三、震坤行星域：客户视角的证词——实时解决「看得见」，异步解决「人不必等」

第三场是全场唯一客户演讲：震坤行高级架构师田军权介绍自建智能体协作平台「星域」，以及如何基于阿里云实时数据与异步通信产品落地 AI Native。他的出发点是很多企业都在琢磨的问题：**当个人 AI 的效率越来越高时，企业级 AI 的效率如何变得更快？**震坤行的答案是把智能体从聊天窗口里的助手变成能主动接任务的数字同事——智能体和人处于同一协作空间，互相委派、共享上下文；人负责目标和决策，智能体负责闭环执行、反馈和交付产物。难点在于企业环境里搭一个靠谱的 AI 同事要过模型选型、提示词、工具配置、环境依赖、内部资产一系列关，所以星域建了两类共享机制：共享知识（业务规则、系统知识、项目经验）与共享能力（技能、脚本、工具），「一处跑通，经过版本化和授权分发就能快速安装复用」。平台还接入了云效、DMS、SLS、OSS 等阿里生态应用（转写另见「SCK」「ARM」，疑为 ASR 误识别，存疑）。

这场对「实时」和「异步」的拆解是全文最清晰的工程表述。田军权先论证实时数据为什么重要：智能体替代人跑需求时，判断依据不再是同事的记忆，而是系统里的实时数据——业务、系统、Agent 自己运行产生的流程数据；一个需求跑了一整夜，人任何时候接入看到的都应是实时产物而非快照；一份证据被开发、测试、验收多方共享，必须确保看到的东西一样；订单、库存、支付状态必须实时，Agent 执行才不偏移、不发散。然后他给出分工：「实时」解决的是看得见的问题——进度、产物、状态、日志、数据都要实时回显；「异步」解决的是人不必等的问题——人把目标和验收条件交代清楚，智能体自主循环执行，不需要人在线交互等待，出现核心问题时通过钉钉、企微、飞书异步通知。共享文档和标准化产物解决读什么，消息通道解决谁在什么时候去读；下游有了可靠产物就自动接着做，不需要人工中途指派。

会话管理是星域落地的真问题：一个需求从提出到验收产生很多会话，需要会话隔离（避免数据混乱）、同会话内有序（保证流程正确）、断点续跑（造数部署回归动辄几十分钟甚至以小时计，人不在线任务也要兜底持续运行）、应用层限流（一个会话卡住不拖垮其他服务和需求）。目前方案是 PG 加 Redis 加阿里 RocketMQ 的融合实现，田军权还透露正评估用 RocketMQ 的 LiteTopic 让「会话即主题」获得更原生支撑——「隔离、有序、续跑、限流这四件事让 LiteTopic 原生支持，进一步减少应用层架构设计的工作量」。所有 AI Native 运行数据统一落数据库和 SLS，「不管 Agent 跑到第几步、在哪里失败、验收凭什么通过，都可以通过运行时实时数据检索查询来回答」；未来计划参考 SLS Data Agent 接入观测平台——统一观测数据模型 UModel、UModel MCP 获取关联数据实体、SLS Skill 封装可复用诊断逻辑。

交付链路的设计是「人只前置关键决策，智能体闭环执行」：目标、边界、验收标准由人事先协同沟通；角色按任务复杂度自由组合（「边界清楚的小缺陷不需要请一桌人到齐」）；两条自修复回路——开发 loop（代码写完经构建编译自测，不满足条件自闭环优化）和 QA loop（Agent 进真实业务场景验收，不通过就按证据定位再修复再验收）；跑完的系统知识和踩坑经验沉淀进知识库。他特别点出自动化测试里最容易被低估的阻碍：**测试数据从哪来——验收「已发货订单能否取消」，不是把订单状态字段改成已发货就行，而是订单涉及的库存、支付、物流状态都要真正成立、相关系统都收到通知并及时更正。**震坤行为此设计了三条路径：「理象」项目录制用户浏览器操作捕获成接口调用流、浏览器 AI 自动化把用户操作产品转化为 UI 操作脚本、通过 MCP 操作数据库构造数据现场修正依赖数据。演进方向是先纵向做深（专业领域超级智能体，同一智能体承担方案、实施、自检、多段标准产物）、再横向拓展（跨领域智能体产物共享与跨域接力）。落地节奏的表述很克制：以中小型需求为切入点逐步推行，业务和产品同事直接在星域提需求，由 AI Native 自主完成代码开发和自动化验收测试——「产研协作入口开始变化，不是只有开发人员拿 AI 工具写代码」。（以上均为嘉宾自述口径）

第三条机制链：企业把 Agent 从个人助手升级为数字同事 → 协作平台的工程重心从「单次对话质量」转向「会话治理」（隔离、有序、断点续跑、限流）与「测试数据真实性」——前者倒逼消息中间件提供会话级原语（会话即主题），后者暴露出自动化验收的真实瓶颈是业务现场的数据成立性而非脚本覆盖 → 二阶影响：需求入口从研发团队扩展到业务与产品（描述目标与验收标准即可），产研组织边界开始移动；运行时数据全量落盘使「验收凭什么通过」第一次变得可检索、可回答 → 读者启发：企业级 Agent 平台先解决四件会话治理再谈智能；做自动化验收时把预算的大头给「构造真实业务现场」（录制、UI 自动化、MCP 改库三条路径），而不是只堆测试用例数量；从中小型需求切入、让业务方直接提需求，是转型风险最低的坡道。（嘉宾自述口径，未经第三方核验）

四、RocketMQ for AI 与 Qoder：手脑分离，一个任务一个 LiteTopic

下半场第一场由阿里云产品专家杨文婷与 Qoder 技术专家泮圣伟接力，讲 Agent 异步通信架构。杨文婷的问题设定与刘尧遥相呼应：Agent 从「问一次答一次」发展到「交一个任务跑几小时」，任务变长后真正执行 worker 的时间只占生命周期的一部分，其余都在等待——等外部工具返回、等人工审批、等算力分配。**若 worker 从任务开始到结束一直占着资源不放，就是巨大浪费；任务越长，遇到网络异常、节点故障、发布重启的概率也越高。**架构必须回答：任务怎么等得住、断点怎么接得上、有限算力怎么分。

她给出的行业坐标是 Harness（模型周围的执行系统）的演进：早期把功能放在一个进程或容器里、任务与运行环境绑定，服务连续性与结果一致性不可兼得；业界进而提出「手脑分离」——大脑（Brain）负责推理决策、手（Worker）是无状态执行单元、Session 保存会话上下文与进度，关键状态存检查点、用事件推进后续执行（如人工审批完成后产生事件，执行系统收到再加载状态继续跑）。RocketMQ 的 LiteTopic 正是以此为切入点：**把一个任务从提交到完成的关键变化，组织成一条可保存、可消费的消息流——「一个任务对应一个 LiteTopic」，任务的内容、结果、状态全部以消息形式写入；消息内容对应任务要做什么，消费位点对应执行到哪一步，加上主动推送与可靠投递，任务状态就能被实时触发推进，故障恢复后从断点继续而不是从头重做。**连接可以断开、工程进度可以结束，但任务接连的依据保存在外部服务系统里，新执行节点随时可以接手。

LiteTopic 的八项能力归为三组：轻量资源（可创建百万级、自动创建、自动过期删除）、可暂停（suspend 指定某个 LiteTopic 暂停投递，时长几十毫秒到几小时皆可由业务方控制）、灵活订阅（通配订阅一次订阅父 topic 下所有 LiteTopic；差异化订阅让每个节点只订阅自己负责的任务集合；排他订阅保证一个 LiteTopic 只被一个消费者订阅、防止并发消费错乱；peek 只读查看不实际消费，用于重建任务上下文）。

三个生产案例把抽象能力落了地。长会话续传：客户端与 Agent 常用 SSE/WebSocket 长连接，后端节点异常或滚动发布导致重连后随机连到其他机器，「返回到一半的结果怎么续传、不让用户重复执行浪费 token」——业务方常用 Redis 做这事，但 Redis 不支持星号订阅、可靠性与性能不可兼得、Stream Key 管理成本高、缺按业务需求过期的 TTL。LiteTopic 的做法是每个会话 ID 一个队列，模型结果按会话 ID 写入；每个前端节点只订阅自己负责的那部分会话，客户端断线重连到别的节点后动态补一个订阅、从上次消费位点继续返回——会话状态从应用节点上彻底脱离，业务代码变成无状态，扩容不再有资源绑定。阿里云百炼的 GPU 限流：请求按 UID+Model ID 隔离、按用户 quota 控速、超额流量削峰填谷——LiteTopic 创建维度就是 UID+Model ID，流控系统只需星号订阅由 RocketMQ 自动负载均衡，限流用 suspend 能力（发现用户达到限额就暂停投递 50 毫秒，推到下一计数区间再投）。杨文婷给出的效果是「限流率下降十倍」，前提是复杂任务对首 token 到达时间的容忍度提高了——用可接受的百毫秒级延迟换显著的限流率下降。

协议层的跟进同样关键：MCP 最新 Roadmap 把「长时任务的主动通知、避免轮询资源消耗」列为 Top One 痛点，成立 Trigger and Event 工作组统一消息原语（把零散的异步 Task 对象、Subscription/Listener 通道、Process 进度概念协调成完整定义）；RocketMQ 团队跟进实现了 A2A transport、MCP 插件与 Flink Connector 的 LiteTopic 消费支持。她的分工表述很准：协议负责让参与方理解任务的含义，消息系统负责在生产环境中保证任务怎么保存、怎么传递、怎么通知。（经核验：Apache RocketMQ 5.5.0 已于 2026 年 4 月发布并将社区提案 RIP-83 的 LiteTopic 开源——百万级轻量会话通道、RocksDB 索引、事件驱动 Ready Set、Session-as-Topic 断点续传、suspend 消费、通配订阅、MCP 与 A2A 集成均见 Apache RocketMQ 官网文档与阿里云官方博客。）

泮圣伟接讲的 Qoder Cloud Agent 是这套架构的最大客户证词。他先给了组织层面的反差数据（引用调查口径）：近九成组织至少有一个业务经常使用 AI、约八成员工认为 AI 提高了自己的效率，但只有约 37% 的组织通过 AI 得到正向收益——「个人提效到组织提效中间有非常大的 gap」。Qoder 的 Cloud Agents（全托管 Agent 服务平台，负责弹性伸缩、沙箱隔离、故障恢复）2025 年 5 月 20 日上 0.1 版本、如今 1.0 已发布，「支撑近千家企业、月调用量超千万级别」（嘉宾自述）。三类典型场景：B2B2C（头部企业定义自己的 Agent API 封装产品能力，如金融客户的投研助手）、高并发检测（阿里云内部每天近万级数据安全检测；淘工厂原本质检只能 1% 人力抽检，基于 Agent API 并发后覆盖率到 100%——嘉宾自述）、组织内专业 Skills 平台化。

架构推导是这场演讲的智力密度高峰：一次完整 Agent 执行（提交代码审计→推理→查代码/数据→再推理→等用户审批→继续）的 Session 生命周期是持续的，但计算资源不必与 Session 完整绑定——「把计算跟等待解耦开，计算时拉起完整上下文，计算结束把上下文持久化掉，下次重新拉回来」，天然适合异步事件驱动。对比业界常见做法（Agent 直接放在一个工作节点上、Session 与 Worker 绑定），Qoder 基于 RocketMQ LiteTopic 实现了典型手脑分离：每个 Session 绑定一个 LiteTopic，「虽然执行引擎共享、server 可以支撑百万级并发规模，但每次会话的所有逻辑都通过 LiteTopic 保证独立性、顺序性与一致性」。工程难点三件事：状态可持久（新节点接手后能还原全部推理上下文）、持久化且有序地交给下一计算节点、运行可控可自恢复（模型被限流后重发请求，上下文能继续往前推理而不是任务作废）。

沙箱成本的数字最能体现这套架构的经济性：千问 APP 类产品的大量请求（聊天、推理）根本不需要沙箱，只有涉及文件读写、Bash 执行、浏览器、Computer Use 时才拉起——**Qoder 估算线上超过 60% 的请求不需要沙箱；需要沙箱的也不必常驻，实际线上沙箱平均使用时长不到一分钟，相比常驻方案降低 95% 以上的使用时长，「沙箱成本只占模型成本的 5%」（嘉宾自述）。**最后的组织哲学：内部使用深度决定对外交付质量——「Qoder 每个产品发布前都在阿里巴巴集团内全量实践，超过数万人的内测使用群」；超级个体（某个同学用 Skill 把问题定位做得特别快）的能力封装成云端 Agent API，就成了超级组织（「组织内任何一个同学都能在这个做得很好的基础上进一步往前走」），「Agent API 让专业能力可以反复被组织、反复调用，经验持续累计」。

第四条机制链：Agent 任务长程化 + 算力稀缺昂贵 → 执行架构从「Session 绑定 Worker」转向手脑分离（计算与等待解耦、状态外置到消息系统）→ LiteTopic 把「会话/任务」变成消息系统的一等公民（百万级、自动创建过期、suspend、排他/通配订阅），会话治理从应用层代码下沉为中间件原语 → 二阶影响：长连接断线重连、滚动发布、GPU 配额限流这些运维问题被同一个原语统一解决（百炼限流率降十倍）；沙箱等重资源按需拉起使 Agent 平台的单位经济模型成立（沙箱成本压到模型成本 5%），「用得起」成为 Agent API 规模化的前提 → 读者启发：自研 Agent 平台时先审计「等待占比」——worker 空转等待的时间比例就是手脑分离能省下的成本上限；评估消息中间件别只看吞吐，会话级原语（独立通道、位点持久化、暂停恢复、排他订阅）才是 AI 时代的新及格线。（Qoder 规模、沙箱与质检数字为嘉宾自述；RocketMQ 5.5.0/LiteTopic/RIP-83 经核验）

五、AgentBridge 与千问办公：不搬数据，用逻辑统一换实时上下文

压轴两场是联合发布。阿里云产品专家陈涛与高级技术专家沈林以双人问答讲 AgentBridge，先从客户走访说起：金融、零售、制造、物流的客户业务差异很大，但建 Agent 时都有一个共同诉求——构建多元实时上下文。四个场景把问题铺开：客服 Agent 要实时分析退单原因、查历史投诉、找既合规又能挽留的方案；制造温度异常要即时关联 IoT 传感器数据与维修记录；物流分拣 Agent 要处理分拣监控、线路规划甚至天气；零售补货 Agent 要实时分析门店流水、区域库存、在途补货与供应链交付承诺。沈林总结诉求普遍的三个原因：企业数据持续实时变化（每次业务描述变更都产生新的实时数据）；Agent 要的一个结论背后涉及很多套应用架构（CRM、订单库、库存履约系统），单系统都不完整；新鲜度是实时数据的根本原则——「Agent 要像老员工一样，时刻了解企业里真实发生了什么」。

两个反面方案的排除是这段发布的论证核心，也是最可迁移的判断。**方案一：给 Agent 挂满 MCP（MQ、数据库、搜索、文档库全挂到一个主 Agent）——原型验证完全可行、也建议先这样跑通链路；但进了生产环境，每次让 Agent 临时判断去哪里找数据、怎么查、怎么关联，结果很难稳定，且数据分散需要实时关联时，Agent 的内存也撑不住。方案二：把各数据源同步到同一个地方（如 Milvus 向量库）——中小规模或原型阶段可行，查询入口确实简单；但生产规模后复杂度转移到复制链路上：同步成本高、数据延迟、副本不一致，链路环节一出问题就互相扯皮。**陈涛的收束：需要一个服务对「数据到 Agent 的全过程」负责。AgentBridge 的定位因此是——**从物理集中转向逻辑统一：数据留在各自合适的系统里，上面建立统一的业务视角，通过 catalog、schema、semantic 让 Agent 知道数据在哪里、长什么样、业务含义是什么，再通过统一查询入口自动路由到合适的数据源，减少 Agent 摸索路径和重复搬运的成本。**它围绕实时业务事件，把分散在各系统的事实、历史、语义规则组织成可信、可追溯、持续更新的实时上下文。

能力细节按层展开。接入层支持数据（数仓、数据库、消息日志、文档）与数据语（实体、术语、偏好约定）两类，主动发送、持续监听、原位挂载三种方式。实时性上，Kafka/RocketMQ 的消息持续写入形成可查询的 Event Table，「原本流动的事件现在可以像一张表一样用关键词模糊搜索或 SQL 直接查询刚刚发生的消息」；且不必集中搬运——一次 SQL 里把实时事件流与数据库维表关联，数据依旧各自存储，上层统一入口实时 join 过滤分析；流转中的过滤脱敏由 Data Bridge（source→filter→transform→目标端）完成，复杂清洗可接函数计算，分类摘要脱敏走 AI Transform（借助模型、智能体和内置 AI 算子）。查询准确性走双路径：金额、状态、数量这类有明确结构和计算结果的用 NL to SQL；政策说明、客服对话、历史案例这类算不出来的走 RAG——「路径选错，模型能力再强结果也会偏差很大」。语义层把企业确认过的知识变成 AI 可遵循的规则（用哪张表、字段枚举、净收入公式、表间关联），配合 ReAct 修正（筛相关表控制在 15 张以内，执行看报错逐步修复）；语义初稿不用人工从零配——继承库内表字段描述、采样字段取值、AI 推断补充关联，领域专家只在初稿上确认校验。生产级保障是最区别于 demo 的部分：语义变更按受控 Pull Request 管理，合并前必须通过内部业务 Benchmark 测试（比对最终数据结果一致而非字符串一致）并由业务 Owner 确认；生效生成新版本而非直接替换、可回滚；全链路用 Event ID、Trace ID、会话 ID 串联可观测；每条召回结果保留来源与版本可追溯。开放性上，加工层可交给企业已有流处理组件、存储可用内置或 Iceberg 等开放格式留在自己对象存储、查询层支持跨源联合查询不复制数据，统一的 Catalog/Schema/Semantic 通过 API、MCP 开放复用。（经核验：AgentBridge 于 9 月 22 日在云栖大会本论坛正式发布、定位「一站式 Agent 实时数据上下文服务」，接入方式三分类、Event Table、语义 PR 化变更管理与全链路 Trace 等细节见阿里云云原生公众号发布稿。）

千问办公硬件产品设计师吴嘉程的收尾把这套能力翻译成业务语言。他先给千问办公定性：企业级 AI 办公智能体，三种形态（深度操作本地文件的桌面端、全天在线的云端 AI 工作空间、移动端原生继承员工组织权限的协作 Agent）加四个能（能执行、能连接、能进化、能管控）——「Agent 的手、眼睛、记忆与大脑、中枢神经」。题眼是演进路线：对话式 AI（聊天出谋划策）→ 执行式 Agent（把活干完，「给挖矿的人一把铲子」）→ 第三层懂业务、懂组织、懂你这个人——靠企业上下文：ERP/CRM/OA 通过开放接口统一接入叫汇集，知识库 SOP 文档导入定时同步并抽取事实叫提炼，结构化与权限清洗让口径统一，再按人按任务实时动态组装。「企业的上下文浩如烟海，如何快速迈出第一步？」答案就是千问办公×AgentBridge 的联合方案与现场发布的数据分析专家套件。

他举的场景每个运营都熟：老板在会上问「这周退订的单子为什么增加了」——你要查订单、对物流、核对指标口径，分析完还要整理成材料。分工是：千问办公提供对话入口，负责理解问题、规划分析、验证结论、组织交付；AgentBridge 承担多元数据接入与统一数据目录，让专家套件能被发现、被读取、确定查询范围。几个细节比功能清单更有说服力：退单率按「发起退款时刻」还是「退款成功时刻」算，口径不同数字天差地别，AgentBridge 的 Luma 会结合业务语义理解、口径不清先澄清再查；双通路设计——自然语言负责分析和探索，SQL 复核关键数字（指标抖动漂移等异常用严格结构化语句验证），确保结论不是「从模型里拍脑袋拍出来的」；还会额外做一次数据质量分析判断新鲜度够不够、有没有截断，确认 trustworthy 才生成诊断看板。现场演示串起全链路：退单 topic 开消息分析、挂 MySQL 与 ES、建 Catalog、配售后知识库（赔付规则、会员权益、历史案例），Luma 里验证「退单客户分析助手」后把 MCP 配置导入千问办公跑同一问题——从单客户挽留方案 A/B 到月度群体画像与报表。吴嘉程的总结说到了点子上：过去二三十年企业通过 SaaS 沉淀的数据资产厚重但流动性很差，这套组合让它「随时随地变现」——「过去业务同学做查数从找数据、写查询、写 SQL 开始，现在从拿结论、开会议开始，中间那段苦差事（dirty work）被这套组合接走了。」（经核验：千问办公为阿里 ATH 事业群产品、本次云栖发布 QwenNote A2 硬件与企业级新品；Qoder 为阿里 ATH 事业群 AI Coding 产品，云栖官方账号有「Qoder：AI Coding 赋能超级个体」论坛预告。）

第五条机制链：Agent 要进生产 → 上下文供给的瓶颈从「有没有数据」变成「数据是否实时、口径是否统一、结论是否可追溯」→ 物理集中（全量同步到一个库）让位于逻辑统一（数据留在原地、catalog+schema+semantic 做统一视图），AgentBridge 类平台把「找数据、对口径、留证据」变成基础设施职责 → 二阶影响：语义变更进入工程化治理（PR+Benchmark+Owner 确认+版本回滚），口径管理从口头约定升级为可测试资产；办公 Agent 与数据平台的分层协作让业务人员从「写 SQL 的人」变成「拿结论的人」，数据分析的 dirty work 被平台吸收 → 读者启发：原型期放心挂满 MCP 跑通链路，生产期就必须建统一语义层——判断切换时点的标志是「Agent 每次临时决定去哪找数据、结果开始不稳定」；双通路（自然语言探索+SQL 复核）是低成本消灭「一本正经胡说八道」的工程手段，值得抄；语义资产按 PR 管理加 Benchmark 回归，比任何「数据治理委员会」都更能守住口径。

结语：实时数据基础设施，正在变成 Agent 的记忆体

把六场演讲串起来看，这场论坛讲的是一个完整的供给链重组。上游，Kafka 流算湖一体解决「数据进来即被处理、就地沉淀」，把 T+1 与人工搬运从飞轮里挤出去；中游，SLS 把 Agent 自己产生的轨迹与会话沉淀为一等资产，让「越用越聪明、越用越可审计」同时成立；通信层，RocketMQ LiteTopic 用「一个任务一个队列」把手脑分离落到中间件原语上，长会话、断点、限流、沙箱成本这些运维顽疾被同一个抽象统一；消费层，AgentBridge 以逻辑统一取代数据集中，让多元实时上下文成为可治理、可追溯的服务；最上层，千问办公封装成业务人员「从大白话提问开始」的套件。震坤行和 Qoder 的证词从两端确认了同一件事：客户买的是确定性——等得住、接得上、查得清、说得明。

值得盯的观察指标有四个：LiteTopic 开源后会话即主题能否成为消息系统的行业默认——震坤行「评估用 LiteTopic 替代 PG+Redis 自研会话治理」是风向标；MCP Trigger and Event 工作组消息原语定稿后协议与实现的对接速度；AgentBridge「PR+Benchmark+Owner 确认」的语义治理范式能否跨厂商复制成行业惯例；千问办公数据分析专家套件在企业的实际使用数据——「拿结论」与「写 SQL」的工作量比例是否真的翻转。反方风险同样要摆出来：五分之四的讲者来自同一家云厂商，效果数字（限流率降十倍、沙箱成本占模型成本 5%、淘工厂质检覆盖率 100%）均为官方或嘉宾自述口径，尚未见独立第三方核验；「逻辑统一不搬数据」在超大规模下的跨源查询性能、语义层初稿「AI 推断+专家确认」的人工成本，都还没有公开落地数据；刘尧自己那句提醒也适用于所有平台——功能跑通不等于平台能力，可靠性、治理、弹性和成本要形成闭环才算数。但方向争议不大：当模型能力的边际差异在缩小，决定生产级 Agent 上限的，正在变成这些看不见的基础设施——数据有多新、口径有多一致、断点能不能接上、结论可不可追溯。论坛那句「让智能分析触手可及」的前提，是先让数据流动得起来、沉淀得下去、追溯得回来。

转写与核验说明：本文基于 102 段、0—12156 秒官方回放的完整本地转写（无缺段），讲者按官方议程对位。ASR 校正：刘瑶→刘尧、张伟平→张美平、镇坤行/正坤行→震坤行、Coder→Qoder、Agent Bridge/Engine Bridge/Edge Bridge→AgentBridge、陈淘→陈涛、田军全→田军权、潘胜伟→泮圣伟、吴嘉诚→吴嘉程、circle/Search→SQL、千万大模型→千问大模型、SOS/Sentry Store→SLS Session Store、绘画→会话。存疑保留：「嘉泽」疑为刘尧花名；「手脑分离由 Atlassian 提出」未找到出处；「Mars 平台」按上下文指百炼、疑为内部代号；「SCK」「ARM（疑为 ARMS）」「理象」未找到对应公开实体。经核验：① Apache RocketMQ 5.5.0（2026 年 4 月发布）开源 RIP-83 提案的 LiteTopic——百万级轻量会话通道、自动创建/TTL 过期、RocksDB 索引、事件驱动 Ready Set、Session-as-Topic 断点续传、Suspend 消费、通配订阅、MCP/A2A 集成与 Flink Connector，及 MCP Roadmap 关注长任务通知与会话状态外化——见 Apache RocketMQ 官网文档与阿里云官方博客；② AgentBridge 于 2026 年 9 月 22 日在本论坛正式发布、定位「一站式 Agent 实时数据上下文服务」，主动发送/持续监听/原位挂载三接入方式、Event Table、语义 PR 化治理与全链路 Trace——见阿里云云原生公众号发布稿（53AI 转载）；③ 千问办公属阿里 ATH 事业群，本次云栖发布 QwenNote A2 硬件与企业级新品（新华网、DoNews 报道）；Qoder 为 ATH 事业群 AI Coding 产品（云栖官方论坛预告）；④ SLS「EB 级存储、PB 级日写入、千亿级记录秒级检索」见阿里云官网技术方案页，与何晓峰口述互证。待核项：Kafka 无盘化「行业最早、生产稳定四年」为官方自述；Qoder 规模与沙箱/质检数字、百炼限流效果、何晓峰「90% SQL 由 Agent 产出、Query Skill 下载量官方市场第二」、震坤行星域全部细节、泮圣伟引用的「九成组织常用 AI/八成员工自认提效/37% 组织获正收益」调查（未指明出处名）均为嘉宾自述或官方口径，未经第三方核验。结尾多轮抽奖环节与技术内容无关，未展开。