演讲介绍

Harness 能力决定效果的下限，企业知识系统决定 AI 产生业务价值的上限。

为什么企业已经建设了数据平台、RAG 和知识图谱，AI 仍然经常答不准、说不清、做不了？问题往往不只在模型和 Agent Harness，而在于企业缺少一套能够表达业务语义、关系、规则和上下文，并连接真实行动的知识系统。

本体是组织企业知识的重要方式，但本体当前没有统一标准。Palantir、Snowflake、Databricks、Apache Ossie 与 Agent Memory 实际采用了五种不同路线。它们真正的差异不是 “有没有图”，而是知识如何表示、运行、生产和验证。

本次演讲将从 DIKW 出发，拆解知识与本体的演进，比较五类主流技术路线，并给出企业从数据工程走向知识工程的落地路径。

演讲提纲

AI 时代，为什么有了数据还不够

知识、本体、Semantic Layer 与知识图谱的关系

本体当前没有统一标准：五类主流路线如何选择

企业知识建设的起点：内核、外围与开放接口

持续知识工程的参考架构和案例：生产、评估、认证与更新

听众收益：

一张概念地图：厘清数据、知识、本体、Semantic Layer 与知识图谱

一张选型地图：看懂五类主流方案的差异、边界与适用场景

一条落地路线：从高价值业务域开始，建立可持续演进的企业知识闭环

落地挑战和方案重点：

挑战：企业知识分散、语义口径不一、本体没有统一标准，传统语义模型又容易成为难以维护的一次性交付。

方案重点：从高价值结构化业务域切入，以 Semantic View 建立确定性语义内核，以 Context 和 Memory 补充长尾知识，以开放规范连接生态，并通过 AI ETL、Observability 和 Knowledge Engineering 形成持续闭环。

演讲介绍：

在金融风控与合规审核中，真正困难的不是再做一个能对话的 Agent，而是让 AI 在真实 case system 上获取正确上下文、理解领域规则、保留证据链，并在跨系统联动时不越权。

  我们从 Business KYC、Individual KYC、KYB、MRM 等真实场景出发，逐步建设 Case Copilot 平台：将分散在代码、API、规则配置、SOP 和领域人员经验中的知识沉淀为可测试的 domain skills，再通过统一的 context、orchestrator、evaluation、trace 以及 UI/API 接口交付给审核人员。

  在这个过程中，我们遇到了许多典型的生产问题：巨大 prompt 导致结果不稳定，长链路调用出现 gateway timeout，动态数据缺乏可靠 snapshot，调用超时不代表下游任务没有执行，不同角色需要的信息粒度完全不同，而单个 Agent 的准确率达标，也不代表完整 workflow 可以安全上线。

  基于这些实践，我们最终完成了“每个 case system 一个独立 domain agent”的架构。各 agent 保留自己的事实、规则和 decision ownership，通过 A2A contract 暴露受治理的能力；其上的 Cross-Case Orchestration Layer 负责生产环境中的能力发现、任务跟踪、证据关联、冲突识别和跨 case 分

  析。

  生产编排并没有交给一个全权自主的“大脑”，而是采用 deterministic workflow + bounded LLM planner：确定性代码负责权限、状态、重试、补偿和高风险动作，LLM 只负责模糊意图拆解以及受限的动态路由。

听众收益：

本次分享展示的不是理想化 Demo，而是一套已经完成生产落地的多 Agent 系统，以及它从单 case Copilot 演进到跨 case agent mesh 的完整过程。我们将复盘哪些方案有效、哪些假设失败，并拆解 Agent Card、Task/Artifact contract、权限传播、版本管理、闭卷评估、decision-level trace、 human gate 和降级机制如何共同支撑生产运行。

参会者可以带走一套经过真实业务验证、可复制、可量化、可审计、可回滚的多 Agent 分层架构与迁移方法。

落地挑战和方案重点：

