演讲介绍

在运满满App内，一个货主平均要沟通5个候选司机才能完成下单。为了节省货主精力，提高平台撮合效率，满帮集团构建了基于Agent系统的双边撮合能力。在此过程中主要挑战是撮合时会大量遇到司机关于货源信息之外的问题，以及如何让agent像专业的平台调度员一样思考和回复。我们通过对用户在平台上交易痕迹的洞察和挖掘构建了颗粒度从细到粗的四层知识底座，并为物流场景贴身打造了harness系统，从而使agent能够真正可靠地运行于真实撮合场景之下。

演讲提纲

•业务场景介绍
•场景中的主要挑战
•如何构建有价值的知识底座
•物流垂类场景下的harness构建
•对agent的准确评估和归因分析

听众收益

1、以物流场景为例，深入了解在垂类专业领域落地agent的全流程；
2、如何在一个存在大量非标和脏数据的场景内逐步构建可信的知识体系；
3、通过harness engineering，使用基座模型也能具备专业级的可靠结果产出。

落地挑战和方案重点

1、在严肃场景下，让agent的准确率达到极高的迭代路径？

演讲介绍

Agentic AI让大模型的效果有了更好发挥，但也带来了请求时延的极大增加。在2c并特定领域下——对时延要求高，且很少遇到复杂问题——这时还有必要选择Agentic AI？我们选择了放弃，但智能体效果、系统性能以及运营带来的效率问题仍然是我们面临的挑战，本次演讲介绍了我们的实践和方案。同时，在进一步探索中，并未放弃Agentic AI，而是提出了更具创新的“离在线混合自进化”解决方案。

演讲提纲

引子：Agentic AI的使用和放弃；
正文：效果、性能和效率的平衡之道；
未来：新架构的探索和尝试。

听众收益

1.在业务落地时是否选择Agentic AI，该如何判断？
2.一些可用于实践的效果、性能及效率的优化手段和方法。
3.Agentic AI和Workflow能否更好的协调，从而更好服务业务？

落地挑战和方案重点

1.在业务落地时是否选择Agentic AI，该如何判断？
2.2c场景下的Agent实践中，如何更好的平衡效果、性能及效率？
3.Agentic AI和Workflow能否更好的协调，从而更好服务业务？

演讲介绍

数据治理做了二十年，BI 和 Agent 却仍然"听不懂业务"：指标口径不一、实体对不齐、AI 幻觉频发。根源在于，数据集成解决了"通"，没有解决"懂"。我们对这一问题的诊断是：语义互操作存在四层系统性缺失，即语义标注缺失、跨系统概念异构、业务规则非形式化、操作语义未定义。

本次分享介绍我们的解决思路与实践：以 O-R-R-A 框架（对象、关系、规则、行动）定义机器可执行的业务认知契约，以增量式本体工程推动企业认知持续生长。目前已在 10 多个主流系统完成分钟级异构字段对齐，指标口径统一率从 62% 提升至 95%，风险路径识别时间从 3 天缩短至分钟级。相关方案已在企业级数据智能项目中落地验证。

演讲提纲

1. 业务背景：为什么 Agentic AI 卡在"最后一公里"

· 企业数据资产现状：系统林立、口径割裂，AI 缺乏业务上下文

· 语义互操作的四层缺失：语义标注缺失、跨系统概念异构、业务规则非形式化、操作语义未定义

· 核心判断：Agent 的瓶颈不在模型能力，而在语义供给不足

2. 方案选型：为什么是本体，而不是更大的数据中台

· 六层语义使能阶梯：从词汇表到逻辑模型的语义建设路径及配套治理机制。四层缺失回答"哪里断了"，六层阶梯回答"该修到哪一层"

· O-R-R-A 本体框架：对象、关系、规则、行动，构成机器可理解、可推理、可执行的业务模型

· 本体与知识图谱的关系：知识图谱是实例层，本体是 Schema 层的业务认知模型，二者协同而非等同。本体不是画出来的知识图谱，而是能被 Agent 执行的认知契约

