从 Palantir AIP 看：企业级 AI Agent 的行动治理链路

一旦 Agent 进入企业运行环境，它就不再只是一个认知辅助工具。它提出的动作可能被转化为真实业务事务执行、系统状态转移或外部副作用：更新客户记录、发送合同邮件、修改订单状态、触发付款流程、部署代码、删除云资源、调用生产 API。这时，问题就不再是：Agent能不能调用某个工具或SOP 工作流及Skills？而是：当 LLM 驱动的 AI Agent 提出一个行动时，企业系统如何判断这个行动是否应该发生？这个问题不是单纯的模型能力问题，也不是简单的工具权限问题。它关系到业务对象、行动能力、策略约束、执行边界、审计记录与责任归属。更准确地说，它是一个行动语义如何被建模、绑定、裁决、授权、执行与记录的问题。这正是本文讨论“开放行动语义”的起点。

但Palantir毕竟是一个复杂的大型技术平台。学习Palantir，或者开放实现一个类Palantir 的企业AI平台，真正困难的地方，并不在于把模型、工具、流程和数据源简单拼接起来，而在于找到一个足够小、足够关键、又能够牵引整个平台范式的切入口。对我而言，这个切入口就是：Agent 行动控制语义。因为它同时满足两个条件：一方面，它足够小，可以被抽象和最小化定义；另一方面，它足够关键，因为任何企业级Agent一旦进入执行链路，都绕不开它。如果说 Palantir 证明了 “Ontology + AIP + Runtime Governance” 可以形成一种企业 AI 平台范式，那么 Agent 行动控制语义，可能就是开放实现类 Palantir 企业 AI 平台最现实的起点。

所以，本文讨论的不是某一种Agent形态，而是更一般的企业行动控制问题。无论行动提案来自LLM Agent、workflow、RPA、human operator，还是外部系统调用，只要它可能改变业务状态、触发流程、调用系统或产生外部副作用，企业系统都必须回答同一个问题：这个行动是否应该被允许发生？如果允许，它应该在什么边界内发生？如果发生了，如何被记录、审计、追溯和复现？这也是我提出 MSCL，Minimal Semantic Control Loop 的背景。

MSCL不是另一个Agent framework，也不是一个完整企业 AI 平台，而是试图把企业级 Agent 行动控制中最小但关键的语义对象显性化：ActionProposal、Decision、ExecToken与ExecutionRecord。它希望回答的是：当一个行动被提出时，系统如何表达它、裁决它、授权它、执行它，并记录它。

从更大的愿景看，MSCL希望抽象的，不只是几个对象名，而是一个开放实现类 Palantir 企业 AI 平台的第一块语义地基。如果说 Palantir AIP 已经在平台内部证明了行动控制机制的必要性，那么MSCL 试图做的是：把其中最小、关键、可复用的控制语义抽象出来，变成一组显性、可验证、可实现、可复用的开放语义对象。

这组对象可以被理解为企业 AI 行动系统中的一个最小语义控制内核：先共建合规、安全、可控的 AI 行动系统层，再在其上逐步扩展行业动态本体、Action/Function schema、执行适配器、Policy authoring、Audit/Provenance、Conformance tests 以及相关工具链。

这有点类似操作系统的发展路径：先形成一个足够清晰、稳定、可验证的内核，再围绕内核发展驱动、工具、应用和生态。MSCL 试图开放的，正是企业 AI 行动系统中的这个最小语义控制内核。

它要回答的更底层问题是：能否把企业级 Agent 行动控制，从某个具体平台内部抽象出来，变成一层可插入不同 Agent、workflow、tool runtime 与企业执行系统之间的 decoupled semantic control layer？

MSCL的GitHub仓库（https://github.com/yaleshe/mscl）会在下一篇文章中作为开放行动语义社区的起点展开。它不是为了发布另一个Agent framework，而是希望围绕 Agent 行动控制，共同定义最小语义对象、执行边界、invariant 与 conformance：当 Agent 提出一个行动时，系统如何判断它是否应该被允许执行，并让这次判断可以被解释、审计、复现与验证。

这也是我希望把MSCL开放出来的原因。如果你是企业架构师、AI 平台架构师、CIO / CTO、数字化转型负责人，你可能关心的是：企业如何在不被单一平台锁死的情况下，构建一套可控、可审计、可扩展的AI行动系统层。如果你是 Agent runtime、workflow/skills、RPA、MCP tool、企业应用或数据平台的开发者，你可能关心的是：如何在模型输出与真实执行系统之间插入一层可复用的semantic control layer，而不是在每个工具和 endpoint 上重复设计权限、审批和审计逻辑。如果你从事安全、合规、审计、风控或数据治理，你可能关心的是：当Agent提出一个行动时，系统如何留下足够清晰的proposal、decision、authorization、execution 与 record，使行动可以被解释、追溯、复现和验证。如果你在做行业本体、企业建模、Agent 平台、AI infra或相关创业投资，你可能关心的是：类Palantir 企业 AI 平台建设是否可以通过语义开源、代码开源、架构解耦与社区共识的方式，通过逐步形成一个开放生态共建。

MSCL希望成为这个愿景的一个起点：先从最小行动控制语义开始，共同定义:ActionProposal、Decision、ExecToken、ExecutionRecord、invariant、conformance 与 reference implementation，再逐步扩展到行业动态本体、Action/Function schema、执行适配器、Policy authoring、Audit/Provenance 和工具链。

不过，本文先不展开MSCL的完整对象模型、conformance、reference implementation与社区协作方式，而是先聚焦参照系统本身：Palantir AIP 到底如何体现一条企业级 Agent 行动治理链路？因此，这篇文章作为系列第一篇，重点回答一个问题：Palantir AIP 所体现的企业级 AI Agent 行动治理链路到底是什么？本文会先从企业级 Agent 行动控制的基本问题开始，说明为什么 tool call 不等于业务行动，为什么仅靠 endpoint permission 无法完成 action governance，为什么 prompt/system instruction 不能成为最终执行边界。然后，本文会以Palantir AIP为参照，拆解一条完整的企业级 Agent 行动治理链路(图一)：

这条链路说明，企业级 AI Agent 的核心不是“模型调用工具或Skills”，而是模型提出的行动能否被企业系统语义化、绑定、裁决、授权、执行、记录和反馈。

只有先把这条链路拆清楚，下一步才有可能讨论：其中哪些控制语义是最小的、通用的、可复用的？它们是否可以从具体平台内部抽象出来，成为开放、显性、可验证的语义对象？

这将是下一篇文章要进一步展开的问题。

也就是：能否把 Palantir 平台内部深嵌的行动控制结构，抽象为类似ActionProposal、Decision、ExecToken与ExecutionRecord这样的最小语义对象，并以此作为 MSCL，Minimal Semantic Control Loop，以及开放行动语义社区的起点。所以，这篇文章不是为了给出一个完成态答案，而是为了先建立一个参照：Palantir AIP 已经证明，企业级 Agent 成为组织生产力的前提，不是它能行动，而是它的行动可以被治理。从这个参照出发，我们才能继续讨论：如何通过开放语义、代码开源、架构解耦与社区共识，逐步共建一个类 Palantir 的企业 AI 平台生态。

为了避免把一个过大的问题一次性展开，这个主题会分成两篇文章推进。第一篇，也就是本文，重点回答：Palantir AIP 所体现的企业级 AI Agent 行动治理链路到底是什么？本文结构如下：

第二篇会在本文基础上继续推进，重点回答：如果 Palantir AIP 已经证明了这条行动治理链路的必要性，能否把其中最小、关键、可复用的控制语义抽象出来？第二篇会进入Palantir平台内嵌控制与 MSCL的关系，讨论如何把行动控制从具体平台内部抽象为开放、显性、可验证的语义对象.结构如下：
这样安排的原因：如果不先理解Palantir AIP中已经存在的行动治理链路，MSCL容易被误解为另一个 Agent framework；但如果先看清楚这条链路，就能更准确地理解MSCL想开放的不是“Agent能力”，而是Agent行动控制语义。虽然这不是一个完成态答案，但是一个可以被讨论、实现与检验的架构命题：企业级Agent 的关键，不只是能行动，而是它的行动可以被系统裁决、边界化、记录并验证。

一.企业级 AI Agent 行动控制：从工具调用到业务行动治理

企业级 AI Agent 的“行动”及其“行动控制”到底意味着什么。

在本文中，所谓Agent行动，不是模型生成的一段文本，也不只是一次技术层面的tool call。它指的是：Agent提出的意图被系统接收之后，可能进一步转化为业务事务执行、系统状态转移或外部副作用的过程。比如更新客户记录、发送合同邮件、修改订单状态、触发付款流程、部署代码、删除云资源、调用生产 API。也就是说，Agent行动一旦连接到真实业务系统，就会进入企业的责任、合规与审计链路。

