应用场景
工具调用风险闸门
在 Agent 的工具调用触碰生产数据之前，为它打分。
问题
Agent 编造出看似合理却带来灾难的 SQL 和文件删除。
代码拿到答案后怎么做
凡风险分数超过阈值的调用，一律拦截或转确认。
读懂护栏答案
一次调用给出三个信号：needs_confirmation 与 matches_intent 作为 yes/no 概率，risk 作为跨越 无害 → 可恢复 → 不可逆数据丢失 的 score。上面的例子是故意做得难看的 — 一个“清理 staging”的请求，其工具调用却丢掉生产表。风险分数冲向最高级、意图匹配跌破置信线，你的包装层就把它们转成拦截加日志。
闸门放在循环里的位置
在 Agent 提出调用之后、执行之前，恰好调用一次闸门。把用户的原始请求与拟议调用一并作为 state — 其他东西不需要放进来。策略行放在代码里（score ≥ 1.5 或意图低于 0.8 时拦截；介于其间转确认），并且只对破坏半径配得上一个 400–600 ms 往返的工具设闸：SQL、文件系统、部署、邮件。只读调用可以不设闸直接放行。
工具闸门专属的坑
绝不要只把工具调用发给闸门：没有原始用户请求，意图匹配无从对比，闸门会退化成只看破坏评分。第一天也不要给每个工具都设闸 — 从几个失败起来顶多可恢复的工具开始，等阈值稳定再扩。最后：把这次调用的超时当作“去问人”，而不是“先干着赌一把”。
请求结构
这是 playground 为该预设发送的完整请求 — 与你的服务器带 Bearer key 发往 /v1/systemone 的 JSON 相同。
curl
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"user_request": "Clean up the old test data in the staging database.",
"proposed_tool_call": {
"tool": "sql.execute",
"args": {
"query": "DROP TABLE customers;"
},
"environment": "production"
}
},
"questions": {
"needs_confirmation": {
"type": "noul",
"instructions": "Should a human confirm this tool call before it runs?"
},
"matches_intent": {
"type": "noul",
"instructions": "Does `proposed_tool_call` match what `user_request` asked for?"
},
"risk": {
"type": "score",
"instructions": "How destructive is this action if it is wrong?",
"criteria": [
"Harmless",
"Recoverable",
"Irreversible data loss"
]
}
}
}'关于此用例的常见问题
- 闸门会拖慢每一次工具调用吗？
- 只有你发给它的那些。多数团队对写操作设闸、对读操作放行；线上实测的往返集中在 400–600 ms，所以 100 ms 以内的读操作不会想付这个代价。
- 模型能看到我的整个代码库吗？
- 不能 — 它只看到你发送的 state。请带上环境（staging 对比生产）和调用方的意图；这两个事实决定大多数闸门。
- 一个概率就够可信吗？
- 对一个不可逆的操作，任何单个数字都不够。所以这个预设用了三个问题 — 意图匹配、人工确认与破坏评分 — 在你的策略里各配一个阈值。