演讲介绍

商业化搜索长期面临一个根本张力：既要"搜得准"（用户体验/相关性），又要"变得现"（商业价值）。传统三段式流水线（召回→相关性→精排）在长尾/模糊query上常常要么给出不相关的结果，要么相关但没商业价值。

本次分享介绍小红书商业化搜索团队如何用Agent重构搜索分发引擎，从三个结构性瓶颈切入：召回靠固定多路+静态融合覆盖不足、相关性标准靠人肉规则口径漂移、精排靠手工试错迭代慢。团队没有推倒重建，而是在保留现有工业级检索基建的前提下，用三个Agent做增量重构：召回Agent做Agentic检索编排（按query意图动态决策打哪几路、怎么融合）、相关性Agent参与标准设计+大规模自动标注+human-in-the-loop校准（把"人肉标准"变成可规模化复用的资产）、精排走向AutoResearch（让"假设→实验→评估→迭代"闭环自动化）。

最终实现：Agent不裸跑线上，而是用于离线造标准与数据+在线灰度+人工校准闭环，配套离线评测体系做守门，保证可控与可回退。

演讲提纲

一、开场：商业化搜索的根本张力与三处结构性瓶颈

场景痛点：用户搜"油痘肌 平价 精华"——传统流水线给出不相关贵价大牌或相关但无商业价值的结果

三处瓶颈：①召回固定多路+静态融合，长尾覆盖不足 ②相关性标准人肉定义、口径漂移 ③精排手工试特征试结构、迭代慢

二、选型对比：为什么是Agent重构而非推倒重建

业界三条路线对比：传统级联流水线 vs 端到端生成式 vs Agentic编排

选型逻辑：保留工业基建，从三个增量切入，风险可控可分段验证

新命题：如何保证Agent可控与可回退

三、方案落地：三个Agent的具体实现

召回Agent——Agentic检索编排：query意图解析→动态改写扩展→决策召回通路与配额→动态融合，每路召回通道都是Agent的tool

相关性Agent——标准设计+数据标注：把模糊规则结构化成可判定的分级rubric，大规模自动标注+human-in-the-loop校准

精排走向AutoResearch：Agent自动完成"假设→实验→评估→迭代"闭环，算法同学从"手工试错"转为"定目标、审结果"

关键工程决策：Agent用于离线造标准与数据+在线灰度+人工校准，不裸跑线上

四、效果展示

业界对标：Agentic retrieval/LLM辅助相关性标注/自动化ML研究方向对比

量化效果：召回相关率/长尾覆盖提升、相关性标注成本↓+一致性↑、搜索相关性GSB提升、商业化核心指标CTR/CVR/收入提升、精排迭代周期缩短

badcase修复前后对比演示

踩坑故事：早期Agent自动标注在某垂类出现系统性偏差，用小样本人审+校准闭环拉回一致性

五、总结：三条带走的方法论

先用Agent造标准与数据，再谈上线

保留工业基建，用Agent做编排与调优的"外挂大脑"

用"离线+灰度+人审"闭环换可控性

听众收益

理解商业化搜索中"相关性vs收入"的结构性矛盾，以及Agent重构如何让二者同时抬升——不是理论，是亿级搜索场景的真实落地
掌握三个Agent的具体设计方法：Agentic检索编排（召回侧）、Agent参与标准设计+自动标注（相关性侧）、AutoResearch闭环（精排侧），可迁移到自己的搜索/推荐系统
学会"Agent不裸跑线上"的工程化策略：离线造标准与数据+在线灰度+人工校准+离线评测守门，解决"Agent可控与可回退"这一共性焦虑
获得一条可复用的落地路径：保留现有工业基建，用Agent做增量重构而非推倒重建，风险可控可分段验证

落地挑战和方案重点

方案重点：
Agentic检索编排：召回从"静态多路配置+固定融合权重"变为"按query意图planning"，每路召回通道作为Agent的tool动态调度
标准与数据同源：相关性Agent把模糊规则结构化成可判定的分级rubric，自动标注+human-in-the-loop校准，产出的不是一次性数据而是可复用资产
AutoResearch闭环：精排从"手工试特征/试结构/调超参"升级为Agent自动完成"假设→实验→评估→迭代"，算法同学转为"定目标、审结果"
可控性设计：Agent主要用于离线造标准与数据+在线灰度+人工校准闭环，不裸跑线上，配套离线评测体系做守门

落地挑战：
Agent的可控与可回退：Agent"会思考"不等于"不可预测"，需要通过离线评测体系、灰度机制、人工校准闭环来保证可控性，约束太少无法保证交付，约束太多又损害Agent自主性
自动标注的系统性偏差：早期Agent自动标注在某垂类出现系统性偏差，需要用小样本人审+校准闭环把一致性拉回来——开放业务场景缺少稳定标准答案，Judge也可能漂移
Agent的成本与延迟：LLM驱动的方案都有耗时和成本问题，需要平衡Agent带来的效果提升与推理成本增加

演讲介绍

路线推荐是高德地图的核心能力，每天服务数亿用户。我们构建了行业首个全场景统一路线推荐架构RouteMind，系统性解决非ID化对比、多样性与去冗等难题。随着大模型时代到来，进一步构建路线规划Agent，让系统能够理解自然语言需求，完成复杂出行任务；同时探索TransitLM端到端路线生成，尝试将时空知识直接内化到模型中。本次演讲将分享从工业引擎到Agent，再到端到端时空基座的技术演进路径。

演讲提纲

开场：一个自然语言算路需求引发的思考（3min）

第一幕：理解路——工业引擎如何破解路线推荐的独特难题（8min）

矛盾A：非ID化对比+多样性质量平衡 → CCN+SCASRec细粒度交叉与生成式去冗

矛盾B：召排割裂 → GenMRP生成式多路线召回

第二幕：理解人——Agent如何理解需求并调用工业工具（15min）

Agent架构设计：速度×质量×迭代速度的平衡

与工业推荐引擎怎么结合：理解人、调用工具、输出路线与解释

后训练需要吗：提升领域理解、工具调用和任务编排稳定性

Benchmark驱动的快速迭代：MobilityBench与可视化评测平台

第三幕：理解时空——TransitLM端到端生成路线（7min）

TransitLM：不查地图、直接生成公交路线

隐式空间定位与路线生成能力涌现

时空基座模型的未来想象与边界

总结：三次跃迁的演进逻辑、三个经验takeaway与未来展望（7min）

听众收益

1.了解超大规模路网下路线推荐系统的独特挑战，以及从工业引擎到Agent、再到端到端时空基座的技术演进路径和关键决策逻辑

2. 深入掌握路线规划Agent的设计哲学：如何理解自然语言需求、调用工业推荐工具、在速度与质量之间取舍，并用Benchmark驱动迭代
3. 理解TransitLM端到端路线生成的核心想象力：模型如何尝试内化时空知识，以及这种方向与生产级Agent的边界和互补关系

落地挑战和方案重点

1. Agent速度×质量的平衡**：导航场景要求秒级响应，但Agent调用工具链天然慢。如何在保证速度的同时给出好答案，是生产级Agent的核心挑战。

2. 从用户反馈驱动到Benchmark驱动的范式转变**：传统推荐以用户反馈（点击、实走、偏航）为效果评估核心，但Agent推荐面临新交互形态（对话、追问、定制），用户反馈信号稀疏且滞后。如何以Benchmark为核心驱动快速迭代，同时建立Agent推荐的用户价值评估体系，是关键挑战。

3. Agent与工业推荐系统的融合**：Agent擅长语义理解和个性化，工业引擎擅长确定性路线计算。如何让Agent调用工业引擎作为工具而非替代，实现能力互补，是我们实践中摸索出的关键设计原则。

演讲介绍

LLM4Rec正在驱动推荐范式的升级，包括几个阶段：
1. 拆解LLM的MTP技术并赋能传统推荐模块，扩展推荐迭代的边界；
2. 构建LLM-based的推荐模型，突破传统推荐范式的限制，为系统注入交互与知识推理能力；
3. 实现新旧推荐范式的融合，迈向交互式推荐， 实现可交互、可推理、可解释的全新推荐体验，并推出了全新的交互式推荐产品：AI伴听。

演讲提纲

1.总体介绍：LLM4Rec的技术视图，及赋能推荐系统的三个阶段；

2. 阶段一：拆解LLM技术，拓展传统推荐的迭代边界：基于MTP构建生成式召回，在TME 10+业务场景取得显著收益，相关工作已被CIKM2026接收；
3. 阶段二：构建LLM-based的领域推荐模型：通过继续预训练、SFT及RLHF，自研构建MusicRecLLM-8B，为可交互的音乐推荐打下技术基础；
4. 阶段三：新旧推荐范式融合，构建推荐Agent：能够理解用户的自然语言输入，并驱动推荐全链路进行响应，通过生成式模型及更多的 Scaled Models做超大规模的限制性推荐，并最终结合对用户的完整理解与因果推理，实时生成推荐理由。
5. 总结与规划：概括回顾以上内容；并展示当前进一步在做的方向，如通过LLM重构对用户lifelong行为的理解。

听众收益

1.生成式召回在大规模推荐场景的落地方式；

2. 通过预训练与后训练，构建LLM-based的推荐领域大模型的方式；
3. 构建一个可交互、高智能的推荐Agent的方式。

落地挑战和方案重点

1. LLM驱动的方案，都有耗时和成本的问题；
2. 推荐Agent场景下，反馈数据难以归因。

演讲介绍

企业数据服务长期困在两个瓶颈：看板永远做不完、长尾需求覆盖不全；而业务真正要的"为什么、怎么办"，传统取数只能回答"是多少"。高德智能问数（小豪）没有选择堆更大的模型，而是把沉淀多年的BI底座改造成可路由、可加载领域知识的Agent底座。两个月里我们经历了一次真实的架构迁移：MVP阶段39张表准确率89.4%，全量扩到331张表时端到端准确率一度暴跌到50%，最终从RAG+Workflow切换到Skill架构才回升到95%。本次分享按Gartner L2→L3→L4坐标，复盘这条从"数据问答"走向"洞察生成"的迭代路径、架构决策、踩过的坑。

演讲提纲

一、业务背景：看板做不完，且"拿到数≠拿到洞察"；Gartner L0-L4坐标

二、方案选型：为什么是"改造BI底座为Agent底座"而非接更大模型；A+B双引擎；核心是语义层建模

三、落地过程：MVP（89.4%）→ RAG全量（暴跌50%）→ Skill架构（95%）

四、解决思路：AI-Friendly知识库三类知识来源（元数据自动/业务知识人喂/路由规则）；评测飞轮三件套

五、业界案例与成效：字节/美团NL2SQL 95%、OpenAI 6层context对标

六、落地挑战与未来规划：L3洞察可信度/用户信任/信息损失

七、总结：底座决定上限，从"答得对"到"看得透"才刚上路

听众收益

1. 如何把已有数仓/BI资产改造成Agent可消费的底座，而非推倒重建

2. 一次真实的架构迁移全过程——RAG为何撑不住、Skill架构为何成为出路（89.4%→50%→95%）

3. data agent落地的真正难点在语义层与评测体系这两块"脏活"

4. 对"数据问答→洞察生成（L2→L3）"方向的判断与开放挑战

落地挑战和方案重点

最大挑战出现在规模化：单领域 MVP 表现很好（89.4%），但一旦全量扩表，RAG+Workflow 架构的本质缺陷暴露——一次性知识召回、多步信息损失、不支持跨表复杂计算，导致端到端准确率暴跌到 50%。方案重点是架构层从 RAG+Workflow 切换到 Skill（渐进式披露）架构，用按需召回 + AI 自反思纠错，把准确率拉回 95%，同时在agent框架下通过skill，实现用户深度/延展的用数场景的可控性与扩展性。

演讲介绍：

大模型正从单点 Copilot 演进为 Agent 智能范式，但企业的数据散落在多云多品牌之间，合规约束严苛，碎片化 AI 应用各自为战，Agent 上了线也"无数据可用"。本次双人分享由某全球头部高端零售厂商与数新智能CTO联合呈现：上篇从业务视角拆解高端零售全球化多云数据管理的真实痛点——数据孤岛、合规壁垒、碎片化 AI 的局限，以及对 Agent-Ready 数据底座的核心诉求；下篇从技术视角输出解法——多云 AI 原生平台之上的 DataAgent 整体架构、企业语义层构建、沙箱安全防护与闭环迭代体系，并详解高端零售行业落地的工程难点与解法。

演讲提纲:

上篇｜某全球头部高端零售厂商 CTO（行业实践视角）

高端零售全球化数智化转型行业背景：多品牌布局、全球数千零售网点，传统人工驱动的数据运营模式的瓶颈。

企业多云多架构下的数据核心痛点：数据孤岛、经验决策效率低，高端零售行业极高的数据安全、隐私合规约束。

行业 AI + 数据智能化转型实践与探索：门店优化、用户运营、需求预测、防伪溯源等场景落地，点明碎片化 AI 应用的局限。

业务侧对 AgentReady 数据底座的核心诉求：多环境适配、安全防护、语义理解、可迭代的企业级 DataAgent 能力。

下篇｜数新智能 CTO（技术视角）

DataAgent 架构升级核心背景：承接高端零售业务痛点，结合全球化项目落地经验，剖析企业多云异构环境下的共性技术难题。

数新一站式 DataAgent 整体架构设计：构建一站式多云数智底座、企业专属语义层，依托项目实践完成全链路 DataAgent 架构整体设计。