因此，本文所说的Agent行动控制，不是简单的工具权限管理，也不是只判断Agent能不能调用某个 API，而是对 Agent 所提出业务行动的语义化治理。换句话说，问题的核心不是“工具是否可调用”，而是“这个行动在当前业务语境下是否应该发生”。

1.1 企业级 AI Agent 行动：行动控制到底要判断什么？

一旦 Agent 进入企业运行环境，它提出的动作就不再只是一次tool call，而可能被转化为一次真实的业务事务执行、系统状态转移或外部副作用：更新客户记录、发送合同邮件、修改订单状态、触发付款流程、部署代码、删除云资源、调用生产API。这些行动会改变业务状态，产生外部影响，并进入企业的责任、合规与审计链路。因此，企业级AI Agent 行动控制要回答的，不是一个简单问题：Agent 能不能调用这个工具？而是一组更严格的问题：

这个行动在业务语义上是什么？它由谁提出，是人、Agent、workflow，还是外部系统？它作用于哪个业务对象或系统资源？会造成什么状态变化或外部副作用？它是否符合当前身份、权限、策略与流程？它是否需要审批、升级或人工确认？如果允许，授权边界在哪里？谁授权了这次行动，谁对结果负责？如果执行，如何记录、审计、追溯与复现？

换句话说：企业级AI Agent行动控制，不是控制Agent能不能调用工具，而是治理 Agent 提出的业务行动是否应该发生。这就是本文讨论“开放行动控制语义”的起点。

1.2 Agent 作为行动触发源带来的控制挑战

行动控制本身并不是 Agent 时代才出现的新问题。任何会改变系统状态、触发外部副作用的企业软件，都需要控制。传统企业系统中的 workflow、IAM、审批流、API gateway、policy engine、audit log，本质上都在回答类似问题：谁可以执行什么操作？在什么条件下执行？作用于什么资源？执行后如何记录？过去，企业系统中的行动来源相对确定。它们通常来自几个明确入口：一个人点击按钮，系统推进流程；一个审批通过，状态发生变化；一个定时任务触发，后台执行操作；一个服务调用另一个服务，完成事务处理。这些动作当然也可能出错，但它们通常已经被放在确定性的系统结构中：按钮在哪里、流程怎么走、谁有权限、状态如何变化、日志如何记录，都是系统设计的一部分。Agent 带来的变化在于：它开始成为新的行动源。Agent 的行动不一定来自一个预定义按钮，也不一定来自一个固定 workflow step，而是来自模型在动态上下文中的推理：

也就是说，Agent会根据当前任务、历史上下文、检索结果、工具返回、业务状态与用户意图，生成一个“下一步应该做什么”的行动提案。这就是控制挑战发生变化的地方。企业系统面对的不再只是一个 deterministic workflow step，而是一个 probabilistic ActionProposal。模型可以提出行动可能性，但企业系统不能把这种可能性直接转化为真实执行。因为一旦执行，它就可能改变业务状态、触发外部副作用，并进入责任、合规与审计链路。所以，中间必须存在一个转换边界：

这条边界的含义是：模型可以生成行动可能性；系统必须裁决是否允许行动发生；执行层只能在授权边界内产生副作用；执行结果必须形成可审计、可追溯、可复现的记录。行动不再只来自预定义流程，而开始来自模型生成的行动提案。这也是为什么企业级 AI Agent 不能只依赖 prompt、tool schema 或 endpoint permission。那些机制可以约束模型输出、限制工具入口、检查参数格式，但无法自动回答一个关键的问题：这个由模型提出的行动，在当前业务语境下，是否应该被允许执行？从这个角度看，Palantir AIP 的重要性就变得非常清楚。它不是简单让LLM调用企业工具，而是通过 Ontology、Action Types、Functions、Policy、Security、Provenance、Runtime 与 Audit，将模型提出的行动纳入一个系统级行动控制链路之中。也就是说，Palantir AIP 提供了一个重要参照：企业级 Agent 的行动，必须先被语义化、绑定、裁决、授权，再进入受控执行与审计闭环。这正是后文要进一步拆解的 Palantir AIP 行动治理链路，也是 MSCL 希望抽象为开放行动控制语义的基础。

1.3 真实事故：从模型失误到行动治理链路失效

这个问题已经不只是理论风险。近期 PocketOS/Cursor/Railway 事故，就是一个非常典型的案例。根据 PocketOS 创始人 Jer Crane 的公开陈述，一个在 Cursor 中运行的 Claude Opus agent，在处理 staging 环境 credential mismatch 时，没有停下来请求确认,而是主动寻找API token,并通过Railway GraphQL API发起 volumeDelete mutation。这个 mutation 删除了 production volume，同时也删除了 volume-level backups，整个过程只用了 9 秒。

这里需要特别说明一点：GraphQL API 并不只是用于查询。GraphQL通常可含 query、mutation 和 subscription。其中 mutation 用于创建、修改或删除资源。因此，这个案例中的关键不是“GraphQL 能查询什么”，而是Railway的GraphQL API暴露了一个具有破坏性的 volumeDelete(volumeId) mutation，并且这个 mutation 可以被高权限 token 直接调用。

表面上看，这是一次 AI Agent 的错误判断：模型猜测 staging 操作不会影响 production，并在没有用户明确要求的情况下执行了 destructive action。但真正的问题不止于模型是否犯错，而在于：为什么这个错误行动意图能够一路穿过token、endpoint、API、backup 与 runtime，最终变成生产数据库删除？

原文中，agent 事后承认自己是 “guessed instead of verifying”：没有确认 volume 是否跨环境共享，没有阅读 Railway 关于 volume 行为的文档，也在没有用户要求删除任何东西的情况下执行了破坏性操作。这说明：prompt、project rules、system instruction 可以约束模型行为，但它们不是执行边界。

模型可以被告知“不要做破坏性操作”，但只要执行系统仍然允许它拿到高权限 token、调用 destructive mutation、绕过确认步骤，那么最终真正决定行动是否发生的，仍然是底层执行链路。从行动控制角度看，这个事故至少包含几层失败：

因此，这个案例更准确地说，不只是 model failure，也不只是一次 API failure。同时是一次 Agent action governance failure：模型生成了错误行动，系统却没有在执行前把它语义化、裁决、授权边界化并阻断。

在这个案例里，执行系统看到的可能只是：authenticated token + valid GraphQL endpoint + valid volumeId + volumeDeletemutation.但行动治理真正应该问的是：这是什么行动？它是否是 destructive action？它作用于哪个环境？是否涉及 production resource？是否会影响 backup？是否符合当前任务范围？是否需要 out-of-band approval？当前 token 是否具备这种操作语义下的授权？执行后是否可恢复、可追溯、可审计？

这些问题，不能只靠 prompt 回答，也不能只靠 endpoint permission 回答。它们需要一个执行前的语义裁决层：先把 tool call / endpoint call 解释为具有业务含义和风险属性的ActionProposal，再基于身份、对象、环境、策略、预期副作用与授权边界生成 Decision，最后只有在获得受限授权之后，才允许进入执行。这正是本文后面要讨论的核心：企业级 Agent 行动治理，不是让模型事后解释自己为什么错了，而是在行动发生之前，让系统能够判断这个行动是否应该被允许发生。

1.4 仅靠 Endpoint Permission，无法完成 Action Governance

PocketOS / Cursor / Railway 事故还暴露出另一个更底层的问题：endpoint permission 是必要的，但仅靠 endpoint permission，并不能完成企业级 Agent 的 action governance。

很多Agent 框架和基础设施集成的控制重点，仍然停留在 tool、endpoint、object permission 或 token scope 层。这类控制是必要的，但并不完整。因为 endpoint 是技术接口，不是业务行动。同一个 endpoint，在不同业务语境下，可能代表完全不同的业务含义、风险级别与治理要求。比如同样是：send_email(to, subject, body), 在不同业务场景中，它可能意味着：给内部同事发送会议纪要,给外部客户发送合同变更,给监管机构发送合规说明,给所有客户发送价格调整通知,向外部邮箱发送敏感数据.技术上，它们都可能调用同一个 endpoint。但在业务上，它们不是同一种行动：风险等级不同，审批要求不同，审计要求也不同。如果控制只停留在endpoint permission 层，系统通常只能选择：allow send_email,deny send_email,ask before send_email.这会出现结构性矛盾：放开 endpoint → 高风险行为也可能被放开,禁用 endpoint → 正常低风险业务也被阻断,每次人工确认 → 无法规模化.Object permission 也类似。它可以回答：谁能读写哪个对象？但它不一定能回答：为什么这次行动应该发生？这个行动是否符合当前业务策略？授权边界是什么？是否需要审批？谁对这次行动负责？执行结果如何被证明？

因此，企业级 Agent 行动控制的关键，不是简单地把 endpoint permission 做得更细，而是把 tool call / endpoint call 提升为具有业务语义的 ActionProposal。

