被拦截并不等于失败：智能体需要边界反馈
大多数智能体设置将拦截的操作视为工具调用失败。
智能体调用一个工具。请求违反了某项规则。系统返回一个通用的错误。工具调用失败。
这乍看之下没问题。不安全的操作被阻止了。但这只解决了一半的问题。
通用错误无法帮助智能体在其限制范围内工作。它将一项策略决策变成了“噪音”。智能体可能会尝试猜测修复方法，可能会重复同样的错误，或者尝试不同的负载 (payload)。这会导致无意义的重试循环。
被拦截的操作应当是一个结构化的决策，而不是一次意外的崩溃。
当请求被拦截时，外部系统本身不应发生改变。然而，响应必须告知智能体如何安全地继续操作。
不要只返回简单的错误，而应使用结构化响应。
想象一下，一个智能体试图写入一个在它规划期间已经发生变化的文件。通用错误会显示“失败”。而结构化响应会显示：
- 决策状态：冲突
- 结果状态：无影响
- 原因：状态陈旧
- 下一步操作：重新读取目标状态
现在智能体知道目标并非无法实现。它只需要更新其信息。它不再盲目猜测，而是采取正确的下一步行动。
这适用于许多场景：
- 如果路径超出范围，建议一条允许的路径。
- 如果效果已经存在，建议复用该结果。
- 如果影响过大，建议等待人工审核。
这并不会使边界变得“软化”。操作依然被拦截，系统依然安全。你只是将死胡同变成了一条引导路径。
你必须在这样做与安全性之间取得平衡。精确的反馈可能会帮助恶意智能体探测你的边界。
对于诸如数据陈旧或输入格式错误等操作摩擦，请使用清晰的原因代码。如果智能体表现出可疑行为或忽略提示，请切换到通用拒绝或人工审核。
将智能体反馈与审计评分分开。智能体需要知道如何保持合规，而系统需要知道智能体的行为是否异常。不要将这两项任务混为一谈。
设立边界是因为智能体正变得足够有用，能够对真实系统执行操作。真实的工作环境是有规则和限制的。
只返回失败的边界是一堵墙；提供引导的边界则是一个工具。
“Blocked”应当意味着：
- 所要求的预期影响未发生。
- 原因已知。
- 下一步的安全行动是明确的。
来源：https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg
可选学习社区：https://t.me/GyaanSetuAi