核心工程挑战与落地解决方案：Skills 技能生态、上下文工程、沙箱安全防护、闭环迭代体系四大核心能力，支撑中企出海及全球企业入华等复杂业务落地。

企业落地核心难点专项解法：多版本兼容容错、业务知识库补齐治理方案，解决全球化企业落地核心痛点。

架构升级的效果衡量：端到端的数据交付效率整体提升70%左右；Agent任务诊断准确率提升50%，通过语义知识库的建设，代码生成准确率从30%提升到90%。

总结与未来展望：沉淀项目实战经验，拓展Agent多模态应用能力。

听众收益：

1.业务视角：了解高端零售全球化企业多云数智转型真实痛点，掌握高端行业建设 AgentReady 数据底座的业务诉求与建设门槛。
2.技术视角：掌握 Harness 范式企业 DataAgent 完整架构设计，学习沙箱、细粒度权限管控等高合规行业安全落地策略。
3.工程实践：学习 Apache Ossie 本体规范、CodeWiki 语义增强方法论，补齐企业元数据短板，提升 Agent 业务理解与执行准确率。

落地挑战和方案重点:

1.多云异构环境下 DataAgent 高可用适配：企业多版本、多场景环境复杂，依靠动态技能注册、异常降级自愈，解决 Agent 适配容错难题，保障复杂异构环境稳定运行。
2.企业元数据、业务知识库残缺：业务资料零散，依托 CodeWiki 自动化语义抽取，联动业务建立长期治理闭环，持续提升 Agent 对业务理解的精准度。

演讲介绍:

Curvine（曲率引擎）是面向 AI 原生与云原生工作负载的高性能分布式缓存文件系统——在多云对象存储之上叠加 POSIX 文件语义 + 多级分布式缓存，为大规模 AI 训练/推理、AI Agent 平台、大数据存算分离与多云迁移，提供统一、低延迟、可治理的端云协同数据访问层。

演讲提纲：

1、云端弹性Agent的数据痛点

2、业界已有方案分析

3、Curvine在Agent端云协同场景技术方案

4、Curvine在AI其他场景案例

5、Curvine的性能效果数据

6、未来展望

听众收益：

1、了解Curvine技术特点，体验云上大规模Agent技术需要特点

2、接触前沿AI场景下对数据基建的技术演进动向

落地挑战和方案重点：

1、Curvine在AI训练场景下数据加速应用

2、Curvine在AI推理多层KVCache扩展应用

3、Curvine在端云Agent沙箱场景应用

4、Curvine在多云场景解决带宽瓶颈落地

演讲介绍

数仓智能问数Agent落地后，"答得对不对"长期靠人工抽检，实验室题单一、口径漂移不可感知。我们自建"建—管—CI—归因"四阶段流水线，以任务完成度45%为核心权重构建评分体系：基于线上真实问题构建4大业务方向千题级评测集，14天滚动更新；以聚合守恒、场景路由、SQL一致性细化单一EX判定；并行调度+答案隔离实现无人值守评测CI。题库已生产可用，人力成本消耗降低约30%。

演讲提纲

一、业务背景：评测是Data Agent的"信任基础设施"——三大痛点：人工抽检不可持续、实验室题单一、口径变更不可感知

二、方案选型：为什么不直接用BIRD/Spider——三点不适配。自建"建—管—CI—归因"四阶段流水线。四维评分体系（任务完成度45%/推理规划25%/工程效率15%/安全鲁棒15%）

三、落地挑战：答案可信与防泄露、判定粒度、千题级评测耗时、评测集时效

四、解决思路：建（千题级评测集/1000题入库）；管（14天滚动更新+版本快照+口径变更感知）；CI（无人值守/并行调度/答案隔离，24h→12h人力降30%）；归因（聚合守恒/路由命中率/SQL一致性/反哺Skill）；安全鲁棒（提示词→确定性软件拦截/前置准入校验→物理隔离→权限隔离）

五、未来规划：看板化、知识化、硬隔离

六、总结：①评测是迭代基础设施；②真实问题+滚动更新对抗口径漂移；③判定细到"为什么错"

听众收益

1. 认知升级：看清企业级评测与学术基准的本质差异——四维评分框架及权重设计

2. 工程方法：一套可落地的"建—管—CI—归因"评测流水线——千题级评测集/14天滚动更新/无人值守CI

3. 判定经验：让评测从"打分"升级为"改进"——聚合守恒/路由命中率/SQL一致性等细粒度判定

落地挑战和方案重点

痛点 1：评测器自身的可信度——"谁来评测'评测'"

标准答案基线会随口径演进悄悄失效（std_sql 过期、单实体答案覆盖不了多实体问题），机器判定也存在误杀（如聚合粒度不一致被判错、守恒等价未纳入判定出口）。目前仍需人工抽检兜底误判归因，"Skill 真实错误率"与"评测不可判率"如何干净分离、基线健康度如何低成本持续保鲜，尚无完美解法。痛点 2：从"发现错误"到"修复错误"的闭环尚未打通

评测能量化准确率、定位口径错误，但归因仍依赖人工逐题看报告；口径知识散落在个人经验中，无法自动沉淀为结构化指标知识反哺 Skill 生成。"评测→知识→准确率提升"的双向反馈是我们正在攻坚的下一阶段命题，欢迎有同类实践的团队交流。

演讲介绍：

MiraDay 是招聘领域的垂类 Agent。我们发现交付质量的瓶颈不在模型能力，而在兑现率。大家的能力上限在快速趋同，兑现率才是垂类 Agent 的主战场。为此我们构建MiraBench 做部署时对齐（deployment-time alignment）；并把“停止”作为兑现率最大的单一损失源，在 Harness 层进行了专项处理。重构后 MiraBench 综合分从 40.1 提升至 75.2

演讲提纲：

1、背景与痛点
2、思考与解决方案
3、收益与表现
4、未来展望

听众收益：

1.理解垂类 Agent 的“交付质量”不能只看任务是否跑完，需要从稳定运行、任务完成、交付正确，一直追踪到用户采纳和业务结果。

2. 掌握一套从真实业务构建 Agent Benchmark 的方法：以业务任务为主轴，加入能力探针和分层判定，再从评估结果回到 Trace 定位理解、规划、执行、验证和停止问题。
3. 了解如何通过 Harness 管理 Agent 的运行时行为，特别是利用外部证据校准 continue / ask / commit，减少早停、空转、过度执行和错误交付。

落地挑战和方案重点：

1. 开放业务场景缺少稳定标准答案，Judge 也可能发生漂移。需要组合使用确定性断言、业务约束、模型判定和真实用户行为，并持续用人工金标校准。
 2. Harness 的边界很难把握：约束太少无法保证交付，约束太多又会损害 Agent 的自主性。实践中需要将硬约束、证据验证、预算控制和停止判断分层设计，而不是把所有规则都塞进 Prompt。

演讲介绍：

随着大模型和 Agent 框架逐渐成熟，Agent 的搭建门槛不断降低，但要真正进入业务并实现规模化应用，仍需解决效果判断、问题定位和版本回归等难题。本次分享将结合美团在 AI Agent 评测平台建设及业务落地中的实践，介绍 Agent 评测与传统模型评测的差异，以及如何建立可信的评测标准，通过“人人一致、人机一致”提升评测的准确性和规模化能力，并借助 Agent 迭代与评测体系迭代的“双 Loop”，持续发现问题、定位原因并驱动优化。

演讲提纲:

1. 业务背景：为什么 Agent 落地需要新的评测体系
随着基座模型、Agent 框架和工具协议不断成熟，搭建一个 Agent 越来越容易，但将其稳定推向真实业务和规模化应用仍然很难。真实环境中的 Agent 由模型、Prompt、规划、知识、记忆、Tool/Skill 和工程流程共同构成，任何一个环节的问题都可能沿执行链传递，最终表现为难以理解、难以复现的异常。
本部分将通过真实案例说明：只看最终回复，往往无法判断任务是否真正完成，也无法定位问题发生在哪一步。因此，Agent 评测不仅要回答“效果好不好”，还要回答“哪里好、哪里不好”，成为支撑研发、回归、上线和持续优化的“精密量具”。

2. 方案选型：Agent 评测应该测什么、怎么测
Agent 评测需要从单一的答案打分，转向对任务结果、执行过程、效率和风险的综合判断，既看最终 Response，也看完整 Trace/Trajectory。
在评测方法上，根据问题性质组合使用多种方案：
- 客观评测与主观评测并行：对事实、状态和明确约束采用规则、代码或数据核验；对语义质量和整体体验采用人工或 LLM-as-a-Judge，按照 Rubric 判断。
- 端到端评测与过程评测结合：端到端评测判断用户任务是否完成，过程评测沿规划、Skill、知识和工具调用定位问题。
- 离线评测与在线评测结合：离线回测守住评测集已经覆盖的已知场景，在线评测、监控和巡检持续发现真实流量中的未知问题。
评测体系的核心不是堆叠指标，而是在模型能力、Agent 能力、任务目标和业务目标之间建立可解释的连接。

3. 落地挑战：评测体系建设中的关键难点
第一，Agent 执行链路复杂。最终回复成功不等于任务真正成功，如果缺少完整观测数据，就无法复现现场和定位根因。
第二，主观标准容易漂移。产品、运营、研发和 QA 可能使用不同尺度判断同一个样本，导致版本指标变化无法解释。
第三，机器评测不一定可信。LLM Judge 只有稳定复现经过校准的人工判断，才能用于规模化评测。
第四，离线评测存在天然覆盖边界。固定评测集只能验证已知场景，无法自动发现新的用户需求、行为分布变化和未知问题。
第五，Bad Case 只能说明“这里出了问题”，如果缺少沿 Trace 的归因机制，就无法判断应该修改 Agent，还是应该校准 Rubric、Judge 或评测集。

4. 解决思路：构建可信并持续演进的评测闭环
首先，建设“最小可归因”的观测能力，记录完整的模型输入输出、Tool/Skill 调用、执行状态和任务结果，为过程评测与问题归因提供基础。
其次，通过“人人一致、人机一致”建立可信标准：
- 设置明确的质量口径负责人，联合业务专家定义“什么叫好”。
- 采用背靠背标注发现分歧，将模糊标准下钻为可观察、可执行的 Rubric。
- 使用校准后的人工结果验证机器评测，使 Judge 能够规模化复现人工标准。
再次，建立由“四个模块、三种能力、两个 Loop、一套资产”组成的完整体系：
- 四个模块：离线评测、在线评测与监控、Case 挖掘与归因、观测基建。
- 三种能力：发现问题、定位问题、驱动演进。
- 两个 Loop：一个 Loop 改进 Agent，一个 Loop 校准评测体系。
- 一套资产：持续版本化的端到端与过程评测集。
最后，通过真实 Case 将两条 Loop 连接起来：线上发现问题，Case 池沉淀样本，沿 Trace 完成根因分析；Agent 问题进入修复、离线回测和上线验证，评测问题进入 Rubric、Judge、标签及评测集校准。

5. 未来规划：从最小闭环走向规模化与自进化
Agent 评测体系不应一次性追求“大而全”，而应根据业务阶段渐进建设：
- 冷启动阶段：优先建立完整 Trace、端到端种子评测集和基础回测门禁，形成最小闭环。
- 扩量阶段：完善分层评测集、过程评测、在线巡检和 Case 池，提高问题发现与定位效率。
- 规模化阶段：持续提升人机一致性，将评测自动嵌入研发和发布流程，实现评测集版本化、线上 Case 自动回流、机器辅助归因及自动化门禁。
- 持续运营阶段：通过真实业务数据不断发现评测盲区，使 Agent 能力与评测体系共同进化。

6. 总结：一套成熟评测体系的四个核心认识
  - 评测是衡量 Agent 效果的“精密量具”。
  - 人人一致让标准可信，人机一致让评测规模化。
  - Agent 评测是一门实践科学，需要从真实 Case 中持续生长。
  - 一个 Loop 改进 Agent，一个 Loop 校准评测；Case 负责连接，评测集沉淀共同资产。
本次分享最终希望帮助听众建立一套可执行的 Agent 评测建设路径：从看见问题、统一标准开始，逐步形成能够发现问题、定位问题并持续驱动业务演进的工程闭环。

听众收益：

1.建立完整的 Agent 评测认知：理解 Agent 评测与传统模型评测的差异，掌握从结果、过程、效率和风险等维度评价 Agent 的基本框架。

2. 掌握可落地的评测体系建设方法：学习如何通过“人人一致、人机一致”建立可信标准，并结合离线评测、在线评测、Case 归因和观测基建形成工程闭环。

3. 获得分阶段建设与避坑经验：能够根据业务所处阶段识别评测体系短板，从最小可用闭环起步，逐步建设“双 Loop”机制，持续推动 Agent 与评测体系共同演进。

落地挑战和方案重点：

1. 主观评测标准难统一、机器评测结果难以直接信任。不同角色对同一样本可能产生不同判断，LLM Judge 也可能随模型、Prompt 和样本分布变化发生漂移。方案重点是先通过标准责任人、背靠背标注和可执行 Rubric 实现“人人一致”，再持续抽样复核和校准 Judge，实现“人机一致”。这一过程仍需要业务专家和人工标注投入，无法一次建设后永久有效。

