OxDeAI：我为AI代理构建了一个确定性的预执行授权边界（默认拒绝、签名工件、适配LangGraph/CrewAI/AutoGen等），寻求反馈。

大家好。我是OxDeAI的作者，这是一个开源协议（Apache 2.0）。之所以在这里发布，是因为我希望从真正构建代理的人那里获得批判性反馈，而不是掌声。我不断遇到的问题是：随着代理从生成文本转向执行操作（API调用、支付、基础设施配置、工具使用），大多数技术栈仍然在代理循环内部通过尽力而为的检查来执行策略。这会导致诸如对非幂等操作的重试放大、预算超支、过期状态执行和权限漂移等故障模式，原因在于“检查”和“操作”存在于同一个信任边界内。核心思想：将决策与执行分离。代理提出意图，OxDeAI确定性评估（意图、状态、策略），如果结果为ALLOW，则签发一个签名的AuthorizationV1工件。然后，Guard/PEP在产生任何副作用之前验证该工件。没有有效的授权就意味着没有执行路径。默认拒绝，并具备一次性重放保护、显式信任（trustedKeySets）以及可离线验证的工件。目前已有的功能：签名的决策工件加上一个不可绕过的守卫（执行函数只能通过守卫闭包访问；有一个演示显示直接调用会被拒绝）。适配器：LangGraph、CrewAI、AutoGen、OpenAI Agents SDK和OpenClaw，这些都是通过一个通用守卫路由的薄绑定。单跳作用域委托（代理之间仅缩小能力的传递）。跨语言一致性向量（TS参考加上Go/Python测试框架），并在规范化和撤销列表表面有字节等价锚点。哈希链审计信封，用于离线验证。关于现状的诚实说明：跨语言可重现性在序列化和KRL表面已经完成，但尚未覆盖所有授权判定（Go/Python尚未覆盖完整的验证表面）。我不希望在向量未完全覆盖所有内容时声称“跨语言确定性”。有一个微基准测试表明每个操作的开销很低，但它只是单进程在我的硬件上运行，因此请将其视为指示性数据，而非生产数字。测试框架位于bench/目录下，欢迎自行测试。已知问题包括一个正在加固的关于自声明意图字段的问题（代理目前可以通过选择自己的agent_id来影响哪些按代理限制生效，此问题正在修复），以及一个关于未来独立安全审查的范围问题。尚未进行第三方安全审查，我在文档中已明确说明。项目尚处于早期阶段。TypeScript是参考实现；协议表面已指定但仍在演进。这不是一个提示护栏或监控/可观测性工具。它位于执行边界，旨在与您现有的框架组合使用，而不是取代它。仓库地址：https://github.com/oxdeai/oxdeai 我真正想了解的是：您在生产中遇到过这些工具调用/副作用故障模式吗？目前您如何在操作级别执行策略：在循环内部、API网关处，还是其他地方？如果您尝试过适配器，集成过程中哪里最棘手？对于注重安全性的朋友：默认拒绝/签名工件边界能否抵御您可能发起的攻击？欢迎贡献者，特别是新的适配器、策略示例以及跨语言判定覆盖。请参阅CONTRIBUTING.md和开放问题。