更新 @2026-09-10：本文第四层「三个 harness 案例」一节与场景轴中 harness 一词的用法，按 OpenAI 2026-02-11 的《Harness engineering: leveraging Codex in an agent-first world》刷新——harness 指模型之外约束、告知、验证、纠正 agent 的整套系统；其余框架与协议以写作时的状态为准。
内容简介
这是三张 AI 学习地图中的第三张（三张的总览与分工见《AI 全栈学习地图》）。《AI-Infra 工程师学习地图》面向跑模型的人，《AI 算法工程师学习地图》面向造模型的人，这一张面向用模型做产品的人——AI 应用工程师。它假设读者有后端工程的基础（服务、数据库、API、部署），同时关心产品：什么场景值得做、用户怎么用、效果怎么衡量。
“AI 应用”在这里取宽的定义：用模型改变现有的流程与体验。模型可以是 LLM，也可以是自动驾驶里的感知模型、VLA 与世界模型；动作可以是调用一个 API，也可以是控制一台车；输入可以是用户敲的字，也可以是传感器的每一帧。这张地图以 LLM 应用为主要案例展开，因为它当前的工程实践最成体系，但每一层的问题都会用物理世界的应用做对照——它们是同一张地图上的不同参数取值，只多出一层数字世界没有的基础设施：仿真。
调用一个模型 API 只要五行代码，这让”AI 应用开发”看起来门槛很低。真正的门槛在第六行之后：模型是一个非确定性、会出错、按 token 计费、有上下文上限的组件，而产品要求的是可靠、可控、可衡量、可负担。AI 应用工程师的全部工作，是在这样一个组件之上，用检索、工具、编排、评测、运营把它变成一个可以交付的产品。
地图回答三个问题：
一个 AI 应用由哪些层组成？每一层需要掌握什么？按什么顺序学？
| 需要什么 | 具体是什么 |
|---|---|
| 一种组件观 | 把模型当作一个有明确契约与失效模式的组件：API、token、上下文、延迟、幻觉 |
| 一套上下文工程 | 决定模型在每一步看到什么：prompt、检索结果、记忆、工具输出，以及它们的预算 |
| 一层检索 | RAG：把私有知识可靠地送进上下文 |
| 一层 Agent | 工具调用、循环、状态、多 agent、人机协作——让模型从”回答”变成”做事” |
| 一套评测 | AI 应用的单元测试：没有评测就没有迭代 |
| 一层运营 | 成本、延迟、安全、发布与回滚、数据飞轮 |
| 一种产品观 | 什么场景值得做、人和模型怎么分工、不确定性怎么呈现给用户 |
与前两张地图不同，这一层几乎没有 PyTorch 那样的事实标准框架。稳定的是协议与模式——OpenAI 兼容的模型 API、MCP、ReAct 循环、RAG 管线、evals；框架（LangChain / LangGraph、LlamaIndex、Dify、各家 Agent SDK）迭代很快。地图以协议与模式为主线，框架只作为抓手或代表点名。
两张图：架构视图与学习路径
第一张图：架构视图
一个 AI 应用从用户到模型的分层，以及贯穿所有层的两条横切：
%%{init: {"flowchart": {"wrappingWidth": 320}}}%%
flowchart TB
subgraph APP["AI 应用"]
direction TB
UI["`**用户与渠道**
Web / IM / IDE / 语音 · 流式呈现 · 引用与可撤销`"]
ORCH["`**应用与编排**
Agent runtime · 工作流 · 状态与持久化 · human-in-the-loop`"]
CTX["`**上下文层**
prompt · RAG 检索 · memory · 工具与 MCP 服务`"]
GW["`**模型接入层**
统一 API · 路由与 fallback · 缓存 · 配额与计费`"]
UI --> ORCH --> CTX --> GW
end
MODEL["`**模型**
云 API ｜ 自托管推理引擎（Infra 地图的范围）`"]
GW --> MODEL
EVAL["`**评测与可观测**
evals · trace · 在线指标`"]
SAFE["`**安全与治理**
prompt injection · 权限 · PII · 审计`"]
EVAL -.- APP
SAFE -.- APP
classDef app fill:#fff7e0,stroke:#c98a00,stroke-width:2px,color:#222
classDef other fill:#f7f7f7,stroke:#c8c8c8,stroke-width:1px,color:#666
classDef cross fill:#eef6ff,stroke:#5b8fd6,stroke-width:1px,color:#222
class UI,ORCH,CTX,GW app
class MODEL other
class EVAL,SAFE cross
style APP fill:#fffbea,stroke:#c98a00,stroke-width:2px
四层各有一个核心问题：用户层——不确定的输出怎么呈现；编排层——多步任务的状态放在哪、失败了怎么继续；上下文层——模型这一步该看到什么、看多少；接入层——用哪个模型、坏了换谁、花了多少钱。两条横切的地位与后端系统里的测试与安全相同：不是某一层的事，是每一层的事。
场景轴：两根正交的轴
架构视图是能力轴。AI 应用还有两根场景轴，彼此正交：服务谁（业务还是 IT）与动作落在哪个世界（数字还是物理）。两根轴拉出一个 2×2：
| 数字世界 | 物理世界 | |
|---|---|---|
| AI4业务（作用于业务流程与客户） | 智能客服、业务助手、内容生成、智能搜索、行业流程自动化（审核、报告、合同）、本体驱动的业务 agent（Palantir AIP 一类） | 自动驾驶、无人机巡检（电网、风机、光伏）、能源调度与设备控制、工业质检与机器人操作、医疗影像辅助设备 |
| AI4IT（作用于工程师与 IT 系统） | coding agent、AIOps（告警归因、变更审查）、数据分析 agent（text-to-SQL）、内部知识库、运维与工单 | 数据中心巡检机器人、机房温控与能耗优化 |
第一根轴决定工具集与验证方式：
| AI4业务 | AI4IT | |
|---|---|---|
| 工具集 | 业务系统 API、CRM / ERP、知识库、设备控制 | 代码库、终端、CI、监控与日志、数据库 |
| 验证方式 | 人工评审、用户反馈、业务指标；难以自动验证，除非把验证前移到本体规则或仿真 | 编译、测试、lint、查询结果；大部分可自动验证 |
| 错误代价 | 面向客户或物理世界，错误外露 | 面向内部，可审核回滚 |
| 当前成熟度 | copilot 为主，agent 在推进；物理世界侧自动驾驶 L2 量产、L4 限定区域运营 | coding agent 已是最成熟的 agent 产品 |
第二根轴决定模型、输入、动作的形态，以及验证的基础设施：
| 数字世界 | 物理世界 | |
|---|---|---|
| 模型 | LLM / VLM | 感知模型、VLM / VLA、世界模型、控制策略；端侧实时推理 |
| 输入 | 用户对话、业务数据、代码与日志 | 传感器流：摄像头、激光雷达、毫米波 / 超声波雷达、IMU、SCADA 遥测 |
| 动作 | API、数据库、文件、消息；大多可撤销 | 控制系统：转向、制动、机械臂、阀门、变桨；连续、实时、不可撤销 |
| 时延 | 秒级，可挂起等人 | 毫秒级硬实时，不能等 |
| 验证基础设施 | 测试、评测集、灰度 | 物理仿真、硬件在环、影子模式、实车 / 实机测试——一套独立的基础设施与上线流程（见 L5、L6） |
| 人在环的形态 | 审批工具调用、code review、坐席审核 | 操作员监控与接管；自动驾驶的 SAE L0–L5 |
四个格子共用全部能力层——模型作为组件、上下文的组装、动作的执行与权限、评测、运营、人机分工。差别归结为三个参数：动作的可逆性、时延约束、验证方式。这三个参数共同决定了一个场景的 agent 能走多远：能自动验证且可回滚的场景（代码能跑测试）允许 agent 自主循环几十步再交给人，这是 coding agent 最先成熟的原因；不能自动验证的场景只能把循环收短、把人放在环内；不可逆且验证成本极高的场景（驾驶、电网控制）则要先把验证做成一门独立的工程——仿真——自主级别才能一级一级往上走。理解这三个参数，比记住哪个场景”火”更重要：它告诉你一个新场景的 agent 化上限在哪。
本图的分层按能力轴走，以 LLM 应用为主线；第四层用三个案例解剖三个格子的 harness：coding agent（IT × 数字）、Palantir 的本体（业务 × 数字）、自动驾驶（业务 × 物理）。物理世界特有的基础设施——仿真——在第五层单独讨论，它的上线流程在第六层。
第二张图：学习路径
| 层 | 主题 | 回答的问题 |
|---|---|---|
| L1 | 模型作为组件 | 模型这个组件的契约是什么？它怎么失效？怎么选？ |
| L2 | Prompt 与上下文工程 | 模型这一步该看到什么？怎么让输出可解析、可稳定？ |
| L3 | 检索与知识接入 | 私域知识怎么进入模型？grep、向量、结构化三类检索各适合什么？何时该微调？ |
| L4 | 工具、Agent 与运行时 | 模型怎么从”回答”变成”做事”？agent 运行时与传统服务、模型 serving 有什么不同？人怎么从环内退到环上、环外？ |
| L5 | 评测、可观测与可追溯 | 怎么知道改了之后更好了？非确定性的系统怎么调试、怎么复现一次失败？ |
| L6 | 生产化与运营 | 成本、延迟、安全、发布、回滚，以及数据怎么回流 |
| L7 | 产品与体验 | 什么场景值得做？人和模型怎么分工？不确定性怎么呈现？ |
| 横切 | 评测驱动开发 | 没有评测集的改动只是猜 |
| 选修 | 微调 ｜ 自托管 ｜ 多模态交互 ｜ 端侧 | 何时从”用模型”走向”改模型”或”跑模型” |
顺序的理由：先把模型当组件理解透（L1），再学控制它的输入（L2、L3）、扩展它的能力（L4），然后才是衡量（L5）与运营（L6）——但评测（L5）应该在做第一个原型时就开始，这是横切一节的主题。产品（L7）放最后不是因为不重要，而是因为它的每个判断都需要前六层的知识做支撑。
两张图的叠加
| 架构视图中的位置 | 学习层 |
|---|---|
| 用户与渠道 | L7 · L6（流式与延迟） |
| 应用与编排 | L4 |
| 上下文层 | L2 · L3 · L4（工具与 memory） |
| 模型接入层 | L1 · L6 |
| 模型 | L1（选型）；实现属于 Infra 地图 |
| 评测与可观测 | L5 · 横切 |
| 安全与治理 | L6 |
| 场景轴 | L7 · L4（可逆性、时延、验证方式决定 agent 化程度） |
逐层说明
L1 模型作为组件
模型这个组件的契约是什么？它怎么失效？怎么选？
后端工程师习惯的组件（数据库、消息队列）有确定的语义；模型没有。这一层的目标是建立一个准确的组件模型——它能做什么、怎么坏、花多少钱、多慢：
| 主题 | 概念 | 说明 |
|---|---|---|
| 失效模式 | 非确定性（同一输入不同输出）、幻觉（自信地编造）、指令遵循不稳、上下文窗口上限与”中间遗忘”、知识截止、对 prompt 微小改动的敏感 | 每一条都对应后面某一层的应对手段；先知道病，再学药 |
| API 契约 | 消息与角色（system / user / assistant / tool）、tool calling、structured output（JSON schema）、多模态输入（图片 / 音频 / 文件）、流式输出、prompt caching、批处理接口、推理模型的 reasoning 参数 | OpenAI 兼容格式已是事实标准，自托管引擎（vLLM 等）也提供同一接口；学一次，处处可用 |
| 成本与延迟形态 | 按输入 / 输出 token 计费，输出贵数倍；缓存命中的输入折价；首 token 延迟（TTFT）与逐 token 速度；长上下文让 TTFT 线性增长；推理模型的”思考”token 既花钱又花时间 | 这是 L6 成本与延迟优化的账本；理解 prefill / decode 的差别只需要 Infra 地图 08 前两篇的结论 |
| 模型选型 | 闭源 API vs 开源自托管；推理模型 vs 非推理模型；大模型 vs 小模型分流；embedding 模型与 rerank 模型；多模态能力；上下文长度；排行榜的局限（污染、与自己任务的相关性） | 选型的正确方法是用自己的评测集（L5）跑一遍，不是看榜 |
| 客户端工程 | 重试与退避、超时、幂等、速率限制、SDK 与直接 HTTP、流式解析（SSE）、tokenizer 计数 | 与调用任何不稳定的第三方服务相同，但失败类型更多（内容过滤、上下文超限、工具调用格式错） |
L2 Prompt 与上下文工程
模型这一步该看到什么？怎么让输出可解析、可稳定？
“prompt 工程”这个词已经不够用：生产系统里模型每一步看到的东西，是 system prompt、对话历史、检索结果、工具返回、记忆片段拼成的一个上下文，它的组装、预算与压缩是一门工程。
| 主题 | 概念 | 说明 |
|---|---|---|
| prompt 设计 | 角色与任务说明、few-shot 示例、思维链与”先想再答”、分步与分解、输出格式约束、负面指令的低效、模型差异（同一 prompt 换模型要重调） | 模式是稳定的，措辞是不稳定的；把 prompt 当代码管，不当文案管 |
| 结构化输出 | JSON schema 约束解码、枚举与类型校验、解析失败的重试与修复、结构化输出对推理质量的影响 | 让下游代码能消费模型输出的前提 |
| 上下文预算 | 各部分（system、历史、检索、工具输出）的 token 配额；历史的截断与摘要；检索结果的数量与排序；工具输出的裁剪 | 上下文不是越多越好：无关内容降低准确率、拉长延迟、增加成本 |
| prompt caching | 前缀稳定才能命中：system prompt 与工具定义放前面、动态内容放后面；缓存对成本与 TTFT 的影响 | 一个排序决定能省一半成本 |
| 版本与迭代 | prompt 放版本库、与模型版本绑定、每次改动跑评测集（L5）、A/B | prompt 改一个词就是一次发布 |
| 长上下文 vs 检索 | 什么时候把全部资料塞进上下文（配合 prompt caching）、什么时候检索；成本、延迟、准确率三者的权衡 | 引出 L3 |
L3 检索与知识接入
私域知识怎么进入模型？grep、向量、结构化三类检索各适合什么？何时该微调？
通用模型不知道你的业务。把私域知识送进模型有两条路：放进上下文（检索、工具查询）或放进权重（微调、继续预训练）。这一层先回答哪条路，再讲检索本身。
1. 先决定：进上下文还是进权重
微调不是灌知识的工具：用 SFT 注入事实不可靠、会遗忘、无法引用来源、知识一变就要重训。微调擅长的是行为——风格、格式、术语用法、工具调用习惯。按知识的类型决定方式：
| 知识类型 | 例子 | 方式 |
|---|---|---|
| 会变的事实 | 价格、库存、政策、工单状态 | 检索或直接查系统（工具调用）；永远不进权重 |
| 结构化业务数据与关系 | 客户—订单—工单、组织架构 | SQL / API / 本体（ontology）与图谱 |
| 非结构化文档 | 制度、合同、技术文档、聊天记录 | 检索（词法 + 向量 + rerank） |
| 领域术语与表达习惯 | 行业黑话、公司内部说法 | few-shot 示例；量大且稳定时微调 |
| 流程性技能 | 怎么写这类报告、怎么审这类单 | 示例 + 工具；效果不够再 SFT |
| 海量领域语料的整体适应 | 法律、医学、代码库整体风格 | 继续预训练（贵，且仍需配检索给事实与引用） |
默认顺序是 prompt → few-shot → 检索 / 工具 → 微调：越靠后越贵、越不灵活、越难追溯。微调的方法（SFT、LoRA、DPO）属于算法地图 L5；应用工程师要会的是判断、准备数据与评测。
2. 三类检索，不是一类
“RAG = 向量数据库”是 2023 年的印象。检索有三类，各有适用条件，生产系统通常混用：
| 类型 | 做法 | 适合 | 不适合 |
|---|---|---|---|
| 词法 / 精确 | grep、glob、BM25、全文索引 | 有精确标识符的语料（代码、日志、配置、带编号的制度）；语料在一个可枚举范围内；agent 能多轮迭代 | 词汇不匹配（”报销标准”vs”差旅费用规定”）、语义相近表述不同、千万级文档 |
| 向量 / 语义 | embedding + ANN（HNSW / IVF）；混合检索 + rerank | 非结构化文档的语义匹配、大规模语料、用户提问与文档措辞不一致 | 精确匹配（型号、编号）、需要关系推理、数据频繁变化 |
| 结构化 | SQL、API、知识图谱、本体（ontology） | 有 schema 的业务数据、实体关系、”agent 该对什么对象执行什么动作”、权限随对象走 | 自由文本 |
coding agent 几乎只用第一类（grep + 读文件）而不用向量库，这不是向量检索过时，而是代码恰好满足第一类的全部前提：精确标识符、单仓库、能迭代。把这个经验搬到企业文档上会失败——那里词汇不匹配、语料大、用户问法与文档措辞不同，第二类仍是正确工具。Palantir Ontology、GraphRAG 一类属于第三类：它们解决的是结构化知识与”动作绑定对象”的问题，不替代前两类。
3. 从流水线到 agentic retrieval
经典 RAG 是一条固定流水线：query → embedding → top-k → 塞进 prompt → 生成。当前的趋势是把检索变成 agent 的工具：模型自己决定查什么、用哪类检索、查几轮、结果够不够。这带来两个变化——检索的召回压力变小（一次没找到可以换词再查），而对工具描述、上下文预算与循环控制（L4）的要求变高。长上下文加 prompt caching 则让”小语料直接全放进上下文”成为第三种选项。三者不是替代关系：流水线 RAG 适合高并发的问答，agentic retrieval 适合复杂任务，全放上下文适合小而稳定的资料。
4. 检索流水线的工程
无论哪种形态，检索本身的工程决定不变：
| 阶段 | 概念 | 说明 |
|---|---|---|
| 文档处理 | 解析（PDF、Office、HTML、扫描件 OCR、表格与图片）、清洗、元数据（来源、时间、权限）、分块策略（固定 / 递归 / 语义 / 按结构）、块大小与重叠 | 分块是效果的第一决定因素，且没有通用答案 |
| 索引 | embedding 模型与维度、向量索引的召回-延迟权衡、向量库（pgvector、Qdrant、Milvus、Elasticsearch 一类，点名不展开）、全文索引、增量更新与删除 | 数据量小时 pgvector 足够；先用现有基础设施 |
| 检索 | 混合检索（向量 + 关键词）与融合（RRF）、rerank（cross-encoder）、query 改写与扩展、多跳、元数据过滤、权限过滤必须在检索时做 | rerank 是性价比最高的一步 |
| 生成 | 引用与溯源、”不知道”的处理、上下文排序对生成的影响 | 引用是可信度的来源（L7） |
| 进阶形态 | GraphRAG、多模态 RAG（图表、图片）、Agentic RAG、长上下文的替代与互补 | 先把基础做好 |
| 评测 | 检索侧：recall@k、MRR；生成侧：faithfulness、answer relevance、context precision；评测集从真实问题采样 | 检索与生成分开评，否则不知道该改哪一半 |
L4 工具、Agent 与运行时
模型怎么从”回答”变成”做事”？agent 运行时与传统服务、模型 serving 有什么不同？人怎么从环内退到环上、环外？
Agent 是当前变化最快、也最容易被过度设计的一层。它的核心机制并不复杂——一个循环：模型看上下文、决定调用什么工具、执行、把结果放回上下文、再决定。复杂的是把这个循环做可靠：
%%{init: {"flowchart": {"wrappingWidth": 260}}}%%
flowchart TB
START(["用户任务"]) --> LLM["模型推理：读上下文，给出下一步"]
LLM --> DEC{"输出类型？"}
DEC -- "最终回答" --> DONE(["交付结果"])
DEC -- "工具调用" --> PERM{"权限与风险检查"}
PERM -- "需要人确认" --> HITL["human-in-the-loop：等待批准 / 修改"]
HITL -- "批准" --> EXEC
HITL -- "拒绝 / 修改" --> LLM
PERM -- "自动允许" --> EXEC["执行工具（沙箱 / API / MCP 服务）"]
EXEC --> OBS["观察结果，写回上下文"]
OBS --> BUDGET{"预算与步数检查"}
BUDGET -- "继续" --> LLM
BUDGET -- "耗尽 / 循环检测" --> FAIL(["降级：交给人或返回部分结果"])
OBS -- "上下文过长" --> COMPACT["压缩 / 摘要上下文"] --> LLM
classDef llm fill:#fff7e0,stroke:#c98a00,stroke-width:2px,color:#222
classDef human fill:#eef6ff,stroke:#5b8fd6,color:#222
classDef stop fill:#f0f0f0,stroke:#888,color:#222
class LLM llm
class HITL human
class DONE,FAIL,START stop
图里每一个菱形都是一个工程决定：权限检查决定哪些工具能自动执行、哪些要人批准；预算检查防止无限循环与失控的成本；上下文压缩决定长任务能走多远。一个 agent 框架提供的，本质上就是这张图的运行时。
agent 运行时是一种新的服务形态
后端工程师熟悉两种服务：传统应用服务，以及（读过 Infra 地图的话）模型 serving。agent 运行时是第三种，把它与前两者放在一起看，才知道为什么现有的框架都不够用：
| 传统应用服务 | 模型 serving（Infra 地图 08） | agent 运行时 | |
|---|---|---|---|
| 一次调用 | 毫秒级，确定性 | 秒级；一个请求进、一串 token 出 | 分钟到小时；几十次模型调用 + 工具执行交替 |
| 状态 | 无状态，或存数据库 | 请求内的 KV cache，引擎自己管 | 每一步都要持久化：崩溃、重启、等人之后从断点续跑 |
| 控制流 | 代码决定 | 无 | 模型决定分支；运行时只提供边界（权限、预算、步数） |
| 等待 | 不等人 | 不等人 | 可能挂起几小时等人批准 |
| 副作用 | 代码可控 | 无 | 执行任意工具；需要沙箱与最小权限 |
| 并发单位 | 请求 | 请求 / batch | 会话（session）；一个会话内部串行，会话之间并行 |
| 失败 | 异常、超时 | 超时、OOM | 幻觉、死循环、预算耗尽、工具半成功——大多不是异常 |
| 资源瓶颈 | CPU / DB | GPU 显存与算力 | 模型 API 配额与费用、沙箱资源、等待中的会话数 |
| 最接近的老概念 | Web 框架 | 数据库引擎 | 工作流引擎 / durable execution（Temporal 一类）+ actor + 沙箱 |
这解释了几件事：为什么 LangGraph 要把 agent 建成带 checkpoint 的状态图；为什么各家都在推”agent runtime”作为独立产品；为什么直接用 Web 框架写 agent 会在”用户关了页面、任务还在跑”和”服务重启、任务从头开始”上撞墙。运行时要提供的核心能力：持久化与恢复、挂起与唤醒（等人、等外部事件）、事件流（把每一步推给前端）、预算与超时、沙箱管理、会话隔离。
长程任务：人从环内退到环上、环外
agent 能自主跑多久，不是模型能力单独决定的，是一组工程手段叠出来的。这些手段的演进顺序，也是人从 human-in-the-loop（逐步批准）退到 human-on-the-loop（监控与抽检）再到 human-out-of-the-loop（无人在环）的路径：
| 阶段 | 关键技术 | 人的位置 |
|---|---|---|
| 单步问答 | prompt、检索 | 每一步都是人发起 |
| 短循环 agent | ReAct、工具调用、逐步审批 | in the loop：每个有副作用的动作都要确认 |
| 长循环 agent | 持久化与断点续跑、上下文压缩、外置计划（todo / plan 文件）、子 agent 隔离上下文、自动验证循环（测试、lint、仿真） | in the loop，但审批粒度变粗：按风险分级，只读自动、写入确认、不可逆二次确认 |
| 策略化授权 | 权限白名单、风险分类器、预算上限、沙箱、可回滚的动作设计 | 从”逐个批”到”批一类”：人定策略，运行时执行 |
| 后台异步 agent | 任务队列、异步交付（提 PR、生成报告草稿）、事件通知 | on the loop：人看结果、看仪表盘、抽检轨迹、处理告警，不看过程 |
| 无人在环 | 只在可自动验证 + 可回滚的动作上；持续的轨迹评测与回归；异常自动降级回环内 | out of the loop，但有退路 |
每上一级，都是把某类验证从人手里交给系统。不能自动验证的动作（给客户发合同）停在 in the loop；能验证但不可逆的动作（删数据库）停在 on the loop 加二次确认；可验证可回滚的（改代码提 PR、跑数据分析）可以走到 out of the loop。自动驾驶的 SAE 分级是同一条路径最严格的版本：L2 是人在环内（随时接管）、L3 是人在环上（系统请求时接管）、L4 / L5 是人在环外，每升一级都对应验证体系（仿真里程、影子模式、安全冗余）的一次量级跳跃，而不是模型换了一代。
| 主题 | 概念 | 说明 |
|---|---|---|
| 工具调用 | function calling 的契约（schema、参数校验、返回格式）；工具描述的写法决定模型用不用对；工具数量与选择准确率的关系；并行工具调用 | 工具是 agent 的手；描述写不好，手就不听话 |
| MCP | Model Context Protocol：把工具、资源、prompt 模板以统一协议暴露给任何模型客户端；server / client 架构、传输方式、鉴权 | 工具生态的”USB 接口”，是这一层最值得学的协议 |
| 循环与规划 | ReAct（思考-行动-观察）、plan-and-execute、反思与自我修正；推理模型对显式规划的替代 | 大多数任务一个 ReAct 循环就够 |
| 状态与持久化 | 多步任务的状态放在哪；中断与恢复；durable execution（每步持久化、崩溃后继续）；状态机建模。LangGraph 在这里作为抓手：它把 agent 显式建成有状态的图，checkpoint 每一步，是理解”agent 运行时”最直接的参考实现——不是因为它是标准，而是这个概念没有具体实现很难讲清 | 后端工程师的老朋友：工作流引擎与状态机 |
| memory | 会话内记忆（上下文本身）、跨会话记忆（用户偏好、历史事实）的存储与检索、记忆的写入策略与遗忘 | 本质是一个特殊的 RAG |
| 多 agent | 什么时候需要（上下文隔离、并行、专业化）；orchestrator-workers、handoff、层级；agent 间协议（A2A 一类）；多 agent 的成本与调试代价 | 多 agent 不是默认选项：先用一个 agent 加更好的工具 |
| 沙箱与安全 | 代码执行沙箱（容器、microVM）、文件系统与网络隔离、工具的最小权限、prompt injection 通过工具返回进入上下文的风险 | agent 的每一个工具都是攻击面 |
| 人机协作 | 哪些动作需要确认（不可逆、高成本、对外）、确认的粒度、人在环内的交互设计、审批的持久化 | 人机分工是 L7 的产品问题，也是这里的运行时问题 |
| 可靠性 | 幂等的工具设计、失败重试与回退、循环检测、步数与 token 预算、超时、部分结果的交付 | agent 的失败是常态，设计要假设失败 |
三个 harness 案例
模型之外的一切——工具、上下文管理、权限、验证、沙箱、可观测——业内叫 harness（马具）。场景轴的三个格子各取一个最成熟的案例，它们的 harness 组件一一对应，取值不同。
案例一：coding agent（IT × 数字）。 Claude Code、Cursor Agent、Codex 一类是当前最成熟的 agent 产品，因为代码场景可自动验证，它们把循环做到了几十步：
| Harness 组件 | coding agent 里的做法 | 通用意义 |
|---|---|---|
| 工具集 | 读文件、搜索（grep / glob）、编辑、执行命令、浏览器；工具少而正交 | 工具集设计：给模型”手”而不是”按钮” |
| 上下文管理 | 项目说明文件（如 AGENTS.md）作为常驻上下文；按需读文件而不是全量塞入；长会话自动压缩；子 agent 隔离探索性搜索的上下文 |
上下文预算（L2）在长任务里的实践 |
| 权限模型 | 只读工具自动执行、写与执行需确认、可配置白名单、危险操作二次确认 | 图中”权限与风险检查”的实例 |
| 验证循环 | 改完跑测试、lint、类型检查，结果回到上下文，模型自己修 | 自动验证是 agent 自主性的来源；业务场景要找自己的”测试” |
| 沙箱 | 工作目录隔离、命令执行的限制、网络访问控制 | 安全边界 |
| 可观测 | 每一步的工具调用、token 消耗、耗时可见；trace 可回放 | L5 的 trace 在 agent 上的形态 |
案例二：本体驱动的业务 agent（业务 × 数字）。 Palantir Foundry 的 Ontology 与其上的 AIP 是业务侧最完整的 harness 样本。它先把企业数据建成本体——对象（客户、订单、设备）、属性、关系，以及每类对象允许的动作（改派、审批、下单）与权限——然后让 agent 在本体上工作，而不是直接碰数据库表和 API：
| Harness 组件 | 本体驱动的做法 | 对应 coding agent 的 |
|---|---|---|
| 工具集 | 本体动作：有类型、有校验、有权限的业务操作，而不是裸 SQL / 裸 API | 读 / 写 / 执行工具 |
| 上下文管理 | 按对象与关系取数：agent 看到的是”这个客户的这几笔订单”，不是全表 | 按需读文件 |
| 权限模型 | 权限挂在对象与动作上，agent 继承发起人的权限；动作分自动 / 需审批 | 只读自动、写入确认 |
| 验证循环 | 动作有前置校验与业务规则；结果写回本体可追溯；审批流是验证的一部分 | 测试、lint |
| 沙箱 | 动作先生成”提案”，人审批后才落库（写入的暂存区） | 工作目录隔离 |
| 可观测 | 每个动作有发起人、依据、时间的审计链 | trace |
它回答了 AI4业务最难的那一格——业务动作没有”测试”可跑，怎么验证？ 答案是把验证前移到本体：动作被类型、规则、权限约束住，agent 能做的错事范围被结构性地压小，剩下的交给审批。这就是为什么本体在 agent 时代重新流行：它不是检索技术，是业务世界的 harness。
案例三：自动驾驶（业务 × 物理）。 自动驾驶栈是这张地图在物理世界的完整映射，而且每一格都被推到了最严格的取值：
| Harness 组件 | 自动驾驶的做法 | 与数字世界 agent 的差别 |
|---|---|---|
| 模型 | 感知（检测、分割、占据网络）→ 预测 → 规划的模块化栈，或端到端模型；VLM / VLA 与世界模型在进入量产栈 | 车端实时推理、算力受限、多模型协同 |
| 上下文 | 多传感器融合（摄像头、激光雷达、毫米波、超声波）、高精 / 轻地图、车辆状态、时序帧 | 上下文是连续的数据流，不是一次组装 |
| 动作 | 转向、油门、制动的连续控制；经底盘控制系统执行 | 不可撤销、毫秒级、物理约束 |
| 权限与安全 | 功能安全（ISO 26262）、预期功能安全（SOTIF）、冗余传感与算力、最小风险策略（安全停车） | 权限模型变成安全架构 |
| 验证循环 | 仿真闭环（场景库、日志重仿真、传感器仿真、世界模型生成）、影子模式（新版本在车上跑但不控车，与人类驾驶对比）、封闭场地与公开道路测试、接管率与每接管里程 | 验证是独立的一门工程（L5 仿真一节），成本是数字世界的几个量级 |
| 数据飞轮 | 接管与 corner case 自动回传 → 自动标注 / 数据挖掘 → 重训 → OTA 推送 | 与 L6 的数据飞轮同构，规模大得多 |
| 人机分工 | SAE L0–L5；驾驶员监控（脱手 / 脱眼检测）、接管请求与接管时间 | 自主级别是产品定义，由验证体系决定 |
| 可观测 | 车端日志与事件回传、事故重建、轨迹回放 | 与 L5 的录制回放同构 |
自动驾驶告诉这张地图两件事。第一，能力层是通用的：换掉模型（LLM → VLA）、换掉工具（MCP → 控制系统）、换掉输入（对话 → 传感器），层次不变。第二，自主级别的上限由验证与可逆性决定：行业花了十几年、数十亿公里把 L2 做到量产、L4 做到限定区域，不是因为模型不够聪明，而是每升一级都要把验证体系重建一次。数字世界的 agent 正在走同一条路，只是可逆性给了它更多犯错的余地。
建设 harness 的人——给 agent 配工具、定权限、管上下文、搭验证——是每个格子里都在出现的新角色：IT 侧的平台工程师、业务侧的本体 / 流程工程师、物理世界的仿真与安全工程师。把这三张表套到任何一个新场景上，缺哪一格，agent 就在哪一格失控。
L5 评测、可观测与可追溯
怎么知道改了之后更好了？非确定性的系统怎么调试、怎么复现一次失败？
evals 之于 AI 应用，如同单元测试之于软件——区别是 AI 应用没有 evals 连”能跑”都不能确认。这是应用工程师与”会调 API 的人”的分水岭。
| 主题 | 概念 | 说明 |
|---|---|---|
| 评测集 | golden set 的构造（从真实流量采样、覆盖边界与失败案例、人工标注期望）、规模（几十条就能开始，几百条能看趋势）、持续补充（线上 bad case 回流） | 评测集是 AI 应用最重要的资产，比 prompt 重要 |
| 评分方式 | 精确匹配与规则（能自动验证的优先）、LLM-as-judge（评分标准、参考答案、pairwise 对比）及其偏差（位置、长度、自我偏好、宽容度）、人工评审的抽样与一致性 | judge 也要被评测：与人工标注的一致率 |
| 评什么 | 单步：准确率、格式正确率、faithfulness；RAG：检索与生成分开（L3）；agent：任务完成率、步数与成本、工具调用正确率、轨迹评测（过程对不对，不只结果） | agent 的评测最难，也最缺 |
| 回归与门禁 | 每次改 prompt / 模型 / 检索参数跑全量评测集；CI 里的评测门禁；模型供应商静默升级带来的回归 | “换了个模型版本效果变差”是常态 |
| 在线评测 | A/B 与灰度、隐式反馈（采纳、重试、放弃）、显式反馈（点赞点踩、纠正）、在线指标与离线评测集的校准 | 离线好不等于在线好 |
| trace 与可观测 | 每次请求的完整链路（prompt、检索结果、工具调用、模型输出、token、耗时、成本）；OpenTelemetry 的 GenAI 语义约定；Langfuse / LangSmith / Arize Phoenix 一类工具（点名） | 没有 trace 的 agent 无法调试 |
| 运行时可靠性 | guardrails（输入输出检查、话题与格式约束）、fallback（换模型、降级到规则）、幻觉检测（引用校验、一致性检查）、置信度与”拒答” | 在评测发现之前，先在运行时兜底 |
非确定性系统的可追溯实践
传统调试假设”同样的输入得到同样的输出”，模型打破了这个假设。让一个 agent 的失败可复现、可解释、可归因，有一组已经成形的做法：
| 实践 | 做法 | 解决什么 |
|---|---|---|
| span 级 trace | 每次模型调用、每次工具调用、每次检索各是一个 span，记录完整输入输出、模型版本、采样参数、token 与耗时；会话 → 任务 → 步骤三级树 | “它为什么这么做”——回到那一步它看到了什么 |
| 录制-回放 | 把每次模型响应按 span 录下来；调试时回放录制的响应而不是重新调用模型，复现同一条轨迹；改了工具或解析逻辑后用录制回放做回归 | 把非确定性从调试与测试里剔除 |
| 决策点日志 | 在 agent 循环的每个分支（选了哪个工具、为什么终止、权限检查结果、预算余量）打结构化事件，而不是只留模型文本 | 让状态机可视化：轨迹图而不是日志流 |
| 轨迹级评测 | 对整条轨迹评分（任务完成、步数、成本、是否走了不必要的弯路、是否越权），不只看最终输出；抽样送人工与 judge | agent 的失败常在过程里 |
| 生产 trace 上的在线评测 | judge 按比例跑在真实流量的 trace 上，指标进监控与告警；离线评测集从这里补充 | 离线集覆盖不到的失效模式 |
| 版本对比 | 同一评测集在两个 prompt / 模型 / 工具版本下的轨迹 diff：哪些 case 由对变错、哪一步开始分叉 | 回归定位 |
| 反馈绑定 | 用户点赞点踩、纠正、接管，都带 trace id 落库 | 从”用户说不好”到”哪一步不好” |
| 失败分类学 | 给失败打类型：检索未命中、指令未遵循、工具返回被截断、幻觉、权限拒绝、预算耗尽…… 按类型统计而不是按条数 | 决定该改哪一层 |
| 敏感数据处理 | trace 里的 prompt 与输出含用户数据：脱敏、分级存储、保留期限、访问审计 | 可观测与合规的冲突 |
自动驾驶把同一套实践做到了极致：车端事件回传、事故的传感器数据重建与轨迹回放、影子模式下新旧版本的逐帧对比——都是 span 级 trace、录制回放与版本对比在物理世界的形态。
物理世界的评测基础设施：仿真
数字世界的 agent 可以在测试环境里随便跑；物理世界的 agent 不能——每一次实车、实机测试都贵、慢、有风险，而要覆盖的场景（暴雨夜晚的施工路段、风机叶片的罕见裂纹、电网的极端负荷）在现实里等不到。所以物理世界的 AI 应用多出一层数字世界没有的基础设施：仿真。它承担的角色相当于数字世界的评测集 + 测试环境 + 数据生成器三者之和。
| 仿真形态 | 做法 | 用途 |
|---|---|---|
| 场景仿真 | 用场景描述语言（OpenSCENARIO 一类）定义交通参与者、天气、路网，在仿真器（CARLA、各厂自研）里闭环运行整套栈 | 覆盖长尾场景、回归测试、把一次事故变成可重复的用例 |
| 日志重仿真 | 把实车录下的传感器数据回放给新版本的栈，比较它与旧版本 / 人类的决策 | 用真实数据做回归；开环（不影响录制的世界）为主 |
| 传感器仿真与合成数据 | 渲染摄像头、激光雷达、雷达的物理级信号；生成带标注的训练与测试数据 | 补真实数据的稀缺场景；标注免费 |
| 数字孪生 | 对一座变电站、一个风场、一条产线建高保真模型，实时同步物理状态 | 能源与工业场景的仿真基座；在孪生上试策略再下发 |
| 世界模型作为学习型仿真器 | 用生成模型预测”如果这样操作，下一帧世界是什么样”（GAIA、Cosmos 一类） | 可控生成罕见场景；正在与传统仿真器融合 |
| 硬件在环 / 软件在环 | HIL：真实控制器接仿真的传感与执行；SIL：全软件 | 验证栈在真实算力与时延约束下的行为 |
仿真带来自己的工程问题：
| 问题 | 内容 |
|---|---|
| sim-to-real gap | 仿真里过、现实里不过；传感器噪声、材质、动力学的失真；用真实数据校准仿真器，用域随机化让模型不依赖仿真的细节 |
| 场景覆盖 | 怎么知道测够了：场景库的构成、参数空间的采样、覆盖率指标（ODD 覆盖）、从实车 corner case 自动生成变体 |
| 开环 vs 闭环 | 开环评测便宜但不反映”决策改变世界”的效应；闭环才能测规划与控制 |
| 保真度 vs 规模 | 高保真跑得慢、覆盖少；低保真跑得快、可信度低；分层：低保真筛、高保真验 |
| 仿真的可信度 | 仿真器本身要被验证——它与现实的偏差要可量化；否则仿真通过率是一个没有含义的数字 |
对能源、无人机、工业机器人，替换掉”车”和”路”，这张表一样成立：电网的潮流仿真、风机的气动仿真、机器人的物理引擎（Isaac Sim、MuJoCo 一类），都在扮演同一个角色。数字世界的 agent 工程正在借这个思路：用模拟的用户与环境（沙箱里的文件系统、模拟的 API、合成的用户）做 agent 的闭环评测，本质上就是仿真。
L6 生产化与运营
成本、延迟、安全、发布、回滚，以及数据怎么回流？
| 主题 | 概念 | 说明 |
|---|---|---|
| 模型接入 | 通过模型网关接多供应商（统一 API、路由、fallback、配额、计费）；应用侧使用网关，网关的建设属于 Infra 地图 09 | 不要在每个应用里各写一遍供应商适配 |
| 成本 | token 账：输入 / 输出 / 缓存 / 思考 token 分别多少；prompt caching 的前缀设计；小模型分流（路由简单请求）；批处理接口；上下文裁剪；缓存语义相同的请求；按用户 / 功能的 token 预算与告警 | 成本是 AI 应用最容易失控的指标 |
| 延迟 | 流式输出（感知延迟）、TTFT 的来源（上下文长度、排队）、并行工具调用、预取与投机（提前检索）、模型选择（小模型快）、超时与降级 | 用户感知的是 TTFT，不是总时长 |
| 安全 | prompt injection（直接与间接——通过网页、文档、工具返回注入）、越狱、系统 prompt 泄漏、数据泄漏（把私有数据发给模型、模型输出中的 PII）、工具的最小权限与沙箱、输出内容安全；防御的分层（输入过滤、权限、输出检查、人工确认）而不是指望一个过滤器 | 间接注入是 agent 时代最重要的新攻击面 |
| 治理与合规 | 审计日志（谁在什么时候让模型做了什么）、数据驻留与供应商条款、用户数据是否用于训练、模型版本的记录、AI 生成内容的标识 | 面向企业客户的必答题 |
| 发布 | prompt / 模型 / 检索配置的版本化与灰度、评测门禁、回滚；供应商模型的弃用周期 | 把 prompt 当代码发布 |
| 数据飞轮 | 线上反馈 → bad case → 评测集补充 → prompt / 检索迭代；积累到一定规模 → 微调数据（选修）；用户纠正作为标注 | 这是 AI 应用长期护城河的来源 |
物理世界的上线流程
数字世界的发布是”评测门禁 → 灰度 → 全量 → 回滚”，几小时到几天。物理世界的发布多了仿真与实机的层层关卡，几周到几个月，而且”回滚”本身可能不安全（一辆行驶中的车不能回滚到上一版）：
| 阶段 | 做什么 | 门禁 |
|---|---|---|
| 仿真回归 | 全量场景库 + 日志重仿真 | 关键场景零退化；覆盖率达标 |
| 硬件在环 | 在目标算力与实时约束下跑 | 时延、算力占用、故障注入下的降级行为 |
| 封闭场地 / 实验室 | 实车、实机、有安全员 | 预定义测试用例通过 |
| 影子模式 | 新版本部署到量产设备上运行但不控制，决策与现役版本 / 人类操作逐帧对比，差异回传 | 差异率与差异类型可解释 |
| 限定范围放量 | 特定车队、区域、时段、天气（ODD）；安全员或远程监控 | 接管率、事件率优于现役版本 |
| 全量 OTA | 分批推送，保留回退版本；监控接管与事件 | 事件率不劣化 |
| 数据回流 | 接管、事件、罕见场景自动回传 → 挖掘 → 标注 → 进场景库与训练集 | 闭环 |
影子模式是这条流程里最有价值的一环，也是数字世界可以直接借用的：新版本 prompt / 模型在生产流量上并行运行但不出结果，与现役版本对比——这就是 L5 的版本对比在线做。能源与工业场景的对应物是在数字孪生上先跑、再在一台设备 / 一条线上试、再推全厂。
L7 产品与体验
什么场景值得做？人和模型怎么分工？不确定性怎么呈现？
| 主题 | 概念 | 说明 |
|---|---|---|
| 场景选择 | 模型擅长什么（生成、总结、分类、抽取、对话、代码）；错误代价与验证成本决定形态；”demo 到产品的鸿沟”——demo 展示的是上限，产品交付的是下限；ROI：省了谁的时间、值多少 | 好场景的特征：错误可容忍或可验证、有明确的人工基线 |
| 形态选择 | copilot（人主导，模型建议）→ agent（模型主导，人审批）→ 自动化（无人在环）；同一场景随可靠性提升逐步升级 | 与场景轴一节的验证方式对应 |
| 人机分工 | 信任的建立与校准：过度信任与不信任都是失败；让用户知道模型在做什么、做到哪；可撤销、可修改、可接管 | 人机协作设计是 AI 产品区别于传统产品的核心 |
| 不确定性的呈现 | 流式输出、引用与溯源、置信度与”我不确定”、多候选、生成过程可见（agent 的步骤） | 让用户能判断，而不是让用户相信 |
| 交互形态 | 对话不是唯一形态：内嵌到工作流、批处理、后台 agent、语音；对话式界面的局限（发现性差、不可预测） | “加个聊天框”往往是最差的集成方式 |
| 产品指标 | 任务完成率、采纳率（建议被接受）、人工介入率、纠正率、用户留存；成本 / 任务；与 L5 在线评测打通 | 用产品指标而不是模型指标判断成败 |
横切：评测驱动开发
没有评测集的改动只是猜。
对应算法地图的”实验方法论”，这一层的核心纪律是：
| 纪律 | 内容 |
|---|---|
| 先有评测再有 prompt | 第一个原型就配几十条评测样例；改任何东西先跑评测 |
| 看 trace 不看感觉 | 效果差先看 trace：是检索没找到、prompt 没说清、工具返回被截断，还是模型本身不行 |
| 一次改一处 | prompt、模型、检索参数、工具描述同时改，就不知道哪个起了作用 |
| 从 bad case 出发 | 线上失败案例进评测集，比凭空设计样例有效十倍 |
| 校准 judge | LLM 评分要定期与人工抽检对齐 |
| 记录一切 | 每次评测的配置、模型版本、结果可追溯；三个月后能解释为什么当时选了这个方案 |
选修
- 微调作为应用手段：决策在 L3 第 1 节；这里补充执行——数据准备（从 trace 与反馈里筛高质量样本）、评测集先于训练、微调后的回归与版本管理。微调的方法（SFT、LoRA、DPO、蒸馏）属于算法地图 L5。
- 自托管推理：数据不能出域、成本到了自托管更便宜的规模、需要开源模型的特定能力。部署与优化属于 Infra 地图 08、09；应用工程师要会的是判断何时值得、以及自托管带来的接口与能力差异。
- 语音与多模态交互：语音输入输出（ASR / TTS / 实时语音 API）、图片与文档理解在产品里的用法、多模态对上下文成本的影响（一张图几百到几千 token）。
- 端侧模型：小模型在设备上运行的场景（隐私、离线、延迟）、能力边界、与云端模型的分工。
与另两张地图的关系
三张地图用一条规则分工：
应用地图回答”用什么、怎么组合、效果好不好”；算法地图回答”模型怎么造”；Infra 地图回答”模型怎么跑”。
| 重叠主题 | 应用地图负责（本图） | 算法地图负责 | Infra 地图负责 |
|---|---|---|---|
| 模型 | 作为组件的契约、失效模式、选型 | 结构、训练、能力 | serving：调度、KV、多卡 |
| 模型网关 | 使用：接入、路由、fallback | — | 建设：多租户、配额、可观测（09） |
| 微调 | 何时需要、数据准备、效果评测 | 配方：SFT / LoRA / DPO | 训练基础设施（07） |
| 评测 | 应用效果：任务完成率、faithfulness、在线指标 | 模型能力：benchmark、LLM-as-judge 方法论 | 性能：吞吐、延迟、MFU |
| embedding / rerank | 选用与调参 | 训练与对比学习 | 向量检索的算力 |
| 上下文与 token | 预算、缓存前缀、成本 | 上下文窗口与位置编码 | KV cache 与 prefill 成本（04、08） |
| 安全 | prompt injection、工具权限、PII | 对齐与拒答训练 | 平台层的隔离与审计 |
| 可观测 | trace：prompt、工具、token、成本 | 训练曲线 | GPU 指标、请求级指标 |
| 成本 | 按 token 的账 | 按训练算力的账 | 按 GPU 小时的账 |
| Agent | 编排、工具、harness | agent 能力的训练（RL、工具使用数据） | RL 后训练的 rollout 基础设施（选修） |
三张地图的交点：应用工程师读 Infra 地图 08 前两篇能理解 token 计费与延迟形态的来源；读 04 系列的 KV cache 与多模态两篇能理解长上下文与图片为什么贵。反过来，Infra 与算法工程师读本图能知道自己的产出被怎样使用、评测与反馈从哪里来。
按目标选择路径
| 目标 | 路径 | 说明 |
|---|---|---|
| 做业务 AI 应用（客服、助手、知识库） | L1 → L2 → L3 → L5 → L6 → L7 | RAG 是主战场；L4 在需要动作时补 |
| 做 AI4IT / coding agent / harness 建设 | L1 → L2 → L4（重运行时与 harness 案例）→ L5 → L6 | 平台工程师的新方向；验证循环与权限模型是核心 |
| 做物理世界应用（自动驾驶、无人机、能源与工业） | 场景轴 → L4（运行时、自主级别、案例三）→ L5（可追溯、仿真）→ L6（上线流程、数据飞轮）；模型部分走算法地图 | 用本图建立应用栈的框架；仿真是这条路径独有的基础设施 |
| 产品经理 / 技术负责人 | L1 → L7 → L5 → 场景轴 → L4（概念层） | 判断场景与形态、看懂评测结果、知道 agent 化的上限在哪 |
| 后端工程师转 AI 应用 | L1 → L2 → L5 → L3 → L4 → L6 | 已有的服务、数据库、API 经验直接复用；新东西是组件观与评测 |
边界与说明
不在地图上的内容
- 模型训练与微调方法：属于算法地图。本图只讲何时需要微调与怎么准备数据。
- 推理引擎与平台内部：serving、网关建设、GPU 集群。属于 Infra 地图。本图只讲如何使用。
- 通用后端与前端知识：Web 框架、数据库、消息队列、前端框架。假设已具备；本图只讲 AI 组件带来的差异。
- 行业知识：金融、医疗、法律等领域的业务逻辑与合规。它们决定场景，但不属于这张地图。
- 具身智能的模型与硬件：感知 / VLA / 世界模型的训练属于算法地图；车端芯片、实时操作系统、底盘控制属于嵌入式与汽车电子；仿真器本身的实现（渲染、物理引擎）属于图形学与 CAE。本图只讨论物理世界应用作为应用栈的组装、仿真验证、上线流程、数据闭环与自主级别演进。
版本与时效
这一层变化最快的是框架与产品，最稳定的是协议与模式：OpenAI 兼容 API、MCP、ReAct 循环、三类检索与 agentic retrieval、durable execution、evals 与 trace 的方法论。地图以后者为骨架；框架只作代表点名，其中 LangGraph 因为”有状态的 agent 运行时”这个概念需要一个具体实现来讲清而被用作抓手，不代表它是标准。模型能力的提升会不断把某些工程手段变得不必要（更长的上下文、更好的指令遵循、内置的工具使用），地图会随之更新，但”在非确定性组件之上做可靠产品”这个问题不会消失。
关于”AI 应用工程师”
这张地图的目标是能判断一个场景值不值得做、把它做成可交付的产品、并用评测证明它有效的工程师。它同时要求产品判断与工程实现，因为在这个领域两者分不开：形态选择（copilot 还是 agent）既是产品决定也是可靠性决定，评测集既是工程资产也是对”效果好”的产品定义。
最终目标
读完这张地图上的内容之后，面对一个业务需求，读者应该能够沿着整个链路追问下去：
| 追问 | 答案来自 |
|---|---|
| 这个场景模型能做吗？错误代价与验证成本允许什么形态？ | L7 · 场景轴 |
| 该用 prompt、RAG 还是微调？长上下文能不能替代检索？ | L2 · L3 · 选修 |
| 私域知识该进上下文还是进权重？用 grep、向量还是本体？ | L3 |
| 检索没找到还是生成没说对？ | L3 · L5（分开评） |
| 这个 agent 为什么在第 17 步做了那件事？能复现吗？ | L5（trace、录制回放） |
| 这个场景能让人退到环上吗？缺的是模型还是验证？ | L4（自主级别）· 场景轴 |
| 这个物理世界的应用测够了吗？仿真通过意味着什么？ | L5（仿真）· L6（上线流程） |
| agent 在第几步失控了？哪个工具该要人确认？ | L4 · trace |
| 改了 prompt 之后是变好了还是变差了？ | L5 · 横切 |
| 一个请求花了多少钱、慢在哪一段？ | L1 · L6 |
| 用户为什么不信它 / 过度信它？ | L7 |
| 供应商换了模型版本，怎么第一时间知道？ | L5 回归 · L6 发布 |
三张地图到这里闭合：造模型的人、跑模型的人、用模型的人，各自知道自己站在哪里、隔壁在做什么、边界上的事该谁负责。
本文由 arganzheng 创作，采用 CC BY 4.0 许可协议。在保留原文作者、署名以及完整原文链接（https://arganzheng.life/ai-application-engineer-learning-roadmap.html）的前提下，欢迎各种形式的转载、翻译或商业引用。
COMMENTS
评论存放在 GitHub Discussions， 用 GitHub 账号登录即可发表，支持 Markdown。 想针对正文某句话说？选中那段文字，点浮出的「评论」即可划线评论；觉得哪里写错了，发表时勾上「同时提交 Issue」。 有人回复你时 GitHub 会按你的通知设置发邮件，不用守在这里。