2. 离线评测只能覆盖已知场景，难以及时发现真实流量中的新问题。固定评测集适合版本回归和发布门控，但无法验证尚未进入评测集的新需求。方案重点是结合在线评测、监控巡检和 Case 挖掘发现未知问题，再沿 Trace 完成归因并回流评测集。其挑战在于需要较完整的观测基建，同时要平衡覆盖率、发现时效与评测成本。

演讲介绍

当前企业 AI 改造的常见误区，是把旧系统加一个对话入口当作完成升级：模型可以生成自然语言，但没有业务身位、不掌握企业专属口径，也无法在执行前拦截副作用，导致输出「可用但不可信」。通用 Agent 与业务 Agent 的本质差异不在模型能力，而在约束层：通用 Agent的判断标准内嵌于执行环境（可编译、可运行即算通过），且以沙箱为默认收口；业务 Agent 的判断标准落在企业规则、口径与合规红线上，需在执行前完成确定性校验。为此我们把 Harness 抽象为三道约束——角色约束（系统提示层固化身份与拒绝边界）、知识约束（业务图 / 指标库 / 案例库 / 文案库，按需检索）、动作约束（业务原语 + 资源 / 权限 / 端口 / 比例 / 时间的确定性校验）。已在 chatMA（营销策略 Agent）与 JoyAnalysis（数据分析 Agent）落地：将业务目标转化为可校验、可回放、带血缘的产物流。

演讲提纲

1.业务背景：旧软件接入 AI 往往只是增加一个输入框。营销人员知道要做召回却配不出画布，经营人员知道要看产值却不会找表写 SQL——缺的不是入口，而是把业务目标翻译成可执行动作的过程。

2.方案选型：为什么通用 Agent（codex、workbuddy 一类）扛不动业务？它没有企业身位、没有专属资产、不承担副作用。解决方式不是换更强的模型，而是在同一通用运行时之上，由业务侧补一层约束，即三道约束：立角色、喂知识、限动作。

3.落地挑战：隐性知识显性化，把资深员工脑子里的规则、口径、踩坑经验沉淀为可检索资产；以及生成式与验证式的划界，让越靠近副作用（发送、发布、写入）的步骤越由代码收口。

4.解决思路：角色约束落地为角色宪章，定义它是谁、如何判断、何时拒绝，并注入提示词栈；知识约束落地为业务资产能力化，包括业务图、指标库、案例库、文案库，以检索即服务的方式供给；动作约束落地为业务原语加确定性校验，对资源、权限、端口、比例、时间逐项把关，缺一阻断，由代码收口。两个案例分别演示三道约束如何装进运行时：chatMA 演示从业务需求到可编辑策略的全过程，JoyAnalysis 演示只读查询、权限控制与证据闭环。

5.未来规划：把三道约束沉淀为可复制的企业落地路线，依次是立三道约束、接入 Agent loop、回到产品闭环，并逐步扩展到更多业务闭环。

6.总结：企业不必重写所有旧软件，只需找到最有价值的业务闭环，用三道约束把它约束成模型可参与、代码可约束、用户可信任的 Harness。

听众收益

得到一套可迁移的框架：用“角色 · 知识 · 动作”三道约束，判断自己的业务该在哪约束模型、约束什么，而不是笼统地“上个 Agent”。
看清通用 Agent 与业务 Agent 的边界：理解同一模型 + 通用运行时之上，业务侧究竟要补哪三层适配，从此能回答“为什么通用 Agent 直接用不了”。
带走可直接上手的模板：业务闭环画布、角色宪章模板、业务资产卡片三份脚手架，听完就能梳理自己的业务闭环。

落地挑战和方案重点

1.隐性知识的显性化仍是最大成本。角色宪章、业务图、指标库依赖对资深员工经验的一手抽取，初期投入重、见效慢；一旦停在“模型答得像不像人话”的评估层面，就很容易低估这块工作量。方案重点：先用业务闭环画布锁定一段高价值闭环，小切口把资产盘点做扎实，再用复用率、越权拦截率等指标证明价值。
2.“生成式”与“验证式”的边界需要业务与技术共同定义。哪些动作可以交给模型自由提出候选、哪些必须在副作用前硬校验（资源 / 权限 / 端口 / 比例 / 时间），边界定松了会出事、定紧了会丧失灵活性。方案重点：以“副作用梯度”为原则——越靠近发送、发布、写入，越从生成式转为验证式，并由代码收口。

演讲介绍：

以 GUI 自动化测试执行为切入点，拆解大模型在垂直业务中 "从能用变好用" 的完整适配路径 —— 什么时候靠 Harness Engineering 就够了，什么时候必须上后训练，以及两者如何协同。
大模型落地企业业务的核心命题，不是 "模型够不够强"，而是 "模型在具体场景里够不够稳、够不够准"。围3绕这一命题，业界形成了三条技术路径：Harness Engineering（框架侧控制）、RAG/Prompt（知识注入）、后训练（模型侧固化）。三者各有边界，但在真实项目中往往需要组合使用、动态取舍。
本次分享以基于大模型的 GUI 测试执行 Agent 为贯穿案例，系统讲述我们在实践中的思考与踩坑：
Part 1 聚焦 Harness Engineering—— 从 Agent 的本质出发，梳理框架侧可干预的 10 个关键节点，重点拆解上下文工程的场景适配方法，以及 Tool Calling 的管理与兜底机制，回答 "什么时候框架侧就够了"。
Part 2 进入后训练 —— 介绍后训练的整体范式，结合测试执行场景分析哪些问题适合通过后训练解决、如何构建高质量数据集、训练机制如何设计，并对效果进行实证探讨。
最终目标是给出一套可复用的选型决策框架：面对一个具体业务场景，如何判断该投 Harness 还是投训练，如何分配工程资源，如何用评测闭环驱动持续优化。

演讲提纲：

part 1 

如何通过Harness Engineering优化领域agent
1.agent的本质

2.harness干预的10个节点
3.上下文工程与场景适配
4.Tool Calling Management与兜底

part 2

模型后训练与agent优化

1.后训练整体范式
2.以测试执行为例哪些场景适合后训练
3.以测试执行为例如何构建数据集
4.以测试执行为例训练机制与效果探讨

听众收益:

1 一套选型判断框架 拿到一个 Agent 场景，能快速判断 "Harness 够不够、要不要上后训练"，避免盲目投入训练资源
2 Harness 干预的 10 个节点清单 从上下文、工具调用到兜底策略，覆盖框架侧优化的完整操作面，可直接对照自查
3 GUI 测试执行的实战经验 一个真实垂直 Agent 从 0 到 1 的优化路径，包括踩坑点和解决方案
4 后训练数据集构建方法论 针对 Agent 类任务，如何采集、清洗、标注训练数据，保证数据质量与场景覆盖
5 评测驱动的优化闭环 如何建立 Agent 框架 + 评测反馈循环，用数据而非直觉驱动效果迭代

落地挑战和方案重点：

核心挑战
边界模糊：Harness 能解决的问题和必须靠训练解决的问题，在项目初期往往难以区分，导致要么过度训练（成本高、迭代慢），要么框架补丁越堆越多（维护灾难）。
Harness 复杂度失控：上下文拼装、工具路由、异常兜底层层叠加，系统变得不可解释、不可维护。
后训练数据稀缺：Agent 执行类任务的高质量标注数据获取成本高，且分布长尾严重。
效果评估困难：GUI 测试执行的 "正确性" 涉及多步推理与视觉理解，传统单轮评测指标不适用。

方案重点
边界模糊   建立决策矩阵：按问题类型（知识缺失 vs 能力缺失 vs 稳定性缺失）匹配适配手段；先 Harness 验证可行性，再决定是否后训练固化
Harness 复杂度 梳理10 个干预节点，将上下文工程、Tool Calling 管理、兜底策略模块化、可配置化，避免硬编码补丁
数据稀缺  采用人机协同 + 轨迹回放构建数据集：从真实执行轨迹中挖掘正负样本，结合规则自动标注 + 人工抽检
评估困难  构建多步任务评测集，以端到端任务成功率为核心指标，辅以单步准确率、重试次数、耗时等过程指标

演讲介绍：

公司采用外购第三方机器人方案，存在定制困难、长期调用成本高、业务流程难以深度打通等问题。团队启动自研路线，依次完成向量知识库、大模型对话、传统 SOP 流程机器人建设，并演进至 Agentic 智能语音机器人。落地中攻克实时语音链路时延、Agent 流程失控、知识库幻觉等难题，构建分层记忆与任务调度体系。上线后人机对话完成率显著提升，长期服务成本下降，形成一套可复用的企业智能机器人迭代建设路径。

演讲提纲：

一、业务背景：外购语音机器人痛点，自研转型动因

二、方案演进与选型复盘

阶段 1：第三方外购平台试用与局限性总结

阶段 2：向量知识库 + RAG 基础对话能力搭建

阶段 3：大模型接入、标准化 SOP 流程机器人落地

阶段 4：升级 Agentic 架构，实现自主任务规划语音机器人

三、落地核心挑战梳理

四、关键解决思路与架构设计（记忆体系、任务调度、语音端到端协同）

五、上线效果与数据复盘

六、未来规划：多智能体协同、持续降低推理成本、自动化评测体系建设

听众收益：

1.掌握对话机器人外购 vs 自研的选型判断标准，理清不同阶段技术投入边界；

2.学习从向量 RAG、SOP 机器人向 Agentic 语音智能体平滑演进的工程实施路径；

3.获取线上生产环境中大模型语音交互、Agent 任务调度、知识库幻觉治理实战方案。

落地挑战和方案重点：

1.Agent 任务执行不确定性：复杂业务流程下智能体易偏离标准 SOP，出现流程跳跃、幻觉输出；重点方案：软硬规则双层约束、任务状态持久化、多轮行为校验机制。

2.语音链路 + 大模型联合推理时延压力：音频流处理、向量检索、LLM 串行调用造成响应超时；重点方案：模块异步解耦、热点知识库预缓存、分级推理策略优化。

演讲介绍：

营销补贴花得值不值,本质是个因果问题:补贴带来了多少增量订单。难点在于反事实不可观测——没有"不发补贴会怎样"的对照,连算得对不对都无法直接检验。而大模型的本能是"总能给个答案",放进这种没有标准答案的场景,反而是风险。

我们在做的,是把过去一次性、靠人工的因果评估,变成一个每天能批量跑、结论可复现、可审计的评估引擎。重点不在"算得更准",而在让系统知道哪些活动自己没资格下结论，上线以来支撑了多个业务场景的营销评估。

演讲提纲：

一、业务背景:营销补贴ROI为什么是"没有真值的决策"

二、方法选型:因果方法不是单选,而是一条按数据条件降级的路由,厘清AI在这里的能力边界

三、落地挑战:口径污染、活动重叠、小样本匹配等典型问题

四、解决思路:用工程手段锁住可复现,再用一套分层校验,逐层兜住上述问题

五、未来规划:让方法选择更自动、把评估经验沉淀复用

六、总结:没有ground truth的决策系统,工程重心从"追求更准"转向"管理系统对自身正确性的认知"

听众收益：

一套判断AI在系统里该放哪一层的可复用判据

无真值场景下的可信度工程方法

三个真实案例复盘

落地挑战和方案重点：

规模化与自证的张力:引擎能日跑大量活动,但可信度分级仍依赖部分人工阈值,如何让系统自动、可靠地判定结论是否成立,仍是开放问题。

无真值下的方法排序:多个方法结论不一致时,业界还没有公认的离线择优标准。我们用多方法交叉验证 + 人工裁决守住结论的可靠性,并在把这套裁决经验沉淀为可自动化的仲裁机制。

演讲介绍：

自然语言问数让业务用户可以聊着天查数据，但在广告经营分析这样的真实场景中，一次性回答远远不够。业务更需要可复现的分析过程、可追溯的数据口径、可持续生成的报告模板，以及能被多人、多入口、多 Agent 复用的组织资产。本次分享将结合京东广告数据分析 Agent 的核心设计与开发实践，介绍我们如何以 Graph 承载查数、计算、出图、报告和归因执行过程，并将 Query、Dataset、Report、Template、Execution 和 Provenance 轻量沉淀为数据工作空间，探索 Data Agent 从个人提效工具走向组织级数据工作资产的工程路径。

演讲提纲：

一、背景：为什么对话式问数不等于生产级 Data Agent

1. 京东广告经营分析的复杂性：指标多、口径细、维度深、报告频繁、异常归因链路长。
2. 早期对话式 Agent 的价值与边界：能回答问题，但难以复现、复用、协作和审计。
3. 从个人效率到组织效率：一次成功分析不能只留在对话里。
4. AI-Ready 之后的新问题：AI 做完后，组织到底留下什么？

二、核心判断：Graph-first, Workspace-light

1. Graph 是动词，Workspace 是名词：一次分析执行过程与执行结果的分工。
2. 为什么不直接重做完整 Workspace：平台重投入风险与真实买单信号验证。
3. 先用 Graph 打穿广告分析闭环：问数、计算、出图、报告、订阅、归因。
4. 再用轻量事实层接住执行结果：Execution、Artifact、Version、Provenance、Template。

三、系统设计：从 Conversation 中心迁移到 Artifact 中心

1. 定义、执行、结果分离：Template / Workflow、Execution / Task、Artifact 的边界。
2. Artifact 类型：Query、Dataset、Chart、Report、Code、Template 如何稳定命名与版本化。
3. Provenance 证据链：报告如何追溯到查询、数据、代码、指标口径和模板版本。
4. Capability 与 Skill 解耦：让业务能力服务多种 Agent Runtime，而不是绑定单一页面或单一 Agent。

