可靠 Agent 的关键不是要求模型“更加小心”，而是默认模型可能误判，然后用普通软件工程把损失半径限制住。

Agent 比聊天机器人多了什么风险

聊天机器人输出一段文本，错误通常停留在屏幕上。Agent 会调用搜索、数据库、邮件、代码执行或业务 API，错误可能变成真实动作。Toolformer 与 ReAct 等研究说明，外部工具能明显扩展模型能力；能力扩展也同步扩大了攻击面。

AgentBench 在多种交互环境中观察到，长期推理、决策和指令遵循仍是主要障碍。这提醒我们：一次漂亮的演示不能代表长流程可靠性。

护栏一：每个工具都只给最小权限

不要把“万能 shell”“管理员数据库连接”直接暴露给模型。把能力拆成窄工具，例如 查询订单、生成退款草案、提交审批，并分别限制资源范围、参数、调用频率和身份。

只读与写入工具应彻底分开；删除、转账、发信和生产发布等高影响动作必须使用短时凭证，并要求额外批准。

护栏二：用结构化接口代替自然语言猜测

工具参数使用固定 schema，程序在调用前执行类型、枚举、长度和业务规则校验。模型输出“差不多像 JSON”不算成功；只有通过解析与校验，动作才可以进入下一步。

{
  "action": "create_refund_draft",
  "order_id": "ORD-20260722-18",
  "amount": 128.00,
  "reason_code": "DUPLICATE_CHARGE"
}

护栏三：给循环设置预算和停止条件

Agent 很容易反复搜索、重试或在错误计划上继续投入。系统应限制最大步骤、总 Token、工具调用次数、费用、运行时间和连续失败次数。达到边界就停止并返回可理解的状态，而不是无限“再试一次”。

护栏四：把验证做成独立步骤

生成结果不能自己证明自己正确。可以使用确定性校验器检查金额、权限、文件差异和单元测试；需要语义判断时，再使用独立评审模型或规则组合。Reflexion 研究表明，语言形式的反馈和历史反思可以改善后续尝试，但它仍应建立在真实环境反馈之上。

提出动作→规则校验→沙箱执行→结果验证→提交

护栏五：高风险动作设置人工审批

审批页面不应只显示“是否允许”。它应展示动作对象、关键参数、影响范围、依据、执行前后的差异和回退方法。低风险读取可以自动化，高风险写入则应遵循风险分级。

护栏六：记录一条可重放的轨迹

至少记录模型版本、提示版本、输入摘要、工具调用、参数校验、返回状态、人工决定、耗时和费用。敏感数据应脱敏或采用受控存储。没有轨迹，就无法判断失败来自检索、模型、工具还是权限配置。

治理不是上线后的文档工作

NIST 的生成式 AI 风险管理资料将治理、场景映射、风险测量和管理放在同一生命周期中。对 Agent 来说，这意味着风险边界、评测集和事故响应要与功能一起设计。

真正值得跟踪的五个指标

  • 端到端任务成功率：是否真正完成目标，而不是只生成了合理文本。
  • 危险动作率：被规则或审批拦下的越权、错误或不可逆动作比例。
  • 恢复率：工具超时、数据缺失或计划失败后，能否回到安全状态。
  • 人工接管率：哪些任务总需要人处理，是否应该退出自动化范围。
  • 成本与延迟分位数：关注 P95/P99，而不只是平均值。

一条务实的上线顺序

  1. 先做只读、单工具、单步骤任务。
  2. 建立可复现的评测集和失败分类。
  3. 再增加多步骤计划，但所有写操作保持审批。
  4. 积累足够轨迹后，只对低风险且稳定的动作逐项放开。

让模型负责模糊判断，让程序负责确定边界。真正可靠的 Agent，通常不是最自由的那个，而是最清楚什么时候不能继续的那个。

资料来源