· 关键选型结论：以本体约束的语义解析替代直连 NL2SQL，解决幻觉与可解释性问题；以本体工程替代一次性知识图谱项目，解决建模周期与治理难题

3. 落地挑战与解决思路：璇玑 DataAgent 平台的架构设计

璇玑 DataAgent 将本体建模拆解为业务数据接入、本体设计、本体实现、本体消费四个步骤，通过人机协同完成建模闭环，对外提供 API/MCP 双通道语义服务，支持语义混合检索。其中，四个步骤构成每个迭代的执行闭环，回答"每一步做什么"；增量式本体工程的六阶段路径（场景牵引、识别对象、按需建模、连接数据、应用验证、持续沉淀）是迭代的推进节奏，回答"迭代多快、如何验收"。内环做事，外环控节奏。

· 挑战一：本体建模周期长、业务参与难。解决思路：用例驱动的增量式本体工程与人机协同建模。以 50 个核心概念为界构建最小可用本体，按六阶段路径推进、90 天完成迭代；业务人员在建模工作台参与本体设计，数据映射引擎自动探查 Schema、辅助异构字段对齐，将建模从专家独白转变为人机共创。

· 挑战二：语义资产"建而不用、用而不治"。解决思路：将本体做成运行时基础设施而非离线文档。能力层面，璇玑 DataAgent 提供六大组件：建模工作台（业务人员协同建模）、数据映射引擎（Schema 自动探查对齐）、语义查询引擎（本体约束生成、语义混合检索、结论可回溯）、统一指标服务（一次注册、全局消费）、Agent 接入网关（上下文注入与语义校验，经 API/MCP 双通道对外服务）、治理控制台（版本、血缘、质量）。治理层面，建立三方评审机制（业务专家定义语义、数据架构师建模、AI 工程师落地）与 SemVer 语义化版本控制，治理目标为跨场景复用率不低于 60%、对齐准确率不低于 95%。

· 挑战三：AI 输出不可解释、不敢采信。解决思路：以本体作为业务认知契约，约束 Agent 的查询生成与推理路径；语义混合检索使每条结论均可回溯到本体概念、关系与规则，实现可解释分析。

4. 企业实践

· 实践一：跨系统语义对齐与对话式分析。完成 ERP/CRM/MES 等系统的实体对齐与分钟级异构字段映射，统一指标语义；对话式分析能力从回答 What 升级为沿关系链下钻 Where、Who、Why、What Next

· 实践二：沿关系链的风险推理。以供应链风险传染路径为主案例，风险识别从单点阈值预警升级为关系链传播推理

· 实践三：场景驱动的精准数据治理。治理导向从资产完备率转向业务价值，从"几万张表都要治理"转向"优先治理支撑场景的关键数据"

5. 未来规划：从项目到认知资产运营

· 语义反馈闭环模型（SFLM）：让本体在使用中持续生长。以查询日志聚类、概念缺口识别、三方评审入库三项机制落地，评审通过的概念以 SemVer 新版本入库，进入下一个使用周期

· 五阶段认知能力跃迁路线图：数据可见、语义可查、关系可推、业务可问、决策可谋

6. 总结与建议

· 两条可复制的最小实践路径：增量式本体工程与 SFLM 反馈闭环

· 核心观点：企业的核心竞争力，正从"拥有数据"转向"拥有可被执行的业务认知"

听众收益

· 一套可诊断的框架：掌握四层语义互操作缺失的诊断方法与六层语义使能阶梯的评估工具，能够对照判断本企业智能建设所处阶段与短板。

· 一条低风险的落地路径：一张可带走的 90 天起步路线图，选定 1 个高价值用例、构建 50 个概念以内的 MVP 本体、接入 1 个 Agent 场景，配套三方评审与语义化版本治理，避开"大爆炸式建模"的失败陷阱。

· 三个可参照的实战样板：跨系统语义对齐与对话式分析、沿关系链风险推理、场景驱动精准数据治理的完整案例，含选型对比、治理机制与量化效果指标，可直接对标。

