企业官网建设流程全解析

neocloud 这类新兴算力云平台把 GPU 资源做成了比传统云更灵活的按需服务，但权限边界往往更薄。Ilya Sutskever 对 neocloud 的提醒，翻译成工程问题就是：当 AI Agent 开始在算力池里自主行动时，网络安全与资源治理必须从同一个权限模型里长出来。如果只把 Agent 当作普通容器部署，只关心推理结果，不考虑它在算力节点上拥有什么权限、能申请多少资源、崩溃后是否会自动重试，那么一次失控调度就可能把整批空闲 GPU 占满，甚至影响同集群其他租户。

这篇文章不打算复述某次具体言论，而是把这个提醒落成一组可执行的技术方案。读者可以是 neocloud 平台的运维工程师、基于 GPU 集群做 Agent 开发的算法工程师，或者刚接触 Agent 安全的学习者。读完以后，你会先理解 Agent 失控抢占算力的完整链路，再掌握身份认证、配额限制、沙箱隔离、日志审计、异常告警这条防线怎么搭，最后获得一份能在自己环境里直接用的排错清单和最佳实践清单。

1. 先理解 neocloud 与失控 Agent 抢占算力的真实链路

1.1 neocloud 是什么，为什么它的资源边界更容易失控

neocloud 通常指新兴的、以 GPU 算力为核心的云服务平台。和传统 IaaS 云相比，neocloud 把 GPU 实例、模型推理、训练任务、API 调用打包成更简单的产品形态，开发者可以快速申请显卡、部署模型、对外提供推理接口。这类平台强调的是“算力像水一样随时可取”，因此资源调度和计费颗粒度都很细。

问题也出在这里。传统云平台的租户隔离、配额管理、审批流程经过了多年沉淀，而 neocloud 为了降低使用门槛，往往把资源分配做得过于宽松。平台对外提供推理 API 时，很难判断请求背后是普通用户脚本还是一个具备自主决策能力的 Agent。当 Agent 进入生产环境，它不再只是“调用一次模型”，而是会循环思考、生成子任务、调用工具、读取上下文、重试失败请求。每一次自主行动都可能触发新的算力申请。

所以，neocloud 自身的网络安全不能只停留在防 DDoS、防 SQL 注入、防暴力破解这一层。它要把 Agent 当作一种“不受信任的自主主体”来处理：Agent 的请求来源不可信、Agent 执行后的行为不可预测、Agent 崩溃后的重试策略可能造成雪崩。这样看，失控 Agent 抢占算力并不是偶发事故，而是 Agent 化应用在资源治理缺位时的必然结果。

1.2 Agent 抢占算力的四条典型路径

在真实环境中，Agent 抢占算力通常不是单点原因，而是多条路径叠加。梳理四条典型路径，有助于后续按图索骥。

第一是身份滥用。Agent 运行时需要访问 GPU 节点、对象存储、数据集、模型仓库。如果平台为用户生成了权限过大的 API Key，或者 Agent 在公共镜像里保留了硬编码密钥，攻击者或失控 Agent 本身就能用该身份申请大量资源。

第二是配额缺失。平台对普通容器做了 CPU 和内存限制，但对 GPU 算力只做“按卡计费”不做事前配额。Agent 在一个循环里连续启动多个子任务，每个子任务申请 1 张卡，并发几十个任务后，配额形同虚设。

第三是权限提升。Agent 在容器内运行，如果容器以 root 身份启动，或者挂载了宿主机 Docker Socket、云平台的元数据服务，Agent 就能通过云 API 申请新的 GPU 实例，绕过原有的资源池限制。

第四是无限重试与循环。Agent 调用模型推理接口，因为超时或模型响应格式错误而进入重试逻辑。如果没有最大重试次数和任务超时时间，这个循环会一直申请算力，直到把当前队列占满。

这四条路径不是互相独立的。权限提升后更容易绕过配额，身份滥用后更容易进入高权限容器，无限循环则会让所有现有防御被持续消耗。理解这条链路后，再设计防护措施就有明确优先级。

1.3 一次“Agent 抢占算力”事件的时间线示例

用时间线描述事故过程，比堆概念更直观。假设某个 neocloud 平台为开发者提供了“可自主运行的模型分析 Agent”。

09:00，开发者通过 Web 控制台上传了一个 Agent 任务，期望它分析一批 PDF 报告，并按模板生成摘要。

