Agent开发知识点

Created2026-10-08|Updated2026-10-08|面经

|Word Count:10.8k|Reading Time:35mins|Post Views:

Agent开发知识点

本文按《大厂Agent面试题库·分类整理》的 T1~T11 主题体系整理 Agent 开发知识点。各章标题为「专业技能(Agent)」章节已有标题与题库主题的合并结果：已有知识标题保留在前，题库新增主题列在其后，内容逐章填入。T12 Java 后端八股不在此文，见《Java后端面经》与《计算机基础》等。

当前为标题骨架，内容待整理。

Agent范式与架构

什么是AIAgent?与传统LLM区别

AIAgent(人工智能智能体)是一种能够感知环境、进行决策并执行动作以实现特定目标的autonomous系统。与传统的LLM(大语言模型)相比，核心区别在于:

传统LLM本质上是一个”静态的文本生成器”，它接收输入文本并生成输出文本，整个过程是一次性的、无状态的(除了当前的上下文窗口)。可以将其认为是一个专业顾问，你问它问题，它给你建议，但它不能去执行任何操作。

AIAgent则是一个”有自主意识的执行者”，它由四个核心组件构成:

LLM(大脑):负责推理、规划和决策
规划(Planning):将复杂任务分解为可执行的子任务
- ReAct 模式(Reasoning + Acting)是目前最主流的 Agent 执行框架。

记忆(Memory):短期记忆(当前会话上下文)+长期记忆(知识库存储)

类型	存在哪里	举例	工程实现
In-context	上下文窗口	当前对话历史	直接放入 Prompt
External	文件 / 数据库	任务计划文件、执行日志	读写本地文件或 DB
Semantic	向量数据库	相似代码片段、历史规范文档	RAG 检索
In-weights	模型参数	模型训练时学到的知识	微调(通常不需要)

工具使用(ToolUse):通过调用外部API、执行代码等方式与真实世界交互
- Tools: 大模型本身不能”执行”任何操作。它能做的，是输出一段结构化的 JSON，描述它想调用哪个函数、传什么参数。你的代码拿到这个 JSON，真正去调用对应的函数，再把结果返回给模型。这个机制就叫 Function Calling，是所有工具使用的底层基础。
- MCP: Anthropic 推出的工具接入标准协议，解决的是工具如何被 Agent 发现和调用的问题。
- Skills: Skill 是比单次工具调用更高层的抽象。类比:Tool 是函数，Skill 是封装好的模块/服务。

Agent的基本架构组成

Agent 在能力层面可以概括为”一个大脑 + 四个外挂”，在工程层面可以概括为”接入 / 编排 / 工具 / 存储 / 可观测”五层。概念题用能力组件视角答，系统设计题用工程分层视角展开。

能力组件视角：一个大脑 + 四个外挂

            LLM (大脑 / 决策中枢)
                    │
                    │ 驱动
    ┌─────────┬─────┴─────┬─────────┐
    ▼         ▼           ▼         ▼
Planning   Memory      Tools   Perception/IO
任务拆解   短/长期记忆  MCP/工具调用   输入/输出

组件	职责
LLM	推理、决策，是整个系统的”思考中枢”
Planning	把复杂任务拆解成子任务，决定执行顺序（ReAct / Plan-and-Execute）
Memory	短期（上下文窗口）+ 长期（向量库 / 数据库）的状态保留
Tools	与外部世界交互的能力，通过 Function Calling / MCP 暴露
Perception / Action	感知输入（文本 / 图片 / 语音），执行输出（API / UI / 文件）

一句话总结：Agent = LLM 做大脑，Planning 给路线图，Memory 当笔记本，Tools 是手脚。

工程分层视角：五层

层	职责	常见实现
接入层	接收用户输入、流式返回	IM / Web 入口、SSE 流式
编排层	意图路由、任务拆解、循环调度	路由引擎、Agent Loop / 状态机
工具层	工具注册、调用、异常治理	ToolExecutor、MCP Server
存储层	会话状态、长期记忆、知识库	Redis 会话、向量库、关系库
可观测层	埋点、评测、告警	分环节埋点、在线 / 离线评测

LLM 是决策核心，决定能力上限；但工程上最容易出问题、最体现功力的是编排与记忆——模型能力是地基，任务拆解和上下文管理决定长任务能不能稳定跑完。

Workflows与自主Agent区别

Workflow 是开发者画好路线让 LLM 走，Autonomous Agent 是 LLM 自己边走边画路线。前者用灵活性换可预测性，后者用可预测性换灵活性。

维度	Workflows	Autonomous Agents
控制流	开发者预定义（if/else、DAG）	LLM 动态决策
可预测性	高，路径固定	低，每次可能不同
灵活性	低	高
调试难度	容易，按节点排查	难，需要 Trace 还原决策
成本	可控	易失控（循环、重试）
适用场景	流程稳定、规则明确（订单审批、请假审核）	任务多变、需要探索（Coding Agent、调研报告）

选型：

流程能不能完全枚举？能 → 固定 DAG Workflow，路径写死，可预测、好排查。
下一步是否依赖中间结果？是 → 在分叉点引入 LLM 决策节点。
解空间是否开放、需要探索试错？是 → 才上自主 Agent，用状态图承载循环与分支。

演进路径：不要一上来就做全自主 Agent。先用 Workflow 把流程跑通，观察哪些节点经常需要临场处理，再把自主权逐步下放给这些节点，从确定性流程渐进过渡到 Agent。

混合实践：生产系统通常两者混用——确定性环节（校验、审批、写数据）用 Workflow 钉死，只把真正需要临场判断的节点（意图理解、方案生成）交给 Agent。

Anthropic 的建议：能用 Workflow 解决的就别上 Agent。先评估任务复杂度，不要为了”显得高级”硬上 Autonomous Agent。

Todo工具在Agent中的作用

