同样一套 Agent，在 Demo 环境里像个勤快的实习生，一旦接到生产，就可能瞬间变成“有手有脚、还拿着万能钥匙的人”。更反直觉的是：最容易出事的那一步，不是模型答错一句话，而是它顺手多连了一个服务、多拿了一个字段、多写了一次不该写的接口。很多团队真正卡住的，也不是技术做不到，而是到了“接内网/接生产”的议程，会议室突然就安静了。
2026 年 5 月 19 日之前，很多团队做 Agent（能自动跑工具的那种）都会卡在同一个瞬间：Demo 跑通了，下一步是“接内网/接生产”，然后大家开始互相看对方的表情。
我自己也见过那种尴尬：前一天还在为“它能自动跑工单、生成日报”兴奋，第二天安全同事问一句“你打算给它什么网络权限、用什么凭证、怎么审计”，现场就只剩键盘声。话说回来，这个问题不是谁谨慎不谨慎的问题，是你一旦接上真实系统，你是在把“能执行指令的东西”放进公司网络里。这跟在聊天框里问问题完全不是一个级别的风险。
今天聊 Claude Managed Agents 这次更新的两个关键点：自托管沙箱（self-hosted sandboxes）和 MCP tunnels。官方公告在这：https://claude.com/blog/claude-managed-agents-updates
“能跑起来”为什么不等于“敢上线”？
直接回答：因为 Agent 的真实风险不在“回答错”，而在它会带着你的网络、凭证和工具权限去做事；一旦越界，排查和追责会非常痛苦。
你可能见过这几类翻车前兆（不少团队都经历过，只是没写进复盘）：
- 网络出界：本来只想让它访问工单系统，结果它能扫到更多内网服务
- 凭证暴露：把长效 API Key 塞进环境变量或日志里，后面谁拿到都能用
- 工具滥用：某个“查询接口”其实也能触发写操作，只是参数不同
- 数据外泄：它把内部数据复制进对话、摘要、或外发邮件里（尤其是“为了让回答更完整”这种正当理由）
这里最反直觉的是：你以为你在评估“模型靠谱不靠谱”，其实你需要评估的是——这套系统有没有把 Agent 当成“随时可能犯错的实习生”，并且提前把门禁装好。
有一次我帮老大整理一份“工具调用日志”做复盘，本来以为就是常规排查。结果越看越像在看一个人“试门锁”：不是一次大爆炸，而是很多次“看起来没什么”的小越权。比如多请求了一个不该看的字段、多打了一次不该打的内部 endpoint。单次都能解释，累计起来就很难看——因为你很难在事后证明：它当时到底有没有看到不该看的东西。
我也不敢说所有团队都能把边界一次画对。尤其是当你工具越来越多、内网服务越来越杂时，“最小权限”这四个字听起来简单，落地时细节会不断冒出来咬你。
自托管沙箱 + MCP tunnel：它们分别把哪道门装上了？
你可以把 Agent 接入真实系统这件事，想成“给新同事发工位”：
- 自托管沙箱：是你让他在公司自己的隔间里干活（隔离执行环境、限制能看到什么文件/网络）
- MCP tunnel：是你给他开一条只通到指定工位的走廊（穿过防火墙把 MCP 服务连出来，但仍然可控）
这里 MCP 需要解释一句：MCP（让 AI 工具互相连接的协议），你可以把它当成“Agent 调工具的标准插口”。有了 MCP，工具不一定非得写死在一个平台里。
下面这张表是我自己梳理的“你到底买到了什么控制力”：
| 组件 | 解决的核心问题 | 你获得的控制点 | 最适合的任务 |
|---|---|---|---|
| 自托管沙箱 | “Agent 在哪跑？能碰到什么？” | 进程/文件/网络隔离、资源限制、可替换执行镜像 | 跑脚本、抓取数据、生成报表、离线处理 |
| MCP tunnel | “怎么让 Agent 够得着内网工具，但又不全网畅通？” | 只暴露指定 MCP 服务、缩小网络面、便于审计入口 | 调内部 API、查库（只读）、访问工单/CRM/知识库 |
你该用哪种组合？先对照 4 个典型场景
下面这段是给“要做试点，但不知道从哪开始”的。
| 场景 | 你真正想要的能力 | 推荐组合 | 为什么这样更稳 |
|---|---|---|---|
| 只读查库/读数仓（分析、对账、日报） | 最小权限读取 + 可追溯 | 沙箱 + MCP tunnel | 计算在沙箱里跑，数据入口走 tunnel，范围清晰 |
| 跑内部脚本（清洗、对齐、生成文件） | 稳定执行 + 不污染宿主机 | 自托管沙箱 | 把“执行”封进隔离环境，出事一键销毁 |
| 调内部 API（工单流转、库存查询） | 访问内网服务但别全开 | MCP tunnel（配最小权限工具） | 通道只通到 MCP 服务，避免把整个内网摊给它 |
| 访问工单/CRM（带少量写操作） | 受控写入 + 审计回放 | 沙箱 + MCP tunnel + 强审计 | 写操作需要更严格的“谁批准、写了啥、能撤回吗” |
到这里你会发现：这波更新的价值不在“又多了个新功能”，而在它终于把一件尴尬事讲明白了——Agent 要进公司内网，必须同时解决“在哪执行”和“怎么连进去”。
到底怎样才算“敢让 Agent 连内网”？
我更喜欢用一个“能不能睡得着觉”的标准：你不需要保证 Agent 永远不犯错，你需要保证它犯错时不会把公司一起带走。
当你能同时做到四件事，才算真的敢让 Agent 连内网：
第一，Agent 的执行必须在隔离环境里（自托管沙箱），出了问题能销毁且不会污染宿主机；
第二，网络只允许访问明确列出的内部服务（通过 MCP tunnel 或白名单），默认全部拒绝；
第三，所有凭证必须是临时的、可撤销的，且权限只覆盖这一次任务需要的最小集合；
第四，必须有可回放的审计记录，能回答“它何时调用了哪个工具、带了哪些参数、返回了什么、写入了什么”。
**满足这四条，试点才会从“赌运气”变成“可控试错”。**做不到也没关系，至少你能知道短板在哪，而不是靠“提示词写谨慎一点”自我安慰。
一套可落地的接入清单：照着做一个低风险试点
我建议你把第一次试点当成“装修样板间”：别想着一步到位全屋智能，先把一间屋子的电路和水路跑通，而且每根线都贴标签。
第 0 步：先选“可失败”的业务切片
你要的不是最性感的场景，而是最容易验收、最不怕出错的场景。
推荐优先级：
- 只读任务（查数、拉取工单、生成周报）
- 低风险写入（写到草稿区/备注区/待审批区）
- 高风险写入（发券、退款、改库存、触达客户）先别碰
做对的反馈标准：业务同事能一句话验收，比如“今天的报表我不用手工拼了”。
第 1 步：权限按“工具”切，不按“Agent”切
很多团队第一步就错在：给 Agent 一个大权限，然后在提示词里说“你要谨慎”。
更稳的做法是把权限收敛到工具层：
- 每个 MCP 工具（比如
get_ticket,search_customer,create_note）单独授权 - 默认只给 read 工具；write 工具需要额外审批（哪怕是人工开关也行）
做对的反馈标准：你能列出“它到底能调用哪几个动作”，并且每个动作的输入输出范围可描述。
第 2 步：网络白名单默认拒绝，只开“该开的洞”
不管你用不用 MCP tunnel，这条都要做：网络策略从“允许访问一切”改成“只允许访问清单”。
建议清单长这样（只给形式，不给你编 IP）：
- 内部 API 网关域名（例如
api.internal.example.com） - MCP server 的固定地址/域名
- 必要的身份认证服务（例如内部 OAuth/STS）
做对的反馈标准：你能从日志里证明它只访问了允许列表内的目标。
第 3 步：凭证别给“长效的”，只给“临时的”
这条是为了防“Agent 没出事，但日志/缓存/人手误把 Key 扩散了”。
你要的策略是：
- 临时凭证（短 TTL、可撤销）
- 作用域最小（只读就别给写）
- 任务绑定（一次任务一个凭证，任务结束即失效）
做对的反馈标准：你能在后台一键吊销，并且吊销后它立刻失去访问能力。
第 4 步：审计要能回答“它做了什么”，而不是“它说了什么”
很多团队只保存对话文本，但真正需要的是“工具调用轨迹”。
你至少要记录：
- 调了哪个工具（tool name）
- 什么时候调的（timestamp）
- 带了哪些参数（request）
- 返回了什么（response，必要时脱敏）
- 是否发生写操作（write flag）
- 写到了哪里（target id / resource id）
做对的反馈标准：出了问题你能复盘“哪一步开始偏了”，而不是只看到一段漂亮的自然语言。
第 5 步：分环境策略——同一个 Agent，三套门禁
很多事故是因为“测试环境跑得好好的，一切照搬到生产”，然后生产数据规模/权限/接口差异把洞放大。
我建议你至少分三层：
- Dev：允许更多日志与调试，但接假的数据或最小数据集
- Staging：接近真实权限模型，但关键写操作仍然关
- Prod：只开放明确业务路径；写操作必须可回滚/可审批
做对的反馈标准：每次开新能力都能说清“在哪个环境开的、开了哪些门”。
可复制素材：一个“上线前门禁检查”Prompt
把下面这段丢给你团队里负责安全/架构的人（或者你自己），让 Agent 方案先过一遍门禁，再谈接生产：
text你是资深安全架构师。请审查我的 Agent 接入方案是否满足“最小权限 + 可审计 + 可撤销 + 网络最小暴露”。
输入包含：
1) Agent 要完成的任务（成功标准）
2) 需要调用的工具列表（读/写分别列出）
3) 需要访问的网络目标（域名/服务名）
4) 凭证发放方式（是否临时、TTL、撤销方式）
5) 审计方案（记录哪些字段、保留多久、如何回放）
6) 环境划分（Dev/Staging/Prod 的差异）
请输出：
A. 最大的 5 个风险点（按严重程度排序）
B. 每个风险的缓解措施（必须可操作、可落地）
C. 哪些能力必须先在只读试点通过后才能开放写操作
D. “可以上线试点”的最低条件清单
留个更现实的问题
沙箱和 tunnel 把“门”装上之后，真正难的往往变成另一件事：你准备把“写操作”开放到什么程度？是永远只读，还是允许写到草稿区，还是允许它在某些条件下直接触达客户？
如果你准备这周就启动一个试点，可以从一个动作开始：挑一个只读场景，把“网络白名单 + 临时凭证 + 工具审计”三件事拉通一次。然后回头看日志——它到底想访问哪些你没预料到的资源？那份“意外清单”，通常比任何安全原则都更能帮你把边界画实。
FAQ
Q: 自托管沙箱是不是等于“我得自己运维一套很重的东西”？
A: 不一定很重，但你确实要为隔离、镜像、日志付出运维成本。好处是边界更清晰：出事能销毁、能复盘、能证明它没越界。
Q: MCP tunnel 解决的是安全，还是连通性？
A: 两者都有。它让 Agent 能够访问内网 MCP 服务（连通性），同时把暴露面收敛到“只通这条通道、只到这几个工具”（安全）。
Q: 第一次试点最推荐从哪里开始？
A: 从只读场景开始：查库/拉工单/生成报表。验收标准清楚、风险低，而且最容易把审计、临时凭证、网络白名单这些底座一次搭好。