适用读者：要对 AI 基础设施做投入决策的架构师/技术负责人。
前置：S23-J01–J04、S22（Agent 工程）、S17（分布式）。
覆盖旧文：A-1988 → 49 点（Agent Infra：框架对比、Workflow vs Agent、MCP、Skills 与安全、沙箱要求与厂商方案；超节点；结论与参考资料）。
扩展点：E-S23-009（Agent 沙箱四要求的验收项）、E-S23-010（带宽需求与上下文长度的关系）。
上一篇：S23-J04 · TileLang：把数据流与调度解耦
下一篇：S23-X01 · 术语、指标与论文速查。
1. 一句话结论
AI Infra 的投入判断只有一条主线：先问"我的瓶颈在算力、带宽，还是在隔离与状态"。模型侧的优化（PD/AFD/TileLang）解决前两者，Agent Infra 解决第三者；超节点是"用带宽换延迟"的重资产选项，只有上下文/并发把互联压到极限时才划算。
| 你的症状 | 该投的方向 | 不该做的事 |
|---|---|---|
| 推理贵、TTFT/TPOT 差 | 分布式推理（J02）、量化与算子（J04） | 先买超节点 |
| 训练/推理互相拖累 | 训推分离（J03） | 堆更多同构卡 |
| Agent 任务跑不稳、代码不敢执行 | Agent Infra：沙箱 + 状态 + 审计 | 用普通容器硬扛多租户 |
| 长上下文并发上不去 | 超节点 + PD 分离 | 只加单卡显存 |
2. Agent Infra 的四个卡点（§2）
原文先给了框架与范式的对比，然后是承载环境的要求。
2.1 框架与范式选择
| 对象 | 原文判断 | 工程含义 |
|---|---|---|
| AutoGPT | 通用任务、完全自主；复杂任务下上下文一致性与成本是问题 | 演示可用，生产慎用 |
| LangGraph | 步骤可明确拆解时优势明显（多步控制、易调试），自主性有限 | 生产主力：可控 > 自主 |
| Workflow | 步骤确定、条件有限，按预设路径执行 | 稳定、可测、成本可预测 |
| Agent | 步骤无固定分支、需在上下文中决策、需跨工具动态组合 | 灵活但不可预测，需护栏 |
判据：能用 Workflow 表达的，不要用 Agent。 只有当"下一步做什么"取决于运行时观察结果时，Agent 的灵活性才值那份不确定性。
2.2 MCP 与 Skills：两个不同层次的标准
| 标准 | 管什么 | 组成/形态 | 与另一个的关系 |
|---|---|---|---|
| MCP | "用什么做"：AI 应用与外部工具/数据源的连接协议 | Server / Client / Host | 标准化接口，生态可复用（对比私有 Function Calling） |
| Skills | "怎么做"：封装专业知识、SOP、判断逻辑 | 按需激活的模块 + 可选脚本 | 依赖 MCP 提供的能力去操作真实世界 |
原文对 Skills 的安全提醒（必须写进设计）：
| 风险 | 机制 | 缓解 |
|---|---|---|
| 语义劫持 / 幽灵指令 | 按需激活时被注入未声明的指令 | 技能清单白名单 + 激活前静态审查 |
| 恶意脚本 | Scripts/ 目录借 Agent 的 Bash 权限执行危险操作 |
脚本沙箱、最小权限、命令审计 |
| 隐密后门 | 不安全配置留下持久入口 | 配置基线 + 定期比对 |
2.3 承载环境：为什么容器/VM/Serverless 都不合适（原文）
| 方案 | 原文指出的问题 |
|---|---|
| Docker 容器 | 进程级隔离，多租户下有逃逸风险 |
| 传统虚拟机 | 启动时延用户无法忍受 |
| Serverless | 状态保持差 → 巨大 I/O 开销与延迟 |
2.4 沙箱四要求与验收项（E-S23-009）
原文给的"腾讯云最佳实践"四条要求，转成可验收项：
| 要求 | 为什么 | 验收项（可判定） |
|---|---|---|
| 强隔离与安全 | Agent 生成的代码不可信，必须防逃逸 | 用已知逃逸样例回归；确认独立内核（非共享内核） |
| 长程任务稳定 | 任务可能跑很久，连接断开不能失败 | 断网/断连 30 分钟后任务仍可续跑 |
| 状态管理与持久化 | Crash 后能否恢复 | 强杀进程后从快照恢复，状态无损 |
| 可观测与审计 | 必须知道沙箱里干了什么 | 每次 exec 有命令、输出、退出码、资源用量记录 |
原文提到的厂商实现（Cube 沙箱 80ms 交付、MVM 快照 + 镜像预热消除冷启动、独立 Guest Kernel、暂停恢复零闲置）属厂商口径，本系列标 needs_verification，不作为选型唯一依据。
3. 超节点与带宽（§3）
原文：跨卡/跨机通信已是刚需；相比 RDMA，GPU 间专有通道更高效；超节点 = 让更多卡通过专有通道互通，形成一个超大 GPU 域。
| 事实（原文转述） | 数值 | 状态 |
|---|---|---|
| NVIDIA Vera Rubin NVL144 | 单域 144 颗 Rubin GPU，支持 FP4，单域带宽 260 TB/s | 厂商口径，待核 |
| 推理需求随上下文增长 | 算力平方级、显存线性级 | 与注意力机制一致，可推导 |
| 部署组合 | 1M 上下文 + Rubin + NVL144 + PD 分离 = 最佳实践 | NVIDIA 博客口径，待核 |
3.1 带宽需求怎么估算（E-S23-010）
每 token 需要搬运的 KV ≈ 2 × 层数 × 隐藏维 × 字节/token （J01 §4）
并发 C、输出速率 R token/s 时，KV 读带宽 ≈ C × R × KV_per_token
例：C=64, R=50, KV=2.62MB → 64×50×2.62MB ≈ 8.4 GB/s（仅 KV 读，未含权重）
上下文翻倍 → 显存翻倍、Attention 计算翻四倍 → 互联压力同步上升
判据：当"KV 读带宽 + 权重读带宽"接近单机 HBM 上限时，才需要跨机高带宽域；否则加卡解决不了的是调度问题，不是带宽问题。
4. 结论与参考资料（§4）
原文的收尾判断值得保留：2025 年的工程方向是"更精细的设计与优化"，而非一味追求超级硬件与超级集群；2026 年重点是低成本硬件的极致性价比，工程重心在 AI Agent Infra——因为所有模型与工程进步最终服务于应用落地。
| 原文引用 | 可核实性 |
|---|---|
DistServe 论文 arXiv:2401.09670 |
原文给了链接，可核实 |
DeepEP（github.com/deepseek-ai/DeepEP） |
原文给了链接，可核实 |
| TileLang 论文 | 原文未给链接，待核 |
| DOPD / SeamlessFlow / Step-3 论文 | 原文未给链接，待核 |
| 行业分析、知乎长文、财新报道 | 二手资料，仅作趋势参考 |
5. 投入决策清单
| 问题 | 若答"是" | 若答"否" |
|---|---|---|
| Agent 会执行模型生成的代码吗？ | 必须上强隔离沙箱（§2.4） | 普通容器 + 最小权限即可 |
| 任务时长 > 10 分钟且要求可恢复？ | 需要快照/持久化 | 无状态即可 |
| 单机 KV 带宽已达上限？ | 评估超节点/PD 分离 | 先做量化与调度优化 |
| 多租户？ | 独立内核隔离 + 审计 | 单租户可放宽 |
| 需要异地容灾？ | 传输与存储成本要单列 | 同域部署 |
6. 常见误区
| 误区 | 纠正 |
|---|---|
| "Agent 框架越自主越先进" | 生产要可预测；能用 Workflow 就别上自主 Agent |
| "MCP 就是 Function Calling 改名" | 一个是标准协议（生态可复用），一个是私有约定 |
| "Skills 只是提示词" | 可含脚本与权限，是攻击面（§2.2） |
| "超节点能解决一切慢" | 只有互联成为瓶颈时才有效（§3.1） |
7. 自测
- 你的 Agent 任务，断连 30 分钟后能续跑吗？
- 你能列出沙箱里每一次 exec 的命令与退出码吗？
- 用 §3.1 算出你的 KV 读带宽，距离单机 HBM 上限还有多少余量？
8. 下一篇
S23-X01 · 术语、指标与论文速查 —— 六个方向的术语表、TTFT/TPOT/算术强度等指标口径，以及本系列引用清单的可核实状态。