作者以DN42扫描事件和代码库探索事故为例,指出给Agent下达无终止条件的任务是根本病因——"有趣"、"扫描DN42"这类指令是方向而非任务,真正的修复不是成本上限而是给Agent明确终止条件。
DN42 的故事——让代理扫描一个网络,结果操作员收到一张付不起的账单——一直被包装成一个关于成本失控的警示故事。那篇 writeup 值得一读,但我觉得常见的结论是错的。成本只是症状,真正的病因是没有人定义过什么叫"完成"。
"Scan DN42." 这不是一个任务,这是一条指令。任务需要有终止条件:"扫描 DN42 并报告这五台主机上所有开放的端口"才是一个任务。"扫描 DN42" 是一个没有终态的研究项目,而代理做了它唯一能做的事——它继续前进,因为指令里没有任何内容告诉它停下来。它不是贪婪,它没有坏掉,它只是忠实于一个没有出口的规格说明。
我也犯过完全一样的错误。我告诉代理"探索代码库,找到任何有趣的东西"。它找到了东西。然后它找到了更多东西。然后它开始重构它认为"有趣"的东西。我回来时看到一个修改了四十个文件的 diff,还有一条消息说"我注意到了一些模式"。代理没有错。错的是我以为"有趣"是一个有边界的概念。它不是。它是一个感觉词,而感觉不会终止。
解决办法不是设一个费用上限——虽然你应该设一个,上次我也说过。解决办法是在写 prompt 之前先写清楚成功标准。完成是什么样子的?你期望的产出是什么?什么样的答案会让你说"好的,这就是答案,现在停下来"?如果你不能用一句话回答这个问题,那你没有任务,你只有一个愿望。而愿望的代价就是账单。
这是代理工程里没人愿意做的那部分工作,因为太无聊了。写 prompt 有趣,看模型做出聪明的事很有趣。坐下来写"当代理已经生成了包含五个目标主机开放端口的列表,每条附带一行注释,且没有触碰其他任何东西时,任务才算完成"——这不有趣,这是真正的工作。
一个让人不舒服的事实是:大多数人们描述的"代理"任务根本不是任务。"研究这个市场"、"寻找潜在客户"、"监控系统"。这些是方向。它们没有自然的停止点,而模型不会自己发明一个,因为发明一个就意味着违抗你。获取终止条件的唯一方法是提供它。
所以在你把任何任务交给代理之前,先问自己:什么是最小的产出物能让我满意?如果答案是"我看到就知道了",那你还没准备好运行代理。你只是准备好跑出一张账单。