Agent 开发备考与学习指南

Java 后端和架构师转 Agent 开发，核心不是证明自己会调模型 API，而是证明自己能把非确定性的 LLM 能力放进可评测、可审计、可治理的企业系统。

目录

章节	说明
一句话定位	面试时如何定义自己的 Agent 方向
备考优先级	P0、P1、P2 三层学习重点
LLM 基础	token、上下文、采样、输出控制
Agent 核心范式	Agent loop、工具调用、状态与记忆
RAG 全链路	从文档处理到召回、重排、评测
Java 工程化能力	Spring Boot、Spring AI、LangChain4j 与生产集成
生产化与安全	可观测、成本、可靠性、权限与防注入
协议与平台能力	MCP、A2A、LLM 网关与多模型路由
推荐项目	企业知识库 Agent 与业务操作 Agent
六周学习计划	从 API 到项目展示的阶段性产出
面试题清单	高频技术题、架构题和行为题
项目讲解模板	面试中如何讲一个 Agent 项目
简历表达	从 demo 写法升级到架构师写法
最终检查清单	面试前必须能回答的问题

一句话定位

作为 Java 后端工程师或架构师，转 Agent 开发时不要把自己包装成模型训练专家。更准确的定位是：

Agent 工程化和企业落地方向的后端架构师。

面试官真正关心的是：你能不能把 LLM 的能力接进真实业务系统，并解决生产环境中的可靠性、权限、成本、评测、可观测性和安全问题。

推荐自我介绍

我的方向不是模型训练，而是 Agent 工程化和企业落地。我过去做 Java 后端和架构，熟悉权限、状态管理、可观测性、可靠性和成本治理。Agent 系统的核心挑战是把 LLM 的不确定性约束在可监控、可评测、可审计的工程边界内，这正是我原有经验可以迁移的地方。

Java 架构师的迁移优势

原有能力	Agent 场景中的对应价值
微服务设计	Agent、工具、知识库、模型网关的边界划分
分布式事务和幂等	工具调用、长任务恢复、高风险操作补偿
权限和审计	知识库权限过滤、工具调用授权、操作留痕
可观测性	prompt、retrieval、tool call、token、cost 的全链路 trace
高可用治理	模型 fallback、工具超时、重试、熔断和降级
性能优化	流式输出、并行工具调用、缓存、token 裁剪

常见误区

误区	问题	正确做法
把 LLM 当数据库	模型会生成，不保证事实正确	事实问题走 RAG 或工具查询
把 LLM 当确定性函数	相同输入也可能得到不同输出	用结构化输出、评测集和版本控制约束
一上来做多 Agent	成本和调试复杂度迅速上升	先用 workflow 和单 Agent + 多工具
只会说 prompt	无法体现工程深度	讲工具、状态、权限、trace、eval
只做 demo	面试缺乏说服力	做一个可运行、可评测、可回放的项目

备考优先级

P0：必须熟练

这些内容决定你能否通过大多数 Agent 开发面试。

方向	要掌握的内容	面试中的证明方式
LLM API	chat、streaming、tool calling、structured output	能写出调用链路和失败处理
Agent loop	plan、act、observe、finish	能解释循环如何终止和如何防死循环
RAG	chunk、embedding、retrieval、rerank、citation	能讲完整链路和排查思路
Java 集成	Spring Boot、Spring AI 或 LangChain4j	能说明核心抽象和代码组织
工具调用	工具 schema、参数校验、权限控制	能设计查询类和操作类工具
可观测性	prompt、chunk、tool、token、latency、cost	能展示一条完整 trace
评测	golden set、离线回归、LLM-as-judge	能用数字说明优化效果
安全	prompt injection、越权、脱敏	能说清防护边界不能只靠 prompt

P1：重点掌握

这些内容适合中高级岗位和架构设计题。

方向	重点
Agent 状态管理	checkpoint、断点续跑、幂等、任务恢复
Human-in-the-loop	高风险操作的人审、确认和审计
Workflow vs Agent	固定流程和动态决策的取舍
LLM 网关	多模型路由、fallback、限流、成本归因
推理模型	适合复杂规划，不适合高频低延迟链路
MCP	client、server、tool、resource、prompt、authorization
Java 并发	虚拟线程、CompletableFuture、并行工具调用、SSE