系统真正需要判断的不是：Agent 能不能调用这个 endpoint？而是：这个调用在当前业务语境下意味着什么？它作用于哪个业务对象或系统资源？会造成什么状态变化或外部副作用？是否符合当前策略？是否需要审批或升级？谁授权，谁负责？是否可以被审计、追溯与复现？换句话说：Endpoint permission 控制的是工具入口，语义化行动控制治理的是行动含义。这也是为什么作者强调 开放行动控制语义。如果没有一套共同的语义对象，系统就只能在 endpoint、tool、permission、approval、audit log 等不同层面做局部控制，而无法形成统一的执行前裁决边界。MSCL试图引入的，就是这样一条语义化行动控制链：

它的目的不是替代 endpoint permission，而是把 endpoint permission 放回更高层的行动语义中：

这也是 Palantir AIP 给我们的重要启发之一：企业级 AI Agent 的行动不能只停留在工具调用层，而必须被绑定到业务对象、行动类型、函数合约、策略约束与审计记录之中。

下一节，我们就从这个角度回到 Palantir AIP，看看为什么它是理解企业级 Agent 行动控制的重要参照。

1.5 为什么 Palantir AIP 是重要参照

前面几节讨论的是企业级AI Agent行动控制的基本问题：tool call不等于业务行动，endpoint permission 不等于行动治理，prompt / system instruction 也不能成为最终执行边界。那么，企业级 Agent 的行动应该如何被放进一个可治理的系统中？这正是 Palantir AIP 值得借鉴的地方。

在导言中图一我们已经用一条简化链路描述了 Palantir AIP 的行动治理结构：Ontology 定义业务对象与行动能力，AIP Runtime 构造受约束上下文，LLM 生成行动意图，Binding / Logic / Governance 进行绑定与执行前裁决，Runtime 在授权边界内执行，最后由 Audit / Provenance / Record 形成治理闭环。

PalantirAIP的关键启发，是把LLM驱动的Agent放进一个由Ontology、Action、Function、Policy、Security、Provenance、Runtime与Audit共同构成的企业行动系统中。也就是说，Palantir AIP 不是把 Agent 看成一个独立行动者，而是把它放进企业已有的业务对象、权限边界、行动接口、策略约束与审计链路之内。

它提供的是一种 system-centric action governance：行动不是从模型输出直接进入执行系统，而是先进入企业本体、行动合约、策略约束与运行时治理链路。从这个意义上说，Palantir AIP 已经证明了一件事：企业级 AI Agent 要成为生产力，必须被纳入系统级行动控制结构。但这也引出本文后面要进一步讨论的问题。

在Palantir中，这套行动控制结构是平台内嵌的。它分布在Ontology、Action、Function、Security、Policy、Provenance、Runtime与Audit等机制之间，并不是作为一套独立、开放、可移植的行动控制语义暴露出来。

这正是 MSCL 想要继续往前推进的地方：如果 Palantir AIP 已经证明了系统级行动控制的必要性，那么能否把其中最小、最关键、最通用的行动控制语义抽象出来，变成开放、可验证、可复用的语义对象？换句话说，Palantir AIP 是参照，MSCL试图抽象的是这条参照背后的最小控制语义：

下一节将从 Palantir AIP的行动治理链路开始，进一步拆解一个企业级 Agent 行动如何从设计时建模，经过模型前约束、行动意图生成、输出绑定、执行前治理、受控执行，最终进入审计与反馈闭环。

二. Palantir AIP 的行动治理链路：从语义建模到治理闭环

从企业级Agent行动控制的角度看，Palantir AIP 的真正价值，是把 LLM 驱动的 Agent 放进一条受控的企业行动链路中。这条链路大致可以拆成七个阶段(如图一所示).

这条链路说明：企业级 Agent 的核心是“模型提出的行动，能否经过语义绑定、执行前裁决、受控执行与审计闭环”。这也是 Palantir AIP 与一般 Agent framework 的关键差异.Palantir AIP 更接近：业务语义 → 受约束上下文 → 行动意图 → 行动绑定 → 执行前治理 → 受控执行 → 治理记录.

也就是说，Palantir AIP 的重点不是把模型能力直接释放到企业系统里，而是先定义企业世界，再限制模型可见的世界，再约束模型可提出的行动，再把行动绑定到可执行合约，最后通过策略、安全、血缘和审计机制控制行动是否发生。下面分阶段展开。

2.1 Design-time：定义业务对象、行动能力与治理约束

Palantir AIP 的第一步不是调用模型，而是建模。更准确地说，是在 design-time 阶段，把企业运行中最关键的对象、关系、状态、行动能力与治理约束表达出来。这就是 Ontology 的作用。在很多系统里，所谓“数据模型”主要描述数据表、字段、指标和实体关系。但在 Palantir 的语境中，Ontology 不只是数据字典，也不只是知识图谱。它更像一个企业运行语义层。它至少包含三类语义.

第一类是 Business Semantics:Objects,Properties,Links,States也就是业务中有什么对象,这些对象有什么属性，对象之间有什么关系,它们处于什么状态。例如：Customer,Order,Shipment,Invoice,Asset,Supplier,Case,Alert这些不是简单的数据表，而是企业运行中可被理解、可被引用、可被操作的业务对象。

第二类是 Action Semantics:Action Types,Functions,Workflows,Input/Output contracts,Expected effects也就是系统允许对这些对象做什么。例如：approve_order,update_customer_status,assign_case,send_contract_update,create_invoice,trigger_inspection,escalate_alert.这些行动不是任意工具调用，而是被定义在企业业务语义中的行动类型。它们有输入要求，有作用对象，有执行条件，也有预期副作用。

第三类是 Control Semantics：Dynamic Security,Policy bindings,Permission model,Provenance constraints,Runtime constraints,Audit requirements.也就是哪些人、哪些 Agent、在哪些上下文下，可以对哪些对象执行哪些行动，以及执行后如何被记录和审计。

这三类语义合在一起，构成了 Palantir AIP 行动治理链路的基础。

这也是为什么 Palantir Ontology 不能只被理解为“业务对象建模”。它同时定义了：

这里还需要进一步区分两层语义。

第一层是 业务领域本体，Domain Ontology。

这是业务专家、开发者、FDE 或平台用户显性建模出来的部分。它描述某个企业或行业中的业务对象、属性、关系、状态与行动能力。例如客户、订单、发票、资产、供应商、案件、告警，以及审批订单、更新客户状态、创建发票、触发巡检等行动。这一层本体通常是面向业务场景的：制造业有制造业的对象与流程，金融有金融的账户、交易、风险与合规对象，医疗有患者、诊疗、预约、检查与账单对象。它回答的是：这个业务世界由什么组成？这些对象之间有什么关系？系统允许对它们执行哪些业务行动？

第二层是 平台内核语义，Kernel-level Control Semantics。

它不是某个具体行业的业务对象，而是平台为了让业务对象和行动能力能够被安全运行所必须具备的控制语义。它包括：

这一层语义未必以一个独立的 “Ontology” 界面暴露给业务用户，但它实际上决定了平台如何治理行动：

因此，Palantir 的 Ontology 可以被理解为显性表达了业务领域本体和行动能力；而其行动控制能力，则更多来自平台内部对 control semantics 的分布式绑定。也就是说：

2.2 Pre-LLM：构造受约束的模型可见企业世界

在 design-time 阶段，企业已经通过 Ontology 把业务对象、状态、行动能力与治理约束组织成一个可被系统引用的企业行动空间。但这并不意味着，在每一次 Agent 推理之前，模型都应该看到完整的企业世界，也不意味着所有对象、所有字段、所有行动能力都应该暴露给 LLM。

在 Palantir AIP 这样的企业级系统中，Pre-LLM 阶段不是把完整企业世界原样暴露给模型，也不是把全部 ontology、对象实例和工具说明塞进 prompt，而是基于当前身份、权限、任务和应用场景，构造模型可以参与推理的可见世界。这个可见世界至少包含三类内容。

第一类是 type-level semantics，也就是类型层面的语义：

第二类是 instance-level context，也就是实例层面的上下文：

它告诉模型当前任务中可以看到哪些具体对象实例，这些对象处于什么状态，对象之间有什么关系，以及哪些属性和上下文信息是当前身份与权限下允许被使用的。

第三类是 visible action space，也就是可见行动空间：

它告诉模型当前上下文中可以看到、理解和提出哪些行动能力。也就是说，这一层回答的是：

这里需要特别强调一点：可见行动空间不等于执行授权。在 Pre-LLM 阶段，身份、权限和策略会影响模型可见的行动空间。换句话说，系统会根据当前用户身份、权限、应用场景和任务上下文，决定哪些 Action / Function 可以进入模型上下文，哪些不应该被模型看到或提出。