第一，Agent 如何真正理解业务。金融风控知识并不集中在一份文档里，而是分散在代码、API、规则配置、SOP 和领域专家经验中。我们的方案是从这些真实来源生成 domain knowledge，再由领域负责人审核和版本化，最终沉淀为可测试、可复用的 skills。

  第二，如何解决巨大 Prompt 带来的不稳定性。早期把大量判断逻辑放在一个 Prompt 中，会导致多次运行结果不一致，一个局部错误也可能污染整个 summary。后续我们把完整判断拆成独立的 checkpoint skills，让每项能力可以单独开发、评估、缓存、上线和回滚。

  第三，如何处理长任务和超时。生产环境中出现过 gateway timeout，但调用方超时并不意味着下游任务没有执行。如果直接重试，还可能造成重复操作。我们的方案是使用 A2A Task 管理任务生命周期，通过唯一 Task ID、幂等 key、异步状态查询和 Artifact 持久化，保证任务可以追踪、恢复和去

  重。

  第四，如何处理跨 Case 的事实冲突。不同 case systems 的数据更新时间、规则版本和业务语义并不完全一致。统筹层不能让 LLM 静默选择一个看起来合理的答案，而是要求每个 Agent 返回数据来源、观察时间和版本信息。当结果不一致时，系统生成明确的 conflict artifact，并将问题交给正确的

  domain owner。

  第五，如何控制 Agent 的权限和责任边界。上层 orchestrator 可以组合领域能力，但不能替代各 case system 的 decision ownership。我们把能力分成 Read、Analyze、Propose 和 Act 四个等级。读取和分析可以在授权范围内自动执行，而修改 case、发送 RFI 或改变 workflow 状态等高风险动

  作，必须经过确定性权限检查和人工审批。

  第六，如何避免多 Agent 的误差叠加。单个 Agent 的准确率达标，并不代表多个 Agent 组合后的完整流程仍然安全。因此除了对每个 Agent 做独立 benchmark，还需要对端到端 workflow 进行评估，比较 human baseline、material error、证据完整性、路由准确率和 unsafe action rate。

  第七，如何让系统安全失败。当某个 Agent 超时、不可用或 schema 不兼容时，统筹层必须返回明确的 partial result，说明哪些结果已完成、哪些领域暂时不可用，而不是用模型补全缺失信息。系统还需要具备 circuit breaker、capability kill switch、旧版本回退和人工流程降级能力。

  第八，如何服务不同角色。相同的证据对不同用户具有不同意义：Risk 需要完整 evidence，Ops 需要 next action，CS 只关心由谁处理以及哪些信息可以向客户解释，管理者需要跨 case 趋势。我们的方案是在共享 evidence 之上生成 role-specific output，而不是把同一份冗长 summary 发给所有人。

演讲介绍：

早期我们使用 AI 工作流实现AIOps业务，但业务演进与 AI 规模化落地后，预定义节点模式难以适配复杂动态任务，不支持记忆沉淀、多智能体协同、租户隔离等高阶能力。

为此我们基于 HermesAgent 底座，自研企业级多租户数字员工系统，已在 SRE AIOps 规模化落地，并拓展至营销、客服、DevOps 等多场景。本次报告分享我们数字员工的 Agent 工程化、多租户治理、记忆知识及多智能体协同的实践方案与行业经验。

演讲提纲：

一、演进背景：从AI工作流到企业级数字员工集群

早期技术现状：基于AI工作流完成线上落地，可满足固定流程自动化需求

范式核心瓶颈：工作流灵活性不足，无法动态决策、持久化记忆、多角色协同，不适配复杂长链路业务

业务升级诉求：企业规模化落地，亟需多租户隔离、精细化权限、可治理、可进化的智能体能力

技术方案升级：基于HermesAgent自研企业级多租户数字员工系统

落地全景：深度落地SRE AIOps，同时覆盖营销、客服、DevOps等多业务线，具备通用落地能力

二、技术架构：HermesAgent多租户数字员工集群核心建设

整体架构：分层集群架构，支撑数字员工规模化、高可用企业落地

云原生能力：基于K8s实现云端部署、弹性调度，保障集群稳定运行

多租户隔离：实现数据、会话、记忆三层隔离；轻量化隔离仍有短板，存在越权、数据泄露风险

企业权限体系：对接SSO实现统一Token鉴权；工具、技能调用缺乏统一权限底座，标准化不足

Skill标准化：统一认证规范，兼容本地/SAAS双模式，厘清技能边界与互斥规则

CoT工程创新：标准化思维链规范推理、剔除冗余思考，提升精准度与性能；原生模型推理冗余、响应慢，需持续优化