落地挑战和方案重点

核心落地挑战一：语义建模起步重、见效慢。传统本体工程动辄数月建模，业务方中途流失。方案重点：用例驱动的增量式本体工程，走六阶段路径，以 50 个核心概念为界构建最小可用本体，每个迭代绑定一个可量化的业务价值点，一个场景一个场景地把企业认知"长出来"。

核心落地挑战二：语义资产建而不用、用而不治。本体沦为文档资产，与数据、指标、AI 应用脱节。方案重点：璇玑 DataAgent 平台将本体做成运行时基础设施，以业务数据接入、本体设计、本体实现、本体消费四个步骤形成建模闭环，经 API/MCP 双通道对外提供语义服务；语义查询层统一对外服务，Agent 接入网关完成工具注册与业务上下文注入，治理控制台实现版本、血缘、质量的全链路管理；通过三方评审与 SemVer 语义化版本控制保障质量，通过 SFLM 反馈闭环让本体在使用中持续生长。检验标准只有一个：本体是否进入了 Agent 的运行时调用链。

核心落地挑战三：AI 输出不可解释、不敢采信。大模型直连数据仓库产生幻觉。方案重点：以本体作为业务认知契约约束查询生成与推理路径，语义混合检索使每条结论可回溯到本体概念、关系与规则，实现可解释分析。

方案重点总结：本体不是画出来的知识图谱，而是能被 Agent 执行的业务认知契约。落地成功的关键不在建模技术，而在增量建设、运行时供给、治理机制、反馈闭环四位一体的工程化体系。

演讲介绍

本次分享拟以物流异常处置为切入点，探讨如何将业务本体与 Agent Harness 相结合，设计面向物流任务的智能体系统。

首先，围绕订单、运单、车辆、线路、站点及异常事件，梳理业务对象、关系和规则，建立 Agent 理解物流业务的语义基础；其次，将运单追踪、延误评估、运力查询、改派申请等能力抽象为可组合的“业务原语”，通过 Harness 组织任务规划、工具调用、状态管理、权限校验和结果反馈。

分享将以“运输延误后的处置流程”为示例，讨论如何贯通业务理解、方案生成、人工确认与系统执行，并进一步探索处置经验的沉淀与复用，为物流 Agent 从问答辅助走向业务执行提供一种设计思路。

演讲提纲

1.用业务本体，建立 Agent 理解物流业务的基础

以订单、运单、运输任务、车辆、站点和异常事件为核心，梳理“谁承运、运到哪里、当前什么状态、受到哪些规则约束”。建模方式可参考业务本体对对象、属性、关系及动作的组织方式。
拟讨论的问题是：面对“这票货可能晚到，应该怎么办”，Agent 需要关联哪些业务信息，而不只是检索一段操作说明。

2. 从系统接口到业务原语，让 Agent 调用有业务含义的动作
尝试将底层系统能力封装为“查询运输状态”“评估延误影响”“查询可用运力”“发起改派申请”等可复用动作。
这里将“业务原语”定义为：具有明确业务含义、输入输出、执行条件和结果校验的可调用能力。 重点讨论如何把业务对象、规则与动作绑定起来，而不是仅给接口换一个容易理解的名字。

3. 用 Harness 串起任务执行，形成可控的处置流程
围绕任务拆解、上下文组织、工具调用、执行状态和结果检查，设计模型外围的运行机制；这也是 Harness 工程所关注的执行层问题。

听众收益

1.理解业务本体、业务原语与 Harness 在物流 Agent 中的作用。
2.了解如何围绕物流异常处置，让 Agent 从“回答问题”走向“执行任务”。
3.获得权限控制、人工确认和结果校验的设计参考。
4.了解如何沉淀和复用处置经验，持续改进 Agent 的业务表现。

落地挑战和方案重点

物流业务对象多、系统链路长、规则复杂，Agent 容易出现业务理解不准、工具调用不稳定、执行结果难校验等问题。