01 · 开篇：需求分析与技术选型

一、起点：不是"我想做 Agent"，而是"岗位要求我做 Agent"

我做前端 + 全栈 8 年，Vue/React 是主栈，后端 Python(Django/FastAPI) 能写，Java 能读能改。 2026 年投简历时发现一个尴尬的事实：简历里没有一条能证明 Agent 能力的项目经历。

于是我做了件笨但有效的事------把自己抓取的 778 条 BOSS 直聘岗位数据做了一遍关键词统计：

技能	命中岗位数	技能	命中岗位数
前端（泛）	249	微服务	10
Python	98	RAG	10
Java	50	Prompt	8
Agent	39	工作流编排	8
大模型 / LLM	26	LangChain	6
智能体	18	Spring / Spring Boot	4
Redis / MySQL / Docker	16 / 14 / 12	LangChain4j	1
高并发	10	MCP / Function Call	2 / 2

（完整统计见 docs/01-岗位技能对标与差距分析.md）

结论很清晰：AI 能力不是独立岗位 ，而是叠加在前端 / 全栈 / Java / Python 之上 的加分项。 所以策略应该是：保留主栈优势，把 AI 能力补齐到"能讲细节、能演示"的程度。

二、JD 原文提炼出的 8 条硬指标

我把 JD 里反复出现的原话摘了出来，它们直接决定了项目要做什么：

1. "熟悉 Prompt、Context、RAG、Agent、Tool Calling、MCP，能独立开发 Skills"
2. "有基于 LangChain/LangGraph 构建实际 Agent 项目，处理过工具调用、多轮推理、错误恢复"
3. "熟悉 RAG（检索增强生成） 、Agent 框架及工具调用"
4. "了解 LLM、RAG、向量数据库 、Prompt Engineering、Function Calling、Tool Use"
5. "理解 Agent 工作流、多轮任务编排、上下文管理、工具调用及异常重试"
6. "负责执行链路、日志观测和结果校验"
7. "基于 Java + langchain4j 实现智能体的感知、规划、决策、执行全流程"
8. "能对 AI 生成代码 进行审查与优化"

每一条都必须在项目里有对应模块------这就是我的需求清单。

三、选一个什么业务场景？

选场景的三个原则：

1. 我自己熟悉（能讲出业务细节，面试不怕追问）
2. 能同时用到 RAG 和工具调用（知识问答 + 数据查询）
3. 能做出"危险动作"（才有必要做人工确认）

最后定了：企业研发效能 / 项目经营分析助手。

• 知识库：成本管理制度、缺陷分级规范、告警 SOP（→ RAG）
• 数据：项目成本、缺陷趋势、交付效率（→ Text2SQL）
• 动作：推送告警到值班群（→ 高危操作，HITL）

而且这个场景和我过往的 BI 数据可视化经历能对上，简历上逻辑自洽。

四、技术选型（附决策理由）

4.1 为什么是"双栈"：Python + Java

统计里 Java 50 条、Python 98 条，而 JD 明确提到 langchain4j 。 我的判断：只做 Python 会丢掉 Java + AI 那批岗位，而那批岗位竞争反而小。

所以同一个业务做了两遍：

	Python 侧	Java 侧
框架	LangGraph + LangChain	Spring Boot 3 + LangChain4j
定位	主力，功能最全	覆盖 Java+AI JD
编排	显式状态图	AiServices 动态代理

面试话术："两套都实现了，选择依据是管控粒度------ 需要严格控制每一步用 LangGraph 显式建图；业务边界清晰、追求接入速度用 LangChain4j。"

4.2 为什么不用 Dify / Coze 这类低代码平台？

JD 里确实有提 Dify/Coze，但它们是加分项不是主项 。 作为求职者，我需要证明的是工程能力，不是"会用平台拖拉拽"。 所以：平台我了解（简历写"了解"），但主项目必须手写核心链路。

4.3 为什么 Agent 编排选 LangGraph？

方案	优点	缺点	结论
手写 while 循环	零依赖	不可视化、难持久化	作为降级兜底
ReAct（思考-行动-观察）	省 token	流程不可控、难调试	不用
LangGraph 状态图	条件边天然表达循环、可持久化、可可视化	需要理解状态合并	✅ 主方案

而且我额外写了等价的内置状态机：langgraph 装不上时自动降级。 这一点在面试时很加分------说明你理解"图"的本质，而不是只会调库。

4.4 为什么向量库默认用内存 / PGVector，而不是 Milvus？

• 演示要"开箱即用" → 默认内存（numpy 余弦）
• 生产推荐 PGVector → 和业务库同一个 PostgreSQL，事务一致、免维护一套中间件
• Milvus → 数据量大、需要独立扩展时才上

三者在代码里是同一接口，改环境变量切换。

4.5 为什么不用 LangSmith 做可观测？

企业内网通常不允许把 prompt 出网。 所以自建 Tracer（Span + Token + JSONL 落盘 + SSE 实时推送）， 同时保留适配位（设置环境变量即可并行上报 LangSmith）。

4.6 最关键的一个决定：没有 API Key 也要能跑

面试现场、客户演示、CI 环境------这三种场景都可能没网没 Key。 所以我内置了两个兜底：

• MockLLM：规则式假模型，能按问题特征输出合法 JSON 计划
• HashingEmbedder：本地零依赖向量（中文 bigram + 有符号哈希投影）

收益 ：git clone 下来什么 Key 都不配，run_all.bat 一点，整条链路（检索→规划→工具→反思→流式回答）完整跑通。

五、最终技术栈

前端   Vue3 + TypeScript + Vite + Pinia + Ant Design Vue + SSE
后端A  Python 3.12 + FastAPI + LangGraph + LangChain + Pydantic
后端B  Java 17 + Spring Boot 3 + LangChain4j + WebFlux
RAG    结构切分 + Embedding + (memory|pgvector|chroma) + BM25 + RRF + Rerank
工具   Function Calling（JSON Schema + 风险分级）：知识库 / Text2SQL / 告警 / 计算器 / 日期
安全   只读 SQL 白名单 + 注入检测 + PII 脱敏 + Human-in-the-loop
记忆   短期窗口 + 长期摘要（memory | sqlite | redis）
观测   自建 Tracer：Span / Token / JSONL / SSE
部署   Dockerfile + docker-compose（PG + Redis + API）

六、小结

这一篇把"为什么做"和"为什么这么选"讲清楚了。 技术选型最重要的是给出"为什么不选另一个"------这也是面试时最容易被追问的地方。