我给 AI Agent 接了删数据、发退款这种高危工具还让它全自动跑,结果它判断失误自主执行了一个不可逆操作、造成真实损失,我对着这次没有人能拦一下的事故复盘
这是一个让我对"给 AI Agent 多大的权力"深刻反思的故事。我做了一个能自主决策、调用工具的 AI Agent,为了让它"更强大、更自动化",我给它接了一整套工具——其中不乏"删除数据""发起退款""群发通知"这类高风险、且不可逆的操作。然后,我让它全自动地跑,自己决定调用哪个工具。大部分时候,它表现得又聪明又高效。可有一次,它判断失误了——基于一个错误的理解,它自主地调用了那个"删除数据"的工具,误删了一批本不该删的数据;还有一次,它错误地给一批用户发起了退款。这些操作,都是不可逆的;它们在我毫不知情的情况下,被 Agent 悄悄、自动地执行了,造成了实实在在的损失;而最让我后怕的是——从它决定执行,到操作完成,中间没有任何一个环节、任何一个人,能拦它一下。
我顺着这次事故反思,才终于揭开真相,补上了我对 AI Agent 工程一个最关键、却最容易被"追求自动化"冲昏头脑而忽视的认知漏洞:问题的核心,是我把"高风险、不可逆"的操作权,毫无保留地、完全交给了 Agent 去自主决定和执行,而没有设置任何"人在环路(human-in-the-loop)"的确认门禁。我一直想当然地以为,"Agent 越自动、越省人力,就越好";可真相是:AI Agent,本质上是一个"会犯错的、不确定的"决策者(它会幻觉、会误解、会被误导);而把一个"会犯错的决策者",和一堆"会造成不可逆后果的危险工具",直接、无门禁地连在一起、还放手让它全自动跑,本身就是一个极其危险的设计——它等于把一把"可能走火的枪",上了膛、还取消了所有保险。正确的做法,绝不是"追求 100% 的全自动",而是要根据操作的"风险等级",来分级地决定给 Agent 多大的自主权:对低风险、可逆的操作(如查询、读取),可以放手让它自主执行;但对高风险、不可逆的操作(删数据、发钱、对外发送),则必须设置"人工确认"的门禁——Agent 只能"提议"要执行这个危险操作,而最终的"批准执行",必须由一个人来点头。我这才痛彻地明白:给 AI Agent 设计能力时,"它能做什么"和"它能自主做什么",是两个必须分开的问题;自主权,要和"犯错的代价"匹配——代价越大、越不可逆的操作,就越要收紧它的自主权、越要让人来把最后一道关。在 Agent 的能力边界上,"人在环路"不是对自动化的倒退,而是在"自动化的效率"和"风险的可控"之间,一道必不可少的安全阀。
故障现场:危险工具无门禁,Agent 自主执行不可逆操作
我把这次"没人能拦"的事故,用伪代码摊开给你看:
# ✗ 灾难: 危险工具直接给 Agent 全自动调用, 无任何确认门禁
TOOLS = {
"query_orders": query_orders, # 低风险(只读)
"delete_data": delete_data, # ✗ 高风险! 不可逆! 却和只读工具一样平等地给了 Agent
"issue_refund": issue_refund, # ✗ 高风险! 涉及钱! 不可逆!
"send_notification": send_all, # ✗ 高风险! 对外群发, 发出去收不回!
}
def agent_loop(task):
while not done:
action = llm.decide_next_action(context) # ✗ Agent 自主决定调哪个工具
# ✗ 不管是查询还是删库, 一律直接执行, 没有任何拦截!
result = TOOLS[action.tool](action.args) # ✗ 危险操作也就这么执行了
context.append(result)
# 事故是怎么发生的:
# 1. Agent 基于一个错误的理解(幻觉/误解上下文)。
# 2. 它自主决定: "我应该调用 delete_data 删掉这批数据" / "给这些人退款"。
# 3. 代码无条件执行了 → 不可逆操作完成 → 数据没了 / 钱退了。
# 4. 全程无人知晓、无人能拦, 等发现已造成损失。
# 根本问题:
# - 把"会犯错的 Agent" + "不可逆的危险工具" 直接无门禁连在一起。
# - 没有按风险分级: 查询和删库, 被同等对待、都全自动。
# - 没有 human-in-the-loop: 危险操作没有人来批准。
# - 没有 dry-run / 审计 / 回滚: 出了事难补救、难追溯。
# 类比: 给一个"聪明但偶尔会犯糊涂"的实习生, 直接开通了生产数据库的删除权限
# 和财务的退款权限, 还让他自己看着办、不用任何人审批 —— 迟早出事。
# 根因: 高风险不可逆操作完全交给 Agent 自主执行, 无人工确认门禁/无权限分级,
# Agent 一旦判断失误就酿成不可逆的真实损失, 且无人能拦。看着这段"把删库和查询一视同仁地全自动"的代码,我才算彻底想明白了这次事故的根源。问题的核心,是我把"会犯错的 Agent"和"不可逆的危险工具",直接无门禁地连在了一起。事故是这么发生的:Agent 基于一个错误的理解(幻觉/误解上下文),自主决定"调用 delete_data 删数据"/"给这些人退款",代码无条件执行,不可逆操作就这么完成了,全程无人知晓、无人能拦。根本问题有四:把"会犯错的 Agent"+"不可逆的危险工具"直接无门禁连在一起;没有按风险分级(查询和删库被同等对待、都全自动);没有 human-in-the-loop(危险操作没人批准);没有 dry-run/审计/回滚(出事难补救难追溯)。打个比方:这就像给一个"聪明但偶尔犯糊涂"的实习生,直接开通了生产数据库的删除权限和财务退款权限,还让他自己看着办、不用任何人审批——迟早出事。归根结底:高风险不可逆操作完全交给 Agent 自主执行,无人工确认门禁/无权限分级,Agent 一旦判断失误就酿成不可逆的真实损失,且无人能拦——这,就是根源。
第一件事:搞懂为什么自主权要和风险匹配
定位到根源,我必须把"Agent 的自主权该如何设计"从根上彻底搞清楚:
Agent 是会犯错的决策者; 自主权必须和"犯错代价"匹配
# 大前提: Agent 是"会犯错、不确定"的
# - 它会幻觉、会误解上下文、会被诱导、会判断失误(见幻觉/盲信篇)。
# - 即: 它的每一个决定, 都有"出错"的概率。
# 风险来自两个维度:
# - 操作的"危害程度": 删数据/发钱/对外发送 >> 只读查询。
# - 操作的"可逆性": 不可逆(删了/发了收不回) >> 可逆(改了能改回)。
# → 高危害 + 不可逆 = 最高风险, 一旦错了无法挽回。
# 核心原则: 自主权 与 犯错代价 匹配
# - 低风险可逆操作(查询/读取): 放手让 Agent 全自动。
# - 中风险: 自动执行但记录、可回滚、有告警。
# - 高风险不可逆(删/钱/对外): 必须 human-in-the-loop, 人来批准。
# → "能力"和"自主执行的权限"要分开: 给它能力, 但收紧危险操作的自主权。
# human-in-the-loop(人在环路):
# - Agent 只"提议"危险操作, 给出理由和将影响的范围。
# - 由人审核、确认后, 才真正执行。
# - 是"效率"和"可控"之间的安全阀, 不是对自动化的倒退。
# 还要配套的安全机制:
# - 权限最小化: 只给 Agent 完成任务必需的工具/权限。
# - dry-run(预演): 危险操作先"模拟"出"将做什么", 给人/Agent 自检。
# - 审计日志: 谁(哪个Agent)在何时调了什么工具、做了什么, 全程可追溯。
# - 可回滚/软删除: 尽量让操作可逆(软删而非硬删、可撤销的退款)。
# - 限额/限频: 危险操作设上限(如单次退款金额上限)。
# 关键认知: 给 Agent 自动化, 但别在"高危不可逆"的地方, 放弃人的最终把关。
# 核心: Agent 会犯错, 自主权要和犯错代价匹配; 高危不可逆操作必须人在环路;
# 配合权限最小化+dry-run+审计+可回滚+限额, 在效率和可控间设安全阀。原理终于清晰了。大前提:Agent 是"会犯错、不确定"的——它会幻觉、误解上下文、被诱导、判断失误,每个决定都有"出错"的概率。风险来自两个维度:操作的"危害程度"(删数据/发钱 >> 只读查询)和"可逆性"(不可逆 >> 可逆);高危害 + 不可逆 = 最高风险,一旦错了无法挽回。由此引出核心原则:自主权 与 犯错代价 匹配——低风险可逆操作(查询)放手全自动、中风险自动但记录可回滚有告警、高风险不可逆(删/钱/对外)必须 human-in-the-loop 人来批准;"能力"和"自主执行的权限"要分开:给它能力,但收紧危险操作的自主权。而 human-in-the-loop:Agent 只"提议"危险操作、给出理由和影响范围,由人审核确认后才执行;它是效率和可控之间的安全阀,不是对自动化的倒退。还要配套安全机制:权限最小化(只给必需的工具)、dry-run 预演(危险操作先模拟出"将做什么")、审计日志(全程可追溯)、可回滚/软删除、限额限频。由此,我刻下一个关键认知:给 Agent 自动化,但别在"高危不可逆"的地方,放弃人的最终把关。归根结底:Agent 会犯错,自主权要和犯错代价匹配;高危不可逆操作必须人在环路;配合权限最小化+dry-run+审计+可回滚+限额,在效率和可控间设安全阀。
第二件事:正解——风险分级 + 人工确认门禁 + 配套安全机制
搞懂了原理,正解就清晰了:给工具按风险分级,低风险放手、高风险设人工确认门禁;再配上权限最小化、dry-run、审计、可回滚。
# ✓ 正解: 工具按风险分级, 危险操作走人工确认门禁
TOOL_RISK = {
"query_orders": "low", # 只读, 可逆
"update_status": "medium", # 可逆, 自动但记录+告警
"delete_data": "high", # ✗→✓ 高风险: 不可逆, 必须人工确认
"issue_refund": "high", # 涉及钱: 必须人工确认
"send_notification": "high", # 对外: 必须人工确认
}
def execute_action(action):
risk = TOOL_RISK.get(action.tool, "high") # ✓ 默认按最高风险(白名单思维)
if risk == "low":
return TOOLS[action.tool](action.args) # ✓ 低风险: 自动执行
if risk == "medium":
result = TOOLS[action.tool](action.args)
audit_log(action, result) # ✓ 记录审计 + 发告警
return result
if risk == "high":
# ✓ 高风险: 不直接执行! 走人工确认门禁
preview = dry_run(action) # ✓ 先 dry-run: 算出"将影响什么"
approval = request_human_approval( # ✓ 请人审批
tool=action.tool, args=action.args,
reason=action.reason, preview=preview, # 给人看清: 要做什么、影响范围
)
if approval.granted:
result = TOOLS[action.tool](action.args)
audit_log(action, result, approver=approval.who) # ✓ 记下谁批的
return result
else:
return f"操作被拒绝: {approval.reason}" # ✓ 没批准就不执行
# 配套安全机制:
# ✓ 权限最小化: Agent 只拿到完成任务"必需"的工具(别一股脑全给)。
# ✓ dry-run: 危险操作先模拟, 输出"将删除 N 条/将退款 X 元", 给人确认。
# ✓ 审计日志: 每步谁(哪个Agent)、何时、调了什么、做了什么, 全可追溯。
# ✓ 可回滚: 软删除(标记而非物理删)、可撤销的操作, 尽量让"不可逆"变"可逆"。
# ✓ 限额限频: 危险操作设上限(单次退款≤X元, 单次删除≤N条, 超了强制人工)。
# 核心: 工具按风险分级, 低风险自动、中风险自动+审计、高风险走 dry-run+人工确认门禁;
# 配合权限最小化、审计、可回滚、限额, 给 Agent 装好刹车和安全带。修复的方向,是给 Agent 的能力"装上刹车和安全带"。核心是 按风险给工具分级、分级处理:低风险(只读)自动执行;中风险(可逆)自动但记审计、发告警;高风险(不可逆/涉及钱/对外)绝不直接执行,而是走"人工确认门禁"。高风险的处理流程是:先 dry-run(预演),算出"将影响什么"(将删除 N 条/将退款 X 元);再 request_human_approval(请人审批),给人看清"要做什么、影响范围、理由";只有人批准了才真正执行,并记下"谁批的";没批准就不执行。这里有个重要细节:风险等级默认按"最高风险"处理(TOOL_RISK.get(tool, "high"))——白名单思维,没明确标为低风险的,一律当高风险对待,宁可保守。还要配上一整套安全机制:权限最小化(只给必需的工具)、dry-run(危险操作先模拟)、审计日志(全程可追溯)、可回滚(软删除而非物理删,尽量让"不可逆"变"可逆")、限额限频(危险操作设上限,超了强制人工)。归根结底:工具按风险分级,低风险自动、中风险自动+审计、高风险走 dry-run+人工确认门禁;配合权限最小化、审计、可回滚、限额,给 Agent 装好刹车和安全带。
第三件事:Agent 安全设计的几个层次
这次踩坑后,我把 Agent 安全/可控设计的几个层次,系统梳理了一遍——人工确认只是其中一环:
Agent 安全可控设计的几个层次
# 1. 权限层: 最小权限原则
# - Agent 只拿完成任务"必需"的工具和数据权限, 别一股脑全开。
# - 不同任务/场景, 给不同的工具集(别给只读任务删除权限)。
# 2. 决策层: 风险分级 + 人在环路
# - 低风险自动, 高风险(不可逆/涉钱/对外)人工确认(本文)。
# - 关键决策让人把关, Agent 提议、人批准。
# 3. 执行层: 预演 + 限额 + 可回滚
# - dry-run 预演影响; 危险操作设限额/限频; 尽量可回滚(软删)。
# 4. 观测层: 全程审计 + 告警
# - 记录每步: 谁、何时、调了什么、参数、结果、谁批的 → 可追溯可复盘。
# - 危险操作/异常行为 → 实时告警, 出事能第一时间发现。
# 5. 兜底层: 熔断 + 人工接管
# - Agent 行为异常(频繁失败/触碰红线)→ 熔断停止, 转人工。
# - 永远保留"一键停止 Agent / 人工接管"的能力。
# 6. 测试层: 红队 + 对抗测试
# - 主动测试: 诱导 Agent 做危险操作, 看防线扛不扛得住。
# 关键认知: Agent 越自主, 越要有"层层防护"; 给它能力的同时, 给它边界。
# - 不是"信任 Agent 不犯错", 而是"假设它会犯错, 并让犯错的代价可控"。
# 核心: Agent 安全是分层的 —— 权限最小化+风险分级人在环路+预演限额可回滚
# +审计告警+熔断人工接管+对抗测试; 给能力的同时给边界。这套分层防护,让我对"如何让 Agent 安全可控"有了体系化的认识。权限层(最小权限):只给必需的工具和数据权限、不同任务给不同工具集;决策层(风险分级+人在环路):低风险自动、高风险人工确认(本文);执行层(预演+限额+可回滚):dry-run 预演、危险操作设限额、尽量可回滚;观测层(审计+告警):每步全程记录可追溯、危险操作实时告警;兜底层(熔断+人工接管):行为异常就熔断转人工、永远保留"一键停止 Agent"的能力;测试层(红队+对抗测试):主动诱导 Agent 做危险操作、测防线。由此,我刻下一个关键认知:Agent 越自主,越要有"层层防护";给它能力的同时,要给它边界——不是"信任 Agent 不犯错",而是"假设它会犯错,并让犯错的代价可控"。归根结底:Agent 安全是分层的——权限最小化 + 风险分级人在环路 + 预演限额可回滚 + 审计告警 + 熔断人工接管 + 对抗测试;给能力的同时给边界。
下面这张图,是这次"危险操作无门禁"的成因与解法:
第四件事:操作风险分级与对应策略
这次踩坑后,我把"操作按风险分级、对应不同自主权策略"整理成一张表,设计 Agent 工具时照着分。
| 风险等级 | 典型操作 | 可逆性 | Agent 自主权策略 |
|---|---|---|---|
| 低 | 查询/读取/搜索 | 无副作用 | 放手全自动 |
| 中 | 更新状态/写日志 | 可逆/影响小 | 自动 + 审计 + 告警 |
| 高(数据) | 删除/批量修改 | 不可逆/影响大 | 人工确认 + 软删 + 限量 |
| 高(资金) | 退款/付款/扣费 | 涉及钱 | 人工确认 + 限额 + 双重审批 |
| 高(对外) | 群发/发邮件/发布 | 发出收不回 | 人工确认 + 预览 + 小范围灰度 |
| 极高 | 删库/改权限/上线 | 灾难性不可逆 | 禁止 Agent 自主, 强制人工 |
这张表,把"给 Agent 多大自主权"变成了"对号入座"。核心逻辑是:风险越高、越不可逆,Agent 的自主权就越要收紧、人的把关就越要加强。低风险(查询读取)放手全自动;中风险(更新状态)自动但加审计告警;高风险数据操作(删除)人工确认 + 软删 + 限量;高风险资金操作(退款)人工确认 + 限额 + 双重审批;高风险对外操作(群发)人工确认 + 预览 + 小范围灰度;而极高风险(删库/改权限/上线)则直接禁止 Agent 自主、强制人工。它给我的启发是:"给 Agent 自主权",不是一个"给/不给"的二元选择,而是一个沿着"风险等级"精细分级的光谱;真正成熟的 Agent 设计,是在这个光谱上,为每一类操作,都精准地匹配上"恰当的自主权和把关力度"——该放手的放手(享受自动化效率),该收紧的收紧(守住风险底线)。
第五件事:人在环路的几种形态
"人在环路"不是只有"每步都问人"一种,它有多种形态,各有适用。我梳理了一下。
| 形态 | 做法 | 适用 |
|---|---|---|
| 事前审批(human-in-the-loop) | 危险操作执行前必须人批准 | 高风险不可逆操作(本文核心) |
| 事中监督(human-on-the-loop) | Agent 自动跑, 人实时监控可随时干预 | 中风险/需要速度但要可控 |
| 事后审计(human-after-loop) | Agent 自动执行, 人事后审查日志 | 低风险/可回滚, 重效率 |
| 抽样审核 | 随机抽一部分让人复核 | 量大、单个风险不高 |
| 阈值触发 | 超过某阈值(金额/数量)才要人审 | 大部分自动, 大额才把关 |
| 双人复核 | 极高风险需两个人都批准 | 资金/删库等灾难级操作 |
这张表,让我看到"人在环路"是个有弹性的谱系,而非只有"事事问人"这一种笨办法。事前审批(执行前必须人批准):用于高风险不可逆操作(本文核心);事中监督(自动跑、人实时盯、可随时干预):用于需要速度但要可控的;事后审计(自动执行、人事后查日志):用于低风险可回滚、重效率的;抽样审核(随机抽查):用于量大、单个风险不高的;阈值触发(超过金额/数量才要人审):大部分自动、大额才把关;双人复核:用于资金/删库等灾难级操作。它给我的最大启发是:"引入人的把关"和"追求自动化效率",并不是非此即彼的对立,而是可以通过这些灵活的形态,巧妙地平衡:大部分情况让 Agent 自动跑(效率),只在"真正需要"的关键节点(高风险、大额、异常)把人请进来(可控)。好的 Agent 系统,不是"要么全自动、要么全人工"的极端,而是"该自动时自动、该有人时有人",在效率和安全之间,找到那个最适合业务的、动态的平衡点。
第六件事:给 Agent 接一个工具时,我现在会怎么决策
现在,每当我准备给 Agent 接入一个工具,脑子里都会过一遍这张决策图——核心就一问:这个操作错了,代价多大、能挽回吗?
这张图的灵魂,是接入工具前的那个必问的问题:这个操作错了,代价多大、能挽回吗?第一问:是只读/无副作用吗?——是,低风险,放手全自动。有副作用,再追问:出错代价大吗?可逆吗?——可逆/影响小,中风险(自动+审计+告警);不可逆/涉钱/对外,高风险(必须人在环路:dry-run 预演 + 人工确认门禁 + 权限最小化 + 限额 + 软删可回滚);灾难级(删库/改权限),直接禁止 Agent 自主、强制人工。而贯穿始终的,是全程审计日志、永远保留"一键停止 Agent"的能力,以及用对抗测试主动诱导它做危险操作、验证防线。这套判断,让我给 Agent 接工具时,不再"图自动化省事就全放开"——核心始终是:自主权要和"犯错代价"匹配,越不可逆越要有人把关。
我立下的几条规矩
这场"没人能拦"的事故,换来了我做 AI Agent 时,刻进骨子里的几条铁律:
- Agent 是会犯错的决策者,自主权要和犯错代价匹配。越不可逆、代价越大的操作,越要收紧它的自主权。
- 高风险不可逆操作必须人在环路。删数据、发钱、对外发送——Agent 只能提议,人批准才执行。
- 工具按风险分级,默认按最高风险。没明确标为低风险的,一律当高风险对待(白名单思维)。
- 权限最小化。只给 Agent 完成任务必需的工具和权限,别一股脑全开。
- 危险操作要 dry-run + 限额 + 可回滚。先预演影响、设上限、尽量软删可撤销,让不可逆变可逆。
- 全程审计 + 一键停止。每步可追溯,永远保留人工接管和紧急停止 Agent 的能力。
- 做对抗测试。主动诱导 Agent 做危险操作,验证防线扛不扛得住,别等真出事。
附:一个带风险分级+人工确认门禁的 Agent 执行器
把风险分级、dry-run、人工确认、审计、限额揉到一起,这是我现在封装"Agent 工具执行器"的骨架,可以直接参照:
from enum import Enum
class Risk(Enum):
LOW = 1; MEDIUM = 2; HIGH = 3; CRITICAL = 4
# 工具注册: 声明每个工具的风险、是否可 dry-run、限额
TOOL_REGISTRY = {
"query": {"fn": query, "risk": Risk.LOW},
"update": {"fn": update, "risk": Risk.MEDIUM},
"delete_data": {"fn": delete, "risk": Risk.HIGH, "dry_run": dry_delete, "limit": 100},
"issue_refund": {"fn": refund, "risk": Risk.HIGH, "dry_run": dry_refund, "limit": 1000},
"drop_table": {"fn": drop, "risk": Risk.CRITICAL}, # 禁止自主
}
def execute(action, agent_id):
meta = TOOL_REGISTRY.get(action.tool)
if meta is None:
raise PermissionError(f"未授权的工具: {action.tool}") # ✓ 白名单
risk = meta["risk"]
audit_log("attempt", agent_id, action) # ✓ 先记一笔"尝试"
if risk == Risk.CRITICAL: # ✓ 极高风险: 禁止 Agent 自主
raise PermissionError(f"{action.tool} 禁止 Agent 自主执行, 需人工操作")
if risk == Risk.LOW: # ✓ 低风险: 直接执行
return _run(meta, action, agent_id)
if risk == Risk.MEDIUM: # ✓ 中风险: 执行 + 告警
result = _run(meta, action, agent_id)
alert("medium-risk action", agent_id, action)
return result
# HIGH: dry-run 预演 + 限额检查 + 人工确认
if "limit" in meta and action.affected_count() > meta["limit"]:
raise PermissionError(f"超过限额 {meta['limit']}, 强制人工处理") # ✓ 限额
preview = meta["dry_run"](action.args) if meta.get("dry_run") else None # ✓ 预演
approval = request_human_approval(action, preview, agent_id) # ✓ 人工确认
if not approval.granted:
audit_log("rejected", agent_id, action, approval.who)
return f"操作被 {approval.who} 拒绝"
return _run(meta, action, agent_id, approver=approval.who)
def _run(meta, action, agent_id, approver=None):
result = meta["fn"](action.args)
audit_log("executed", agent_id, action, approver, result) # ✓ 记下结果+谁批的
return result
# 核心: 工具白名单+风险分级, CRITICAL禁止自主、HIGH走dry-run+限额+人工确认、
# MEDIUM自动+告警、LOW直接执行; 全程审计, 把"能力"和"自主权"分开管控。这个执行器,把前面所有的安全原则,固化成了一道"每个工具调用都必经的关卡"。它的几个关键设计:第一,工具白名单——不在 TOOL_REGISTRY 里的工具,直接拒绝(未授权);第二,每个工具声明自己的风险等级、dry-run 函数、限额;第三,按风险分级处理——CRITICAL(删库)直接禁止 Agent 自主、HIGH(删数据/退款)走"限额检查 + dry-run 预演 + 人工确认"、MEDIUM 执行+告警、LOW 直接执行;第四,全程审计——从"尝试"到"执行/拒绝",每一步都记下"哪个 Agent、什么操作、谁批的、结果如何"。这一道关卡,把"能力"(Agent 能调哪些工具)和"自主权"(它能不经人就调哪些)清晰地分开管控了。这,正是我想用这段骨架,留给每一个做 Agent 的人的最后一课:"安全可控",不该是散落在各处、靠每次调用时自觉去判断的事,而该收敛成一个统一的、强制的"执行器关卡"——让每一个工具调用,都必须穿过这道关卡的风险审查;把"风险分级、人工确认、限额、审计"这些安全机制,内建进 Agent 的基础设施,而不是依赖开发者在每个调用点的"小心"。当"安全"成了架构的默认行为,而非个人的自觉时,你的 Agent 才真正可以放心地、自动地跑起来。
写在最后
回头看,这场由"给 Agent 太大权力"引发的、不可逆操作失控的事故,真正教给我的,是一个比"加人工确认"本身更深的道理:当我们把"行动的能力"赋予一个"会犯错的智能体"时,我们就同时,把"为它的错误后果负责"的担子,也揽到了自己身上;而"能力"和"责任(后果)"必须匹配——你给它多大的、能造成多大后果的能力,就必须为它配上多强的、能约束这种后果的"缰绳"。我之前的错误,是只陶醉于"赋予 Agent 强大能力、实现全自动"的兴奋,却忘了同时,为这份强大的能力,配上与之匹配的约束;我给了它一匹烈马,却没给它套上缰绳。这让我深刻地领悟到:在 AI Agent 这个"赋予机器以行动力"的时代,一个负责任的设计者,衡量自己工作的标准,不该只是"我的 Agent 有多强大、多自动",更应该是"当我的 Agent 犯错时,后果是否可控、是否能被及时拦住和挽回"。"自动化"很诱人,但"可控"才是底线;尤其是当 Agent 的手,伸向了那些"会造成真实、不可逆后果"的操作时,那道"人的把关",绝不能省。给 Agent 能力的同时,给它与能力匹配的缰绳——这,是我用一次"没人能拦"的事故,换来的、关于 AI Agent、也关于"如何驾驭强大而不确定的力量"的、最朴素也最深刻的领悟。如果这篇复盘,能让你在下一次给 Agent 接入危险工具时,先为它装好那道"人工确认"的门禁,那我对着那次不可逆的损失复盘的这大半天,就值了。
—— 别看了 · 2026