P2：了解即可

这些内容知道概念即可，不要投入主要备考时间。

方向	备考建议
Tree of Thoughts	知道是多路径探索，生产中成本较高
复杂 Multi-Agent	重点讲风险和边界，不要堆概念
A2A 协议	适合多 Agent 平台架构题，普通 RAG 应用不是最高频
模型训练细节	除非岗位明确要求 fine-tuning 或模型基础设施

LLM 基础

核心概念

概念	说明	工程影响
token	模型处理的基本单位	决定上下文容量和成本
context window	单次请求可容纳的输入和输出上限	影响历史、文档和工具结果能放多少
temperature	控制随机性	业务系统通常取低值以提升稳定性
top_p	核采样参数	通常不要和 temperature 同时大幅调整
max_tokens	输出上限	防止无限生成和成本失控
system	系统级行为约束	应放规则、边界和安全要求
tool	工具返回消息	工具结果要回填给模型继续决策

输出控制优先级

生产系统中，输出控制的可靠性优先级如下：

Tool calling / function calling
  -> Structured output / JSON schema
  -> JSON mode
  -> Prompt 要求输出 JSON
  -> 正则解析自然语言输出

越靠前约束越强、稳定性越高；越靠后越灵活，但失败率和维护成本越高。

工具 schema 示例

{
  "name": "query_order_status",
  "description": "查询订单状态，只用于用户明确提供订单号并询问订单进度、物流或退款状态的场景",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "订单编号，例如 ORD-202606260001"
      },
      "include_items": {
        "type": "boolean",
        "description": "是否返回商品明细，默认 false"
      }
    },
    "required": ["order_id"]
  }
}

面试要能追问到这些点：

• description 写不清会导致模型误调工具。
• required 字段过多会导致模型无法调用。
• 参数 schema 不能替代服务端权限检查。
• 工具返回值也要控制长度，避免污染上下文。

Prompt 工程

Prompt 不应该靠玄学调参，而应该工程化管理。

做法	目的
明确角色和任务边界	降低无关输出
使用分隔符隔离用户输入	降低 prompt injection 影响
few-shot 示例	稳定格式和风格
schema 约束	降低解析失败率
prompt version	支持回滚和回归测试
golden set 评测	判断改动是否真的变好

模型选型

场景	选择倾向	原因
简单分类和抽取	小模型	成本低、延迟低
复杂规划和推理	强推理模型	需要更强的多步推理能力
高频客服问答	中等模型 + RAG	平衡成本和质量
敏感数据场景	私有化或脱敏后调用	降低数据泄露风险
代码生成和修复	代码能力强的模型	代码上下文和工具能力更重要

Agent 核心范式

Agent 和普通 LLM 调用

普通 LLM 调用是一次性生成：

用户输入 -> 模型输出

Agent 是模型驱动的循环决策：

用户目标 -> 模型决策 -> 调用工具 -> 观察结果 -> 再次决策 -> 完成或中止

核心区别：Agent 不只是回答问题，它会根据目标选择工具、读取结果、更新状态，并决定下一步动作。

Agent loop 的关键控制点

控制点	设计问题
入口意图识别	是否需要 Agent，还是普通问答即可
工具选择	工具是否匹配任务，是否有权限
参数补全	缺参数时追问用户还是使用默认值
工具执行	超时、失败、限流如何处理
结果观察	工具结果是否足够继续下一步
终止判断	什么时候完成，什么时候中止
最大轮数	防止循环调用和成本失控

常见 Agent 模式

模式	适用场景	风险
ReAct	通用工具调用，边推理边行动	长任务容易漂移
Plan-and-Execute	步骤多、依赖强的复杂任务	初始规划错误会放大
Router	根据问题类型分流到不同链路	路由错误会导致整体错误
Supervisor	一个主管协调多个子 Agent	调试成本高，一致性难控
Reflection	自检和修正输出	增加 token 和延迟
Workflow Agent	固定流程中嵌入 LLM 判断	灵活性低于自主 Agent

