26年4月来自哈工大、Heriot-Watt大学马来西亚分校和苏州大学的论文“Harnessing Embodied Agents: Runtime Governance for Policy-Constrained Execution”。

具身智体正迅速从被动的推理系统演变为主动的执行者，能够与工具、机器人及物理环境进行交互。尽管近期的进展显著提升了规划、工具使用及长周期任务执行的能力，但也暴露出一个日益突出的系统性挑战：一旦具身智体被赋予执行权限，核心问题便不再仅仅是如何使其采取行动，而是如何在运行时确保其行动的可控性。现有的方法往往将安全性、故障恢复及决策约束直接嵌入到智体自身的运行循环（agent loop）之中，这使得执行控制难以实现标准化、审计及跨环境的自适应。

本文主张，具身智能不仅需要更强大的智体，更需要强有力的运行时治理机制。为此，提出一种针对“策略约束执行”的运行时治理框架，旨在将智体的认知决策与执行监管职能相分离。该框架并未将所有的控制逻辑内嵌于智体内部，而是将治理职能外化至一个专用的运行时层级，由该层级负责执行策略检查、能力准入、执行监控、回展（rollback）处理以及人工干预等任务。这种设计使得具身智体在保持其持续运行特性的同时，能够灵活地调用并迭代自身的能力，且始终受制于明确的运行时约束。

本工作的核心理念在于：可靠的具身执行应当在运行时层级进行治理，而非完全托付给智体模型自身。对具身智体、具身能力模块（ECMs）以及运行时治理层之间的控制边界进行形式化定义，并构建一条专为仿真环境与现实世界部署场景设计的“策略约束执行”流水线——该流水线已在仿真环境中得到验证。其实现一个参考原型系统，并通过一系列仿真实验对其性能进行验证。实验共包含1000次随机试验（涵盖5组随机种子 × 200次试验），评估维度涵盖三个治理层面：未经授权行为的拦截、运行时违规行为的检测，以及故障恢复/回展（rollback）机制的有效性。

实验结果显示，本文提出的框架在拦截未经授权行为方面取得 96.2% ± 2.7% 的拦截率；在遭遇运行时漂移（runtime drift）时，能将智体继续执行不安全操作的概率从 100% 显著降低至 22.2% ± 3.1%；此外，该框架在实现完全策略合规的前提下，取得 91.4% ± 3.0% 的故障恢复成功率。上述各项指标均显著优于“直接执行”、“静态规则”以及“能力内嵌式”等基准方法（所有对比结果的 p 值均小于 0.001，经配对 t 检验）。一项组件级消融实验证实，各个治理子系统均发挥着独特的作用：移除“执行监视器”（Execution Watcher）将导致所有运行时检测功能失效；而移除“恢复管理器”（Recovery Manager）则会导致恢复成功率骤降至 28.1%。在一组模拟审批条件下进行的专门人工干预评估显示，该干预界面能够 100% 拦截那些未经批准的高风险请求——若无此干预，此类请求在 34.2% 的情况下本将继续执行。

通过将运行时治理重新定义为一个“第一类”系统问题，本文确立“受策略约束的执行”作为具身智体系统的核心原则；并主张未来的机器人软件栈在设计时，不应仅着眼于执行功能本身，而更应致力于实现“可治理的执行”。

---

具身智体正从被动的推理与对话辅助阶段，迈向在物理世界中进行持续执行的新阶段。近年来，大模型 [1–3]、工具使用 [4–6] 以及机器人策略学习 [7, 8] 领域的显著进展，使得构建单一的智体系统变得日益可行——该系统能够解读目标、调用能力、与机器人及软件工具交互，并在动态环境中完成跨越长时程的任务 [9, 10]。然而，在这一新兴场景下，核心挑战已不再仅仅是如何驱动智体采取行动，而是如何确保其在运行时采取的行动是可控的。

这种转变具有根本性的意义。一个具备执行能力的系统，未必就是一个能够在明确约束下执行、在运行过程中保持可观测、以受控方式从故障中恢复、或在必要时将控制权移交给人类的系统。随着具身智体开始接入各类工具、执行器、传感器以及现实世界的执行通路，运行时故障所带来的代价已与纯数字环境下的情况产生了本质上的差异。错误不再局限于给出错误的响应或 API 调用失败；相反，它们可能导致不安全的动作、未经授权的操作、不稳定的故障恢复行为，甚至导致智体长期偏离既定的部署策略。

现有的具身智体系统在规划、动作生成、策略学习和任务执行等领域已取得了重要进展 [9, 11, 12]。然而在许多情况下，负责调控执行过程的逻辑仍与智体本身紧密耦合、纠缠不清。安全启发式规则、故障恢复策略、审批条件以及动作约束等要素，往往被直接嵌入到提示（Prompts）、智体循环、任务策略或临时的控制器逻辑之中。尽管此类设计对于特定域的狭窄任务或高度受控的演示场景可能行之有效，但当同一个具身智体需要在仿真环境、实体机器人、不断变化的部署情境以及人机交互环境中跨域运行时，上述设计便会变得愈发难以实现标准化、审计、验证与自适应调整。

智体系统与运行时“驾驭”（Runtime Harnesses）的兴起

近期的智体系统已将关注焦点从被动的语言交互，转向那些能够调用工具、操作软件环境并跨多步任务保持状态持续的系统 [15, 16]。在此背景下，围绕智体的执行环境变得日益重要。近期关于“驾驭工程”（harness engineering）的讨论，将这一转变解读为：不再仅仅孤立地优化智体本身，而是转向设计相应的工具、防护栏（guardrails）、评估机制以及运行时控制界面，从而确保智体始终处于“受控”状态 [14]。这一新兴观点与工作尤为契合，因为它突显一个关键事实：实际应用中的瓶颈已不再局限于智体本身的智能水平，而更多在于负责协调执行过程的系统层。