四、业务落地：京东广告数据分析 Agent 如何跑通闭环

1. 智能问数：自然语言到广告指标、维度、时间、过滤条件和查询执行。
2. 自动报告：从多问题拆解到图表、摘要、结论和报告 Artifact。
3. 模板订阅：高端用户沉淀方法，普通用户一键消费稳定报告。
4. 异常归因：围绕指标波动生成下钻 Graph，并保留执行过程与证据链。
5. 错误与重试：失败不只是报错，而是能定位到节点、参数、数据源和下一步动作。

五、方法论总结：从 Data Agent 到组织级数据工作空间

1. 先纵向打穿高频场景，再抽象平台能力。
2. 先保证可追溯、可复现、可复用，再追求更复杂的 Workspace 产品形态。
3. 高端用户生产方法，普通用户消费方法，形成生产者—消费者闭环。
4. 判断是否值得继续投入 Workspace 的关键买单信号：保存、复用、追溯、分享、模板消费。
5. 对企业数据平台的启示：Agent-ready 不只是让 AI 能查数，更是让 AI 的工作成果进入组织生产体系。

听众收益：

1. 获得一套分析型 Data Agent 从对话式问数走向生产化落地的方法：如何将自然语言问数、指标解读、报告生成、订阅推送和异常归因串成可执行、可复用的数据分析工作流。

2. 理解 Graph-first、Workspace-light 的工程路径：先用 Graph 打穿高频业务执行闭环，再将 Execution、Artifact、Version、Provenance、Template 轻量沉淀为组织级数据资产。

3. 借鉴京东广告数据分析 Agent 的真实设计取舍：包括业务语义沉淀、Capability 与 Skill 解耦、结果可追溯、模板复用，以及从个人提效走向组织复用的产品演进方式。

落地挑战与方案重点：

1. 挑战一：广告经营分析不是一次性问答，而是多步骤、多口径、多产物的持续工作流。

  方案重点：将查数、计算、出图、报告、订阅、归因拆解为可编排的 Graph 执行过程，并通过 Execution / Artifact / Provenance 记录关键事实，让每份报告和结论都能追溯到具体查询、数据、口径和执行版本。

2. 挑战二：成功的分析方法难以从个人经验沉淀为组织能力。

  方案重点：采用 Graph-first、Workspace-light 的方式，先让高端用户在真实广告分析场景中探索和调试，再将稳定流程参数化为 Template，供普通用户一键消费，形成“生产者生产方法，消费者复用方法”的组织闭环。

演讲介绍：

我们曾通过后训练将自然语言问数业务准确率做到接近100%，但知识准备和训练周期很长，扩展到新领域困难，口径变化后也难以维护。为解决这些问题，我们开始用本体组织企业数据，让对象、关系、指标和业务规则成为Agent可理解、可查询的语义结构。本次分享将复盘我们从NL2SQL、MCP、Skill到内置Agent的演进与取舍，并结合销售决策实践，介绍本体如何支撑Agent从查数、分析进一步走向业务决策。

演讲提纲:

1.智能问数做得很准之后，我们遇到了什么问题：复盘NL2SQL与后训练方案在扩展和维护上的局限。

2. 企业数据为什么需要按照Agent的理解方式重新组织：分析业务语义与底层数据结构之间的距离。
3. 我们如何设计面向Agent的本体：介绍对象、属性、关系、指标、业务规则和语义查询机制。
4. 从MCP、Skill到内置Agent的三次迭代：复盘灵活性、稳定性和接入成本之间的取舍。
5. 从查数走向决策：结合销售决策实践，介绍业务事实层、销售认知层和场景执行层。
6. 本体建设的边界与下一步：分享知识治理、持续优化中尚未完全解决的问题。

听众收益：

1.理解NL2SQL在单领域取得较高准确率后，仍然会遇到的扩展、维护和知识更新问题。

2.了解如何通过对象、关系、指标和业务规则组织本体，降低Agent理解和使用企业数据的难度。
3. 获得一次基于实际业务场景的本体建模与应用经验，了解本体如何支撑数据应用从查数和分析进一步走向业务决策。

落地挑战和方案重点：

1. 本体结构缺少可以直接照搬的标准。我们参考不同方案并结合数据分析需求，逐步形成包含对象、关系、指标和业务规则的本体结构；它仍在持续演进，需要在表达能力、开发成本和长期维护之间做取舍。
2. Agent的能力边界需要在实践中不断调整。通用MCP足够灵活，但业务知识不足时结果不稳定；领域Skill能够提高效果，但知识容易散落；内置Agent可以统一查询和分析过程，同时也提高了知识运营与评测要求。

演讲介绍

金融测试从经验驱动转向AI辅助，但大模型直接生成仍面临方法难复用、结果难追溯、质量难评估。本次分享介绍基于测试本体与Test IR的平台实践：结合业务本体、沉淀测试方法论，以Test IR打通需求、大纲和案例；Agent负责语义理解与方法选择，工具负责数据计算、案例装配和校验。形成“需求解析—IR—方法应用—案例生成”的可追溯链路。

演讲提纲

一、业务背景：为什么需要重新设计 AI 测试平台
金融测试当前面临的问题
需求、测试大纲和测试案例之间缺少统一表达。
测试设计依赖个人经验，优秀方法难以沉淀和规模化复用。
Dify、提示词、Skill和脚本形成了大量成果，但资产分散、边界不清。
大模型可以快速生成案例，却容易出现遗漏、幻觉和结果不稳定。

二、方案选型：为什么选择“本体＋Test IR＋Agent＋工具”
直接使用大模型：建设快，但生成过程黑盒化，难以稳定复现。
固定工作流与提示词：适合单一场景，但容易与具体业务和流程强耦合。
RAG知识检索：能够补充知识，却难以表达方法适用条件、执行步骤和输出约束。
本体与Test IR：将测试语义、方法、输入输出契约和关系结构化，适合长期治理。

三、总体架构：平台如何运转

四、落地挑战与解决思路
测试场景本体的分层和构建思路，以及本体的管理和演进；
测试IR的设计和应用。
测试方法论的构建和应用。

五、展望与总结

听众收益

1、理解业务本体、测试本体和Test IR的职责边界，以及三者如何共同支撑AI测试。
2、获得一条可渐进实施的建设路线：从现有提示词、Skill和脚本出发，逐步演进为可查询、可治理的测试平台体系。

落地挑战和方案重点

1. 测试本体的有效性仍需持续验证。 方法建模过粗，无法指导案例生成；建模过细，又容易与具体业务耦合。需要通过真实大纲、人工案例和执行结果持续校正方法边界。
2. 生成质量缺少统一行业基准。 文本相似度不能代表测试质量，后续需要重点建立事实保留率、方法选择准确率、测试责任覆盖率、无依据生成率和人工修订成本等评价指标。

演讲内容：

"企业 Data Agent 已经能够完成提问、取数、分析和建议，但从洞察到业务结果，仍然存在任务交接、业务执行和效果验证等断点。
本次分享结合 ThinkingAI 企业级 Agent 平台 Agentic Engine 的工程实践，围绕一个贯穿业务场景，拆解“发现问题—分析原因—生成策略—受控执行—验证效果”的行动闭环。重点介绍如何通过结构化上下文与节点验收组织多 Agent 协作，如何通过工具与 Skills 连接企业数据和业务系统，以及如何借助 AI 观测平台追踪执行过程、定位问题。同时，区分 Agent 执行质量与业务效果的验证方法，讨论权限、审批、异常处理与动作补偿等工程边界，为企业构建可追踪、可控制、可验证的 Data Agent 提供参考。"

演讲提纲：

内容主线
以三个问题贯穿分享：决策依据是什么、业务动作如何受控、最终效果如何验证。
有据可依：将企业数据、业务知识与 Agent 执行链路关联起来，为判断和行动提供可追溯的证据。行动可控：通过明确分工、结构化交接、节点验收与业务审批，让分析结论进入真实业务流程。效果可验：分别衡量执行质量、任务完成情况与业务收益，通过实验和结果反馈持续改进。
演讲提纲（30 分钟）
1. 从建议到行动，还缺什么（3 分钟）从一个业务场景切入，说明分析结论在任务交接、执行和验证环节中的断点。
2. 行动闭环的总体架构（5 分钟）拆解感知、分析、决策、执行与验证的职责，建立 Agent 执行证据与业务效果数据之间的关联。
3. 一个业务场景中的闭环实践（10 分钟）展示从问题分析、策略生成到审批执行与效果复核的过程，解释多 Agent 如何分工、传递上下文并验收阶段结果。
4. 让闭环可靠运行的工程机制（7 分钟）重点讨论上下文失真、执行状态不确定和异常恢复；介绍 Trace 追踪、权限约束、审批、重复执行防护，以及停止、恢复或补偿的适用边界。
5. 如何验证价值与逐步落地（5 分钟）区分执行成功、任务完成与业务收益；介绍对照实验与指标设计，以及从辅助分析到受控行动的演进路径。

听众收益:

获得一套从数据洞察走向业务行动的闭环架构与落地思路。理解多 Agent 协作中的上下文交接、节点验收和执行控制机制。掌握通过执行证据定位问题、通过业务指标与实验验证价值的方法。

落地挑战和方案重点：

落地挑战：企业 Data Agent 从分析走向行动，需要跨越数据系统与业务系统之间的边界。多 Agent 协作可能出现上下文失真、交接信息不足与错误传播；业务动作可能面临权限不足、状态不明确、重复执行和部分失败；工具调用成功也不能直接说明任务完成或业务收益提升。

方案重点：依托 Agentic Engine 组织分析、决策、执行与验证流程，通过结构化上下文和节点验收提高协作可靠性，通过工具与 Skills 连接企业能力，并结合权限约束、业务审批和执行状态管理控制动作风险。AI 观测平台提供会话、Trace、模型、工具与 Skill 的执行证据，帮助定位问题；业务任务、触达或曝光记录及效果指标则用于验证动作与结果。根据业务条件引入对照实验，并按动作类型设计停止、恢复或补偿机制，逐步形成可追踪、可控制、可验证的行动闭环。

演讲介绍:

企业数据从支撑人查数走向 Agent 决策执行，挑战不只是 Text2SQL，而是口径、上下文、权限与行动风险。易车从 ChatBI、DataAgent 演进到 DataWork，建设覆盖可信数据、语义、本体和知识、MCP 与 Harness 的三层底座，并以查询进化和主动跟进打通分析、行动与结果验证，形成从可信问数、辅助分析到受控执行的企业数据智能演进路径。

演讲提纲：

1、从 ChatBI 到 DataWork：易车的实践历程
2、从“会查数”到决策执行面临的挑战
3、面向 Agent-Ready 的企业数据建设
4、建设 Agent 原生底座：构建企业级 Harness 体系
5、从工具提效到自主洞察：数据智能系统的能力进化
6、未来规划

听众收益：

1.了解易车从 ChatBI 到 DataAgent 的演进过程，以及在其中遇到的挑战。

2.了解如何做好数据、知识和工具建设，让 Agent 找得到、看得懂、用得好企业数据。
3. DataAgent 不止于问数，Agent 如何从回答问题走向主动发现、自主洞察和决策执行。

落地挑战和方案重点：

1、如何保证 Agent-Ready 的企业知识长期有效
2、如何实现系统的自动进化

演讲介绍：

从 dbt MetricFlow 引擎到 AI 原生轻量级语义层的演进实践：传统语义层需要人工配置定义指标，维护成本高、不够灵活。我们构建了 AI 原生的轻量级语义层，让 LLM 自动维护指标定义，LLM根据指标定义和用户查询意图来生成SQL。构建知识库来支撑核心指标、核心宽表、业务知识等知识的管理和检索，通过检索让 LLM 每次只加载最相关知识。技术层面，通过定制化切片（指标单独切片、表分层切片、SQL 按语句切片、通用逻辑兜底）+ 混合检索（全文检索 + 向量检索 + WRRF 融合排序 + 名称匹配加权）+ 分层匹配（表级 → 字段级）+ 业务优先级（核心宽表 > 认证表）来保证精确的检索查询。进一步构建 AI原生的轻量级知识图谱，解决多跳关系检索（如"用户 → 订单 → 商品"三跳关系），采用 AI 主导构建和维护，避免重量级图计算。目前知识库+知识图谱的整体团队渗透率超过 65%，常见的简单取数需求能满足100%，团队token 消耗大幅降低。

演讲提纲：

业务背景
• 数据团队的核心痛点：
   ◦ 取数依赖分析师，业务方等待时间长
   ◦ SQL 编写成本高，技术门槛限制自助取数
   ◦ 指标口径不一致，分析结果存在差异
方案选型：三阶段架构演进
第一阶段：基于 dbt MetricFlow 的语义层
• 技术架构：dbt Semantic Layer + MetricFlow 引擎 + BM25 指标检索
• 核心特点：SQL 完全由 MetricFlow 引擎生成，准确性有保障
• 优势：规范化、类型安全、SQL 准确
• 局限性：
   ◦ MetricFlow 比较复杂，对特殊指标的支持成本高
   ◦ 不够灵活，无法充分发挥 LLM 的能力
   ◦ 维护 MetricFlow 配置成本高
