国家发改委：AI+落地应用牵引，监管沙盒与全生命周期安全标准提速

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 读得懂、又动不了的那张图。

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