长期在线且会行动的 Agent，为什么不能把安全当附录

普通聊天 agent 的错误常常止于当前会话，但长期在线系统的错误可能持续累积。

一旦 agent 可以调用工具、浏览器和自动化任务，风险就从“说错”变成“做错”。

CLI、消息、浏览器和自动化入口一起存在时，真正的风险来自边界是否统一。

一个能持续推进任务的系统，必须同时设计好暂停、审查、接手和回滚路径。

先在最小权限和最小入口下运行 Hermes，再逐步增加入口、浏览器和自动化能力。

只有当日志、回报和人类接手路径都清楚时，长期运行才值得打开。

浏览器、外部写入和自动触发这类能力，不该作为默认起手式。

不要一开始就同时开放消息、浏览器和自动化任务；先让最小入口稳定，再逐步放开。

如果没有清晰的日志、结果回报和接管路径，所谓长期自治只会增加排障和风险成本。

任何外部写入、浏览器操作和自动触发都应该晚于基础运行验证，而不是反过来。

对于长期在线的 agent，安全不该是最后一页文档，而应是运行方式的一部分。

某团队希望 Hermes 能最终处理文件写入操作，但不想一步到位开放所有权限。

Hermes 同时接入 Slack 和自动化任务，两类入口的安全要求不同。

长期在线的 agent 不像一次性脚本，出错的持续时间和影响面都会放大。安全应该在第一天就纳入设计。

不同的入口有不同的风险等级。共用身份意味着最高权限被所有入口共享，任何一个入口的泄露都会威胁全部。

某些高风险操作（如文件删除、数据写入、命令执行）应该设置人工复核节点，而不是完全交给 agent 自动决定。

安全配置不是一劳永逸的。随着入口增加、能力扩展和任务变化，安全边界也应该定期重新评估。