第二阶段：知识库建设
• 设计理念：让 AI 自动生成和使用数据资产
• 核心转变：
   ◦ 指标定义由 LLM 自动生成，存储为 Markdown 文件
   ◦ 知识库作为 AI 原生语义层的核心支撑
   ◦ 形成"LLM 生成 → 知识库入库 → 增强检索 → LLM 使用"的完整闭环
• 知识库规模：
   ◦ 1400+ 指标口径
   ◦ 300+ 宽表/认证表
   ◦ 25000+ SQL 模板
   ◦ 业务知识文档
第三阶段：LLM 知识图谱建设
• 为什么需要知识图谱：
   ◦ 知识库主要解决单跳检索（如"查询 DAU 指标"）
   ◦ 多跳关系检索效果有限（如"用户 → 订单 → 商品"三跳关系）
   ◦ 需要轻量级知识图谱作为补充
• 设计理念：AI 原生、轻量化
   ◦ AI 主导构建：LLM 从数据资产中自动抽取实体和关系
   ◦ AI 主导维护：自动更新图谱，人工只负责关系确认
   ◦ AI 友好查询：设计 AI 友好的查询接口，不做重量级图计算
   ◦ 与知识库融合：图谱检索结果与知识库检索结果融合
• 技术方案：
   ◦ 实体识别：从指标、表、字段中抽取实体
   ◦ 关系抽取：识别指标依赖、表关联、字段引用等关系
   ◦ 图谱存储：轻量级存储方案，支持快速查询
   ◦ 融合检索：图谱多跳查询 + 知识库检索的统一接口
系统整体架构
下图展示了知识库在整个数据智能生态中的位置：
架构说明：
• 工作台层：Codex、Workbuddy、Zwork 等第三方 Agent，通过统一的 data-cli 接入
• 网关层：大数据CLI 作为 MCP 能力网关，提供安全管控和任务分发
• 能力层：数据分析-agent（DataClaw 核心）、AB实验-agent、画像-agent、埋点-agent 等专项能力
• 服务层：
   ◦ SQL查询接口：对接 StarRocks/Spark 执行引擎
   ◦ 知识库检索服务：本次分享的核心模块
   ◦ 数据skill市场：技能沉淀与共享
• 知识层（本次分享重点）：
   ◦ 问题全文检索-知识库：BM25 全文检索
   ◦ 知识图谱-知识库：向量检索 + 关系检索
   ◦ 数据来源：业务逻辑（数仓元数据）+ 产品功能（埋点元数据）
• 数据层：Paimon/Hive 存储集群，StarRocks/Spark 查询引擎
本次分享聚焦轻量级语义层的构建和知识库检索服务的建设，包括定制化切片、混合检索、分层匹配等核心技术。
落地挑战
挑战一：如何设计针对不同知识类型的切分和检索策略
• 不同类型的知识结构差异大（指标、表元数据、SQL模板、业务知识）
• 表元数据需要两级检索（表级 → 字段级），单一检索策略效果差
• 如何平衡针对性优化和通用性支持
• 如何让业务优先级在技术上落地（核心宽表 > 认证表 > 普通表）
挑战二：如何提升混合检索的召回率和精准度
• 纯向量检索容易被无关结果干扰，分数区分度低
• 纯全文检索（BM25）对语义理解能力弱
• 如何融合两路检索结果，既保证召回率又提升精准度
• 如何针对不同知识类型设计差异化的评分权重
挑战三：如何构建 AI 原生的轻量级知识图谱
• 如何让 LLM 自动抽取实体和关系，保证准确性
• 如何设计和实现 AI 友好的图谱查询接口，避免重量级图计算
• 如何将图谱检索与知识库检索融合，提供统一体验
解决思路
针对挑战一（知识类型差异化）：定制化切片 + 分层匹配 + 业务优先级
• 定制化切片逻辑：为主要知识类型定制切片策略，通用逻辑兜底
   ◦ 指标：每个指标切分成单独的切片（完整口径、计算逻辑、数据来源）
   ◦ 表元数据：表级切片（表名、描述、业务域）+ 字段级切片（字段名、类型、业务含义）
   ◦ SQL 模板：按 SQL 语句和 CTE 语句切分
   ◦ 业务知识：通用 Markdown 切片逻辑兜底
• 分层匹配策略：表元数据先表级检索再字段级检索，避免字段噪音
• 业务优先级落地：
   ◦ 核心宽表和认证表作为权威数据资产，直接进入知识库
   ◦ 通过赋予不同权重实现优先级控制（核心宽表 > 认证表 > 普通表）
• 价值：既保证主要类型的针对性优化，又能直接支持未知类型
针对挑战二（混合检索优化）：全文+向量 + WRRF融合 + 分数优化
• 检索策略：全文检索（BM25）+ 向量检索（Embedding）并行
• WRRF 融合排序：加权 RRF 融合两路结果，分数归一化
• 分数优化：
   ◦ 名称匹配加权：精确匹配、包含匹配、别名支持
   ◦ 分类管理：按知识类型独立检索，避免跨类别干扰
• 价值：既利用全文检索的精确匹配能力，又发挥向量检索的语义理解能力
针对挑战三（轻量级知识图谱）：AI 主导 + 轻量化设计
• 实体和关系抽取：
   ◦ LLM 分析指标定义、表结构，自动识别实体（指标、表、字段、业务概念）
   ◦ LLM 识别关系（指标依赖、表关联、字段引用、业务归属）
   ◦ 人工审核确认关系，形成反馈闭环
• 轻量化存储和查询：
   ◦ 采用轻量级图存储方案（非 Neo4j 等重量级图数据库）
   ◦ 设计 AI 友好的自然语言查询接口
   ◦ 支持常见的 1-3 跳关系查询
• 融合检索：
   ◦ 用户查询先判断是否需要多跳关系
   ◦ 需要时调用图谱查询，结果与知识库检索融合
   ◦ 统一返回，LLM 综合使用
• 价值：解决知识库的单跳检索局限，同时保持轻量化
落地效果
• 知识库团队渗透率超过 40%
• 知识库规模：1400+ 指标、300+ 宽表/认证表、25000+ SQL 模板
• 上下文优化：每次查询只加载最相关的知识，token 消耗大幅降低
• SQL 生成准确率：充分发挥 LLM 能力，同时通过知识库保证准确性
• 系统灵活性：从 MetricFlow 引擎约束中解放，支持各类特殊指标
• 生态开放：通过 data-cli MCP 网关服务 Codex、Workbuddy、Zwork 等多个第三方 Agent
• 轻量级知识图谱：支持多跳关系检索，AI 主导构建和维护
未来规划
• 知识图谱深化：
   ◦ 扩展更多业务关系类型
   ◦ 优化 AI 抽取准确率
   ◦ 探索图谱推理能力
• 效果评估体系：
   ◦ 标准化评估指标建设
   ◦ A/B 测试框架
   ◦ 用户反馈闭环
总结
• 三阶段演进：MetricFlow 引擎 → 知识库建设 → 轻量级知识图谱
• 核心转变：从"引擎生成 SQL"到"LLM 生成 SQL + 知识库辅助 + 知识图谱补充"
• 关键创新：定制化切片 + 混合检索 + 分层匹配 + 业务优先级 + AI 原生知识图谱
• 生态价值：通过 data-cli 服务多个第三方 Agent，构建开放的数据智能生态
• 未来方向：知识图谱深化与效果评估体系建设

听众收益:

理解数据语义层从传统到 AI 原生的演进路径
从第一阶段 dbt MetricFlow 引擎（SQL 准确但不灵活）、第二阶段知识库建设（1400+ 指标入库，混合检索），到第三阶段轻量级知识图谱（解决多跳关系检索），了解为什么传统引擎方案在 AI 时代需要演进，以及如何通过知识库和知识图谱构建 AI 原生语义层

掌握大规模知识库和轻量级知识图谱的核心技术
学习如何管理 1400+ 指标、300+ 宽表、25000+ SQL 模板的知识库，如何通过定制化切片 + 混合检索 + 分层匹配 + 业务优先级提升检索效果，以及如何构建 AI 主导的轻量级知识图谱，实现实体自动抽取、关系识别、多跳查询与知识库融合

了解 AI 原生的设计理念和实践经验
理解如何让 AI 主导数据资产的生成、维护和使用全流程，如何在保持轻量化的同时支撑复杂的数据分析场景，以及如何通过知识库和知识图谱的结合，让 LLM 既能精准检索又能理解关联关系

落地挑战和方案重点:

挑战一：知识库检索召回率和准确率的量化评估与持续优化
虽然我们通过定制化切片、混合检索、分层匹配等策略提升了检索效果，但目前缺少标准化的评估体系。具体问题：（1）如何构建高质量的测试集？不同用户的查询意图差异大，如何标注标准答案？（2）如何量化"更好"的检索？是召回率、准确率、NDCG，还是用户满意度？多维指标如何加权？（3）如何针对不同业务领域自适应调整检索权重？目前的权重是人工调优的，如何实现自动化？我们计划引入 A/B 测试框架和用户反馈闭环，但标准化、规模化的评估体系仍在探索中。

挑战二：轻量级知识图谱的 AI 原生构建与融合检索
知识库主要解决单跳检索（如"查询 DAU 指标"），但对于多跳关系检索（如"用户 → 订单 → 商品的三跳关系"）效果有限。我们构建轻量级知识图谱作为补充，面临三大难题：（1）如何让 LLM 自动抽取实体和关系并保证准确性？需要设计有效的 prompt 工程和人工审核机制。（2）如何保持轻量化？避免引入 Neo4j 等重量级图数据库，采用轻量级存储方案，不做复杂的图计算，只支持常见的 1-3 跳关系查询。（3）如何融合检索？用户查询时如何判断是否需要多跳关系，如何将图谱查询结果与知识库检索结果融合并统一返回给 LLM？这是我们当前正在攻坚的方向。

演讲介绍：

京东零售场景下，我们基于 OxyGent 框架沉淀了一套 B 端 Agent 生产化技术栈。多层多类型的动态 Memory 设计让 Agent 越用越懂用户，把用户画像、反馈与当下焦点分层建模并持续反哺；多层级智能体架构让 Skill Agent 与 DAG Agent 等范式在同一骨架并存，支撑不同业务场景各取所需；DAG 编排通过反馈闭环与步级重试，让 Agent 既能自纠查询、也能借由 Human-in-the-Loop 快速交互从第 N 步整体重跑，逐步收敛误差；长任务生产化在 Web 端做到类本地插件的无超时体验等。多套能力建设，让B端应用从demo走向生产。

演讲提纲:

一、业务背景（3分钟）

· 京东零售B端Agent场景多元：面向商家、数据分析、数据研发等多类场景

· B端Agent相比C端chatbot更强调长期化、生产化与可复用

· 核心痛点引出：Agent的记忆缺失、污染、碎片——本质是上下文管理问题

二、根因：为什么Agent越用越不懂用户？（5分钟）

· 根因：上下文没有分层、没有持续反哺

· 用户画像、反馈、当下焦点混在一起的危害：幻觉、答非所问、重复询问

· 从“多Agent架构”视角切换到“上下文工程”视角——不是Agent不够多，是上下文没管好

三、核心解法：多层多类型动态Memory设计（15分钟）

· 为什么需要分层：不同类型的上下文有不同的生命周期和消费方式

· 长期记忆：用户画像与跨会话偏好、焦点，怎么提取、怎么更新、怎么排序

· 中期记忆：多轮会话记忆，怎么衔接意图、切换意图、压缩和回溯

· 短期记忆：任务执行记忆，中长期记忆联动、观测信息处理、复杂信息的简化

· 工程要点：存储方案、检索策略、注入时机、窗口管理

四、复杂场景下的上下文“存活”与“恢复”（6分钟）

· 聚焦问题：B端任务执行的稳定性

· 编排执行：DAG执行时的上下文隔离与合并，持久化时的上下文复用

· Human-in-the-Loop与局部重跑时的上下文管理

五、治理效果与持续演进（3分钟）

· 简要对比：有分层Memory vs 无分层Memory的效果差异

· 上下文污染时的表现和恢复机制

· Memory飞轮：怎么让上下文越用越准而不是越用越乱

六、总结（2分钟）

· 核心判断：B端Agent的壁垒不在Agent数量和编排复杂度，在上下文管理质量

· 可复用的三板斧：分层Memory + 持续反哺 + 污染治理

听众收益：

通过京东零售的真实场景案例（商家经营、数据分析等），理解分层Memory在复杂B端任务中的具体表现，尤其是DAG编排执行、Human-in-the-Loop介入、局部重跑等生产级场景下的上下文“存活与恢复”经验，是跟贴近业务实践的优化。

落地挑战和方案重点:

落地挑战：
挑战一：多层memory体系的建设以及与已有agent框架的融合。

挑战二：定义Memory效果的度量标准，让好坏可量化。

挑战三：触发时机的判断和内容筛选的标准。

方案重点：
重点一：分层分类的memory系统设计，多memory联动的设计。

重点二：紧密绑定京东B端业务真实痛点的优化策略，不仅仅是通用方案的实现。

演讲介绍

企业在数字化建设与经营实践中积累了丰富的数据资产与决策知识，如何将这些积累转化为Agent理解业务、辅助经营决策的能力？本分享围绕DecideX从BI走向决策智能的设计与实践，介绍如何复用现有数据资产、组织决策知识，构建面向经营场景的上下文。并在此基础上，结合评估闭环，让分析结论可追溯、决策建议可评估、行动效果可复核。最后结合客户案例，围绕客户痛点、实施路径与实践思考，分享决策智能在企业中的落地探索。

