上一篇讲了怎样定义回访行动，以及 Agent 怎样围绕一次购车机会组织跟进简报。本篇换一个角度，回答一个更基础的问题：Agent 用到的这些数据、知识、工具连接，分别来自哪个产品，两个产品之间又是一种什么关系。

一句话概括：Dataphin 负责把企业数据与知识加工成安全、可信、可推理的企业知识——Data for AI；WinNexo 负责通过业务语义中心与大模型推理，让这些知识进入业务现场、被人与 Agent 使用——AI for Business。 前者解决「让 AI 理解」，后者解决「让 AI 参与业务」。执行产生的业务结果与客户反馈，经过治理回流，持续更新企业知识，形成闭环。

图：Dataphin × WinNexo 一体化架构（内部方案材料）——左侧 Dataphin 把业务系统与非结构化资料加工为有依据、可治理的企业知识，右侧 WinNexo 的业务语义中心、大模型推理与主动感知把知识用于业务流程；底部为业务结果经治理回流企业知识的闭环。图中分工为设计口径，不代表两个产品已按此完成集成。

两产品各自负责什么

沿图分左右看。

Dataphin 加工企业知识。 左侧输入是企业已有的两类信息：结构化数据来自 CRM、ERP 等业务系统与数据库；非结构化数据是文档、图片、音视频与互动记录。结构化一侧通过规范建模管理业务对象、活动与指标定义，形成指标与视图；非结构化一侧经知识图谱加工，提炼实体、关系与属性。两边都带知识治理——权限、来源、敏感控制——所以产出的是有依据、可追溯的企业知识，而不是各自为政的数据文件。

WinNexo 让知识进入业务。 右侧的业务语义中心集中管理规则、流程、知识与业务经验、上下文，把企业知识翻译成业务可用的语义；大模型推理在此之上做记忆与任务规划、评估与监控；语义事件、定时任务与 Webhook 支持主动感知与决策。最终通过人机协同执行，进入团队与业务流程——销售与管理人员的岗位、任务与审批。

分界线因此清楚：知识的组织与治理在 Dataphin，知识的使用与行动在 WinNexo。 一项销售任务需要的三种信息，恰好各自归位——

事实、语义和知识缺一项，任务就可能偏离。事实过时，会把已经下订的机会仍列为待跟进；语义不清，会把一家人的多条记录拆成多个客户；上下文缺失，则容易让顾问再次询问已经讨论过的问题。它们还有不同的更新节奏——订单状态随业务变化，指标口径需要团队确认，车型资料依赖版本——把这些信息连起来时，应保留各自的标识、时间及来源，让调用方知道自己正在使用什么。

一个业务问题怎样穿过两层

分工之后，关键在衔接。岗位、技能与工具怎样组织跟进任务，第四篇已经展开；本篇聚焦两个产品之间怎样衔接。

试驾结束后，销售顾问需要一份可以直接用于跟进的简报：机会进展到哪里，家庭里谁关心什么，下一次沟通应准备什么。这些问题不会只落在一边——订单状态在业务系统里，客户的表达散在沟通记录与产品资料里。即使分别接入了 AI，顾问仍然需要它们围绕同一次购买需求组织起来。

第一步，Agent 查询编排把问题拆成两路：一路走结构化查询拿精确数字，一路走知识关联找关系与证据。第二步，语义与知识服务层把两边查到的记录统一识别为同一业务对象——结构化表里的编号与知识图谱里的名称，指向的是同一个人、同一家企业。第三步，推理规则基于对象关系作出判断，同时保留证据与来源片段。第四步，结果融合返回：既有结论，也有可查看的依据。

映射到购车场景，同一份跟进简报走的就是同一机制：结构化一路查这次机会的下订条件、体验记录与回访安排，来自 Dataphin 加工的业务表；知识一路检索上次沟通中的车型顾虑与适用产品资料，来自沟通材料和文档的图谱化结果；语义层把多条记录统一归到同一购车机会、同一家庭——这正是本系列一直在讲的本体作用；推理给出「尚未下订、存在未解决的车型顾虑」的判断，证据是沟通原文与资料片段；融合后形成简报，顾问核对后进入业务流程。

为什么必须两个产品配合？单靠结构化查询，查不出散在沟通记录里的顾虑与关联；单靠知识检索，给不出订单状态这类精确事实。衔接的关键动作是语义层统一识别业务对象——编号对名称、事实对依据、数字对关系，都靠同一套业务定义对齐。这也是架构图中间那一层存在的理由。

已确认的三条接入通道

上面是设计中的整体关系。目前已确认的落地通道有三条，分别服务于语义建设、知识检索与工具调用。

