AI 一分钟教学｜2026/10/07：AI Agent 出错后别急着重跑，先记「发生什么／碰了什么／谁要知道」｜文章

AI Agent 寄错信、碰到不该碰的系统或做出异常操作时，第一反应常是改 Prompt 再跑一次。但重跑可能让原始纪录被覆盖，甚至让同一个问题再发生。今天只学一个方法：先停下流程，留下「发生什么／碰了什么／谁要知道」三格事件纪录，再决定修复、重跑或升级通报。澳洲最近讨论 AI Agent 强制事故通报，也正好说明「出了什么事、影响到哪里、谁应该知道」已开始变成正式治理问题。

AI Agent 做错事情时，

很多人的第一反应是：

「改一下 Prompt，再跑一次。」

但如果这个 Agent 已经会：

寄 Email、

改 CRM、

开网站、

调用 API、

读公司数据、

操作其他系统，

直接重跑可能不是最好的第一步。

因为你可能还没搞清楚：

它刚才到底做了什么。

更麻烦的是，

第二次运行还可能：

覆盖原本纪录、

再做一次相同错误，

甚至把影响范围扩大。

所以今天只学一个动作：

先停，再记三格。

不是先修 Prompt。

不是先重跑。

而是先留下：

发生什么／碰了什么／谁要知道。

这篇是给谁的？

如果你已经开始让 AI：

自动整理数据、

更新 CRM、

追网站、

操作 App、

创建文档、

寄出内容

或定期运行工作，

这三格就值得先准备好。

尤其是小团队。

因为大公司可能已经有：

Security Team、

Incident Response、

Audit Log、

Compliance Process。

小公司最常发生的是：

「好像有点怪。」

「先重跑看看。」

「没事就算了。」

但真正出了问题后，

最难补的往往不是 Prompt。

而是：

没有人还记得第一版到底发生了什么。

第一步：先停，不要立刻 Retry

假设 Agent 原本应该：

整理 20 笔客户询问，

创建 Draft，

等人确认后再寄。

结果你发现：

其中 3 封已经真的寄出去了。

这时不要先按：

Retry。

也不要先叫 AI：

「把刚才错的修好。」

先停止：

调度、

Agent Run、

Automation

或相关自动运行。

因为现在最重要的不是：

让工作赶快完成。

而是：

先把现场保留下来。

第一格：发生什么？

不要只写：

「AI 出错。」

这句以后几乎没有用。

至少记清楚：

原本期待什么？

实际发生什么？

大约什么时间发生？

是哪一个 Agent／Workflow？

例如：

原本：

只创建 Email Draft。

实际：

3 封 Email 已送出。

这样未来回头查，

才知道你要找的是：

Draft Permission 问题？

Approval Step 没运行？

还是 Send Action 被错误开放？

所以第一格是在回答：

「它偏离原本工作哪里？」

第二格：碰了什么？

接着不要只看：

「最后答案错了。」

要看 AI 在整段流程里：

到底碰过什么。

例如：

哪个 App？

哪个 Account？

哪些数据？

哪个 API？

有没有对外送数据？

有没有改写内容？

有没有真的运行 Action？

假设 Agent：

读错一份内部文档，

和：

把客户数据送到外部网站，

严重程度完全不同。

所以第二格可以写成：

系统：CRM、Gmail

数据：3 笔客户联系数据

外部动作：3 封 Email 已送出

你不是现在就要完成完整鉴识报告。

只是先把：

影响范围

框出来。

为什么「碰了什么」这格这么重要？

因为 AI Agent 最大的差别，

就是它不只是产生文字。

它可能真的：

读、

写、

删、

寄、

查、

调用、

下载、

上传。

所以一个 AI Incident 的严重程度，

不能只看：

「回答错多少？」

更要看：

错误有没有跨进真实系统。

如果只是：

一份内部草稿写错日期，

可能重新生成就好。

但如果它已经：

寄给客户、

改掉帐务纪录、

碰到个资、

访问外部系统，

处理方式就完全不同。

第三格：谁要知道？

这一格很容易被忽略。

小团队看到问题修掉后，

常常就结束了。

但至少要问：

这件事除了我之外，还有谁需要知道？

可以先分三层。

第一层：工作负责人

谁负责这条 Workflow？