与此同时，围绕 OpenClaw 类生态系统的近期研究，进一步揭示了具备执行能力的智体所蕴含的机遇与风险。例如，近期针对 OpenClaw 的研究分析了个性化本地智体如何遭受操纵或颠覆 [17]；这些研究强调指出，强大的执行权限会引入新的攻击面和治理难题，其复杂程度远超普通聊天机器人的应用场景。上述发展趋势印证了本文所提出的论点：一旦智体具备实际行动的能力，运行时治理便不再是可有可无的安全附加组件，而是必须优先解决的核心系统工程问题。

然而，当前关于“驾驭”的大多数讨论仍主要聚焦于软件智体、编程智体或桌面执行环境。本文工作与之不同，其研究的是“具身环境”（embodied settings）下的运行时治理问题。在具身环境中，任务执行过程在物理空间中随时间展开，直接作用于执行器与传感器；且在特定部署策略的约束下，可能还需要引入中断、状态回展（rollback）以及人工接管等干预机制。从这一意义上讲，这一新兴的“驾驭”视角已经拓展到具身人工智能（Embodied AI）与机器人软件系统领域。

具身智体与长时程机器人任务执行

近年来，具身人工智能领域正朝着更具智体特质、且能力日益增强的机器人行为控制方向迈进，尤其是在受语言指令引导及涉及长时程任务的场景中。RoboClaw [9] 便是一个极具代表性的案例；该项目提出一种智体驱动的机器人框架，通过单一的“视觉-语言模型”（VLM）控制器，将数据采集、策略学习与任务执行三大环节有机地整合在一起。RoboClaw 引入“纠缠动作对”（Entangled Action Pairs, EAP）机制，将正向执行动作与逆向恢复动作进行耦合，从而实现可自动重置的数据环，并显著提升长时程任务的执行成功率。该论文报告称，相对于其基线系统，其在长周期任务成功率方面实现了 25% 的提升，在人工时间投入方面则减少了 53.7%。

这一研究方向之所以重要，是因为它表明具身系统正日益能够将推理、策略选择和执行整合到一个统一的控制回路中。本文工作与这一研究议程相辅相成，而非相互对立。RoboClaw 主要探讨的是：单个智体控制器如何支持可扩展的长周期机器人任务。相比之下，本文关注的是另一个不同的系统性问题：一旦具身智体获得了执行权限，其在运行时期的行动应当如何受到约束、监控、中断、恢复和监管？换言之，既往工作在“具身智体如何行动”这一问题上已取得了长足进步，而本文工作则聚焦于“具身智体在行动过程中如何保持可控性”。

在更广阔的具身智体研究领域中，涌现出了许多能够展现出持续且自适应智体行为的系统：Generative Agents [18] 证明了由大语言模型（LLM）驱动的智体能够保持长期的行为一致性；ProgPrompt [19] 引入了针对情境化机器人任务规划的“程序化提示”技术；而 Voyager [20] 则展示了在具身环境中实现开放式终身学习的可能性。近期的综述文献 [12, 21] 反复指出，安全性、实时约束执行以及运行时可靠性，依然是具身系统在实际部署过程中尚未解决的难题。诸如 CARLA [22] 和 Gazebo [23] 之类的仿真平台虽然为安全性基准测试提供了支持，但其关注重点在于环境的逼真度，而非系统的治理架构。近期的一项基准测试 EARBench [24] 直接评估了基于基础模型的具身智体对物理风险的感知能力；另一项名为 SafeAgentBench [25] 的基准测试则为具身 LLM 智体的安全任务规划提供了全面的评估体系，该测试结果显示，即使是那些在设计上最为注重安全性的基线系统，对于危险任务的拒绝率也仅为 10%。这些实证结果有力地证明了当前系统在风险识别能力方面存在显著的短板——而这正是本文所设计的“治理层”旨在弥补的缺陷。尽管源自空间机器人领域的“故障检测、隔离与恢复”（FDIR）技术 [26] 为构建结构化的故障恢复流程提供了先例，但这些技术往往具有特定的域局限性。上述综述文献均强调对轻量级运行时监控、开销受控的安全约束执行机制，以及在充满不确定性的现实世界环境中实现鲁棒执行能力的迫切需求。本文工作通过将运行时治理确立为明确的架构与评估目标，而非将其视为次要的实现细节，从而弥补了这一空白。

安全机器人学、运行时监控与约束强制执行

大量的机器人学研究通过控制器设计、反应式防护 [27, 28]、控制障碍函数（barrier function） [29, 30]、约束策略优化 [31, 32] 以及运行时监控 [33] 等手段来解决安全性问题。关于安全强化学习 [34, 35] 以及自主系统鲁棒控制这一更广阔领域 [36] 的综合综述均确立了这样一个观点：具身执行（embodied execution）不能被视为一种无约束的动作生成过程。Simplex 架构 [37] 开创性地提出了“高保障控制器”这一概念，即允许该控制器接管并覆盖那些虽高性能但验证程度较低的控制器；这一思想预示所提出的“外部化运行时权限”这一概念。同样，Seldonian 框架 [38] 证明了在策略改进过程中，无需将安全约束内嵌于学习目标函数本身，即可对这些约束进行强制执行。工业机器人与服务机器人领域的安全标准 [39, 40] 进一步以规范形式确立了在已部署系统中对运行时监控、紧急停止以及人工接管功能的需求。系统论视角的安全工程 [41] 以及自动驾驶车辆安全分析 [42] 进一步强化了这样一个更宏大的原则：安全性本质上是一个控制问题，而不仅仅是某个单一组件所具备的属性。

近期关于基于大语言模型（LLM）的机器人异常检测研究 [43] 表明，基础模型（foundation models）能够执行实时异常检测与反应式重规划任务，从而为所设计的“治理层监视器（watcher）”机制提供了一种在能力层面上相互补充的辅助机制。