企业场景建议：

能用 workflow 约束的地方优先用 workflow；只有在路径不固定、工具选择动态、需要多轮观察时才引入 Agent loop。

Memory 设计

类型	存储位置	典型内容	风险
短期记忆	上下文窗口	本轮对话历史	token 膨胀
工作记忆	Redis 或数据库	当前任务状态、中间结果	状态不一致
长期记忆	向量库或数据库	用户偏好、历史摘要	隐私和过期问题

Memory 设计要回答四个问题：

1. 什么信息值得记？
2. 记多久？
3. 用户是否可见、可删除？
4. 什么时候摘要、检索或丢弃？

Agent 状态模型

长任务 Agent 至少需要以下状态字段：

字段	说明
session_id	用户会话
task_id	一次完整任务
step_id	一次模型调用或工具调用
tool_call_id	工具调用唯一标识
status	running、waiting_approval、failed、completed、cancelled
checkpoint	可恢复的中间状态
retry_count	重试次数
trace_id	全链路追踪标识

工具调用时序

sequenceDiagram
    participant U as User
    participant A as Agent
    participant T as Tool
    participant S as State Store
    U->>A: 提出任务
    A->>S: 创建 task 和 step
    A->>A: 选择工具并生成参数
    A->>T: 调用工具
    T-->>A: 返回结果
    A->>S: 记录 tool result 和 checkpoint
    A->>A: 判断继续或完成
    A-->>U: 返回答案或请求确认

RAG 全链路

RAG 是 Agent 面试最高频主题之一。不要只说“向量库检索”，要能讲完整链路。

文档采集
  -> 清洗和解析
  -> 分块 chunk
  -> embedding
  -> 入库
  -> query rewrite
  -> hybrid search
  -> rerank
  -> prompt assembly
  -> answer generation
  -> citation
  -> eval

文档处理

环节	关键问题
采集	PDF、Markdown、HTML、Word、网页如何接入
解析	标题、表格、代码块、图片 OCR 是否保留
清洗	去广告、去导航、去重复、去无效页眉页脚
分块	固定长度、标题层级、语义分块如何选择
元数据	租户、权限、来源、时间、文档类型
增量更新	文档更新后如何重建 embedding 和索引

Chunk 策略

策略	优点	缺点	适用场景
固定长度	实现简单	容易切断语义	快速 demo
固定长度 + overlap	降低切断损失	冗余和成本更高	通用文本
按标题层级	保留结构	依赖文档质量	Markdown、技术文档
语义分块	语义完整	实现复杂	长文档和知识库
表格单独处理	保留结构化信息	需要特殊解析	报表、规格表

Embedding 选型

Embedding 模型决定语义检索效果上限。面试要能讲：

• 中文、多语言、代码、专业术语场景要选合适模型。
• 向量维度越大不一定越好，要考虑成本、存储和检索延迟。
• embedding 模型升级通常意味着需要重建索引。
• 私有化部署要考虑吞吐、GPU 成本和批处理。

维度	关注点
语言能力	中文、多语言、专业术语
部署方式	托管 API 还是私有化
向量维度	存储成本和召回质量
吞吐能力	批量文档入库速度
稳定性	版本升级是否影响索引

检索优化

技术	解决的问题
BM25	关键词、编号、专有名词匹配
Vector search	语义相似问题
Hybrid search	同时兼顾关键词和语义
Rerank	提升 top-k 相关性
Metadata filter	权限、租户、时间、类型过滤
Query rewrite	将用户模糊问题改写为可检索表达
Multi-query	从多个角度召回后合并去重

RAG 问题排查

现象	可能原因	排查方向
答案错但召回正确	prompt 或生成问题	查看 prompt assembly 和模型输出
答案错且未召回	检索链路问题	检查 chunk、embedding、query rewrite
召回片段太长	chunk 过大	调小 chunk 或按结构切分
召回噪音多	top-k 太大或过滤不足	加 rerank 和 metadata filter
引用不支持答案	citation 绑定不严	让模型只基于证据片段回答
权限越权	过滤位置错误	检索前按租户和 ACL 过滤

RAG 评测指标

