在遭遇多次'合法但错误'的失败后，我为工具边界构建了一个确定性执行层

Reddit r/openclaw 工具
deterministic-enforcement llm-agents open-source tool-boundary yaml-contracts temporal-logic

摘要

作者描述了构建 Sponsio 的过程，这是一个面向 LLM 代理的开源确定性执行层，通过使用时间逻辑的 YAML 合约评估工具调用来防止'合法但错误'的行为，弥补了提示工程中的一个缺口。

使用 openclaw 几个月了，一直困扰我的失败模式并不是糟糕的代码生成，而是代理执行了那些“技术上合法但操作上错误”的操作：编辑工作目录之外的文件，因为提示说“确保分支干净”而强制推送，对错误的数据库运行迁移。提示工程捕获了大部分问题。但漏掉的 5% 恰好就是事后分析中的典型案例。论点：LLM 代理在构造上就是概率性的。提示提供的是统计行为，而非保证。一旦上下文填满，即使是“显而易见”的规则也会偏移。硬性保证必须存在于系统的概率部分之外。因此我构建了 Sponsio。开源，Apache 2.0。你编写 YAML 合约。运行时在每个工具调用提交之前对其进行确定性评估。保证子句是基于操作轨迹的时间逻辑，因此你可以表达“测试必须在提交前通过”或“会话中不能对同一文件进行两次写入”，而不仅仅是黑名单。即插即用。Sponsio 位于工具边界。你可以继续使用 openclaw（也适用于 Claude Agent SDK 和常见框架）。热路径中没有 LLM，p50 约 0.14 毫秒。仓库：[github.com/SponsioLabs/Sponsio](http://github.com/SponsioLabs/Sponsio) 好奇其他 openclaw 用户遇到过哪些“合法但错误”的失败，尤其是那些在任何明显日志中都不显示的失败。
查看原文

相似文章

Sponsio：面向LLM Agent的确定性合约层 [P]

Reddit r/MachineLearning

Sponsio是一个开源确定性合约层，用于强制执行LLM Agent的工具调用边界和规则，解决了提示工程和事后审计无法完全解决的生产可靠性问题。

构建AI代理工具调用的开源执行层

Reddit r/AI_Agents

介绍Faramesh，一个开源运行时执行层，用于AI代理工具调用，在操作执行前检查策略，提供超越可观测性或LLM评判的解决方案。

Contract2Tool：学习前提与效果以实现可靠的工具增强型LLM代理

arXiv cs.AI

本文介绍了Contract2Tool，一个从工具元数据、文档和执行轨迹中自动推断轻量级工具契约（前提条件、效果、风险）的框架，为LLM代理实现可靠的因果工具过滤。实验表明，学习到的契约在下游多步骤代理任务中达到了接近黄金契约的性能，同时显著减少了token使用量。