Todo 工具让 Agent 把任务计划显式持久化到外部，是长任务 Agent 的”任务清单 + 进度条”。

作用机制：计划不只存在于上下文里，而是写进外部工具 / 文件，Agent 每轮先重读 Todo 再决定下一步——即使上下文被压缩或截断，目标也不会丢。这就是它同时能抗 Context Rot、支持中断恢复的原因。

核心作用:

作用	解释
防止跑偏	强制 Agent 先列计划再执行，约束推理路径
进度可见	用户能看到 Agent 当前在干什么、下一步是什么
抗 Context Rot	计划写在外部文件/工具中，不怕被压缩丢失
支持中断恢复	任务跑一半挂了，下次根据 Todo 继续
Compaction 友好	即使上下文被压缩，Todo 还在，任务不丢

典型工作流:

用户: 帮我重构这个模块
  ↓
Agent → TodoWrite([
   "1. 分析现有代码结构",
   "2. 列出需要拆分的类",
   "3. 编写新结构",
   "4. 迁移测试",
   "5. 跑通 CI"
])
  ↓
Agent → 执行 step 1 → 完成后 TodoUpdate (1 → completed)
  ↓
... 循环 ...

与 checkpoint 的分工：Todo 外化的是”要做什么”（计划），checkpoint 外化的是”做到哪了”（执行状态），两者互补——Todo 保证任务目标不丢，checkpoint 保证执行能从断点恢复。

Claude Code 的 TaskCreate/TaskUpdate 就是典型 Todo 工具。Anthropic 的设计经验:有 Todo 的 Agent，长任务完成率提升明显。

ReAct框架

原理：ReAct（Reasoning + Acting）让大模型在思考和行动之间交替循环，每一步都先推理再执行，而不是一股脑输出最终答案。核心循环为 Thought（分析当前状态，决定下一步）→ Action（调用工具/执行操作）→ Observation（获取工具返回结果）→ 判断是否足够 → 不够则回到 Thought，足够则输出 Final Answer。

┌─────────────────────────────────────────────────┐
│                  用户输入 Query                   │
└──────────────────────┬──────────────────────────┘
                       ▼
          ┌───→ Thought(思考)    ← 分析当前状态，决定下一步该做什么
          │          │
          │          ▼
          │    Action(行动)     ← 调用工具 / 执行操作
          │          │
          │          ▼
          │   Observation(观察) ← 获取工具返回的结果
          │          │
          │          ▼
          │     ┌──────────┐
          │ 否  │ 够了吗？   │
          └──── └────┬─────┘
                     │ 是
                     ▼
              ┌──────────────┐
              │ Final Answer │  ← 输出最终结果
              └──────────────┘

一个典型交互示例：

Question: "iPhone 16 的电池容量是多少毫安时？"

Thought 1: 我需要查找 iPhone 16 的电池规格，让我搜索一下。
Action 1:  search("iPhone 16 电池容量 mAh")
Observation 1: 搜索结果显示 iPhone 16 配备 3561mAh 电池...

Thought 2: 我已经拿到了准确数据，可以回答了。
Action 2:  finish("iPhone 16 的电池容量为 3561mAh。")

优缺点：

优点：可解释性强，每一步都有 Thought，能看到推理过程、方便调试；通过实际调用工具获取事实，减少幻觉；根据每步 Observation 动态调整策略，灵活迭代。
缺点：每步都要一次 LLM 调用，长任务延迟和 Token 成本累积；局部决策缺乏全局规划，任务一长容易跑偏、绕圈甚至死循环；效果依赖工具 Observation 的质量，工具报错会把推理带偏。

适用任务与场景：问答、搜索、工具调用、Coding Agent 等需要与外部环境交互的任务；绝大多数生产 Agent 的默认范式。

解决了什么问题：解决纯推理模型”凭记忆编造、无法与外部世界交互”的问题，让思考和行动同步推进——即”怎么把当前这一次任务做完”。

Plan-Execute框架

原理：把规划和执行拆成两个阶段。先由 Planner 一次性产出完整任务计划（步骤列表），再由 Executor 逐步执行；执行结果可以回传给 Replanner 动态修订剩余计划（Plan → Execute → Replan 循环）。与 ReAct”走一步看一步”不同，Plan-Execute 是”先画完整路线图再出发”。

优缺点：

优点：计划显式可见，便于人工审查、断点续跑和进度追踪；规划与执行分离，Planner 可以用强模型、Executor 用便宜模型，成本结构更优；对长任务有全局结构，不容易像 ReAct 那样中途跑偏。
缺点：计划赶不上变化，前期规划与实际不符时必须靠 Replan 兜底，否则整条计划作废；多了一个规划环节，首 Token 延迟更高；任务高度动态、信息不全时，一次性规划的质量有限。

适用任务与场景：步骤依赖清晰、链路较长的任务，例如多步数据处理、报告生成、项目级代码改造；需要向用户展示计划或支持中断恢复的场景。

解决了什么问题：解决 ReAct 局部决策缺全局结构、长任务易跑偏的问题，把”做什么”（规划）和”怎么做”（执行）解耦。

Reflexion框架

原理：Reflexion（Shinn et al. 2023，Northeastern + MIT）在 ReAct 基础上引入”失败反思 + 经验复用”机制——Agent 把每次尝试失败的教训以自然语言反思的形式存进长期记忆，下一轮重试时把反思作为上下文输入，避免重复同样的错误。本质是用 Verbal Reinforcement Learning（语言强化学习）替代传统 RL 的权重更新。核心三组件：Actor（执行 Agent，通常就是一个 ReAct Agent，产出轨迹）、Evaluator（规则/LLM/外部信号打分，返回 reward 或成功标记）、Self-Reflection（失败时产出语言反思，写入长期记忆），配合短期记忆（当前轨迹）与长期记忆（反思档案）双层结构。

