从概率生成到受控执行：图模融合如何让企业级 Agent 敢执行、可审计

11 月 3 日，国家发展改革委在发布会上明确释放最新信号：将深化拓展“人工智能+”行动，以落地应用牵引技术创新，同时加快推进人工智能全生命周期安全标准与“监管沙盒”建设。回溯至 10 月 9 日，中共中央、国务院印发《关于发展新质生产力的意见》，明确提出要“构建技术监测、风险预警、应急响应体系，确保人工智能安全、可靠、可控”；而在此之前的 5 月，国家网信办等三部门联合印发《智能体规范应用与创新发展实施意见》要求：智能体执行操作不得超出用户授权范围，要发展“规则内嵌、行为围栏”等技术，建立重要应用场景智能体行为“可验证、可追溯”机制。

这些政策共同指向同一个核心命题：AI 要真正进入生产环境，先要回答三个问题——谁授权、能不能追溯、出了问题谁负责。

这正是海致一直在回答的问题。我们的核心观点是：当模型能力到达边界，企业需要一套可查询的事实结构，把 AI 从“概率游戏”送进“受控执行”。这套结构不依赖模型参数的堆叠，而是把行业经验编码为人与智能体共同遵守的定义——数据在哪、是什么意思、能做什么操作、谁在什么条件下可以做，让 AI 站在一张可查询、可校验、可回滚的事实结构上干活。

本文将从模型的边界、图模融合的分工、业务本体的建模方法、可审计智能的落地路径四个层面展开，分享海致在产业 AI 落地上的思考与实践。

01 模型的边界：长链任务里，90% 的成功率会坍缩成 12%

大模型“读不懂”企业：它擅长语义理解与生成，而企业的业务数据大量躺在关系表及其背后的确定性计算里，这是数据形态上的鸿沟。

从另一个侧面看：即便数据被读懂、被准确地送进上下文，企业真实任务的特点，也会让大模型“纯概率生成机制”的方式难以直接胜任。

根本问题，出在训练目标上。从学术上说，在当前训练目标与评估范式下，模型的“幻觉”无法被根除：预训练的目标是给出答案，而不是表达未知；评估又往往奖励“猜一个”，而不是奖励“承认不知道”。因此，“幻觉”不是偶发bug，而是概率生成机制的结构性副产品，需要外部事实结构兜住。

这在闲聊场景无伤大雅，但放到企业生产环境里，问题会被成倍放大。企业真实任务动辄包含 20 甚至 30 个决策节点。假设单个决策点模型的成功率是 90%，经过 20 次决策后，整体成功率只剩约 12%（0.9 的 20 次方约等于 0.12）——这就是长链任务的“指数坍塌”。真实系统中若有审批、回滚或并行分支，衰减会有所缓解，但趋势不变。

更麻烦的是，模型的决策过程是不可预估、不可审计的。首先，一个企业如果把自己所有的数据都交给大模型，那么企业本身就丧失了竞争力。其次，整条链路也不可信——AI 在什么时间、因为什么原因、调用了哪些数据、改了哪些记录，企业说不清楚，审计就无从做起。对于政务、金融、能源等准确率与合规敏感的场景，这样的链路是不可接受的。

具体拆开，企业级 Agent 面前横着五道坎：

训练目标错位：模型学的是给出答案，不是表达未知；

小模型为主：出于数据安全考虑，企业私有化部署多以小参数模型为主，能力进一步受限；

上下文丢失：企业数据被拍平成纯文本喂给模型，对象之间的关系没了；

无法核验：推理链没有事实依据，对错分不清；

不敢执行：没有权限与状态约束，动作不可控。 

基于此，海致构造了基于图的 AI 引擎，或者叫 Harness。它要应对的，还有一个常被忽视的现实：企业内部早已有自己的业务系统、小模型和规则引擎。如果把所有数据归拢到一个大模型，改造量巨大，原有系统的能力也被闲置。真正需要的，是把这些已有能力调动起来，而不是推倒重来。 

所以，结论只有一个：模型能力之外，企业需要一套可查询的事实结构，替模型兜住它兜不住的部分。 

02 图模融合：图谱管事实，模型管智能

在这个思考之下，海致提出了图模融合。

图天然贴合现实世界的建模：金融里的账户与转账、电信里的手机号与通话，本来就是图的形态。那么，我们就可以用图去负责对象、关系、状态、权限的建模，用模型去理解、规划以及去做候选动作的编排。这样，可以检查和审批交互质量。