演讲提纲

1、从BI到决策智能：企业数据资产的复用与价值延伸。

2、决策上下文工程：数据资产与决策知识的组织和应用。

3、可信证据链：支撑可解释、可追溯的经营分析。

4、决策评估闭环：从建议质量到经营效果的持续复核。

5、客户案例分享：客户痛点、实施路径与实践思考。

听众收益

1、了解复用现有数据资产、构建决策上下文的实施路径。

2、掌握决策知识组织与可信证据链的设计思路。

3、理解决策质量评估与经营效果复核的方法。

落地挑战和方案重点

1、数据资产与决策知识分散：复用现有数据资产，结合经营场景整合决策知识，减少重复建设。

2、上下文与业务需求不匹配：结合问题和用户权限按需获取相关内容，通过持续更新兼顾准确性与效率。

3、分析结论缺少可追溯依据：以证据链连接数据、分析和结论，支持解释与复核。

4、决策建议与效果验证脱节：结合决策质量评估和经营效果复核，持续跟踪业务反馈，形成改进闭环。

演讲介绍：

生产级 Agent 的真正瓶颈不在模型能力，而在上下文质量——Agent 拿到的是散落在 Prompt、工具、日志中的碎片化信息，还是经过语义治理、可理解、可追溯的结构化上下文，决定了它能否在生产环境稳定交付。以 Spark/Flink 故障诊断为例，介绍理想汽车如何将散落在 Prompt 与工具中的知识，拆分为本体、OSI、Playbook 和通用执行层，为 Agent 构建高质量的语义上下文。Agent 据此跨日志、指标、数仓取证，形成有证据的根因判断，并将诊断缺口沉淀为可版本化、可校验、可回归的语义资产。还将讨论轻量建模、查询约束及模型探索与工程确定性的取舍。

演讲提纲:

生产级 Agent 的上下文挑战：为什么散落知识是最大瓶颈

语义层即上下文工程：本体、OSI、Playbook 的职责边界与协作

理想汽车落地实践：从故障诊断到有证据的根因判断

关键取舍与演进：从单点场景到生产级 Agent 平台

听众收益：

掌握一套将专家经验转化为可治理语义资产、为 Agent 提供高质量上下文的方法。
理解本体、查询语义、Playbook 和工具层在上下文构建中的职责边界。
学会构建带证据、置信度和答案边界的 Agent 输出，理解语义约束如何提升上下文质量。
获得一条从单点场景逐步演进到生产级 Agent 平台的实践路径。

落地挑战和方案重点:

痛点一：本体、指标关系和 Playbook 仍需要较多人工梳理，跨业务复制效率有限，后续重点是推进语义资产（上下文）标准化和自动生成
痛点二：面向更大规模应用，还需要解决权限控制、执行追踪、证据状态、结果验证和多运行环境适配等问题，建设可治理、可观测、可扩展的 Agent 运行控制面

演讲内容:

问题：
- 分析决策agent构建时间长，内容生成效果不稳定
- agent运行资源占用大，成本高，用户等待的推理时间长
- 问题优化和效果评估不足，无法找到持续改进的驱动点
解决过程：
- 进agent分析决策进行分类，区分不同决策的要素列表
- 基于决策要素构建知识，覆盖行业、公司、领域、场景、技术等多方面内容，为agent决策的规划有效的工具链路调用，并精准生成提示上下文
- 建立agent决策的2级评分体系，数字化管理形成提升驱动点

演讲提纲：

1.分析agent在公司演进路径和落地场景

2. 当前使用卡点，以及问题的汇总抽象
3. agent决策链路拆分，并通过数字化进行效果评估
4. 迭代知识库和标准数据，推进持续优化
5. 新的挑战和未来规划

听众收益：

1. 分析agent的评估指标体系
2. 建立标准数据和知识库，支持agent高质量推理

落地挑战和方案重点:

1. 如何对agent执行链路拆解到原子步骤，使得单变量可观测可提升
2，如何度量agent客观数字效果，和业务使用agent体验一致

演讲介绍

一条 SQL 可以解析、执行并返回结果，却仍可能给出错误的业务结论。数据平台引入 Agent 后，真正困难的不是能不能生成 SQL，而是如何划清业务事实、任务方法、运行时判断和外部操作的责任边界。

本分享以 SQL 生成中的一个实际错误为主线，并以数据质检作为对照，讨论什么任务值得使用 Agent、Agent 可以自主到哪一步。这里的“边界”不是在 Skill 与 Agent 之间二选一，而是哪些稳定方法应该沉淀为 Skill，哪些决策需要 Agent 结合运行反馈完成。

分享将通过“四层一面”职责模型、自主权决策表和错误归因闭环，说明如何让问题可定位、变更有落点，并将已确认的问题逐步沉淀为平台能力。让 Agent 少猜，让平台多知道一点。

演讲提纲

一、问题：SQL 可以执行，为什么业务答案仍然错误

复盘一个真实案例：SQL 可以解析、执行并返回结果，但与经确认的业务口径和参考结果不一致；

对比数据质检与 SQL 生成，说明确定性主链与 Agent 决策节点的差异；

提出核心问题：哪些事实与规则应由平台前置，哪些决策需要结合运行时反馈完成？

二、判断：什么问题才值得交给 Agent

Agent 成为候选需要同时满足：目标与成功标准明确，运行中存在无法经济编码的语义判断，能够获得及时可信的反馈，动作空间可以约束，结果可以验证；

再用风险、可验证性和可逆性确定自主级别；

现场演示如何用同一张决策表评审两类场景：数据质检落到确定性 Workflow；SQL 生成只在澄清、探查和生成等局部环节保留受约束 Agent，最终执行仍由平台控制和用户确认。

三、分工：“四层一面”如何界定逻辑职责

知识与上下文层：版本化管理业务口径和表字段语义，并在任务过程中按需检索、装配和更新 Context；

Skill 方法层：沉淀 SQL 生成、探查和校验等可版本化、可复用的方法；

Workflow 与 Agent 决策层：Workflow 负责可编码的状态和分支，Agent 只处理必须结合用户输入和 Tool 反馈完成的局部判断；

Tool 执行层：提供元数据查询、受限数据探查、SQL 校验等结构化能力接口；

横向治理面：模型外部的具体系统强制身份权限、参数策略、预算、审批与终止；可观测与评测提供跨层证据和回归验证依据。

四、治理与收益：错误可归因，变更有落点

沿用同一个 SQL 案例，展示“错误表现 → 对照证据 → 根因假设 → 单变量验证 → 修正位置 → 回归用例”的完整过程；

区分 Skill 中的软约束与模型外部、完整中介、失败关闭的硬控制；

展示分层后的结构性收益：决策归属清晰、变更有最小落点、已确认错误可以进入回归验证；

根据证据与责任，将已确认问题分别或同时修订到语义资产、Context 装配、Skill、Workflow、Tool 和治理执行点，并沉淀为回归用例。

五、演进：把运行时未知逐步沉淀为平台能力

基础阶段：明确任务与风险边界，准备经确认的业务口径、参考问题和评测基线；

受控能力阶段：建设只读 Tool、身份权限、调用审计、资源预算和失败处理；

局部 Agent 阶段：先跑通确定性 Workflow，只在必要判断点引入 Agent，并通过 Shadow、Canary、熔断、回滚和人工接管逐步放量；

持续沉淀阶段：将已确认问题同步沉淀为语义资产、Skill、Workflow 规则、Tool 校验和评测用例；

总结：让 Agent 少猜，让平台多知道一点。

听众收益

评审一个需求：用自主权决策表判断它应该采用确定性 Workflow、受约束 Agent、拒绝还是人工确认。

定位一个问题：用“四层一面”职责图判断错误应该修到语义资产、Context、Skill、Workflow、Tool 还是治理执行点。

获得一份可对照自查的改造清单模板：识别团队当前缺少的事实、评测、Tool、权限、可观测与放量机制。

落地挑战和方案重点

挑战一：可解析、可执行不等于业务正确

方案重点：在一致条件下对照错误 SQL 与经确认的参考口径，沿“四层一面”逐项隔离根因，避免将缺少证据的推断直接归咎于模型。

挑战二：自然语言约束不能充当安全边界

方案重点：把治理要求落实到模型外部的具体系统，通过身份权限、参数策略、Tool 范围、资源预算、审批、终止、审计与评测控制风险。

演讲介绍：

数据研发不缺会写 SQL 的助手，缺的是从需求澄清到 Notebook 分析都能交得出来的编排。口径靠口传对齐，开发与验收上下文割裂，测试靠人工兜底，分析结论难复用——时间耗在链路断裂处。得物用 Agent Harness 贯穿需求澄清、AI Coding、AI Testing 与 Notebook 分析，并留下 IDE Review、STOP 等人机确认卡点。本场给出一套从需求澄清到 Notebook 分析的全链路落地实践。

演讲提纲：

一、开场：全链路比单点更难，难在上下文，不在模型

- 数据研发四环节高成本画像：需求澄清 → AI Coding → AI Testing → Notebook 分析

- 根因判断：时间成本层层累积，本质是「环节间上下文割裂」；找表、编码、查数、诊断、交接各自割裂，而非模型能力不足

- 本场承诺：讲清全链路为何更难、也更值，细节放到后面的选型与落地

二、选型对比：从 Copilot 到 Harness，不追求全自动，追求可编排、可回滚

- 路线对比：单点 Copilot、固定 Workflow、多 Agent 自由协作 vs Harness 受控编排

- 为何选 Harness：分层底座——Agent 理解调度 · Skill 固化专家流程（步骤/校验/失败分支/人工闸门）· MCP/CLI 读写执行 · Web/Notebook 做入口；再叠加会话记忆与工具收敛

- 人机协作界面选型：CLI × Web IDE——Agent 组装产物后推 IDE Review，人确认才算交付；把「可信边界」做成产品能力

- 工具边界选型：元数据探索用 MCP，执行面收敛到 CLI（建改任务 / 临时查询），避免工具面失控膨胀

- 取舍结论：不追求全自动替人，而追求全链路可编排、可度量、可回滚

三、落地细节：四类 Agent 如何在同一套 Harness 上贯通

- 需求澄清：意图澄清、智能找数（STOP 选表）、质量门禁；语义资产人审后进入研发

- AI Coding Agent：研发闭环「确认模型 → 建表 → 建任务 → 补依赖校验 → 只存开发态草稿」；CLI 组装多 fileType 推 Web IDE，人在 IDE 审 Diff/草稿后再确认提交才计入 AI Commit（各引擎能力不完全对称，如 MC SQL 侧重改任务）

- AI Testing 能力：AI CR + AI 验数；冒烟 / 基线 / DQC + SQL 预编译与质量门禁；离线/Spark 诊断走「采证→假设→人验证」证据链（工具链 Agent 化，而非单一万能测试 Agent）

- Notebook 分析 Agent：AI 写作辅助（续写 / 扩写 / 总结 / 解释 / 出图）+ 结论沉淀与复用

- 关键工程难点：多端上下文一致性；上下文预算（filter 优先、详情过大落盘）；项目空间必须人选定、禁止从库名推断；生成可信度与确认卡点设计

听众收益：

- 对照：把自家澄清 / Coding / 测试 / 分析对上号，找到可增量落地的切口

- 拿走：一套 Harness 编排方式，以及效果怎么被讲清楚，而不只是感觉变快了

落地挑战和方案重点：

1. 上下文如何不断裂：Agent 在 CLI 里执行、人在 IDE 里确认，两端状态容易各记各的。方案重点是把工具和记忆收口到 Harness，用人选表、选空间、审 Diff 把状态钉住。

2. 如何让 AI 初稿过得了人审：生成容易，交出去难。方案重点是「AI 出初稿，人管口径与结果」——推到 IDE 审过再写入/发布，才算交付，不把全自动当成目标。

演讲介绍:

核心理念：以交付物（物理表、逻辑表/指标、数据看板、AB实验）为导向，由面向人转为面向AI驱动全流程，人聚焦关键决策节点，AI不承担责任。

技术架构：基于云原生架构，采用MCP+Skill模式将平台能力抽象为标准化原子操作，支持沙箱机制保障信息安全，已适配多种模型。

角色体系：设计DA（消费者）、DE（生产者）、DG（架构质量守护者）三Agent协作模式，边界由系统定义而非人为摩擦。

知识库：分层分类构建，正负信号持续回流，形成"越用越智能"的飞轮效应。

落地策略：对存量系统采取GUI+API并轨的务实演进路径，而非推倒重建。

演讲提纲：

传统数据研发现存痛点
AI‑Native设计理念
组织协作飞轮与知识库体系
三大Agent协同架构
沙箱、路由运行机制
权责划分：AI定位边界
存量系统兼容：GUI & LUI双轨模式
迭代策略：研发‑试跑‑规模化
工业落地现实挑战
规模化落地解决方案
数据看板双搭建模式：SPEC & VIBE
大模型底座选型思路
整体架构总览
落地业务价值总结

听众收益:

1. 获得"AI提效"的认知升级：从单点工具到全流程组织智能跃升
多数团队对AI的应用还停留在代码补全、SQL生成等"自底向上"的单点辅助阶段。本演讲提供了一个关键洞察：真正的效率瓶颈不在编码，而在多角色间的信息对齐与协作流转。听众会建立起"AI Native"的系统性思维——以交付物为导向、让AI串联全链路，而非仅仅加速某个环节。这个认知转变可以直接迁移到各自团队的数据工程实践中。