┌──────────────────────────────────────────────────────┐
│                   用户输入 Task                       │
└──────────────────────┬───────────────────────────────┘
                       ▼
       ┌──────────────────────────────┐
       │ Long-Term Memory(反思档案)     │ ← 历次失败的反思文本
       │ "上次因为 X 出错，下次先做 Y"    │
       └──────────────┬───────────────┘
                      │ 注入到下次尝试的上下文
                      ▼
       ┌──────────────────────────────┐
       │ ① Actor(执行 Agent)          │ ← 通常就是一个 ReAct Agent
       │   产出 Trajectory(轨迹)       │
       └──────────────┬───────────────┘
                      ▼
       ┌──────────────────────────────┐
       │ Short-Term Memory(当前轨迹)    │
       └──────────────┬───────────────┘
                      ▼
       ┌──────────────────────────────┐
       │ ② Evaluator(评估器)           │ ← 规则 / LLM / 外部信号打分
       │   返回 reward / success flag   │
       └──────────────┬───────────────┘
                成功  │  失败
              ┌──────┴──────┐
              ▼             ▼
            返回      ┌──────────────────────────┐
                      │ ③ Self-Reflection(反思)   │
                      │   产出语言反思: "我哪里错   │
                      │   了，下次该怎么改进"       │
                      └────────────┬─────────────┘
                                   │ 追加到 Long-Term Memory
                                   └──→ 回到 Actor 重试(带反思)

优缺点：

优点：无需微调，用自然语言反思替代权重更新，零训练成本；跨 trial 学习，能从历次失败中积累经验而不只在单次轨迹内推理；反思本身是自然语言、可解释、可审计；小样本即生效，常常 2~3 轮反思就显著提升成功率（HumanEval、AlfWorld、HotpotQA 论文均有验证）。
缺点：必须有可靠的 Evaluator 信号（自动评分器/单元测试/人工标注），否则反思方向会错；反思文本要做长度控制，否则长期记忆越积越多撑爆上下文；不适合单次性任务（没机会重试）或没有客观评测指标的开放生成场景。

适用任务与场景：有重试机会且可量化评测的场景——代码生成（跑测试）、刷题（看对错）、博弈（看胜负）、需要多次尝试的决策任务。

解决了什么问题：解决”多次尝试怎么越做越好”的问题——把失败教训沉淀为可复用的语言经验，下次少踩坑；与 ReAct 是上下层关系而非替代：ReAct 管单次任务内怎么执行，Reflexion 在外面包一层”评估 → 反思 → 重试”的元循环。

Self-Refine框架

原理：Self-Refine（Madaan et al. 2023）是”生成 → 自评 → 修改”的三段循环：Generator 先产出初稿，同一个 LLM 扮演 Critic 对初稿给出批评意见，Refiner 再根据批评修订；如此迭代 2~3 轮后输出终稿。全程在单次任务内完成，不调用外部工具，也不需要外部 Evaluator——模型自己当裁判。

优缺点：

优点：不需要外部评分信号，落地成本低，加一段 Prompt 就能实现；对写作、报告、代码 Review 这类”输出质量型”任务增益明显；批评和修订都是自然语言，过程可解释。
缺点：自评自改存在盲区，模型发现不了自己认知之外的事实性错误，幻觉改不掉；提升有边际递减，通常 2 ~ 3 轮后收益趋零；每轮自评加修改，Token 成本约为 2 ~ 3 倍；在调工具的 Agent 链路里，其功能常被 ReAct 的工具 Observation 覆盖，额外收益有限。

适用任务与场景：单次产出、无外部评测信号但希望提升质量的场景：文案写作、报告生成、代码 Review、翻译润色。

解决了什么问题：解决”一次性生成质量不够、又没有外部评分器”的问题，让模型在单轮内自评自改。与 Reflexion 的关键区别：Self-Refine 留在单次任务内、不需要外部 Evaluator；Reflexion 跨多次 trial、必须有外部 reward。

CoT框架

原理：Chain-of-Thought（Wei et al. 2022，Google）让模型先显式输出推理过程、再给最终答案，把”一步到位”改成”逐步推导”。触发方式很轻：Prompt 里加一句”Let’s think step by step”（Zero-shot CoT），或在示例里带上推理过程（Few-shot CoT，两者可叠加）。

优缺点：

优点：实现成本极低，一句提示词即可；对数学、逻辑、多步推理类任务准确率提升显著；推理链可见，便于排查模型在哪一步想错。
缺点：输出变长，Token 成本和延迟上升；对简单任务是浪费；推理链本身也可能错（中间步骤幻觉）；强模型（Opus、GPT-4 级别）已内化 CoT 能力，显式提示词可以省略。

适用任务与场景：数学题、逻辑推理、代码调试、多步决策等推理过程重要的任务；也常作为其他范式（ReAct 的 Thought、ToT 的分支）的底层思考方式。

解决了什么问题：解决大模型”直接给答案容易错”的问题——通过强制展示中间推理步骤，把复杂问题拆成若干简单步骤，提高准确率。

ToT框架

原理：Tree of Thoughts（Yao et al. 2023，Princeton + Google DeepMind）把 CoT 的”单条线性推理链”升级为”多分支推理树 + 自评 + 搜索回溯”。核心三件套：Thought Generator（每步采样 N 个候选 thought，典型 N=3 ~ 5）、State Evaluator（LLM 给每个候选打分，如 sure/maybe/impossible 三档或 1 ~ 10 分）、Search Algorithm（BFS 每层保留 Top-K，或 DFS 深度优先 + 回溯），遇到死胡同可以回到上一步换分支。

CoT(单条链):               ToT(多分支树 + 搜索):

  Q                              Q
  ↓                          ┌───┼───┐
Thought 1                   T1a T1b T1c    ← 每步生成多个候选
  ↓                          ↓   ↓   ↓
Thought 2                   评分 8  3  6   ← LLM 自评
  ↓                          剪枝:保留 Top-2 → T1a, T1c
