工作方式
一个客服智能体发起退款。
Herkus Guardian 在退款即将生效的那一刻，决定它能不能发生。
1模型提出退款。
退款 订单 #1042 · ¥49.90大模型 → AI 智能体
2在即将生效时接受检查。按设计，这笔退款只生效一次。
退款请求 · 订单 #1042AI 智能体 → Herkus Guardian
现在可以做吗？ 放行
退款 ¥49.90 放行Herkus Guardian → 退款系统
3流程变了。
这张订单被交给了新的流程，之前的请求还在路上。
4迟到的请求到了，不会生效。
迟到的请求 · 退款 订单 #1042 拦下AI 智能体 → Herkus Guardian
已失效 拦下
一笔退款已记录
开始时被允许，到生效时已经失效。
放行暂停拦下结果不明
示意流程 · 虚构数据
动手试
生效那一刻的三项检查
Herkus Guardian 的设计目标是在智能体的动作生效之前检查三件事。改一改请求，看看会发生什么。
批准 A-1182
退款上限 ¥50.00 · 订单 #1042
退到客户账户 ··· 4821
智能体要做的
退款金额
收款账户
与此同时
Herkus Guardian · 生效之前虚构数据
在批准范围内。¥49.90 退到 ··· 4821，与批准 A-1182 一致。通过
仍被批准。批准 A-1182 没有被撤回，也没有过期。通过
上一次结果已知。没有等待回复的上一次尝试。通过
赫库斯的回答
放行。在批准额度内，批准仍然有效。
退款系统 · 已向 ··· 4821 退款 ¥49.90。
示意示例 · 虚构数据
- 退款
- 订单变更
- CRM 更新
- ERP 记账
- 发票付款
有什么不同
先前的批准，不是定论。
一个业务动作可能在某一刻被请求，稍后才到达业务系统。Herkus Guardian 检查的是：在那个稍后的时刻，它还能不能生效。
知道智能体是谁，并不能告诉你这个动作现在能不能生效。
不只是一个审批步骤
| 仅有审批步骤 | Herkus Guardian | |
|---|---|---|
| 什么时候检查 | 发起请求时 | 动作即将生效时 |
| 中途批准被撤回 | 动作可能照样执行 | 动作被拦下 |
| 请求与批准的内容不一致 | 往往不做比对 | 与批准的动作、客户、金额和去向比对 |
| 支付系统没有回复 | 重试或升级处理 | 暂停，直到结果确认 |
| 两个智能体请求同一笔退款 | 两笔都可能执行 | 按设计，同一个业务效果只生效一次 |
| 记录 | 谁批准的 | 每个动作为什么执行或被拦下，依据的是哪一次批准 |
按设计运行在你的环境中。信任与安全