L1 · Agent System 需要怎样的运行环境？ - Infrastructure
所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：02 · Agent System 是如何构建和运行的？ - Technical Architecture
文档类型：基础设施技术原理、架构选型与工程实践研究
版本：v1.2
更新日期：2026 年 10 月 28 日
核心问题：Agent System 的任务执行、模型调用、工具运行和状态交互需要哪些底层计算、操作系统、进程、网络与隔离能力？如何根据单机原型、长期运行服务、并发任务及高风险工具执行等不同需求，选择本地、虚拟机、容器、托管计算或集群环境，并以可检验的资源、故障、安全和成本约束完成基础设施设计？
专题导读
本篇属 Technical Architecture。Agent System 不会因为接入大语言模型就自动获得稳定的运行环境。一个 Agent 可能在模型返回工具调用之后启动子进程、访问文件系统、请求外部 API、等待数小时的人类审批，或因机器重启而中断。基础设施层要解决的是：这些计算究竟在哪里执行、由谁提供 CPU/内存/磁盘/网络、进程如何被隔离与终止、失败后哪些事实仍然存在，以及系统在给定资源和风险约束下能否持续运行。
本篇是 03 · Agent System → 02 · Agent System 是如何构建和运行的？ - Technical Architecture 的第一篇，承接 Fundamentals 对系统边界、组件、执行语义和架构原则的研究。它研究 L1 Infrastructure 的责任和实现选型，而不是把所有 Agent System 都预设为 Kubernetes 集群。对于一个仅调用云端模型 API 的个人研究 Agent，普通笔记本和 Python 进程可能足够；对于需要运行不可信代码、并发处理任务、承诺可用性的团队服务，则需要明确的进程监督、网络策略、资源限额和故障域设计。两者都属于 Agent System，但基础设施要求不同。
全文贯穿“技术研究助理 Agent System”：先给出基础设施需求模型，再解释计算与进程、操作系统与容器、网络与身份、存储边界、弹性与故障、安全隔离、部署拓扑和验收方法。特别区分基础设施提供的能力与 L2 平台服务、L3 模型服务、L4 Agent Engine、L5 编排和 H 系列横向治理能力；同一技术可能跨层，但每篇的研究问题不同。
一、L1 的定位：运行资源与执行边界
1.1 L1 提供什么，不提供什么
L1 提供底层资源及其运行约束：计算资源、进程或容器运行环境、操作系统接口、网络连通性、磁盘与基础持久化介质、资源隔离、节点生命周期、基础设施层的健康与故障信号。它可以来自开发者电脑、物理服务器、虚拟机、容器宿主机、云托管计算或集群。
L1 不直接决定 Agent 采用何种推理策略，不定义工具 Schema，不负责选择模型，不替代业务状态机，也不保证端到端任务恢复。即使容器能自动重启，正在进行的 Run 也可能丢失；即使磁盘持久化，外部邮件发送也可能在崩溃前已经发生。是否能安全恢复，需要 L1 与 L2 状态服务、L4 执行器及 H4/H7 的协议共同保证。
| 责任 | L1 典型供给 | 不应误认为 |
|---|---|---|
| 计算 | CPU、内存、GPU、执行实例 | Agent 推理算法 |
| 运行 | OS、进程、容器、VM | 任务工作流状态机 |
| 网络 | DNS、路由、连接、TLS 基础设施 | 模型路由策略 |
| 存储介质 | 本地卷、块设备、对象存储入口 | 业务数据模型与一致性协议 |
| 隔离 | 用户、命名空间、配额、沙箱 | Prompt 安全或完整授权体系 |
| 故障域 | 主机、区域、实例生命周期 | 端到端恰好一次执行 |
1.2 必要条件与可选增强
最小 Agent System 只需要一个能执行其程序并连接所需依赖的运行环境。它可以没有独立数据库、容器编排、GPU、消息队列或公网入口。引入这些组件必须由任务合同驱动：并发、数据保留、执行时长、隔离、延迟、成本或可用性目标。反过来，如果 Agent 可以执行任意用户提交代码，那么仅靠“在同一 Python 进程内调用函数”通常不足以构成可信隔离。
1.3 从任务约束推导基础设施
先写下可测量的需求：单任务最大执行时长、峰值并发 Run 数、每 Run 的内存与 CPU、工具子进程数、模型部署方式、数据驻留与保留、可接受中断时间、是否有不可逆副作用、外部网络访问范围，以及成本上限。然后决定部署形态；不要先选 Kubernetes 再倒推需求。
例如，一个只在本地读取授权文档、调用云端 LLM、生成 Markdown 的个人 Agent，可以采用“单机进程 + 本地目录 + 受控出站网络”；如果任务可能跨夜执行，至少需要进程监督、状态检查点及可恢复的执行协议。若同时为多个组织执行代码，则必须进一步考虑租户隔离、独立工作目录、凭据边界和工具执行沙箱。
1.4 从章节总纲到 L1：六层架构的交付关系
Technical Architecture 的 L1 - L6 是技术责任分层，不是强制要求六套独立进程或六个微服务。L1 的交付物是可运行、可隔离、可连接、可度量的基础资源及其运行约束；L2 将这些资源封装为数据库、消息队列、缓存等软件服务；L3 管理模型服务的接入与调用；L4 实现 Agent 的执行循环；L5 处理任务依赖与多 Agent 协作；L6 对外提供产品和应用接口。横向的 H 系列 负责贯穿这些层的安全、状态、可观测性和运维治理。
以技术研究助理为例：运行在笔记本上的 Python 进程和本地工作目录属于 L1；SQLite 的表结构、事务和查询接口属于 L2；模型 API 适配器属于 L3；Run/Step 的执行逻辑属于 L4；多个研究角色之间的任务交接属于 L5；研究任务提交页面属于 L6。一个实际程序可以同时实现多个层的职责，但故障诊断时必须能识别责任边界。
二、计算模型：CPU、内存、GPU 与 I/O
2.1 区分模型推理计算和 Agent 运行计算
Agent System 的资源需求可分为：①模型推理（可能发生在远端 API）；② Agent 控制循环（解析模型输出、规划、状态变更）；③工具工作负载（浏览器、代码执行、文档转换、检索）；④数据处理与网络 I/O。使用远端模型 API 并不代表本地运行零成本：浏览器自动化、PDF 解析、嵌入生成、文件转换或多任务并发可能成为真正的瓶颈。
CPU 密集型任务（大规模解析、压缩、索引）关注核心数和可并行性；内存密集型任务（浏览器、多文档上下文）关注峰值 RSS 与 OOM 风险；I/O 密集型任务（网络 API、数据库访问）关注并发连接、排队和超时；GPU 密集型任务（本地模型推理、视觉模型）还需要显存、驱动、运行时兼容性和批处理策略。不能把这些资源需求简单用“每个 Agent 占一个 CPU”估算。
2.2 容量估算的基本关系
对稳定到达、稳定完成且统计条件满足的工作负载，Little 定律提供近似关系：L = λ × W，其中 L 为系统平均在途任务数、λ 为平均到达率、W 为平均停留时间。它用于理解并发规模，不直接给出 CPU 或容器数量。如果一个 Run 的大部分时间在等待远端模型，那么“在途 Run 数”与“同时消耗 CPU 的任务数”差异很大。
简单容量规划可以分两层：首先估算 峰值在途任务 ≈ 峰值到达率 × 平均任务耗时；然后按阶段测量 CPU、内存、浏览器实例、连接数和外部 API 配额。应加入突发系数和尾部延迟评估，但系数来自实际负载测试而非通用常数。对于长尾任务，平均值不足以保证 P95/P99 性能。
2.3 资源限制不是业务预算
容器 CPU quota、memory limit、进程数限制和超时可保护宿主机；Token 预算、模型费用、工具调用次数和单任务业务限额则属于上层可信控制。一个 Agent 即使只消耗少量 CPU，也可能通过高频云模型调用产生高费用。基础设施限额与业务预算需要并行设置。
三、操作系统、进程与执行单元
3.1 进程、线程、协程、容器不是同一概念
进程提供独立虚拟地址空间和操作系统级资源边界；线程共享进程内存；协程是程序级调度机制，适合管理大量等待中的 I/O；容器通常通过内核隔离机制和资源控制组合提供进程运行环境；虚拟机拥有独立客户机操作系统与虚拟硬件边界。它们是不同层次的机制，不能作为互斥的四种“Agent 类型”。
Agent 控制循环可以是一个异步进程；每个工具调用可以是同进程函数、子进程、独立容器或远程服务。选择依据是信任等级、执行时长、依赖冲突、资源消耗和故障隔离，而不是工具数量。
3.2 进程监督与退出语义
长期运行服务需要明确：进程由谁启动、退出码如何解释、异常后是否重启、停止时是否发送终止信号、等待多久后强制结束、未完成任务如何标记。Linux 环境可使用 systemd；容器环境可依赖容器运行时或编排系统管理进程生命周期。但自动重启只恢复进程，不自动恢复业务 Run。
应区分：进程存活、服务可接收请求、执行器可取得任务、外部依赖可用。仅有 TCP 端口打开或健康接口返回 200，不足以证明 Agent 能完成真实任务。
3.3 任务取消和子进程树
Agent 常通过工具启动子进程。取消 Run 时，必须定义取消信号如何传播、子进程是否属于独立进程组、是否有超时后强制回收机制，以及工作目录和临时文件如何清理。只取消上层 asyncio.Task，不一定终止已经启动的浏览器、Shell 或外部 API 操作。
推荐的执行单元契约包含：run_id、execution_id、principal、resource_limits、deadline、working_directory、network_policy、cancellation_token、artifact_paths。这些字段是参考设计，并非通用标准接口。
四、容器、虚拟机与沙箱：隔离的实际含义
4.1 容器解决哪些问题
容器镜像有利于打包运行依赖、复制部署环境、限定文件系统视图和资源配额；它不是天然的强安全边界。容器通常共享宿主机内核，实际隔离效果取决于运行用户、capabilities、seccomp、AppArmor/SELinux、namespace、挂载、设备访问、网络策略及运行时配置。
尤其是让 Agent 执行生成代码时，不能仅凭“放进 Docker”就认为安全。应审查是否以 root 运行、是否挂载 Docker socket、是否暴露宿主机凭据、是否允许访问内网元数据服务、是否有资源与时间限制。对于高风险或不可信执行，可考虑独立 VM、微型虚拟机或经过专门设计的受限沙箱，并结合最小权限和出站网络控制。
4.2 部署隔离选型
| 运行形态 | 优点 | 主要代价或边界 |
|---|---|---|
| 本地进程 | 最易调试，启动成本低 | 环境差异与隔离较弱 |
| 单机容器 | 依赖可复制，易设资源限制 | 共享内核，需安全加固 |
| 虚拟机 | 客户机 OS 隔离较强 | 启动和资源开销较大 |
| 托管计算 | 减少主机维护负担 | 生命周期、超时和平台限制 |
| 容器集群 | 多节点调度与扩缩容 | 运维、网络与状态复杂度 |
该表是典型特性，不是绝对安全等级。具体安全性取决于实现与配置；某些托管沙箱可能提供比自行管理的 VM 更强的操作约束。
4.3 文件系统与工作目录
建议按 tenant_id/run_id/execution_id 或等效隔离标识组织临时目录，限制可读写路径，并为输出文件建立独立的交付流程。不要把整个宿主机家目录挂载给执行不可信工具的容器。需要持久保留的结果应在任务完成或检查点时转存到明确的持久化位置，并记录对象标识和校验信息。
五、网络：连通性、信任与外部依赖
5.1 出站依赖往往比入站更重要
研究 Agent 可能不需要公网入站端口，却需要访问模型 API、授权检索源、代码仓库和对象存储。网络设计应先列出允许的出站目标、DNS 需求、代理、TLS 验证、超时、连接池和重试边界。限制网络访问不是只靠 Prompt 中的“不要访问其他网站”，而是通过可信执行层与网络策略共同实施。
5.2 信任边界
至少区分四种网络身份：用户到应用、应用到模型服务、执行器到工具或数据源、沙箱到外部网络。凭据不应在这些边界间无条件传递。用户提供的 URL 不能直接等同于被授权访问的目标；执行器需要防范请求被重定向到内部地址、云实例元数据接口或其他受限资源。仅有域名白名单并不足以解决所有 DNS、重定向或代理问题。
5.3 超时、重试与幂等
网络调用可能在服务端已经执行成功、但客户端尚未收到响应时中断。此时“重试一次”可能重复外部副作用。对于写操作，应优先使用目标 API 支持的幂等键、操作 ID、状态查询或人工核验机制；不支持幂等的外部系统必须明确其不确定性与补偿策略。TCP 重连、HTTP 重试与业务级 exactly-once 不是同一保证。
六、持久化边界：基础设施能保存什么
6.1 本地盘、卷、对象存储与数据库的分工
L1 研究存储介质的持久性、可用性、吞吐、容量和故障域。L2 进一步研究数据库、对象存储服务、缓存、队列的语义和使用方式；H4 研究业务状态及恢复协议。一个容器的可写层可能在重建后消失；挂载持久卷能改善数据存活，但不能保证多步骤任务事务性，也不能保证数据永远不会损坏。
| 数据 | 典型保存位置 | 关键问题 |
|---|---|---|
| 临时工具输出 | 隔离工作目录 | 生命周期与清理 |
| 报告和附件 | 持久对象存储或受管目录 | 版本、校验、访问控制 |
| Run 检查点 | 事务性状态服务 | 原子提交、恢复点 |
| 工具执行记录 | 事件/审计存储 | 关联 ID、保留期 |
| 凭据 | Secret 管理机制 | 最小权限、轮换 |
6.2 故障恢复的两个边界
计算恢复：机器、容器或进程重新启动。任务恢复：系统能够根据可信状态确定哪些步骤已完成、哪些步骤可重做、哪些外部动作需要查询确认。前者由 L1 支持，后者依赖 L2、L4 与横向能力协作。没有检查点或事件协议，重启一个无状态容器可能只会重新开始整个任务。
七、四种典型基础设施拓扑
7.1 A：个人本地研究 Agent
用户 / CLI
│
本地 Agent 进程 ───→ 云端模型 API
│
├──→ 授权网页 / 检索 API
└──→ 本地受限资料目录与报告目录适用：低并发、可信个人使用、允许人工重启。关键措施：虚拟环境或容器固定依赖、最小凭据权限、文件备份、请求超时、明确中断后任务处理方式。无需因为“是 Agent”而部署集群。
7.2 B：单机长期运行服务
用户 / API
│
反向代理 ──→ Agent 服务进程
│
工具子进程 / 沙箱
│
持久状态与成果存储适用：小团队、低至中等并发、希望持续可用。新增关注：进程监督、健康检查、资源限制、持久化、备份、凭据管理、任务取消和故障恢复。是否采用容器不改变业务恢复协议的必要性。
7.3 C：多工作节点的异步任务服务
应用入口 → 任务提交与状态服务
│
任务队列 / 调度
│
┌───────┴────────┐
Worker A Worker B
│ │
工具沙箱 工具沙箱
└───────┬─────────┘
持久状态 / 成果适用：大量任务、不同任务耗时差异大、需要隔离故障。关键挑战不是“加 Worker”本身，而是任务租约、重复领取、任务超时、幂等、背压、队列积压和版本兼容。这些语义主要由上层队列、编排和执行器实现，L1 提供节点与资源承载。
7.4 D：不可信代码执行隔离
Agent 控制面（可信）
│ 授权后的执行请求
▼
沙箱调度器 / 执行网关
│
每任务隔离 VM / 受限容器
│
受控网络 + 受限挂载 + 资源/时间上限
│
产物扫描、校验、导出适用：Agent 可能执行模型生成代码、用户脚本或不可信第三方工具。关键原则：决策进程与高风险执行环境分离；不能让沙箱持有控制面高权限凭据，也不能将沙箱输出自动当成可信指令。
八、基础设施选型：由工作负载驱动，而非由技术流行度驱动
8.1 决策顺序
首先确认模型在哪里推理。如果全部使用云端 API，优先测量 Agent 控制进程和工具的资源；如果本地部署模型，再评估 GPU/显存、驱动、推理引擎和模型服务吞吐。其次确认工具是否可信，决定同进程、子进程、容器还是 VM。再次确认任务执行时长、并发和恢复目标，决定是否需要长期服务、队列和多节点。最后根据团队运维能力、成本与合规要求选择云或本地。
8.2 不应机械套用的经验
- “多 Agent 一定需要分布式部署”：错误。多个 Agent 可以在一个进程中协调。
- “使用 Kubernetes 就具备高可用”：错误。无状态副本、数据库、队列、跨节点故障与业务恢复均需分别设计。
- “Serverless 一定更便宜”：不一定。长时间运行、频繁冷启动或特殊依赖可能改变成本结构。
- “有 GPU 就应本地推理”：不一定。需要综合模型质量、吞吐、显存、运维、隐私和调用成本。
- “容器能防止提示注入”：错误。提示注入属于模型与工具信任边界问题；容器仅能限制部分执行后果。
8.3 成本模型
基础设施成本可粗分为：计算实例 + 存储 + 网络流量 + 监控日志 + 运维。完整 Agent 单任务成本还包含 模型推理 + 外部工具 API + 人工审核 + 失败重试。比较方案时，应同时报告每次尝试成本、成功任务摊销成本和峰值容量成本。云价格、配额和产品限制随地区及时间变化，本篇不提供未经实时核验的价格表。
8.4 贯穿案例：技术研究助理的基础设施选型推导
假设研究助理接受问题、访问获准的资料源、调用云端模型、执行本地文档解析并生成 Markdown 报告。基础设施选型不应从“是否使用 Kubernetes”开始，而应从以下四类约束推导：任务数量与同时运行数、单次解析的峰值内存、工具执行是否可信、任务中断后允许丢失多少进度。
方案 A：个人研究原型。 假设仅一名使用者、任务可手动重试、工具仅访问受信任文件，可先选择单机 Python 进程、受限工作目录和定期保存的结果文件。这里不需要独立的消息队列，也不能因为采用 SQLite 就把系统称为“分布式持久执行”。最低验收证据包括可重复启动、依赖版本记录、异常退出后结果文件状态明确，以及外部凭据不写入交付物。
方案 B：团队异步研究服务。 当任务可能运行数十分钟、用户需要查看排队状态、进程退出后不能丢失已接受的任务时，基础设施应提供可监督的 Worker 进程、稳定网络、持久卷或托管存储、实例健康信号和受限资源。队列的确认语义、Run 状态机与恢复协议属于 L2/L4/H4，不能因为 L1 提供了持久磁盘就视为已经实现。
方案 C：允许生成代码并执行。 当模型可能提出 Shell/Python 代码时，风险性质发生变化，即使仍然只有一名用户，也应考虑独立的低权限执行身份、沙箱/VM、隔离的工作目录、无默认宿主凭据、出站访问控制和硬超时。隔离强度必须根据威胁模型选择；普通容器配置不能被默认视为对恶意代码的充分安全边界。
| 决策因素 | 个人原型 | 团队服务 | 不可信代码执行 |
|---|---|---|---|
| 计算承载 | 单机进程 | 受监督 Worker | 独立隔离实例 |
| 状态要求 | 可接受手动恢复 | 需可恢复任务 | 需保留审计与结果 |
| 主要风险 | 环境不可复现 | 任务丢失、积压 | 越权与宿主逃逸 |
| 验收重点 | 启动与文件完整性 | 故障、排队、资源 | 权限、网络、超时 |
这三种方案是条件化的架构示例，不是经过负载基准证明的性能排名。应在测量实际任务的峰值资源、到达率和恢复目标后，再决定是否拆分服务、增加节点或采用托管执行。
九、可验证的工程实践：运行环境验收
9.1 从需求到验收证据
| 风险或要求 | 验证方法 | 通过依据 |
|---|---|---|
| 内存失控 | 对工具注入高内存负载 | 超限被隔离，宿主机不失稳 |
| 进程崩溃 | 强制终止 Worker | Run 状态可诊断，恢复符合契约 |
| 工具超时 | 启动超时子进程 | 子进程被回收，无孤儿进程 |
| 出站越权 | 请求未授权目标 | 网络/网关拒绝并留证据 |
| 凭据隔离 | 从沙箱尝试读取凭据 | 无权访问控制面密钥 |
| 任务重复 | 模拟重复领取 | 副作用不超出定义的保证 |
| 磁盘耗尽 | 注入大量临时文件 | 配额生效，失败可诊断 |
| 并发突发 | 负载测试 | 延迟、积压和资源符合目标 |
“通过依据”必须在项目中进一步量化，例如 P95 任务等待时长、内存上限、故障恢复时间和允许丢失的状态窗口。表中只给出验收设计方法，不代表已经运行实验。
9.2 最小 Linux 容器加固示意
以下是配置思路示意，不是可直接照搬的生产安全基线：使用非 root 用户、只读根文件系统、只挂载必要工作目录、丢弃不需要的 Linux capabilities、限制 CPU/内存/进程数、禁用提权、配置 seccomp/LSM、限制出站网络并设置工具执行超时。具体参数必须结合运行时和工具依赖验证；例如某些浏览器自动化工具需要额外共享内存或系统调用，不能盲目禁用所有能力。
9.3 实施顺序与阶段性验收
阶段 0：单机可复现。 固定 Python/Node 版本与依赖，写清启动命令、环境变量、目录权限，证明任务能在新环境中重现。阶段 1：运行受控。 引入进程监督、资源限额、超时和最小网络权限，证明工具异常不会拖垮主进程。阶段 2：状态可恢复。 接入持久状态和明确的恢复协议，验证进程崩溃与重复执行。阶段 3：并发可扩展。 在有实测需求时引入队列、Worker 和水平扩展，并验证背压与任务所有权。阶段 4：风险可隔离。 对不可信工具执行建立独立沙箱、身份边界、审计与产物导出控制。
阶段是建议性工程路径，不代表所有系统必须依次部署五层设施。高风险代码执行系统即使规模很小，也应优先处理隔离，而不是等到“阶段 4”。
9.4 可执行的验证步骤与证据记录
以下步骤用于设计测试，本文未实际执行。在隔离测试环境中运行，避免在生产宿主机上进行破坏性故障注入。
测试 A：Worker 崩溃与恢复。 (1) 提交具有唯一 task_id 的测试任务；(2) 记录其已接受状态、当前 run_id 与外部副作用标识；(3) 在指定 Step 处终止 Worker；(4) 由监督机制重新启动进程；(5) 检查任务是否被重新领取、从何处恢复，以及是否重复写入交付物。保留进程退出码、任务事件、恢复耗时和副作用去重记录。L1 只能证明重启与资源承载，端到端恢复需与 L2/L4 联合验收。
测试 B：内存与进程数限制。 (1) 在受控容器或 cgroup 内设置明确内存及进程上限；(2) 使用专用测试程序逐步增加内存占用并创建子进程；(3) 观察限制是否生效、宿主是否受影响；(4) 检查退出码、内核 OOM 事件与资源指标。阈值应由具体任务画像确定，不能将示例数值当成通用安全配置。
测试 C：子进程取消。 (1) 启动一个会派生子进程并持续等待的测试工具；(2) 触发任务取消或超时；(3) 检查进程组/子进程树是否被正确终止；(4) 验证文件句柄、临时文件与锁是否被清理。记录 PID、进程树快照、取消时延及残留资源。跨平台的信号与进程组行为不同，需按操作系统分别测试。
测试 D：凭据与网络隔离。 (1) 为工具执行环境提供不包含控制面密钥的最小身份；(2) 尝试读取未挂载的凭据路径；(3) 请求允许与禁止的出站目标；(4) 检查实际访问结果与拒绝日志。必须验证真实访问是否被拒绝，不能只凭模型回复或网络策略配置文本认定安全。
测试 E：持久化与产物交付。 (1) 在临时目录和正式持久化位置分别生成标识文件；(2) 重建执行实例；(3) 检查哪些文件仍然存在；(4) 通过上层服务验证正式产物的读取与完整性。此测试用于揭示存储生命周期差异，不替代数据库事务或备份恢复测试。
建议每项实验记录：test_id、运行环境及版本、配置摘要、预期不变量、注入动作、实际事件、通过/失败结论、证据文件位置和限制说明。没有这些运行证据时，应标记为“待验证”，不能写成“已通过”。
十、与 L2 - L6 及横向能力的接口
| 相邻领域 | L1 提供 | 对方负责 |
|---|---|---|
| L2 Platform Services | 网络、磁盘、计算与故障域 | 数据库、队列、缓存、对象存储语义 |
| L3 Model Services | 推理服务计算与连接环境 | 模型接入、推理协议、路由与服务质量 |
| L4 Agent Engine | 进程、资源、工具执行承载 | 决策循环、Run/Step 语义、工具协议 |
| L5 Orchestration | Worker 承载与资源边界 | 任务依赖、调度规则、协作协议 |
| L6 Application | 应用服务运行与网络入口 | 用户交互、业务 API 与交付体验 |
| H2/H4/H7/H11 | 基础设施隔离和运行信号 | 端到端安全、状态、可靠性和运维治理 |
同一系统中可能没有清晰分开的部署组件，但职责仍然存在。例如 L2 的数据库可以是本地 SQLite 文件，L4 Agent Engine 可以和应用接口运行在同一进程。纵向分层是分析框架，不是强制部署图。
十一、常见失败模式与架构复盘
失败模式 A：把容器重启当成任务恢复。 Worker 崩溃后容器重启，Run 从头执行并重复发送通知。根因是缺少持久执行状态、外部副作用幂等协议，而不是重启策略配置不够激进。
失败模式 B：把工具当成普通函数。 模型生成的 Shell 命令直接在宿主机高权限执行。根因是没有将模型决策与可信授权/隔离执行分开。
失败模式 C：无限扩容掩盖外部瓶颈。 Worker 增加后，模型 API 限流和数据库连接耗尽更严重。根因是只观察 CPU，而没有测量端到端资源与背压。
失败模式 D：临时目录承担持久交付。 容器更新后报告消失。根因是混淆临时文件与正式成果存储，未定义持久化与备份策略。
失败模式 E：共享密钥跨越沙箱边界。 不可信代码可以读取模型 API Key 或数据库凭据。根因是执行身份和凭据范围设计错误。
十二、研究结论
Agent System 的基础设施不是固定技术栈，而是一组由任务合同决定的运行资源、隔离边界和故障承载能力。最小系统可以运行在一台个人电脑上；复杂系统可能需要多节点调度、持久存储和强隔离，但增加技术组件并不自动提高系统质量。判断基础设施是否合格，应看它能否支持实际任务所需的计算、网络、存储、进程控制、故障边界与安全约束，并留下可核验的运行证据。
本篇最重要的五项判断是：第一，区分 Agent 控制计算、模型推理计算与工具负载；第二，区分进程重启和业务 Run 恢复；第三，区分容器打包能力与可信安全隔离；第四，以真实并发和故障数据决定扩缩容，而不是根据 Agent 数量猜测；第五，基础设施必须与上层状态协议、授权机制和副作用控制协同设计。
下一专题 「L2 · Agent System 需要哪些基础软件服务？ - Platform Services」 将研究数据库、对象存储、缓存、队列、服务发现、配置和其他通用软件服务的职责、接口、语义与选型方法，进一步回答基础设施之上的系统支撑能力如何组织。
附录 A：参考文献与原始资料入口
以下优先列出规范、官方文档和可长期追溯的技术入口；部分文档会随版本演进，实际部署应核对所用版本与发行说明。本篇没有声称对所有链接进行 2026 年 10 月 28 日的逐页实时核验。
- The Linux kernel documentation：cgroup v2 资源控制、namespace、进程与内核接口。docs.kernel.org/admin-guide/cgroup-v2.html
- Docker Engine documentation：容器资源约束、运行时权限、文件系统与安全。docs.docker.com/engine/containers/resource_constraints ；docs.docker.com/engine/security
- Kubernetes documentation：Pod 生命周期、资源请求与限制、健康探针、调度与网络策略。kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle ；kubernetes.io/docs/concepts/configur...sources-containers ；kubernetes.io/docs/concepts/services-networking/network-policies
- systemd documentation：服务管理、退出、重启与资源控制。www.freedesktop.org/software/systemd...stemd.service.html
- OpenTelemetry documentation：基础可观测性、指标、日志与分布式追踪。opentelemetry.io/docs
- NIST SP 800-190, Application Container Security Guide：容器安全风险与防护框架。csrc.nist.gov/pubs/sp/800/190/final
- NIST SP 800-125, Guide to Security for Full Virtualization Technologies：虚拟化安全基础。csrc.nist.gov/pubs/sp/800/125/final
- AWS Well-Architected Framework：可靠性、性能效率、成本优化等架构质量属性的参考。docs.aws.amazon.com/wellarchitected/...ework/welcome.html
- Google SRE Book：服务可靠性、监测、容量与运维实践。sre.google/sre-book/table-of-contents
- Little, J. D. C. (1961), A Proof for the Queuing Formula: L = λW, Operations Research 9(3), 383 - 387。用于容量与在途任务的概念分析，不直接推导容器实例数。
- Temporal documentation：持久执行与工作流重放的参考实现；本篇仅用于理解“基础设施重启”和“业务执行恢复”的区别。docs.temporal.io
- LangGraph durable execution documentation：Agent 图执行持久化与恢复语义参考。docs.langchain.com/oss/python/langgraph/durable-execution
附录 B：研究证据、验证声明与适用边界
资料与结论类型。 Linux cgroup、Docker/Kubernetes 资源管理、虚拟化与容器隔离等属于可由官方技术资料核验的机制；L1 - L6 层级划分、四种拓扑、阶段实施路径、验收矩阵和执行单元字段属于本知识库组织的研究性参考模型，不是行业统一标准。
验证范围。 本篇未运行 Docker、Kubernetes、VM 或真实云服务的负载测试、故障注入、网络隔离实验，也未测量任何实际模型或工具的 CPU、内存、GPU、成本、延迟和恢复时间。文中的验收表是待执行的测试设计，不能被引用为已通过的工程验证。没有配套运行代码，因此不存在“测试通过数量”。
适用前提。 容器与 VM 的安全性取决于具体运行时、内核、权限和配置；托管服务的实例生命周期、超时、地域与价格依供应商而变；并发与容量公式只在满足相应统计前提时适用；跨服务外部副作用不能仅靠容器重启或网络重试获得 exactly-once 保证。
本次修订说明。 v1.2 已统一标题与所属章节的正式名称，补充六层责任衔接、贯穿案例和可执行的故障/隔离验收步骤；这些补充为研究分析及待执行的测试方案，未增加任何实际测试通过的声明。
后续证据计划。 实际建设 Agent System 时应补充：工作负载画像、资源采样、进程/子进程取消实验、崩溃恢复轨迹、重复投递与副作用测试、网络策略拒绝日志、沙箱权限检查、并发负载测试和成本账本。发布结论应注明运行环境、版本、测试样本与限制。