ArbiterOS — 港中文 CURE Lab 开源 Agent 运行时治理内核¶

Ch04.824 ArbiterOS — 港中文 CURE Lab 开源 Agent 运行时治理内核¶

📊 Level ⭐⭐⭐ | 10.2KB | entities/arbiteros-governance-kernel-cuhk-2026.md

→ 原文存档

ArbiterOS 是香港中文大学 CURE Lab 开源的 Agent 运行时治理内核，把治理点放在模型输出和工具执行之间：模型负责规划，确定性的治理层决定动作能否进入执行面。它在模型输出与工具执行之间增加一层运行时治理，将工具调用整理成结构化指令（Instruction），记录数据来源和步骤依赖，再由策略决定放行、阻断或请求确认——补的是 Agent 控制循环里长期缺失的一层。

定位与边界¶

ArbiterOS 并非新的 Agent 框架，也不是装上就能覆盖所有风险的操作系统。当前实现建立在 LiteLLM 代理之上，要求 Agent 能把模型请求路由到 OpenAI 兼容端点（本地默认 http://127.0.0.1:4000/v1）；README 列出的集成包括 OpenClaw、Nanobot 和 Hermes Agent。能否管住一条调用链，取决于请求有没有经过代理、工具格式能否被解析、部署时启用了哪些策略——直接运行的脚本、MCP Server 或宿主进程绕过这条链，治理层就看不到它们。

问题根源：控制循环里缺一个执行前控制点¶

很多 Agent 系统把规划、判断和下一步动作都交给同一个概率模型：模型既决定"做什么"又决定"现在就做"，外面再补 Prompt、确认弹窗和日志。传统应用里权限系统、事务、网关和基础设施分别把守执行边界，而 Agent 的高风险动作缺少一个独立、确定、位于执行前的控制点。单独一层防护都不够：Prompt 难成强制权限边界；安全模型未必掌握完整数据来源和系统状态；Sandbox 不理解客户数据接下来要发给谁；人工确认频繁弹窗造成授权疲劳。这些机制都要保留，ArbiterOS 的价值在于给它们补上一份共同的运行时上下文。

五层责任：规划权与执行权分开¶

沿一次真实调用往下，责任分五层：

Agent 与模型负责规划：理解任务、拆步骤、选择工具，允许阻断后重新规划；
ArbiterOS 负责运行时判断：把工具调用转成 Instruction，追踪来源与依赖，运行策略并记录 Trace；
工具网关负责执行：文件、数据库、浏览器和外部 API 的真实调用从这里发生；
Sandbox、IAM 和网络出口负责刚性限制：进程能读什么、身份能写什么、请求能去哪里；
业务系统负责最终一致性：审批、幂等、监控、补偿和回滚属于具体业务，治理内核无法替代。

完整调用路径：任务输入 → Agent 规划 → ArbiterOS 判断 → 工具网关执行 → Sandbox/IAM/网络约束 → 业务验证与恢复。少了前面的治理判断，动作可能来不及拦；少了后面的刚性权限和业务恢复，策略通过也不代表系统安全。

Instruction：数据流比工具名更重要¶

ArbiterOS Kernel 位于 LiteLLM 请求链路中，请求到达后维护 Trace、处理元数据和消息格式；模型返回工具调用后由 InstructionBuilder 解析成统一 Instruction，交给策略模块。一条 Instruction 可以记录：工具名/调用参数/可选结果；runtime_step、parent_id、source_message_id 等步骤关系；保密性、可信度、风险和可逆性等安全属性；reference_tool_id 指向的上游工具调用。

核心思想：策略除了知道"Agent 正在发请求"，还要知道请求里的数据从哪里来。网页内容被标记低可信度、本地密钥文件带高保密性，后续摘要引用这两份结果时标签沿指令依赖传播；等数据进入网络外发、数据库写入、文件删除这类高风险终点时，策略看到的是整条数据链而非孤立的工具名。工具白名单回答"这个工具能不能用"，数据流回答"这次调用带着什么数据、从哪一步来、要流向哪里"。Instruction 是可追踪的中间表示，不是可信事实——模型结论是否正确、工具解析是否完整、策略是否覆盖真实风险仍需各自验证。