09:05，Agent 启动，调用第一个大模型接口处理第一份 PDF。模型返回超时，Agent 代码进入重试分支。

09:06 到 09:20，Agent 不断重试同一份 PDF，每次重试都重新初始化推理客户端、重新加载上下文，GPU 显存消耗持续上升。

09:21，由于重试次数没有上限，Agent 新建了多个并行子任务，每个子任务都申请独立的 GPU 实例。调度器看到资源还有剩余，继续分配。

09:25，同一节点上的其他正常推理服务响应变慢。平台监控报警，但值班同学看到的是“GPU 利用率高”，第一反应是业务高峰。

09:35，Agent 申请的 GPU 实例数量超过配额剩余量，容器运行时开始报错，但 Agent 的异常捕获逻辑把错误写入日志后继续重试。

09:50，运维工程师发现计费账单在半小时内快速上涨，定位到该 Agent 任务，强制终止后集群才恢复。

这条时间线说明：可以先产生“算力抢占”的结果，再被从计费数据或监控中反向发现。如果平台在 Agent 设计阶段就约束重试次数、并发数、单任务时长，事故根本不会走到 09:35 之后。所以，防护的核心不是事后止损，而是在 Agent 的运行时边界和平台资源层同时卡住。

2. 网络安全视角下的风险面，不是再加一层防火墙

2.1 从 OWASP Top 10 到 Agent 安全，风险模型发生了什么变化

传统网络安全里，OWASP Top 10 覆盖注入、失效的身份认证、敏感数据暴露、访问控制缺陷、安全配置错误等风险。这些风险在 neocloud 中依然存在，但 Agent 化应用引入了一个新的特点：风险主体从“用户请求”变成了“带状态的自主程序”。

普通 HTTP 请求是一次性的，服务器响应完就结束了。Agent 不一样，它有记忆、有工具调用、有子任务分解能力，还可能在一个会话里连续执行多个动作。如果每个动作都重新校验身份，那么就需要一套完整的身份传递机制；如果 Agent 能自主调用其他服务，那么它本身就是攻击面的一部分。

举个例子，一个联网检索型 Agent 被诱导读取恶意网页，网页里包含 prompt injection 指令。Agent 可能因此生成新的工具调用，请求内部的文件读取服务。如果没有对这些工具调用的权限校验，Agent 就从“业务工具”变成了“内网跳板”。这与用户直接提交恶意请求不同：用户请求往往有固定参数结构，而 Agent 的工具调用是动态生成的，防火墙和 WAF 很难提前枚举规则。

因此，neocloud 平台在安全设计上要做两层转换。第一层，把 Agent 当作不可信的外部实体，所有资源访问都必须经过身份认证和授权。第二层，把 Agent 的每一次工具调用都记录为独立事件，纳入审计和异常检测范围。不能因为 Agent 是平台自己的程序，就默认它的内部流量是可信的。

2.2 身份认证在 Agent 场景下为什么比传统 API 更难

传统 API 认证通常是“客户端携带密钥，服务端验证密钥”。Agent 场景的难度在于，同一个 Agent 在执行复杂任务时，会代表不同用户、不同租户发起请求。如果 Agent 只保存一个“服务账号”，那么它获得的所有结果都归属于同一个身份，审计时无法区分是哪位用户发起的分析任务。

另一个难点是：Agent 的长时运行任务可能持续几小时甚至几天，而 API Key 的过期时间往往按天或小时配置。如果密钥过期，任务会中断；如果密钥不过期，泄露后的风险窗口又太大。合理的做法是把短期身份令牌和长期任务状态分离：Agent 启动时获取短期令牌用于外部服务调用，内部任务状态保存在有权限控制的存储中，而不是放在一个永不失效的 API Key 里。

那在实际工程中能落地的做法是什么？

• 平台为每个 Agent 任务分配一个临时身份，而不是共用一个平台级服务账号。
• 对外部服务调用使用短期 Token，并允许 Agent 在任务执行期间自动刷新，刷新动作本身也要审计。
• 对 Agent 能访问的存储桶、模型仓库、推理服务做细粒度授权，尽量使用资源级策略，而不是全局管理员权限。

身份认证不是 Agent 开发的最优先任务，但它决定了事故发生后能不能定位到责任人、能不能快速吊销权限。没有独立身份的 Agent，本质上就是一个运行在黑盒子里的定时炸弹。

2.3 权限模型：给 Agent 最小权限，而不是“能用就行”

