“
介绍一篇Agent相关工作的论文 《Agentium: A Governable Agent Operating System Immutable Run Contracts, Policy Gates, and Auditable Automation》 开源代码：github.com/GuiminChen/…
置于企业环境里的大语言模型智能体，问题往往不只在「模型这一句答得好不好」，而在于：它会调用哪些工具、走哪些通道、后台任务在无人在场时会做什么、出站内容是否可控——这些合在一起，单靠提示词加固或者粗粒度权限，常常在「意图」「实际运行」「事后追查」之间留下缝隙。
最近在整理的一篇工作，名字叫 Agentium，副标题可以理解为：不可变运行契约、策略门控与可审计自动化。并不承诺解决所有安全问题，也不打算和某个闭源产品在未公开细节上比高低；更侧重把上面这类风险说清楚：在网关、manifest、registry、policy、审计链等按规范工作的前提下，外向的影响应当能从声明过的表面流过，并且能够挂到可追溯的记录上。这是架构层面的可追责思路，而不是对任意对手的密码学证明。下文分三块：问题从哪来、设计上有哪些抓手、评测与边界写到哪一步。
一、问题从哪来
行文把 ReAct 式工具调用和各种框架带来的「能动」看作是前提，把注意力放在另一类事情上：工具、通道与后台，都会产生副作用；这些副作用需要和组织声明的策略一致，并且在发生事故之后能够复盘、甚至重放。仅靠应用层的常见缓解，容易在系统性上不够用。
因此用「平面」这两个字把职责拆开：治理、编排、受治理的后台、控制、执行、资源等。核心是：跨边界的影响应当走带稳定标识的观测与控制入口（例如 run_id、tool_use_id 等），而不是指望模型侧的叙述本身承担合规与追责的全部重量。
图 1：Agentium 各「平面」的概念分层（界面 → 治理与协调 → 后台 → 控制 → 执行 → 资源）。虚线框表示通道适配器与 AI 网关路由等入口侧组件；后台平面显式画在治理之下。图中组件名为示意图。
威胁模型里写明了不包揽的范围：物理入侵、绕过文档接口的侧信道、传输层密钥被完全攻陷的后果，以及对自然语言普遍真值的无条件担保——这些都不在宣称之内。读起来会觉得保守，但这是有意为之：先把边界钉住，再往里谈机制。
二、设计上的三条线
摊开写会很长，这里先拣三条，把骨架搭起来。
第一是「运行清单」与单次运行的绑定。
一次 run 会用一份快照式的 manifest：声明允许哪些工具、策略版本指向哪里、路由等关键配置在哪里。单次运行从某种意义上说，是和这份快照「绑在一块」的证据关系；ingress 一侧对清单外的工具要能失败闭锁，而不是悄悄扩大能力面。
第二是策略与人的门控连在一起。
PolicyEngine 在给定租户、给定 run、给定工具风险类别上，给出允许、需要审批、或直接拒绝一类的裁决——并且希望这是版本化、可复现的；不是换一种模型口吻糊弄过去。ApprovalGate 在需要人审时，希望在 tool_use_id 粒度上挂住外向副作用，批准或拒绝之后用可恢复的语义继续或结束，而不能用一句自然话来冒充授权。
图 2：简化工具门控——ingress 对齐 declared_tools、policy_bundle_ref 与当前生效策略版本；ToolRegistry 拒绝未声明工具名；PolicyEngine 给出 allow / HITL / deny；Audit 对所有路径发出事件（含 tool_use_id、trace）；仅 allow 进入 Execute。deny 或待人工（HITL）进入 Stop（无执行）。出站数据防泄漏（假设 H4）走独立 egress，本序列未画出。
第三是后台不能与前台两套规矩。
定时、间隔、事件触发的 automation 会和前台会话并行，但必须经过与同一条清单、同一套策略租户上下文一致的守门机制；不能因为「跑在后台」就注册清单外工具、放大出站，或绕过与人审等价的高风险路径。过载、噪声触发时，用节流、熔断、killswitch 等有界降级，这些是设计里反复强调的语义，不是靠模型临场发挥。
图 3：后台平面安全回路示意——BackgroundPolicyGuard 侧观测（daemon tick、触发、守卫信号）；窗口/SLO 越阈后电路断开（kill-switch、pause）；安全降级约束外向影响；最后在治理参与的恢复（含 HITL/运维）后重新武装（re-arm）。对应正文所述 H3 式有界降级思路。
此外还有 入站协议里写死的语义字段：例如消息如何处置（收集、跟进、纠偏），以及 MCP 的执行分层，避免同一种入口在不同通道上出现「松紧不一」的双轨。研究类接口可以附带与出处对齐的结构化引用——文中明确：不宣称在全集成路径上已经做完所有 DLP 阶段的实证，也不宣称取样级引用覆盖率的统计结论；协议与脚手架先立住，更深的实证留给后续。
三、正文里写了六条
六项依次是：分层控制平面、策略与人审与审计的串联、受治理的后台、把常见「暗路径」写进可对齐的矩阵和验收协议、可替换但必须服从合同的后端插件、以及与 grounding 挂钩的协议字段。条目上分条写，后面几节其实是在给这一串铺路，不是六样各管各的「小发明」。与学习相关的产出在参考实现里是进 提案队列，而不是静默改掉线上策略——这是刻意的设计选择，为了在组织里保住「谁在什么时候改了什么对外行为」这根线。
评测部分也值得单独说一句：正文认领的是 harness 层面的协议与自动化核验，包括与附录对应的 H1–H6 一类的门禁映射、治理能力剖面的对比、程序化消融与微基准等；还特意写明不向闭源模型或专有助手求证，消融在可控子进程里跑。读者如果期待的是大规模线上 A/B、或者全行业攻击抽样的代表性统计，「威胁与效度」一节亦写明局限：合成用例、单租户偏多、不包含对不同记忆后端做消融等——这些在正文里就已摊开。
四、和已有开源栈的关系
论文里有一张很克制的定性表，只对 OpenClaw、DeerFlow 一类的公开叙事做对齐；GPTs、Claude Code 等闭源或未充分公开的产品 deliberately 不入表格，只在正文散文里点到为止，以免写成未经审计的竞品结论。论点侧重在于：不是要替代某一种网关，而是主张「路由可以多样，但路由、注册表、出站与后台不能脱离同一根可审计的合同链」——说白了就是：集成功能多，不等于治理能力自动跟上。
结语
用一句话收口：Agentium 试图把 enterprise LLM 智能体的一组常见风险，收敛到可控平面上的问题：清单、策略、人审、审计与后台的周界对齐，并用可自动化的验收规程把能说清楚的部分说清楚；该谦虚的地方谦虚，不把 harness 上的小结论吹成生产力革命。
概念解释
下列条目可与正文对照查阅。
- run / run_id（单次执行实例）
-
- 是啥：智能体某一趟任务从头到尾的那一段生命周期。
- 白话：
run_id是这一趟的「数字指纹」，日志、审批、审计都跟它串在同一条线上，外向副作用要能追问到「到底是哪一次触发」。
- manifest（运行清单 / 声明式快照）
-
- 是啥：Agentium 里很靠前的一块——任务在启动瞬间冻结下来的一份配置快照：可用工具、策略版本绑哪一版、路由怎么设等，都写在这一纸「死契约」里。
- 白话：模型事后想再多调一样没声明的工具，系统应按设计拒绝闭锁，别把能力面偷偷撑大。
- ingress / egress
-
- 是啥：请求进来（ingress）、响应或副作用出去（egress）两道关口。这里概括为：进门先对齐清单，出门再过数据防泄漏等检查。
- 防误解：这两个词在防火墙、零信任（Zero Trust）那一套里也常见——Agentium 相当于把这类「先看门再放行」的工程哲学，搬到了智能体控制的语境里。
- registry（工具注册表）
-
- 是啥：系统登记「有哪些工具、叫什么、怎么挂」的地方。
- 白话：和 manifest 并排用，避免「名册里没有、契约里也没写」的工具被稀里糊涂调起来。
- MCP（Model Context Protocol）
-
- 是啥：一种旨在把「主机如何把上下文交给工具、工具如何回调」标准化的公开协议规范；生态还在演进，用词上留一点余地是必要的。
- 值得强调的是：执行形态一旦不同——例如本地直连式调工具，对比走需沙箱约束的代码执行类 MCP——能力半径和该有的风控档位就要在契约里写明，不能把模型在中间某一步悄然「升格」成权限更大的渠道。
- PolicyEngine / ApprovalGate（原型模块名）
-
- 是啥：前者做自动化策略裁决（放行 / 须要人审 / 直接拒绝），后者接手「真要人按键」的那一截。
- 白话：ApprovalGate 把「口头在聊天里说行」拦在正式的、可核验的授权之外。
- tool_use_id（单次工具调用意图的编号）
-
- 是啥：「这一刻打算调用某个工具、带什么参数」这一条意图有了自己的 id。
- 白话：挂起、恢复、审计可以细到这一次调用，而不是糊成一整段对话。
- harness（Test Harness）
-
- 是啥：论文配套的那段自动化测试与核验脚手架（test harness）：脚本、带门禁的用例——该过的过、不该过的别过——凑成一整套验收架子。
- 防误解：不是生产线上跑接单业务的那份代码；就是专门拿来「找茬」、盯住系统边界有没有被掏空或绕过的架子。
- DLP（Data Loss Prevention，数据防泄漏）
-
- 是啥：查出站载荷里有没有不该带出去的东西的一类机制。
- 这儿多说一句：设计上分路径、分期打算做完整条管道；并不宣称原型已经在每一步都收口到底。
- 提案队列（Proposal Queue）
-
- 是啥：学习环、演进环产出的先倒进待审队列。
- 白话：不直接重写线上清单或策略文件，避免模型那条回路「暗中改规矩」。