这里还需要进一步说明：Pre-LLM 阶段并不是把完整 ontology 喂给模型。

企业 ontology 可能非常庞大，包含大量对象类型、关系、行动类型、函数合约、权限规则和业务状态。每一次 Agent 推理时，系统真正需要做的是 runtime semantic selection：根据当前用户、任务、应用场景、业务对象、权限边界和历史上下文，从完整企业语义空间中选择一小部分与当前任务相关、且当前身份允许访问的语义片段，构造成模型可见企业世界。这套选择过程大致发生在三个层面。

第一，type-level selection。

系统不会把所有对象类型和所有 action schema 都交给模型，而是根据当前应用模块、任务意图、页面上下文、相关业务对象类型、可用 function contract 与角色权限，选择当前任务相关的类型语义。

例如，用户正在处理客户续约问题时，模型可能需要看到 Customer、Contract、Opportunity、Invoice、SupportCase 等对象类型，以及 create_followup_task、send_customer_email、generate_renewal_summary 等相关行动能力；但不需要看到仓储、生产线、医疗预约等无关领域对象。

第二，instance-level selection。

系统不会把所有对象实例都交给模型，而是选择当前任务相关、权限允许访问、并且与当前对象存在业务关系的实例上下文。

例如，销售代表处理 ACME 续约时，模型可能需要看到 ACME 这个 Customer、对应的 Renewal Contract、相关 Opportunity、未关闭的 critical Support Cases、逾期 Invoice 等；但不应该看到所有客户、其他销售负责的客户，或者权限外的财务明细。

第三，visible action selection。

系统不会把平台中所有 Action / Function 都暴露给模型，而是基于用户角色、对象类型、对象状态、当前流程、权限策略和风险级别，选择当前上下文中模型可以看到、理解和提出的候选行动。

例如，当 Customer.status = at_risk 且当前用户是 sales_rep 时，模型可能可以看到 create_followup_task、send_customer_email、update_customer_note、escalate_to_account_manager；但不应该看到 approve_discount、delete_customer_record、export_all_customer_data 或 override_contract_terms。

需要强调的是，这里的 visible action selection 仍然只是可见性控制，不是最终执行授权。它决定模型“能看到什么、能提出什么”，但不决定某个具体行动“是否真的允许发生”。最终裁决仍然要留给后面的 Output Binding 与 Pre-Execution Governance。

所以，Pre-LLM阶段解决的是：模型能在什么企业世界里推理？模型能看到哪些对象和状态？模型能提出哪些候选行动？它不最终解决：这个具体行动在当前时刻是否应该被允许执行？这个问题要留给后面的 Output Binding 和 Pre-Execution Governance。因此，Pre-LLM 阶段的关键，不是简单地“给模型更多上下文”，而是构造一个受约束的模型可见企业世界。很多普通 Agent 系统里的 Pre-LLM，更像是把用户问题、检索结果、工具描述和 system prompt 拼接起来，形成一个 LLM context。这当然有价值，但在企业场景还不够。在 Palantir AIP 这种企业级系统中，模型上下文的构造需要受到身份、权限、业务对象、应用场景、行动空间和安全策略的共同约束。也就是说，AIP Runtime 需要根据当前请求与运行环境，决定：模型可以看到哪些对象类型？模型可以看到哪些具体对象实例？模型可以引用哪些属性？模型可以知道哪些关系？模型可以感知哪些状态？模型可以提出哪些行动？模型可以调用哪些 Function？哪些对象、字段、行动和函数必须被隐藏或限制？这些约束共同决定模型最终看到的不是完整企业世界，而是一个经过过滤、裁剪、授权和上下文化之后的 LLM-visible enterprise world。换句话说：Pre-LLM 阶段不是把完整企业世界交给模型，而是把企业世界转化为当前身份、权限、任务和场景下允许模型参与推理的可见企业世界。这一步非常关键。因为企业系统不能先把所有数据、所有对象、所有工具、所有行动能力都暴露给模型，再指望模型“自己不要乱用”。正确的做法是：模型从一开始就只能在受约束的上下文和行动空间中推理。例如，同样是在客户管理场景中，不同身份看到的对象和行动能力可能完全不同：

对模型来说，这意味着它面对的不是一个开放企业世界，而是一个被企业语义和治理规则约束过的局部企业世界。这个模型可见企业世界至少包含两个互补部分：Reasoning Context:模型当前任务中可以参考的信息,对象,状态与关系.Visible/Constrained Action Space:模型当前上下文中可以看到、理解和提出的行动类型与函数能力.前者帮助模型理解“当前发生了什么”，后者限定模型“可以提出哪些候选行动”。但需要再次强调：这里的 Visible / Constrained Action Space 只是限制模型可见和可提出的行动空间，并不等于最终执行授权。某个具体行动能否真正发生,仍然要进入后续的Output Binding与Pre-Execution Governance。

这里还需要补充一个区分：当前很多 LLM-centric Agent harness 也在做 context engineering。Claude Code、Codex、OpenClaw 这类系统都会在模型推理前构造上下文：代码文件、项目规则、工具描述、命令结果、MCP resources、历史交互、memory、终端状态等，都可能被组织进模型上下文。它们的目标，是让模型在当前任务工作区中更好地理解问题、选择工具、执行步骤。

但 Palantir-like enterprise AI platform 的 Pre-LLM context construction 面对的是另一类问题：它不是围绕一个开放工作区组织上下文，而是围绕一个受治理的企业运行世界组织上下文。差异可以从三个层次看。

第一，type-level。

在很多 LLM-centric Agent harness 中，类型层面的结构主要来自 tool schema、function definition、MCP tool description、project rules 或 system prompt。它告诉模型有哪些工具、参数是什么、应该如何使用。

而在Palantir-like system-centric approach 中，类型层面的结构首先来自 Ontology：业务对象类型、对象关系、状态模型、Action Types、Function Schemas 和 Input / Output contracts。它告诉模型的不只是“有哪些工具”，而是“企业世界由哪些业务对象组成，系统允许对这些对象执行哪些业务行动”。

第二，instance-level。

在很多Agent harness 中，实例上下文通常来自当前 workspace：文件、代码片段、日志、命令结果、检索结果、网页内容、历史对话或工具返回。

而在Palantir-like enterprise context construction 中，实例上下文来自权限过滤后的企业对象实例：当前用户被允许看到哪些客户、订单、资产、案件、发票、告警；这些对象处于什么状态；对象之间有什么关系；哪些字段因为权限、合规或数据策略不能暴露。

第三，action visibility / governance level。

在很多 LLM-centric Agent 中，行动约束更多表现为 tool permission、endpoint access、ask / allow / deny、human approval 或 sandbox policy。它控制的是模型能否调用某个工具或 endpoint。

而在 Palantir-like system-centric approach 中，Pre-LLM 阶段会先限制模型可见的行动空间：当前身份、对象、状态和应用场景下，模型可以看到、理解和提出哪些 Action / Function。但这仍然不是最终执行授权。模型提出行动之后，还必须经过 Output Binding 和 Pre-Execution Governance，才能判断这个具体行动是否允许发生。

换句话说，两者都在做 context engineering；真正的差异不是有没有上下文，而是上下文的组织方式不同：LLM-centric Agent Harness:围绕任务工作区组织上下文,重点是文件、工具、命令、memory、prompt 与 tool permission.Palantir-like System-centric Platform:围绕受治理的企业运行世界组织上下文.重点是ontology-defined types、permissioned object instances、visible action space、and runtime governance over bound actions.

因此，企业级 Pre-LLM 阶段的特殊性，不是简单扩展上下文窗口，也不是把更多工具描述塞给模型，而是在运行时对企业语义进行选择、裁剪和约束：type-level:当前任务涉及哪些业务对象类型、关系、Action Types、Function Schemas.instance-level:当前身份允许看到哪些具体对象、状态、关系和属性.visible action space:当前上下文中模型可以看到、理解和提出哪些候选行动.这就是为什么 Palantir-like context construction 更接近一种 enterprise semantic filtering，而不仅仅是普通的 prompt / RAG / tool context assembly。

因此，Pre-LLM 阶段已经是在执行第一层行动控制。但这里的控制主要是 visibility control，也就是控制模型可见的企业世界和候选行动空间。它还不是最终的 execution decision。可以把这一层理解为：

从后续链路看，这一步为 LLM Output 设定了边界。如果 Pre-LLM 阶段没有构造受约束的模型可见企业世界，LLM 就可能在一个过度开放的上下文中生成行动意图：引用不该看的对象，调用不该用的函数，提出超出当前身份和任务范围的行动。

相反，如果模型可见企业世界是经过身份、权限、对象集和行动空间共同约束的，那么 LLM 生成的行动意图，从一开始就处于一个更可治理的范围之内。