指标	含义
context recall	答案所需证据是否被召回
context precision	召回内容是否足够相关
faithfulness	回答是否忠实于上下文
answer correctness	最终答案是否正确
citation accuracy	引用来源是否真实支持答案

RAG vs Fine-tuning

需求	更适合的方案	原因
私有知识库问答	RAG	知识可更新，可引用来源
最新政策和文档	RAG	不需要重新训练
固定输出风格	Fine-tuning	学习格式和表达习惯
领域术语表达	RAG + Fine-tuning	RAG 给事实，微调给表达
工具调用习惯	先 prompt 和 schema，必要时微调	微调成本较高

Java 工程化能力

主线技术栈

建议选择一条主线深入，不要两个框架都只会皮毛。

技术	适用情况
Spring AI	Spring Boot 企业项目，和现有技术栈融合自然
LangChain4j	Java Agent 和 RAG 能力完整，适合快速做项目
Spring Boot	API、SSE、权限、任务、审计的工程外壳
Redis	session、任务状态、锁、短期缓存
PostgreSQL / MySQL	任务表、审计表、评测集
pgvector / Milvus / Qdrant	向量存储和语义检索
Elasticsearch	BM25 和 hybrid search
OpenTelemetry	全链路 trace

Java 集成需要能讲清

能力	面试要点
Streaming	SSE、WebFlux 或响应式流
Tool calling	注解或 schema 声明工具，服务端做权限和校验
Memory	按 session 或 user 维度管理上下文
RAG	VectorStore、Retriever、Reranker、Prompt assembly
并发工具调用	CompletableFuture、虚拟线程或响应式组合
超时和重试	工具调用和模型调用分开治理
观测	每步记录输入、输出、token、延迟、错误

工具设计原则

工具不应该暴露底层数据库接口，而应该封装成业务语义明确的能力。

工具类型	示例	风险控制
查询类	query_order_status	权限校验、结果裁剪
检索类	search_knowledge_base	ACL 过滤、来源记录
创建类	create_ticket	参数校验、幂等 key
操作类	create_refund_request	人工确认、审计
通知类	send_approval_message	频控、模板限制

工具调用服务端校验

public ToolResult queryOrderStatus(QueryOrderRequest request, UserContext user) {
    validator.validate(request);
    permissionService.checkOrderReadable(user, request.orderId());
    Order order = orderService.findById(request.orderId());
    return ToolResult.success(orderViewMapper.toSafeView(order));
}

关键点：

• 参数校验在服务端做。
• 权限校验在服务端做。
• 返回给模型的是裁剪后的安全视图。
• 错误信息要可理解，但不能泄露内部细节。

生产化与安全

可观测性

Agent debug 不能只看最终回答，必须能回放完整执行轨迹。

每次请求至少记录：

字段	说明
user input	用户原始输入
prompt version	系统提示词版本
model name	使用的模型
retrieved chunks	召回片段和分数
tool calls	工具名、参数、耗时、结果
token usage	输入、输出、总 token
latency	总耗时和各阶段耗时
cost	单次调用成本
final answer	最终回答
trace id	串联所有步骤

成本控制

手段	说明
模型分级路由	简单任务走小模型，复杂任务走强模型
prompt caching	静态 system prompt 和工具定义尽量复用
上下文裁剪	只保留必要历史和高质量片段
rerank 后再拼 prompt	减少无效上下文
限制 loop 轮数	防止工具循环调用
token budget	按用户、租户、任务限制预算
LLM 网关	统一统计成本、限流和 fallback

延迟优化

手段	适用场景
流式输出	降低用户体感延迟
并行工具调用	多个查询互不依赖
检索缓存	高频知识问答
减少 loop 轮数	固定流程用 workflow 替代
小模型预判	路由、分类、简单抽取
结果裁剪	减少工具结果回填 token

可靠性

Agent 生产化必须考虑：

• 模型超时。
• 工具超时。
• 指数退避重试。
• fallback model。
• fallback answer。
• 最大循环次数。
• 死循环检测。
• 任务取消。
• 断点续跑。
• 失败任务表或 DLQ。

安全边界

