工具与选型清单：按层点名（Toolchain Inventory）

所属：01-fundamentals（跨节的地图层，不归任何单一子目录）
面试权重：★★（它本身不是考点，但「你们那一层用什么」是每一层的必然追问 —— 答不出具体名字，前面讲的所有架构都会显得是背的）
来源：各工具的官方文档公开定位（通识层描述，未做一手考证，也未在本仓库实测）；层与判据对回《深入理解 AI Infra：量化分析与系统设计》第 9–11 章（推理 / 训练 / 运行环境）与《深入理解 AI Agent：设计原理与工程实践》第 1、3、10 章；一手经验只引 02-interview/projects/*.md 正文点名的工具，其余一律标「待你确认」
相关知识点：各层专题篇 —— ./06-agent-infra/vllm-pagedattention.md、./06-agent-infra/07-distributed-inference.md、./06-agent-infra/gateway-routing.md、./06-agent-infra/09-training-systems.md、./06-agent-infra/10-agent-runtime.md、./06-agent-infra/observability.md、./03-rag/pipeline.md、./02-post-training/grpo.md、./05-agent-evaluation/rag-eval.md、./04-agent-architecture/16-agent-runtime-tools.md

一句话#

这个仓库把每一层讲厚了、却很少点名 —— 面试官追问「你们那一层用什么」时，你需要一张按层的点名表 + 每层的选型判据，以及一句诚实的「这层我没在生产里运维过」。

它是一张地图，不是评测：每层只给「一句话定位 + 判据 + 被追问时怎么答」，读完能说清「这一层有哪些档、什么时候选哪档」，但不能说清任何一个工具的内部机制 —— 机制归各自的专题篇。

为什么重要（面试角度）#

• 「你们用什么？」是架构讲完之后必然的追问。答不出具体名字，前面讲的分层、路由、并行都像是从文章里背来的 —— 名字是把「知道」和「做过」分开的第一道检验。
• 但反过来也成立：报了名字就要接得住下一问 —— 为什么选它、它的边界在哪、换掉要付什么代价。所以本篇每层都给判据而不是推荐：有判据，追问就落在你的推理上；没有判据，追问就落在你的记忆上。
• 它还是「六块学习目标」的工具索引 —— 想知道某一块业界在用什么，从这里进，再顺着链接去对应专题篇看机制。
• 最后一条是边界纪律：这张表里没被你的项目正文点名的层，就是要老实说「知道它解决什么，没在生产里运维过」的地方。把读来的讲成做过的，追问两层就崩。

核心内容#

免责（全篇适用）：下面是通识层的产品定位，未做一手考证，不保证覆盖全部选项、不代表任何性能或成熟度排序。具体能力、支持范围与限制以各自官方文档为准。本篇刻意不写性能数字、版本号、发布日期与排名 —— 没有实测，也不该假装有；需要机制就点进对应的专题篇。

每一层固定四行：这一层解决什么 / 主流选项 / 判据（什么条件下选哪个）/ 被追问时怎么答；再加一行一手经验（只在 02-interview/projects/*.md 正文点名过该工具时才写，否则标「待你确认」）。

1. 模型服务层（Model Serving）#

• 这一层解决什么：把模型权重变成「一个能吃并发、能限流、能被网关调用的 HTTP 服务」—— 引擎决定单实例效率（显存、吞吐、TTFT/TPOT），拓扑决定算力放在哪。
• 主流选项（一行一个定位）：
  • vLLM —— 以 PagedAttention 与连续批处理为核心的通用推理引擎，生态最广、兼容性最好的一档。
  • SGLang —— 以共享前缀复用（RadixAttention）与结构化输出执行为特色的推理引擎，多轮对话、共享前缀、复杂输出约束的场景常见。
  • TensorRT-LLM —— NVIDIA 官方的编译式推理栈，贴近自家硬件做图优化与量化，绑定 CUDA 生态。
  • TGI（Text Generation Inference）—— Hugging Face 出的推理服务，与 HF 权重/推理生态贴合。
  • Ollama —— 面向本机/单机的「一键运行 + 量化模型分发」，定位是开发者本地与边缘验证，不是高吞吐线上服务。
• 判据：自建高吞吐服务默认从 vLLM / SGLang 起步；被 NVIDIA 硬件绑定且要压榨单卡/集群极限 → TensorRT-LLM；想顺着 HF 生态零改造 → TGI；只是本机验证 → Ollama。引擎的机制（分页、前缀复用、并行、PD/AF 分离）不在本篇展开 → ./06-agent-infra/vllm-pagedattention.md、./06-agent-infra/07-distributed-inference.md、量化见 ./06-agent-infra/quantization.md。
• 被追问时怎么答：把「引擎选型」和「部署拓扑」分开说 —— 引擎决定单实例效率，拓扑（加副本 / PD 分离 / AF 分离 / 共享 KV）决定算力放哪。拓扑用「资源占用时间、状态传输字节、排队与就绪谁先到」这三种量来选（详见 ./06-agent-infra/07-distributed-inference.md）。
• 一手经验：../02-interview/projects/quewi-chatbot.md 正文点名 vLLM（「基于 vLLM 的推理部署」，并讨论了显存与尾延迟的坑）。SGLang / TensorRT-LLM / TGI / Ollama 在项目正文里未被点名 —— 待你确认。

2. 模型接入层（网关）#

• 这一层解决什么：把「接模型」的横切关注点（统一接口、密钥、配额、限流、降级、日志、路由、缓存）收拢成一层，让 M 个应用 × N 个模型/供应商从 M×N 套对接代码压成 M+N。
• 主流选项（一行一个定位）：
  • LiteLLM —— Python 生态的模型代理与统一 SDK，把多家 API 与自建模型包成 OpenAI 兼容接口，自带密钥/预算/日志，自建网关最常见的起点。
  • One-API —— 国内常见的「一站式」API 分发/中转，多密钥与多渠道管理，偏聚合而非深度可观测。
  • Portkey —— 商业化 AI 网关，偏可观测、缓存、护栏与团队治理（托管为主）。
  • Higress —— 云原生网关（Envoy 系）加 AI 插件，兼做模型代理与常规服务入口。
  • APISIX —— 通用 API 网关，通过 AI 插件承担 LLM 代理、限流与鉴权。
  • Kong AI Gateway —— 通用网关 Kong 的 AI 能力扩展，适合已有 Kong 基础设施的团队。
  • OpenRouter —— 托管的模型聚合服务，一个 key 调多家模型；定位是「直接买聚合」，不是自建网关。
• 判据：「什么时候该有网关、没有网关会怎样、网关集中了哪些职责」见 ./06-agent-infra/gateway-routing.md，本篇不复述。这里只补一句产品面判据：要求密钥/数据不出内网、路由策略自己写 → 自建（LiteLLM / One-API 一类）或云原生网关（Higress / APISIX / Kong）；要求少运维、直接买 → 托管聚合（OpenRouter / Portkey）。
• 被追问时怎么答：先答「需不需要网关」（用 M×N→M+N 的论证，见 gateway-routing.md），再答「用哪个」—— 用哪个取决于三点：数据能不能出内网、要不要自己实现路由、团队会不会运维这一层。
• 一手经验：../02-interview/projects/quewi-chatbot.md 正文说「搭了 AI 网关」，但没有点名任何具体开源网关 —— 自研还是 LiteLLM / One-API 一类，待你确认。

3. 训练与后训练层#

• 这一层解决什么：让「训练 / 微调 / 对齐」在有限显存里跑得起来、跑得完、坏了能恢复 —— 算法侧与系统侧是两条线。
• 主流选项（一行一个定位）：
  • Verl —— 字节开源的 RL/RLHF 训练框架，把 rollout 与训练拆成可独立伸缩的 worker，RL 训练要解耦采样与训练时的常见选择。
  • TRL —— Hugging Face 的 RLHF/DPO/GRPO 训练库，贴近 transformers 生态、上手快。
  • Megatron-LM —— 大规模预训练/微调框架，强在张量/流水并行，偏大集群。
  • DeepSpeed —— 分布式训练库，ZeRO 分片与 offload 的代表实现。
  • FSDP —— PyTorch 原生的全分片数据并行，与 torch 生态一体、改动小。
  • PEFT / LoRA —— 参数高效微调库/方法族，小数据窄任务的首选，省显存省数据。
  • Unsloth —— 面向单卡/小规模的高效微调库，主打显存与速度优化。
  • LLaMA-Factory —— 一体化微调工具，配置化跑 SFT/DPO/RL，偏「开箱即用」。
  • Axolotl —— 配置驱动的微调工具，社区活跃。
• 判据：系统侧（显存、checkpoint、并行怎么切、坏了怎么恢复）见 ./06-agent-infra/09-training-systems.md；算法侧（SFT/DPO/GRPO/PPO、灾难性遗忘、数据工程）见 ./02-post-training/ 下各篇。产品面判据：全参大规模 → Megatron-LM / DeepSpeed / FSDP；小数据窄任务 → PEFT·LoRA（或 Unsloth / LLaMA-Factory / Axolotl 这类一体化工具）；RL 要采样与训练解耦 → Verl / TRL。
• 被追问时怎么答：先分清框架与并行策略不是一回事（FSDP/ZeRO 是分片，不是一条并行轴，见 ./06-agent-infra/batching-parallelism.md）；再答为什么这个规模的训练用这套 —— 并主动说清「训练状态常驻量、每步预算、故障重做」这本账。
• 一手经验：../02-interview/projects/race-bot-hkjc.md 正文点名 Verl（Qwen-32B 的 SFT + GRPO 两阶段训练，并解释了选 GRPO 的理由）；../02-interview/projects/writing-copilot.md 用了 DPO→GRPO 但未点名训练框架。其余框架 —— 待你确认。

4. RAG 与检索层#

• 这一层解决什么：把「先检索、再生成」变成一条可调试的流水线 —— 决定语义距离可不可靠（embedding）、几百万条里多快找到近邻（向量库）、召回与精度怎么兼顾（hybrid + reranker）、以及怎么评（RAG 评测）。
• 主流选项（一行一个定位）：
  • 向量库：Milvus / Qdrant / Weaviate —— 独立向量数据库（各自带过滤、分片、运维形态）；pgvector —— 挂在 PostgreSQL 上的扩展，图省事/复用现成 PG 运维时常见；Chroma —— 轻量、偏本地与原型；FAISS —— 库而非服务，自己管索引与存储。
  • 检索框架：LlamaIndex —— 偏「把数据接进来做检索/索引」的框架；Haystack —— 老牌的检索/QA 流水线框架；LangChain 的 retriever —— 作为更上层编排框架里的一个组件。
  • reranker：BGE 系列 —— 中文/多语常见的开源 cross-encoder 家族；Cohere Rerank —— 托管的 rerank 服务。
  • RAG 评测：Ragas —— 提供 faithfulness / context relevance 一类指标的开源框架。
• 判据：ANN 索引的取舍、向量库「规模 / 是否需要 metadata 过滤 / 运维成本」的选型口径见 ./03-rag/embedding-vector-db.md；hybrid 与 reranker 的分工见 ./03-rag/hybrid-rerank.md；全流程与失败归因见 ./03-rag/pipeline.md；评测指标口径见 ./05-agent-evaluation/rag-eval.md（框架内部同样是「LLM 判断 + 提示词假设」，换模型/语言/领域后会漂移，需自行校准）。
• 被追问时怎么答：先答「为什么检索是这条链路」（失败分类法，见 pipeline.md），再答「用哪个库」时把判据落在规模、过滤需求、运维成本三点上，不要用「大家都用 X」来答。
• 一手经验：../02-interview/projects/race-bot-hkjc.md 正文点名 Elasticsearch 做实体模糊匹配（该项目明确讨论了「为什么不用向量检索」）。向量库、检索框架、reranker、RAG 评测框架 —— 在项目正文里未被点名，待你确认。

5. Agent 层#

• 这一层解决什么：把「模型 + 工具 + 状态 + 循环」组装成一个能跑、能停、能恢复的 agent。
• 主流选项：按框架 / 运行时 / Harness / 通用持久化执行引擎四分 —— 本篇只点类别名，不点名展开产品；各家站位与具体产品见 ./04-agent-architecture/16-agent-runtime-tools.md（配套可读 ./04-agent-architecture/17-agent-loop-from-scratch.md，那是手写一遍把框架替你兜的东西看穿）。
• 判据：判据是「谁的抽象层少、且不骗你」，而不是「谁功能多」；四分与逐家判断全在 16 那篇展开，本篇不复述。
• 被追问时怎么答：先分清这个工具站在哪一层（框架 / 运行时 / Harness / 执行引擎），再谈选型。
• 一手经验：../02-interview/projects/writing-copilot.md 正文点名 LangGraph（多智能体写作架构 + 共享 state）；../02-interview/projects/quewi-chatbot.md 正文点名 MCP 工具链。其余框架 —— 待你确认。

6. 沙箱与隔离执行层#

• 这一层解决什么：工具调用最终要由普通程序执行 —— 这一层决定隔离边界画在哪（防的不只是别的沙箱，也防沙箱自己伤到宿主）、环境什么时候销毁、以及密度能开多高。
• 主流选项（一行一个定位）：
  • E2B —— 托管沙箱，底层用 Firecracker microVM，模板由容器镜像构建（镜像决定「有哪些依赖」，microVM 决定「怎么和宿主隔离」）。
  • Modal —— 托管 serverless 计算平台，常用于跑工具/GPU 任务，附沙箱能力。
  • Daytona —— 面向 agent 的开发环境/沙箱管理。
  • Firecracker —— microVM 的代表实现（AWS 为无服务器计算开发），自带内核、经虚拟硬件与宿主隔离。
  • gVisor —— 用户态内核，给容器加一层系统调用拦截，落在「容器」与「microVM」之间的那条轴上。
  • microsandbox —— 面向 AI 代码执行的 microVM 沙箱（较新）。
  • Docker —— 容器隔离的默认实现，最规范、生态最广，但启动有开销（常用容器池缓解）。
• 判据：隔离强度是一根连续的轴（进程 / 容器 / microVM / 完整虚拟机），代价随强度上升 —— 那张对照表见 ./06-agent-infra/10-agent-runtime.md §2，本篇不复述。产品面判据：自建可控 → Firecracker / gVisor / Docker；不想自己运维隔离 → E2B / Modal / Daytona 这类托管。
• 被追问时怎么答：先答「要防谁」（别的租户？不可信代码？宿主？），再选强度档位，最后谈密度与启动开销这一对可交换的量（见 10-agent-runtime.md §3/§4）。
• 一手经验：沙箱这一层在 02-interview/projects/*.md 正文里未被点名（E2B / Firecracker / Docker 出现在 infra 篇与设计篇，不是你的项目正文）—— 待你确认。

7. 可观测与评测层#

• 这一层解决什么：agent 是多步、非确定性、会传播错误的系统 —— 这一层把一次运行拆成带输入输出的 step 树（定位「哪一步坏了」），并把这些真实运行变成评测数据与训练数据（形成闭环）。
• 主流选项（一行一个定位）：
  • Langfuse —— 开源 LLM 可观测平台，提供 trace/session/observation 数据模型，可在 trace 上挂 score、建 dataset。
  • LangSmith —— LangChain 官方的 trace/评测平台，与 LangChain/LangGraph 生态一体（托管为主）。
  • OpenTelemetry —— 通用追踪标准，生态成熟、可接既有 APM，但 LLM 特有字段（token、成本、prompt）需自定义约定。
  • Phoenix (Arize) —— Arize 开源的 LLM 可观测/评测工具。
  • Braintrust —— 商业化评测与实验平台。
  • Helicone —— 网关式的 LLM 可观测/代理。
  • promptfoo —— 开源 prompt/模型评测与红队工具，偏离线评测/CI。
  • DeepEval —— 开源 LLM 评测框架，把指标写成断言。
• 判据：trace 的数据模型、要记哪些字段、「自建 vs 采购」的评估口径（数据合规常是一票否决项）见 ./06-agent-infra/observability.md（§「工具与选型」已点 Langfuse 与 OpenTelemetry，本篇不重复）；评测方法与统计显著性见 ./05-agent-evaluation/（agent-eval.md / llm-as-judge.md / 05-statistical-significance.md）。产品面判据：数据不能出境/不能给第三方 → 自建或开源自部署（Langfuse / Phoenix / promptfoo / DeepEval）；要省事、生态一体 → LangSmith / Braintrust 等托管。
• 被追问时怎么答：把「观测」与「评测」分开答 —— 观测回答「这次为什么坏」，评测回答「这版比上版好不好」；两者通过 trace→dataset→回灌连成闭环（见 observability.md）。
• 一手经验：可观测与评测工具在 02-interview/projects/*.md 正文里未被点名（项目里讲过评测体系的方法与自制 benchmark，但没有点名工具）—— 待你确认。

8. 协议层#

• 这一层解决什么：把「LLM 应用 ↔ 工具/数据源」与「agent ↔ agent」「agent ↔ 前端」的接入方式标准化，让接入从 M×N 收敛成 M+N。
• 主流选项（一行一个定位）：
  • MCP（Model Context Protocol）—— LLM 应用 ↔ 外部工具/数据源的接入标准，由 Anthropic 提出的开放协议。
  • A2A —— agent 间协作的协议（互操作/委派这一层）。
  • AG-UI —— agent 与前端交互的协议（把 agent 的执行状态暴露给 UI）。
• 判据：MCP 的分层、为什么用 MCP、以及它不解决什么（工具选择准确性）见 ./04-agent-architecture/mcp.md；A2A 与多 agent 协作的机制、冲突治理见 ./04-agent-architecture/13-multi-agent-coordination.md。协议只解决「怎么接」，不解决「接得好不好」。
• 被追问时怎么答：主动划边界 —— 协议解决接入标准化，不解决工具/agent 的选择准确性、权限与质量；那些仍是 prompt、评测与权限模型的活。
• 一手经验：../02-interview/projects/quewi-chatbot.md 正文点名 MCP 工具链（并主动说明 MCP 解决接入标准化、不解决工具选择准确性）。A2A / AG-UI —— 待你确认。

收口一：选型判据的四条通法#

这四条不依赖具体产品，任何一层的「你们为什么用这个」都能用它们往下接：

1. 不要自研 —— 先问有没有成熟方案。 判据：只有当成熟方案在你最在意的那条约束上（合规、成本、时延、控制粒度）明确不满足时，自研才成立；否则自研的维护成本会长期吃掉那点定制收益。
2. 有没有托管版 —— 运维成本算进来了吗。 判据：把「自己运维要几个人、出问题谁 on-call」算进总成本；托管省人但常带来数据出内网与锁定问题，两者要一起称。
3. 锁定成本 —— 换掉要付多少。 判据：看接入是走标准协议（MCP、OpenAI 兼容接口、OpenTelemetry）还是私有抽象；标准接口下的替换只是配置，私有抽象下的替换是重写。
4. 谁来运维 —— 这东西落谁头上。 判据：一项技术如果没人认领它的值班、升级与故障，就等于没有这个选型 —— 先在团队里找到 owner，再决定引不引入。

收口二：被问「你技术栈是什么」时怎么答#

按层答，每层三句话：「用了什么 + 为什么 + 边界」。 结构比清单重要 —— 面试官要的是判断力，不是名词表：

• 一句话定框架：「我这两年多的技术栈是一条从上往下的线 —— 训练/后训练、推理服务、网关与路由、多智能体编排，最后沉淀成一层基础设施。」（串联见 ../02-interview/projects/README.md）
• 每层只讲你真正深的那一层，并且主动说边界：例如「推理服务这层，我用 vLLM 做过部署，遇到的主要是显存与尾延迟；量化、分布式拓扑这些我是知道它解决什么，没有在生产里运维过」。
• 没用过的层要显式划界：说成「知道它解决什么，没在生产里运维过」，而不是含糊带过或硬答。这正是 AGENTS.md「知道 ≠ 做过」那条硬规矩 —— 把读来的讲成做过的，追问两层就崩。
• 报名字之后自己先接住下一问：为什么选它、它的边界在哪、换掉要付什么代价 —— 用上面收口一的四条通法自问一遍，答不上的层就别主动展开。
• 别报自己不确定有没有用过的工具：这张表里凡标「待你确认」的位置，先回去核对自己项目，再决定要不要说出口。

常见面试问法#

Q： 你们那一层用什么？能不能具体说几个工具名？ A：按层答，每层「用了什么 + 为什么 + 边界」，并显式区分「做过的」与「只知道是什么的」。示范结构：① 推理服务 —— 用过 vLLM（讲部署时遇到的显存/尾延迟）；② 网关与路由 —— 搭过 AI 网关并做模型路由（讲 M×N→M+N 与路由开销必须便宜）；③ 训练/后训练 —— Verl 跑过 SFT+GRPO 两阶段；④ 编排 —— LangGraph 做过多智能体 + HITL；⑤ 其余层（沙箱、可观测平台、向量库选型等）明确说成「知道它解决什么，没在生产里运维过」。关键不是清单长，而是每报一个名字都接得住下一问。

Q： 为什么用 X 而不是 Y？（给定两个候选） A：不要背功能列表，用你所在场景的那条约束来答。可行的一条推理链：先定「这一层最在意的约束是什么」（合规不许数据出内网？要自己写路由？显存不够要省状态？），再看候选在这条约束上的表现，最后算「换掉的锁定成本」。如果两个候选在关键约束上等价，就承认「差别不大，我们按团队熟悉度选了 X」—— 这比编一个技术理由可信得多（通法见收口一）。

Q： 怎么判断一个领域该不该自研？ A：先问有没有成熟方案（不要自研）；再看有没有托管版、运维成本多高；再算锁定成本（标准接口替换便宜，私有抽象替换贵）；最后确认谁来运维。只有成熟方案在最在意的约束上明确不满足、且团队有 owner 接得住时，自研才成立。「别人没有，所以我们造一个」不是理由，「别人的方案在我们的硬约束下不成立」才是。

Q： 你怎么保证自己说的是「做过的」而不是「看过的」？ A：报工具名之前先分清三档：亲手搭过并踩过坑的（可深挖）、在项目里配过/调用过的（能说用了但别展开机制）、只读过文档定位的（只说「知道它解决什么」）。第三档绝不主动展开，被追问就老实说「这块我知道它解决什么，没在生产里运维过」。这条纪律的价值在于：面试官隔两层就能分辨「用过」和「看过」，提前划界反而比模糊带过更稳。

Q： 如果让你给一个新项目选型，你按什么顺序走？ A：先把这一层的约束写清楚（合规、延迟、成本、团队规模），再列候选，再用四条通法筛（要不要自研 / 有没有托管 / 锁定成本 / 谁来运维），最后用一条最小验证把选型落地（跑通一条链路、量一个数），而不是直接上生产。顺序是「约束 → 候选 → 判据 → 最小验证」，先定判据再选产品可以避免被某一家的功能宣传带着走。

易错点#

自测#

1. 面试官问「你们那一层用什么」，一个「答得住追问」的回答结构是什么？

2. 为什么「报了工具名」之后还要能接住下一问？报名字的风险是什么？

3. 选型判据的四条通法是什么？请各给一句判据。

4. 有人说「我们靠 RAG 评测框架的分数保证质量」，这个说法的问题在哪？