对企业和个人的数据做建模，不需要完全规整，只需要抽取出知识里存在的概念。图能把“概念”和“实例”对应起来：比如个人资料里有很多数据库相关知识，有存储引擎、元数据引擎，有各种实例，但对于“图数据库”这个概念，只需要抽象出现一次，其下再挂各种具体实例。这很像百度百科对某一个名词的解释方式，包括名词的概念、观点、实例。

模型不可能在预训练时见过企业的全部数据。有了这层结构，当模型拿到一个问题时，它可以先到图里找到相关概念及其解释、实例的含义，以及对应能处理接口，从而知道“这个问题涉及哪些数据、这些数据是什么意思、能用哪些接口处理”。

落到职责上，这个解法可以拆成三句：

图谱管事实：给每个对象稳定 ID 与状态版本，覆盖对象、关系、状态、权限；

模型管智能：做语义理解与任务拆解，负责理解、规划、候选动作；

融合管落地：做推理核验与执行编排。

在 AtlasGraph 的实践中，图谱事实层始终是投入最重的一层，这也说明企业级 AI 的重心在哪里。

传统的 Agent 在开放工具集里自由组合：环境里挂了 116 个工具，模型每次都要在 116 个候选里搜索、试错。而在图模融合的架构里，任务的语义、数据的位置、每个工具的前置条件和产出结果都预先定义在图上。

同样是处理一个 PDF，跟它关联的 skill 可能只有两三个，候选工具集更少；模型动手之前就知道可以选择哪些工具、操作这个工具会产生什么结果。这套分工的关键机制，是把模型的搜索空间从“开放工具集里的无限试错”收敛到“本体约束下的可枚举候选集”；“有限状态机”是工程隐喻。候选集收敛，每一步成功率随之提升，长链任务的“指数坍塌”就被打断了。

模型不是变得更聪明了，而是被放进了一个更容易做对的结构里。

从更宏观的视角看，人类解决任何问题——无论是一个技术难题还是一个业务流程——本质上都可以抽象为一张图：起点是问题，经过一系列关系节点，最终到达目标。

海致的解决方案本身也是一张图。当问题的形状和解决方案的形状同构时，我们就有了确定的建模语言和确定的执行路径。

这也是为什么 Harness 或 Agent 的发展从最初的 Open Tool 到 Prompt Engineering、Context Engineering，再到今天的 Graph Engineering，本质上都希望将“如何思考、如何解决问题”的方法论沉淀下来。

那为什么最终选图做底座？分两层看

就单一场景而言，本体未必非图数据库不可——关系表能承载，向量索引也能承载，选型取决于查询与计算需求。

真正的问题出在本体越建越多之后：不同场景各建各的，彼此无法互认、无法复用，本体就退化成了资产管理问题。所以企业必须先建一层大家互认的“图语义”，就像当年在数据仓库里建 DWD 公共层，用统一清洗和口径对齐来约束语义。

把几类数据库放进“事实约束强度×关系复杂度”的坐标系里，这个选择就更清楚了：低约束、低复杂度的场景，向量库足够，因为它擅长语义检索和片段召回；低约束、关系复杂的场景，就用关系库，因为它适合低跳数的表连接和事务；时序库解决时间序列上的多版本与序列查询问题；而高约束、多跳的场景——既要多跳路径穿透，又要权限校验、状态快照，图数据库是最直接的表达方式。SQL当然也能处理连接与递归，但选图为的是直接表达多跳依赖：把对象边界、可达路径、前置依赖变成可查询的结构。

而多模融合，解决的是另外两件事。

第一是向量。企业数据大量以自然语言形态存在，把图上的实体向量化、建立索引关联回图节点，模型就能“用语义找到节点，再顺着图走关系”。

第二是时序。企业的审计通常按周或月级别进行，如果数据被 AI 随意改写，几周之后就无从对账。而且多数人面对“是否允许修改”的提示，可能并不细看就直接选了“是”。时序让每一次写入都成为新版本而非原地修改，图的任何一个时间切片都能重新可见——AI 在什么时间段调用了什么接口、用了什么工具、改了什么数据，全部可以回放。

这也是企业使用 Agent 的底线：不是 Agent在控制人，而是人控制 Agent。

