我给 Agent 配了删数据、发邮件、调付费接口的工具,没设任何护栏,结果它一顿"自主操作"删错了数据、群发了邮件,我对着 Agent 的权限与确认机制排查了大半天的复盘
那是我做的一个"能自主干活"的运维 Agent。为了让它强大,我给它配了一堆工具:查数据、删数据、发邮件、调用一个按次收费的第三方接口。我满心欢喜地以为"工具越多越能干",就放它去自动处理任务了。结果出事了:它在处理一个任务时,理解偏了,自主地删掉了一批不该删的数据;还在另一个任务里,因为判断失误,给一大批用户群发了不该发的邮件;那个按次收费的接口,也被它在一个循环里反复调用、产生了一笔意外的费用。我看着这一连串"Agent 自作主张闯的祸",惊出一身冷汗:我光想着给它能力,却完全没想过——它会不会用错这些能力?排查复盘了大半天,我才真正理解了 Agent 工程里一个被严重低估、却至关重要的方面:Agent 的权限控制与人工确认护栏。这篇就把这场"Agent 没护栏闯大祸"的事故,从头复盘一遍。
故障现场:Agent 自主执行了破坏性操作
先看现场。问题就藏在我那个"给了能力、却没给护栏"的设计里:
# 我的 Agent: 给了一堆"有破坏性"的工具, 却没有任何护栏
TOOLS = [
query_data, # 查数据(只读, 安全)
delete_data, # ✗ 删数据(破坏性!) —— 直接让Agent能调
send_email, # ✗ 发邮件(对外、不可撤销!) —— 直接让Agent能调
call_paid_api, # ✗ 调付费接口(花钱!) —— 直接让Agent能调
]
def agent_loop(task):
messages = [...]
while True:
resp = llm.chat(messages, tools=TOOLS)
if resp.tool_calls:
for call in resp.tool_calls:
result = run_tool(call) # ✗✗ 不管什么工具, Agent决定调就直接执行!
messages.append({"role": "tool", "content": result})
continue
return resp.content
# 闯祸是怎么发生的:
# 1. Agent 是"概率的", 它的理解/决策可能出错(它不是 100% 可靠的)。
# 2. 我给了它"删数据/发邮件/花钱"这些【破坏性、不可逆、有代价】的工具。
# 3. 却没有任何护栏: Agent 一旦"决定"调用这些工具, 代码就【无条件执行】。
# 4. 于是: Agent 一次错误的决策(理解偏了、判断失误), 就被【直接、无拦截地】
# 转化成了真实世界里破坏性的、不可撤销的后果:
# - 删错数据(可能无法恢复)。
# - 群发错误邮件(发出去就收不回了)。
# - 反复调付费接口(钱花出去了)。
# 现象拼图:
# - Agent 不可靠(会犯错) + 工具有破坏性 + 没有护栏 = 灾难。
# - 我把"决定权"和"执行权"都【完全交给了】一个会犯错的 Agent,
# 它一犯错, 破坏性操作就直接落地, 没有任何人/机制能拦住。
# - ★ 根因: 我只关注了"给 Agent 能力", 完全忽略了"约束 Agent 的能力"——
# 尤其是对那些"破坏性、不可逆、有代价"的高危操作, 该有护栏。
看着这一连串祸事,我才明白自己的设计漏了最关键的一环。问题的根源,是一个危险的组合:Agent 不可靠(它是概率的、理解和决策会出错)+ 工具有破坏性(删数据/发邮件/花钱,不可逆、有代价)+ 没有任何护栏(Agent 决定调用就无条件执行)= 灾难。我犯的错是:我把"决定权"和"执行权"都完全交给了一个会犯错的 Agent——它一旦理解偏了、判断失误,这个错误的决策就被直接、无拦截地转化成了真实世界里破坏性的、不可撤销的后果(删错数据可能无法恢复、群发邮件收不回、反复调付费接口钱花出去了),没有任何人或机制能拦住。根因是:我只关注了"给 Agent 能力",完全忽略了"约束 Agent 的能力"——尤其是对那些"破坏性、不可逆、有代价"的高危操作,本该有护栏。
第一件事:搞懂为什么 Agent 的高危操作必须有护栏
要解决它,得先理解 Agent 的"不可靠性"和"高危操作"叠加在一起的风险。
为什么 Agent 的高危操作必须有护栏
# 一、Agent 是"不可靠的执行者"(本质决定)
# - Agent 的核心是大模型, 它是"概率的"——理解可能偏、决策可能错、
# 还可能幻觉(编造)、被诱导。它【不是 100% 可靠】的。
# - 你不能假设 Agent "永远做出正确的决策"。它一定会在某些时候犯错。
# 二、操作有"危险等级"之分
# - 安全操作(只读): 查数据、读文件、搜索... 错了顶多结果不对, 无破坏。
# - 危险操作(写/对外/花钱): 删数据、改数据、发邮件、转账、调付费接口、
# 执行命令... 这些是【破坏性、不可逆、有代价】的!
# - 危险等级越高, 错误的后果越严重、越难挽回。
# 三、"不可靠的执行者" × "高危操作" × "无护栏" = 灾难
# - 安全操作: Agent 错了也没关系(无破坏)→ 可以放心让它自主。
# - 高危操作: Agent 一旦错了, 就是真实的、不可逆的损失!
# → 绝不能让它"无护栏地自主执行"。
# 四、护栏的核心思想: 人在回路(Human-in-the-loop) + 最小权限
# - 人在回路: 高危操作, 让"人"来最终确认/审批, Agent 只负责"提议", 不"决定执行"。
# - 最小权限: 只给 Agent 完成任务"必需"的最小权限, 别给它用不到的高危工具。
# - 沙箱/限额: 在隔离环境执行、设操作上限(如最多删N条、花费上限)。
# - 可审计/可回滚: 记录Agent的每个操作, 高危操作尽量可撤销。
# 核心: Agent不可靠会犯错(本质), 高危操作(删改/对外/花钱)破坏性不可逆;
# "不可靠×高危×无护栏=灾难"; 必须用 人在回路确认 + 最小权限 + 沙箱限额 + 可审计回滚 护栏。
想透 Agent 的不可靠性和高危操作的叠加,这个风险就清楚了。一、Agent 是"不可靠的执行者"(本质决定)——它的核心是大模型、是概率的,理解可能偏、决策可能错、还可能幻觉、被诱导,不是 100% 可靠;你不能假设它永远做对决策,它一定会在某些时候犯错。二、操作有"危险等级"之分——安全操作(只读:查数据、搜索)错了顶多结果不对、无破坏;危险操作(删/改数据、发邮件、转账、调付费接口、执行命令)是破坏性、不可逆、有代价的。三、"不可靠的执行者" × "高危操作" × "无护栏" = 灾难——安全操作 Agent 错了也没关系、可放心自主;高危操作 Agent 一旦错了就是真实不可逆的损失,绝不能无护栏地自主执行。四、护栏的核心思想:人在回路(Human-in-the-loop) + 最小权限——人在回路(高危操作让人最终确认/审批,Agent 只"提议"不"决定执行")、最小权限(只给完成任务必需的最小权限)、沙箱/限额(隔离执行、设操作上限)、可审计/可回滚(记录每个操作、高危尽量可撤销)。
第二件事:正解——给高危操作加确认、限权、限额、可审计
搞懂了原理,正解就清晰了:给工具分级、高危操作要人工确认、最小权限、限额与沙箱、全程审计与可回滚。
# ====== 正解一: 给工具"分级", 高危操作走"人工确认" ======
TOOL_RISK = {
"query_data": "safe", # 只读, 安全, 可自主执行
"delete_data": "high", # 高危: 必须人工确认
"send_email": "high", # 高危: 必须人工确认
"call_paid_api": "medium", # 中危: 限额/记录
}
def run_tool_with_guard(call, approve_fn):
risk = TOOL_RISK.get(call.name, "high") # 默认按高危处理(白名单思维)
if risk == "safe":
return execute(call) # 安全操作: 直接执行
if risk == "high":
# ★ 高危操作: 不直接执行! 先把"Agent想做什么"呈现给人, 等人确认
if not approve_fn(call): # 人工确认(同步等待人点"批准")
return {"status": "rejected", "msg": "操作被用户拒绝"}
return execute(call) # 人批准了才执行
# 中危: 执行 + 限额检查(见下)
return execute_with_limit(call)
# ====== 正解二: 人在回路(Human-in-the-loop)的确认 ======
def approve_fn(call):
# 把 Agent 的意图清清楚楚地展示给人, 让人决定
print(f"⚠️ Agent 想执行高危操作:")
print(f" 工具: {call.name}")
print(f" 参数: {call.args}") # 让人看清"要删什么、发给谁"
print(f" 影响: {estimate_impact(call)}") # 如"将删除1200条记录"
return input("批准吗? (yes/no): ") == "yes"
# → 关键: Agent 只"提议"高危操作, 真正"按下执行按钮"的是人。
# 人能拦住 Agent 的错误决策(如"它要删1200条? 不对, 拒绝!")。
# ====== 正解三: 最小权限 + 限额 ======
# - 最小权限: 这个Agent的任务只需要"查"和"发邮件", 就别给它"删数据"工具!
# (能不给的高危工具就不给, 从源头减少风险)
# - 限额: 给操作设上限, 防"失控的批量破坏":
def execute_with_limit(call):
if call.name == "delete_data" and count_affected(call) > 100:
return {"status": "blocked", "msg": "单次删除超100条, 已拦截, 请人工处理"}
if call.name == "call_paid_api" and today_cost() > BUDGET:
return {"status": "blocked", "msg": "今日已达费用上限"}
return execute(call)
# ====== 正解四: 沙箱 + 可审计 + 可回滚 ======
# - 沙箱: 让Agent的危险操作在隔离环境/受限账号下执行(炸了也不影响生产)。
# - 可审计: 记录Agent的每一个操作(谁、何时、做了什么、影响了什么), 出事能追溯。
# - 可回滚: 高危操作尽量设计成"软删除/可撤销"(如删除=标记deleted, 而非物理删)。
audit_log.record(agent_id, call.name, call.args, result, timestamp)
# ====== 正解五: 危险操作"默认拒绝"(白名单思维)======
# - 别"默认允许、黑名单拦截"(总有漏网的); 要"默认拒绝/需确认、白名单放行"。
# - 未知/未分级的工具, 一律按"高危"处理(需确认)。
# 核心: 工具分级, 高危操作"人在回路"确认(Agent只提议人决定执行)+ 最小权限(不给用不到的高危工具)
# + 限额沙箱(防失控批量破坏)+ 审计可回滚(可追溯可撤销)+ 默认拒绝白名单放行。
修复的核心,是"在 Agent 的'决定'和'高危操作真正落地'之间,加上一道道护栏"。正解一:给工具"分级",高危操作走"人工确认"——给每个工具标风险等级(安全/中危/高危),安全的直接执行、高危的必须人工确认;未分级的默认按高危处理(白名单思维)。正解二:人在回路(Human-in-the-loop)的确认——把 Agent 的意图(要删什么、发给谁、影响多大)清清楚楚展示给人,让人决定;关键是 Agent 只"提议"高危操作,真正"按下执行按钮"的是人,人能拦住 Agent 的错误决策。正解三:最小权限 + 限额——只给 Agent 任务必需的工具(能不给的高危工具就不给)、给操作设上限(防失控的批量破坏,如单次删除超 100 条就拦截、费用超预算就拦)。正解四:沙箱 + 可审计 + 可回滚——危险操作在隔离环境/受限账号执行、记录每个操作可追溯、高危操作设计成软删除/可撤销。正解五:危险操作"默认拒绝"(白名单思维)——别默认允许+黑名单拦截(总有漏网),要默认拒绝/需确认 + 白名单放行。归根结底:工具分级,高危操作人在回路确认 + 最小权限 + 限额沙箱 + 审计可回滚 + 默认拒绝白名单放行。
第三件事:Agent 自主性与安全性的权衡
排查后我意识到,这本质是"Agent 自主性"和"安全性"的权衡。我把这个权衡梳理了一遍。
Agent 自主性 vs 安全性的权衡
# 一、核心矛盾:
# - 我们希望 Agent "自主"(少打扰人、自动把事办了, 这才是Agent的价值)。
# - 但 Agent 不可靠, 完全自主 + 有高危能力 = 风险失控。
# - 权衡: 在"自主带来的效率"和"失控带来的风险"之间, 找平衡。
# 二、按"操作风险"分级授权(关键思路):
# - 低风险/只读操作: 让 Agent 完全自主(无需确认), 发挥它的效率。
# - 中风险操作: Agent 自主执行, 但限额 + 记录审计 + 事后可查。
# - 高风险/不可逆操作: 必须人工确认(人在回路), Agent 只提议。
# → 不是"全自主"或"全人工", 而是"按风险分级"地授权。
# 三、随"信任度"渐进放权:
# - 新Agent/不成熟阶段: 多设确认, 谨慎放权(宁可多打扰人)。
# - 经过长期验证、足够可靠后: 可逐步对部分操作放宽(减少确认)。
# - 像带新人: 一开始什么都要审, 信得过了再逐步授权。
# 四、设计理念: 让"代价大的错误"变得"难以发生"
# - 不是追求"Agent永不犯错"(做不到), 而是让"它犯错时, 造成的代价可控":
# * 高危操作有人确认 → 错误决策被拦在执行前。
# * 限额 → 即使漏过, 破坏范围也有限。
# * 可回滚 → 即使发生, 也能挽回。
# - 多层防御: 确认(防) + 限额(限) + 审计(查) + 回滚(救)。
# 核心: Agent自主性与安全性要权衡, 按操作风险分级授权(只读全自主/中危限额审计/高危人工确认)、
# 随信任度渐进放权; 理念是不求Agent不犯错, 而是用多层护栏让"代价大的错误"难以发生、可控可救。
排查让我意识到,这本质是"Agent 自主性"和"安全性"的权衡。一、核心矛盾:我们希望 Agent 自主(少打扰人、自动办事,这是 Agent 的价值),但 Agent 不可靠,完全自主 + 有高危能力 = 风险失控;要在"自主的效率"和"失控的风险"之间找平衡。二、按"操作风险"分级授权(关键思路)——低风险/只读让 Agent 完全自主(发挥效率)、中风险自主执行但限额+审计、高风险/不可逆必须人工确认(Agent 只提议);不是"全自主"或"全人工",而是"按风险分级"地授权。三、随"信任度"渐进放权——新/不成熟阶段多设确认谨慎放权,经长期验证可靠后逐步放宽;像带新人,一开始什么都审、信得过了再授权。四、设计理念:让"代价大的错误"变得"难以发生"——不求 Agent 永不犯错(做不到),而是让它犯错时代价可控(高危有人确认→错误拦在执行前、限额→破坏范围有限、可回滚→能挽回);多层防御:确认(防)+ 限额(限)+ 审计(查)+ 回滚(救)。下面这张图,是这次 Agent 无护栏闯祸的成因与解法:
第四件事:Agent 工具的风险分级与护栏速查
这次踩坑后,我把 Agent 工具按风险分级、以及对应的护栏整理成一张表。
| 风险级别 | 操作举例 | 护栏 |
|---|---|---|
| 安全(只读) | 查数据/搜索/读文件 | 可完全自主,无需确认 |
| 中危(可逆写/有限代价) | 改状态/写日志/小额调用 | 限额+审计,自主但记录 |
| 高危(不可逆/对外/大代价) | 删数据/发邮件/转账/执行命令 | 必须人工确认 |
| 极危(系统级/大范围) | 批量删除/改配置/部署 | 人工确认+多重审批+沙箱 |
| 未分级/未知工具 | — | 默认按高危处理 |
这张表,把 Agent 工具按风险分级、并配上了对应的护栏。核心思路是:护栏的强度,要和操作的风险等级匹配——只读操作完全放开(让 Agent 高效),高危操作严格管控(人工确认),极危操作多重审批。它给我的最大启发是:不是"所有操作都要确认"(那 Agent 就失去了自主的价值、变成了个累赘),也不是"所有操作都放开"(那就是这次的灾难);而是要"分级"——把宝贵的"人工确认"成本,花在真正高危的操作上,而对安全操作充分放权。这其实是一个普适的"风险管理"思想:资源(这里是"人工确认"这种昂贵的注意力)是有限的,要把它按风险高低,有重点地分配——对高风险的重点防控,对低风险的从简放行;"一刀切"(全确认或全放开)都不是好的风险管理。这让我领悟到设计 Agent(乃至任何自动化系统)的一个关键平衡:在"自动化的效率"和"人工的把关"之间,不是非此即彼,而是按风险分级地、智能地决定"哪些交给自动化、哪些保留人工";让自动化处理大量低风险的常规操作(提效),让人专注于少量高风险的关键决策(把关)——这才是人机协作的理想形态。
第五件事:Agent 治理的其他要点
权限护栏之外,Agent 的"治理"还有几个要点,我一并梳理了。
| 治理要点 | 防的问题 | 做法 |
|---|---|---|
| 权限护栏(本文) | 自主执行破坏性操作 | 分级+确认+限权+限额 |
| 可审计 | 出事无法追溯 | 记录每个操作和决策 |
| 可观测 | 不知Agent在干什么 | 监控Agent的行为/token/异常 |
| 可中断 | 失控了停不下来 | 提供紧急停止/熔断开关 |
| 可回滚 | 错误操作无法挽回 | 软删除/操作日志/撤销机制 |
| 沙箱隔离 | 影响生产/越权 | 受限账号/隔离环境 |
| 评估测试 | 不知Agent可不可靠 | 用测试集评估行为安全性 |
这张表,把"Agent 治理"的要点串了起来。除了权限护栏,一个可靠的生产级 Agent 还需要:可审计(记录每个操作可追溯)、可观测(监控它在干什么)、可中断(失控了能紧急停止)、可回滚(错误能挽回)、沙箱隔离(不影响生产)、评估测试(知道它可不可靠)。它给我的最大启发是:"给 Agent 自主能力"和"对 Agent 进行治理",是必须配套的两件事;就像我们给一个员工权限的同时,也会有"审批流程、操作日志、权限边界、绩效考核"等管理机制一样,给 Agent 自主权,也必须配上相应的"治理机制"。我之前只做了前者(给能力)、完全没做后者(治理),才酿成大祸。这让我领悟到一个随着 AI Agent 越来越强而越来越重要的认知:当我们让 AI"自主地、有能力地"在真实世界里行动时,"如何治理这种自主性"(确保它安全、可控、可追溯、可纠正)就和"如何赋予它能力"同等重要,甚至更重要;一个能力强但不可控的 Agent,是危险的;一个能力适中但治理良好的 Agent,才是可用的。能力与治理并重——这是把 AI Agent 真正、负责任地用到生产里的前提。
第六件事:给 Agent 配工具时,我现在的决策习惯
现在每当我要给 Agent 配一个工具,我都会按这张图先评估它的风险、配上护栏:
这张图的精髓,是"配工具前,先问'需不需要'、再按风险配护栏"。第一问 "这任务真的需要它吗":不需要就别配(最小权限,用不到的高危工具不给)。需要的话,按风险等级配护栏:只读安全的让 Agent 完全自主;可逆写的中危操作自主执行 + 限额 + 审计;不可逆/对外/花钱的高危操作必须人工确认(Agent 只提议、展示意图和影响、人决定执行)。贯穿始终的是:全程审计 + 可观测 + 可中断,高危操作尽量可回滚、用受限账号/沙箱执行。这套习惯,让我配工具时,从"工具越多越好、配了就让它随便用"变成了"按需配、按风险设护栏"——核心始终是:Agent 会犯错,高危操作必须有护栏,只给必需的工具、危险操作要人工确认。
我立下的几条规矩
这场"Agent 没护栏闯大祸"的事故,换来了我做 Agent 时,刻进骨子里的几条铁律:
- Agent 不可靠,会犯错。别假设它永远做对决策,要为"它犯错"做好准备。
- 高危操作必须有护栏。删/改/对外/花钱的操作,绝不能让 Agent 无拦截自主执行。
- 高危操作人在回路确认。Agent 只提议,真正按下执行按钮的是人。
- 最小权限。只给 Agent 任务必需的工具,用不到的高危工具坚决不给。
- 限额 + 沙箱。给操作设上限防失控批量,危险操作在受限环境执行。
- 可审计 + 可回滚 + 可中断。记录每个操作、高危可撤销、失控能紧急停止。
- 能力与治理并重。给 Agent 自主权,必须同时配上治理机制。
附:一个带风险分级 + 人工确认 + 审计的工具网关
口说无凭。下面把"风险分级 + 人工确认 + 限额 + 审计"封装成一个统一的工具调用网关:
import time
class ToolGateway:
"""所有 Agent 工具调用的统一入口: 分级 + 确认 + 限额 + 审计。"""
RISK = { # 工具风险分级(白名单, 未列入的默认high)
"query_data": "safe", "search": "safe",
"update_status": "medium", "call_paid_api": "medium",
"delete_data": "high", "send_email": "high", "exec_command": "high",
}
def __init__(self, approve_fn, audit_log, limits=None):
self.approve_fn = approve_fn # 人工确认回调(高危时调用)
self.audit = audit_log
self.limits = limits or {} # 各工具的限额, 如 {"delete_data": 100}
self.usage = {} # 累计用量(限额用)
def call(self, agent_id, name, args):
risk = self.RISK.get(name, "high") # ★ 未知工具默认按高危(白名单思维)
# 1. 高危: 必须人工确认(Agent只提议, 人决定执行)
if risk == "high":
impact = self._estimate_impact(name, args)
self.audit.record(agent_id, name, args, "pending_approval", time.time())
if not self.approve_fn(name, args, impact): # 同步等人批准
self.audit.record(agent_id, name, args, "rejected", time.time())
return {"status": "rejected", "msg": "操作被拒绝"}
# 2. 中危: 限额检查
if risk == "medium":
limit = self.limits.get(name)
if limit is not None and self.usage.get(name, 0) >= limit:
return {"status": "blocked", "msg": f"{name} 已达限额 {limit}"}
self.usage[name] = self.usage.get(name, 0) + 1
# 3. 执行(安全/已确认/未超限的) + 审计
try:
result = self._execute(name, args)
self.audit.record(agent_id, name, args, "success", time.time())
return {"status": "success", "data": result}
except Exception as e:
self.audit.record(agent_id, name, args, f"error:{e}", time.time())
return {"status": "error", "msg": str(e)}
def _estimate_impact(self, name, args):
# 评估影响, 展示给确认者(如"将删除1200条""将发给5000人")
...
def _execute(self, name, args): ...
# 用法: Agent 的所有工具调用都走 gateway.call(), 而不是直接执行
# gateway = ToolGateway(approve_fn=ask_human, audit_log=db_audit,
# limits={"delete_data": 100, "call_paid_api": 50})
# result = gateway.call(agent_id, call.name, call.args)
# 核心: 把"分级+高危人工确认+中危限额+全程审计+未知默认高危"封装进统一工具网关,
# Agent所有工具调用都过它; 一处把关, 让护栏对所有工具默认生效, 而非靠每处自觉。这个 ToolGateway,把这篇文章的所有护栏,落成了一个统一的"工具调用网关"。它的精妙,在于把"风险分级、高危人工确认、中危限额、全程审计、未知工具默认按高危"这一整套护栏,集中在一个 call 方法里;Agent 的所有工具调用都必须经过这个网关,而不是直接执行。这样,护栏就成了"对所有工具默认、强制生效"的统一关卡,而不是"依赖每个工具、每次调用都自觉去加确认"(那必然会漏)。尤其那个"未知工具默认按高危处理"的设计(白名单思维),保证了即使将来新增了一个忘了分级的工具,它也会被默认当成高危、需要确认,而不会"因为没分级就裸奔"。这,正是我想用这个网关,留给每个做 Agent 的人的最后一课:"安全/治理"这种横切关注点,绝不能"依赖每个开发者、每个工具都记得正确处理"(人必然会漏),而要把它做成一个"统一的、绕不过去的、默认安全的"基础设施关卡。这呼应了我在这一系列复盘里反复强调的工程思想:把"正确/安全的做法",从"需要每个人自觉遵守的纪律",变成"系统强制、默认就有"的机制;因为靠纪律会漏,靠机制才可靠。对 Agent 这种"能自主造成真实后果"的系统,这种"把护栏做成统一、默认、强制的关卡"的工程能力,正是把它从"危险的玩具"变成"可信赖的生产力"的关键所在。给强大的能力,配上统一、默认、绕不过的护栏——这是 AI Agent 走向成熟和可信赖的必经之路。
写在最后
回头看,这场由"Agent 没护栏"引发的、自主执行破坏性操作的事故,真正教给我的,远不止"高危操作要加确认"这一套技巧。它让我在 AI Agent 这个新事物面前,补上了一堂关于"权力与约束"的课。我最初做 Agent 的全部心思,都放在"如何让它更强大、更自主、能干更多事"上——我兴奋地给它赋予各种能力(权力),却完全没想过要同时约束这种能力。可这次事故狠狠地告诉我:能力(权力)和约束,从来都该是配套出现的;给一个"不完全可靠的主体"(Agent)以"能造成真实后果的能力",却不加任何约束,几乎必然出事。这其实是一个古老而普适的智慧,在 AI 时代的重现:无论是对人(权力要有监督和制衡)、还是对系统(危险操作要有审批和限制)、还是现在对 AI Agent——"能力越大,越需要相应的约束";不受约束的能力,无论掌握在谁手里(哪怕是善意的人、或一个想把事办好的 Agent),都是危险的。这让我意识到,随着 AI Agent 变得越来越强大、越来越自主地参与到真实世界的操作中,"如何给 AI 的能力套上恰当的缰绳"(对齐、护栏、人在回路、可控可纠),会变成一个和"如何提升 AI 能力"同等重要、甚至更紧迫的命题。具体到我手上的每一个 Agent,这意味着:赋予它能力时,永远同步地问一句"如果它用错了这个能力,会怎样?我该如何约束和兜底?"——让能力始终在可控的边界内运行。能力与约束并重、为强大的自主性配上恰当的缰绳——这,是我用一次"Agent 闯大祸"的事故,换来的、关于 AI Agent、也关于"权力与约束"的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次给 Agent 配高危工具时,先想想"该给它加个怎样的护栏",那我对着那一连串 Agent 自主闯下的祸事复盘的这大半天,就值了。
—— 别看了 · 2026