Published
- 31 min read
名词、动词与权限：AI 时代的"本体层"
前段时间我看了一段访谈视频。Palantir 的 CEO Alex Karp 坐在那里，用一种接近失态的语气谈论企业 AI，说”有些事情已经彻底错了”。视频的传播点是他的情绪，以及他对几家前沿模型公司的不满。但真正把我拽住的，是他反复提到的一个词：ontology。
他说，大语言模型要在企业环境、战场环境、受监管环境里真正可用，必须有一个”应用层”，而他们把这个层叫做 ontology。他说这一层让模型变得”安全、有用、精确”。他说现在所有人都在抄这个东西。
我对他的商业主张没有兴趣，那部分是一个比较简单粗暴的推论，本文不处理。我也不打算评价被他点名的那几家公司。需要说明的是，我本人是 AI 的重度使用者，我接下来要谈的不安，是我自己的不安，不是一个抽象的行业议题。
但那个词卡住了我。因为我在几个月前的一次企业实习里，参与过一段关于 enterprise data model（企业数据模型，简称 EDM）的讨论，并且在那之后，我自己动手做了一个独立项目，把我理解到的东西完整地实现了一遍。当我去查 ontology 到底是什么的时候，我发现我几乎不需要学习。我只是在看自己造过的东西，被换了一个消费者。
而这个”换消费者”的动作，恰好回答了我很长一段时间以来一个说不清楚的问题：在大规模使用 AI 的未来，敏感的东西到底该怎么办？
这篇文章不是一篇结论性的文章。它是一次思考过程的完整记录。我想把从”看到一个词”到”重新安置一个疑问”的整条链条留下来，因为其中好几个分支，我认为都值得将来单独展开。
如果要先把落点说出来，那就是这一句：
模型能力可以被时间和金钱堆出来，所以它会持续变强、持续变便宜。而本体层的内容不是技术，是你自己的业务，没有任何供应商能替你堆出来。企业真正需要意识到的，是这道选择题的存在本身。
下面是我怎么走到这一句的。
一、这个词到底是什么
先做一个必要的澄清，否则后面全是误会。
Palantir 说的 ontology，不是哲学意义上的本体论，也不是 OWL、描述逻辑那一支的知识表示。它在血统上更接近领域驱动设计里的通用语言（ubiquitous language）、知识图谱、以及工作流引擎三者的融合。我在下文里把它称作本体层，但请始终记住这个限定。
按照 Palantir 自己的文档，本体层是”组织的运营层”，它坐在被接入平台的数据资产之上，把这些资产连接到现实世界中的对应物。它由两组要素构成：
语义要素（semantic elements）：对象类型（object types）、属性（properties）、链接类型（link types）。这是企业的名词——哪些实体存在，它们有什么特征，它们之间是什么关系。
动力要素（kinetic elements）：动作类型（action types）、函数（functions）、动态安全（dynamic security）。这是企业的动词——谁可以对这个对象做什么，前置条件是什么，会产生什么副作用，写回到哪个系统，留下什么痕迹。
他们的文档里有一句话概括得很准：本体层描述的不是数据，而是企业如何决策与行动。
名词 + 动词 + 权限。这就是全部。听上去朴素得有点可疑，但正是这个朴素的结构，让我在十分钟里认出了它。
二、我为什么能在十分钟里认出它
从局部地图到绝对坐标系
在那次实习里，我花了一段时间去理解企业内部几个系统之间的数据流：一个负责接收外部提交的入口系统、一个负责搬运的中间层、一个作为核心记录仓库的系统、一个负责转换和翻译的集成中间件、以及若干个下游的运营系统。数据在它们之间不停流动，人工干预和自动流程混杂在一起，人工步骤用来填补那些没有被自动化打通的缝隙。
看着看着，我形成了一个假设，并且把它写进了当时的沟通邮件里：
虽然数据在多个系统之间持续流动，但同一个业务概念在这些系统里，可能并没有被一致地表达——在命名上、在结构上、甚至在含义上。
如果这个假设成立，后果不只是集成时要多做几次翻译。更关键的是耦合：当你要新增一个字段或者调整一段逻辑时，语义和结构上的不一致会让一个局部改动被迫扩散成跨多个系统的协同改动。在小规模下这是可以忍受的摩擦；随着系统和数据复杂度增长，它会变成一种结构性约束，直接限制未来的可扩展性。
当时我给自己找了一个比喻，来理解 EDM 到底想干什么：
每个系统都在维护自己的一张”局部地图”。这些地图在各自的范围内都能用，但它们建立在各自的相对坐标系上。当你试图把这些地图拼在一起的时候，缺少一个统一的坐标系，使得对齐变得极其困难。EDM 像是在这些地图之上，引入一个共享的”绝对坐标系”，让不同的系统可以对齐到同一个空间结构上，同时仍然保留各自的实现。
这个比喻我至今认为是准确的。它抓住了语义层的本质：不替代局部系统，而是给它们一个共同的参照。
但它有一个缺口，而这个缺口正是本文的转折点。
坐标系只回答”在哪儿”，它不回答”能做什么”。
一个绝对坐标系可以告诉你，A 系统里的 case 和 B 系统里的 file 指的是同一个东西。它不告诉你，谁有权把这个东西从”待处理”改成”已完成”，改之前要满足什么条件，改完之后哪些系统需要被通知，以及这次改动应该留下什么痕迹。
本体层比 EDM 多出来的，正是动词。
我的项目里其实已经“长”出了动词
在那次讨论之后，我意识到停留在概念层面并不足以让我真正内化这些东西，于是我做了一个独立的实验项目（Enterprise Integration Lab，代码与完整文档在我的 portfolio 里）。它是一个刻意做成行业中立的企业集成模拟：一个入口门户、一个事件队列、一个后台 worker、一个规范化的 canonical 语义层、一个下游运营工作流系统、一个文档仓库、以及一套语义血缘与审计记录。
当我回头用本体层的语言重读自己的代码，对应关系几乎是一一映射的：
| 本体层的原语 | 我项目里的实现 |
|---|---|
| 对象类型（名词） | canonical.business_objects |
| 链接类型（关系） | canonical.lineage 血缘记录 |
| 动作类型（动词） | PATCH /operational/cases/{id}/status + 受限的状态迁移白名单 + case_status_history |
| 写回与状态传播 | OperationalCaseStatusChanged 事件 + worker 异步同步回 canonical 层 |
| 可审计性 | sync_logs + 状态变更历史 |
| 动态安全（对象级权限） | 缺失 |
最后一行我会在后面专门谈。先看倒数几行。
我当时设计的状态迁移是这样的：合法迁移只有 open → in_progress、open → rejected、in_progress → completed、in_progress → rejected，其余一律拒绝；每次变更强制写入变更前状态、变更后状态、变更人、变更原因、变更时间；变更完成后发出一个集成事件，由 worker 异步地把状态传播回 canonical 层，并留下血缘记录。
这在结构上就是一个动作类型：一个类型化的动词，带前置校验，带声明式的副作用，带审计尾迹，带异步写回。我当时并不觉得自己在做什么特别的事，我只是觉得”不能让人随便把一个已完成的 case 改回未开始”。
还有一处更精确的击中。项目早期，我把用户在表单里选的客户和协议信息，直接嵌进了请求描述的自由文本里。功能上完全可以跑通。后来我把它们提取出来，变成结构化的 UUID 外键，并在项目笔记里写下了当时的教训：
文本不能替代关系。
现在回看，这句话几乎就是本体层的定义性动作：把隐含在自然语言里的语义，提升为结构化的、可以被机器无歧义引用的关系。 我是在自己踩坑之后写下它的，不是从任何人那里读来的。
结构没有变，服务对象变了
所以我和这个概念的关系，不是”我的项目是它的简化版”，也不是”它是我的项目的延伸”。准确的说法是：
结构是同一套，但消费者换了。
我的 canonical 层是为系统与系统之间的互操作而建的。它的消费者是另一个系统。那个系统有确定的 schema，有确定的行为，传错了参数会抛异常，不会自作主张。
本体层是同一套骨架，但它的消费者变成了一个没有组织记忆、没有隐性知识、并且不应该被默认信任的执行者。
这个替换看起来轻，但它改变的是整个信任模型。
人类操作员是自带隐性语义的。一个做了五年的老员工知道，运营系统里的 case 和内容仓库里的 file 说的是同一件事；他知道状态卡在某个值意味着要人工打电话；他知道哪个字段在月末不能碰。这些知识活在人的手上，不在任何系统里，运行时由人当场补齐。
正因为如此，企业过去可以长期容忍语义模型停留在文档层——因为执行者是人。
大模型没有这层组织记忆。你把原始 schema 甩给它，它会做出语法正确、语义错误的操作，而且非常自信。
于是语义层从”设计期的治理文档”，变成了”运行期的执行接口”。 这就是本体层相对 EDM 的真正跃迁，也是 Karp 口中那个”应用层”的技术实质。
三、它把我说不清的不安，拆成了三个能问出口的问题
我之前的不安是模糊的。它大概是这样一种东西：如果我把 AI 大规模引入工作流，那么公司里那些敏感的东西怎么办？
这个问题之所以让我难受，是因为它问不出口。它太笼统了，笼统到无法被处理。
本体层这个概念对我最大的价值，不是它给了我答案，而是它让我把这个问题拆成了三个可以分别回答的问题：
一、模型能看到什么？ 二、模型能改什么？ 三、这件事在哪儿做、由谁做？
这三个问题不是行业术语，也不是 Karp 的划分。它是我为了拆解这个概念，自己搭的一个分析框架。它的价值在于，这三条各自有各自的答案，混在一起就没有任何答案。
能看到什么
答案的两端是：一端是把原始的表和 schema 整个甩给模型；另一端是模型只能看到被解析过、被裁剪过、被授权过的对象和属性。
本体层在这一条上是有实质作用的。模型拿到的不是表，是对象。 敏感属性可以在语义层就根本不进入上下文——不是被加密了，而是从未出现在模型的视野里。
Karp 那句听起来很像营销的”safe because it doesn’t touch your underlying data”，真实含义就在这里。
回看我自己的项目，这一条其实早就有物理实现，只是我当时的理由完全不同。文档仓库那部分，二进制文件进对象存储，关系数据库里只留元数据：文档 ID、关联的提交 ID、关联的请求 ID、文件名、文档类型、存储键、上传时间。业务逻辑只读元数据。
翻译成 AI 语境：一个 agent 可以基于文档的元数据完成路由、分类和判断，而完全不接触文件内容本身。 我当时写下这个设计的理由只是”不要把二进制混进业务表”。同样的设计，在新的信任模型下，含义完全不同。
还有 reference 层。我把客户、协议、请求类型、团队约束成受控的引用数据，表单只能从下拉框里选，不允许自由输入。当时的理由是防止用户填进上游系统里根本不存在的值。在 AI 语境下，它变成了另一个东西：约束模型输出的落点。 AI 的归一化结果必须落进一个已知的、封闭的集合，否则被拒绝。
能改什么
答案的两端是：一端是给模型数据库写权限（灾难）；另一端是给它一组声明式的、带前置校验的、带审计的动词。
这是本体层的动作类型在做的事。模型不能执行任意操作，它只能提议一个已经被声明过的动作，参数是类型化的，由确定性的代码校验之后才执行。
这意味着幻觉无法变成一个未被声明的操作。 模型可以胡说八道，但它胡说八道的产物必须先通过一道确定性的闸门。
这也正好是我项目里那套状态迁移白名单在做的事。我为人类操作员写的那道闸门，原样可以用来接住一个 agent。
在哪儿做、由谁做
答案的两端是：一端是把数据发到某个 SaaS API；另一端是气隙环境里的本地部署，模型权重归客户所有。
这一条，本体层完全不管。
它不属于本体层的范畴。它只能靠部署边界和合同来解决：零留存条款、权重归属、隔离环境。
Palantir 和 Nvidia 在 2026 年 6 月 29 日宣布的合作，解决的正是这一条：把 Nvidia 的 Nemotron 开放权重模型带进气隙和涉密环境，客户在自己的基础设施上用自己的数据做训练，并保留最终模型的完整所有权，包括权重本身。
Karp 在那份公告里的说法值得注意。他说这样做是为了消除”专有洞察迁移进闭源模型权重”的风险。
也就是说，他自己承认：需要被隔离的东西不只是数据，还有那些会沉进权重里的东西。 这一点我在第五节还会回来。
而我的整个 lab 跑在一台我自己的虚拟机上，Docker Compose，局域网访问。这是这一条的一个极端答案。
Zero Trust 的位移
如果要给这三个问题找一个理论坐标，最贴切的是零信任（Zero Trust）：不预设信任任何执行者，按最小权限逐次授权，全程留下可审计的痕迹。
本体层做的事情，本质上是把零信任从网络层搬到了语义层。传统零信任问的是”这个请求来自哪台机器、哪个身份”；本体层问的是”这个执行者能看到哪些对象、能调用哪些动词”。同样的原则，换了一个抽象层次。
那个被我省掉的东西
现在回到映射表里的最后一行。
我在项目的”这个项目不是什么”一节里，明确排除了身份认证和基于角色的授权。我当时的理由是合理的：这是一个演示项目，权限不是我要展示的重点。
但当执行者从系统变成 AI，权限恰恰是唯一不能省的那一层。
系统对系统的时候，权限可以靠网络边界、部署约定、以及”另一个系统不会乱来”这个前提来兜底。执行者变成一个会自作主张的东西之后，这些兜底全部失效。权限是唯一还站着的东西。
这是我在这次思考里对自己项目最诚实的一次批评。它不是一个”未来改进”，它是一个结构性的缺口。
四、从这三个问题，我得到了一个企业侧的判断
这一节是我认为这篇文章里最有价值的部分。
先看供应商侧：为什么模型层收不到结果价值
Karp 在访谈里问了一个很尖锐的问题：如果这东西真这么值钱，如果我明天能让你赚十亿，我为什么不说”我让你赚十亿，我要三成”？他们为什么按 token 收费？
这个观察本身是对的。按 token 计费是一种商品化定价，和电、和云带宽是同构的：可计量、可替代、按消耗量收钱。
但他从这个观察里推出的结论是错的。他推出的是：卖方自己也不相信它值那么多钱。
真正的原因是结构性的，跟卖方相信什么没有关系：
归因做不到。 要按结果收费，你必须能证明结果是你造成的。而一个可以随时被换掉的零件，在原理上就无法被归因。同一套供应链优化，换个模型可能精度只差两个百分点，价值差异被应用层、数据质量、流程改造吃掉了。你没法把三成 alpha 归给一个可替换件。
计量做不到。 token 是唯一在供应商侧可观测、可审计的量。企业创造了多少价值，供应商看不见，也无权去看。要看，就得进企业的账本，那恰恰是企业最不愿意给的东西。
边际成本是真实的。 推理要烧算力和电。有真实边际成本的东西按用量收费，是标准做法。
所以结论是：能不能收结果价值，取决于你可不可替换，不取决于你多有价值。 模型层接受了商品化定价，不是因为它不值钱，而是因为它接受了（或者被迫接受了）可替换性。
这个结论比 Karp 的更硬，而且它同时解释了他的愤怒，和他愤怒的方向为什么错了。
但这是供应商视角。企业视角的推论完全不同
上面那一整段，是站在卖方的位置上看的。而我关心的不是谁能收到钱，我关心的是一家企业应该把力气花在哪儿。
从同一个”零件”前提出发，企业侧的推论是这样的：
第一，模型能力是可以被时间和金钱堆出来的。 算力和芯片会贵，但它们不构成一堵无法翻越的技术墙。这意味着模型会持续变强、持续变便宜。为”今天最强的那个模型”支付溢价，或者把谈判精力花在压这个价上，是在为一个注定贬值的东西讨价还价。
第二，本体层的内容不是技术，是你自己的业务。 你的企业里有哪些对象类型、哪些属性、哪些关系、哪些动词、哪些状态迁移是合法的、谁有权做什么——没有任何外部供应商能替你堆出来，因为它根本不在他们手里。 更聪明的模型可以帮你更快地把这一层写出来，但它不能替你决定这一层。决定权就是主体性所在。
把这两条合起来：
凡是能被时间和金钱堆出来的，都会变便宜；凡是只能由你自己定义的，都不会。企业应该把资源投在后者。
为什么”够用就好”是可能的
还有一层机制，让这个判断在经济上成立：本体层降低了任务对模型智力的要求。
给模型一堆命名混乱的表和一句”帮我处理这个理赔申请”，它必须自己推断语义、自己猜规则、自己判断哪些字段可信。这是一个高难度任务，需要很强的模型，而且仍然会错。
给模型一组定义清晰的对象、一份合法动词清单、一组封闭的取值集合——同一个业务目标，变成了一个低难度任务。弱模型也能可靠完成。
本体层做的事，是把”模型必须自己补齐的语义”，转移成”系统预先给定的语义”。 于是同一个业务目标所需要的模型智力，被系统性地压低了。
两条路径，和那个不对称
于是未来的企业面前有两条路：
路径 A：不建本体层，靠更强的模型硬吃混乱。它也能解决问题，这一点必须承认，否则就是稻草人。代价是：持续为最前沿的模型支付溢价；能力上限受制于模型今天恰好有多强；并且你把最难的那部分判断，外包给了一个你无法审计的黑箱。
路径 B：先建本体层，然后根据实际任务的难度，选择恰好够用的模型。代价是前期的建模投入。
关键的不对称在这里：
路径 A 的成本是持续的、递增的、且不可积累的。 每一次模型换代，你都要重新评估、重新采购、重新调优，而你昨天付出的溢价不会给你留下任何资产。
路径 B 的成本是一次性的、可积累的、并且会被每一代模型的降价反复兑现。 你的任务难度已经被压低了，模型每便宜一次，你就可以再往下换一档，而你的语义层原封不动。
这就是”我们肯定会选后者”的严格理由。它不是价值观，它是成本结构。
但真正关键的，是先意识到这是一道选择题
这才是我想说的重点。
一家没有意识到这个问题存在的企业，会把全部力气花在两件事上：选一个更牛的模型，然后把它的价格谈下来。这两件事都不是错的，但它们都发生在那个注定会贬值的层上。
意识到这道选择题的存在，本身就是一个分水岭。 意识到之后，你才会知道该往哪儿使劲。
一个诚实的反面
上面这套推论不是普适的，它有一个明确的失效条件：
当业务本身还没有稳定下来的时候，路径 B 是错的。
本体层的作用是把业务逻辑固化。如果你的业务每个季度都要推倒重来，那你固化的是噪音。对早期公司、对探索期的业务，“未确定”本身就是有价值的，过早的标准化会杀死它。在那种阶段，用强模型硬吃混乱，恰恰是正确的选择。
这个限定不是补丁。它提醒我们：本体层是一种给已经知道自己在做什么的组织准备的基础设施。
五、它没有解决，也不打算解决的事
到这里为止，本体层看起来非常有用。但我必须把它的边界画清楚，否则这篇文章就变成了推销。
下面三条，每一条我都认为可以单独写一篇。这里只写到”能站住”的程度。
权重与部署：不在它的范畴内
前面已经说过了，这里只补一个观察。
“能看什么”和”能改什么”这两条越成功，对”在哪儿做”的依赖就越强。
因为前两条的实现方式，是把最浓缩的业务逻辑组织成一个干净的、显式的、可导出的层。这个层一旦存在，“它跑在谁的机器上、谁能读到它、供应商是否留存它”这个问题的分量就急剧上升。
你通过建这一层解决了授权模糊，代价是制造了一个前所未有的高价值单点。
这大概也解释了，为什么 Palantir 必须去做那笔气隙交易：本体层这个东西，在逻辑上就必须配一个部署侧的答案，否则它自己就是最大的泄露面。
逻辑层的保密：技术上无解
这一条最难，也最有意思。
先做一个区分：alpha 不是一个东西，是两个东西。
数据是可以被有效保护的。 气隙部署、零留存条款、属性级裁剪、只暴露元数据不暴露正文，这套组合在工程上是可靠的。
不可保护的是逻辑。
要让 AI 在你的企业里干活，你必须交代背景：有哪些对象，它们怎么关联，哪些动作是合法的，什么条件下可以做什么。这些东西的总和，就是这家企业的业务逻辑。 而这些交代出来的背景关系，即便使用的是转译过的、抽象过的定义，在逻辑上也已经是透明的了。
对比一下从前的状态：一个老员工知道”这个 case 卡在某个状态就得手动打电话给某某”，但他说不清为什么。那条规则活在他的手上，不在任何文档里。这种逻辑的不可窃取，不是因为它受到了保护，而是因为它不可表述。
本体层要求你把它写出来。写出来之后，它第一次成为一个离开这家公司也能被读懂的东西。
所以这不是本体层的缺陷，这是它的成功条件。 它必须先把业务逻辑显性化，才能让 AI 用得上。显性化和可泄露，是同一个动作的两面。 技术上没有解法。
顺便说，Karp 在 Nvidia 那份公告里的措辞，其实已经承认了这件事：他担心的是”专有洞察迁移进权重”。洞察不是数据。洞察就是逻辑。
这让我想到一个更古老的结构：咨询师悖论。
你请一个咨询师来帮企业解决问题，你就必须把企业真实的运行逻辑和盘托出。你没有办法一边防着他，一边让他帮到你。企业请咨询师、请审计师、请外包开发商，几百年来都在做同一件事：为了获得帮助，必须被理解；被理解，就意味着被读取了。
而人类社会对这个问题的解法，从来就不是技术性的。是保密协议、是竞业条款、是执照与吊销、是声誉市场、是行业规范。全都是制度性的，没有一个是技术性的。
AI 只是把这个古老的问题放大了：咨询师读得慢、记得少、会离开；模型读得快、记得全，而且可能被写进权重。
顺着这条往下推一步（此处不展开，值得单独成篇）：如果逻辑层无法保密，那么纯逻辑型的优势会加速贬值。“我们比别人更懂怎么调度、怎么核保、怎么定价”这类护城河，会变得越来越浅。而执行、关系、牌照、资产、数据积累这些不能通过阅读获得的东西，相对价值会上升。
组合性越权：语法约束不了意图
这是我在整个思考过程中，自己推出来的最重要的一条，也是让我最不安的一条。
本体层的动作类型解决的，只是语法层面的授权模糊。它能约束”哪些动作存在”、“参数是什么类型”、“前置条件是否满足”。
它不能约束”这个动作此刻该不该做”。
一个 agent 完全可以在每一步都合法的前提下，通过一串合法动作的组合，达成一个从未被授权的结果。
举个例子。一个 agent 有权导出单条记录（合法），有权做批量查询（合法），有权发送通知邮件（合法）。它没有”导出全库并外发”这个动作类型。但把前三个动作组合起来循环一万次，结果等价于它。
没有任何单点检查能发现这件事，因为每一步都通过了。
要发现它，你必须在动作序列的层面做判断。而”这一串动作合起来意图是什么”，是一个语义问题，不是语法问题。本体层是一台语法机器，它在这里没有抓手。
六、归位
写到这里，我可以回答一开始的问题了。
本体层做的事，是把一个此前根本没有被标准化的东西标准化了。但最核心、最底层的问题，还在原地。
这个结构和 EDM 的历史完全对称。EDM 没有解决”业务为什么会长成这个样子”，它只是让数据交换有了共同的坐标。本体层没有解决”AI 该不该被信任”，它只是让授权有了共同的语法。两者都是必要的基础设施，都不是答案。
而我的不安，没有消除。它被搬了个家。
它原来的位置是：我大规模用 AI，我的数据会不会被吃掉？
它现在的位置是：一串每一步都合法的动作，最终会做成什么？
这不是解决，但这是进展。因为模糊的不安无法处理，精确的不安可以。
而这个新的不安，已经不是我一个人的直觉了
在完成上面这些推论之后，我去查了一下这个领域现在走到了哪一步。结果是：我担心的事情，今年已经有人在做，而且已经被验证了。
我推出来的那个”每一步都合法、组合起来越权”的结构，在今年的研究里已经有了名字，也有了实证。有工作明确指出，目前主流的多 agent 框架，全都建立在一个从未被系统检验的假设之上：如果每个子任务单独是安全的，那么整个计划就是安全的。 而这个假设是错的。研究者构造出的攻击链里，每一个单步都通过了全部已部署的安全分类器，组合起来的结果却违反了企业策略。另一条实证工作显示，把单独无害的工具编排成序列，攻击成功率可以超过九成。
制度层面也在动，而且它的动法本身就说明了问题。
NIST 在 2026 年 2 月 17 日启动了 AI Agent Standards Initiative。与之配套的概念论文点名了两类最紧迫的漏洞：一类是提示注入，另一类是自主行动链中的问责缺口，也就是 agent 的下游动作无法沿着授权链，追溯回一个负有责任的人。第二类就是我自己推出来的那个东西，只是它已经被写进了政府文件。
新加坡在 2026 年 1 月 22 日发布了全球第一份专门针对 agentic AI 的治理框架。它建议的技术控制里有一条是”把 agent 的访问限制在白名单服务上”——这和我在自己项目里为人类操作员写的那套状态迁移白名单，是同一个动作。而它反复强调的是：人类最终要承担责任。 遵循这个框架是自愿的，但组织对其 agent 行为所负的法律责任，不是自愿的。
欧盟这边最有意思。AI 法案里的高风险义务，包括第 14 条的人类监督，原定 2026 年 8 月 2 日适用。而在 2026 年 6 月 29 日，欧盟理事会最终通过了简化方案，把这批义务推迟到 2027 年 12 月 2 日。推迟的理由是：需要的技术标准和合规工具还没有准备好。
这件事本身就是这篇文章的一个注脚。规则可以先立起来，但让规则可执行的技术底座，现在还不存在。
而其中有一条没有变，并且恰好把这篇文章绕回了它的重心：人类监督的义务，落在部署方身上，不在模型供应商身上。
这件事无法外包。 这是一条法律事实，不是我的主张。
一个诚实的反驳，和它的转折
技术侧也有一批新的工作，正在试图把意图本身形式化：把一整个计划当作单元来验证，把动作绑定到用户的意图令牌，用形式化方法做监督。也就是说，业界正在尝试把”意图”也变成一个可以被语法约束的东西。
所以”语法约束不了意图”这个判断，也许是暂时的。 我不能装作没看见这一点。
但即便这条路走通了，还有一个环节绕不过去：要形式化意图，必须先有人说清楚”哪些意图是被允许的”。
而”这家公司允许什么、不允许什么、什么样的动作组合在业务上是荒谬的”——没有任何供应商能替你回答。
所以人的位置没有消失，它只是从”执行”移到了”定义”。
这和本体层的逻辑完全同构：能被自动化的部分会被自动化；剩下的那部分之所以剩下，正是因为它必须由一个真正懂这门生意的人来决定。
这条路还很长。而我现在至少知道，我在担心的是什么。
参考文献
Center for AI Standards and Innovation. (2026, February 17). Announcing the “AI Agent Standards Initiative” for interoperable and secure innovation. National Institute of Standards and Technology. https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure
Council of the European Union. (2026, June 29). Artificial intelligence: Council gives final green light to simplify and streamline rules [Press release].
European Union. (2024). Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union.
Infocomm Media Development Authority. (2026, January 22). Model AI governance framework for agentic AI. Government of Singapore. https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai
NVIDIA. (2026, June 29). Open models, closed environments: Palantir brings secure AI to US agencies with NVIDIA Nemotron. NVIDIA Blog. https://blogs.nvidia.com/blog/palantir-secure-ai-us-agencies-nemotron-open-models/
Palantir Technologies. (n.d.). Ontology overview. Palantir Documentation. https://www.palantir.com/docs/foundry/ontology/overview
Palantir Technologies. (2026, June 29). Palantir launches engine for deploying NVIDIA Nemotron open models in sovereign environments [Press release]. https://investors.palantir.com/news-details/2026/Palantir-Launches-Engine-for-Deploying-NVIDIA-Nemotron-Open-Models-in-Sovereign-Environments/
Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207
Wang, C. (2026). Enterprise Integration Lab [Portfolio project]. https://nortant.com/portfolio/enterprise-integration-lab/