他一定要知道。

否则同一个 Agent 明天可能照样再跑。

第二层：公司内部需要处理的人

如果涉及：

帐号权限、

资安、

个资、

客户数据、

付款、

合约、

正式纪录，

就可能需要：

主管、

IT、

Security、

Privacy、

Legal

或其他负责人知道。

小公司不一定有这些正式部门。

但还是要有：

一个明确负责做判断的人。

第三层：外部对象

如果 AI 的错误已经影响：

客户、

合作伙伴、

外部网站、

第三方系统，

就要进一步判断：

对方是否需要被通知。

这里不能用一条全球通用规则回答。

因为：

不同国家、

数据类型、

合约、

产业

可能有完全不同的通报义务。

Proof：澳洲现在就在讨论这个问题

10 月 6 日，

OpenAI 与 Anthropic 在澳洲国会听证上，

都表态支持：

AI Agent 发生 Data Breach 等事件时，

创建：

Mandatory Disclosure Framework。

也就是未来不一定再只是：

「公司自己决定要不要说。」

这场争议的重要背景是：

OpenAI 的 Agent 先前进入澳洲 Medicare Statistics 系统，

事件发生后约三个月，

澳洲政府才收到正式通知。

OpenAI Chief Strategy Officer Jason Kwon 在听证中也承认：

公司内部事件信息传递可以做得更好。

所以今天真正值得小团队学的，

不是：

「澳洲可能要立什么法。」

而是：

如果你连最基本的事件纪录都没有，未来根本无法判断要不要通报。

这也不是 SasaDaily 自己才这样想

美国 NIST 的 AI Risk Management Framework，

在 MANAGE 4 里就明确把：

Incident Response、

Recovery、

Communication

列入 AI 系统部署后的风险管理。

其中还特别要求：

Incident 与 Error 应该：

被追踪、

被记录、

被处理，

并和相关 AI Actors 沟通。

NIST 的 Generative AI Profile 也指出，

Logging、

Recording、

Analyzing

AI Incident，

有助于后续追查影响来源，

以及避免相同问题再发生。

所以：

留下事件纪录不是大公司才需要的官僚进程。

它是 AI 工作流程真正开始自动化后，

很基本的一层控制。

但不是每一次 AI 答错都叫 Data Breach

这个 Boundary 很重要。

AI：

摘要写错一句，

和：

未经授权碰到别人的系统，

不是同一个等级。

也不是所有小错误都需要：

报政府、

找律师、

通知全部客户。

今天这个三格方法的目的不是：

把每一次 AI 小失误都变成重大事故。

而是先留下足够信息，

让你后面可以判断：

这是普通品质问题？

流程错误？

权限错误？

数据外泄？

还是真正需要升级处理的安全事件？

也不要把敏感数据全部贴进 Incident Log

事件纪录本身也要注意数据边界。

如果涉及：

密码、

API Key、

完整信用卡号、

医疗数据、

敏感个资，

不要为了「留下证据」

就把全部内容拷贝进一般文档或公开群组。

比较合理的是：

记录：

哪类数据、

哪个系统、

哪段时间、

影响范围，

再把真正敏感的原始纪录留在适当、安全的位置。

一分钟记法

Agent 出错后：

先停。

然后记三格。

1. 发生什么？

原本应该怎样？

实际发生什么？

2. 碰了什么？

哪些系统、

数据、

帐号

或外部服务受到影响？

3. 谁要知道？

Workflow Owner？

主管？

IT／Security／Legal？

客户或第三方？

把这三格填完，

再决定：

修复、

重跑、

撤销动作、

通知相关人员

或升级 Incident Response。

最后不要只修 Prompt

如果问题已经真的发生，

只改一句 Prompt：

「下次不要这样做」

通常不够。

还要回头看：

权限是不是太大？

Approval Step 为什么没挡住？

Log 有没有留下？

系统能不能 Undo？

同样错误能不能被自动侦测？

什么条件下一定要停？

真正成熟的 AI Workflow，

不是永远不出错。

而是：

出错时你知道发生了什么、影响到哪里，而且有人知道下一步该接手。

如果你也想知道自己的工作里，哪一步最适合先交给 AI，留言「流程」，我可以先帮你看看从哪一步开始。