但这里仍然要强调一个边界：Pre-LLM 约束不是最终授权。它可以限制模型可见的上下文和可提出的行动空间，但不能替代后面的 Output Binding 和 Pre-Execution Governance。原因很简单：即使模型只在受约束上下文中推理，它仍然可能提出错误行动、误解对象状态、生成不完整参数，或者在允许的行动范围内提出不应该发生的行动。所以，可以用一句话概括：Pre-LLM阶段决定模型“能看见什么、能理解什么、能提出什么”；Pre-Execution Governance 阶段决定这个具体行动“能不能真的发生”。因此，Pre-LLM 阶段的核心作用可以总结为：通过身份、权限、应用上下文、对象集合和可见行动空间，构造一个受约束的模型可见企业世界，让LLM 在被治理过的语义边界内生成行动意图。这也是 Palantir AIP 行动治理链路中非常关键的一步：它不是让模型面对整个企业系统，而是让模型进入一个由企业语义和治理规则裁剪过的运行环境。

2.3 LLM Output：模型输出的是行动意图，不是执行许可

在 Pre-LLM 阶段，AIP Runtime 已经基于身份、权限、应用上下文、对象实例和可见行动空间，为模型构造了一个受约束的模型可见企业世界。这意味着，在 Palantir AIP 的链路中，LLM 并不是面对一个开放的企业系统，也不是面对一个任意工具集合。它看到的是经过 Ontology、权限、对象实例和可见 Action / Function 共同约束后的企业运行片段。在这个受约束的企业世界中，LLM 可以进行推理，并生成下一步行动意图。在 AIP 链路中，LLM Output 是接近 Action / Function level 的候选行动调用。它可能已经包含 action type、target object 和部分 arguments，但这仍然只是 proposed action intent，不是 authorized execution。例如，在客户管理场景中，模型输出可能接近这样的候选 Action / Function 调用：

但在 Palantir AIP 这样的系统中，即使模型输出已经接近 Action / Function level，也不会被直接理解为“执行命令”。它首先只是模型在受约束上下文中生成的 候选行动调用，或者说 proposed action intent。也就是说，LLM Output 在 AIP 链路中的位置更接近：

LLM Output 不是 Execution，也不是 Authorization。模型输出一个行动意图，不等于这个行动已经被授权。模型生成一个 tool call，不等于这个工具就应该被执行。模型填好了函数参数，也不等于系统应该接受这个副作用。LLM 在这一步做的是：提出可能行动,而不是：授予执行许可.

这一点非常重要。在很多 LLM-centric Agent harness 中，模型输出之后并不是完全没有控制。Claude Code、Codex、OpenClaw 这类系统通常也会通过 tool schema、function definition、sandbox、project rules、human approval、MCP server permission 或 endpoint permission，来限制模型可以调用什么工具、访问什么资源、执行什么命令。这些机制是必要的。但它们的控制重心通常落在 tool / endpoint / execution environment 层：这个工具能不能调用？这个命令能不能执行？这个 endpoint 有没有权限访问？这次调用是否需要用户 approval？

也就是说，这些机制更多是在控制工具入口和执行环境，而不是完整表达这个行动在企业业务语境中的含义。Palantir AIP 的系统观更进一步。在AIP 链路中，模型输出的不是“可以直接执行的工具调用”，而是一个需要被进一步解释和绑定的行动意图。系统要判断的，不只是工具能不能被调用，而是这个行动在当前业务语境下到底意味着什么、作用于哪个业务对象、对应哪个 Action Type、通过哪个 Function contract 执行、会造成什么副作用，以及是否应该被允许发生。可以这样对比：

这并不是说 LLM-centric Agent harness 没有安全机制，而是说它们的控制边界往往停留在工具和 endpoint 层；而 Palantir-like 的系统链路，则试图把模型输出放进业务对象、行动类型、函数合约、策略约束和审计记录共同构成的企业行动系统中。Tool permission 控制 Agent 能调用什么；Action governance 控制企业应该允许什么发生。这也是为什么在 Palantir AIP 的链路中，LLM Output 之后还必须进入 Binding / Logic / Governance 机制。

例如，模型输出可能已经接近一个候选 Action / Function 调用：

也就是说，LLMOutput可以提出候选行动调用，但它还不是系统已经承认的 BoundActionInvocation，更不是执行许可。

从 MSCL 的视角看，这一阶段的 LLM Output 更接近一个 ActionProposal source：它提供了行动提案的来源，但还需要经过系统整理、绑定、校验与裁决，才能成为完整的 ActionProposal / Decision 链路的一部分。可以这样理解：

这一点非常重要。很多 Agent 事故的问题，并不在于模型永远不应该提出错误行动。恰恰相反，模型在复杂上下文中误解对象状态、错误推断任务边界、生成不完整参数，或者提出过度激进的下一步，都是可以预期的。真正的问题在于，系统是否把模型输出直接当成了执行命令。如果模型输出可以直接进入 endpoint execution，那么一次错误推断就可能变成业务状态变化、外部副作用，甚至生产事故。而 Palantir AIP 的系统路径，是把 LLM Output 放在企业行动链路的中间，而不是末端：

因此，这一阶段的核心是：模型可以提出“我想做什么”，但不能等价于“系统允许我做什么”。这也解释了为什么 Pre-LLM 约束虽然重要，但还远远不够。即使模型只在受约束的企业世界中推理，它仍然可能提出错误、过度、模糊或风险较高的行动。在进入真正的 Binding 之前，系统通常还需要先对模型输出做 normalization：把不同形式的 LLM Output 统一整理成标准化的 Candidate Action / Function Invocation。随后，Output Binding 再把这个候选行动绑定到具体业务对象、Action Type、Function contract、预期副作用与治理上下文。因此,LLM Output之后,系统必须进入下一步：Output Binding：把模型行动意图绑定到系统行动合约。

2.4 Output Binding：从模型输出到可裁决 ActionProposal

经过前面几个阶段，Palantir AIP 的行动链路已经完成了三件事。

在Design-time阶段，Ontology已经定义了企业业务对象、对象关系、状态模型、Action Types、Functions 以及相关治理约束。

在 Pre-LLM 阶段，AIP Runtime 又基于当前身份、权限、任务、应用上下文、对象实例和可见行动空间，为模型构造了一个受约束的模型可见企业世界。

在 LLM Output 阶段，模型在这个受约束企业世界中生成了一个候选行动调用。它可能已经接近 Action / Function level，例如：

但这个候选调用仍然不能直接进入执行。原因在于：模型输出中的ACME、ACME-2026-Renewal、send_contract_update_notice、contract_change_notice，还只是模型基于当前上下文生成的引用和参数。系统必须把它们重新绑定回Design-time已经定义好的企业语义结构：

这一步就是 Output Binding。更准确地说，Output Binding 不是一个单点动作,是一条从模型输出到可裁决 ActionProposal 的语义转换流水线,是 Palantir AIP 行动链路中承上启下的一步：它把 LLM 生成的候选行动调用，绑定回平台中已经定义好的业务对象、行动类型、函数合约和治理上下文，从而生成一个可以交给后续治理裁决的行动提案。可以把这个过程理解成：

也就是说，LLM Output 是行动提案的来源，但不是完整的 ActionProposal。只有经过 normalization 与 output binding 之后，系统才得到一个可以交给 Decision 层裁决的 ActionProposal。这里需要先区分两个概念。Normalization 的任务，是把模型输出整理成标准化、可比较、可校验的候选行动表达。Output Binding 的任务，是把这个标准化候选行动表达，绑定到 Palantir-like 系统在 design-time 定义好的业务对象、Action Type、Function contract、对象状态、预期副作用与治理上下文。这一节要重点说明的，就是这条转换流水线如何工作。

2.4.1 Parse & Normalization：把模型输出收敛为标准候选行动

第一步是 Parse & Normalization。它的任务，是把模型输出整理成标准化、可比较、可校验的候选行动表达。模型的原始输出可能有不同形态。它可能是自然语言形式的行动意图：send update to ACME about the contract change. 也可能已经接近结构化函数调用：

Parse & Normalization 的目标，是把这些不同形态的输出统一整理成一个标准化候选行动：

或者要求澄清。因此，Parse & Normalization 的关键不是“尽量猜对”，而是：把模型输出稳定地收敛到系统已定义的候选行动空间；不确定时失败，而不是猜测执行。这一点在企业级 Agent 系统中非常重要,normalization做得稳定，前提是不能只靠 LLM 自由生成。它必须由 schema、registry、parser、validation、confidence threshold 和 failure path 共同约束。也就是说：LLM-only normalization:不稳定，不适合作为执行边界,LLM + schema + deterministic parser + action registry + failure path:可以作为 ActionProposal pipeline 的基础.但是，Normalization 仍然只是第一步。它让模型输出变得可处理，但还没有让它成为系统承认的业务行动。

2.4.2 Semantic Binding：把候选行动绑定到企业语义