Answer                       ↓       ↓
                          ┌──┼──┐ ┌──┼──┐
                          T2a T2b T2c T2d  ← 继续展开
                          ↓
                       ... 遇死胡同则回溯换分支 ...
                          ↓
                         Answer(从最优路径产出)

优缺点：

优点：多候选 + 自评 + 选优，对需要规划、探索、试错的复杂问题效果最好；支持回溯，走错能回头换分支；ToT 是 CoT 的严格泛化——分支数 N=1 且不做评分时就退化为 CoT。
缺点：Token 成本 10~100 倍（每步 N 倍候选 + 评分 + 搜索）；延迟高，多次串行调用 LLM；工程复杂度高，需自行实现 Generator、Evaluator、Search 三件套；适用条件苛刻，任务必须有明确对错标准且解空间可离散化。

适用任务与场景：24 点、填字游戏、复杂规划、博弈决策等需要多解空间探索的任务。工业界实际落地极少，通常被 Self-Consistency（多次采样 CoT 投票）、Best-of-N（生成 N 个选最优）等简化方案替代。

解决了什么问题：解决 CoT”一条路走到黑、错了无法回头”的问题，用搜索和回溯换取复杂问题上的更高正确率。

ReAct/Plan-Execute/Reflexion/Self-Refine/CoT/ToT对比

六个概念的一句话总结表：

框架	核心循环	解决的问题	主要优点	主要缺点	典型场景	Token 成本
ReAct	Thought → Action → Observation	思考 + 行动同步推进，完成任务	可解释、减幻觉、灵活迭代	长任务易跑偏、成本累积	问答、工具调用、Coding Agent	中
Plan-Execute	Plan → Execute → Replan	先全局规划再逐步执行	结构清晰、可断点续跑、规划执行分离	计划失准需重规划、首 Token 延迟高	长链路多步任务、项目级改造	中
Reflexion	Trial → Evaluate → Reflect → Retry	从失败中积累经验、跨任务越做越好	无需微调、跨 trial 学习、可解释	必须有可靠 Evaluator、反思需控长	代码生成（带测试）、博弈、可重试任务	高
Self-Refine	Generate → Critique → Refine	单次输出质量自校	无需外部评分器、落地简单	自评盲区、收益边际递减	写作、报告、代码 Review	中–高
CoT	单条 Thought 链 → Answer	显式推理提高准确率	一句提示词即可、推理可见	输出变长、强模型已内化	数学、逻辑、多步推理	1x（基准）
ToT	多分支 Thought 树 → 自评 → 搜索	复杂规划 / 探索 / 试错	多候选 + 回溯、正确率上限高	成本 10~100x、工程复杂	24 点、填字、复杂规划	10~100x

按”作用层 × 改进时机 × 工程成本”横向对比：

维度	ReAct	Plan-Execute	Reflexion	Self-Refine	CoT	ToT
提出时间/来源	Yao et al. 2022（Princeton + Google）	工程界通用模式（LangGraph Plan-and-Execute 模板）	Shinn et al. 2023（NEU + MIT）	Madaan et al. 2023（CMU 等）	Wei et al. 2022（Google）	Yao et al. 2023（Princeton + Google DeepMind）
作用层	推理 + 行动（执行层）	任务编排（规划层）	经验复用（元学习层）	输出质量（自校验层）	推理结构（思考层）	推理结构（思考层）
改进时机	单步内（边想边做）	执行前规划 + 执行中重规划	跨 trial（多次尝试间复盘）	单次任务内（生成后自评自改）	单次推理内（线性展开）	单次推理内（多分支并行）
是否调工具	✅ 核心	✅（执行步骤通常调工具）	✅（Actor 通常是 ReAct）	❌（纯文本生成）	❌（纯思考）	❌（纯思考）
是否多候选	❌	❌	❌	❌	❌	✅（每步 N 个）
是否需 Evaluator	❌（依赖工具 Observation）	❌（靠 Replan 判断）	✅（必须可靠的外部 reward）	❌（LLM 自评）	❌	✅（LLM 自评）
是否能回溯	❌（错了往前走或停）	✅（Replan 修订剩余计划）	❌（trial 内不回溯，靠下次重试）	❌（线性改）	❌（一条路走到底）	✅（可换分支）
Token 成本	中（每步 1 次 LLM）	中（规划 1 次 + 每步执行）	高（trial × N + 反思）	中–高（自评 + 修改 2~3 次）	1x（基准）	10~100x

关系图（叠加关系）：六种范式不是互斥选项，而是不同层次的机制，生产系统通常叠加使用——

┌─────────────────────────────────┐
│      跨任务经验层(元学习)          │
│   Reflexion = 外层 Evaluator      │
│              + 反思档案          │
└─────────────────────────────────┘
              ▲ 包裹
┌─────────────────────────────────┐
│     任务编排层(先规划再执行)        │
│        Plan-Execute             │
└─────────────────────────────────┘
              ▲ 拆解为步骤
┌─────────────────────────────────┐
│     单任务执行层(Agent Loop)      │
│           ReAct                 │
│   (Thought → Action → Obs)      │
└─────────────────────────────────┘
              ▲ 调用
┌─────────────────────────────────┐
│       单次推理层(怎么想)           │
│       CoT / ToT                 │
│       (单链 vs 多分支搜索)        │
└─────────────────────────────────┘
              ▲ 输出后
┌─────────────────────────────────┐
│       输出自校层(轻量改写)         │
│       Self-Refine                │
│  (Generate → Critique → Refine)  │
└─────────────────────────────────┘

选型决策树（按场景一句话挑）：