逆向建模：从已有资产生成语义定义。 Dataphin 中已有模型、元数据、SQL 和血缘，为理解数据含义提供依据。WinNexo 支持基于 Dataphin 数据进行 AI 逆向语义建模：完成配置后利用这些资料生成候选语义定义，再由团队审阅、校验和确认发布。可读取的 Dataphin 资产与血缘范围，以产品文档所述为准，使用前应按所选数据源核对可读取的资产类型。例如已有「客户编号」究竟标识个人还是家庭，试驾记录怎样关联一次机会，都可以结合已有资料核对；候选定义仍应回到业务记录确认含义。准备采用这类连接时，可先查看 WinNexo 的数据源配置指南，核对关联对象、输入范围和相应授权。具体如何圈定范围、检查候选、修正模型和验收查询，下一篇单独展开。

外部知识库：知识服务进入岗位检索。 Dataphin 的知识服务 API 可以注册为 WinNexo 外部知识库。连接配置填写 API 网关域名与 Dataphin 应用凭证，知识库可关联岗位，检索时调用相应知识服务。资料维护与查询入口因此有明确分工。

图：WinNexo 外部知识库的 Dataphin 连接配置——凭证字段为空，截图展示接入方式；具体知识服务需按应用授权配置。

在销售任务设计中，应先确定 API 提供什么内容，接受哪些查询条件，返回哪些记录或来源。比如，以车型及问题为条件提供知识依据，是一种可以设计的服务目标；是否得到适用结果，需要检查具体服务的模型、数据和配置。注册连接本身不意味着已完成某一具体销售服务。

CLI：技能组织已授权命令。 WinNexo 也可调用 Dataphin CLI。技能可以组织已授权命令，辅助查询或完成相应工作，例如查询项目或表的元数据、执行已发布的数据查询。需要哪类命令、调用什么资源、返回结果如何进入任务，都应结合具体技能和权限配置。

图：三种已确认接入方式——逆向建模读取建模依据、岗位外部知识库检索知识服务、技能与应用连接调用 CLI 命令；箭头表示从 WinNexo 发起读取或调用的方向，具体查询与销售任务仍需配置和验证。

三条通道职责与授权各不相同，不应合并成一条笼统的「全面打通」连线：外部知识库用于把知识服务提供给岗位检索，CLI 提供相应操作能力，逆向建模服务于语义建设。它们分别回答建设、检索和工具使用中的问题。

业务人员在 WinNexo 中的岗位和资源授权，与 Dataphin 中的应用及资源授权分别管理。接入时应对应检查业务人员使用范围与实际调用身份，既明确谁能使用岗位，也明确该连接可以读取或操作哪些资源。职责划分因此落实到具体配置，而非只停留在图上。

用同一次机会检验协同是否成立

一套架构是否能工作，可以从一份简报倒查。

先用已知机会检查名单范围与去重，核对体验时间、当前负责人及下订条件。再从建议回到沟通原文和产品资料，检查机会归属、车型及版本。最后检验交付能否用于工作：建议应落到具体个人角色及待解决问题，材料缺失则列出待核对事项，后续记录区分计划、实际联系和购买结果。

发生错误时，沿职责定位。名单错误，检查模型定义、数据加工与查询；资料不适用，检查知识来源和检索条件；建议没有落到具体工作，检查岗位职责和技能；操作结果不明，检查相应业务服务和完成证据。

这种验收也保留了业务变化的时间关系。一份上午简报记录当时的状态，下午下订属于新的事实。后续任务需要读取更新后的记录，而不是继续沿用旧简报中的判断。实际联系后产生的新沟通材料，也应按企业约定归档、关联机会，再用于下一次分析。

因此，连接验收可以先围绕一个已知机会完成。名单结果、知识来源和任务产出能够逐项对应，错误也能定位到负责的模型、服务或技能，这套分工才具备实际使用基础。后续实践篇将用完整任务记录检验它，价值验收篇则进一步区分任务表现与经营效果。

希望了解数据模型与知识服务的产品能力，可从 Dataphin 产品介绍继续阅读。希望讨论企业已有数据、文档知识与业务任务如何配合，可以通过瓴羊官方联系入口说明 Dataphin 与 WinNexo 的相关需求。

继续阅读：06 本体与逆向语义建模：如何从已有数据提炼业务定义？

回顾：03 Dataphin与企业本体：业务语义怎样落到数据模型与知识图谱中？ · 04 从本体到行动：业务语义如何帮助 Agent 推进销售工作？

资料来源

Dataphin 规范建模：已有业务模型与指标定义的管理。
Dataphin 知识查询与 SQL 模式创建 API：图谱查询及数据服务配置。
WinNexo 数据源配置与审阅并保存生成结果：Dataphin 关联、候选审阅、校验与发布。
WinNexo 语义中心与自动化任务：业务定义与任务组织。

系列作者：莫疑