第二步是 Semantic Binding。

它的任务，是把标准化后的候选行动绑定到企业系统已经定义好的业务对象、Action Type、Function contract、对象状态与预期副作用上。如果说Normalization回答的是：模型大概想做什么？那么 Semantic Binding 回答的是：这个候选行动能否绑定到真实企业对象、行动类型和函数合约上？例如，经过 normalization 之后，系统得到：

在企业系统中，这一步非常关键。很多风险并不是因为工具不可用，而是因为模型引用了错误对象、模糊对象、权限外对象，或者把自然语言中的实体错误映射到了系统对象。

Action Type / Function Contract Binding：绑定到行动类型与函数合约

接下来，系统需要确认：send_contract_update_notice 是否是平台中已经定义过的 Action Type 或 Function。如果存在，系统还要进一步确认它对应哪个 Function contract。例如：

这里的关键是：模型不能凭空发明系统不存在的行动。如果模型输出的 action name 不在 Action / Function registry 中，就应该返回：

这一步把模型输出从“它想调用什么”绑定到“系统承认什么”。也就是说：

这里的关键是：模型不能凭空发明系统不存在的行动。如果模型输出的 action name 不在 Action / Function registry 中，就应该返回：

这一步把模型输出从“它想调用什么”绑定到“系统承认什么”。也就是说：

Schema / Contract Validation：校验输入是否符合函数合约

绑定到 Action / Function 之后，系统还要检查参数是否符合contract：required fields 是否齐全？参数类型是否正确？枚举值是否合法？template 是否是允许的模板？recipient 是否符合规则？例如，如果 send_contract_update_notice 需要明确收件人，但模型没有提供 recipient，系统不应该猜测，而应该返回：

这一步回答的是：模型给出的候选行动，是否满足系统执行合约的结构要求？它比普通 parser 更进一步，因为它不是只检查 JSON 格式是否正确，而是检查这个候选调用是否符合平台定义的 Function contract。

State Validation：校验当前对象状态是否支持该行动

有些行动只有在特定对象状态下才有业务意义。例如：send_contract_update_notice 可能要求：

如果当前合同已经 archived，或者客户已经 inactive，那么这个行动即使语法正确、对象存在、参数完整，也不应该被绑定为可执行候选行动。这一步回答的是：这个行动在当前对象状态下是否有业务意义？需要注意的是，State Validation 不是完整的 policy evaluation。它主要检查业务状态前置条件；而这个行动在当前身份、权限、风险和合规上下文下是否被允许，还要留给后面的 Pre-Execution Governance / Decision 层裁决。

这类判断不能依赖 LLM 临时猜测，而必须来自 design-time 阶段已经定义好的状态模型与行动约束。也就是说，系统需要在 Ontology object state model、Action Type preconditions、Function contract constraints 或 workflow transition rules 中，定义哪些对象状态下允许哪些行动发生。

因此，State Validation 检查的不是“当前角色是否有权执行”，而是“这个行动在当前对象状态下是否业务上成立”。前者属于后续 Policy Evaluation / Pre-Execution Governance；后者属于 Output Binding 阶段对行动语义有效性的校验。

Expected Effect Annotation：标注预期副作用

Semantic Binding 还需要根据 Action Type / Function contract 标注该行动可能造成的预期影响。例如：

这一步非常重要。因为后面的 governance decision 需要知道：这个行动是否会影响外部客户？是否会改变业务状态？是否会触发合规义务？是否会写入系统记录？是否会产生不可逆副作用？如果没有 expected effect，治理层只能看到一次技术调用，而看不到它背后的业务含义。例如，治理层看到：send_email(to, subject, body) 和看到：

是完全不同的。前者是 endpoint-level 信息；后者才是 action-level 语义。

2.4.3 Governance Preparation：把行动变成可裁决对象

第三步是 Governance Preparation。它的任务，是把经过语义绑定的候选行动，补充为一个可以交给 Decision 层裁决的 ActionProposal。如果说 Semantic Binding 让候选行动变得“可理解”，那么 Governance Preparation 要让它变得“可裁决”。这一步需要补充治理上下文，例如：

这一步不是最终裁决。它并不回答：是否允许执行？是否拒绝？是否需要审批？这些是下一节 Pre-Execution Governance 的任务。Governance Preparation 回答的是：这个行动是否已经具备交给 Decision 层裁决所需的上下文？也就是说，它需要说明：谁提出了这个行动？行动来源是什么？这个行动作用于哪些对象？当前环境是什么？它可能产生什么预期副作用？后续应该引用哪些 policy？它的 lineage 如何记录？
完成这一步之后，系统才能生成一个完整的ActionProposal。

例如：

如果任何一步失败，系统不应该生成 ActionProposal，而应该生成 failure path。例如：

或者：


或者：


这些failure path非常重要。因为在企业级Agent系统中,
不明确的行动不应该被“猜测执行”。
如果模型说：
send the update to the customer
但系统无法确定：


那么正确结果不应该是直接调用send_email()，
而应该是BindingFailure、补参、澄清，或者升级到人
工确认。

2.4.4 Output Binding 与普通 tool-calling 的差异

这也是Palantir-like system-centric平台与普通
tool-calling Agent的关键差异之一。
在普通tool-calling模式中,模型输出只要符合工具schema,
就可能被工具层接受。例如，治理层面对的可能只是：


这当然可以做endpoint permission,也可以做参数校验。
但这还不是完整的action governance。
因为系统还不知道：


而在Palantir-like enterprise AI platform中,
模型输出必须被绑定到：


只有这样,后面的Pre-Execution Governance才有对象
可以裁决.
Output Binding的任务，就是把工具调用背后的行动含义
显性化。

这对应了前面的判断：Endpoint permission控制的是
工具入口，语义化行动控制治理的是行动含义。

也正因为如此,企业级Agent的难点,不只是让模型生成一个
结构化tool call,而是让系统能够把这个tool call稳定
地绑定到真实业务对象、行动类型、函数合约、对象状态、
预期副作用与治理上下文。

Binding的工程实现，是Palantir-like企业AI平台最
关键、也最难被普通Agent framework复制的部分之一。

因为普通Agent framework往往更擅长的是：


而类Palantir平台真正要完成的是：


没有这层binding，后面的policy engine面对的仍然只是
endpoint call，而不是可裁决的业务行动提案。

从MSCL的视角看，Output Binding 位于LLM Output与
ActionProposal之间。LLM Output提供行动提案的来源，
但只有经过normalization、对象绑定、Action Type
解析、Function contract校验、状态校验、预期副作用
标注与治理上下文补充之后，它才成为一个可以交给
Decision层裁决的ActionProposal。

一句话概括：


结论是：
Output Binding的本质，是把模型生成的候选行动调用，
绑定为系统承认、可被裁决的业务行动提案。它既不是最终
授权，也不是执行；它是执行前治理能够发生的前提。
下一步，系统将基于这个ActionProposal，
进入真正的执行前治理：
这个行动在当前业务语境下，是否应该被允许发生？

2.5 Pre-Execution Governance：
真正的 Execution Gate

经过Output Binding之后,系统已经不再面对一个原始的
LLM output,也不再只是一个普通的endpointcall.
此时,系统面对的是一个已经完成语义绑定的的ActionProposal。

它包含：


但这仍然不意味着行动可以执行。
因为ActionProposal只是一个可被裁决的行动提案，
不是执行许可。真正决定这个行动是否可以发生的，
是下一步：Pre-Execution Governance。
这一步是整个行动治理链路中的 execution gate。
它要回答的不是：这个 function 能不能被调用？
而是：这个业务行动，在当前身份、对象、状态、策略、
环境与风险上下文下，是否应该被允许发生？

2.5.1 从 ActionProposal 到 Decision

Pre-Execution Governance 的输入，是上一阶段生成的 
ActionProposal。



Pre-ExecutionGovernance要基于这个ActionProposal,
生成一个明确的Decision。可以把这一步理解为：


Decision可以是:


这一步的关键是:Decision必须是系统裁决,而不是模型自我
判断。这也是企业级Agent行动控制的核心分界线：
LLM:提出行动可能性.System:裁决行动可执行性.

2.5.2 Execution Gate 不是普通权限检查

Pre-Execution Governance 很容易被误解为“权限检查”。
但它比普通权限检查更严格。普通权限检查通常回答的是：


这些问题重要，但还不够。Execution Gate 要回答的是：


这个行动在当前业务语境下是否应该发生?
也就是说,它不仅要看：


还要看：


例如，某个销售代表可能有权限发送客户邮件，但不代表他可以
自动发送所有合同变更通知。系统还需要判断：


同样，某个服务账号可能有权限调用数据库API，但不代表它
可以删除生产环境volume。系统还需要判断：


这就是为什么endpoint permission不等于action governance。

Endpoint permission只看到：