要让 Agent 用工具完成任务                   → ReAct
任务长、步骤依赖清晰、要先出计划             → Plan-Execute(配 Replan)
有重试机会 + 可量化评测(如代码跑测试)     → ReAct + Reflexion 叠加
单次输出想要更高质量，没有外部 Evaluator     → Self-Refine
让模型"显式推理"提高数学/逻辑题准确率        → CoT
任务需要规划/试错/多解空间探索               → ToT(或 Self-Consistency 简化版)
日常 Agent 默认选                            → ReAct + CoT 内化(强模型自带)

工业实战经验：

80% 的生产 Agent 用 ReAct + 强模型自带 CoT 就够，不需要显式叠加其他范式。
Reflexion 适合代码、博弈这种”有客观对错”的场景——编译器、单测、胜负都是天然 Evaluator；薪酬 AI 质检项目里的”Self-Refine + 编译器 Verifier”循环其实就是 Reflexion 的轻量变体（把跨 trial 压缩到单次任务内 3 轮）。
ToT 实际生产落地极少，多数被 Self-Consistency（多次采样 CoT 投票）和 Best-of-N（生成 N 个选最优）替代，工程实现简单一个量级且效果接近。
Self-Refine 在写作、报告生成场景增益明显；但在 Agent 调工具的链路里，通常被 ReAct 的工具 Observation 覆盖了同样功能。
Plan-Execute 与 ReAct 的取舍：任务结构稳定、需要用户确认计划或断点续跑时选 Plan-Execute；任务高度动态、信息边走边明时选 ReAct。两者也可组合——外层 Plan-Execute 出计划，每个步骤内部用 ReAct 执行。

什么是Agent Loop

Agent Loop 是 Agent 执行引擎的主循环：组装上下文 → 调用 LLM → 解析输出 → 若有工具调用就执行工具并把结果写回上下文 → 再调 LLM，如此循环，直到模型给出最终答案或触发终止条件。它就是 ReAct 范式的执行载体——Thought / Action / Observation 分别对应循环里的”模型思考 / 输出 tool_call / 工具结果写回”。

构造一个 Loop 需要六个模块：

模块	职责
上下文组装器	把 system prompt、历史消息、工具结果拼成 messages，溢出时先压缩 / 截断
LLM 调用层	屏蔽模型协议差异（tool_result 嵌套 vs 独立 tool 角色），支持流式
输出解析器	区分文本回复与 tool_call；JSON 解析失败要有修复 / 重试兜底
工具注册表 + 执行器	按 schema 注册工具，参数校验、调用、异常捕获
循环控制器	终止条件：无 tool_call、最大轮数、超时、token 预算
状态持久化	消息历史 / checkpoint 落盘，中断后可恢复（短任务可省）

三个容易漏掉的设计点：

工具异常不要抛出中断循环，而是把错误信息当成结果写回上下文，让模型自己决定换参数重试还是放弃；
max_rounds 是必须的熔断，否则模型反复调同一个工具会一直空转，烧 token 也烧时间；
终止信号要显式：要么靠”无 tool_call”，要么设一个 finish 工具，不要靠猜文本语气。

MiniClaw 就是按这个结构做的最小实现：Brain → Hands → Brain 工具循环（最多 10 轮防死循环），Brain 抽象层屏蔽 Anthropic tool_result 嵌套与 OpenAI 独立 tool 角色的协议差异，上层统一 Message / ToolCall 数据结构。

手写最小可用Agent循环

手写最小循环（核心十几行）：

def agent_loop(user_input, tools, max_rounds=10):
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": user_input},
    ]
    for _ in range(max_rounds):
        resp = llm_chat(messages, tools=[t.schema for t in tools])

        # 没有工具调用 = 最终答案，退出循环
        if not resp.tool_calls:
            return resp.content

        messages.append(resp.to_message())

        # 逐个执行工具，结果写回上下文供下一轮决策
        for call in resp.tool_calls:
            try:
                result = tools[call.name].run(**call.args)
            except Exception as e:
                result = f"工具调用失败: {e}"
            messages.append({"role": "tool", "tool_call_id": call.id,
                             "content": str(result)})

    return "达到最大轮数，任务终止"

Agent完整执行链路

完整链路一般分七个环节（以菜小蜜的实现为例）：

入口接收：协议接入（IM / Web / HTTP），开启 Trace，全程用同一个 TraceId 串联日志。
会话准备：输入校验、会话构建 / 复用、加载历史对话、组装请求级上下文对象（身份、会话、历史贯穿全链路）。
前置拦截：规则链把高频标准问题短路掉（特殊指令、转人工、FAQ 精确匹配），不调 LLM、毫秒级延迟，未命中才放行。
意图路由：决定这次请求交给哪个能力处理（技能路由、语种检测、Query 改写可并发跑）。
技能分发：按路由结果查注册表，拿到具体工具 / 技能实现。
主执行：Agent Loop / RAG / 业务工具执行，最重的一步。
收尾：语种回译、引用来源整理、落库、空答案兜底（转人工 / 工单卡片）。

每轮LLM调用的预处理和后置校验

每轮 LLM 调用前的预处理：

上下文组装：system prompt + 历史消息 + 工具结果，按角色规范拼好顺序；
上下文治理：历史超阈值先压缩 / 截断（compaction）再进模型；
工具列表收敛：按权限和场景过滤工具（圈人过滤、渐进式披露），别把所有工具都塞进 prompt；
输入校验：长度、合法性、敏感内容；
预算检查：token 预算、轮数是否超限，超了先熔断。

每轮 LLM 调用后的后置校验：

格式校验：结构化输出能否解析，失败则重试、修复提示或降级；
工具调用校验：工具是否存在、参数是否过 schema、危险操作是否要审批；
内容安全：输出侧过滤（敏感信息、诱导注入内容）；
终止条件判断：是否最终答案、是否该结束循环；
可观测落盘：轮数、token 消耗、模型决策，关联 TraceId。

Agent任务状态机怎么设计

为什么需要状态机：长任务动辄跑几分钟到几小时，进程崩溃、人工审批、网络抖动都可能中断；纯内存执行一旦中断只能从头再来，写操作还可能做了一半。