落地形态：覆盖个人、团队、全员共享数字员工，包含通用问答、专项技能两类形态

全局性能瓶颈：大模型及Agent原生推理链路耗时高，无法满足业务毫秒级响应诉求，推理冗余、耗时不可控，是行业规模化落地的核心共性难题

三、治理体系：记忆+知识+技能协同，构建Agent自进化飞轮

核心能力分层：明确数字员工、Skill、知识库、长效记忆的定位与协同关系

可管控记忆体系：规则化记忆约束模型输出；当前规则分散、易被绕过，输出一致性较弱

CoT+记忆联动：结合业务长效记忆与标准化思维链，保障推理输出稳定可追溯

多源知识接入：支持专属、业务、企业存量知识及知识图谱多形态接入

自进化飞轮：形成业务运行-经验沉淀-知识迭代的能力闭环；知识库召回精度不足，存在错配、遗忘问题

四、场景落地：流程+状态机驱动的多智能体协同模式

创新协同架构：搭建流程+状态机标准化多智能体协同体系，替代无序协同模式

角色分工机制：单员工绑定专属职责与任务状态，权责清晰、专人专事

状态流转机制：通过标准化状态变更、任务交接，驱动复杂业务全自动闭环

核心落地场景：落地SRE AIOps全链路场景，实现故障处置、修复、代码提交自动化，完成运维能力右移

通用能力验证：多业务线落地，验证平台全域复用能力

现存协同短板：多Agent协同体系不成熟，缺少标准化管控，任务交接、闭环作业能力不足

五、总结与未来演进方向

范式升级总结：从无状态工作流自动化，升级为可记忆、可管控、可协同、可进化的数字员工自治体系

核心落地结论：企业级Agent核心壁垒为工程化、治理、安全与协同能力，而非单纯模型能力

未来迭代方向深耕性能优化，解决大模型/Agent推理耗时问题，突破毫秒级业务响应瓶颈，精简推理冗余链路

优化CoT精细化推理逻辑，进一步提升模型输出准确率与稳定性

迭代知识库治理能力，优化精准召回，解决知识错配、遗忘问题

完善流程+状态机协同框架，补齐多智能体标准化协同、闭环管控能力

听众收益：

1，企业数字员工、Agent 工程实践：学习多租户隔离、Skill 体系、工程化 CoT 思维链的落地思路，了解如何解决记忆管控、权限治理等生产环境实际难题。

2，数字员工多智能体协同方案：了解基于流程 + 状态机的数字员工分工协作模式，借鉴 SRE‑AIOps 及多业务线真实落地经验。

3，数字员工生产级问题的解决思路：了解数字员工在记忆治理、技能管控、租户安全方面的实战方案，可直接复用至内部 Agent 平台建设。

落地挑战和方案重点：

1，数字员工能力的沉淀和进化。随着场景增多，skill泛滥、业务与运维经验零散无序、散布各处，如何确保数字员工高效工作、快速响应、持续进化。

2，大模型及Agent全局性能提升：大模型及Agent原生推理链路耗时高，无法满足业务毫秒级响应诉求，推理冗余、耗时不可控。

演讲介绍

LMCache 是一个面向大语言模型（LLM）推理的开源 KV 缓存管理层，已加入 PyTorch Foundation，并被 NVIDIA Dynamo、LLM Production Stack、llm-d、KServe 等主流推理基础设施集成。它从设计上就是完全厂商中立的：上层适配 vLLM、SGLang、TensorRT-LLM 等主流推理引擎；硬件覆盖 NVIDIA、AMD、Intel、华为昇腾、摩尔线程、寒武纪等众多加速器；KV cache 的二级（L2）存储后端通过插件方式支持 Mooncake Store、Redis / Valkey、S3 兼容对象存储、NIXL Storage、分布式文件系统以及 GPUDirect Storage；Llama、Qwen、DeepSeek、GPT-OSS、各类 MoE 与多模态模型等几乎所有主流开源模型都开箱可用。

作为 LMCache 的维护者与核心贡献者，我将在本次分享中讲述「一个开放的 KV 缓存层在实践中究竟意味着什么」。我们会一起回顾 2025–2026 年社区最重要的几个里程碑：加入 PyTorch Foundation；让 MoE 推理吞吐提升最高达 10 倍的多进程（MP）架构重构；让项目真正保持厂商中立的可插拔 L2 存储连接器框架；以及让真实用户敢于上生产的可观测性与健康检查体系。

