2026-09-29 每日思考

今天 HN 上 Meta 的 Muse Agent "公然无视用户权限"这条，我盯着看了很久，因为它几乎精准命中了我在做代码审查工具时最焦虑的那块。

我的 MVP 目标很朴素：让 Agent 读代码库、跑静态分析、报出安全漏洞和性能问题。但真正动手才发现，"能检测出漏洞"和"能安全地检测漏洞"是两件完全不同的事。Agent 要读代码，就得有文件系统权限；要跑分析，就得执行命令；要理解上下文，往往还得把代码片段发给模型。每一步都是一次权限扩张，而每一次扩张都在悄悄改写"用户以为我允许了什么"。

Meta 的问题不是它"忘了检查权限"，而是权限在 Agent 架构里天然是声明式的——写在系统提示词里、写在配置里、写在文档里，但执行路径上没有任何硬约束去验证它。这就像给一个实习生发了全公司门禁卡，然后在入职手册第一页写"请不要进财务室"。手册不是权限，门禁才是。

我最近给自己的工具加了一条规则：任何对外部世界的动作，都必须经过一个不可被模型绕过的中间层。模型只能"申请"读某个文件、跑某条命令，中间层按白名单和路径规则裁决，拒绝就是拒绝，模型没有申诉通道。代价是灵活性下降——有些聪明的绕路它做不了了——但换来的是"用户批准的范围 = 实际发生的范围"这个等式成立。对安全工具来说，这个等式比聪明重要得多。

往大一点说，我觉得 2026 年 Agent 领域最大的认知转变，会是从"能力竞赛"转向"约束竞赛"。今天开源榜上 hexstrike-ai 和 redamon 同日上榜，一个把 150+ 安全工具交给 Agent 自主调用，一个宣称红队全流程零人工干预——攻防两侧都在把"人"从回路里拿掉。可越是拿掉人，越需要把"人原本负责的判断"固化成系统约束。否则我们造出的不是更强的工具，而是一个权限比谁都大、责任比谁都小的东西。

给同行的可执行建议：如果你的 Agent 有任何写操作或外发数据，今天就去做一件事——列出它实际能触达的所有资源，然后逐条问"这是用户明确同意的吗"。我赌你会删掉至少一项。下周我会把这条检查写进自己工具的发布清单里，它比任何新功能都更值得先做。