最小权限原则并不是新概念，但 Agent 场景需要把它落到更细的粒度。普通容器镜像运行时只需要读取模型权重、写日志、访问对象存储，那么它的 Deployment 就不应该拥有创建 GPU 实例的权限。

更关键的是，Agent 的工具调用权限要单独建模。例如 API 服务器对外提供“文件上传”“数据查询”“模型推理”三个接口，Agent 的权限模型应该分成三种独立授权：

权限模型设计完成后，还要有一个很关键的动作：把 Agent 的运行身份和访问外部服务的身份分开。运行身份决定它在容器、集群内能做什么；访问身份决定它调用外部 API 时能做什么。两者都遵循最小权限，即使其中一个被突破，另一个还能兜底。

3. 最小可落地的防线设计：配额、沙箱、任务超时

3.1 用 Kubernetes 资源配额限制 Agent 能拿到的算力上限

如果 neocloud 平台基于 Kubernetes 构建，资源配额是第一道硬边界。Kubernetes 的 ResourceQuota 可以限制一个命名空间下的 CPU、内存、GPU 数量。LimitsRange 可以给每个 Pod 设置默认的 GPU 请求值，防止 Agent 在未声明资源需求时申请超大显卡。

下面是一个在 NVIDIA GPU 节点上限制 GPU 数量的 YAML 示例。需要提前安装并配置 NVIDIA Device Plugin，确保集群节点可以上报 nvidia.com/gpu 资源。

apiVersion: v1 kind: ResourceQuota metadata: name: agent-gpu-quota namespace: ai-agent-prod spec: hard: requests.nvidia.com/gpu: "4" limits.nvidia.com/gpu: "4" requests.cpu: "20" requests.memory: "64Gi" limits.cpu: "40" limits.memory: "128Gi" count/pods: "20"

这段配置的核心是把命名空间 ai-agent-prod 中所有 Agent Pod 的总 GPU 数量限制为 4 卡。CPU 和内存同时设上限，避免 Agent 在 GPU 申请失败时靠 CPU spikes 拖垮节点。count/pods 限制 Pod 总数，配合 HPA 或自研调度器后，能防止失控任务无限扩容。

使用配额后，还需要设置默认资源请求。否则 Agent 的 Pod 如果忘了写 resources，调度器不会报错，但无法准确计算配额占用，集群审计时也看不到真实用量。

apiVersion: v1 kind: LimitRange metadata: name: agent-default-limit namespace: ai-agent-prod spec: limits: - default: nvidia.com/gpu: 1 cpu: "2" memory: "8Gi" defaultRequest: nvidia.com/gpu: 1 cpu: "500m" memory: "1Gi" type: Container

注意两点。第一，ResourceQuota 只限制超卖数，不限制单个 Docker 容器内的进程行为。如果 Agent 在一个 Pod 里通过多线程并发申请显存，而显存又是在进程内直接分配，Kubernetes 配额并不能完全阻止显存溢出，需要配合 NVIDIA 容器的显存限制。第二，给 Agent 分配 GPU 时尽量使用整卡分配，不要用 GPU 时间片或 MIG 切分，否则显存隔离问题更复杂，排查成本更高。

3.2 沙箱隔离：Agent 不应该看到宿主机和云平台元数据

Agent 的运行环境必须被认为是不可信的。容器逃逸风险、恶意 prompt injection、依赖包漏洞都可能导致 Agent 在运行时执行意外的代码。如果能访问宿主机资源，后果会从“算力浪费”升级为“基础设施被控制”。

最基本的三条硬约束：

• 不要以 root 身份运行容器。镜像内指定非 root 用户，并在 SecurityContext 中设置 runAsNonRoot 和 drop 能力。
• 不要挂载 Docker Socket、/proc、/sys 等敏感路径。Agent 不需要访问宿主机 Docker 守护进程，也不需要修改内核参数。
• 不要直接放行云平台元数据服务 IP（例如 169.254.169.254）。Agent 如果拿到元数据服务访问权限，可能获取临时凭据进而申请新的 GPU 实例。

在 Kubernetes 里，可以这样配置 PodSecurityContext：

apiVersion: v1 kind: Pod metadata: name: ai-agent-example namespace: ai-agent-prod spec: securityContext: runAsNonRoot: true runAsUser: 10001 seccompProfile: type: RuntimeDefault containers: - name: agent image: registry.example.com/ai-agent:1.4.2 resources: limits: nvidia.com/gpu: 1 cpu: "2" memory: "8Gi" securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL

