12 月 19—20 日，在 AICon 全球人工智能开发与应用大会上，我们策划了「Data+AI / Agent 落地实践论坛」，聚焦一个更现实的问题——Agent 不只是“能不能做事”，而是能否在真实企业环境中，稳定、可控、可复用地创造价值。
论坛出品人商汤科技大装置事业群 CTO 宣善明指出，如今行业讨论的重点，已从功能演示，走向“能否解决真实业务难题”。因此，本次论坛刻意弱化“炫技式 Demo”，而是聚焦四个最具代表性的实践场景：复杂售前方案评估与标书生成、具备判断力的 BI 与数据分析、可信的用户研究智能体，以及已深入生产系统的智能运维。这些案例有一个共同点：不再停留于模型能力本身，而是通过工程方法论、架构设计与系统闭环，让 Agent 真正成为可规模复用的生产力。 这也是我们希望与行业共同推进的重要方向。
商汤大装置王志宏|从需求到投标：数据驱动的智能技术方案生成 Agent 实战
王志宏 商汤科技 /大装置 研发总监
项目数量激增、客户需求高度定制化，产研团队则承担评估与响应工作压力巨大。基于这样的现实，商汤大装置打造了一个数据驱动的智能技术方案生成 Agent：构造一个由多个专家 Agent 组成的协同系统，分析杂乱无章的数据并得到我们需要的结果。该方案主要解决两件事情：①帮助完成立项与解决方案评估；②自动化完成标书生成与合规审核
“认知—匹配—生成—校验—复用”的工程化闭环
王志宏讲到，这套“数据驱动的智能技术方案生成 Agent”实践，本质是在复杂售前与方案编制场景下，通过产品知识解析、产品与需求的数据匹配和分析、智能生成、校验与改写等，构建一条从“认知—匹配—生成—校验—复用”的工程化闭环。
首先将问题拆解为几个关键步骤：一是对产品侧进行系统化结构解析，面对多源资料（Word/PDF/Excel），通过目录解析、层级重建、功能抽取与 metadata 提取，完成分层（IaaS/MaaS/应用层）+聚类建模，形成一个可持久化、可复用、可增量更新的产品知识库；
二是进行数据驱动的匹配与分析，按产品聚类切分需求、逐层匹配产品，结合功能得分、过滤条件与“最少产品覆盖最大需求”的优化策略，同时评估定开成本与人力投入，整体来看，对于一篇 50 页左右的产品文档和需求说明，约需要花费 50w Token 的费用，耗时约 30 分钟。
在此基础上进入智能生成阶段，通过“长文本拆解→子问题规划→工具化 Agent 并行求解→Refine 回填”策略，避免一次性大段生成的不稳定问题，结合代码工具、检索与复杂子任务能力，产出结构正确、逻辑一致、风格符合模板要求的标书与解决方案；
最后，构建审核与改写体系，会进行基础语言、结构审核，再针对废标项、功能承诺与合规红线等做场景审核，并采用“多节点粒度+多维度并行+大模型复审”机制生成问题清单，再按类型分流回填与最终复核，10 万字标书约 1 小时即可完成审核与修改。
整个体系最终实现从“专家数日鏖战”到“系统数小时完成+人工最终确认”的效率提升，并通过统一知识底座与多重校验机制显著提升质量，让一次性工程真正沉淀为可复用能力体系。
依托 LazyLLM——真正面向工程落地的 Agent 应用开发框架
支撑这一体系的，是商汤自研 Agent 应用开发框架 LazyLLM，能够以极低成本构建强大 Agent 系统，并解决私有化与复杂生产环境中的关键难题。
统一了本地与云端模型的使用方式：支持不同推理框架与模型的无缝切换，支持所有模型微调和评测
复杂应用一键跨平台部署：通过数据流 Pipeline 自动发现并启动所需服务，包括大模型、向量模型、文档管理、召回服务等，并可接入 K8s 实现工业级能力。
灵活地定制数据切分和解析策略：可轻松构建“可替换、可扩展”的高定制 RAG，仅需十余行代码即可完成复杂能力搭建，并具备清晰易定位的错误提示体系。
更重要的是，它不是“只做 Demo”的框架，而是已在实际 PoC 与工业生产中大规模应用，并在高并发与扩展性方面完成工程化打磨，真正让 Agent 开发变得“简单但可靠、灵活且可落地”。
王志宏最后讲到，未来不仅是把系统“跑起来”，更重要的是让系统“学起来”。通过真实客户反馈形成“执行→结果反馈→误差分析→模型更新→知识更新→系统进化”的闭环，让每一次成功或失败都转化为能力提升，推动从效果复盘走向算法与系统能力持续进化。
腾讯翁旭东|让表格会思考，多智能体重构大数据自助分析
翁旭东 腾讯 /PCG 数据分析平台 算法工程负责人
AI 如何跟数据分析结合，同时保持高效与专业性，一直是 BI 和数据分析领域产品技术关注的焦点。基于用户分析和过往的数据产品经验，腾讯云建设了一款新的大数据表格结合 AI 的数据分析产品 Tomoro，旨在通过用户熟悉的表格操作与无边界的数据引入，结合 AI 驱动的大数据分析工作台，实现零门槛的大数据自助分析。
翁旭东讲到，“我们希望做的不是一款‘功能升级版 BI’，而是一款真正为 AI 时代重构的数据分析产品——一张会思考的表格。”
Tomoro 背后其实包含三层设计思路：坚实的大数据引擎能力，熟悉且零学习门槛的表格式工作空间，以及真正能理解业务需求、具备分析能力的 Data Agent（AI 数据分析师）。
Tomoro 延续了团队长期深耕 BI 的技术积累，具备百亿级数据秒级查询能力，拥有完善的分析方法体系与大量真实行业案例沉淀，这些都成为 AI 时代的可靠底座。同时，他们又刻意保持“表格”这种最自然的交互方式，希望让更多原本不会使用传统 BI 的人，也能毫无门槛地进入数据分析世界。内部验证也证明了这一路径的有效性，Tomoro 带来了大约 40% 的新增 BI 用户群体。
如何让 AI 真正进入数据分析的核心流程，是 Tomoro 的另一项创新。团队最终选择了“主 - 从式”的多智能体架构，并不是单一 Agent，而是让系统更像一个数据分析团队在协同工作。
系统中的 Master Agent 更像一位经验丰富的分析 Leader，既能理解用户的业务目标，又能结合上下文和历史偏好拆解任务，规划分析路径，并在执行过程中持续评估与决策。
而不同类型的 Executor Agents 则承担具体分析任务，负责执行不同维度、不同复杂度的分析工作。这样一种“团队化 AI 协作”，为应对现实世界中从简单问题到高复杂度业务决策的问题体系，提供了更加可扩展、可应对不确定性的能力。
翁旭东直言：“我们希望它不仅能做分析，还能与其他智能体协同，最终真正做到分析驱动业务行动。多智能体 + Workflow 混合模式成为必然选择。”
可以看到，Tomoro 所做的，是一次从技术能力到交互范式、从产品设计到架构理念的系统性重构。它不仅拓展了 BI 的用户边界，也在推动 BI 从“查询与展示工具”，走向真正能够理解业务、参与分析、辅助决策的“智能伙伴”。在这一意义上，BI 的未来，确实正在走向表格操作与智能体能力的深度融合。
火山引擎蒋煜|模型驱动的用户研究 Agent：真实业务的实践与挑战
蒋煜 火山引擎 /数据应用资深工程师
过去一年，我们持续在真实业务环境中探索一个问题：如何让大模型真正融入用户行为分析，而不是仅仅作为一个“工具”或一个“插件”。
背景来自非常具体的业务需求——分析师们长期以来需要依赖复杂的逻辑规则和人工经验，去判断用户是否具备某种行为倾向，例如为什么一个长时间沉默的用户突然变成了活跃评论者。
在这样的背景下，我们开始思考：如果让大语言模型参与行为分析，会发生什么？大模型天然具备两种优势——对自然语言的强理解能力和对复杂语境的泛化推理能力。
架构核心：行为数据的“中间表示层”
然而，将原始日志直接丢给大模型，并不能真正解决问题。真实业务的数据复杂度远比想象中高得多，更重要的是，原始日志充满参数噪声与不可理解的结构化字段，在这样一个“信息洪流”中，模型不仅难以聚焦关键行为，还极容易产生不稳定与幻觉。
因此，我们在架构设计中提出了一个关键创新——在原始日志之上构建“行为数据形态中间表示层”。这一中间层的本质，是把原本冗长、结构分散、语义不统一的行为日志，转化为一种更接近人类理解方式、更适合模型推理的表达形态。通过日志增强与语义抽象处理，我们成功将原始日志压缩到 5% 左右，同时支持分析时长扩展至原来的 20 倍以上。
在这一过程中，不仅对行为进行了逻辑聚合与叙事化表达，还对关键链路进行了语义补全与重构，使模型既能“看到结构”，也能“理解故事”。更重要的是，中间层同时保留了回溯链接——每一段模型分析都可回溯到原始日志，从而大幅降低幻觉风险，并为用户建立起可信赖的分析体验。
关键技术与实现路径
围绕这一核心设计，我们在真实产品化过程中解决了三个关键技术挑战。
第一，突破窗口限制，支撑超长行为分析。在真实业务中，用户行为往往跨越较长时间跨度。通过行为事件筛选、参数降噪、行为切片与语义重组，我们将庞大日志拆解为若干可理解且结构清晰的片段，并通过分段分析与结果汇总，实现“长行为 → 可推理行为”的转化。
第二，构建可信分析链路，保证可解释与可验证。大模型带来的不确定性与幻觉问题，是业务落地中最大的信任障碍。为此，我们的系统设计始终保持“模型结论 ↔原始数据”的强连接关系。通过日志增强中的回溯机制，每一条分析结果都可以清晰对应其支撑证据，从而让大模型从“黑盒分析工具”变成“可协作的智能分析伙伴”。
第三，强化人机协同，让 Agent 随业务成长。行为分析从来不是一次性计算，而是一种持续学习与认知进化过程。因此，我们在系统设计中引入业务知识库、领域分析知识与主动学习机制，使用户不仅是“使用者”，也是“训练者”。分析师可以通过自然语言提出新问题、提供反馈，Agent 则在这种互动中不断调整分析策略、优化推理逻辑。系统逐步形成一种“可共创”的分析模式，大幅提升团队分析效率与组织认知能力。
在实践打磨中，我们逐步形成了这样一种清晰共识：用户研究 Agent 的价值，不是简单替代分析师，而是用模型驱动数据理解，让行为分析回归“认知科学”本质。通过行为数据形态中间表示层，我们解决了海量行为数据与模型能力之间的结构性矛盾；通过可信机制与回溯设计，我们化解了黑盒不透明带来的业务不信任；通过人机协同与主动学习，我们让系统具备持续成长能力。
阿里云赵庆杰|数据驱动的智能诊断系统：多智能体系统在生产环境中的技术落地与实践
赵庆杰 阿里云 /Serverless 基础架构负责人 & AgentRun 产研负责人
赵庆杰分享了一套已经在阿里云核心生产系统落地运行，并在真实业务中验证价值的数据驱动智能诊断系统，在其中经历了从零到生产的完整过程，踩了很多坑，也逼迫我们对 Agent 技术能力、安全边界与工程落地进行了系统性思考。
这套系统最初诞生的背景非常直接。阿里云某核心 PaaS 系统每天承载着接近百万级别的实例运行，而运维团队需要在昼夜轮值下应对各种疑难问题。每一个问题背后都可能存在极其复杂的成因：可能是网络环境问题，可能是服务依赖异常，可能是业务代码设计不当，甚至可能是底层资源层噪音。在引入智能诊断之前，我们主要依赖人工排障，既耗费巨大人力成本，也难以避免人为误差，这成为推动我们采用 Agent 技术的现实起点。
系统的架构设计遵循“明确角色化分工”的原则。我们将诊断过程拆解为感知、推理、验证与执行四类核心能力，并由四种 Agent 分别承担对应职责。
感知 Agent 负责系统状态感知与异常捕获，它从指标、日志、链路数据以及 eBPF 事件中持续采集信息并进行初步异常识别；推理 Agent 则承担根因分析职能，它基于累积的上下文数据构建因果推断路径，给出候选解释；验证 Agent 专门进行“假设检验”，不断对推理结果进行校验，确保结论不是模型想象出来的“合理故事”；执行 Agent 则围绕修复策略进行生成与评估，并在安全约束之下输出可执行方案。
这种清晰角色划分的设计，让系统拥有了接近人类专家团队协作的能力结构，而不是把所有任务压在一个“大而万能”的模型身上。
支撑上述能力的核心基础，是我们打造的一套“全栈数据闭环体系”。在传统运维系统中，指标、日志、Trace 链路、系统内核事件往往被割裂存放与使用，导致诊断过程信息碎片化，模型无法获得真正有价值的上下文。我们统一将这些异构数据进行建模与封装，让其成为智能体可以理解、关联和推理的结构化语义上下文。这不仅显著提升了推理 Agent 的判断能力，也为验证 Agent 的逻辑校正提供了可靠数据基座。更重要的是，系统形成了“诊断—修复—反馈—再学习”的闭环，模型能够随生产演进持续进化，而不是停留在一次性规则堆砌。
最终，这套系统在真实生产环境中稳定运行，实践效果显著：MTTR 实测降低约 40%，人力值守压力大幅下降，诊断效率与稳定性都有明显提升，更重要的是，我们获得了一种可复制、可持续演进的工程方法论。
结语：
出品人宣善明总结到，从这次 Data+AI / Agent 落地实践论坛来看，四个案例分别覆盖了文档生成、数据分析、行为洞察和系统运维等典型业务环节，也代表了 Agent 正在进入企业真实场景的“深水区”。它们共同体现出三个明显变化：从单一模型能力转向具备角色分工与系统设计的工程化体系；从一次性效果转向具备闭环与可沉淀能力的长期机制；从简单替代人工转向增强团队与组织能力，让经验被结构化、复用并持续放大。
未来 Agent 的价值判断也将更加务实：是否稳定可靠、是否可控、是否能形成长期能力资产。谁能把 Agent 做成可复用、可持续演进的工程能力，而不是一次性工具，谁就更可能在下一阶段的智能化建设中真正受益。