用一句话概括 AtlasGraph 的查询分工：图查路径，向量找语义，时序定格版本——一套存储底座，三种查询视角，在同一份数据上各司其职。底层是同一套存储结构，上层再提供检索算子与管理策略，让每一个时间切片的图都能被高效查询。但边界同样要画清楚：相似度高不等于事实为真，更不等于有权限。

放到 AI 工程的演进脉络里，这一层的位置也更清楚：Prompt Engineering 解决“怎么问”，Context Engineering 解决“给什么”，Harness Engineering 解决“如何驾驭模型”；Graph Engineering 则解决“多个 Agent 如何以图结构组织任务、协调组件、管理运行时状态”。图谱与本体是这一层的事实底座，让编排不仅连得起来，而且每一步都可校验、可追溯。模型负责聪明，结构负责可信。

海致的 harness 与通用 harness 最大的区别，就是底座——底下是不是一张可查询、可约束的图本体平台。

03 业务本体：把“谁在什么条件下能做什么”写进图里

分工定了，接下来的问题是：图上放什么？

答案是业务本体。

这里需要把两个概念分开：知识图谱描述的是“哪些事实彼此关联”，回答“是什么”；企业本体则进一步定义“这些关联意味着什么、可以触发什么行为”，回答“怎么做”。海致把行业经验表达为一组本体定义，人和智能体都按定义操作——它说明业务里有什么、能做什么、谁在什么条件下可以做。

把数据的归属、角色的权限、可执行的行为这三件事都把控住，系统的准确率会明显提升：既能跑在模型训练时没有见过的业务上，也能跑得更好。

本体之于企业数据，就像文件夹之于个人文档。人给文件夹命名，本质是在做知识归类，告诉未来的自己”这里面存的是什么”。对文档进行归类、划分多个文件夹、每个文件夹又有它自己的多个子文件夹，就形成树的形状，而树就是一种图。

到了智能体时代，同样的事情要为 Agent 再做一遍：告诉它取到的数据是什么含义、属于谁、可以执行什么操作。

实际上，在人类使用企业系统时，大量经验是存在脑子里的，我们知道点哪里、复制什么、下一步去哪；但模型没有这些经验，所以必须为数据、也为可操纵的接口，做一层机器可读的语义认知建模。

建模后，模型通过接口调用处理数据时，就能感受到：它所操作的并不是离散或者碎片化的数据和接口，而是规整的一张业务图，从而能很好地完成预训练时没有注入知识的场景。

这个思路不限于企业，个人整理资料、使用 Agent 时同样适用。

对企业而言，还有一个好处：这些知识或者业务本体存在企业内部，是企业保持竞争力的根本。这也是现在说的主权 AI 的思想。

这层建模在 AtlasGraph 上分为三个模型。

语义模型，回答“业务里有什么”。先定义类型，再落实例：比如工序是一个对象类型，属性包括状态、负责人，关系包括”使用设备”、“依据文件”；实例化之后就是工序 OP-204，状态“待检验”，使用设备 EQ-17，依据工艺文件 R3。设备 EQ-17 的身份由设备台账提供，工艺文件 R3 的修订号由文档系统管理——每个对象实例都有稳定身份，关系带版本，指向具体对象与修订版本。

为什么要费这个劲？因为在企业内部，一个工序往往只剩一个代号。如果图上只有 OP-204 这个编号，模型并不知道它是什么、由谁负责、该配哪些设备。建了本体，问题就能反过来问：这套工序要用哪些设备、依据哪些工艺文件？模型顺着“使用设备”、“依据文件”两条边查下去，答案和依据一起出来。

更关键的是，这个查找过程是可以显式化给客户的。用户不必在海量碎片化文档里翻找模型用过的资料，他看到的是一条路径：从工序到设备、再到工艺文件。反过来想，如果还得靠人把碎片化文档通读一遍才能审计，那这件事让人来做就行了，何必再上 Agent。

运行模型，回答“什么操作可以发生”。动作定义包含输入参数、前置条件、状态变化和操作授权。以”确认工序完成”为例，对象引用、预期版本、检验记录显式输入，前置检查要求检验结果合格、必要记录齐全，授权要求当前主体具备该工序的确认权限。只有三个条件全部通过，状态才从“待检验”流转到“已完成”。只读计算函数与写动作分开，最终校验和事务由业务服务执行。