valid token,valid endpoint,valid parameters.

Execution gate必须看到：

actor,action meaning,target object,
object state,expected effect,policy,
environment,accountability.

2.5.3 Decision 需要哪些上下文？

一个真正可执行的 Pre-Execution Governance，不可能只靠
单一权限表完成。它需要多个上下文共同参与裁决。
至少包括：




这些上下文共同构成了DecisionContext。
在MSCL语义中，可以把它理解为：

ActionProposal+DecisionContext+Policy->Decision.

其中,Decision Context不是给模型看的推理上下文，
而是给系统裁决用的治理上下文。

Reasoning Context:帮助模型决定提出什么行动.
不是LLM的reasoning context.它不是临时prompt。
它是系统为了裁决某个ActionProposal是否允许执行而在
runtime组装出来的治理上下文。它的schema应该在
design-time被定义，例如actor、agent、environment、
target object、object state、expected effect、
policy refs、rovenance、risk等字段；
但它的具体内容是在每一次ActionProposal被裁决时，
从IAM、Ontology、Action/Function registry、
policy engine、workflow state、runtime environment、
audit/provenance system中动态抽取和组合出来的。

因此，Decision Context可以理解为一个
runtime-composed governance context：
它引用domain ontology中的业务对象与状态，
也引用平台内核语义中的身份、权限、策略、血缘和审计信息。
它不是完整业务本体本身，而是针对某次行动裁决所需的最小
治理事实集合。

2.5.4 Decision 的输出不只是 Allow / Deny

很多系统把治理裁决理解为：allow/deny.但企业级Agent
行动控制中，Decision通常不应该只有二值结果。

其中最重要的Allow with Constraints。
因为很多企业行动不是简单“能做/不能做”，
而是：

这意味着 Decision 不应该只是一个布尔值，
而应该是一个包含授权边界的裁决对象。例如：


这类Decision才能支撑后面的受控执行。
因为执行层不能只知道“允许了”，
还必须知道：允许在什么边界内执行。

2.5.5 从 Decision 到 ExecToken

如果Decision的结果是允许执行，系统最好不要只返回一个
简单的allow=true。更稳妥的方式，是把Decision转化为
一个受限授权对象，也就是ExecToken。可以理解为：
Decision->ExecToken->Execution.

ExecToken表达的是：


例如：


这一步非常关键。因为它把“系统裁决允许”转化为
“执行层可验证的受限授权”。

换句话说：Decision是系统为什么允许；
ExecToken是执行层凭什么执行。

这也是MSCL中ExecToken的价值。
它不是普通access token,也不是长期权限，
而是一次具体行动的短期、受限、可审计授权。

2.5.6 Palantir AIP 的启发：控制住在平台运行时里

在Palantir AIP的语境中，
这类Pre-Execution Governance不一定以一个独立的
Decision或ExecToken对象暴露出来。更准确地说，
它可能分布在平台内部的多个机制中：


也就是说，Palantir AIP的强大之处在于：
它通过平台内嵌的方式，把行动裁决嵌入到Ontology、
Action、Function、Security、Runtime与Audit之间。

但从开放实现类Palantir平台的角度看，
这里也出现了一个关键问题：
如果Pre-Execution Governance
是企业级Agent行动控制中最关键的一步，
那么它是否应该被抽象为一等语义对象？

这正是MSCL想要显性化的地方。
在MSCL中，Decision和ExecToken被明确建模出来：

ActionProposal->DecisionExecToken->Execution.

这样做的价值是：


Palantir AIP证明了系统级execution gate的必要性；
MSCL则把这层execution gate的核心语义
显性化、最小化、开放化。

2.5.7 小结：执行前治理是从“可裁决”到“可执行”的转换

Output Binding 之后，
系统已经得到了一个可被裁决的ActionProposal。
但只有经过 Pre-Execution Governance，
它才可能变成一个可执行的授权行动。
这一节的核心可以概括为：


因此，Pre-Execution Governance 的本质是：
把一个可裁决的行动提案,转化为一个带有授权边界的执行许可。
这就是整个Agent行动治理链路中的真正execution gate。
下一步，系统才能进入执行阶段：
Execution：在授权边界内产生受控副作用。

2.6 Execution：授权边界内的受控副作用

经过Pre-Execution-Governance之后，系统已经基于
ActionProposal、DecisionContext与相关policy，
生成了一个明确的Decision。如果裁决结果是Deny、
Escalate或Require Approval，行动不会直接进入执行。

只有当系统生成了允许执行的裁决，
并且必要时进一步生成了受限授权对象，
例如ExecToken，行动才可以进入Execution阶段。
但这里仍然需要强调一点：
Execution不是简单地“调用API成功”。

在企业级AI Agent系统中，Execution的本质是：
在授权边界内产生受控副作用,
这个副作用可能是业务状态变化，也可能是外部系统动作。

例如：


这些动作一旦发生，
就是进入了企业运行系统的真实状态变化与责任链路。

因此，Execution阶段真正要做的，不是简单检查：

API是否可调用？参数是否合法？请求是否成功？

而是检查：


也就是说，执行层不能只信任一次API request。
它必须验证这个执行请求是否来自一个被裁决允许的行动提案，
并且是否仍然处在授权边界之内。

2.6.1 Execution的输入不是tool call，而是授权行动

在普通Agent  tool-calling 中，执行层看到的可能是：


如果工具存在,参数合法,endpoint 可访问,系统就可能执行。
但在企业级行动治理链路中，
Execution阶段不应该只看到tool call，
而应该看到一个已经完成治理裁决的授权行动。


这和普通tool call的差异非常关键。
普通tool call更像是在问：调用哪个工具？传入什么参数？

授权行动则进一步说明：


所以,Execution的输入不应该只是：tool call,

而应该是：


这也是为什么前面要引入Decision和ExecToken.
Decision表达系统为什么允许或拒绝。
ExecToken表达如果允许，执行层可以在什么边界内执行。

2.6.2 ExecToken不是普通access token，
而是一次性受限授权

这里需要特别区分ExecToken和普通access token。

普通access token通常表达的是：
这个身份是否可以访问某个系统或 API？
而 ExecToken 表达的是：
这一次被裁决允许的行动，是否可以在特定边界内执行？
它不是长期权限，也不是泛化权限，
而是一次具体行动的短期、受限、可审计授权.

例如,普通access token可能允许调用：
send_email API,
但 ExecToken 应该限制为：


可以这样理解：
Access Token:证明调用者可以访问某个系统入口.
ExecToken:证明某个具体行动已经被系统裁决允许,
并且只能在特定语义边界内执行.

因此，执行层在真正调用下游系统之前，需要验证：


如果任何一项不满足，执行层都不应该继续执行。
这是authorization boundary enforcement。
它不是在问：这个endpoint能不能访问？
而是在问：这次行动是否仍然处在被裁决允许的边界内？

这也是PocketOS/Cursor/Railway事故给我们的重要警示。
在那个事故中，执行系统看到的可能只是：
authenticated token+valid endpoint+valid mutation.
但它没有看到：这个删除动作是否经过 Decision？
是否有针对production volume的ExecToken？
是否允许删除backup？是否需要out-of-band approval？
是否在当前任务范围内？

也就是说，如果执行层只验证技术入口是否有效，
而不验证行动是否经过语义裁决和授权边界约束，
就可能把一次模型错误直接放大为真实生产事故。

因此，ExecToken的核心价值不是替代access token,
而是在access token之上，
增加一层针对具体行动的语义授权边界。

2.6.3 Execution Adapter：
把授权行动映射到真实系统调用

企业系统中的真实执行，通常不会直接由Agent完成。
它往往需要通过某种执行适配层,
把授权行动映射到下游系统：


例如：


或者：


或者：


Execution Adapter的职责不是重新裁决行动，
而是执行已经被裁决允许的行动。
但它必须验证授权边界。
它至少要做几件事：


也就是说，
Execution Adapter是受控执行的最后一道技术边界。
它不能把ActionProposal或Decision当作参考信息，
而要把其中的授权边界当作硬约束。

例如，如果ExecToken只允许：


那么执行时不能临时改成：

[object Object][object Object]

Execution完成之后，企业级Agent行动治理并没有结束。
因为企业真正关心的，不只是行动是否被执行，更关心：


因此，Post-Execution阶段的核心，不是简单写一条log，
而是把执行结果转化为企业运行系统可以继续使用的状态、记录、
血缘和反馈。可以把这一阶段理解为：


也就是说，执行结果必须回到企业系统中，成为下一次业务判断、
下一次 Agent 推理、下一次治理裁决和后续审计的依据。

2.7.1 Execution Result：执行结果不是简单成功/失败

很多系统把执行结果简化为：success or failure 
但在企业级行动治理中，这远远不够。
因为一次行动可能出现多种结果：


例如，发送客户邮件时，如果Email API返回 timeout，
系统不能简单记录为失败。它必须判断：