控制点必须在执行前¶

"不要读取生产配置"写进 System Prompt 只能减少模型主动选择；同样的边界落到文件权限和 Sandbox，进程才真的读不到。网络白名单写进策略可提前识别目标，真正限制连接范围靠出口代理或防火墙。ArbiterOS 管的是中间这层判断：把路径、参数、数据来源和动作后果放到一起，在工具执行前给出放行、阻断或确认，并把原因写进 Trace。

两个落地要求：① 所有高风险工具调用经过同一治理入口——Agent 主循环走代理、旁边 Python 脚本直连数据库、MCP Server 在宿主机拿完整权限时，治理覆盖率只存在于报表里；② 防治理层变成新的超级权限中心——需要最小权限、策略版本管理、变更审计、超时熔断，Trace 里避免泄露密钥/客户数据/完整请求体，日志脱敏、分级保留、访问控制。

回滚跟着故障域走¶

"策略允许"和"业务安全"之间隔着恢复链路。不同副作用属于不同故障域，回滚方式差别很大：代码修改停在工作树可丢弃 Diff/回退提交；依赖安装改了锁文件和缓存需核对制品；生产配置更新靠发布平台回滚；数据库迁移可能只能执行补偿脚本；邮件、支付、外部通知离开本系统往往没有真正"撤销"。治理内核能告诉团队哪一步被批准、哪条策略命中，却不能凭空恢复已损坏的数据。架构原则：执行权跟副作用绑定，恢复能力跟故障域绑定。

落地：小策略表 + Trace 三问¶

落地不必先设计"Agent 宪法"。选一条任务链把最易产生副作用的动作写清楚（测试环境先跑），每行要对应真实工具、真实账号、真实日志：读取普通测试日志→允许；读取密钥/生产配置→阻断；写入测试目录→允许+Diff 记录；删除文件/数据→请求确认；访问外部网络→白名单；发送邮件/关闭工单→草稿优先；生产写入/部署→阻断或升级审批。麻烦在于每个映射都要回答"由哪一层识别、软链接/脚本封装会不会绕过、白名单限制域名还是最终连接、审批后参数替换是否重确认、Trace 记摘要还是哈希"。

Trace（log/{trace_id}.json 按轨迹组织）要回答三件事：输入从哪里来，哪条规则生效，确认是否真的发生。这对策略迭代很重要——规则频繁命中可能是边界太宽或任务该拆分，误拦截集中某类工具说明解析器或策略缺上下文。但 Trace 只能证明治理层看到了什么：旁路、未解析的工具参数、业务系统内部二次调用都不能靠日志自动补齐。

评测数据有边界¶

论文在 AgentDojo 和 Agent-SafetyBench 攻击轨迹上做确定性重放，人工复核得到 1,914 个危险案例：OpenClaw 原生策略拦截率 6.17%（118/1,914），集成 Arbiter-K 后 92.95%（1,779/1,914）。实验采用围绕危险步骤的 prior+current 重放以减少重新规划差异，不等于"生产 Agent 安全率"（规划漂移、插件覆盖、旁路调用、业务状态、网络环境仍在）。可用性代价：OpenClaw 312 个良性样本通过率从 92.95%（290/312）降到 88.78%（277/312），额外误拦截集中在跨会话委派、日历/界面副作用、外部通信等边界动作。论文：《From Craft to Kernel: A Governance-First Execution Architecture and Semantic ISA for Agentic Computers》（arXiv:2604.18652）。

与相关实体关系¶

ArbiterOS 与 Agent Harness 上下文管理：工作集视角互补：前者管"动作能不能进执行面"（执行权治理），后者管"窗口里放什么"（上下文治理），同属 Harness Engineering 体系下的不同故障面。与 CrewAI 数据治理与凭据模式相比，ArbiterOS 走的是"模型输出与工具执行之间的确定性治理层"路线（Instruction + 数据流标签传播 + Trace），而非凭据封装模式；其"规划权与执行权分离"与 Claude Code 大型代码库 Harness 配置的边界设计思路一致。