举一个日常的例子：用户说“我要充话费”。模型先在图上找到“话费”这个实例，它关联到手机号，并关联到“充值”接口；接口定义写明了需要哪些参数、会产生什么结果。模型拿到这些信息，就知道该补齐什么参数、调用哪个接口，而不是在一堆工具里凭感觉试错。这也有助于解决企业里的一个实际麻烦：不同部门使用系统和接口往往非常相似，只有在本体里写清楚各自的归属与含义，模型才不会张冠李戴。

数据源映射，回答“数据从哪来”。这是很多企业最关心的问题：上本体，是不是要把所有数据搬进图？海致的答案是否定的。智能化要循序渐进，本体的正确用法是在上层建立业务认知，把 ERP/MES 的表做字段映射与身份归一，把技术文档做解析分块与关系审核，把设备运行数据做对象绑定与时间对齐；来源与访问标签随事实保留。

顺序上也有讲究：先结构化、后非结构化。统一语义必须唯一、确定，而业务系统里数据的唯一性天然优于散落在文档中的描述，所以先把结构化事实对齐，再让文档内容往上靠拢。模型遇到问题时，通过语义映射自行选择数据源、调用对应接口取数，而不是把企业所有数据归拢到一处。

以关系库为例，只要表结构和字段比较规整，就可以先对数据采样，再由模型做语义总结，弄清这个数据源属于哪个部门、能解决什么业务，然后把这些语义关联进图，形成数据源的语义图。之后遇到问题，模型沿着语义图找到数据源和对应的表，再调用已有的 SQL 或接口取数即可。这个过程不能完全依赖 AI：模型生成的总结，最终仍需要业务方接入审阅和修改，也需要业务方愿意在这件事上投入。这是改造量最小的承载方式。

这套思路也解释了一个行业现象：为什么 AI 在编程场景落地最好，别的企业场景却相对缓慢？因为代码的“本体”早已被内化——函数、变量、声明、结构体、文件，模型在预训练里见过海量这类强约束结构，写代码等于在一张现成的语义图里行动。这也与很多人的 Vibe Coding 体验吻合：任务很快“做完”，却发现一些功能不可用，原因往往是生成的代码太多、人没有真正弄清里面的结构。相比之下，AI 生成文档、PPT、图片之所以顺利，是因为它们多半是相对独立的单个任务，复杂度有限。

其他业务缺的恰恰是这层本体。源码或设计资料不等于本体，但如果企业已有这些材料，AI 可以辅助生成本体初稿，再由业务方校正——初稿可以辅助，定义和校正仍靠人。这也正是海致团队的共识：能把程序写好，前提是人自己能把系统设计得足够严谨。本体建设，就是把这种“人的严谨”显式化，交给模型的过程。

更深一层的原因是：现有的大量系统本来就是按照“人来使用”设计的，使用经验存在人的脑子里。要让 AI 真正用好它们，就得把这些经验显示地画出来、告诉 AI。

有了本体，Agent 的执行上下文也随之改变。它不是简单的文本拼接，而是带版本号的结构化事实集合，包含四类要素：对象引用（稳定ID与来源系统）、状态快照（如stateVersion=37, validAt=10:31）、版本集合（如 ontology=2026.09, policy=risk-v17）、证据来源（每条事实挂原始记录）。

构建分五步：限定范围、向量召回（相似度仅用于排序）、时间快照、版本固定、打包输出。版本固定带来四个性质：可复现、可审计、带版本、可回滚。

其中有一条工程红线：不能把未授权材料先交给模型再过滤——权限必须在构建上下文时就生效。

04 可审计的智能：越用越强的企业资产

图模融合并不是为某一两个场景定制的方案。在政务、金融、能源等领域，这套架构都已经有规模化的落地。

这里挑两个形态差异比较大的案例：一个面向动态的物理世界，一个面向跨部门的治理协同，正好可以看同一套底座如何支撑完全不同的业务。

案例一：低空经济

在低空经济政策推动下，某低空经济先行城市启动全空间智能无人体系创新应用示范项目，海致承接其核心数据底座建设任务。

这个场景的痛点是典型的“数据孤岛”：设备信息、运营企业资质、飞手执照、空域审批分散在不同业务系统，监管难以快速厘清”谁在飞、飞什么、在哪飞”；而一次飞行的背后，串联着设备归属、飞手资质、运营许可、空域审批状态、实时气象等多重关系，传统关系型数据库在多跳关联查询上力不从心，监管决策却需要秒级响应。