风险	说明	防护
prompt injection	用户输入试图覆盖系统指令	指令隔离、输入作为不可信数据
tool injection	检索内容诱导模型调用工具	检索内容不具备指令权
数据越权	召回无权限文档	检索前 ACL 过滤
工具越权	调用不该调用的业务工具	工具白名单和服务端鉴权
PII 泄露	日志或模型输入含敏感信息	脱敏、审计、最小化传输
高风险动作	发消息、扣款、删数据	人工确认和幂等

核心原则：权限、风控和审计必须在系统层实现，不能只写在 prompt 里。

协议与平台能力

MCP

MCP 解决的是 LLM 应用和外部工具、数据源之间的标准化连接问题。

概念	说明
MCP client	通常在 Agent 应用侧
MCP server	暴露工具、资源和提示模板
tools	可执行动作
resources	可读取上下文数据
prompts	可复用提示模板
authorization	企业环境必须考虑认证授权

面试表达：

MCP 的价值是把工具接入从“每个 Agent 单独适配”变成“标准协议接入”，降低工具生态集成成本。

A2A

A2A 解决 Agent 与 Agent 之间通信、任务协作和状态交换的问题。

一句话区分：

MCP：Agent 连接工具和数据。
A2A：Agent 连接其他 Agent。

A2A 更适合多 Agent 平台、跨组织 Agent 协作、复杂任务委派；普通企业知识库 Agent 不一定需要优先实现。

LLM 网关

LLM Gateway 类似 LLM 时代的 API Gateway。

能力	价值
统一模型 API	屏蔽不同供应商差异
多模型路由	按任务、成本、延迟选择模型
fallback	主模型失败时切换备用模型
限流	控制用户、租户和场景配额
成本归因	统计部门、用户、应用成本
prompt 审计	保留版本和调用记录
敏感信息过滤	降低数据泄露风险

推荐项目

面试最有说服力的不是概念，而是一个能运行、能评测、能回放的项目。

项目一：企业知识库 Agent

这是最稳的主项目。

功能范围

功能	说明
文档上传	支持 PDF、Markdown、HTML
文档解析	保留标题、段落、表格和代码块
chunk	按标题层级和语义切分
embedding	支持批量入库和重建索引
hybrid search	BM25 + vector
rerank	提升 top-k 相关性
citation	回答标注来源
streaming	SSE 流式输出
权限	用户只能查有权限的文档
trace	记录召回、prompt、tool、token 和 cost
eval	维护 30-50 条 golden set

架构图

flowchart LR
    U["User"] --> API["Spring Boot API<br/>SSE"]
    API --> A["Agent Orchestrator"]
    A --> R["Retriever<br/>Hybrid Search"]
    R --> V["Vector Store"]
    R --> E["BM25 Index"]
    A --> L["LLM Gateway"]
    A --> T["Business Tools"]
    A --> O["Trace Store"]
    T --> B["Business Services"]
    style A fill:#cfc,stroke:#060
    style O fill:#eef,stroke:#33f

面试要能讲

• 为什么按标题层级 chunk。
• 为什么需要 hybrid search。
• 为什么 rerank 能提升 top-k 质量。
• 权限过滤放在检索前还是检索后。
• 如何避免模型编造。
• 如何做引用溯源。
• 如何用 eval set 证明效果提升。
• 一次回答的 trace 包含哪些字段。

项目二：业务操作 Agent

适合体现后端架构优势。

可选场景

场景	工具
订单客服 Agent	查订单、查物流、查退款政策、创建工单
运维排障 Agent	查日志、查指标、查发布记录、生成排障摘要
内部工单 Agent	查知识库、创建工单、催办、总结处理结果
数据分析 Agent	查指标、生成 SQL、解释异常、生成报告

必须包含的工程能力

• 查询类工具。
• 操作类工具。
• 高风险操作人工确认。
• 参数校验。
• 权限控制。
• 幂等。
• 审计日志。
• 工具失败处理。

项目指标展示

准备一张真实或离线评测表。

指标	示例
问题集规模	50 条
证据召回率	84%
答案正确率	78% 提升到 86%
平均延迟	4.8 秒
首 token 延迟	1.2 秒
平均 token 成本	每次 0.006 美元
工具调用成功率	97%
高风险操作拦截率	100%