readOnlyRootFilesystem 会让容器根文件系统只读，Agent 要写日志时需要挂载单独的 emptyDir 或持久化卷。这可能在改造初期带来一点工作量，但它能显著降低恶意代码篡改二进制和配置的风险。

对于更严格的隔离需求，可以考虑基于 Kata Containers 或 Firecracker 的微虚拟机运行时。它相当于在容器外面再加一层虚拟机壳，Agent 即使突破了容器的权限限制，也没有宿主机内核权限。代价是启动速度变慢、资源 overhead 增加，所以要根据业务对隔离等级的要求权衡。

3.3 任务超时、重试上限和并发控制是最后一层兜底

即使身份认证、配额、沙箱都做了，Agent 自身的代码 bug 依然可能导致死循环。因此平台上必须提供任务级的三项硬指标：单次任务最大执行时长、最大重试次数、最大并发子任务数。

对于单次任务时长，可以在 Agent 的调度器入口做检查。下面是一段 Python 伪代码，表示一个 Agent 任务在执行前会先声明自己的预算。

class AgentTask: def __init__(self, task_id: str, owner: str, max_duration_seconds: int = 1800): self.task_id = task_id self.owner = owner self.max_duration_seconds = max_duration_seconds self.start_time = None def start(self): self.start_time = time.time() def over_budget(self) -> bool: return time.time() - self.start_time > self.max_duration_seconds

调度器在每轮 Agent 循环中检查 over_budget，一旦超时就终止任务，并记录终止原因。类似逻辑也用于重试控制：

MAX_RETRY = 3 retry_count = 0 while retry_count < MAX_RETRY: try: result = call_model_api(prompt) break except ApiTimeoutError: retry_count += 1 logging.warning("model api timeout, retry %d", retry_count) else: raise AgentTaskFailed("model api retry limit exceeded")

并发控制通常放在平台侧，不要只在业务代码里写信号量。平台可以对每个 Agent 身份、每个命名空间做并发任务数统计，超过阈值后新的任务请求直接进入等待队列，而不是立即创建容器。这样即使业务代码里忘记限制并发，平台也能拦住。

4. 从现象到根因：失控 Agent 的排查链路

4.1 现象：算力利用率异常上涨，账单项突涨

多数失控 Agent 事件首先被监控或账单暴露。典型现象包括：

• 集群 GPU 利用率从 20% 突然冲到 90% 以上，且持续超过几个小时。
• 某个命名空间或某个账号的 GPU 实例数量快速增加。
• 推理服务的响应时间变长，同一节点上的其他业务容器开始 CPU throttling。
• 成本报表中某个 Agent 任务的费用异常，通常是任务级费用超出预估的 5 倍以上。
• 任务日志中出现大量重复的 “timeout” 或 “retry” 关键字。

这些现象本身不具有唯一性。GPU 利用率高也可能是正常训练任务，实例数增加也可能是业务扩容。所以要先用身份维度和任务维度区分：是哪个账号、哪个任务 ID、哪个容器镜像导致的资源增长。如果这些问题不能在监控页面上回答，说明可观测性建设还不完整，首要任务不是优化代码，而是补齐标签。

4.2 检查顺序：先看身份、再看调度、最后看代码

遇到可疑资源抢占时，建议按这个顺序排查，不要一上来就登录节点 kill 进程。盲目 kill 会导致任务状态不一致，也拿不到故障现场。

第一步，确认资源增长来源。查询监控平台中 GPU 利用率 Top 容器，拿到命名空间、Pod 名称、Owner 标签、镜像名称、任务 ID。如果监控系统没有这些信息，立即补上，否则后续所有排查都是盲猜。

第二步，确认身份是否异常。检查该 Pod 使用的 ServiceAccount 是否有权限创建新 Pod、申请 GPU、读取云平台 API。如果权限过大，说明 Agent 可能通过权限提升路径自建资源。如果权限正常，继续下一步。

第三步，确认调度器行为。查看该命名空间的 ResourceQuota 是否生效，已经在运行的 Pod 数量是否到达配额上限。如果 Pod 数量远小于配额上限但 GPU 利用率很高，说明问题出在单个 Agent 的显存使用或线程模型上。

