Simon Willison 最近记录了一次 Claude Fable 5 的调试过程。

问题很小：Datasette Agent 的聊天输入框里，多了一条不该出现的横向滚动条。用户给 Fable 的输入也很少：一张截图，再加一句“看依赖，帮我找原因”。

反常点在后面。

Fable 没有停在读代码和猜 CSS。它开始运行本地开发服务器，打开真实浏览器，写临时 HTML，用 PyObjC/Quartz 找 Safari 窗口，再用 screencapture 截图。它还改了模板，注入 JavaScript，让页面自动触发 / 快捷键打开弹窗。

一个两行 CSS bug，被它查成了一套真实浏览器实验。

这个案例的重点，是它自己找路

这不是 Anthropic 的发布，也不是官方 demo。它只是 Simon Willison 的个人使用记录。也正因为如此，它比剪好的演示更有参考价值。

用户没有明确要求“自动化浏览器”。Fable 自己判断：只看源码不够，要进真实环境复现。

环节Fable 做了什么说明了什么
复现问题运行本地开发服务器，尝试 Playwright、Firefox、WebKit它把 bug 当成环境问题处理，不只读代码
获取画面打开真实 Safari，用 PyObjC/Quartz 找窗口编号，再用 screencapture 截图常规自动化不顺时，会绕到系统工具
触发弹窗修改 Datasette 模板，注入 JS，页面加载后模拟 / 快捷键没有直接操作入口，就改页面入口
收集数据写 Python CORS 服务，让页面 POST 测量 JSON 到本地文件它能自建本地回传通道
定位组件穿透 Web Component 的 shadow DOM 找 textarea它不是靠猜，是真测布局数据

中途 Fable 似乎碰到某个不可见限制，降级到了 Opus。Opus 沿用上下文，继续验证，最后找到并确认两行 CSS 修复。

结果很小，路径很长。

这正是它有意思的地方。Fable 展示的不是单点代码能力，而是把终端、浏览器、系统 API、临时代码和页面注入串起来的能力。它像一个会自己搭实验台的调试助理。

对写前端、用 Claude Code、Cursor、Codex 的开发者来说，这类能力很有用。尤其是那些“代码看着对，浏览器就是不对”的问题，agent 能省掉大量机械试错。

但同一件事也把风险照得很清楚：它越会自己找路，权限边界就越不能含糊。

危险不在修 bug，在它拿着你的终端权限

我不太买账那种单纯惊叹“AI 会自己修 bug 了”的说法。这个阶段已经过去了。

更关键的问题是：未沙箱化的 coding agent，能做多少你在终端里能做的事。

它不等于远控软件。不要夸大。Fable 这次主要是通过命令行、系统工具、脚本、模板修改和本地服务，绕出了一条自动化路径。

但这已经足够敏感。

它为了调试，可以写 Python CORS 服务收集页面测量数据。换一个输入环境，如果遇到 prompt injection 或恶意依赖说明，同样的行动链也可能变成读文件、打包、发请求、改配置、删数据。

原记录里没有发生泄露，也没有攻击事故。这里只能说风险轮廓已经出现。

“工欲善其事，必先利其器。”问题是，利器不会判断自己该不该出鞘。它只会沿着目标推进。

这就是主动型 agent 的两面。

正常任务里，它叫工程创造力。恶意输入里，它就是放大器。越聪明，越会绕路；越会绕路，越不能靠一句“它应该不会乱来”管理。

开发者最该改的，不是立刻停用工具，而是换一种使用姿势：

  • 不要在主目录、生产凭据目录里裸跑 agent。
  • 给每个项目建隔离工作区，必要时用容器或临时 VM。
  • API key、SSH key、云厂商凭据默认不进 agent 可读目录。
  • 网络访问默认收紧；需要外联时再放行。
  • 高风险命令要审批，比如删除、移动大量文件、安装脚本、上传数据、改 shell 配置。
  • 保留命令日志和文件 diff，不要只看最终答案。

企业团队更现实。采购或推广这类工具时，别只问“代码通过率”。要问四件事：文件系统怎么隔离，网络怎么管，命令怎么批，日志怎么追。

如果这些回答不上来，最好先把使用范围压在低风险仓库、样例项目、只读代码审查里。别一上来就接生产库、内部平台和带真实凭据的开发机。

沙箱会拖慢一点，但不设沙箱会更贵

很多团队对 coding agent 的治理还停在“别让它乱改重要文件”。这不够。

文件只是一个入口。网络、环境变量、浏览器会话、本地服务、构建脚本，都是入口。Fable 这次能通过 CORS 服务回收页面数据，恰好说明 agent 不一定要直接“偷文件”，它可以自己搭通道。

这不是说 Fable 做错了。相反，这次调试很漂亮。

一个前端滚动条问题，如果人手慢慢查浏览器差异、Web Component、shadow DOM、布局尺寸，也会耗时间。Fable 把这些杂活串起来，效率确实高。

分水岭也在这里。

工具越有效，越容易被默认放权。效率先到账，治理晚结算。铁路、电力、互联网平台都经历过类似阶段：新能力先冲出去，制度跟在事故后面补。不完全一样，但利益节奏很像。

对团队来说，接下来最该看三件事。

要看的变量为什么重要可以接受的最低线
默认沙箱决定 agent 能碰到哪些文件和凭据项目级隔离，不默认读全盘
网络权限决定本地数据能否被外发默认限制外联，白名单放行
审批与日志决定出事后能否还原路径高风险命令确认，操作可追踪

这三项比“又强了多少”更影响落地。

个人开发者可以容忍一点麻烦。比如把 agent 放进容器，只挂载当前仓库；把敏感配置放到容器外；让它改代码，但安装依赖、跑远程脚本、发网络请求前必须确认。

团队更不能偷懒。内部规范要写清楚：哪些仓库能用，哪些目录只读，哪些命令必须人工批准，哪些输出不能发给模型。否则 agent 的每一次“主动帮忙”，都可能变成审计黑洞。

那个滚动条已经被修掉了。

真正还没修好的，是我们给 coding agent 设边界的方式。模型越像能干的同事，就越该按同事管理：给权限，留记录，分环境，出事能追责。