六周学习计划

第 1 周：LLM API 和工具调用

目标：

• 跑通 chat。
• 跑通 streaming。
• 跑通 structured output。
• 跑通 tool calling。

产出：

• 一个 Spring Boot /chat/stream 接口。
• 一个订单查询工具 demo。
• 一份工具 schema 设计说明。

第 2 周：RAG 最小闭环

目标：

• 文档解析。
• chunk。
• embedding。
• 向量检索。
• 生成带引用的回答。

产出：

• 上传 10 篇文档。
• 支持知识库问答。
• 回答中显示引用来源。

第 3 周：RAG 优化

目标：

• hybrid search。
• rerank。
• query rewrite。
• metadata filter。
• 权限过滤。

产出：

• 30 条 eval set。
• 对比优化前后的准确率和召回率。

第 4 周：Agent 工具和状态

目标：

• 接入 3-5 个业务工具。
• 增加 Agent loop。
• 增加状态表和 step 记录。
• 增加最大循环次数和失败处理。

产出：

• 一个可以查知识库、查订单、创建工单的 Agent。
• 一张 agent_task 表和一张 agent_step 表。

第 5 周：生产化

目标：

• trace。
• token 和成本统计。
• 超时、重试、fallback。
• 高风险操作人审。
• 日志脱敏。

产出：

• trace 页面或 trace API。
• 成本统计报表。
• 人审流程 demo。

第 6 周：面试打磨

目标：

• 准备架构图。
• 准备项目讲解。
• 准备高频题答案。
• 准备转型叙事。

产出：

• 一页项目架构图。
• 一页 RAG 链路图。
• 一页 Agent 执行 trace 示例。
• 一份简历项目描述。

面试题清单

Agent 基础

问题	回答重点
Agent 和普通 LLM 调用有什么区别？	循环决策、工具、状态
Agent 和传统 workflow 有什么区别？	动态决策 vs 固定流程
什么时候不该用 Agent？	路径固定、高确定性、低容错场景
ReAct 和 Plan-and-Execute 区别？	边行动 vs 先规划
Agent 陷入死循环怎么办？	最大轮数、状态检测、人工中断
工具调用失败怎么办？	重试、降级、追问用户、终止
长任务如何断点续跑？	checkpoint、step 表、幂等
高风险操作如何做人审？	参数展示、确认、审计、幂等

RAG

问题	回答重点
RAG 完整链路是什么？	文档到 eval 的全链路
chunk size 怎么选？	文档结构、语义完整、召回效果
embedding 怎么选？	语言、领域、维度、部署
hybrid search 为什么更稳？	关键词和语义互补
rerank 解决什么问题？	top-k 精排
召回不到答案怎么排查？	chunk、embedding、query rewrite
召回到了但答错怎么办？	prompt、证据约束、模型能力
如何保证基于知识库？	只基于证据、引用、拒答
RAG 和 fine-tuning 怎么选？	知识更新 vs 行为风格

工程化

问题	回答重点
如何做 Agent 可观测性？	trace 全链路
如何评估 Agent 效果？	golden set、指标、回归
如何测试非确定性系统？	mock、固定评测集、LLM-as-judge
如何控制 token 成本？	模型路由、缓存、裁剪
如何优化延迟？	streaming、并行、缓存
如何设计 LLM 网关？	路由、限流、fallback、审计
如何处理 prompt 版本？	版本号、灰度、回滚

安全

问题	回答重点
什么是 prompt injection？	用户输入覆盖系统意图
检索内容有恶意指令怎么办？	检索内容不具备指令权
如何防止工具越权？	白名单、鉴权、参数校验
如何防止查到无权限文档？	检索前 ACL 过滤
日志中如何处理敏感信息？	脱敏、最小化、审计

Java 方向

问题	回答重点
Spring AI 和 LangChain4j 怎么选？	企业集成 vs Agent 能力完整度
Java 如何实现流式输出？	SSE、WebFlux、SseEmitter
如何并行调用多个工具？	CompletableFuture、虚拟线程
状态存在 Redis 还是数据库？	短期状态 Redis，审计和恢复 DB
如何接入已有微服务？	工具封装、权限透传、审计