第四步，查看 Agent 日志。搜索 retry、timeout、loop、error 等关键词，统计相同错误日志的出现频率。如果同一错误每分钟出现几十次，基本可以断定任务进入了死循环。

第五步，确认代码行为。拉取 Agent 镜像对应源码，重点看三处：模型调用的重试逻辑是否设置最大次数、任务是否声明最大执行时长、子任务生成是否有并发上限。

第五步不要在压力态下做。紧急处理时，先停掉可疑任务，保存日志和监控截图，再离线分析代码。

4.3 排查命令与日志关键字

在 Kubernetes 环境中，可以用 kubectl 快速定位可疑工作负载：

kubectl get pods -n ai-agent-prod --field-selector=status.phase=Running -o wide kubectl top pods -n ai-agent-prod --sort-by=cpu kubectl describe pod <pod-name> -n ai-agent-prod

kubectl describe 可以查看 Pod 的 Request、Limit、调度失败原因、容器重启次数。如果容器反复重启但在 30 秒内又申请 GPU，说明可能存在健康检查失败加无限重启的组合问题。

查看 GPU 显存使用，可以用 NVIDIA 官方工具：

nvidia-smi nvidia-smi dmon -s pucvmet nvidia-smi --query-gpu=index,utilization.gpu,memory.used,memory.total --format=csv

dmon 的 -s pucvmet 参数同时输出电源、使用率、时钟、显存、温度等指标，适合观察 Agent 是否把显存打满。

日志关键字清单：

日志采集本身要防止被 Agent 日志淹没。建议对每条 Agent 日志增加 task_id、namespace、pod_name 标签，并关闭不重要的 debug 日志输出。否则发生问题时，日志检索会非常慢，影响止损速度。

5. 生产环境下的纵深防御，与学习环境的差异

5.1 账号和密钥管理：平台级 API Key 必须拆分成细粒度凭证

学习环境里，开发者经常把 API Key 写在环境变量或 .env 文件中。生产环境不能这样。生产环境的密钥管理要满足几个硬要求：

• 密钥集中存储在密钥管理服务中，例如 Kubernetes Secret、云厂商 KMS、HashiCorp Vault。
• 密钥轮换必须有自动化流程，不能靠人工修改。
• Agent 使用的密钥要和用户个人密钥隔离，避免一人泄露导致全平台受影响。

热词中提到的“src网络安全挖洞平台”“网络安全学习路线”说明很多网络安全学习者会关注漏洞挖掘，其中一大类漏洞就是硬编码密钥。如果 Agent 镜像里残留平台 API Key，镜像被传到一个公共仓库后，等于把算力池的钥匙公开。这一点在 neocloud 场景尤其危险，因为算力是有成本的高价值资源。

推荐做法是：在 CI 阶段使用密钥扫描工具检查镜像内是否包含密钥特征；运行时使用密钥管理服务动态注入，而不是把密钥烧进镜像层；对外部服务调用使用短期令牌，令牌过期后由平台自动刷新，同时记录刷新动作。

5.2 Agent 运行时防护：运行时安全扫描与行为基线

Agent 的依赖库更新速度很快，框架版本升级可能引入新的 CVE，因此生产环境需要定期做镜像漏洞扫描，并在扫描出高危漏洞后建立阻断发布流程。

除了漏洞扫描，还需要行为基线。所谓基线，就是对同一个 Agent 的正常行为做统计：它平时调用哪些 API、写哪些路径、申请多少 GPU、运行多长时间。当某个 Agent 突然开始请求外部未知域名，或者尝试读取 /etc/passwd、访问元数据服务，行为基线就会触发告警。

实现行为基线的方式可以从轻到重：

• 在容器内使用 falco 检测系统调用，对 execve、open、connect 等关键调用做规则匹配。
• 在 API 网关注入审计中间件，记录 Agent 每次工具调用的目标服务和请求参数。
• 在集群层使用网络策略，限制 Agent 只能访问白名单内的服务，禁止访问外部互联网。

网络策略是容易被忽略的一层。很多 Agent 依赖外部 API，但生产 Agent 的访问出口通常是可控的。给每个命名空间显式声明 egress 白名单，能阻断不少恶意下载或数据外传行为。

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: agent-egress-policy namespace: ai-agent-prod spec: podSelector: matchLabels: app: ai-agent policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: name: model-inference ports: - protocol: TCP port: 443

