我在真实的LangGraph代理周围添加了一个运行时监督器——它在执行前拒绝了一个工具调用，模型重新规划了

我一直在构建ARK，一个用于工具使用AI代理的运行时监督层。理念很简单：保留你的模型，保留你的代理框架，保留你的工具，在运行时周围添加ARK。我终于让它在真实的LangGraph代理中使用真实的OpenAI模型运行了。在这个测试中，我故意创建了一个冲突：用户提示要求最便宜的航班，而运行时策略要求排名第二的选项。目的不是证明排名第二的“更好”；而是测试ARK是否能在不控制代理的情况下执行运行时约束。实际的顺序是：OpenAI模型生成：book_flight(option="A") → ARK检查它 → 拒绝 → A执行=false LangGraph将ARK的反馈反馈给模型 OpenAI模型生成：book_flight(option="B") → ARK再次检查 → 允许 → B执行=true 重要的部分是ARK没有自己将A重写为B。原始模型生成的工具调用是：第一轮：book_flight(option="A") 第二轮：book_flight(option="B") 而实际的副作用是：实际预订：["B"] A执行：false B执行：true 重试状态由ARK的Go运行时维护，而LangGraph继续拥有模型、规划器、工具和执行循环。我还在LangGraph周围测试了ARK的仅观察模式：模型调用 → 工具调用 → 完成 其中LangGraph报告模型/令牌/工具信息，ARK构建决策跟踪并推导运行遥测。SDK尚未公开（可能今天或明天就会），我仍在发布前强化它。实时测试已经发现了一个模型定价解析错误，我们的确定性测试没有暴露，我正在修复它后再发布。对于在生产中运行工具使用代理的人的问题：你愿意在执行路径中有这样的监督器吗？什么会让你信任它或拒绝使用它？