过去几年企业IT团队已经很习惯用容器和K8s来管理应用。服务如何部署副本如何扩缩节点故障后如何恢复版本如何滚动升级这套工程体系已经很成熟。很多团队开始做Agent平台时也会自然沿用这套经验既然Agent也要运行代码、访问文件、调用工具那是不是给每个Agent任务分配一个容器就能把执行环境管起来这个判断在早期试点里通常说得通。任务数量不大执行动作比较简单用户也集中在少数研发或运营团队容器可以提供一个相对干净的运行环境也方便做资源限制。但Agent进入企业真实业务后问题会变得细很多。它不再像一个长期运行的后端服务也不完全像传统批处理任务它会根据用户输入临时规划执行步骤在过程中调用工具、读写文件、访问内部系统有时还需要把中间状态保存下来失败后继续处理。因此传统容器仍然是企业Agent基础设施的重要组成部分但它更适合承担资源编排和基础隔离。大规模Agent需要的是在容器之上再增加一层面向任务语义的运行时和沙箱治理能力把身份、权限、网络、文件、工具调用和审计记录放进同一条执行链路里。一、容器和K8s原本解决的是稳定工作负载问题Kubernetes官方文档把Pod定义为K8s中最小的可部署计算单元。这个抽象很适合微服务因为微服务通常有明确镜像、固定入口、健康检查、服务发现和副本数量。平台不需要理解业务逻辑只要保证这些工作负载按照预期运行。K8s也支持Job这类一次性任务适合批处理、离线计算、定时执行等场景。但Agent任务的特点不只是“执行一次就结束”。同一个Agent可能在一次任务里完成多轮推理中间调用不同工具并根据工具返回结果调整后续步骤。一次任务可能只有几十秒也可能持续十几分钟一次只是查询知识库下一次可能要生成脚本并访问内部接口。容器能把进程装起来但它默认并不知道这次执行背后的业务身份、操作意图和风险等级。维度微服务/传统容器工作负载大规模Agent执行任务生命周期相对稳定按版本发布和扩缩容临时创建任务结束后释放执行内容代码和入口相对固定由用户输入、模型规划和工具返回共同决定状态管理通常依赖数据库、缓存或持久卷需要记录任务步骤、中间文件、工具结果和恢复点隔离重点进程、资源、网络和命名空间用户身份、工具权限、文件边界和任务级策略审计对象服务日志、访问日志、容器事件每次任务、每个关键动作和人工确认记录这张表里的差异会直接影响架构设计。把Agent当作普通应用托管早期能降低建设门槛进入生产环境后平台要管理的不只是算力和容器实例还包括Agent以什么身份执行、能碰哪些数据、工具调用是否被允许以及执行失败后能不能复盘。二、突发创建会把调度成本放大企业内部的Agent任务往往带有明显的突发性。业务部门可能在月底集中生成分析材料客服团队可能在活动期间批量处理工单研发团队也可能在同一时间段发起大量代码检查任务。对微服务来说峰值通常通过扩副本和队列缓冲处理对Agent来说平台面对的是大量临时执行环境的创建和回收。如果每个任务都从零创建容器或Pod调度、镜像拉取、网络初始化、权限注入都会占用时间。对于长时间运行的服务这些成本可以被摊薄对于短任务这些准备成本可能比真正执行任务还显眼。工程团队当然可以通过镜像预热、节点池、任务队列和容器复用池来优化但这些优化已经超出单纯“用K8s跑起来”的范畴开始接近Agent Runtime的设计问题。Agent Runtime这一层要解决的是如何把临时任务稳定地放进可控环境里执行。它需要知道任务优先级知道哪些任务可以复用轻量环境哪些任务必须进入更强隔离的沙箱也要在高峰期限制并发避免一批Agent任务把集群资源打满。三、隔离粒度要从容器边界下沉到执行动作Docker安全模型依赖Linux namespace、cgroup等机制也可以叠加seccomp、AppArmor、SELinux等能力来限制系统调用和访问范围。这套机制对传统应用很有价值但Agent执行内容经常更接近“不完全可信代码”。模型可能生成脚本工具可能处理用户上传文件任务还可能访问企业内网接口。风险不只来自容器逃逸也来自Agent在容器内部做了不该做的事情。企业在这里关心的隔离粒度会变细。某个Agent能不能读取这个目录能不能访问某个域名能不能执行Shell命令能不能把结果写回系统这些问题无法只靠容器边界回答。容器能限制一个进程组能用多少CPU、内存和文件系统视图但企业还要把业务权限、工具权限和数据权限映射到每次任务上。在这种执行风险下gVisor、Firecracker这类技术就会被纳入架构讨论。gVisor通过用户态内核拦截和实现系统调用减少工作负载直接接触宿主机内核的机会Firecracker使用microVM为容器和函数类场景提供更强隔离。它们各有适用边界不能简单理解为传统容器的替代品更适合在高风险Agent执行场景中作为安全隔离层的一部分。四、短生命周期任务更需要状态恢复和执行留痕传统服务重启后通常重新接入流量状态放在数据库或外部存储里。Agent任务的状态复杂一些它可能已经完成了资料读取、知识检索或工具调用也可能在等待人工确认。如果执行环境中断平台不能只给出“容器失败”这样的结果还要知道任务卡在第几步哪些动作已经生效哪些中间结果可以复用哪些临时凭证要回收。这类状态管理很难完全交给K8s原生对象处理。K8s可以告诉你Pod是否重启、Job是否成功、容器退出码是什么但Agent平台还需要记录更贴近业务的执行语义。比如一次核对任务已经读取了哪些文件调用了哪个内部接口生成过什么结果是否经过人工确认。缺少这层记录平台即使能把任务重新拉起来也很难解释这次Agent执行为什么走到这里。在企业环境里审计也不是简单存日志。日志要能串起用户请求、Agent规划、工具调用、策略命中、人工确认和结果交付。只有这些信息能被追溯安全团队和业务负责人才能判断一次执行是正常自动化、误操作还是策略配置存在漏洞。五、多租户安全要细到任务和身份K8s多租户通常会使用namespace、RBAC、ResourceQuota和NetworkPolicy等机制来隔离团队或应用。这个基础能力仍然重要但Agent平台里的租户边界更细一个员工、一个部门、一个业务系统、一次临时任务都可能成为权限判断对象。更麻烦的是Agent执行会同时携带多种身份。它代表哪个用户发起任务当前Agent属于哪个业务空间调用工具时使用什么凭证访问内部系统时继承哪一层权限这些身份如果没有统一管理就会出现审计断点。平台表面上看起来是Agent在执行真正追责时却无法确认是用户授权、系统默认放行还是工具配置过宽。安全层次传统容器常见控制点Agent沙箱需要补充的控制点资源CPU、内存、存储配额按任务限制资源并结合优先级做并发控制文件挂载卷和目录权限任务目录隔离、临时文件回收、敏感文件访问策略网络命名空间和网络策略按任务动态控制出口、内网访问和工具侧连接身份ServiceAccount、RBAC用户身份、Agent身份、工具身份之间的映射审计容器日志、集群事件任务步骤、策略命中、人工确认和结果归档难点并不集中在某一个控制点上。一次Agent执行从开始到结束身份注入、策略匹配、高风险动作拦截、环境回收和证据保留都要同时生效。仅靠容器编排层很难把这些业务语义全部串起来。六、更现实的架构K8s做资源底座Agent沙箱做执行治理企业不需要把K8s和Agent沙箱放在对立面。更现实的做法是让K8s继续管理节点、镜像、资源和基础网络把Agent任务调度、沙箱策略、工具权限和审计留痕放到更上层的Agent Runtime里处理。可以把这一层拆成几个相对清晰的模块。任务编排层负责接收用户请求把任务拆成可执行步骤并决定是否需要人工确认。沙箱调度层负责选择轻量容器、强隔离容器或microVM等执行环境。安全策略层负责在任务运行前注入文件、网络和工具权限并在运行中拦截高风险动作。审计层负责把任务过程记录成可查询、可复盘的链路。例如凡泰AI的Agent安全执行底座更适合承担这类Agent执行层工作。它和K8s的分工可以拆开看K8s负责底层资源编排Agent安全执行底座负责把隔离、策略、审计和任务级管控补到运行链路中。企业要处理的是Agent运行之后的控制问题包括访问范围、执行动作、失败恢复和事后追溯这些内容已经进入任务级治理范畴。七、企业建设时可以先抓住几个边界做大规模Agent平台时架构不一定一开始就上到最复杂的形态。更稳妥的推进方式是先按风险把任务分层。普通知识检索和文本生成可以进入轻量环境涉及脚本执行、文件处理和内网接口访问的任务进入受控沙箱涉及系统回写、客户触达或高价值数据处理的动作需要增加人工确认和更完整的审计记录。同时企业要避免把所有能力都堆到模型层。模型负责理解和规划执行层负责隔离和策略业务系统负责最终数据一致性和权限判断。几层边界划清楚后Agent才不会变成一个权限过宽的黑盒进程。技术团队后续做容量规划、安全复盘和故障定位时也能从任务视角找到问题不必只在集群日志里搜索某个容器为什么退出。这个差异处理清楚之后Agent平台才不只是“能跑任务”而是逐步接近企业可以长期运营的AI执行基础设施。