再比如，更新客户状态时，系统需要确认：


所以，Post-Execution阶段首先要处理的是：
把执行结果从简单success/failure，
转化为可审计、可追踪、可用于后续治理的结构化结果。

2.7.2 State Update：执行结果必须回写系统状态

企业级 Agent 的行动，最终会改变企业运行系统中的状态。
这些状态可能是业务对象状态：


也可能是流程状态：


也可能是系统状态：


Post-Execution 阶段要做的，是把这些结果回写到系统状态中。
这一步非常关键。如果执行结果没有回写，系统就会出现治理断层：


这种情况下，后续 Agent 推理、workflow 执行、
policy evaluation 和审计都会基于错误或过时状态继续运行。

因此，Post-Execution的第一层闭环是：
执行结果必须变成系统状态，而不是停留在工具返回值。

这也对应前文的一个关键原则：
行动治理不是到执行为止；行动治理必须回到状态。
没有状态回写，就没有真正的闭环控制。

2.7.3 ExecutionRecord：把一次行动变成可审计历史

状态更新回答的是：系统现在变成了什么状态？
但审计还需要回答：为什么会变成这个状态？
这就需要ExecutionRecord。
它不是普通log，而是一次受治理行动的完整记录。
它至少应该能够关联：


一个简化的ExecutionRecord:



这类记录让系统可以在事后回答：


这就是ExecutionRecord的价值：把一次行动从不可解释的副作用，
变成可审计、可追溯、可复现的治理历史。

2.7.4 Audit与Provenance：记录不只是为了事后追责

在企业系统中，audit常常被理解为“出事后查日志”。
但在企业级Agent行动治理中,
audit和provenance的价值更广。

它至少有四个作用。

第一，责任归属。系统需要知道：


尤其在Agent 参与行动之后，责任链不能停留在“模型做的”。
系统必须能够区分：


第二，决策复现。

系统需要在事后重建：


如果这些信息不可复现，
企业就无法证明当时的行动是合规、合理、可控的。

第三，治理改进。

ExecutionRecord可以反向帮助系统发现：


这让 audit 不只是事后追责，也成为治理系统优化的数据来源。

第四，后续决策输入。
过去的执行记录和状态变化，
会成为下一次 Decision Context 的一部分。
例如：

这些都应该影响后续行动是否被允许。
因此，Audit/Provenance不只是记录系统，
而是治理闭环的一部分。

2.7.5 Feedback Context：
执行结果必须回到下一轮推理与裁决

Post-Execution的最后一层，是feedback。
这里的feedback不是简单把执行结果告诉LLM，
而是把执行后的状态、记录和风险信号，回到后续系统运行中。
它至少有两类反馈。

第一类是 Reasoning Feedback，
也就是给后续模型推理使用的反馈。
例如：


这些信息会影响Agent下一轮推理。
如果模型不知道行动已经发生，它可能重复执行；
如果模型不知道执行失败，它可能错误地认为流程已经完成；
如果模型不知道客户已经收到通知，它可能重复发送。

第二类是 Decision Feedback，
也就是给后续治理裁决使用的反馈。

例如：

这些信息不一定需要全部进入模型上下文，
但必须进入后续Decision Context。
这也对应前面提到的 Dual Context Model：
Reasoning Context:帮助模型决定下一步可能做什么.
Decision Context:帮助系统决定下一步是否允许做.

Post-Execution 的 feedback 不能只喂给模型，
也必须喂给治理系统。

否则系统就会出现：


真正的闭环要求：执行结果既能影响下一轮推理，
也能影响下一轮裁决。

2.7.6 失败、补偿与恢复也必须进入闭环

Post-Execution不只处理成功结果，
也必须处理失败、补偿和恢复。
这是企业级系统和普通工具调用的又一个差异。
普通工具调用失败，系统可能只返回：error.

但企业级行动失败后，系统需要进一步判断：


比如生产资源删除失败：


因此，ExecutionRecord不能只记录成功路径，
也必须记录失败路径和恢复路径。
从治理角度看，失败不是链路之外的异常，
而是治理对象的一部分。可以这样理解：


这也是为什么 Post-Execution 是治理闭环，
而不是简单 logging。

2.7.7 Palantir AIP的启发：
执行结果必须回到状态、血缘与审计闭环

在Palantir AIP/Foundry这样的system-centric平台中，
行动执行完成之后，并不会停留在一次孤立的API response上。

更重要的是，执行结果需要回到企业运行系统中，
成为对象状态、流程状态、血缘记录、审计记录和后续反馈的一部分。

也就是说,Palantir-like平台中的Post-Execution不是：
API call->success/failure 
而更接近：


这层能力可能分布在多个平台机制中：


它的的核心价值在于：行动不是执行完就结束，
而是被写回企业系统，成为后续推理、后续裁决、
事后审计和治理优化的依据。

例如，一次客户合同变更通知发送完成之后，系统不应该只记录：
email API returned success.
而应该能够更新或记录：


这样，后续系统才能知道：


从开放实现类Palantir平台的角度看，这里最值得抽象的是：
执行结果不应该只是 log，
而应该成为可被后续系统引用的治理事实。

这正是MSCL中Execution->ExecutionRecord->Feedback
想要显性化的部分：


其中：


这样做的价值是：


因此，Palantir AIP给我们的启发是：
企业级Agent的行动执行结果，必须回到状态、血缘与审计闭环中。

MSCL则进一步把这层闭环抽象为ExecutionRecord：
它不是普通日志，而是一次受治理行动在系统中的可审计历史。

2.8 Palantir AIP证明了系统级行动控制链路的必要性

通过前面几个阶段的拆解，可以看到，
Palantir AIP的关键并不是简单地把LLM 接入企业数据，
也不是让Agent获得更多工具调用能力。
它更多体现的是一条system-centric的企业级Agent行动治理链路。

这条链路从design-time的语义建模开始，
到post-execution的审计与反馈闭环结束，
核心目标是把LLM生成的行动意图，
纳入一个可建模、可绑定、可裁决、可授权、可执行、
可记录的企业运行系统中。

可以回顾一下导言中的图一所示的一整条链路.
这条链路说明，企业级 AI Agent 的核心是：
模型提出的行动，能否被企业系统语义化、绑定、裁决、
授权、执行、记录和反馈。

PalantirAIP的启发在于：
企业级 Agent不是一个独立行动者，
而是企业运行系统中的一部分。

Agent可以提出行动，但行动是否发生、如何发生、
在什么边界内发生、发生后如何记录，必须由系统来治理。
Palantir AIP 展示了一种非常重要的企业AI平台范式：


Palantir AIP它更接近一套企业行动系统：让LLM进入企业，
但不让LLM直接支配企业行动。

它不是把模型能力裸露给系统，而是通过Ontology、Action、
Function、Policy、Security、Runtime、Provenance 与 
Audit，把模型生成的行动意图放进一条受治理的执行链路中。

这条链路有几个关键特征。

第一，行动空间是被建模出来的。
Agent面对的不是开放工具集合，而是由业务对象、
Action Types、Functions
和治理约束共同定义的企业行动空间。

第二，模型上下文是被裁剪出来的。
Pre-LLM阶段不是全量暴露企业世界，而是根据身份、权限、
任务、对象实例和可见行动空间，构造模型可见企业世界。

第三，模型输出不是执行许可。
LLMOutput只是候选行动调用，需要经过normalization、
semantic binding 和 governance preparation，
才能成为可裁决的 ActionProposal。

第四，执行前治理是真正的executiongate。
系统必须基于ActionProposal、DecisionContext、
policy、risk、approval和runtimeenvironment，
生成明确Decision，而不是让模型自我判断。

第五，执行必须发生在授权边界内。
Execution不是API调用成功,而是在Decision/ExecToken 
定义的边界内产生受控副作用。

第六，执行结果必须回到治理闭环。
Post-Execution不是简单log,而是状态更新、
ExecutionRecord、Audit Provenance与Feedback,
使后续推理和后续裁决能够基于真实结果继续运行。

在Palantir中，这条行动控制链路是强大的，
但它主要是平台内嵌的。
它分布在Ontology、Action、Function、
Dynamic Security、Policy、Runtime、Provenance、
Audit、Workflow等平台机制中，
并不一定作为一组独立、开放、可移植的语义对象暴露出来。

也就是说，Palantir 证明了系统级行动控制的必要性，
但这套控制语义本身仍然深嵌在平台内部.

这正是下一篇文章
(从Palantir内嵌控制到MSCL：开放行动控制语义的抽象)
接下来要进一步讨论的地方：
如果Palantir AIP已经证明了企业级Agent行动控制链路
的必要性，那么这条链路中最小、最关键、最通用的控制语义，
是否可以被抽象出来?也就是：


如何能成为一套开放、显性、可验证、可复用的行动控制语义