OPA、Cedar等工具擅长根据明确规则给出允许或拒绝。更困难的是：规则怎么管理、是否正确、升级会不会出问题、出了问题能否还原。
版本、责任人、审批状态和生效范围不清楚，容易出现旧规则仍在运行。
→ 建立完整生命周期缺少标准场景和预期结果，Policy修改后无法系统判断是改善还是倒退。
→ 建立测试、Replay与Benchmark没有统一Decision Log和Trace，就无法还原当时用户、Agent、工具、数据与Policy版本。
→ 建立可审计证据链点击模块查看作用。引擎选型和两个算法的落点已经明确：中间是 OPA，上线前由算法一找规则缺陷，运行后由算法二验证实际影响。
不用专业缩写：一位员工请Agent汇总受限客户资料，系统需要同时判断人、数据、用途和工具。
“请汇总这家客户的基本信息，并生成一份内部沟通摘要。”
系统不能只判断“她是不是员工”，还要结合她的角色、数据敏感等级、用途、准备调用的工具，以及当前Policy版本。
先把 Phase 1 需求拆成 5 个板块、11 个功能点，再对四个开源引擎逐项打分（5 分制，外加开发难度与稳定性），最后结合定位给出结论。TrueFoundry 因未找到开源代码，不纳入比较。
通用策略决策框架，核心特色是policy-as-code：用代码形式的条件语句表达约束，决策结果稳定、确定性强。
总分 48 / 60 · 四项中最高同属底层决策框架，特色是围绕授权关系判断（什么身份才能做什么事）。表达与约束范围更小，处理授权关系时更顺手。
总分 40 / 60以 Agent 行动流程为中心：从启动、调用模型与工具到结果返回，每步前后设检查点拦截。优点是把拦截过程标准化，不必自行编写相关代码。
总分 46 / 60以 LLM 内容安全为中心，重点判断输入输出是否安全。对自然语言描述的 Policy 很友好，但判断依赖 LLM、不确定性较高，更适合提示词注入等场景。
总分 41 / 60OPA 版本稳定、规则是直观的条件判断语句、长期维护时接口不易变；Cedar 除写规则还要定义较多授权模型，相对麻烦；AGT 开源版迭代快、稳定性偏弱，但对 Rego 有专门适配，与 OPA 相性很好；Guardrails 多数判断依赖 LLM，不稳定。
只选一个底层引擎 → OPA；若要同时加强 Agent 行为管控与自然语言约束 → AGT + OPA。两套算法正建立在这个结论之上：算法一依赖 OPA 规则的可解析性，算法二依赖 OPA／AGT 的决策日志与沙箱能力。
这两个算法不是额外的研究设想，而是针对调研评分里分数最低的三格——冲突缺口检测、回归回放、指标统计，四个引擎在这三格上几乎都是空白。
部署前的静态检查：不执行真实业务，只检查 Policy 规则之间是否存在逻辑问题。
运行后的动态验证：基于一次真实发生过的 Agent 任务，保持大部分条件不变，只修改指定条件，重新执行并比较结果。
这里的“因果”指受控修改条件后重新执行，而不是仅凭历史日志相关性推断因果。
算法一负责“发现规则可能有问题”，算法二负责“验证这个问题在真实执行中会造成什么影响”。Phase I 建议重点实现：算法一覆盖冲突、冗余、不可达、覆盖缺口；算法二覆盖 Policy 版本变化、Agent 身份变化、数据等级变化和用途变化；两者共同输出可复现证据和自动化回归测试。
分数越高越好（5 分制）。带框的格子是四个引擎最薄弱的位置，也正是两套算法要补的位置。
| 评分项 | OPA | Cedar | AGT | Guardrails | 算法补强对应 |
|---|---|---|---|---|---|
| 1.1 加载 Policy 及相关数据 | 5 | 5 | 5 | 5 | 四家均原生支持 |
| 1.2 Policy 版本、所有权与状态管理 | 3 | 3 | 3 | 2 | 由规范包定义（D03） |
| 2.1 接收结构化上下文 | 5 | 5 | 5 | 5 | 四家均原生支持 |
| 2.2 支持包含多种决策结果 | 5 | 2 | 4 | 3 | OPA 可返回任意类型 |
| 2.3 决策默认安全、异常时拒绝或转人工 | 3 | 3 | 5 | 3 | 算法二 · fail-closed 纳入测试 |
| 3.1 部署前的编译和正确性检查 | 5 | 5 | 5 | 5 | 复用原生，不重复造轮子 |
| 3.2 冲突检测、缺口检测、规则不可达检测 | 2 | 4 | 2 | 1 | ★ 算法一（缺口检测四家全空白） |
| 4.1 提供自定义测试接口和函数 | 5 | 2 | 5 | 5 | 原生支持足够 |
| 4.2 支持回归、回放测试 | 3 | 3 | 3 | 3 | ★ 算法二（四家均为手工比对） |
| 5.1 记录每次查询的中间信息 | 5 | 2 | 5 | 5 | OPA／AGT 原生支持 |
| 5.2 支持指标统计 | 2 | 2 | 2 | 1 | ★ 算法二（差分结果即指标来源） |
| 开发难度与稳定性 | 5 | 4 | 2 | 3 | — |
| 总分（满分 60） | 48 | 40 | 46 | 41 | — |
3.2：OPA 仅 2 分（只原生支持规则冲突检测），Cedar 4 分但明确写了不支持缺口检测——“覆盖缺口”是四家共同的空白。 4.2：四家一律 3 分，实现方式都是手工对比历史用例。 5.2：最高只有 2 分，除 latency 外的 FP/FN、覆盖率、冲突率全都要自建。算法一填 3.2，算法二同时填 4.2 与 5.2。
算法一需要可解析的规则源码：OPA 在 3.1 上原生支持 check/build 静态校验（满分），且 Rego 是声明式语言、可解析为 AST。算法二需要可重放的 Trace 与 Policy 版本快照：OPA 在 5.1 上原生支持决策日志且可自行补充中间信息，Bundle 机制天然带版本与签名。另外 2.2 OPA 满分，与决策契约的 allow / deny / allow_with_constraints / escalate 四种 effect 契合。
缺口检测缺“业务意图”，是最大前置依赖。四家都不支持缺口检测，原因不是技术做不到，而是没有“应有控制但未被规则覆盖的域”就无法定义缺口——算法一必须先拿到合作方的控制矩阵或正负样例，否则“注入缺陷检出率 ≥90%”无法计算。端到端因果归因不要写进 Phase I 验收。只覆盖“决策层重放 + 工具 Mock”的 2–3 个代表性流程。指标口径要先固化。5.2 四家都低于 2 分、没有任何现成实现，口径不定，算法二产出的差分就变不成可验收指标。另外 2.3 OPA 仅 3 分（没有运行异常下的兜底代码），算法二做 fail-closed 验证时要把它纳入测试范围。
点击任意月份查看该月的SCUT研究重点、合作方配合事项与当月的可验收交付。每两个月形成一个明确Gate，避免研究与工程长期脱节。
SCUT回答“应该怎样设计、如何验证、怎样衡量”；合作方回答“如何接入现有Agent Hub、如何安全上线和稳定运行”。
不承担：Agent Hub生产系统实现、集成与运维。
双方共同：范围确认、阶段验收、数据治理、知识产权与成果发表。
每个交付包都停留在“方法与可验证产物”这一层：既有设计说明，也有能在代表性业务场景中评价的样例与结论。
需求基线、差距分析、目标架构、路线图与任务清单。
四引擎逐项评分、层级定位、选型结论与集成前提。
缺陷检测与反事实推演的算法设计、形式化表达与可行性论证。
冲突／缺口／回归测试方法、Benchmark场景、预期结果与Replay方法。
指标口径、基线结果与治理证据结论。
最终报告、培训材料、论文初稿、专利技术交底书与Phase 2准入评估。
保留难以准确翻译的英文，同时用一句话说明作用。
合作方不只是“装上一个Policy Engine”，而是拥有能持续管理、验证、度量和审计Agent行为的治理能力；SCUT的方法与算法成果也能被工程团队直接接管。