状态定义：CREATED → PLANNING → RUNNING → WAITING_TOOL / WAITING_HUMAN → COMPLETED / FAILED / CANCELLED，每次流转必须有明确事件，不允许随意跳转；按需支持 PAUSED。

四个能力的实现要点：

能力	实现要点
可追溯	状态流转做成 append-only 日志（状态 + 事件 + 时间戳 + 触发者）；每步保留完整证据：prompt、模型版本、工具输入输出、审批记录，出问题能回答”哪一步放过去的”
可暂停	危险操作（删数据、对外发送、转账）前设 INTERRUPT 中断点，等人工审批（HITL）；支持外部暂停信号
可续跑	步骤边界把状态持久化到 checkpoint（DB / Redis），恢复时从最近 checkpoint 继续，不重跑已完成步骤；步骤设计要幂等，重复执行无副作用
可回滚	写操作记录快照或补偿操作，失败时按序回滚或标记人工介入；非幂等工具要防重放（去重键）

实现选型：LangGraph 用 interrupt() + Checkpointer（MemorySaver 开发、PostgresSaver 生产）；重场景用 Temporal / Step Functions 这类工作流引擎；自研就是状态表 + 事件日志 + 步骤边界持久化。

两个工程细节：只在步骤边界持久化，不要在步骤中间存，否则恢复逻辑会很复杂；恢复时要校验状态版本兼容——Agent 代码升级后，旧 state 要能被解析。

用户指令不明确时Agent如何自主拆任务补全信息

三层处理，按优先级依次来：

能补的先补：先查上下文——历史对话、用户画像、长期记忆。典型工程实现是 Query 改写：补全指代（”那这个呢？”→ 前文提到的具体对象）、关键词扩展、身份信息补全。
能拆的就拆：让 LLM 把目标拆成子任务清单（Todo / Plan），逐步执行，中间结果出来再修正拆解（Plan-Execute + Replan）。拆解时标注依赖和优先级，独立子任务并行执行。
该问的才问：关键信息缺失且无法可靠推断时，向用户反问。两个细节：一次把要问的合并问完，别一句一打断；设置置信度阈值，高于阈值直接执行，低于阈值再问或转人工。

工程红线：

默认值要显式：推断出的信息要告知用户”按默认值 X 执行”并允许修改，不能静默假设；
写操作必须确认：数据订正、提交、发送这类危险操作，执行前必须让用户确认参数。菜小蜜智能请假就是这个流程——解析请假参数 → 匹配假期额度 → 发确认卡片 → 用户点确认才真正提交；
宁停不编：信息不足时降级（反问 / 转人工），不要脑补，fail-close。

Agent 开发流程有几个环节?

六个环节：

需求定义：明确任务边界、验收标准、哪些环节自动化、哪些留给人；先判断 Workflow 能不能解决，别硬上 Agent。
能力设计：工具清单、Prompt 结构、上下文与记忆方案、模型选型（路由小模型 / 主力大模型）。
原型实现：最小 Loop 先跑通主链路，先硬编码后动态化，先单工具后多工具。
评测建设：评测集 + 指标（任务完成率、工具调用准确率、幻觉率）；先有自动打分的裁判，再谈优化。
迭代优化：bad case 驱动改进，调 Prompt / 工具 / 流程；A/B 或灰度验证后再放量。
生产上线：可观测（埋点、告警）、成本与限流、安全防护（注入、权限）、兜底与人工接管入口。

两点区别于传统开发的认知：一是评测先于优化，没有评测集，调 Prompt 就是盲调，改完不知道是变好还是变坏；二是上线不是终点，bad case 回流和持续迭代才是 Agent 的常态。

本地 Agent 为什么会空转?怎么解决?

Planner和Critic的分工?Critic如何识别幻觉和工具无效结果?

多诉求任务拆分与调用拆分取舍

快慢任务兼容(对话式快任务 vs 复杂慢任务)

Workflow 首任务错误放大问题

上下文工程与记忆

为什么”记忆”对Agent至关重要

假如让你设计记忆管理你会如何设计

上下文溢出/分层记忆/Compaction

什么是ContextRot?如何防止

上下文压缩放在loop哪一步?触发机制?具体策略

多轮对话如何保证记忆一致性、避免前后矛盾/信息丢失

记忆覆盖问题如何解决

长期Memory应该在什么条件下写入

Redis在Agent系统里存什么?会话状态/缓存/记忆/checkpoint/限流怎么区分?

多用户高并发时会话隔离和记忆隔离怎么做?

记忆库持续膨胀、检索精度下降怎么迭代?

怎么沉淀部门级记忆/知识库?怎么解决”经验随人走”?

Skill和Memory的沉淀怎么设计?

多Agent间上下文传递：全量还是核心结论?状态同步怎么避免信息错乱?

Agent会话上下文怎么存储?MySQL瓶颈怎么优化?Redis会话丢失怎么办?

为什么限制上下文长度?长文档如何优化?

Memory与上下文工程的边界

记忆有效性与质量(事实vs推断/噪声过滤)

记忆注入与检索重排机制

历史记忆复用降本

工具与协议

Function Calling/MCP区别

Tool Calling的JSONSchema设计最佳实践

Tool Handler(工具调度器)的设计原则

工具调用失败后如何降级

如何保证ToolCalling的可靠性

Agent为什么会陷入死循环?如何检测和解决

MCP/Tools/Skills在Context中的引入顺序

MCP的OAuth2.1授权流程

MCP生态的Prompt Injection与工具描述污染

MCP/A2A区别

MCP 2026-07-28规范核心变化(无状态化)

Skills渐进式披露

如何设计高质量的SKILL.md?有哪些常见反模式

Agent系统中如何实现Skill的动态发现与编排

skill和tool的区别

