AI Agent 通用知识地图#

这是一张「AI Agent 开发通用知识地图 + DocMind 落点索引」。其余 16 篇文档都是「DocMind 怎么做的」，这一篇补的是「这个领域应该知道什么」——L1→L8 分层的通用知识。

用法：面试官问到任何一层，先在这里找到坐标和通用原理，再跳到对应实现文档看 DocMind 的落地。每个主题都标注了「DocMind 落点」：✅ 已落地（指向实现文档）/ ⚠️ 部分落地 / ⭕ 领域通识，DocMind 未实现（知道方向即可，面试坦诚说明）。

原则：DocMind 没真做的，这里只讲原理 + 标 ⭕，绝不假装成项目实现——「句句可追溯到源码」是这套文档的可信度底线。

整体分层#

┌─────────────────────────────────────────────────────────────┐
│ L8 前沿方向   多Agent协作 / 长期记忆 / Agent评估 / RL训练     │
├─────────────────────────────────────────────────────────────┤
│ L7 工程化     可观测 / 成本控制 / 容错 / 安全 / 部署          │  ← DocMind 主场
├─────────────────────────────────────────────────────────────┤
│ L6 框架&协议  LangGraph / MCP / A2A / 编排框架                │
├─────────────────────────────────────────────────────────────┤
│ L5 Agent架构  ReAct / Plan-Execute / 多Agent拓扑             │  ← DocMind 主场
├─────────────────────────────────────────────────────────────┤
│ L4 RAG        检索增强 / Agentic RAG / GraphRAG              │  ← DocMind 主场
├─────────────────────────────────────────────────────────────┤
│ L3 工具调用    Function Calling / MCP tool / 结构化输出       │
├─────────────────────────────────────────────────────────────┤
│ L2 Prompt工程  指令设计 / few-shot / CoT / 输出约束           │
├─────────────────────────────────────────────────────────────┤
│ L1 LLM基础     Transformer / 推理参数 / 上下文窗口 / 局限     │
└─────────────────────────────────────────────────────────────┘

一句话定位：Agent 的整套工程（L2–L8）本质上都是在补 L1 那些 LLM 的固有短板——幻觉、知识截止、无状态、不可靠推理。理解这条主线，比记住任何单个技术名词都重要。

L1 LLM 基础#

不用会训练大模型，但要懂它作为「组件」的特性和边界。⭕ 本层基本是领域通识，DocMind 是 LLM 的使用方而非实现方。

Transformer / 自回归（直觉）#

• Self-Attention：每个 token 生成时「看」上下文里所有 token，按相关性加权——这是 LLM 能理解长程依赖的根。直觉上是「软性的、可微的查表」。
• 自回归生成：LLM 一次只预测下一个 token，把它接到输入末尾再预测下一个，循环直到结束符。⟹ 推论：生成是顺序的、不可并行的，这就是流式输出（逐 token 吐）和 TTFT 指标的物理来源。
• Tokenization（BPE/subword）：文本先被切成 subword token 再喂模型。中文一个汉字常 ≈1–2 token，英文一个词可能拆成多个 token。⟹ 按 token 计费、context 预算都建立在这上面。

上下文窗口与 context rot#

• Context Window：模型单次能处理的 token 上限（输入+输出共享）。
• Context Rot（上下文腐烂）：⚠️ 关键反直觉——塞进去的 context 越多，召回反而可能下降。模型对长上下文「中间段」的信息利用最差（lost-in-the-middle）。⟹ 这正是 RAG 要做精排、压缩、只塞 Top-K 的根本原因，而不是「context 越大越好」。
• DocMind 落点：✅ 上下文压缩见 03-检索与排序链路 与 05-工程化实践「上下文压缩」；会话历史膨胀与 context rot 的关系见 08-RAG系统痛点分析 P7。

推理参数#

关键认知：temperature>0 是 RAG 系统不确定性的来源之一——同一个问题两次回答可能不同，也是为什么工具选择、路由这类决策 DocMind 用规则引擎而非 LLM（见 L5 / 02）。

LLM 四大固有局限（→ DocMind 补偿机制）#

面试话术：

“我理解 Agent 工程的主线就是补 LLM 的四个固有短板：幻觉用 RAG + 反思补，知识截止用联网补，无状态用记忆补，推理不可靠就把确定性决策从 LLM 手里拿出来交给规则引擎。DocMind 的每个模块基本都能对应到这四条里的某一条。“

L2 Prompt 工程#

Prompt 不是「咒语」，是可控的接口设计。⚠️ DocMind 在 05「Prompt 工程」节有落地（7 模板 + PromptAssembler 三模式），本节补通用方法论。

