确定性网关：AI Agent 的“典狱长”还是“护城河”

这篇文章最有价值的信息是：Stonefold 提出的“确定性”方案，与当前主流的 AI 网关路线形成了根本分歧。一个在防，一个在堵。

我跑了几年 AI 条线，看了太多 Agent 项目死在“安全”这道坎上。最近这几周刚上手 MCP 和飞书，更直观地感受到，当一个 Agent 能调用十几个工具、横跨多个系统时，出事的概率不是线性的，是指数级的。

Stonefold 的定位很有意思：它是一个“确定性网关”。它的核心逻辑用一句话总结就是，—“AI 提议，你的机器执行”。这不是一个简单的路由转发，而是一个硬性规则引擎。

开环 vs 闭环：两种安全哲学的碰撞

先看主流方案。Kong 的 AI Gateway 代表了当前主流的技术路线：它位于 Agent 和上游服务之间，提供身份认证、RBAC、速率限制，本质上是一个功能更丰富的 API 网关。它依赖的是“策略”机制，—你定义规则，网关执行规则。但问题是，AI 的输出是概率性的，规则的边界是确定性的。用确定性的规则去管概率性的输出，就像用渔网去筛沙子，总有漏网之鱼。

我上周在客户那边试过一个场景：让一个 Agent 调用内部 CRM 的写权限，帮客户查询订单状态。Kong 的阿里布达规则能拦住“查询”这个动作，但拦不住 Agent 把订单号拼错了，导致查询了别人的数据。这不是安全漏洞，是逻辑漏洞。

Stonefold 的解法不同。它把“AI 提请求”和“系统执行”这两个步骤彻底解耦。AI 提出一个操作意图，Stonefold 根据预设的确定性规则（比如“只允许查询用户本团队的订单”），决定是否执行、如何执行、甚至替换执行参数。它不是“禁止”，而是“保证”。

damn，这个思路其实很像金融系统里的“交易匹配引擎”——你下单，引擎保证成交价不超出你的限价。AI 是“出价方”，Stonefold 是“清算所”。

技术取舍：为什么“确定性”很难做

这条路线听着漂亮，但代价很现实。

从 Stonefold 的宣传材料来看，它需要你提前定义好所有可执行的“原子操作”。比如“查询订单”、“修改订单状态”、“发送邮件通知”这些，每个都必须有明确的输入输出规范和边界条件。这意味着，对接一个系统的工作量，从“写一个 API 包装”变成了“写一个完整的操作描述+验证规则”。

对于大型企业，这可能是好事，—安全审计部门会爱死它。但对于初创公司，或者需要快速迭代的场景，这种前期投入可能就是致命的。

我一直在想的一个问题是：当 AI 的推理能力越来越强，它会不会被迫在被兜底的环境里“逆向选择”？如果 Stonefold 严格限制了操作范围，那 Agent 会不会学会“钻规则漏洞”？比如，不直接改订单状态，而是调用一个“自动触发状态变更”的内部流程，绕过了网关。

Stonefold 的团队可能已经想到了这一点。它强调“确定性”，但没说自己是“完全禁止”。也许它允许 Agent 在规则内“探索”，然后通过后续的审计日志来修正规则。这其实是一个“反馈闭环”的设计。

给你的行动建议

如果你正在做 Agent 类项目，特别是涉及金融、医疗、企业 SaaS 这类对数据安全敏感的领域，Stonefold 的路线值得深入研究。但别急着上生产。

我的建议是：先拿最简单的场景做 POC。比如，只开放一个“只读查询”的原子操作，让 Agent 跑一周，看看它会不会产生你没想到的边界情况。等确定性规则跑通了，再逐步放开范围。

确定性，是安全的最后一道防线。但也是最难构建的那一道。

---

本文编译自 Hacker News，原文：https://stonefold.ai/
版权归原作者所有，本文为基于公开报道的编译与独立分析。