海致的解法是：构建统一的无人设备图本体模型，把设备、运营企业、飞手资质、飞行任务、空域审批、航路规划深度关联，形成“一机一档、一飞一档”的全生命周期数字孪生——设备归属可追溯、资质可核查、任务全貌可还原，为违规飞行调查与安全事故溯源提供数据支撑。

现实世界里的设备、任务、空域每变一次，图上就更新一次；模型不需要修改任何内容，就能基于最新的本体和实例数据把任务跑完。这是从抽象数据处理走向复杂、动态物理场景的一次从零到一。

图模融合在这里同样“分工”：大模型负责交互友好性，监管人员用自然语言完成复杂查询；知识图谱负责事实约束，保证监管场景下结果的准确可靠。Atlas 图平台的元数据知识图谱能力，还构建了统一的数据要素目录与血缘关系图谱，让数据资产可视、可管、可追溯，为数据共享交换与市场化交易打下基础。

案例二：政务知识本体

民政、市场监管等部门的数据各自孤立，跨部门分析长期依赖人工传递；政务规则散落在法规文本与业务系统里，大模型“能读”但无法结构化推理。统一语义本体把全市数据织通，把规则编码为图谱，AI 的判断从概率猜测升级为规则推导。

落到使用上就是一条闭环：市民提出一个民生问题，系统智能导向应受理的部门，找到该部门对应的数据源与关联接口，模型自动把这件事办完。

更关键的是演化路径：局部图的空间有限、业务链路有限，每一条成功的查找链路，都可以打上标签沉淀回图——下次遇到同类场景，Agent 不再重新决策，直接按已验证的路径调用接口。高频场景沉淀得越多，系统就能越用越强，最终从垂直大脑成长为城市治理的 AI 操作系统，成为持续增值的企业智能资产。

这两个案例还指向同一个方向：今天建成的本体，在建成那一刻是静态的；而真实业务里的对象关系是活的——设备在增删、任务在流转、部门职责在调整。动态本体需要的不是一次性建模，而是持续的知识抽取与更新能力：每一次变化都作为新版本进入图谱，由时序能力保证“从何时到何时成立”可以被追溯。这也是本体建设真正的难点所在——不是把图画出来，而是让图跟着业务一起长。

落地过程中的另一个硬问题是权限。海致的做法分三层：

第一层，利用图数据库原生的权限能力，可以把节点及其关联边打包成一个授权单元；Agent 以当前用户身份访问时，只能看到被授权的“点+边”。A 部门和 B 部门能访问的数据本来就不同，个人也一样：希望 Agent 能读什么、能改什么、不能碰什么，都要在本体里定义清楚，再借助数据库自带的权限机制做强约束。

第二层，把写操作归纳为追加而非原地修改，新状态先在系统内可见，落库前需人工审核审批；

第三层，在本体上把动作与用户节点关联，按白名单、黑名单加人工审批约束执行。

当然，这套体系也有边界：如果拥有权限的人蓄意破坏数据，任何技术都无法根绝——这和数据库管理员可以篡改数据是同一个问题。技术能做的，是让每一次操作可审计、可追溯，把“人确认负责”变成默认设置。

结语

从概率生成到受控执行，从无限状态空间到有限状态机，从文本拼接到带版本的事实集合——企业级 Agent 落地的关键，正在从“让模型更聪明”转向“让模型站在一张可查询、可校验、可回滚的事实结构上干活”。

而贯穿这一切的枢纽，是业务本体。它把行业经验——数据在哪、是什么意思、能做什么操作、谁在什么条件下可以做，编码为人与智能体共同遵守的定义。多模数据在图上积累，本体与动作沉淀在图上，Harness 编排执行，走向持续的业务运营。

AI 不仅要能帮人完成任务，更要可审计、可追溯——在人能够确认负责的前提下，它才有真正的业务价值。

这也解释了当下行业的一个观察：通用场景的 Agent 产品层出不穷，真正在企业业务级别落地的应用却不多。政策已经把“安全、可靠、可控”和智能体行为的“可验证、可追溯”写进了国家要求，接下来比拼的，是谁先把企业的行业经验，变成 AI 读得懂、也改不了的那张图。

*本文基于海致科技副总裁、海致院士工作站图模融合课题负责人王铮在某运营商内部技术分享活动的演讲整理撰写

本文来自微信公众号“海致科技”，作者：海致，36氪经授权发布。