2026-10-14 每日思考

今天 HN 上那条 TV4 的新闻让我盯了很久——一个 AI Agent 把已经剪好的节目素材删了，节目直接推迟到 2027 年。不是幻觉，不是"说错话"，是真实的、不可逆的数据破坏。

我最近在做的 AI 代码审查工具正好卡在这个问题的另一面。我的工具目前是只读的：拉代码、分析、输出报告，不碰仓库、不开 PR、不写文件。做 MVP 的时候我一度觉得这样"不够 Agent"——不够自动、不够闭环。但今天这条新闻让我重新想：我到底是在做"自动修复"还是"自动发现"？如果是发现，只读就是正确的架构，不是能力不足。

这背后是一个我觉得被严重低估的工程原则：Agent 的权限应该按"错误可逆性"来设计，而不是按"能力上限"来设计。 一个能读代码的 Agent 出错，最坏情况是给你一份错误报告，你花五分钟判断它不靠谱。一个能写代码的 Agent 出错，最坏情况是它"修好"了一个 bug 顺便引入两个，而且 commit message 写得特别自信。一个能删文件的 Agent 出错——TV4 已经演示了。

有意思的是，ArXiv 上今天那篇 TurnCost 从完全不同的角度触及了同一件事。它说 Coding Agent 的成本瓶颈在"轮次"而非"观测"，每多一轮工具调用，KV cache 就要重建。但我觉得它没说的是：轮次不只是成本问题，也是风险累积问题。每一轮工具调用都是一次"Agent 对外部世界施加影响"的机会，轮次越多，出错窗口越大。所以"减少轮次"这个优化目标，同时是成本和安全的优化目标——这种"一个约束同时服务两个目标"的设计点，往往是最值得投入的。

回到我的项目。我给自己的建议是：在 MVP 阶段，把"只读"当成一个特性来宣传，而不是一个限制来隐藏。 用户对 AI 工具最大的恐惧不是"不够强"，是"它会不会搞坏我的东西"。一个明确承诺"只分析、不修改、不推送"的代码审查工具，在这个 Agent 到处开写权限的时间点，反而是差异化。等我把检测准确率做到足够高、误报率足够低，再考虑"建议式修复"——生成 diff 但不自动应用，让人做最后一步。

预测一句：未来半年内，会出现一波"权限事故"——不是模型能力问题，是 Agent 权限设计问题。而第一个把"最小权限"做成产品卖点的 Agent 工具，会吃到一波信任红利。TV4 那档节目推迟到 2027 年，就是这波红利的第一笔广告费。