更重要的是，我会讲述这一切背后的开源故事：来自 Tencent、Red Hat、NVIDIA、AMD、Intel、IBM、AWS、Google Cloud、Samsung、Cohere、Pinterest、Hugging Face、CoreWeave、Mooncake、Valkey、DDN、VAST、WEKA、昇腾、DaoCloud、Tensormesh、character.ai、Yotta Labs、芝加哥大学等数十家公司与机构的贡献者，是如何协同推进一个高速演进的 AI 基础设施项目的；我们如何保持极低的贡献门槛与新人友好度；以及为什么「开放、中立、双赢合作」不是口号，而是 LLM 时代基础设施唯一可持续的建设方式。

LMCache 把 KV 缓存从GPU 上的临时产物变成可复用、可持久化、厂商中立的推理基础设施层。本次分享将带你走进这个开源社区——它同时跑在 vLLM / SGLang / TensorRT-LLM 之上，覆盖 NVIDIA / AMD / Intel / 昇腾 / 摩尔线程 / 寒武纪等加速硬件，对接 Mooncake / Redis / S3 / NIXL 等存储——并且始终为新贡献者敞开大门。

演讲提纲

一、提出问题：2026 年的 LLM 推理为什么离不开 KV 缓存。并就此介绍：

二、开放性设计：LMCache 的生态全景 

三、LMCache 从进程内库到引擎独立服务 

四、处处可插拔：LMCache 如何坚持厂商中立 

五、走向生产：可观测性、健康检查与 PD 分离 

六、背后的开源故事 

七、Roadmap 与号召 Contribution

听众收益

一个真正开放、厂商中立的 KV 缓存层在 2026 年长什么样，以及为什么 LLM 生态需要它。

LMCache 背后的社区故事：加入 PyTorch Foundation、被 NVIDIA Dynamo / Production Stack / llm-d / KServe 集成、与 vLLM / SGLang / TensorRT-LLM 等主流推理引擎深度协作。

插件化架构（引擎独立的多进程服务、可插拔 L2 存储连接器、原生连接器）如何在不分裂生态的前提下，支撑多推理引擎、多硬件、多存储后端。

来自一线贡献者的工程实践：POSIX 共享内存、零拷贝 KV 传输、存储后端的动态发现、可观测性与健康检查体系。

社区如何保持极低的贡献门槛：新人友好的 issue、透明的设计讨论、跨厂商 CI，以及让协作真正双赢的文化习惯。

落地挑战和方案重点

痛点1：架构"破坏性重构"的平滑落地问题 从单进程（与推理引擎"共生死"）迁移到推理引擎独立的多进程（MP）服务架构，虽然基于 POSIX 共享内存 + eventfd 的零拷贝方案已经获得极大吞吐提升，但如何在不打破海量下游用户既有部署方式和使用习惯的前提下完成这次重构以支持扩展不同的平台和 Device，目前仍依赖社区逐步验证和过渡适配，没有一次性的完美迁移方案。

痛点2：厂商中立生态的碎片化与长期治理 LMCache 通过插件化 L2 存储连接器框架 + 动态发现机制，让新硬件（昇腾/摩尔线程/寒武纪等）、新存储厂商（Mooncake/NIXL/S3等）可以低门槛接入，无需侵入主库。但随着接入方数量持续增长，跨厂商 CI 覆盖、接口长期稳定性、以及"不分裂生态"的持续治理，仍是需要长期投入、尚未有一劳永逸解法的问题。

当 LLM 能力渗入数据平台，一个绕不开的问题是：数据能力该封装成 Skill 还是 Agent？全做成 Agent 会带来成本失控与能力重复；全做成 Tool 又撑不起归因、洞察、SQL 生成等多步决策场景。我们提出 Skill（原子能力层）/ Agent（场景编排层）/ 项目空间（治理层）的三层抽象，通过统一接口契约让 Skill 在多个 Agent 间复用，通过项目空间实现个人 → 空间 → 平台的三级贡献分发。目前已支撑探索分析、归因、洞察、SQL 生成等多个场景 Agent，底层 Skill 跨 Agent 复用率显著提升，个人贡献的能力也能沉淀为平台资产。本分享将正面回答"Skill 和 Agent 到底怎么分"这一高频争论，并复盘真实的设计取舍与踩坑。

