大模型接进生产系统的那一刻安全问题就不是“以后再说”的事了。智能体Agent本质上是一段持有企业密钥、能够执行任意命令、还能基于模型输出自动决策的代码。它不像传统服务那样可以通过静态审查来控制行为边界——因为它的每一步行为在运行时才真正浮现。很多团队第一版把智能体跑起来了然后就出了事故代码执行把宿主机目录删了、提示词注入让Agent把内部API密钥吐出去了、模型返回的恶意指令被当成系统命令直接执行了。这些事不是“可能发生”而是“已经反复发生了”。智能体沙箱就是这个问题的标准解法。它的思路不复杂把不可信的智能体代码关进一个隔离环境里环境里面它怎么折腾都行出来就是干干净净的日志和响应碰不到宿主机的内核、网络、文件系统。但“隔离环境”这五个字从选型到落地能愁死人隔离级别怎么定内核要不要虚拟化网络怎么放通模型API怎么安全接入日志怎么审计出了问题怎么排查。这篇文章不聊PPT架构直接把我自己在生产环境落地的全过程拆开来讲从隔离内核选型到大模型安全运行每一步都给出可复现的参数和思路希望帮你少走几趟弯路。1. 为什么大模型应用必须上沙箱1.1 智能体本质上是不可信的执行体先理清一个概念智能体跟传统应用到底差在哪里传统应用是“代码固定 输入变化”它的行为路径在发布时已经确定了。智能体则完全反过来——模型根据用户在对话中下达的意图动态决定调用哪个工具、执行哪段代码、读取哪些数据。这意味着你根本无法静态分析出智能体的完整行为集合。我见过一个内部工具型智能体本来只是让用户查询订单状态结果有人输入了一段精心构造的prompt智能体竟然读取了服务器的环境变量文件然后把数据库连接串拼进响应里返回给了用户。这属于典型的提示词注入攻击但暴露出来的问题恰恰在于我没有给这个智能体套上沙箱让它直接跑在宿主环境上了。沙箱从命名就知道干什么——一堆沙子里放个玩具孩子在沙池怎么挖都出不去。在生产环境里我们需要的也是这种“随便折腾但出不去”的运行环境。智能体的代码执行能力越强比如支持生成Python脚本、操作shell命令、读写文件越需要一个真正的隔离内核来兜底。隔离内核和普通进程隔离不一样普通进程共用内核攻击者一旦利用漏洞提权直接接管宿主机隔离内核则是每个沙箱实例运行在独立的轻量级内核里系统调用被用户态拦截和过滤攻击者即便击穿了应用层面对的也是一层几乎不可绕过的系统调用防线。1.2 哪些场景最需要沙箱不是所有大模型应用都需要完整沙箱我根据自己的实际经验把场景分成了三挡低风险场景模型纯做文本生成不调工具、不写文件、不联网。这种只需要做好API层限流和内容过滤不用上沙箱成本不值得。中风险场景智能体需要调用有限的工具比如查数据库、调用内部API但不执行任意代码。这种情况需要策略引擎审计日志对工具调用做白名单控制。高风险场景智能体具备代码生成并执行的能力或者需要操作浏览器、访问文件系统、运行任意命令。这类是必须上沙箱的而且要上隔离内核级别的沙箱。当前行业里大量智能体产品都具备“代码解释器”功能让模型生成的Python代码在服务器上跑这是最有价值也最危险的功能。没有沙箱这段Python代码就能访问宿主机所有文件有了隔离内核沙箱代码就只能在一个受限文件系统里打转访问不了进程列表、网络接口、真实环境变量这些敏感信息。2. 隔离内核选型四种主流沙箱技术全对比2.1 从系统调用级到虚拟机级的隔离光谱隔离内核的选型有个核心矛盾隔离越彻底性能损耗越大兼容性越好隔离越容易出漏洞。现在生产环境里常见的有4条技术路线我把它们放在一起对比一下技术方案隔离级别启动耗时性能开销兼容性典型场景DockerrunC内核命名空间毫秒级约5%以内极好低风险工具调用gVisorrunsc用户态Sentry拦截系统调用百毫秒级约20%-40%较好高风险代码执行Kata Containers轻量级虚拟机数百毫秒约20%-50%极好多租户强隔离Firecracker微VM轻量级VMM百毫秒级约15%-30%较好Serverless批量沙箱WASM运行时软件定义边界毫秒级约10%-20%受限于WASI纯计算场景单纯看这张表可能有点抽象我给你说个实际的例子。Docker默认的隔离方式只是把进程关在了一个“不同的房间”里但地板、墙面、管道都是共享的——也就是共享内核。攻击者拿到容器内的root权限如果内核有CVE漏洞就能穿过这些隔离直接攻击宿主机。gVisor的思路完全不同它不共享内核而是造了一个跑在用户态的“影子内核”Sentry所有应用发起的系统调用都被Sentry拦截、检查、转发仿佛给程序套了一个看不见的夹板任你如何使劲也摸不到真实内核。2.2 为什么生产环境我更倾向gVisor我最初在Kata Containers和gVisor之间反复犹豫过。Kata的隔离性确实扎实每个沙箱一个真虚拟机安全边界跟云主机一样牢固但它有两个让生产环境很难受的短板第一是启动速度太慢冷启动几百毫秒到一秒以上对交互式智能体体验很伤第二是内存和CPU占用偏重每个沙箱都跑一个完整内核集群跑几百个并发实例时资源消耗非常惊人。最后我选了gVisor作为主力方案核心原因是它在安全性和成本之间找到了一个舒服的平衡点。它装起来极简单——在Docker配置里把runtime从runc换成了runsc其他该用Docker Compose还是Kubernetes都不受影响。系统调用拦截的兼容性问题固然存在某些深度调用系统底层功能的程序会跑不了但Agent类应用本身主要就是跑Python、Node脚本调用最大的无非是文件读写、网络请求、进程管理这些gVisor都支持得很成熟。分享一个我个人实测过的基准测试数据。同样一段用Python写的批量数据处理的任务脚本在普通Docker里跑完需要12秒在gVisor里跑完是16.5秒性能损耗大约在30%——看着不小但在真实业务场景里Agent大部分时间都花在等模型推理返回、等外部API响应这些I/O环节上CPU计算占比并没有那么高所以实际体感损耗会远低于30%。严重依赖CPU密集计算的智能体任务我建议把这类业务分流到专属计算集群里别往沙箱里塞。2.3 WASM沙箱作为轻量补充对于纯函数型的智能体代码无文件系统持久化需求、无网络监听的场景WASM沙箱是我会额外用到的轻量方案。它把代码编译成WebAssembly字节码运行在Wasmtime或WasmEdge这类运行时中安全模型是纯软件定义的内存访问有边界也没有系统调用的概念一切外部访问都要显式通过WASI接口授权。在我看来WASM最适合用来跑“模型生成的单次计算函数”一个函数跑完就销毁异常干净。但它的问题是生态还不够完善很多Python库带C扩展编译成WASI支持的模块时经常报错所以目前只能作为特定场景的补充没办法全面替代gVisor。3. 沙箱架构实战设计从内核到网络的全链路隔离3.1 系统调用层的过滤与拦截机制确定用gVisor之后落地就不只是“把runtime换掉”这么简单了。整个沙箱架构我拆成了四层系统调用过滤层、文件系统隔离层、网络隔离层、资源配额层。下面一层层说。系统调用层是隔离内核最关键的部分。gVisor的Sentry内核会拦截所有系统调用运行时会根据策略决定放行还是拒绝。实际部署时我建议在默认策略之上再叠加一层seccomp过滤器。gVisor应用层的程序发起一个execve调用默认情况下gVisor就会拒绝执行未挂载的二进制文件但如果你的Agent本身需要动态编译和执行代码就需要在白名单里显式放行。这里重要的经验是拒绝列表永远比放行列表安全。我为智能体沙箱配置的默认策略是“所有未显式放行的系统调用全部拒绝”再单独把Agent时代的Python解释器、node进程需要用到的调用加进白名单。这样就算模型生成了恶意的shell命令连创建进程这第一道门槛都迈不过去。3.2 文件系统隔离的三种挂载方式文件系统隔离是另一个容易踩坑的点我在这上面栽过一次。最初我图省事直接把宿主机的一个工作目录挂载进沙箱让Agent在里面读写临时文件。看起来逻辑没问题结果一次模型生成了递归删除的代码把工作目录下的所有数据清光了。数据本身不敏感但工程同事辛苦整理了一周的标注数据就这样没了。教训就一句话绝不把宿主机真实目录直接挂给Agent沙箱。我后来设计的文件系统结构分三个独立目录用读多写少的思路控制权限/sandbox/app只读挂载。用于存放Agent程序本体、依赖包、模型配置等沙箱内不可修改。/sandbox/work可读写但映射到一个临时的内存盘数据卷里沙箱销毁时自动清空。专门放Agent生成的临时文件和中间产物。/sandbox/data可按需挂载宿主机中目标数据集目录但默认只读只有当用户显式授权某个文件给Agent时才通过动态挂载切换成可写。这种设计既保证了Agent有足够空间干活又限制了它只能破坏“一次性”的临时数据。生产环境里我给这个临时工作目录设置了严格的磁盘配额默认为每个沙箱实例5GB防止一段失控代码瞬间把磁盘空间填满。毕竟沙箱隔离的是访问权限不是资源滥用。3.3 网络隔离与出口策略网络隔离是智能体沙箱里最麻烦的一层也是最需要掉头发的。智能体要工作就得能访问外部API、模型服务、数据库——完全断网的沙箱没有实用价值。但给沙箱全开网络它就可能变成一个帮你发起DDoS攻击的跳板或者向外回传敏感数据。我的方案是把网络流量分成三类代理转发第一类模型API流量。走网关代理目的地址限制为内网模型服务的域名请求头自动注入服务身份鉴权凭证沙箱内的Agent不需要也不应该感知到真实的API密钥。密钥保存在对接的密钥管理服务的加密库里Agent拿不到明文。第二类白名单外部API流量。按业务需求维护一个域名列表杂七杂八的外部搜索、天气查询、新闻接口都算通过透明代理直连。DNS解析强制走代理侧沙箱内禁用自定义DNS从源头上阻断尝试绕过域名白名单的行为。第三类全部其他流量。默认拒绝。用iptables规则和代理层双重限制保证即使Agent代码试图向外部发送裸TCP包也会被彻底拦下。网络这部分我给出一个具体的配置参考。我用的代理服务器是EnvoygVisor沙箱里的Agent进程设置HTTP_PROXY环境变量指向Envoy的监听端口Envoy再按上面的三类策略做路由。这样做的好处是审计极其方便——每次外部请求都有完整日志事后要追溯Agent行为时可以直接从日志里还原它跟外部的所有交互。只允许Agent走这一条受控出口路径则无论模型被怎样诱导它找到的出口都只能是那扇用白名单过滤过的大门。3.4 资源配额与并发管理最后是资源配额。沙箱不是无限资源的保护壳一段死循环代码就能把一个节点的CPU全部占满。我每启动一个Agent沙箱实例就用cgroup给该实例设置三个硬性指标CPU默认限制0.5核高峰期可以动态上调至1核。内存默认2GB足够跑轻量模型推理脚本和数据处理但不是一次性给足而是配合gVisor的自定义内存缓存机制逐步释放。进程数限制每个沙箱最多生成50个进程。配额设好之后还要关注一个指标并发沙箱数量和宿主机总资源的比率。我踩过的坑是把40个2GB内存的沙箱实例塞进一台32GB内存的宿主机结果还没到高峰期宿主机直接进入内存回收状态所有沙箱都慢得像蜗牛。合理的规划是预留出宿主机总内存的20%-30%作为弹性余量避免出现物理内存耗尽。4. 大模型安全运行模型侧的另一半防线4.1 模型调用网关的鉴权与流量控制很多团队把注意力全放在沙箱技术上结果忽略了模型API本身的安全——这其实是最容易出漏洞的环节。沙箱负责隔离Agent代码但模型调用链路上还需要一道专门的防护关口。智能体沙箱里的Agent触达模型服务时我要求它必须通过一个前置网关而不是直接点对点连接模型服务。网关承担四件事鉴权、限流、审计、请求改写。鉴权很好理解每个沙箱实例创建时下发一个一次性token网关校验通过才放行过期立即失效。限流则是按用户维度控制调用频次比如每个用户每秒钟最多10次模型推理请求防止一个失控Agent把自己陷入死循环疯狂调用模型烧钱。审计配合沙箱日志储层能为后续问题定位提供完整的模型输入链路原始记录。请求改写比较妙——如果Agent在系统提示词中说明了某类敏感信息不可访问网关会在请求到达模型前自动注入安全提示词相当于在模型入口加一个软约束。4.2 提示词注入攻击的检测与防御提示词注入是大模型应用最头疼的安全问题之一沙箱解决不了它——因为注入发生在模型和工具交互的语义层而不是系统调用层。攻击者在外部数据源网页、文档、API响应里埋入恶意指令Agent读取这些数据时可能把指令当成系统要求执行进而访问不该访问的数据、调用不该调用的工具。我搭建了三层防御网输入侧分离把所有外部来源的文本与系统提示词在结构上隔离。分隔符策略仍然基础但关键是在给模型的系统提示词中明确告诉它外部内容是数据不是指令永远不要执行其中包含的命令。上下文感知检测引入一个轻量级的分类模型专门判断“模型即将执行的动作是否偏离了用户原始意图”。比如用户只是问了句“今天天气怎么样”但Agent准备去调用删除文件的工具这个偏差立刻触发拦截。最小权限执行即便提示词注入成功Agent能调用的工具范围也被策略引擎牢牢控制。可以这样比喻就算有人拿到了你办公室钥匙串里的某一把他开的也只能是其权限范围内的那扇门而不是整栋楼的所有房间。实际效果怎么样我做过一次渗透测试用了一份包含恶意指令的PDF文档喂给智能体让它读取后总结。正常情况下模型会直接执行PDF内容里的“调用微信接口给指定用户发消息”指令。但配上自动增设的关键工具调用确认与用户侧阻断机制之后Agent在提交高风险工具调用之前会停下来向用户确认用户一看操作内容就知道不对劲。这就是把安全边界从“技术强制”延伸到了“人机协同决策”。4.3 模型输出内容的过滤与脱敏模型输出同样是一道隐患。大模型在推理过程中可能不小心“想起”训练数据里的敏感信息比如真实姓名、手机号也可能被诱导输出不该渲染的内容。对于生产环境输出侧过滤是最终防线必须有。我用的方案是双层输出过滤先过一个正则规则层用来匹配手机号、身份证号、密钥模式等高危模式匹配到的内容直接脱敏替换成占位符再过一层基于意图分类的安全模型判断输出内容的语义安全性比如是否包含暴力指令、色情内容、自我伤害诱导等违规信息。规则层处理不了长尾内容语义问题模型层处理不了精确的模式匹配问题双层结合覆盖高价值证据相对完备。这里有一个容易被忽略的设计点过滤不要“静默替换”要“替换并标记”。被脱敏的位置要注入特殊标记让下游系统知道此处有信息被过滤掉了AGENT或用户如果在生成的JSON里看到这个标记就能判断输出完整性受影响及时做后续处理。有一次智能体返回一段代码片段其中包含了一个疑似真实的内部服务器IP地址要不是输出过滤把这段替换成了[REMOVED_IP]标记这个内网地址就会直接被暴露到不可信的客户端。4.4 模型本身安全权重与配置的保护大模型权重文件动辄几个GB甚至几十GB训练一个模型投入的成本很高这些文件在服务器里的安全和Agent沙箱完全无关——它不需要被Agent读取。部署时模型加载的根目录权限设置为仅对模型服务进程可读沙箱容器内即使有恶意代码也无法访问该目录。模型的配置文件和运行时参数同理只能由模型服务进程拥有读写权限。另外建议不同租户或不同业务线的智能体用不同的模型服务实例即使底模相同这样即使一个业务线的Agent被攻破另一个业务线的模型环境和数据也不会受牵连。我自己曾经遇到过一次因为共用一个模型服务实例导致一个低权限Agent意外读到了高权限业务线的数据库schema信息的险情。从那之后我把多租户模型服务的隔离作为一个硬性要求固定下来。5. 生产落地实录踩坑、调优与调试技巧5.1 容器编排里的gVisor兼容性难题实际部署到Kubernetes集群时第一个坑马上就出现了K8s默认的容器运行时是containerd它不会自动识别gVisor。你需要为K8s节点单独配置containerd的sandbox运行时并确保Pod的runtimeClassName指向runsc。具体来说在节点上安装gVisor之后要在containerd配置里增加一段运行时映射把它注册成一个可用的运行时然后在Pod的spec里指定runtimeClassName: gvisor。K8s调度时的资源分配也有讲究。gVisor沙箱的进程模型和普通容器不太一样它需要额外的用户态Sentry进程对节点的内存会多一些开销。如果你部署了资源配额建议在每个沙箱Pod的request内存上多留出约300MB的余量否则K8s的OOM Killer会在内存压力大的时候优先杀掉gVisor的Sentry进程沙箱里的Agent应用会毫无悬念地跟着挂掉。这个坑我调试了两天一开始还以为是模型服务出了问题查了半天才发现是Sentry被杀。5.2 性能调优从损耗30%到15%的过程gVisor的性能损耗虽然能接受但团队内部还是有些不满意——毕竟业务测过基准Python计算密集任务跑在gVisor里比普通Docker慢接近30%。我花了两周做了系统性的调优把实际损耗降到了15%以内这里分享三个最有价值的优化项。开启gVisor的FastPath。gVisor对纯计算型任务不涉及系统调用有直接在本机执行的优化路径这个开关默认是关的手动开启后CPU密集任务的损耗显著下降。需要说明的是FastPath开启后某些系统调用的跟踪能力会弱化审计完整性的要求决定了对审计敏感的应用要不要整体启用通常的做法是按实例粒度单独开启。启用平台虚拟化加速。gVisor有几个后端平台ptrace、kvm等用KVM平台比ptrace快不少。当时开启KVM平台后I/O密集型任务的性能直接提升了一个量级因为很多系统调用不再需要经过层层ptrace调试器模拟。调优网络路径。让沙箱的网络流量尽量走gVisor的虚拟网卡驱动不要走嵌套的用户态网络协议栈。用host-user网络模式替换默认的NAT模式后网络时延大约降低了20%。改动的时候要注意灰度顺序每改一个参数跑一次完整的Agent回归测试再对比指标稳定之后逐步放量。这类安全组件的调优点在于既没有充分压责任感和业务性能数据作支撑就不要凭直觉改改错了不只是性能问题可能连隔离策略都被关联影响。5.3 审计日志体系从沙箱到模型的全链路追踪智能体沙箱落地后安全团队会要求你回答“如果真的出了事你能知道Agent干了什么吗”。这就要求有一个全链路审计能力从用户发出指令开始到模型推理、工具调用、外部请求、数据读取每一步都要有记录。我的日志方案分三个存储通道沙箱日志gVisor的runsc产生的系统调用日志记录Agent进程尝试发起的每个敏感系统调用。因为日志量太大了我做了采样策略只记录被拒绝的调用和成功的高危调用execve、mount、ptrace、socket等。完整的“所有调用都记录”在日常流量下会把磁盘写穿不值得。应用层追踪Agent框架本身发出的结构化日志包括输入输出摘要、工具名、调用参数、耗时等。这类日志最重要排查问题时80%的线索都在这里。模型层日志网关记录的模型请求哈希、返回校验状态、脱敏标记等。不存全量的文本——有隐私风险只存向量哈希需要的时候再通过安全审计通道解密拉取原文。三条通道的日志通过同一个traceId串起来。每次用户会话开启就生成一个全域唯一的traceId贯穿沙箱生命周期、应用逻辑、模型调用链路的日志统一上报至日志平台套件。事后排起查来非常爽输一个traceIdAgent在这段时间里做的所有事情以一种时间线的方式聚合在同一个界面上展示出来。行为审计的意思就是靠这套体系实现的——它能准确回答“某一毫秒Agent在执什么”、行对应宿主机上的哪一层边界就像机舱黑匣子一样。5.4 故障演练与渗透测试的实操经验架构搭好以后不能干等着“出事再修”主动做故障演练和渗透测试才是成熟做法。我现在的习惯是每个季度对智能体沙箱做一次全面渗透演练模拟的攻击路径大致有3类我们称之为“三道送命题”第一道恶意代码执行。构造包含恶意Python代码的输入诱导Agent执行任意命令读取宿主机/etc/passwd、查看环境变量、访问元数据服务。验证的指标是这些行为必须被沙箱和网络策略双重拦截并且触发审计告警。第二道提示词注入。在外部的文档、搜索结果、甚至图片OCR文本里埋隐藏指令看Agent是否会被诱导调用越权工具或回传敏感数据。验证指标是越权调用被策略引擎拦截在调用前敏感数据的回传被输出过滤脱敏同时产生异常行为告警。第三道逃逸尝试。尝试从沙箱内发起对宿主机内核的攻击宿主机内网探测、向外部建立未经授权的网络连接、写入宿主机的共享目录。验证指标是所有违规行为不仅被拦截而且有对应的日志可供分析。三次演练分别解决“代码层出事”“语义层出事”“边界层出事”的问题。每次演练结束后我会根据结果更新策略引擎的白名单规则库。隔一段时间攻击手段又会升级所以这个清单本身也得持续更新迭代。6. 常见问题速查表与排查经验6.1 六个高频问题及其排查思路下面这几个问题是我在反复支撑生产环境的过程中积累的整理成速查表方便遇到问题时快速定位方向。问题现象可能原因排查思路沙箱内Agent启动失败日志无输出gVisor路径未生效Pod仍然用默认runc检查Pod的runtimeClassName配置看容器真实运行时是否为runsc沙箱内无法访问外部API返回超时网络策略白名单未覆盖目标域名查Envoy日志确认流量是否到达代理层再检查域名白名单Agent执行速度极慢单步操作超时gVisor FastPath未开启或KVM平台未开启确认后端平台类型结合CPU密集任务占比调整平台配置沙箱内文件读写权限报错挂载目录权限设计过于严格按实际需求调整挂载方式数据目录优先维持只读临时目录保持可写模型报警“敏感内容”但Agent并未输出输出过滤层对业务合规内容误判检查过滤模型的阈值配置把业务场景的负样本加进训练集再重调阈值沙箱实例内存持续增长无法回落Agent程序内部缓存问题或gVisor的缓存机制未释放定位具体进程确认是业务内存泄漏还是沙箱内存碎片按情况优化或重启6.2 一个诡异的“幽灵进程”问题简单分享一个让我印象深刻的奇葩问题和排查过程。有段时间生产环境的沙箱节点频繁出现CPU飙升但看沙箱日志却看不到明显异常。后来跟踪到Sentry层才发现是gVisor在特定条件下会出现一个内部状态更新循环出现忙等待busy-wait。这个问题表现得很隐蔽——从应用层看Agent什么都没干但CPU就一直被烧。最终解决方式是更新了gVisor的版本并在每个节点上加了CPU异常突刺的监控告警一旦某节点CPU持续超过85%并且沙箱处于空闲状态就自动触发沙箱重启流程。这种问题千万别指望一个月一次的故障演练能提前发现。生产环境的问题总是千奇百怪保持监控粒度、保持对安全组件升级迭代的敏感度比任何应急预案都管用。6.3 一条适用于全行业的公共安全口诀做智能体沙箱这段经历让我想通了一个底层道理安全不是某一层做得多好而是每一层都有一点纵深。操作系统层面的内核隔离兜底能力最强网络层面的出口白名单收紧权限应用层面的策略引擎约束语义行为模型层面的过滤防线避免最后一公里泄密——这四层互相补位任何一层被突破都不至于全盘崩溃。具体到架构之外还有一个团队协作的经验非常想强调智能体安全不能只靠安全团队开发智能体业务逻辑的同事同样要多沟通。很多漏洞其实源于开发团队为了方便私自把某段业务代码绕过沙箱跑在了宿主机上——这种“走后门”行为对整体安全架构的伤害比任何外部攻击都更直接。我后面给开发团队开了个沙箱使用规范所有Agent代码的运行通道都必须走统一的沙箱入口任何特例都要走审批流程。比较庆幸的是我们很早就定下了这条规矩后期少了很多头疼的善后工作。6.4 当前落地的最终架构长什么样现在整个智能体沙箱生产架构已经稳定运行了接近一年总结下来是一个包含三个核心组件的体系沙箱运行池负责承载所有Agent实例用gVisor做隔离内核配合同步更新的资源配额和文件系统挂载策略安全策略引擎统一管理所有Agent能调用的工具权限、网络白名单、高危操作审批流程规则全部配置化不用改代码就能调整全链路审计平台接收并索引沙箱日志、应用追踪日志、模型网关日志支撑事后追溯和行为审计。对大模型应用的理解越深越觉得这个架构还得继续演进。比如当前越来越多的团队开始让智能体自主管理长期记忆库存储在向量数据库里的敏感信息怎么在沙箱框架下做更细粒度的访问控制已经是我在规划的下一个方向。Agent的能力边界还会继续扩张安全架构也要跟着它一起跑步前进。写这篇长文的初衷很简单——把我在这个过程中踩过的坑、验证过的方案、想透了的原理都留下来。希望每一个准备把智能体推向生产环境的团队都能少走几段弯路多一份安全底气。