行为面试

问题	回答重点
为什么从 Java 后端转 Agent？	原能力迁移到 Agent 工程化
和算法背景候选人相比优势是什么？	落地、治理、稳定性、架构
过去复杂系统经验如何迁移？	状态、权限、观测、可靠性
如何看待 Agent 的不确定性？	用工程边界约束不确定性

项目讲解模板

面试中讲项目时按这个顺序，不要散讲技术名词。

1. 业务目标：解决什么问题，为什么需要 Agent。
2. 架构图：入口、模型、工具、RAG、状态、trace。
3. 核心链路：用户问题如何变成答案或操作。
4. RAG 设计：chunk、embedding、retrieval、rerank、citation。
5. 工具设计：工具 schema、权限、参数校验、失败处理。
6. 状态设计：session、task、step、checkpoint、幂等。
7. 安全设计：prompt injection、权限过滤、人审、脱敏。
8. 评测结果：准确率、召回率、延迟、成本。
9. 踩坑和优化：至少准备 3 个真实问题和解决过程。
10. 后续演进：MCP、LLM 网关、多模型路由、多 Agent 协作。

踩坑案例

问题：知识库问答经常答非所问。
排查：查看 trace，发现模型没有乱编，问题出在召回片段不相关。
原因：chunk 过大，且只用向量检索，关键词型问题召回差。
方案：改为标题层级 chunk，引入 BM25 + vector hybrid search，再加 rerank。
结果：50 条 eval 中答案正确率从 72% 提升到 84%，引用命中率从 68% 提升到 86%。

STAR 表达

阶段	说明
Situation	原来的业务痛点是什么
Task	你负责解决什么问题
Action	你如何设计 RAG、工具、状态、评测
Result	指标如何变化，线上效果如何

简历表达

不推荐写法

使用 LangChain 实现智能问答系统，支持知识库问答和多轮对话。

问题：太泛，像 demo，无法体现工程深度。

推荐写法

设计并实现企业知识库 Agent，基于 Spring Boot + LangChain4j 构建 RAG 闭环，支持文档解析、语义检索、BM25 + 向量混合召回、rerank、引用溯源和流式回答；接入订单和工单查询工具，设计工具权限校验、参数 schema 校验和高风险操作人工确认；建设 50 条 golden set 评测集和 trace 体系，记录 retrieved chunks、tool calls、token、latency 和 cost，用于回归评测与线上问题排查。

架构师版写法

负责 Agent 应用工程化架构设计，将 LLM 调用、RAG、工具执行、状态持久化、权限治理、可观测性和成本控制抽象为统一平台能力；通过 LLM 网关实现多模型路由、限流、fallback 和成本归因，通过 agent_task / agent_step 状态模型支持长任务断点续跑和审计回放。

最终检查清单

面试前确认自己能清楚回答：

• 什么是 tool calling？
• 为什么 structured output 比 prompt JSON 稳？
• Agent loop 如何终止？
• 工具失败如何处理？
• RAG 为什么需要 rerank？
• hybrid search 的价值是什么？
• 权限过滤应该在检索前还是检索后？
• 如何评估一个 Agent？
• 如何防 prompt injection？
• 如何记录一次 Agent 执行 trace？
• 如何控制 token 成本？
• Spring AI 或 LangChain4j 的核心抽象是什么？
• MCP 解决什么问题？
• Workflow 和 Agent 怎么取舍？
• 为什么你适合做 Agent 工程化？

最终目标不是背完所有概念，而是准备出：

1. 一个能跑的项目。
2. 一套可量化评测。
3. 一条完整 trace。
4. 一张清晰架构图。
5. 三个真实踩坑案例。
6. 一个清楚的转型叙事。

参考资料

• 本地材料：/Users/maxingfang/tmp/r/materials/agent-interview-learning-guide.md
• 多智能体简介（补充理解多 Agent 的基本概念和风险）
• AI Agent 开发最佳实践（补充 Agent 工程实践）
• 企业知识库建设实操指南（补充企业知识库和 RAG 落地）