演讲提纲：

一、业务背景与问题定义
1. 数据平台面对探索性、诊断性需求的响应困境
2. LLM 引入后的两种极端：全 Agent 化 vs 纯 Tool Use，各自失效的原因
3. 数据领域的独特张力：确定性 × 决策性并存

二、方案选型与核心架构
1. 三层抽象：Skill（能力层）/ Agent（编排层）/ 项目空间（治理层）
2. Skill 的接口契约：输入输出 / 副作用 / 权限 / 幂等
3. Agent 的编排模式：ReAct、Plan-Execute、人工介入
4. 项目空间的治理职责：发布订阅、权限穿透、生命周期

三、边界辨析：Skill 与 Agent 的五维判据
1. 是否用 LLM / 是否多步规划 / 是否有状态 / 面向谁 / 失败语义
2. 真实争论：SQL 生成到底是 Skill 还是 Agent？
3. 反模式：什么能力不该做成 Agent，什么能力不该做成 Skill

四、落地挑战与实证案例
1. 探索分析 / 归因 / 洞察 / SQL 生成：Agent 共用 Skill 的复用图谱
2. 踩坑：Skill 粒度失控、命名语义重叠、质量参差、贡献动力不足

五、贡献机制、未来规划与总结
1. 个人 → 空间 → 平台的三级分发机制
2. Skill 自动评测、Agent 能力图谱、跨空间能力流转
3. 开放问题：私有 Skill 体系与 MCP / A2A 开放协议如何共处

听众收益：

1. 一套可迁移的双层抽象方法论：掌握 Skill 与 Agent 的边界判据，能在自己的数据平台中落地分层能力架构，避免"每个需求都做一个 Agent"的失控。
2. 数据领域 Skill 设计经验：针对归因、洞察、SQL 生成等复杂场景，理解哪些原子能力值得沉淀为 Skill、哪些应当封装为 Agent，以及标签系统在其中的定位。
3. 能力贡献生态的工程取舍：理解个人 → 空间 → 平台的三级分发机制，在质量、权限、复用之间取得平衡，避免"人人可建"沦为"无人敢用"。

奇虎360做了一件挺有意思的事——在公司云数仓整体架构之上，搭了一个能"聊着天就把数据查了"的 AI 应用。一开始的想法很简单：让业务同学不用写 SQL，用自然语言就能取数。但做着做着发现，想让它从"会查数"变成"懂业务"，中间隔着一座大山——语义层。大模型写 SQL 这件事，学术数据集上能跑到 85%，一进真实数仓就现原形：几百张表、上万个字段、口径靠口口相传，准确率断崖式下跌，而且错了你都不知道它错在哪。更麻烦的是，业务不可能等你花半年把语义层建好再上线——大多数企业手里就只有散落的表文档和老员工的"这个字段是那个意思"。我们的做法是"半成品冷启动，边跑边长"：先用双路径混合路由让系统跑起来——语义完整的走确定性编译引擎，只有表和文档的走 RAG 降级，同时给每一条结果带上置信度分数，用户一看就知道"这条是系统算出来的，那条是系统猜的"；然后从薄 API 起步，查数、归因、决策逐层长成 Skill，高频使用的经验再反向沉淀为语义资产；配上三级评测加反馈飞轮，让质量可度量、可回溯。这套方案目前已支撑内部大数据集群运维、S3 、PoleFS 存储运维的指标分析与归因场景，同时、Ops机房运维、文库搜索、会员中台等跨部门业务也已接入使用。语义资产在真实使用中持续自生长——这条路我们已经在走了，来跟大家聊聊踩过的坑和拿到的一手经验。

演讲提纲：

一、范式转变：从"模型写 SQL"到"引擎写 SQL"
1. 学术基准的幻觉：Spider 85% → 真实数仓 50%，差距来自哪里？
2. 行业共识形成：不确定的归模型，确定的归引擎
3. 但新问题随之而来：语义层没建完的时候怎么办？

