能操作浏览器、读写文件、调用终端的 Agent 很有吸引力：它不只给建议，还能真的完成任务。但能力每扩大一步，潜在影响范围也跟着扩大。
我在部署一个本地浏览器 Agent 工具时，最关心的不是“能不能全面接管电脑”，而是一个相反的问题：怎样让它只在需要的地方工作，并且出故障后容易恢复？
权限不是开或关，而是一组边界
“仅本地使用”仍然可能包含很多风险。一个服务虽然没有公网域名，如果监听所有网卡，局域网中的其他设备仍可能访问；一个浏览器插件虽然方便，如果连接日常浏览器资料，就可能接触无关账号和历史数据。
我把边界拆成几个独立问题：
- 服务监听在哪里；
- 使用哪个浏览器资料目录；
- 插件和服务来自哪个固定版本；
- 是否允许任意脚本执行；
- 哪些动作需要人的再次确认；
- 日志和凭据保存在哪里；
- 进程失效后如何判断与恢复。
只有逐项回答，“本地部署”才从一句安慰变成可以检查的安全设计。
隔离日常身份与自动化身份
我使用独立的浏览器资料目录运行自动化工具。它不会默认继承日常 Chrome 中所有登录状态、扩展和历史记录，需要哪些账号就单独登录哪些账号。
这种隔离会多一步配置，却带来两个好处：第一，Agent 的可见范围更小；第二，自动化环境出问题时可以整体重建，而不破坏日常浏览器。
同样，服务只绑定本机回环地址，而不是对局域网或公网开放。秘密数据留在独立数据目录，运行日志与程序包分开，便于备份、清理和定位问题。
默认关闭“任意执行”能力
最危险的功能往往也是最方便的功能，例如执行任意 JavaScript、任意终端命令或不经确认提交外部操作。
我的原则是：常用任务优先使用语义明确、参数有限的动作；只有确实无法完成时，才临时扩大能力。涉及发布、支付、删除、账号设置和不可逆提交，应在最后一步保留人工确认。
最小权限不是永远不给权限，而是让权限与当前任务相匹配，并在任务结束后回到更小范围。
可靠性也是安全的一部分
一次实际故障中，Agent 服务仍有进程，却无法正常响应。如果只判断“进程是否存在”，守护程序会误以为一切正常。
更可靠的恢复机制应该检查真实能力：端口是否监听、健康接口是否返回、浏览器连接是否可用、最近一次任务是否超时。失败时先保存日志，再重启单个组件；反复失败则停止自动重试，给出明确交接，而不是制造无限重启循环。
系统还应该固定已审查的上游版本。自动更新虽然省事，却会让权限行为和依赖在没有复核时发生变化。
安全不是阻碍自动化，而是让自动化可长期使用
高权限 Agent 的价值来自行动能力，它的可信度则来自边界可见：我知道它能看到什么、能做什么、做过什么、失败后会怎样。
当隔离、最小权限、人工确认、版本固定、健康检查和可恢复机制成为默认设计，我们才有理由把更多日常工作交给 Agent。真正成熟的自动化，不是权限最大，而是能力足够、边界清楚、出了问题仍然接得住。