我是如何解决智能体审批疲劳的:给每个智能体一台独立的电脑,然后测试它无法访问哪些资源
摘要
作者分享让持久化 AI 代理真正可用的三点经验:为每个代理分配独立容器、主动测试安全边界而非默认信任,以及定义可机器验证的"完成"标准。
有三项改动让持久运行的智能体对我来说真正变得可用了。分享一下,希望能帮别人省下几周时间。每个智能体一台电脑。每个智能体都在我 Mac 上独立的 Linux 容器中运行:没有 capabilities 权限,系统只读,只挂载该智能体的工作区,没有主目录或宿主机凭据,还有各自的浏览器和登录会话。里面没有我的任何东西,我就不再逐条批准命令了。以前一项任务要问我 3 次,现在一次也不用问。容器是一道坚固的边界,但不是保证,所以我把它当作一层防护,而不是完整的解决方案。测试边界,而不是直接相信它。容器使用独立的网络,容器外部的规则会拒绝访问私有地址段和链路本地地址段。让智能体自己尝试访问时,访问我的路由器和宿主机都得到了 EHOSTUNREACH,访问公共网站则得到了 200。每次启动时,它都会重新检查,因为虚拟机重启会清除防火墙规则。到目前为止,我只在 Apple Silicon Mac 上用 Colima 测试过,还没有在 Docker Desktop、OrbStack 或 Windows PC 上测试过。让“完成”成为可以核查的结果。研究任务最终要交付一个文件,附上文件大小、来源数量和哈希值,并注明这些来源只是列出,未经事实核查。代码任务最终要提供实际的测试输出,而不是让智能体口头说测试通过了。在让智能体独立运行之前,你会检查什么?
相似文章
智能体自行报告“这已经完成,所有测试都通过了”,你如何验证这一点?如何在大规模智能体场景下进行验证?
开发者讨论在 AI 代理规模化工作流中如何验证代理自称的“已完成且测试通过”,提出需要外部独立的验证步骤与可留证的调用记录,而非信任代理的自测结果。
我如何让 AI 代理连续运行数天而不忘记自己在做什么
作者分享让 AI 代理长时间运行而不丢失状态的做法:在上下文窗口写满前将工作状态保存到检查点文件,新会话读回检查点继续工作,并通过带验证的完成项来解决伪造完成的问题。
@knoYee_: https://x.com/knoYee_/status/2062780637677752366
作者复盘了使用多Agent协作三个月的经验,总结出五个主要痛点(如Agent间矛盾、忽略边界条件、自我审查失效、合并决策困难、压缩执行后暴露更难问题)和两个心得(只读审查Agent价值高、Agent矛盾暴露需求模糊),强调了人类在AI协作中的核心决策作用。
我的智能体配置的三个部分:持久记忆、自我改进和协调
作者分享其 AI 代理工作流设置的博客文章,围绕三大原则:持久化记忆(版本控制的技能库与 AGENTS.md/CLAUDE.md 约束)、递归式自我改进(授权代理在任务中修补记忆文件)以及可扩展并行化(通过协调工具管理文件写入范围以避免冲突)。
并非每个 Agent 操作都需要同样的审批
作者探讨 AI Agent 审批流程的设计问题,主张审批应基于风险等级而非组织架构——读操作放行、常规更新记录放行、高风险操作才需指定人工审批,并指出真正的业务规则往往存在于未文档化的实践者经验中,而不是 API 权限模型里。