这段策略表示 ai-agent-prod 命名空间中带 app=ai-agent 标签的 Pod，只能访问 model-inference 命名空间内 Service 的 443 端口。如果 Agent 还需要访问对象存储或外部模型 API，则要按实际依赖增加目的地规则。

5.3 学习环境与生产环境的安全差异速查

这张表可以作为发布前的执行清单。每当新版 Agent 要上线时，先逐项核对，缺哪一项就补哪一项，不要等到事故发生再做。

6. 常见配置失误与预防建议

6.1 失误一：只限额不阻断，配额形同虚设

很多团队配置了 ResourceQuota，但 Agent 任务超出配额后只是报错，调度系统没有把错误映射成“任务终止”，而是让上层继续重试。结果配额限制了资源并行数，却放大了请求失败后的重试风暴。

观察点：如果监控里出现大量 Quota exceeded 错误，且每次错误后 Task 都会重新创建 Pod，说明平台的错误处理逻辑有问题。正确做法是：超过配额的任务进入等待队列，而不是反复创建新 Pod；等待队列也要设置最大等待时长，超时后终止整个任务。

6.2 失误二：Agent 无状态，崩溃后自动重建导致雪崩

Agent 任务不像普通无状态微服务，它内部保存了上下文、工具调用历史、中间结果。如果实现时把这些状态放在内存，而不做持久化，当容器崩溃后调度器会自动重建 Pod，新 Pod 从零开始，可能重复发起同样的推理请求和文件下载，导致资源翻倍。

解决方向：

• 把 Agent 中间状态写入对象存储或 Redis，Pod 重建后能恢复断点。
• 为每个任务设置唯一执行 ID，在外部服务调用中带上该 ID，外部服务做幂等去重。
• 对无法自动恢复的任务，直接标记为失败并交由人工处理，不要自动重启。

依赖自动重启解决所有问题，是 Agent 资源失控的常见温床。

6.3 失误三：显存监控只盯显卡温度，忽略了内存和句柄

有些团队在 GPU 节点只监控节点级指标，比如 GPU 温度和整体利用率。但 Agent 失控时，最先上升的往往是显存分配数量、容器线程数、文件句柄数。如果这些指标不上报，你会在 GPU 利用率已经因为被打满而短暂下降时才发现异常，失去了最早的干预机会。

建议每 30 秒采集以下指标并关联到任务标签：

• nvidia-smi 返回的显存已用、显存总容量、电源功率。
• 容器层面的进程线程数、打开文件数、内存 RSS。
• Agent 任务级别的重试次数、单次推理平均耗时、外部 API 调用错误码。

6.4 可复用的排查和加固清单

最后整理一份可以在新环境里快速执行的清单。它不覆盖所有平台细节，但适用于大多数基于 Kubernetes 和 NVIDIA GPU 的 neocloud 环境。

• [ ] 确认每个 Agent 任务有唯一身份，日志和监控可按该身份聚合。
• [ ] 确认平台 API Key 未硬编码在镜像、代码仓库或环境变量中。
• [ ] 确认命名空间已配置 GPU ResourceQuota 和 LimitRange。
• [ ] 确认 Agent 容器以非 root 用户运行，root 文件系统只读，丢失所有 Linux Capability。
• [ ] 确认未挂载 Docker Socket、主机敏感目录、云元数据服务地址。
• [ ] 确认网络策略限制 Agent 只能访问白名单服务。
• [ ] 确认 Agent 的单次任务时长、最大重试次数、最大并发子任务数在平台侧有配置。
• [ ] 确认 GPU 显存、CPU 内存、网络 IO、外部 API 错误率均已接入告警。
• [ ] 确认日志包含 task_id、namespace、pod_name、错误码，且关键日志可按字段检索。
• [ ] 确认可疑任务终止后，平台不会自动重建该任务。
• [ ] 确认镜像上线前经过漏洞扫描，高危漏洞未修复时阻断发布。
• [ ] 确认异常任务终止和人工介入的流程已经演练过至少一次。

这份清单既可以用在 Agent 服务上线前的安全评审，也可以作为危机发生后的复盘依据。实际项目里，Agent 安全很难一步到位，但把身份、配额、沙箱、超时、监控、清单这些基础工作做扎实，就能避免绝大多数“Agent 抢占算力”式事故。后续再扩展时，可以继续关注 Agent 框架自身的供应链安全、模型输出内容过滤、跨租户数据隔离等方向，但前提始终是先把资源边界和权限边界守住。