然而，上述文献中的大部分工作往往仅聚焦于低层级的安全强制执行，或是针对特定任务的流水线设计；它们鲜少触及这样一个系统层面的核心问题：面对模块化的能力组合、动态变化的环境特征以及人工监管下的执行模式，一个具备持续运行能力的具身智体（embodied agent）究竟应当如何进行治理？本文工作立足于运行时安全与监控背后的基本理念，但将视角从“控制器层面的安全”提升至“基于策略约束的执行过程之运行时治理”——这一治理过程涵盖了完整的生命周期：从能力提案与准入审批，到策略的强制执行，再到由监视器驱动的干预、状态回展（rollback）以及审计复核。

基于大语言模型的智体之运行时强制执行

近期关于安全型大语言模型智体的研究已开始更为明确地探索“运行时强制执行”这一课题。 AutoRT [44] 展示了如何利用一种“机器人宪法”（robot constitution）对机器人智体进行大规模编排；该宪法通过一个基于大语言模型（LLM）的“critic”来过滤不安全的任务提案。这是目前与治理方法最为接近的现有系统，尽管 AutoRT 的宪法机制主要充当一种“执行前过滤器”，而非一种具备监控、恢复及人工干预能力的“持续运行时治理层”。SafeEmbodAI [45] 针对具身智能（Embodied AI）系统中的移动机器人提出了一套安全框架，该框架整合安全提示工程与状态管理机制，旨在抵御恶意指令注入攻击，但并未涉及运行时执行监控或结构化恢复等环节。GuardAgent [46] 引入一种“守卫智体”（guard agent），能够动态生成“护栏代码”以保护目标智体；该系统在医疗保健领域的访问控制基准测试中取得超过 98% 的准确率，但其关注重点在于数字智体的安全性，而非具身智体的物理执行安全性。RoboGuard [47] 针对基于 LLM 的机器人提出一种两阶段式“护栏架构”，成功将不安全规划的执行率从 92% 降低至 2.5% 以下；这是目前在具身智能安全领域与本文系统最具直接可比性的工作。然而，RoboGuard 的侧重点在于“执行前规划过滤”，而非具备恢复与回展（rollback）机制的“持续运行时治理”。

AgentSpec [48] 深入研究了针对 LLM 智体的“可定制运行时强制执行”机制，并针对多个应用领域（包括涉及机械臂操作的具身智能场景）对该机制进行了评估。NeMo Guardrails [49] 提供了一套工具包，用于为 LLM 应用构建可编程的“运行时护栏”；近期的一项研究 [50] 更进一步，专门针对基于 LLM 的机器人提出了特定的安全护栏方案。TrustAgent [51] 引入了一种“智体宪法”（agent constitution）概念，其中包含了“规划前、规划中及规划后”三个阶段的安全策略；这种流水线式的架构设计与本文所采用的“准入/监控/恢复”三个阶段的架构设计在理念上颇为相似，尽管 TrustAgent 的应用对象是数字智体而非具身智体。Pro2Guard [52] 由 AgentSpec 团队开发，将运行时强制执行机制进一步扩展至“基于马尔可夫链模型”的概率性违规预测领域；该系统能够在违规行为实际发生之前便实施主动干预，从而为本文系统中负责被动响应的“执行监视器”（Execution Watcher）提供一种极具互补性的能力。运行时验证理论 [53] 提供了一套坚实的理论基础，用于针对既定的“时序属性”（temporal properties）对智体的执行轨迹进行形式化监控与验证；这一理论视角为本文设计“执行监视器”模块提供了重要的指导与启示。本文工作在范畴上与上述所有方案均有所不同：其围绕三个明确的实体（持久化具身智体、模块化能力包以及运行时治理层）构建治理体系，并着重强调持续的运行时治理——这不仅涵盖执行前的过滤，还将执行监控、故障恢复与回滚纳入治理职能范畴，同时引入环境感知型策略配置文件，并将人工干预作为治理流程中的一个结构性组件。

“驾驭具身智体”（Harnessing Embodied Agents）

本文主张，具身智能不仅需要更强大的智体，更需要一套强健的运行时治理机制。其将这一理念概括为“驾驭具身智体”（Harnessing Embodied Agents）：不应预设智体自身必须内化所有的安全、恢复与执行控制逻辑，而是建议将这些职责外化，交由一个专门的“运行时治理层”来承担。在此架构下，智体仍将专注于负责任务理解、规划以及能力调用等核心职能；治理层负责在明确的策略约束下，判定执行过程是否获准进行、何时启动以及如何展开。因此，关注重点在于“执行边界”——即具身智体从意图向行动转化的操作层级；正是在这一层级上，能力准入、策略执行、过程监控、回展（rollback）处理以及人工干预等机制必须得到明确的界定。

基于这一视角，其提出一种针对策略约束执行的运行时治理框架。该框架将当前具身系统中常被混淆的三种角色进行分离：作为决策主体的“持久化具身智体”（Persistent Embodied Agent）、作为可执行单元的“能力包”（Capability Package），以及作为约束与监督执行之权威的“运行时治理层”（Runtime Governance Layer）。这种分离机制建立在一篇姊妹论文AEROS [13] 中所引入的单智体运行时架构及“具身能力模块”（ECM）抽象概念的基础之上。推动这一分离的动因源于三项观察：(i) 具身系统日益需要能够跨越不同任务持续运作的智体，而非仅局限于孤立的单行为策略；(ii) 此类智体所具备的可执行能力正趋于模块化与可更新化，这使得在“能力层级”上实施治理比采用“整体式控制”更为切实可行；(iii) 不同的部署环境在可接受的操作边界上存在显著差异——在仿真环境中被允许的动作，在真实机器人上执行时可能存在安全隐患，或在人机共存的环境中需要获得人工审批。

