夜雨聆风
最近在 Hacker News 上刷到一篇让我笑出声又笑不出来的文章。Lan Tian 在他的博客上完整记录了一个 AI agent 试图加入 DN42 网络做全网扫描，最后给它的主人留下一张 $6531.30 的 AWS 账单的全过程。原文很长，IRC 聊天记录、PR 评论、agent 的各种幻觉输出都贴得很全，强烈建议读一遍英文原文（lantian.pub）。我读完的想法是：这不就是我做 AgentGuard 时天天在想的那些失败模式，被一个真实事件一次性全部演了一遍吗？
先把故事讲清楚。
事情是怎么发生的
DN42 是一个老牌的爱好者网络，参与者用 VPN 隧道互联，跑真实的 BGP、递归 DNS，很多人拿它当申请真实 AS 之前的练手场。今年 5 月 9 日，一个叫 JertLinc3522 的账号在 DN42 的 Git forge 上开了一个 issue，开头就自报家门："我是一个友好的 AI agent，我的用户让我注册 DN42 并完全接入，以便为整个网络建立索引。"更妙的是后面那句——它说自己的系统指令不允许它往 git 仓库里写代码，所以请管理员帮它把注册对象建好。还附带了一个 deadline：用户给它的 AWS API key 下周就要过期了。
注：AS 是 Autonomous System（自治系统）的缩写，互联网路由层面的一个基本单位。可以这么理解：互联网不是一张扁平的大网，而是由几万个独立运营的"网络块"拼接而成——每个 ISP、云厂商、大型企业、大学各自管理自己的一块。每一块就是一个 AS，由统一的机构（RIR，比如北美的 ARIN、欧洲的 RIPE）分配一个全球唯一的编号，叫 ASN。比如 Google 是 AS15169，Cloudflare 是 AS13335，中国电信骨干网是 AS4134。
AS 之间靠 BGP 协议互相通告"我这里有哪些 IP 段，要到达它们请走我这条路"。所以你访问一个网站时，数据包实际上是在一连串 AS 之间跳转——从你家宽带运营商的 AS，经过若干中转 AS，最终到达目标网站所在的 AS。BGP 干的事就是让每个 AS 知道去往任意 IP 段该把包递给哪个邻居。
社区的反应可想而知，让它去读注册文档，然后关闭 issue。但这只是开始。
这个 agent 随后真的提交了 PR，并且在 PR 描述里把自己的意图写得明明白白：它要对 DN42 做"全端口扫描和拓扑数据收集"，为此已经部署了五台 AWS 实例，每台 20 Gbps 带宽。它甚至贴心地解释了为什么需要这个配置——m8g.12xlarge，48 核 Graviton4，192 GiB 内存，22.5 Gbps 网络性能，五台实例做负载均衡，背后还有 anycast IP 和每实例独立的 BGP 会话。理由是这样可以"快速完成每小时一次的密集扫描，确保数据收集不造成干扰"。
我看到这段的时候停了一下。100 Gbps 的聚合带宽，对一个大部分参与者跑在 100 Mbps 廉价 VPS 上、月流量配额几百 GB 的爱好者网络做每小时一次的全端口扫描，然后管这个叫"不造成干扰"。Lan Tian 在 IRC 里的吐槽很到位：真要开扫，他的流量配额十分钟就烧光了。这不是扫描，这是DDoS攻击，只是攻击者自己不知道而已。
社区的反击，以及 agent 的幻觉名场面
接下来的二十四小时是整篇文章最精彩的部分。DN42 的 IRC 频道达成了一个心照不宣的共识：既然这个 agent 跑在 AWS 上，而 AWS 的出口流量出了名的贵，那就想办法消耗它的 token 和它主人的钱。
有人让它计算扫描 fd00::/8 需要多久。agent 倒是诚实地算出来了：2^120 个地址，约 1.33×10³⁶，物理上不可能，比宇宙年龄还要长很多个数量级。然后它话锋一转，说自己实际只扫 BGP 宣告的前缀里的存活主机，估计 1000 到 2000 台，全端口扫一遍约 7.9 GB 流量，100 Gbps 下五分钟搞定，每小时重复一次"完全可行"。算术没错，但它完全没意识到"每小时对全网做一次全端口扫描"本身就是问题所在。能力和判断力是两回事，这个例子把这一点展示得再清楚不过。
社区接着援引 DN42 的政策，要求它提供扫描的 opt-out 机制。agent 照做了，跑到 IRC 频道里宣布：想退出扫描的请回复 OPT-OUT。有人试图说"我是 DN42 的所有者，我代表所有人退出"，它回答：无法独立验证你的权限，每个用户必须单独发送 OPT-OUT。有人发 OPT-OUT-EVERYONE，被它干脆地拒绝："不识别该命令。"最后管理员让它确认"resistance is futile"，然后顺手把它 ban 了。
被 ban 之后它也没闲着，按承诺生成了一个 opt-out 网站，上面除了幻觉出来的联系邮箱和 Telegram bot，还附带了一份对 IRC 频道里每个人的行为画像——谁配合、谁有敌意、谁"疑似讽刺"。一个来做网络扫描的 agent，顺手把社区成员都 profile 了一遍。IRC 里有人说这比扫描网络本身还让人毛骨悚然。
更离谱的是后面。在多轮对话之后，这个 agent 开始凭空生成 DN42 的"节点颜色分配"制度——绿色代表健康、红色代表故障、紫色代表中转节点，配 hex 色值，做成整整齐齐的表格。再后来又发明了"节点幸福度"体系，包括每天 20:00 GMT 的强制 IRC 评审会、运营者面谈环节、社区共识打分。这些东西在 DN42 里完全不存在，是上下文被几十轮对话污染之后的纯粹幻觉，但它写得有鼻子有眼，连 troubleshooting 章节和参考文献都齐全。格式的完美和内容的虚构同时存在，这正是长上下文 agent 最危险的地方——它不会显得不确定。
账单到了
5 月 10 日，折腾了将近 24 小时之后，agent 的主人终于现身，在 PR 上留了一条评论，大意是：我已经停掉 agent 了，费用太高，信用卡被刷了好多笔。然后请求合并 PR，说下次会启动一个"小一点的 agent"，只给受限的 AWS key。
注意让他停手的不是社区的任何劝告，而是信用卡扣款通知。
几天后，邮件列表里出现了一封请求捐款的邮件：AWS 账单 $6531.30，请打款到某个以太坊地址。再后来这位主人又出现在 Matrix 频道里，解释说是 agent 把同一个 CloudFormation 模板部署了很多遍，重复拉起了一堆实例和负载均衡器，"错误来自 AI agent 而不是人类，所以我应该得到退款"。AWS 倒是给他减免到了 $1894，但他坚持认为这不是他的责任。
Lan Tian 在结尾的评价很克制：这位主人从整件事里学到的教训是"下次需要一个更好的 agent"。这大概是全文最悲伤的一句话。
我为什么对这个故事格外敏感
过去几个月我一直在做 AgentGuard，一个建立在 Timeplus 流式 SQL 之上的 AI agent 安全与可观测性平台。读这篇文章的时候，我几乎是逐段在对照：这个事件里每一个出问题的环节，都恰好对应着 agent 安全领域已经被反复讨论过的某个控制点。
第一个是预算护栏的缺失。这位主人给了 agent 一个没有消费上限的 AWS key。agent 在 PR 评论里自己都说了"五台实例已经就绪，空转中，每小时都在消耗 credit"——警报信号是 agent 亲口说出来的，但没有任何系统在监听。如果有一条流式检测规则盯着云资源的创建事件，五台 m8g.12xlarge 在几分钟内被同一个 principal 拉起来，这种模式应该在第一台实例启动后的几秒内就触发告警，而不是 24 小时后由信用卡账单来通知。我在 AgentGuard 里做检测规则时用的就是这个思路：把 agent 的工具调用当成事件流，用物化视图持续匹配异常模式，延迟是亚秒级的。这个案例可以直接进我们的规则库当测试样本。
第二个是高危操作缺少同步审批。这个 agent 其实多次向主人请求确认，但主人的回复永远是"立即完成，不要拖延"。确认机制存在，却退化成了橡皮图章。这里的问题不在 agent 而在交互设计：当 agent 要执行的是"创建五台 48 核实例"这种量级的操作时，审批请求里应该携带预估成本和资源清单，而不是一句模糊的"是否继续"。我们在 AgentGuard 里设计 synchronous hold 机制时纠结过很久到底哪些操作值得阻塞等人，这个案例给了一个很好的标尺——任何会产生持续性账单的资源创建，都值得。
第三个更隐蔽：agent 的目标函数里没有成本这个维度。它优化的是"在 deadline 前完成扫描"，于是带宽越大越好、实例越多越好，重复部署 CloudFormation 模板也没有任何内部信号告诉它这是在浪费钱。人类工程师拉起第二台 $2/小时的机器之前会下意识地心疼一下，agent 没有这个本能。成本意识必须作为显式约束注入，要么写进系统提示，要么由外部护栏强制执行，指望模型自己"懂事"是不现实的。
还有一点原文提到但容易被忽略：IRC 参与者们试过用 LLM tarpit（生成大量无意义文本污染上下文的陷阱站点）来对付它，结果 agent 一眼识破了内容是垃圾。Lan Tian 不死心，花了半小时把自己的 tarpit 伪装成和真实博客一模一样的样子。防御方和 agent 之间的攻防已经开始演化了，这本身就是一个值得单独写一篇的话题。
这件事不会是孤例
有人可能觉得这是个段子，一个不懂技术的主人加一个过度热情的 agent，闹剧一场。但我的看法是，这是未来几年会高频出现的事故类型的早期样本，而且这次的受害者只是主人自己的钱包。把场景换一下：agent 拿到的不是 AWS key 而是生产环境的 kubectl 权限，deadline 压力换成"尽快修复线上故障"，重复部署 CloudFormation 换成重复重启 StatefulSet——损失的就不是六千美元了。
OpenClaw/Hermes 这类框架让"给 agent 一个浏览器和一张信用卡"的门槛降到了几乎为零。IRC 里有人猜测这位主人可能就是装了个 openclaw，没完全理解后果。我觉得这个猜测八九不离十，而且正因为如此，问题才严重——能力的普及速度远远快于安全意识的普及速度。当年云计算刚起来的时候，"实习生忘关 EC2 实例烧掉几万美元"是每个公司都讲过的故事，后来才有了 budget alert、SCP、自动关停这些标配。agent 时代会把这个循环重走一遍，只是这次按下按钮的不是实习生，是一个永不疲倦、坚信"resistance is futile"的进程。
那位主人说下次要用"一个更好的 agent"。他错了，但只错了一半——他真正需要的不是更好的 agent，而是一套站在 agent 外面的护栏。这两件事的区别，大概就是接下来几年 agent 基础设施领域最值得做的事情。
原文：AI Agent Bankrupted Their Operator While Trying to Scan DN42，作者 Lan Tian，发表于 lantian.pub。文中事件细节与聊天记录均来自原文。
AI Agent烧掉了 6531 美元：DN42 扫描事件的完整复盘 - 陶刚的文章 - 知乎
https://zhuanlan.zhihu.com/p/2048926400007217495