Function Calling 完整执行链路?模型输出 JSON 不规范/解析失败怎么兜底?

配置十多个工具时如何避免模型选错/误调用?怎么保障按需调用?

Agent 是怎么选择工具的?

FC、MCP、Skill、Rules 的区别?MCP 解决什么问题/使用场景?

工具的动态注册怎么做?Coding Agent 最初如何挂载工具?

权限校验怎么做?权限规则是硬编码的吗?

工具调用不做限制有什么风险?参数校验/命令注入/SSRF 怎么防?

大量无效调用拉高成本拖慢QPS：限流和拦截怎么做?

如何区分模型输出问题与下游工具/接口问题，快速定位根因?

Agent 结构化输出是什么/怎么做?

数据实时更新时，如何避免 Agent 调用过期工具、输出过时信息?

怎么理解 RAG、MCP、FC、Skills 四者的关系?

Skill 自进化流水线与生命周期

工具动态分发与结果合并

LLM 调用限流(RPM/TPM/双令牌桶)与任务排队

RAG 与知识库

除了阿里内部的向量库，你还了解哪些RAG向量库?如何选型?

Graph RAG和传统RAG的区别是什么?

RAG的局限性

如何设计一个支持百万级文档、检索延迟<200ms的RAG系统?

文档切片(Chunking)策略

表格/PDF/图片等非结构化文档如何做RAG

混合检索(HybridRetrieval)是什么

如何避免检索到无关片段导致回答跑偏

多轮对话中如何自动触发检索

Rerank(重排序)/为什么需要

什么是”长文档中间丢失”问题?

知识库内容频繁更新如何保证一致性

RAG 整体流程?

Agentic RAG 和传统 RAG 的区别?Agent 如何自主判断检索次数、动态改写 query?为何做成检索策略/放知识库还是上层?

召回时分片不完整怎么办?

Embedding 选型：BGE 还是自训?维度多少?微调负样本怎么采?

提升 RAG 检索质量的技术?

召回不理想优先排查哪些环节?

低质 Query/模糊诉求怎么避免空召回错召回?

知识库数据隔离：物理 vs 逻辑?对索引和检索性能影响?

通用知识库 vs 业务定制?怎么判断能力做成平台还是交给业务?会不会被成熟开源产品替代?

知识库还可以用在哪些场景(除文档检索)?

RAG vs 塞 Prompt / RAG vs 微调的选型

云端 RAG vs 端侧 RAG 差异

多模态 / 视频知识库处理链路

多 Agent

常见Multi-Agent协作模式

多Agent怎么保证其比单Agent强

何时用多Agent比单Agent更合理

如何解决多Agent的”无限循环”或”通信冗余”

多Agent系统设计范式

设计一个多Agent协作系统

设计一个多Agent辩论系统

分布式多Agent状态流转设计

什么是Subagent(子智能体)模式?解决了什么问题

子 Agent 失败整体怎么兜底/重试/降级?输出结论冲突怎么仲裁?

多 Agent 争抢哪些资源?怎么隔离?

海量任务下多 Agent 分片、并发调度、避免抢占?

多 Agent 怎么实现责任追溯?错误能否定位到具体节点和工具调用?

多 Agent 成本怎么控?token 预算超限先砍记忆、检索还是规划?

多 Agent 之间如何通信?

主 Agent 与子 Agent 的模型分配

评估与质量

怎么设计评价 Agent 系统好坏的指标体系?业务指标和技术指标?任务完成率/工具准确率/幻觉率怎么量化?

评测集和 Ground Truth 怎么构造?如何从海量线上日志构建有限离线评测集?

评测是人工还是机器?

LLM-as-a-Judge 的位置偏见/长度偏见怎么规避?

线上大量用户反馈任务失败，怎么排查和迭代?bad case 怎么回流?

大模型幻觉的成因?怎么解决?

置信度通过什么规则判断?什么情况二次确认用户?

Prompt 调优到瓶颈后，降幻觉的优化优先级怎么排?

模型/Prompt 迭代后怎么基线对比和灰度验证?版本迭代怎么保稳定?

Eval、Trace、Guardrail 分别解决什么问题?为什么只靠 Prompt 优化不行?

怎么保证 Agent 产出达到之前人工制作的质量?

如何评估小模型抽取结果?复杂样本怎么处理?

过程评估与贡献归因分析

数据回流与自迭代

工程质量提升手段(无微调高准确率 / AI 代码质量)

生产工程与安全

Human-in-the-Loop中断点与可恢复执行

如何设计防注入的Prompt结构

首Token延迟和整体吞吐量如何优化

Agent性能优化常见手段

如何减少Token消耗

Token消耗成本如何控制

如何防止恶意刷Token

如何监控Agent的Token消耗

Agent开发中敏感信息如何防泄露

多用户高并发任务堆积/卡死/资源耗尽怎么设计?

大促高峰咨询暴增，批量任务堆积卡顿怎么优化调度?哪些场景强制切规则链路?

SSE 如何边生成边推送?SSE vs WebSocket?

Agent 沙箱机制怎么设计?E2B 了解吗?

Checkpoint 底层怎么实现?MemorySaver vs PostgresSaver?状态序列化版本兼容/存量会话迁移?

Coding Agent 运行中用户发消息打断，怎么处理?

Agent 实例池怎么设计?千级 Agent 扩容、亲和路由、实例淘汰重建?

Agent 多租户隔离怎么做?

AI 代码工程化：单测生成/补丁应用/沙箱执行/版本回滚哪步最易出生产事故?怎么防控?

系统线上稳定性保障的落地思路?监控告警体系?

ZSet 限流瓶颈?

生产可用 vs Demo 的判断标准

框架与 Harness

LangChain

LangGraph

LangChain vs LangGraph vs LlamaIndex

Harness Engineering

SDD/Spec-Driven Development