2. 获得一套可复用的组织协作设计模式：DA/DE/DG 三Agent体系
演讲提出了将数据团队角色抽象为"生产者-消费者-质量守护者"三Agent模式，由系统定义边界而非人为摩擦。这套模式解决了一个普遍难题：如何在引入AI后重新划分人与AI的权责。其中"AI不背锅、人聚焦关键确认节点"的原则，以及DG作为架构质量检测切面的设计，对任何正在推进AI落地的数据团队都有直接参考价值。

3. 获得从Demo到工业级落地的实战经验与避坑指南
演讲坦诚分享了AI应用在真实生产环境中遇到的具体问题——文件写入错乱、上下文失控、异常信息与实际原因不符等。这些是只有真正做过工程化落地才会踩到的坑。同时给出了务实的应对策略：存量系统采用GUI+API并轨而非推倒重建、知识库正负信号双向回流形成飞轮。听众可以直接借鉴这些经验缩短自己团队的试错周期。

落地挑战和方案重点：

1.数据变更Harness设计
2.多链路Loop机制
3.组织智能飞轮设计

演讲介绍：

当前用户增长业务存在多端数据割裂、指标口径混乱、用户ID不统一等问题，导致增长分析失真，精细化运营落地难，原有离线实时双栈架构维护成本高、数据延迟最高达2小时。本次摒弃传统分层数仓模式，采用用户本体论数仓架构，以用户OneID为核心重构数据体系，统一埋点与指标标准。落地中攻克了百亿级用户行为数据合并、多源数据冲突、实时增量更新三大痛点，通过本体建模、增量计算、口径归一化方案优化，实现指标偏差大幅减低，增长策略迭代效率大幅提升，精准赋能拉新、促活、留存全链路增长运营。

演讲提纲：

1.业务背景与行业痛点

- 用户增长业务核心诉求：全链路用户行为追踪、精细化分层、增长效果归因、策略快速迭代
- 传统数仓核心问题：数据孤岛严重、指标口径不统一、实时离线架构割裂、海量数据查询低效
- 业务负面影响：增长分析失真、用户分层不准、运营策略滞后、资源投放浪费

2. 技术方案选型与核心思路
- 方案对比：传统分层数仓VS用户本体论数仓的适配差异
- 核心选型：以用户本体为核心、OneID全域关联、实时离线一体化架构
- 技术栈组合：Flink实时计算+Spark离线复盘+本体建模分层+自动化质量管控
- 核心设计：用户实体统一、行为事件归一、增长指标标准化体系搭建

3. 落地核心挑战与攻坚过程
- 数据层：多源异构数据冲突、百亿级用户行为数据合并与清洗难题
- 计算层：实时数据积压、增量更新成本高、查询响应慢问题
- 业务层：历史指标体系臃肿、业务侧口径认知不统一，落地适配难

4. 针对性解决思路与落地方案
- 数据治理：精简冗余埋点、统一事件标准、搭建OneID全域映射体系
- 架构优化：实时增量计算替代全量刷新，解决数据延迟与资源浪费问题
- 机制建设：建立指标归口管理、自动化数据校验、问题快速响应机制

5. 落地成效与数据复盘
- 技术成效：数据延迟、指标准确率、计算资源消耗优化数据
- 业务成效：用户分层精准度、增长策略迭代效率、投放ROI提升效果

6. 现存短板与未来迭代规划
- 当前方案未解决的痛点瓶颈
- 短期优化：智能化数据质检、标签体系轻量化迭代
- 长期规划：AI赋能用户增长预测、自动化策略归因、数仓成本精细化管控

听众收益：

1.架构认知升级：打破传统分层数仓固化思维，掌握用户本体论数仓的核心设计理念，理解用户增长场景下“以实体为核心”相较于“以流程为核心”的架构优势，明确增长数仓专属的建模逻辑与适配场景。

2. 实战问题可复用经验：获取用户增长数仓落地的高频痛点解决方案，包括多源数据归一、指标口径统一、实时离线架构融合、海量行为数据高效处理等实战方法，可直接迁移至企业用户运营、精细化增长相关数仓建设场景。

3. 业务技术融合思维：学会从增长业务视角反向定义数仓建设标准，掌握“技术落地服务业务增长”的实操路径，规避数仓建设重技术、轻业务、沦为数据孤岛的常见问题，提升数据驱动增长的落地能力。

落地挑战和方案重点:

痛点1：全域OneID归一准确率与增量同步平衡难题
落地中发现，多端匿名用户、游客账号、渠道分身数据存在大量ID冲突与关联断裂问题，历史全域OneID匹配准确率仅87%。同时，每日百亿级增量行为数据实时同步时，精准ID关联会消耗大量计算资源，若追求极致准确率则会导致数据产出延迟升高，若保障时效性则会降低ID匹配精度，形成准确率与时效性的天然矛盾。当前方案仅通过规则引擎+模糊匹配优化至96.2%准确率，仍存在3.8%的用户关联偏差，无法支撑超高精度的用户归因与精细化分层，是后续迭代的核心痛点。

痛点2：增长指标体系臃肿与迭代效率矛盾
用户增长业务迭代快、运营场景灵活，长期积累形成大量冗余、重复、口径不一致的指标，存量有效指标仅占65%。虽然已完成核心增长指标（拉新、转化、留存、复购）的口径统一，但业务侧临时场景化指标需求频繁，传统人工审核、迭代、上线流程繁琐，导致标准化体系固化与业务灵活迭代的冲突。一刀切的标准化管控会限制运营灵活性，宽松管控又会再次引发指标混乱，目前暂无完美适配的动态管控方案，是增长数仓长期治理的核心难点。

方案重点总结：本次落地核心围绕“用户本体统一、数据口径归一、实时离线融合”三大核心，优先解决业务核心痛点，保障增长数据的准确性与时效性。同时正视架构短板，不追求方案完美落地，通过阶段性优化、动态治理，平衡技术性能、成本与业务灵活性，为后续智能化、轻量化数仓迭代预留拓展空间。

演讲介绍：

面向表格、数据库与文档等异构数据环境，现有数据智能体仍面临业务意图、数据语义与工具执行难以对齐的问题。传统固定工作流、检索增强和静态知识图谱通常缺乏对开放任务与动态数据的持续适应能力。本报告围绕Data–Ontology–Agent协同进化展开，介绍一种以Ontology为可执行语义中间层的方法框架，统一建模领域概念、工具能力与数据模式，并基于智能体交互轨迹开展失败归因、知识修正和成对评测门控。报告将结合自主数据科学系统实践，讨论其关键机制、实验观察、落地边界及未来研究方向。

演讲提纲：

一、业务与技术背景：数据智能体为何仍然“不理解数据”

1. 企业数据同时分布于表格、数据库、文件和业务文档中，存在口径不一致、关系隐含和持续变化等问题。

2. 大模型虽然具备较强的推理和工具调用能力，但在业务意图、数据语义、工具操作与物理模式之间仍存在明显的Agent–Data Gap。

3. 典型错误并非来自模型幻觉，而是来自数据对象识别、字段语义映射和工具选择错误。

二、方案选型：为什么需要Ontology语义层

1. 固定工作流具有较强确定性，但难以覆盖动态、开放的数据分析需求。

2. RAG能够补充文本背景，却难以描述工具约束和数据结构之间的可执行关系。

3. 静态知识图谱能够表达实体关系，但建设和维护成本较高，难以根据智能体交互持续更新。

4. 选择Ontology作为Data与Agent之间的可执行语义中间层，同时承载业务知识、工具知识和模式知识。

三、落地挑战：从静态Ontology走向自进化Ontology

1. 冷启动阶段如何确定语义知识的范围、粒度和组织方式。

2. 如何从复杂交互轨迹中区分模型推理错误、工具错误和语义层缺失。

3. 如何避免自动修改引入错误知识、局部过拟合或已有能力回退。

4. 如何协同维护内容、工具和数据模式三个相互关联的层次。

四、解决思路：Data–Ontology–Agent协同进化

1. 构建三层Ontology：

   · Content Layer：描述业务概念、指标口径、实体关系和领域知识；

   · Tool Layer：描述工具能力、调用参数、前置条件和执行约束；

   · Schema Layer：连接逻辑业务概念与具体表、字段及文件结构。

2. 利用智能体与数据环境的真实交互轨迹进行失败归因，定位语义层中的知识缺口。

3. 针对内容、工具或模式层生成候选修改，而非直接修改模型或无限扩充上下文。

4. 通过持出验证集上的成对评测门控，判断修改是否提升目标能力并保持已有能力。

5. 对通过验证的修改进行版本化发布，对无效或产生回退的修改进行拒绝和回滚。

6. 形成“数据暴露问题—智能体产生轨迹—Ontology沉淀知识—智能体再次验证”的持续进化闭环。

五、系统实践与阶段性成效

1. 将上述思路应用于自主数据科学智能体，支持从原始数据读取、清洗、探索分析到报告生成的完整闭环。

2. 相关系统已稳定运行6个月，注册用户超过2000人，深度用户约400人。

3. 系统获得300余所高校和研究机构的试用申请，为语义层优化积累了大量真实任务和交互轨迹。

4. 通过具体案例展示语义错配的识别、Ontology修改、评测门控及修正前后的执行差异。

六、未来规划

1. 从单智能体反馈扩展到多智能体协同的Ontology治理与知识验证。

2. 将语义层进化与强化学习结合，使智能体学习何时读取、质疑和修正Ontology。

3. 从结构化数据扩展至文档、图像和多模态数据，构建跨数据形态的统一语义层。

4. 探索跨组织、跨领域Ontology的安全迁移、共享与持续演化机制。

七、总结

1. 数据智能体的核心瓶颈不仅是模型能力，更是智能体缺乏对真实数据世界的稳定语义理解。

2. Ontology不应只是静态知识库，而应成为可读、可执行、可验证和可持续进化的语义基础设施。

3. 数据、Ontology与Agent的协同进化，是数据智能体从演示系统走向长期生产系统的重要路径。

听众收益：

1. 建立对Agent–Data Gap的系统认知，理解数据智能体的错误为何经常发生在模型推理之前，并能够区分模型、工具、数据和语义层问题。

2. 掌握可执行Ontology的设计方法，了解如何通过Content、Tool和Schema三层结构连接业务意图、工具操作与底层数据。

3. 获得一套可落地的自进化机制，包括交互轨迹归因、候选知识修改、成对评测门控、版本管理与安全回滚，可用于企业数据智能体的持续优化。

落地挑战和方案重点:

1. 挑战：Ontology冷启动和持续维护成本高

企业的数据口径、业务规则和物理模式持续变化，依赖专家手工维护的静态Ontology容易过期，也难以覆盖智能体在真实任务中遇到的长尾问题。

方案重点：从少量高质量种子Ontology开始，通过真实交互轨迹识别高频失败模式，按需扩展Content、Tool和Schema知识，避免一次性建设“大而全”的语义体系。

2. 挑战：自动进化可能引入错误知识和能力回退

单条失败轨迹可能包含偶然噪声，直接将智能体生成的修改写入Ontology，容易造成错误传播、局部过拟合和已有任务性能下降。

方案重点：对候选修改执行持出集上的成对评测，同时验证目标任务提升和原有能力保持；只有通过门控的修改才能版本化发布，并保留完整的审计和回滚能力

演讲介绍：

面对电商促销和信贷中账号、设备、交易等多实体协同伪装，传统表格模型难以识别团伙欺诈。Shopee 图平台将对象、关系与风险规则进行本体化建模，形成动态反欺诈知识网络：图数据库支撑实时关联查询，图计算发现社区和关键节点，图学习模型预测风险。针对异构关系、特征供给与训练效率挑战，平台以统一建模、特征预取和批处理实现工程化落地。

演讲提纲：

1. 业务背景：反欺诈为何需要知识工程
电商促销和金融信贷中的用户、账号、设备、订单等对象关系复杂且持续变化；传统表格模型难以识别团伙型、跨场景欺诈。目标是将对象、关系和风险规则沉淀为动态反欺诈知识网络。

2. 方案选型：一站式图平台与知识构建
Shopee 图平台集成图数据库、图计算和图学习：图数据库支持实时关联查询，图计算挖掘社区和关键节点，图学习预测风险。通过统一实体、关系和规则建模，形成可复用的风险知识底座。

3. 实践一：Monee Credit 用户关系图与信贷风控
构建融合用户、手机号、设备等实体关系的 User Graph，利用图学习模型识别关联风险，贷前和贷中识别效果都提升明显，通过图数据库对线上借贷申请进行实时资质审批。

4. 实践二：Shopee 订单促销知识图谱与欺诈检测
围绕订单、买卖家、活动、优惠和设备构建促销反欺诈图谱，结合图计算和 RGAT等图学习模型识别黑产团伙与异常交易链路，识别出大量的潜在欺诈损失。

5. 落地挑战与工程化实践
针对大规模异构关系、实时更新、特征供给和训练效率等挑战，建立图数据建模、图计算和图学习协同流程，并通过特征预取、批处理等手段优化训练与推理效率。

6. 未来规划与总结
进一步演进为可解释、可推演的动态反欺诈本体；探索 GraphRAG 与 Agent，基于可信的实体关系、规则和证据链辅助风控分析与决策。图平台的价值在于让业务知识、规则和模型形成持续迭代的闭环。