本文对这三个实体之间的控制边界进行形式化定义，并构建一条“策略约束执行流水线”；在该流水线中，智体所提议的动作需依次经过能力准入、策略校验、执行监督、异常中断触发、状态回展（rollback）处理以及人工干预（Override）等环节的中介与调控。本设计并未将治理机制视为一种辅助性的安全保障手段，而是将其确立为一种核心的运行时架构组件；这一设计理念能够独立于智体模型本身去推演与分析系统的“可治理性”，并能够在无需重写智体代码的前提下，灵活地调整与适配操作策略。

本文是一篇专注于具身执行过程之“运行时治理框架”的论文。研究目标并非要在任务成功率等指标上与 RoboClaw [9] 之类的系统展开竞争，而是旨在解决一个具有互补性的关键问题：随着智体能力的不断增强，如何确保具身执行过程始终保持在策略约束之下，并具备良好的可观测性、可恢复性与可审计性。

如图 1 所示本文核心理念。(a) 在非受控执行模式下，具身智体直接调用各项能力，无需经过策略检查、运行时监控或故障恢复支持。(b) 框架在智体认知与物理执行之间引入一个“运行时治理层”：每一次能力调用均需通过准入控制、策略检查及执行监控；此外，运行时还可提供故障恢复与人工干预（覆盖）功能。这种架构分离机制使得执行过程具备策略约束、可观测、可恢复及可审计的特性，且无需对智体模型本身进行任何修改。

1 问题陈述

考量一种具身智体系统，该系统在较长的时间跨度内运行，并通过可执行的能力与物理环境进行交互。与纯粹的对话式智体不同，此类系统的运行过程并非止步于生成响应。相反，它必须将高层级意图转化为情境化的具体执行，这一过程往往需要在不断变化的环境条件下，调用特定的技能、工具、控制器或机器人专用程序来实现。

本文所要解决的核心问题如下：
如何使具身智体能够实现持续且自适应的执行，同时确保其执行过程在明确的运行时约束下是可管控的？

这一问题的产生源于具身执行所引入的一种结构性张力（tension），即智体的自主性与操作控制之间的矛盾。一方面，智体必须保持足够的自主性，以便解读目标、编排动作并响应不断变化的情境。另一方面，部署系统必须确保智体的各类动作始终受限于安全要求、特定环境规则、组织策略以及人类的监管权限。若将这些约束条件隐式地处理于智体内部的运行循环之中，那么对执行过程进行管控（即“执行治理”）将变得难以审查、难以标准化，也难以在不同应用场景之间进行迁移复用。

因此，将“受策略约束的执行”视为一个系统工程层面的问题，而非单纯的模型层面的问题。其核心挑战不仅在于具身智体能否生成一套动作规划，更在于其所产生的具体执行过程，能否通过一套明确的运行时机制，实现有效的准入、监控、中断、恢复与审计。

2 系统假设

假设存在一个具备以下特性的具身系统：

1. 持久的智体身份。该系统包含一个具有持久性的具身智体；该智体能够在跨交互过程中保持任务的连续性，而非仅仅充当一个无状态的、针对特定任务的控制器。
2. 模块化的可执行能力。智体并不直接自行实现所有的底层执行逻辑。相反，它会调用一系列模块化的可执行单元——在此称之为“能力包”（capability packages）——这些单元封装各类技能、控制器、工具或可执行程序。
3. 依赖于环境的约束。同一种能力在某种部署条件下可能是允许执行的，但在另一种条件下则可能受到限制。例如，在仿真环境中可接受的动作，在物理机器人上执行时可能会被禁止，或需要经过审批。
4. 运行时的变异性与故障。由于传感器噪声、工具不可用、执行机构不稳定、策略不匹配或环境扰动等因素，执行过程可能会发生故障。因此，系统必须支持运行时的监控与故障恢复机制。
5. 人类监督的可能性。至少在某些应用场景下，人类可以对执行过程进行审查、中断、审批或接管（覆盖）。人类的干预并非被视为一种事后补救，而是被纳入系统的治理模型之中，成为其有机组成部分。

上述假设在设计上刻意保持广泛性。它们适用于各类系统，涵盖了基于仿真的具身智体、机器人操作智体、移动机器人助手，以及混合式的虚实融合智体平台。

3 核心实体

在系统中定义三个主要实体：具身智体（Embodied Agent）、能力包（Capability Package）和运行时治理层（Run-time Governance Layer）。

具身智体

具身智体是系统中的持久性决策主体。它负责解读用户目标或任务目的，维护任务层面的上下文与连续性，选择或组合各项能力，提出执行规划，并在规划层面响应运行时反馈。

值得注意的是，并不假定具身智体拥有不受限制的执行权限。其职责在于生成预期的动作及能力调用请求，但无权单方面决定这些动作在当前的运行情境下是否获准执行。

形式化地，设时间步 t 时的具身智体表示为：

A_t = (I_t, M_t, G_t, P_t) (1)

其中，I_t 表示智体当前的身份标识与状态连续性；M_t 表示记忆及与任务相关的上下文信息；G_t 表示当前活跃的目标；P_t 表示所提出的规划或动作意图。关键在于，P_t 仅为一项执行提案，而非执行动作本身。

能力包

能力包是一种可执行单元，用于封装具有明确边界的操作功能。根据具体的部署环境，能力包内可包含机器人技能、运动原语、控制器封装模块、工具使用流程、感知-动作例程、故障恢复行为，或复合型工作流。

能力包充当高层级智体意图与底层具体执行基座之间的边界。假定每个能力包均对外暴露一套机器可读的接口，并附带足以支撑运行时治理所需的元数据。将能力包 C_i 表示为：

C_i = (名称, 接口, 前置条件, 后置条件, 权限, 风险, 回展, 环境配置文件) (2)