二、双路径混合路由：语义层不完善时的冷启动方案
1. AST 主路径：语义层完备时，LLM 仅做意图提取 → 确定性编译器生成 SQL，不走"猜"的路径
2. Fallback RAG 降级路径：只有表和文档时，混合检索（embedding + 关键词 + 外键图）定位相关表，LLM 兜底生成
3. 路由决策：PreMatch + 置信度度量 → 自动判定走哪条路径
4. 置信度的关键价值不止于"准不准"——它决定了哪些场景可以放心用。举个例子：产品运营同学要分析某个功能改版后的留存变化，一条错误的数据可能直接误导产品方向判断。但有了置信度兜底，0.95 以上自动入报表，0.65 以下系统主动提示"这条我不太确定，建议人工确认"——用户心里有数，敢用。反过来看，正是因为有了置信度，这类直接影响业务决策的高敏场景才敢投入生产使用，而不是永远停留在 demo 阶段。

三、Skill 体系：薄 API → 厚 Skill → 本体元数据
1. 行业参考：Snowflake Cortex Agent（语义查询 + 非结构化检索 + UDF + Agent Skills 编排）与我们的层面对齐
2. 渐进路径：暴露指标/维度/枚举查询接口（薄 API）→ 快速构建查数/归因/预测 Skill → 高频经验（归因因子、维度层次、业务阈值）沉淀为本体元数据
3. 最终形态：Skill 退化为纯编排器，知识全由本体层提供

四、量化评测：从学术基准到生产落地
1. 学术基准为什么不够：比 SQL 文本而非查询结果、不涉及业务口径/多轮对话/幻觉检测
2. 三级评测架构：L1 程序自动比对结果集 → L2 LLM Judge 语义判断 → L3 人工兜底
3. 数据飞轮：用户点赞经防污染过滤后自动采样为回归测试集，9 维指标持续追踪

听众收益：

1. 一套可迁移的渐进式语义层落地方法论：双路径路由让系统先跑起来，RAG + 置信度引导让语义资产在使用中自然生长。
2. 理解 NL2SQL 学术与生产的鸿沟：WikiSQL / Spider / BIRD 为什么不够用，以及如何搭建面向业务口径的生产级评测体系。
3. 掌握 Skill 到本体层的演进路径：薄 API → 厚 Skill → 本体元数据的设计取舍与落地经验。
4. 可复用的三级评测架构：L1 程序 → L2 LLM → L3 人工 + 反馈数据飞轮 + 回归测试。

演讲介绍

AI 问数正在逐步成为数据消费的基础能力，但大模型直接回答业务数据问题时，容易出现幻觉、不稳定、不置信等问题。尤其在需要 TEXT2SQL 场景中，单纯依赖模型训练知识或文本召回，很难保证结果准确一致。

  语义层的价值，是在大模型和底层数据资产之间增加一层强约束知识。它把指标、维度、实体、业务过程、物理实现、SQL 规则等内容结构化管理起来，让 AI 在明确边界内理解业务、生成 SQL、解释结果。相比单一的文本知识库、RAG 向量召回或全量资产元数据召回，语义层具备更明确的查询约束指导、可解释性、更低的推理消耗，也能同时服务人和 AI 的优势。

  将语义层平台化后，进一步解决口径过期、物理表更新、本地版本不一致、知识分散维护等问题。平台作为统一事实源，持续管理语义定义、版本、映射关系和消费治理，从而提升 AI 问数的准确性、一致性和可信度。

演讲提纲

1. 为什么需要语义平台

2. 本体和数据语义

3. 语义平台建设思路

   语义挖掘、语义检索、本体、语义映射、测评体系、MCP、数据治理

4. 未来方向

听众收益

1. 如何基于数据仓库的数据语义平台建设

2. 面向数据消费的数据语义建设

3. dataagent

演讲介绍：

小米团队在 BIRD 全球 Text2SQL 评测中斩获第三，但更重要的问题是：如何让这个能力在真实业务中持续变准、越用越好？我们的答案是：把 BI 平台多年积累的语义层变成 AI 持续进化的燃料——低成本构建领域评测集，驱动效果闭环迭代，并基于已验证的评测集同步提升准确率与响应效率。今年我们进一步开放 CLI 能力，让用户通过自然语言完成知识沉淀与效果迭代。本次分享还原这条路径的核心取舍，为行业Data Agent 落地提供参考。

演讲提纲：

1、小米Data Agent介绍
2、落地挑战与解法
3、实践案例
4、经验与展望