• 清晰指令 + 角色设定：给模型明确身份和任务边界，比模糊指令稳定得多。
• Few-shot：给 1–N 个输入输出范例，让模型「照着做」——对格式约束、风格对齐尤其有效。DocMind 的 query_decompose.txt 就含 3 个 few-shot 例子（05）。
• CoT（思维链）：让模型「先推理再给答案」（“让我们一步步想”），显著提升多步推理准确率。代价是更多 token、更长延迟——简单任务别滥用。
• 输出约束（正向）：
  • JSON mode / 结构化输出：API 层强制模型只吐合法 JSON，降低解析失败率。
  • XML 标签分隔：用 <context>...</context> / <question>...</question> 把指令区和数据区分开，既提升遵循度，也是抗 prompt 注入的缓解手段（文档内容藏指令时不易越界）。
  • ⚠️ 关键认知：正向约束（JSON mode）降低出错概率，但不能 100% 保证——仍需输出后容错（剥壳、白名单、降级），见 05「LLM 的 JSON 不可信」。两者是「事前约束 + 事后兜底」的组合。

面试话术：

“对小模型吐结构化结果这件事，我的态度是双保险：prompt 侧用 JSON mode / few-shot 例子做正向约束把出错率压下来，代码侧做剥壳 + 字段白名单 + fallback 兜底——因为再强的约束也挡不住偶发的格式抽风。这也是为什么我把它当成接口设计而不是写咒语。“

L3 工具调用（Function Calling）#

Agent 区别于纯聊天机器人的分水岭。✅ DocMind 用 Spring AI @Tool 暴露 6 个工具端点（02「MCP 工具双路复用」/14）；但 MCP 协议全貌 DocMind 只用了 tool 子集，本节补协议规范（⭕ 部分为通识）。

Function Calling 协议本质#

• 模型只「输出」调用意图，不执行：LLM 返回「我想调 web_search(query="...")」这个结构化意图，真正的执行在你的代码里。执行结果再回喂给 LLM 决定下一步。这是 Agent loop 的核心一拍。
• JSON Schema 定义工具：每个工具用 JSON Schema 描述名字、参数、类型——模型据此知道有哪些工具、怎么填参。
• 错误回灌（error feedback）：⭕ 工具执行失败时，把错误信息作为 observation 回喂给 LLM，让它重试或换策略——这是「让 LLM 自主纠错」的通用做法。DocMind 未用 LLM 原生错误回灌：工具调度走规则引擎并行派发，失败走确定性降级链（02「完整降级链」），而非让 LLM 看着错误重想。这是有意取舍——确定性 > 灵活性。
• 并行工具调用：⭕ 现代模型支持单轮返回多个工具调用意图并行执行。DocMind 的并行是规则引擎层面的 Worker 并行派发（RetrievalPlanner 决定调哪几个 Worker → 线程池并发），不是 LLM 原生并行 tool calls——概念上区分清楚。

MCP（Model Context Protocol）规范#

面试话术：

“MCP 我落地的是 tool 这一类原语——把 DocMind 的 6 个检索工具用 Spring AI 暴露成 MCP 端点，外部 Agent/IDE 能直接调。但 MCP 协议本身比这大：底层是 JSON-RPC 2.0，传输有 Streamable HTTP 和 SSE 两种，原语除了 tool 还有 resource（读数据）和 prompt（共享模板），有完整的 initialize 握手和能力协商。我现在只用了 tool 子集——这是 MVP 阶段够用的选择，安全边界和 resource 暴露是规划里的下一步（见 02 MCP 安全边界）。”

追问预判：“你的工具调用是 LLM 选的还是规则选的？” → DocMind 主路径是规则引擎选工具（RetrievalPlanner，4 信号映射），保留 LLM Function Calling 作降级路径。理由见 02/05 规则引擎四层价值。

L4 RAG（DocMind 主场，✅ 覆盖最全）#

本层 DocMind 几乎全覆盖，这里只做「通用知识点 → 实现文档」的索引，不重复细节。

面试话术：

“RAG 是我这个项目的主场，从基础的混合检索 + RRF + Cross-Encoder 重排，到 Agentic RAG 的 CRAG 三档评分 + 条件补偿检索 + 问题拆解，再到离线评估体系都做了。要展开哪一块我都能指到具体的类和评测数据。“

L5 Agent 架构#

核心范式要能讲清适用场景和 trade-off。✅ DocMind 当前落地了真·LLM 工具调用 agentic 循环（受约束的 ReAct：4 个读工具 + 1 个沙箱计算工具白名单 + 手动控环 + max_iterations 兜底）与 Supervisor-Worker（一次性检索兜底路径）。Plan-and-Execute、自研 Query Decomposition、自研串行多跳、Self-Reflection 均曾落地、后在「对标主流四刀改造」中移除——拆解 / 多跳由 agentic 循环运行时自驱，置信度改由结构化引用覆盖率给出（见 04 #21/#22、20-改造实现设计）。本节补真多 Agent 拓扑（⭕）和 HITL（⭕）。

三种核心范式对比#