其中，“名称”用于标识该能力；“接口”指定其输入、输出及调用结构；“前置条件”定义了执行有效的必要条件；“后置条件”描述了预期的执行结果或完成信号；“权限”指定了所需的授权或策略适用范围；“风险”表征了操作风险等级；“回展（rollback）”指定是否支持恢复或撤销操作，以及具体支持方式；而“环境配置文件”则指明环境兼容性（例如：仅限仿真环境、允许在实体机器人上执行、或需经人工审批等）。

这种能力包抽象机制使得在能力层面上实施治理成为可能。运行时环境不再仅仅针对自由形式的动作进行推理，而是能够针对已声明的可执行单元进行推理。

运行时治理层

运行时治理层是本文研究的核心对象。这是一个专用的操作层，负责在智体意图与具身执行之间进行协调与中介。其宗旨在于确保每一个可执行的状态转换过程均处于明确的运行时控制之下。

运行时治理层主要负责以下职能：能力准入管理、策略评估、执行过程监控、异常触发式中断、回展（rollback）或恢复任务分派、人工审批与干预（覆盖）、以及日志记录与审计追踪生成。

将时刻 t 的运行时治理状态表示为：

R_t = (Π_t, Γ_t, Ω_t, Λ_t) (3)

其中，Π_t 表示当前处于激活状态的策略集合；Γ_t 表示当前的治理上下文（包含环境状态与权限状态）；Ω_t 表示运行时观测数据与执行遥测数据；而 Λ_t 则表示干预状态（包含审批决策、中断指令及回展决策）。

运行时治理层负责判定智体所提议的动作是否获准执行、在何种条件下获准执行，以及在动作执行期间应启用哪些监控或干预机制。

4 控制边界

本文的一个核心论点在于：具身系统需要在以下三个实体之间确立明确的控制边界——智体（Agent）负责提出其意图执行的动作；能力包（Capability Package）负责定义哪些动作是可执行的；而运行时治理层（Runtime Governance Layer）则负责裁定当前时刻实际允许执行的动作。

这一关系可表述为一种受约束的执行关系：

E_t = F(A_t, C_i, R_t) (4)

其中，E_t 表示时刻 t 的实际可执行动作；函数 F 并非智体意图的直接投射，而是一种经由治理机制中介转换后的结果。换言之，实际执行并非简单的 E_t = P_t，而应表述为：

E_t = GOV(P_t, C_i, Π_t, Γ_t, Ω_t) (5)

其中，GOV(·) 代表运行时治理函数。这一公式化表述强调指出：智体并不直接拥有执行权。智体仅拥有动作的提议权与自适应权，而实际的执行权限则是由运行时治理层有条件地授予的。

5 策略约束执行

现在，定义本文的主要执行模型。

定义 1（策略约束执行）。如果系统中每一个由智体（Agent）发起的、可执行的动作，仅在经过针对一组显式运行时策略集的评估之后才被准许并执行，且在整个执行过程中始终处于运行时监视、中断及治理干预的管辖之下，则称该系统展现出“策略约束执行”特性。

该定义包含四层含义：(1) 执行前的准入：动作在进入执行环境之前即须接受检查。(2) 执行中的约束：治理机制在动作获准后仍持续生效，而不仅仅局限于执行前的预检阶段。(3) 异常或升级时的干预：运行时监视器有权中断或重定向执行流程。(4) 环境敏感型强制执行：同一项能力在不同的部署情境下，可能会受到截然不同的约束。

这一特性将策略约束执行与两种较弱的执行模式区分开来：一是“无约束执行”，即智体直接调用动作，无需任何治理机制的中介；二是“静态预验证执行”，即动作仅在执行前接受一次验证，而在运行时不再受到监视。与此不同，本文所提出的模型要求治理机制必须贯穿于整个执行生命周期的始终。

6 治理职能

将运行时治理建模为基于智体提案和执行状态的四项可组合职能。

能力准入（Capability Admission）负责判定准入资格：Admit(cˆ_t, Π_t, Γ_t) → {0, 1}。
策略检查（Policy Check）负责评估当前生效的约束条件：Check(cˆ_t, x_t, Π_t, Γ_t) → {allow, modify, deny, escalate}；其中，modify（修改）操作旨在将执行过程重塑为符合策略要求的形式。
执行监控（Execution Monitoring）负责观测运行时信号：Ω_t = Observe(s_t, a_t, o_t)。
干预（Intervention）职能针对违规行为采取行动：Intervene(Ω_t, Π_t, Γ_t) → {continue, pause, stop, rollback, handover}。

7 环境配置文件

将运行时治理职能外部化的主要动因在于：不同运行环境下的操作约束往往各不相同。因此，定义一种环境配置文件（Environment Profile）E，用于对策略的执行过程进行参数化配置。具体的示例包括：

仿真环境配置文件——其特征是放宽力学限制、无需人工审批、且具备更宽泛的故障恢复容忍度；
实体机器人环境配置文件——其特征是具备更严格的运动约束、感知硬件状态的安全限制、以及明确的回展操作要求；
人机共享环境配置文件——其特征是特定动作需经审批、划定受限移动区域、且对中断信号具有更高的敏感度；
测试环境配置文件——其特征是扩展日志记录范围、强制捕获审计数据、并包含回展性能基准测试功能。

因此，运行时治理的决策依据不仅取决于动作类型，还取决于当前所处环境配置文件的具体设定：

Π_t = Π(E, O, H) (6)

其中，E 代表环境配置文件，O 代表组织层面的策略或部署策略，H 代表人工权限配置。这种建模方式有助于实现策略的可移植性，从而避免针对每一个具体的部署场景都必须重写智体自身代码的繁琐工作。

8 故障与恢复模型

具身执行必须将运行时故障视为一种正常的运行状况。因此，不将故障建模为一种罕见的异常，而是将其视为一种预期的状态转换。