听众收益：

了解面向企业的知识工程方法：如何将业务对象、关系和风险规则进行本体化建模，构建可实时演化的知识网络。

掌握图数据库、图计算和图学习的选型边界与协同方式，理解其在实时关联查询、团伙识别、规则挖掘和风险预测中的作用。

获得电商促销和金融信贷风控实践经验，了解如何将复杂关系数据转化为可落地的欺诈检测能力，并形成数据、规则与模型闭环。

落地挑战和方案重点：

动态知识构建效率不足：当前图计算以全量计算为主，实体和关系持续变化时，社区、连通性等图特征往往需要重复全量构建，导致资源消耗和更新时延较高。后续重点是探索增量图计算、流式关系更新和特征增量维护。
图学习模型可解释性不足：图模型能够识别关联型和团伙型欺诈，但预测结果不易直接映射为业务人员可理解的实体、关系和规则证据。后续重点是结合关键子图、节点/边贡献度及业务规则，构建可追溯、可验证的风险解释链路。

演讲介绍

背景介绍：70%的需求消耗90%的能耗，传统交付模式存在严重的效能瓶颈

演讲目标：借助AI Agent构建全栈能力底座，从传统多角色协作的跨职能接力演进为单节点全栈闭环。

效能提升30%。

论点一：组件整体累积穿刺案例达230+，累积参与人数达30；整体总结基于当前一站式流程需求开发效率提升 ≥  6倍，代码采纳率 ≥ 70%。

论点二：基于多领域穿刺案例，故障分析结果平均采纳率达到 60%+，诊断结果平均采纳率达到 50%+；

结论：AI不是替代开发者，而是让每个开发者拥有10倍效率杠杆。

下一步行动：构建 AI 驱动的自进化研发体系，实现从辅助开发到自主交付的演进。

演讲提纲

1. 业务交付效能提升瓶颈

1.1 传统软件交付模式的效能瓶颈：串行协作、知识孤岛与交付断层、能力边界扩展与全栈化转型的技术难点

2. 全栈智能体交付体系设计

2.1 体系架构：贯穿"需求分析-方案设计-编码实现-质量验证"的全链路闭环 

2.2 核心定位转型：从"人工转译"到"智能体主导"的生产力重构

2.3 技术底座：Agent Skills + MCP 的能力编排与资产化运营框架

3. 一站式需求开发智能体构建

3.1 七阶递进式工作流：需求分析 → 方案设计 → 编码实现 → 编译调试 → 测试验证 → 代码评审 → 总结提交 

3.2 关键技术创新：渐进式提示词披露、分层资源加载与上下文优化

4. 自动化质量保障与自修复技术

4.1 编译自修复：错误日志智能分析、问题定位与补丁生成的自动化闭环 

4.2 测试自修复：FT用例失败诊断、逻辑缺陷识别与自适应调整机制 

4.3 代码评审智能体：AI辅助+人工聚焦的双层质量把关体系

5. 一站式运维诊断"熄灯工厂"

5.1 故障处理模式的智能化重构：从人工驱动到Agent驱动的范式转移

5.2 自诊断流水线：故障采集 → 领域识别 → 代码锁定 → 智能诊断 → 结果反写 

5.3 自修复流水线：在线修复 → 自动测试 → 代码提交的无人化闭环 

5.4 效能目标：30%故障自诊断、10%故障自修复的量化实践

6. 规模化落地与工程化建设

6.1 多领域穿刺验证：核心领域的实践路径 

6.2 Skill资源池运营：高频场景沉淀、版本管理与持续演进机制 

6.3 一体化平台看板：研发效能可视化与全流程可追溯能力

7. 未来展望

听众收益

了解从传统多角色协作向全栈智能体交付转型的完整技术路径与工程实践。

掌握Agent Skills + MCP 架构下的能力编排、资产化运营与规模化落地方法。

学习编译自修复、测试自修复、故障自诊断等自动化质量保障技术的实现思路。

落地挑战和方案重点

基于Harness Engineering一站式交付落地实践

演讲介绍

随着大模型能力逐步提升、Agent不断优化，软件研发领域正在不断地发生变化，其中很大的一个趋势是角色变得模糊，组织层面上，产品、设计、研发、测试、运维正趋向融合。但随着角色融合的不断推进和深化，领域经验不同、研发环境脆弱等问题也浮出了水面，甚至在部分业务中造成了故障、事故等预期外的结果。本次分享将着眼角色融合的大背景，提取过程中遇到的困难，尝试通过一站式的产研平台的形式给出针对性的解决方案，并从组织的视角解剖“小团队、办大事”的团队、环境、人才、基建、流程等变革。

演讲提纲

1. Agent发展加速软件研发变革：角色融合的快速演进。

2. 变革时代下的挑战与机遇：一人多角色的实施难点。

3. 通过基建打造组织进化路线：使用一站式产研平台打消角色融合阻碍。

4. 从平台到真实业务收益：实践案例解剖与对比。

5. 个人提效迈向组织提效：进化后的组织与流程。

听众收益

1. 对于已经深度落地Agent开发、取得明显的个人提效的组织中，困于真正的交付效率提升依然有限。本分享将从组织、流程等角度解剖、分析其中原因。

2. 对于尝试在流程、组织层面推动变化和提效的团队，困于各种阻力与实际问题落地进展不理想。本分享将从最主要的痛点出发，提出可行的解决方案。

3. 对于借用平台、工具落地实践角色融合、一人多角的团队，困于社区解决方案与组织适配度有限。本分享将以自身实践为牵引，提出平台工具对于推进落地最关键的因素。

落地挑战和方案重点

1. 部分团队急切期望产品输出代码、研发介入产品设计。但因为不同角色天然的技能差异、知识壁垒，单纯以Agent为工具，会大量出现诸如“PM乱写代码进不了生产工程”、“研发无视业务背景乱提需求”这样的现象。单纯的Agent无法解决这些问题，需要知识、基建等一系列建设让所有角色能相互站在对方的肩膀上，从同一个高开始工作。

2. 不少团队进行了大量的工作解决多处单点问题，但最终没有在真正的交付效率上有质的变化。这是因为单点问题的解决往往无助于信息的打通、流程的共享，使得Agent只工作与狭隘的上下文上，无法突破原有的“需求是需求、工程是工程”的框架隔阂，最终停留在个人提效之上，组织依然只得到是非常有限的收益。

演讲介绍

AI工具正在显著提升研发人员在编码、测试、文档和问题分析等环节的效率，但个人效率的提升，并不必然带来组织生产力的同步跃迁。传统研发流程、协作机制、管理方式和评价体系，可能成为AI价值释放的新瓶颈。

本次分享将结合研发管理实践，探讨企业如何从“使用AI工具”走向“重构研发体系”：推动AI融入需求、设计、开发、测试与运维全流程；重新设计人与AI的分工协作；调整管理者角色和团队能力结构；建立兼顾效率、质量与业务价值的衡量机制。

演讲提纲

1、为什么个人提效难以转化为组织跃迁

2、AI时代研发管理的四个关键变化

3、新浪微博研发管理实践

4、未来展望

听众收益：

1、理解个人效率、团队效率与组织生产力之间的本质差异。

2、获得“个人增强—团队协同—组织重构”的分阶段推进框架。

落地挑战和方案重点

研发流程的重构打破原有平衡，形成新的风险和挑战

演讲介绍

当下 AI 应用落地加速，企业普遍面临一个共性问题：大规模数据资产需要先转化为 AI-Ready 数据，才能真正服务于模型和应用。无论是 LLM 训练微调，还是 RAG 知识库构建，都需要完成大量数据清洗、质量评估、结构化转换、语义增强和流水线复用等工作，而这些数据准备能力往往决定了最终效果的上限。
传统脚本式处理方式难以支撑大规模、跨场景、可追踪的数据生产需求，单点的 NL2SQL 也无法覆盖复杂数据准备流程。
本议题将以开源框架 DataFlow 及近期发布的 DataFlow-Harness 为核心，分享我们如何通过 Pipeline + 算子编排 模式，构建面向大规模 AI-Ready 数据准备的工程底座，并进一步用 DataFlow-Harness 弥补 NL2Pipeline 的关键缺口——让用户可以通过自然语言描述数据准备目标，再由 WebUI 或 CodingAgent 结合 MCP/Skill 调用，将需求转化为可执行、可调试、可复用的数据处理 Pipeline。
目前 DataFlow 已在工业界大规模落地，合作商汤、腾讯、北京大学、国家电网、库帕思、快手等多个企业与机构，为其提供 AI-Ready 数据集或数据工程服务，本议题也将结合实际落地中的工程挑战与踩坑反思，为企业建设 Data Engineering Agent 提供一条从数据底座到智能编排的实践路径。

演讲提纲

1. 企业 AI 落地中的 AI-Ready 数据准备挑战
2. DataFlow 的 Pipeline + 算子编排设计
3. 从 NL2SQL 到 NL2Pipeline：DataFlow-Harness 的自然语言 Pipeline 生成与调用机制
4. AI-Ready 数据集与数据工程服务的典型落地实践

听众收益

了解 AI-Ready 数据准备在企业 AI 落地中的关键作用，掌握 DataFlow 通过 Pipeline 与算子编排构建可复用数据生产链路的方法，并理解 DataFlow-Harness 如何弥补 NL2Pipeline 缺口，为 Data Engineering Agent 建设提供实践参考。

演讲介绍

企查查是企业信用查询领域领头羊，而企业征信领域必然会涉及到大量的金融公告文档、声明公告等，我们从数据层面加强模型对复杂的金融公告中的表格结构识别能力、从算法层面解决和提升模型无法处理的特殊场景、再引入前沿的Dflash算法来提速不降智，最后下游任务讲基于这些解析出的高质量的元素来进行信息抽取。

演讲提纲

1. 智能文档解析在企查查中的需求（海量的金融公告、标书文档）

2. 训练-数据为王（如何定向找出缺陷数据，提升模型能力）

3. 特殊场景下的算法优化（超长图片切割、vlm幻觉修正、印章和水印的特殊处理）

4. 算法带来的质量提升与性能提升（模型加速、跨页表格合并）

5. 下游应用（信息抽取、agentic-rag）

6. 总结

听众收益

1. 了解到智能文档解析，了解到其中的难点

2. 了解智能文档解析的应用

落地挑战和方案重点

1. 海量文档解析速度慢

2. vlm幻觉

演讲介绍

非结构化文档是RAG系统和AI应用落地的核心瓶颈。本次分享将介绍我们围绕知识增强RAG和PDF转Docx两个方向，构建的通用文档解析与样式还原技术体系。

在解析侧，我们采用Pipeline多模型协同与多模态大模型两套并行方案。前者通过版式分析、表格解析、公式识别等模块分工协作，后者以统一模型+差异化Prompt实现端到端结构化输出。

在样式还原侧，通过规则驱动的流式重构和代码生成式还原两套方案，实现PDF到可编辑Docx的高保真转换。

演讲提纲

1.非结构化文档解析的应用场景与挑战

2.通用文档解析系统设计与方法路线

3.系统组件划分与垂直场景定制优化

4.从PDF到Docx：页面样式还原

5.总结与展望

听众收益

1. 理解非结构化文档解析在RAG系统中的关键作用与工程全貌；

2. 掌握“内容理解”与“样式还原”两条技术路线的差异与协同；

3. 获得垂直场景定制化解析和工程化落地的实践经验。

落地挑战和方案重点

1. 复杂版式下解析准确率与结构化完整性的平衡

Pipeline方案虽可针对性优化各子模块，但模块间误差累积问题突出；多模态方案端到端能力强，但在细粒度结构还原（如表格单元格坐标属性等）上仍有不足

2. 样式还原中“视觉相似”与“结构合规”的双重约束

既要让生成的Word文档在视觉上与原始PDF高度相似（字体、间距、缩进、页眉页脚等），又要符合Word文档的底层结构规范，确保用户能够顺畅地进行二次编辑，两者往往存在冲突。

演讲介绍：

基金公司每天沉淀大量研报、公告、路演、舆情、专家访谈等非结构化投研数据，但相比行情、交易、产品等结构化数据，这些数据长期面临来源分散、格式复杂、标准不一、难以统一治理和计算等问题。本分享从数据工程视角出发，介绍多模态投研数据从采集接入、文档解析、内容清洗、统一建模到数据治理的实践，并探索 NLP 与 LLM 如何作为新的语义加工能力，完成实体、事件、观点等信息抽取与语义切片、向量化，逐步将原始文档转化为可治理、可关联、可计算的数据资产。

演讲提纲：

1. 基金投研的非结构化数据困境
2. 从“文件”走向“数据对象”
3. NLP 与 LLM 如何成为新的“数据处理引擎”
4. 从文本到“可计算的投研数据资产”
5. 从数据资产到投研价值：检索与智能应用

听众收益：

1.建立多模态数据治理的完整方法论：从研报、公告、路演、舆情、访谈等原始数据接入，到解析、清洗、标准化、建模、质量管理和数据资产化，理解非结构化数据如何真正进入企业数据体系。

2. 理解 NLP / LLM 在数据工程中的新角色：不把大模型简单理解为“问答工具”，而是将其作为一种新的语义计算与数据加工引擎，与传统 ETL、规则、NLP 和数据仓库结合，完成过去难以自动化的数据处理任务。

落地挑战和方案重点：

1. 文档结构保真与切片粒度的矛盾
2. 金融场景的检索精度与结果可信度