ReAct                  Plan-and-Execute        多 Agent
─────                  ────────────────        ────────
思考→行动→观察→再思考    先规划全流程→逐步执行     按角色拆分:
（边走边想）            （可重规划）             Planner/Worker/Critic/Router
适合：探索性、          适合：步骤明确、          适合：复杂任务分治、
不确定路径             减少中途漂移             需要专业化分工

其余能力#

• 任务分解：✅ Query Decomposition，见 03。
• 记忆管理：短期（对话历史拼接）vs 长期（外部存储）。✅ 跨会话长期记忆见 05——三层存储 MySQL SoR + Redis 缓存 + Milvus 向量召回；通用记忆体系（episodic/semantic/consolidation）作为扩展方向见 07。
• 反思 / Reflexion：✅ DocMind 的 Self-Reflection 是单轮重写（02）。⭕ 学术上的 Reflexion 范式更进一步：把每次失败的反思写入 episodic memory，跨多次尝试积累经验——DocMind 未做这种带记忆的多轮反思循环。
• 人在回路（HITL）：⭕ 关键动作前暂停等人确认/修正（如高风险操作、低置信答案让人介入）。DocMind 未实现 HITL；最接近的是低置信度警告徽章（提示用户人工核验），但不是阻断式的人工确认。

面试话术：

“ReAct、Plan-and-Execute、多 Agent 我会按任务确定性来选：路径不确定的探索型用 ReAct 边走边想，步骤明确要防漂移的用 Plan-and-Execute 先规划后执行，需要专业化分工的才上多 Agent。DocMind 落地了 ReAct 和 Supervisor-Worker；Plan-and-Execute 我 Phase 2 实现过，但发现它规划早于检索、处理不了链式多跳，就删了改用串行有界迭代——这本身是个’加了又删’的取舍故事。我也会坦诚说我的 Supervisor-Worker 是规则编排 + 无推理 Worker，不是真正意义上每个 Worker 都能自主推理的多 Agent——那是下一步方向。“

L6 框架与协议#

⭕ 本层多为横向对比知识。DocMind 用 Spring AI（✅），其余框架/协议作为通识掌握，重点是「能区分各自解决什么问题」。

编排框架定位#

Agent 相关协议对比#

「不用框架怎么实现这个 loop」（高频追问）#

面试官常问这个来探底层理解。答案就是手写 Agent loop：

loop:
  1. 把 (system prompt + 历史 + 工具 schema) 喂给 LLM
  2. LLM 返回：要么是最终答案 → 结束
              要么是工具调用意图 → 解析出 tool + args
  3. 在代码里执行该工具，拿到 observation
  4. 把 observation 追加进上下文，回到第 1 步
  直到 LLM 给出最终答案或达到 max_iterations

DocMind 的 02「ReAct Agent 执行模型」本质就是这个手写 loop 的工程化版本——不依赖 LangGraph 这类框架，用 Java 直接编排。底层原理比框架 API 更重要，框架只是把这个 loop 包装得更好用。

L7 工程化（DocMind 最强项，后端出身的护城河）#

✅ 本层几乎全覆盖，是相对算法背景候选人的差异化优势。这里做索引，细节全在 05。

补充概念：context editing（运行时动态裁剪/重写已进入上下文的内容，区别于一次性压缩）——⭕ DocMind 未单独实现，上下文压缩是入 prompt 前的一次性裁剪。

面试话术：

“工程化是我作为后端工程师的护城河。算法背景的候选人可能 L1–L5 更扎实，但’怎么把 Agent 稳定、低成本、高可用地跑在生产’——超时分层、降级链、有界线程池反压、Langfuse 全链路 trace、双模型成本分级——这些是我能拿满分的地方，也是大厂 Agent 工程岗最缺的能力。“

L8 前沿方向#

⭕ 面试加分项，知道方向即可，不必假装做过。DocMind 大多未实现，诚实标注。

面试话术：

“前沿方向我保持关注但不会硬包装成做过的。真正的多 Agent 协作、MemGPT 式的长期记忆、computer use 这些我知道在解决什么问题、技术路线大概是什么，但 DocMind 没实现——我更愿意把已经做的工程化深度讲透，而不是堆没落地的名词。“

实操建议：面试该怎么用这张地图#

真正的优势在 L7。 算法/研究背景的候选人 L1–L5 可能更扎实，但「如何把一个 Agent 系统稳定、低成本、高可用地跑在生产环境」，正是后端工程师该拿满分、也是 ByteDance/Alibaba 这类公司招 Agent 工程岗最缺的能力。

建议在 DocMind 上把 「评估平台 + 成本/延迟优化 + 容错」 讲成完整故事（05/09/10），这比再堆一个新框架更有说服力。

用法口诀：被问到任何一层 → 在本图找坐标和通用原理 → 跳对应文档讲 DocMind 落地 → 遇到 ⭕ 标记就坦诚说「这是方向，我没做，但我知道它解决什么问题」。坦诚边界比假装全做过更可信。