令 X_t 表示一个执行故障事件。此类事件可能源于能力前置条件失效、执行超时、感知不一致、物理不稳定性、进入不安全状态、策略违规，或工具/执行器不可用。

一旦发生 X_t 事件，运行时治理模块将分派一项恢复策略：

ρ_t = Recover(X_t, C_i, Π_t, Γ_t) (7)

可能的输出包括：在有限资源预算内重试、调用恢复能力、回展至先前的安全状态、请求人工审批，或终止执行并重新规划。这种建模方式将恢复过程提升为一种治理决策，而非嵌入在每个具体能力内部的临时性行为。

9 人类权限模型

人类的参与在治理层中得到了显式体现。不预设智体总是完全自主的，也不认为所有的人机交互都必须发生在执行流程之外。

令 H_t 表示当前的人类权限状态。根据部署策略的不同，运行时治理模块可能要求进行执行前审批、执行中确认、接管请求、强制终止，或执行后审查。因此，人类决策可被建模为：

u_t = HumanApprove(cˆ_t, Π_t, Γ_t) (8)

并被整合进最终的治理决策结果中。这使得“人机在环”（Human-in-the-loop）式的监督成为了运行时模型的一等公民，而不再是游离于系统定义之外的某种备用手段。

10 设计目标

基于上述系统架构，本文的设计目标并非不惜一切代价去最大化纯粹的自主性，而是致力于优化“可治理的具身执行”。具体而言，旨在构建具备以下特性的系统：

• 可执行性：智体能够通过调用各项能力来完成有用的任务。
• 可治理性：每一个执行步骤均受制于显式的运行时控制。
• 适应性：策略与约束条件可在不同环境中进行调整，而无需重写智能体代码。
• 可恢复性：故障发生时，能够触发显式的恢复或回展流程。
• 可审计性：执行结束后，所有的决策与干预操作均可供追溯与审查。
• 可中断性：在必要时，人类或系统能够通过干预手段暂停或重定向执行流程。

这些属性定义该系统针对具身智体的运行时治理目标。

---

1 概述

在此介绍一种运行时治理框架，该框架将上述系统模型付诸实践。该框架由六个相互协作的组件构成：(1) 能力准入模块，(2) 策略守卫模块，(3) 执行监视模块，(4) 恢复与回展管理器，(5) 人工干预接口，以及 (6) 审计与遥测层。这些组件共同构成一条治理流水线，其位置介于智体意图与执行基底之间。

2 设计原则

该框架的设计遵循五项基本原则。

认知与治理的分离

智体仍负责任务解读、规划及能力选择，但治理逻辑并不直接嵌入智体内部。这种设计确保执行控制过程始终具备可审查性、可配置性，并能在不同的部署环境中实现跨环境移植。

以能力为中心的强制执行

运行时约束的强制执行作用于“可执行能力包”这一层级，而非仅作用于智体产生的“自由形式输出”层级。这使得策略检查过程更为显式化，且更易于机器自动执行。

持续性治理

治理并非仅限于执行前的一次性验证。它贯穿于整个执行过程之中，从而能够在运行时条件发生变化时，支持暂停、干预、回展以及人工接管等操作。

环境敏感型自适应

同一智体及能力包在不同部署环境下（例如在仿真环境中、实体机器人上、测试模式下，或与人类共享的环境中），可能会依据不同的治理规则进行运作。

可恢复性与可审计性

一个可治理的具身系统不仅必须支持执行审批功能，还必须具备故障响应能力、操作过程的可追溯性，以及对决策与干预措施进行事后审查的能力。

3 框架架构

运行时治理框架位于具身智体（embodied agent）与执行基底之间。从概念上讲，其执行路径如下：

目标 → 提案 → 请求 → 治理 → 执行

与直接的“智体-控制器”管道不同，治理层在执行之前及执行过程中插入明确的控制点。该架构可视为由四个堆叠的层级（stratum，strata）构成：

第1层：智体认知层。该层包含持久化的具身智体，涵盖目标解读、记忆、规划及能力选择等功能。
第2层：能力层。该层包含可执行的能力包。这些能力包可对应于各类技能、控制器、工具封装、恢复例程或组合行为。
第3层：运行时治理层。这是本框架的核心贡献所在。它包含下文所述的各类治理组件，并负责判定执行任务的可行性与连续性。
第4层：执行基底。该层包含实际的具身执行环境，具体包括仿真器后端、机器人中间件、传感器、执行器以及特定于平台的接口。

这种分层设计使得同一套智体认知逻辑能够与不同的治理策略及执行基底相耦合，而无需对整个系统进行重写。

运行时治理框架架构如图 2所示：

4 能力准入

能力准入是首个治理检查点：它负责判定某项能力请求是否获准进入执行管道。准入模块接收的输入信息包括：拟调用的能力标识符、调用参数、当前活跃的环境配置文件、当前的策略集、权限状态以及能力清单。该模块将逐一核查该能力是否存在、是否已针对当前环境完成注册、是否具备足够的执行权限，以及是否符合治理配置文件的相关规定。准入判定将产生四种结果之一：接受accept（进入策略评估阶段）、拒绝reject（不允许执行）、推迟defer（当前不具备执行条件，但稍后可能有效）或上报escalate（需提交至上级进行监督审查）。

5 策略守卫（Policy Guard）

如果说“能力准入”（Capability Admission）回答的是“这项能力是否可以被考虑？”，那么“策略守卫”回答的则是“在当前时刻，该调用可以在哪些约束条件下执行？”它针对具体的请求评估运行时策略——包括参数边界、力/速度限制、位置禁令、重试预算、审批阈值以及特定于环境的约束条件。策略规则采用抽象形式：若 φ (cˆ_t , x_t , Γ_t) 成立，则执行 δ；其中 φ 是一个条件，而 δ ∈ {允许, 修改, 拒绝, 升级}。其中的“修改”结果尤为重要：它将执行过程约束在更安全的运行边界内，而无需智体（Agent）从头开始重新规划。例如，一项移动操作请求在仿真环境中可能被直接允许执行，但在真实机器人上执行时，可能会被修改为降低速度、限制活动区域（走廊）宽度，并强制要求保持一定的防碰撞裕度。