自研 vs OpenAI SDK vs LangGraph/AutoGen/CrewAI/OpenManus 怎么选?讲清 trade-off?不用框架原生写过吗?

LangGraph 子图复用/动态子Agent注册/热更新图定义?

Prompt/Context/Harness Engineering 三者关系?

Claude Code/Codex 类 harness 的执行思路?agent.md、skills 文件怎么落地?Claude Code 上下文管理优缺点?

AI 代码助手怎么高效输入整个仓库上下文?全量灌还是分层检索?

是否 fork 过 deep-agent?upstream 冲突怎么处理?

LangChain Trace 链路追踪

模型与意图识别

多模型调度策略如何设计

Agent SystemPrompt的最佳结构是什么?

Prompt Template在生产中的实践?

意图识别：规则、分类模型、LLM 三种方案怎么取舍?轻量模型和规则怎么协同?

意图歧义/置信度低的兜底?结合真实 bad case

意图模型线上漂移怎么发现?bad case 怎么回流?在线蒸馏?

对大模型底层原理了解多少(Transformer/attention)?

Text-to-SQL 怎么保证 SQL 准确?

信息抽取适合什么模型?

端云协同怎么设计?哪些任务放端侧哪些上云?

构建高质量数据集怎么保证质量?

Agentic RL 与模型训练(RL loss / GRPO / GSPO / OPD / SFT / rollout)

模型接入协议与推理强度控制

ASR 选型评估

场景设计题

答法框架：澄清需求→分层架构→关键设计→降级与评测。

设计旅游咨询 Agent：机票/退改/酒店/攻略混合提问，怎么拆多意图、并行调度、聚合结果?

设计小爱个人助理：日程/天气/本地文件/多轮/SSE/多租户，端云协同架构与难点

设计 AI 面试助手：上传简历自动生成问题并模拟面试

用 AI 做游戏 UI 自动化测试怎么设计?

售后 Agent 对接订单/物流/退款多工具，怎么保证多步骤闭环不遗漏?

时间检索工具怎么设计?模糊时间怎么规范化?

交易流程最核心关注哪些点?对接第三方支付还是统一封装?

影视二创高光片段 Agent 设计

从零设计企业级 AI Agent 应用(全模块)

智能客服机器人设计

开放题与HR

Vibe Coding

Agent 行业概念泡沫?真实落地价值和瓶颈?

智能化越高不确定性越强，怎么平衡智能性和业务可控性?

未来更看好工程落地还是模型能力升级?

Agent 的局限性?

为什么从后端/深度学习转 Agent?

怎么建立技术判断力?没成熟经验时依据什么信号决定投入?

近半年深耕的最难论文/开源源码?

怎么看 AI 发展阶段/对工作产品的影响?基础架构团队做到什么程度才信任 AI?

学习新领域的方法?怎么判断技术值得深学还是了解?

怎么证明你思考深度比别人深?AI 时代的潜力怎么定义?

项目最大缺陷?重构怎么改?业务指标长期不提升怎么办?

算法和后端同学对 Agent 边界认知不一致怎么处理?技术方案和业务方分歧怎么沟通?

两周上线座舱 demo 但知识库未齐，怎么排优先级?

算法侧要加一步 LLM 调用提准确率，怎么核算成本/延迟/失败率并决策?

HR 常规(薪资/加班/职业规划/挫折/成就/为什么本公司/离职原因/稳定性)—— 模板清单，不逐题写

Author: cwp0

Link: https://cwp0.github.io/posts/20003.html

AI Agent开发知识点

Sponsor

wechat
alipay

2026-06-22

Agent开发面经

自我介绍面试官您好，我叫陈温鹏，硕士毕业于南京理工大学软件工程专业，目前在阿里巴巴菜鸟集团担任全栈开发工程师，这次应聘的是 Agent / 全栈 / Java / 服务端开发岗位。在菜鸟工作的一年多期间，我主要负责核心人事系统与薪酬系统的迭代开发和稳定性保障在 AI 工程化方面，我们团队做了很多 AI 方向的工作:除了传统项目开发外，我参与了企业级员工助理 Agent 与薪酬 AI 质检平台两个AI Native项目，并独立搭建了薪酬&社保域 AI 研发助手——把域知识与研发 SOP 沉淀为技能，编排数据库、日志、监控等研发工具，覆盖答疑、排查、交付全链路，钉钉落地服务全组。我个人的 AI Coding 采纳率稳定在 95% 以上，从去年到今年实现了个人月需求吞吐量翻倍。除此之外，我熟练掌握 Java 基础、并发编程、熟练在日常开发中使用 Vibe Coding、SDD等 AI 编程范式，熟练使用MCP、Skill用于排查日常问题；另外，我对Agent开发相关知识也有一定了解。最后感谢贵公司给我这次面试机会，我也十分希望能加入团...

2026-06-22

Agent开发知识点总结

本文档分三段：第〇部分是术语速查表（按主题分组）；第一部分是核心知识体系（10 章主体面试题）；第二部分是框架与生态（Java/Spring 栈）。新增内容请按主题归位到对应章节末尾。第〇部分：术语速查上下文窗口上下文窗口是指AI模型每次处理时能”看到”和记住的最大文本长度限制，超出这个范围的内容就会被”遗忘”。 tokenToken 是AI模型处理文本的基本单位，大约对应一个单词或几个汉字，模型的计费和上下文长度都以token数量来衡量。一个汉字约1.5-2 token，一个英文单词约1 token。 KV Cache/Prompt Caching模型在推理时，会把已经计算过的 Token 的中间结果（Key-Value 矩阵）缓存起来，下次遇到相同前缀时直接复用不需要重新计算。好处：减少重复计算，提升推理速度减少成本。模型对命中KV Cache的token收费更低(1/10) 温度/Temperature控制模型输出随机性的参数，范围0-2，值越大，模型越随机。一般Agent的temperature设置为0...

Comments

ValineDisqus