技术 · 熟练
装完 agent 框架，先关掉三扇门
出事的往往不是模型，是你为了调试把它跑起来的那一面
绝大多数 agent 框架出事，都不是模型被骗了，而是有人够到了那个「能执行东西的界面」——一个 Web 控制台、一个 Playground、一个本地编辑器。它们为调试方便而生，默认往往对全网开着，权限模型又比主服务弱。这一页给的是装完框架后的三道处置：先把「跑起来看的」与「对外开的」分开，逐个确认监听地址；再按四条已公开的洞型逐个对版本；最后给会跑命令的 agent 定五样沙箱策略。顺序不能反：先收暴露面，再升级版本，最后补测试。
方法 · 一图看懂
1
分清「跑起来看的」与「对外开的」 — 凡带 Web UI / Playground / 编辑器 / 本地 API 的组件，逐个记下它监听哪个地址：只有 `127.0.0.1` 才算没开门
2
四条已公开的洞型逐个对版本 — 编辑器改流程并执行 · 跨租户越权 · 本地 Web UI 触发任意工具 · 流式接口早断开不释放并发
3
升级之后写一条能抓住它的测试 — 用真实请求打一次（不是比对版本号），把失败写进回归
4
给会跑命令的 agent 定五样沙箱策略 — 文件系统 · 网络 · Git 凭据 · 命令行凭据 · 本地 MCP，先定默认值再放它跑
5
留一张「谁在哪个端口上」的清单 — 写进你自己的 agent 手册，下一个接手的人才知道哪里是门
原理 · 为什么有效
为什么有效 —— 第一层机理是暴露面与权限模型错位：主服务通常要正经鉴权，而控制台、Playground、编辑器为了「开发方便」常常只做弱校验，甚至允许任意已登录用户编辑并执行流程；一次 RCE 的入口因此不在业务接口上，而在调试界面上。第二层是本地不等于关闭：本地 Web UI 常以开发者权限运行，它自己就能调用工具（读写文件、发请求），所以「我这个跑在自己机器上」并不构成边界 —— 它构成的是「本机上任何进程、以及任何能访问这个端口的人，都能用」。第三层是版本落后是静默的：CVE 公告不给你发通知，安装命令也不提醒你；同一份依赖文件今天装的和下个月装的可能差三个安全版本。⇒ 所以处置顺序是「收面 → 升级 → 证伪」：先让够不到，再让洞不存在，最后用一条真请求证明前两步真的生效。反过来先升级，等于窗还开着换了一把锁。
适用场景
适用：自建或本地跑 agent 框架的人；把 Playground / 控制台跑在云主机或内网服务器上的人；给团队发过「一键起个 agent」文档的人；做多租户 agent 应用（别人的数据在你的流程里跑）的人。
⛔ 不适用：只用网页版聊天、没在自己环境里跑过任何框架的人；只调用云端 API、从不启动本地服务的轻量用法。
⚠️ 一条边界：本条不谈「模型会不会被骗」 —— 提示词注入是另一个问题，处置手段也不同；把两件事混在一张清单里，会既漏收暴露面、又用错预算。
自测 · 5 问
我说得出自己这台机器上现在有哪些 agent 组件在监听端口，各自绑在哪个地址
我的控制台 / Playground 是只有本机能连，还是同网段甚至公网都能连
控制台的「编辑并运行」权限，是只有管理员有，还是任意已登录用户都有
我装的框架版本，和最近一次安全公告里的修复版本对得上吗
如果给我一项「你必须证明这个洞堵上了」的任务，我拿得出哪条请求
怎么上手 · 验证步骤
按这个顺序做，一次只动一层：
第一步收面 —— 把框架自带控制台 / Playground 的监听地址改回 `127.0.0.1`，或直接停掉；确需远程访问就放到带鉴权的反向代理之后，⛔ 不要「先开着回头再说」。
第二步列清单 —— 在项目目录里列出所有会起服务的组件（主服务、控制台、向量库、调试代理），每条写三样：端口 · 绑定地址 · 谁能访问。
第三步对版本 —— 拿框架名加「CVE」与「security advisory」两种说法各查一次官方仓库的安全页，把「当前版本 / 修复版本 / 是否受影响」逐条写进同一张表。
第四步补测试 —— 针对你受影响的那一条写一个最小复现：一个请求、一个预期拒绝；修好后它必须从「成功」变成「被拒」，然后挂进回归。
第五步定策略 —— 给会跑命令的 agent 先写默认值：能读哪些目录、能不能出网、用哪个 Git 身份、能不能调用本地 MCP，写成一份文件而不是口头约定。
做完自己核对三件：① 我能一句话说出每一个 agent 组件的端口、绑定地址、访问者 ② 受影响的那条 CVE 有对应的最小复现测试，且它在修复前会失败、修复后通过 ③ 沙箱策略是文件里写好的默认值，而不是「记得别乱跑」。三条缺一条，这套就还是「靠运气」。