6 执行监视器（Execution Watcher）

“执行监视器”实时观测执行过程，以判定其是否始终符合既定策略、预期进度以及安全运行条件——若缺乏此组件，整个治理体系将退化为单纯的静态预检查机制。它接收并处理各类信号，例如控制器状态、传感器读数、运动轨迹、时间进度、完成度指标、重试计数器以及环境状态变化等；并履行四项核心职能：(1) 进度追踪；(2) 约束监控（检测运行时策略违规）；(3) 异常检测（识别不稳定、超时、漂移或不安全的过渡状态）；以及 (4) 升级信号触发（当触及治理阈值时发出警报）。

7 恢复与回展管理器（Recovery and Rollback Manager）

“恢复与回展管理器”负责决定当执行过程发生故障或中断时应采取何种后续行动。该框架并未将恢复逻辑内嵌于每一项具体的能力之中，而是将其视为一种治理层面的职能，从而确保故障响应机制既能遵循既定策略，又能充分考量当前的环境状况。恢复行动的选项包括：在限定范围内重试、调用专门的恢复能力、回展至先前的安全状态、切换至风险较低的运行模式、终止当前任务以进行重新规划，或请求人类操作员接管控制权。具体采取何种行动，取决于故障类型、风险等级、环境特征、权限状态以及回展的可行性——例如，在仿真环境中发生的操作故障可能允许系统自动重试；但若在真实机器人上发生同样的故障（且机器人正抓取易碎物体），则可能要求系统立即暂停，并等待人类操作员进行确认。

8 人机接管接口（Human Override Interface）

“人机接管接口”将人类的决策权——既包括主动审批，也包括被动干预——整合为治理体系中的一个可配置且依赖于既定策略的核心组件。系统支持五种权限模式：需审批（执行前确认）、升级审批（仅限高风险情境）、可中断（随时暂停或终止）、可接管（直接接管控制权）以及仅复核（执行后检查）。该界面会显示当前操作及上下文信息，阐明权限升级的原因，呈现风险相关信息，记录决策过程，并留存所有干预事件的记录以供审计。

9 审计与遥测层

审计与遥测层负责记录系统曾提出过哪些建议、批准哪些操作、执行哪些任务，以及发生人工干预的原因。所记录的事件涵盖智体建议、策略配置文件、准入与策略守卫的决策结果、执行过程中的遥测数据、监视器告警、恢复操作、人工干预行为以及最终的执行结果。该层主要服务于三大目的：运维调试（用于诊断故障）、治理验证（用于确认策略执行的正确性），以及事后问责（提供用于合规审计的追踪记录）。除了被动的日志记录功能外，遥测数据还会被反馈至在线治理环节，从而支持自适应阈值的调整以及策略的重新设计。

---

1 概述

上一节描述的运行时治理框架定义了实现可治理的具身执行所需的结构组件。现在，将描述这些组件如何相互协作，构成一个具体的执行流水线。该流水线的目的是确保从智体意图到具身动作的每一次转换，都必须通过显式的运行时治理进行中介，而不能被视为智体输出的直接后果。

所提出的流水线被称为“策略约束执行”，因为执行过程不仅由智体生成，还会持续受到策略、环境状态、运行时观测以及干预逻辑的塑造。在该流水线中，执行被理解为一个受治理的生命周期，而非单一的决策点。

从宏观层面来看，该流水线包含七个阶段：(1) 目标解读，(2) 能力提议，(3) 准入与策略评估，(4) 受治理执行启动，(5) 运行时观测与约束追踪，(6) 干预、恢复或升级，以及 (7) 完成、审计与重返规划。下图3以受治理生命周期的形式展示该流水线。

2 阶段1：目标解读

执行生命周期始于具身智体接收或持有某项任务目标之时。该目标可能源自人类指令、系统触发的任务、预定的计划，或是此前未完成的执行线程。

在此阶段，智体执行任务层面的推理，其内容可能包括：解读目标、将任务落地（grounding）至当前环境、从记忆中检索相关上下文、将任务拆解为子目标，以及识别候选能力。

重要的是，此阶段的产物是意图结构，而非直接的执行动作。其输出结果是一条通向行动的拟议路径，但并非获准采取行动的许可。将目标解读的结果表示为：

g_t → Pˆ_t (9)

其中，g_t 表示当前活跃的目标，而 Pˆ_t 表示智体拟议的执行规划。

3 阶段2：能力提议

随后，智体选择一个或多个候选能力包，以实例化下一个可执行步骤。此项选择可能基于规划、检索、过往的执行轨迹、环境状态，或是智体内部的策略偏好。一项能力提案至少包含以下要素：能力标识符、调用参数、目标对象或位置、预期的执行模式、预期的前置条件、可选的恢复偏好，以及置信度或优先级等元数据。

将提案表示为：

q_t = (cˆ_t, x_t, z_t) (10)

其中，cˆ_t 表示所提议的能力，x_t 表示调用参数集，而 z_t 则表示置信度、意图类别或任务优先级等上下文元数据。

提案阶段被有意设计为由智体（Agent）自主掌控。治理层并不取代规划环节；而是在规划完成之后，对执行过程进行协调与仲裁。

4 阶段 3：准入与策略评估

一旦提出某项能力请求，该请求即进入运行时治理层。此阶段包含两项相互关联的检查：能力准入与策略守卫评估。

能力准入

能力准入模块负责判定所提议的能力是否获准进入管道（pipeline）：

