正在加载，请稍候
企业 AI Agent 平台搭建的真正难点在执行侧：隔离、启动、状态、规模、治理五类矛盾如何拆解成沙箱层、托管层与网关策略层。
某券商办公智能体在测试环境里一句话就能生成周报，接进生产第一周被安全团队拦下的不是"它会不会做"，而是"谁允许它写文件、连内网、装依赖"。企业做 AI Agent 平台搭建，真正的分水岭就在这一句上。
智能体的能力边界这两年扩张得很快：写代码、跑代码、操作浏览器与桌面、读写文件、安装依赖、调用内部系统，甚至参与训练与评测。能力不再稀缺，稀缺的是"允许它动手到什么程度"。
2026 年 QCon 上海站把这件事摆上了主舞台。蚂蚁集团高级技术专家林鑫的议题《从沙箱到执行边界》给出的判断很直接：当自主性越过传统应用的安全边界、长生命周期会话撞上资源成本约束、批量训练需要瞬时拉起可信执行环境时，传统容器与普通 Serverless 都撑不住企业级规模（议题摘要）。
我们复盘过几个事故，结论一致：模型侧大多完成了任务，出问题的是执行侧缺一层统一裁决。
上述议题把生产环境的问题归纳成五类矛盾。整理成下面这张表，可以在评审会上直接对着问。
| 矛盾 | 生产现场表现 | 我要追问的判据 |
|---|---|---|
| 隔离难 | 会执行生成的代码，同时要访问文件系统与内部网络 | 租户、身份、网络、内核四层边界是否各自有明确归属？ |
| 启动慢 | 安全容器、镜像拉取、依赖初始化、持久化挂载叠加 | 冷启动里各环节耗时占比拆过没有？缓存命中率是多少？ |
| 状态重 | 工作区、依赖、会话上下文要留，资源又不能空转 | 哪些状态必须持久化，哪些可以快照恢复？ |
| 规模大 | 批量评测瞬时拉起大量环境，镜像风暴与配额竞争 | 环境是否可版本化、可复现、可公平调度？ |
| 治理散 | 高危动作的判断散落在各个业务 tool 里 | 策略由谁裁决，审计链路是否端到端贯通？ |
最常被低估的是这一条。业务方希望智能体像同事一样用内部系统，安全方希望它像个陌生进程。两个诉求都合理，冲突只能靠架构而非承诺来解决。
可行做法是先划清四层边界各自的责任人：租户边界由调度层负责，身份边界由令牌体系负责，网络边界由出口网关负责，内核边界交给安全容器。四层里任何一层靠"业务代码里判断一下"，后面都会出事。
如果你们还处在"沙箱到底该覆盖哪些动作"的争论阶段，可以先看我们拆过的从沙箱到产线的四个工程门槛，那里的判断顺序可以直接复用。
强隔离和低延迟天然对立。安全容器、网络隔离、持久化挂载都会推高启动成本，缓存池、镜像懒加载、内存快照只能缓解，无法消除所有场景的冷启动压力——这是议题里明确承认的取舍。
工程上先做拆解而非优化：把镜像拉取、调度、挂载、启动、ready 各阶段耗时单独打点，否则"启动慢"会变成一个无法归因的笼统抱怨。
办公智能体和编码智能体希望像云电脑一样长期保存状态，平台方希望空闲即释放。这个冲突没有单点解，只有持续权衡：哪些工作区必须持久化，哪些用检查点恢复，哪些允许重建。
我们的经验是把"状态"拆成计算状态、文件状态、身份状态三类分别治理。三者混在一起谈，讨论会无限循环。
做智能体强化学习或批量评测时，瓶颈往往不是算力，而是环境供应链。瞬时创建大量沙箱会同时打击镜像中心、缓存层和调度器，出现缓存击穿与租户间配额竞争。
环境必须可版本化、可复现、可调度、可观测。缓存感知调度、多集群路由、租户配额、批量任务优先级这几个机制，缺一个都会在压测时暴露。
多智能体协作放大的是同一个问题：参与角色越多，需要同时存在的执行环境越多。这方面的一份实验复盘值得对照——多智能体实验的三个工程警示。
最典型的反模式是：每个业务 tool 自己判断"这个操作要不要进沙箱"。上线三个月后，没人说得清全站有多少条这样的判断，也没人敢改。
正确方向是把安全决策收敛到平台层（议题中的做法是收敛进工具网关），业务侧只声明动作的风险元数据，由平台在派发前统一裁决。相关机制我们做过一次拆解，见给工具调用立规矩的工程拆解。
落地顺序建议遵循议题总结的三句话：先定义执行边界，再优化启动性能；先拆状态，再谈弹性；先平台化策略，再放开 Tool Use。后一句为什么成立，可以先读为什么 harness 比模型更重要（议题提纲）。
如果你们的托管层还没建起来，先判断一下要不要自研：低代码平台二次开发与私有化部署的取舍，我们已经写过一份路径对比（Coze 平台二次开发）。
核心判断是：不是所有东西都进沙箱，而是把高危动作路由进受控执行边界。常规对话与编排跑在普通服务里，代码执行、文件修改、构建测试、外部输入处理和高危系统操作才进沙箱。
策略侧需要动作分类、风险元数据、以及派发前裁决（可选结果包括宿主机执行、试运行、人工审批、沙箱执行、直接拒绝）。身份与审计要同时做：短期委派身份、最小权限令牌、出口网关、调用链追踪与操作审计，一个都不能省。
最后是状态共享。主智能体在外部服务运行、高危动作在沙箱内执行，两者之间的工作区、产物、追踪标识、输入输出包必须走显式协议，否则整条链路会变成不可观测的黑盒。
量级参照比绝对值更有用。该实践体系支撑的是数万级每日沙箱创建、千万级日请求和万核级资源峰值——在这个规模下，任何被忽略的浪费都会被放大成账单。
我们建议平台团队先把三个口径固定下来，再谈优化：
只有把这三件事写进容量报表，"要不要为了快而牺牲一点隔离"才能在数据上讨论，而不是在会议室里吵。
执行边界不是内部洁癖，它直接影响外部风险。云安全公司 Wiz 在一份名为《GhostApproval：AI 编码助手中的信任边界漏洞》的报告里指出，有六款 AI 编码助手可能被恶意代码库欺骗，向用户展示看似无害的审批提示——审批环节看着在，实际已经失效（InfoQ 相关报道）。
同一篇报道还提到，InfoQ 此前报道过厂商披露的沙箱逃逸问题。这说明隔离层一旦被穿透，后面的审批与审计都是纸面防线。
另一端是效率与安全的平衡怎么做才算健康。Figma 的安全智能体接入了 100 多个数据源，把复杂告警的处理速度提升了约 70%、值班通知减少了 20%，但生成的修复请求默认置为草稿，敏感数据也不允许出现在公共频道里（原文）。它们给的经验是：先提高精确率，再提高召回率。
换句话说，能自动执行的先别急着自动生效。把"自动完成 + 人工确认"作为默认档位，比事后补审计便宜得多。
这八条里的每一条，我们都在真实项目里见过因为跳过它而返工的案例。
取决于动作风险等级。只读查询、纯文本处理可以跑在常规隔离环境里；执行生成的代码、写入文件系统、访问内部网络这类动作，需要内核级隔离加网络出口治理。全量上重隔离会拖垮体验，全量不上则等于没有边界。
都不是。模型可以做建议但不能做裁决，业务方各自裁决会迅速失控。可行做法是平台定义动作分类与策略框架，业务方只提供风险元数据，裁决在派发前由平台统一完成。
把安全决策从各个业务 tool 里收回来。它是高危动作进入受控环境的唯一入口，同时承担身份注入、出口管控、调用链追踪与操作审计。没有它，审计链路一定是断的。
先拆到阶段级别，再按场景定目标：办公类交互场景看 P95 体感，批量评测场景看吞吐与缓存命中率。用缓存池、镜像预热、内存快照把常见路径压下去，接受长尾场景仍有一次完整启动。
如果你正在做 AI Agent 平台搭建，卡在"要不要给执行权限、给到什么程度"这一步，可以看看我们交付过的企业智能体与平台工程案例，里面有执行边界、审计链路与成本口径的完整设计记录；也可以直接联系我们，把你们现在的动作清单拿出来过一遍。