a_t = Admit(q_t, Π_t, Γ_t) (11)

其中，a_t ∈ {accept, reject, defer, escalate}。

策略评估

若请求获准，策略守卫（Policy Guard）将评估该具体调用是否满足当前生效的运行时约束：

p_t = Check(q_t, Π_t, Γ_t) (12)

其中 p_t ∈ {允许, 修改, 拒绝, 升级}。若评估结果为“修改”，系统会将该请求约束为一个符合策略要求的版本：q’_t = Constrain(q_t , Π_t , Γ_t)。

5 阶段 4：受控执行启动

如果请求通过准入检查和策略评估，执行过程将在治理监督下启动。选定的能力包将被绑定到执行基底上。根据具体的系统实现，这一过程可能涉及通过机器人中间件下达指令、调用运动规划器、启动操作控制器、启动工作流程序、将传感器流绑定到能力实例上，或者创建一个受监控的执行会话。

执行启动不同于普通的控制器调用，因为它明确地关联一个治理上下文。将启动的执行实例定义为：

e_t = (cˆ_t, x_t′, Π_t, Γ_t, κ_t) (13)

其中，x_t′ 是最终的受约束参数集，κ_t 是执行会话的状态。这意味着执行过程并非在“真空”中开始；相反，它是在附带运行时策略上下文和观测通道的情况下启动的。

6 阶段 5：运行时观测与约束追踪

一旦执行开始，执行监视器将持续观测该会话，这也是本流程管道与静态验证环节的区别所在。观测流 Ω_t:t+∆ = Observe(e_t) 将依据策略预期进行评估：

w_t = Watch(Ω_t:t+∆, Π_t, Γ_t) (14)

其中，w_t 可能指示执行状态为：正常继续、警告、违规、超时、不稳定、升级、或已完成。约束追踪不仅要确认初始计划是否合法，还要持续监测随着条件演变，执行过程是否依然保持合法——例如，在执行过程中有人类进入工作空间，或者机械臂进入受限的力控制区域。该流程管道将执行状态表示为以下几种：运行中（RUNNING）、已暂停（PAUSED）、已升级（ESCALATED）、恢复中（RECOVERING）、已完成（COMPLETED）或已失败（FAILED）。

7 阶段 6：干预、恢复或升级

当监视器发出异常或违规信号时，恢复与回展管理器将确定相应的响应措施：

i_t = Intervene(w_t, Π_t, Γ_t, H_t) (15)

该函数将产生以下结果之一：继续（continue）、暂停（pause，即挂起执行并保留当前状态）、停止（stop，即终止会话）、回展（rollback，即恢复至安全状态），或升级（escalate，即请求人工决策）。若系统具备可恢复性，则将调用：

r_t = Recover(e_t, w_t, Π_t, Γ_t) (16)

该恢复过程可能涉及有限次重试、控制器模式切换，或调用预先指定的恢复功能。在具身设置（embodied settings）场景中，回展（rollback）机制尤为关键；因为物理状态的改变无法通过符号操作进行“撤销”，系统必须主动采取行动以恢复至安全状态。当系统不再适宜自主继续执行时，即触发“升级”机制，并通过“人工接管接口”（Human Override Interface）将处理流程切换至人工监督决策的分支路径。

8 阶段 7：完成、审计与重返规划阶段

执行过程通常以三种主要方式之一结束：(1) 成功完成；(2) 经治理后的恢复过程，随后达成完成或安全终止；(3) 失败或需进行重新规划的移交。

一旦执行结束，治理层将记录该会话的完整轨迹，其中包括初始提案、策略决策、执行观测数据、监视器警报、干预事件、恢复路径、人工操作以及最终结果。我们将该最终轨迹表示为：

τ_t = Trace(q_t, e_t, Ω_t, i_t, o_t) (17)

其中，o_t 表示最终结果的标签。该轨迹具有多重用途：用于未来的调试工作、运行时策略的优化与调整、审计与合规性检查、智体记忆存储或学习训练、恢复过程的基准测试，以及故障分析。

执行完成后，系统可能会重新进入规划循环。若任务尚未完成，具身智体将依据当前结果及轨迹上下文来决定下一步行动：

(A_t, τ_t) → Pˆ_t+1 (18)

至此，便形成了连接“受治理的执行过程”与“持续性智能体运作”的闭环。

9 执行场景示例

为具体阐释这一流程管线，本文以一台移动机械臂为例，假设其接收到的指令是从一个共享工作空间中抓取某物体。

步骤 1：目标解读。智体对指令进行解析，并识别出其中包含“抓取并运送”这一子目标。
步骤 2：能力提案。智体提出一个能力序列方案，其中包括导航、物体定位、抓取以及搬运等能力模块。
步骤 3：准入与策略评估。导航与定位能力模块获准直接执行。抓取能力模块虽获准执行，但根据既定策略进行了调整——由于机器人正处于人机共享环境中作业，其抓取时的施力强度与运动速度均被下调。
步骤 4：启动受治理的执行。受约束条件限制的抓取执行任务正式启动，并伴随有实时的动态监控。
步骤 5：运行时观测。在执行过程中，监视器检测到有人类进入了机器人的近距离安全区域。
步骤 6：干预处理。运行时治理层随即暂停当前执行任务，并将控制权上报至“人工监督模式”。待确认安全隐患已排除后，执行任务恢复。若随后检测到抓取状态出现不稳，恢复管理器将立即调用“安全重定位”例程进行处理。
步骤 7：完成与重返。目标对象已成功交付。系统记录策略修改、暂停事件以及恢复例程。随后，智体（Agent）判定广义任务是否已告完成，抑或是否尚需启动新一轮的获取周期。

本例表明，执行的成功并非仅取决于规划的质量，更归功于运行时治理机制——正是该机制确保了在环境条件发生变化时，执行过程依然能与既定策略保持高度一致。