AI Agent 工程师求职文档

AI Agent 工程师 8 周突击学习计划

适用对象：有 10 年 C#/.NET 后端经验、每周可投入 30 小时以上、希望在 2 个月内完成 AI 应用工程岗位准备的开发者。

文档定位

这份计划不是泛泛的“AI 学习路线图”，而是围绕 AI Agent 工程师 岗位要求整理的一份求职导向文档。核心目标只有一个：在 8 周内做出一个能演示、能讲交付、能讲优化、能讲部署与稳定性的项目，让你的既有后端经验顺利迁移到 AI 应用工程场景。

计划刻意避开大而散的学习方式，不追求覆盖所有 AI 概念，而是沿着 Prompt 调优、RAG、Agent 工作流、工程化交付 这条高频岗位主线推进。每一周都要求有可见的交付物，这样学习结果才能自然转化为作品集、简历项目和面试回答。

适用前提

默认前提为：以 Python 为主，向量库采用 PostgreSQL + pgvector，知识源采用 上市公司公告 + 交易所规则文档。这条路线兼顾岗位匹配度、落地速度与面试可讲述性。

路线判断

从当前市面上的 AI 应用工程岗位看，最常见的服务端主线仍然是 Python 生态，尤其是 FastAPI、LangChain、LangGraph、向量检索和部署调试相关能力。虽然 .NET 也能做 AI 应用，但如果目标是提高岗位覆盖面和面试命中率，以 Python 为主更稳妥。

向量库部分，这份计划不走“只选最炫技术”的思路，而是选 pgvector。它足够主流，学习和部署成本低，又能和你原本的数据库、索引、性能调优经验自然衔接。面试时你不仅能讲“会用”，还能讲表结构、检索链路、存储设计和性能治理。

知识源之所以选公告和规则文档，是因为它们公开、真实、结构复杂，既能体现文档解析与 RAG 质量治理能力，又能贴近金融/证券类岗位偏好。这样的项目不会像纯 Demo 一样轻飘，面试官也更容易相信它具备真实业务迁移价值。

你的优势不在于重新做一个初级 Python 开发，而在于把 10 年后端经验迁移到 AI 应用工程里：服务治理、稳定性、边界控制、排障能力、数据建模和交付意识，都是这个岗位真正缺的东西。

技术主线

这类岗位通常不要求候选人训练基础模型，但会非常看重能否把大模型能力做成一个可交付、可观测、可迭代、可上线的应用。你需要重点补的不是传统服务端基础，而是 AI 应用开发特有的几个薄弱环节：检索增强、Prompt 版本治理、工具调用、评测与回归、引用溯源和故障兜底。

能力方向 推荐技术 在项目中的体现
服务端骨架 FastAPI 接口、流式输出、异常处理、健康检查、配置治理
RAG 基础 LangChain + pgvector 文档导入、切分、向量检索、引用返回
Agent 编排 LangGraph Plan → Retrieve/Tool → Check → Final 的工作流
缓存与状态 Redis 会话、缓存、限流、短期上下文管理
文档解析 PyMuPDF、unstructured PDF 内容提取、页码与来源保留
可观测性 OpenTelemetry + 结构化日志 traceId、模型耗时、token 用量、工具调用链路
部署交付 Docker Compose 本地一键起服务、数据库、缓存和向量扩展
测试与回归 pytest 接口测试、Prompt 回归、RAG 评测

八周总览

整套计划采用高强度单主线推进方式。每周建议投入 30 到 36 小时，保持“开发新能力、修 badcase、补工程化、写复盘”四件事并行，不要把所有时间都用来堆功能。

周次 核心目标 本周产出 验收标准
W1 Python 工程地基 + LLM 服务骨架 基础 API、流式输出、结构化输出、README v0 本地启动稳定，接口可跑，日志完整
W2 会话、缓存、可观测、配置治理 session、Redis 缓存、trace、统一响应规范 服务像样，能看日志、能看链路、能处理超时
W3 RAG v1：入库、切分、检索、引用 导入脚本、检索接口、问答接口、首批知识源 回答附带来源，至少导入 30 份真实文档
W4 RAG v2：混合检索、重排、评测 评测脚本、优化记录、badcase 列表 能量化展示优化前后差异
W5 Agent v1：工具调用与工作流 2 个工具、LangGraph 工作流、执行轨迹 问题能触发正确工具，链路可回放
W6 Agent v2：回归、结构校验、兜底 Prompt 回归、拒答策略、结构化校验 改 Prompt 有测试，错误输出有拦截
W7 容器化、压测、稳定性治理 Compose、压测报告、部署文档 能部署、能压测、能说明排障方法
W8 作品集与面试表达收口 README 成品、Demo 脚本、简历项目描述 10 分钟内能完整讲清项目价值和决策

逐周执行

下面把 8 周计划细化为“可勾选”的待办清单，并按 每周 6 天 × 每天 5 个小时块 组织（合计约 30h）。你可以把 H1~H5 理解为 5 个 60 分钟专注段，具体在一天中的哪个时间段由你自己安排。

勾选状态默认保存在当前浏览器本地（localStorage）。如果你希望在多设备之间同步，可用“导出进度/导入进度”把进度文件带走。

W1：Python 工程地基 + LLM 服务骨架 目标：把 FastAPI 服务壳、日志、异常、流式与结构化输出打牢
0/0
D1（约 5h）：项目初始化与工程基线
小时任务完成
H1创建仓库与目录结构（app/prompts/tests/docs 等）
H2建立 Python 环境与依赖管理（pyproject/requirements 二选一并固定）
H3加入格式化/静态检查（ruff/black 或等价组合）并形成统一命令
H4配置分层：env → config 模块 → 运行时注入（本地/生产）
H5建立结构化日志骨架（统一 traceId 字段，先打通写日志）
D2（约 5h）：FastAPI 基础服务壳
小时任务完成
H1创建 FastAPI 应用入口、路由模块与依赖注入骨架
H2实现统一响应结构（success/error），定义错误码枚举
H3实现异常处理中间件：捕获异常、记录日志、输出统一错误
H4实现 /health 与 /version（包含 git commit、构建时间等）
H5补一轮“本地一键启动”命令（Makefile/justfile/脚本均可）
D3（约 5h）：LLM 调用封装 + /chat
小时任务完成
H1封装 LLM Client：模型名、baseUrl、API key、超时参数
H2定义消息结构（role/content）与会话请求 schema（Pydantic）
H3实现 /chat（非流式）并打日志：traceId、latency、token
H4加入基础重试（仅网络/超时类）与指数退避
H5手动跑通 10 个样例问题，记录 3 个失败样例
D4（约 5h）：流式输出 /chat/stream
小时任务完成
H1定义流式响应协议（SSE 或 chunked），统一字段（delta、done、error）
H2实现 /chat/stream，支持断开连接时中止生成
H3补超时与最大输出长度控制（避免长输出拖垮服务）
H4记录流式关键指标：首 token 时间、总耗时、token 数
H5用 Postman/curl/简单前端脚本验证流式体验与异常路径
D5（约 5h）：结构化输出 + Prompt 模板化
小时任务完成
H1定义 1 个结构化任务：从问题里提取意图/检索关键词/输出 JSON
H2实现 JSON schema/Pydantic 校验（不合法则重试一次）
H3把 prompt 抽到 prompts/（yaml 或 txt），实现加载器与版本号
H4实现 /extract-intent（或等价）接口，输出结构化 JSON
H5准备 20 条结构化用例（输入→期望字段），作为回归基础
D6（约 5h）：测试与文档收口
小时任务完成
H1写 5~10 条接口测试（health、chat、extract-intent 等）
H2补 README：启动方式、配置项、接口示例、常见错误
H3整理日志字段清单（traceId、latency、token、model、errorCode）
H4做一次“从零启动”演练：清缓存/新环境启动并跑通接口
H5复盘：记录 3 个踩坑与修复（写进 docs/ 或 README）
W2：会话、缓存、可观测、配置治理 目标：服务化升级，让一次请求可追踪、可降级、可复盘
0/0
D1（约 5h）：会话态与上下文窗口控制
小时任务完成
H1定义 session 模型：sessionId、消息列表、创建/更新时间
H2实现上下文裁剪策略：最大消息数/最大 token 估算
H3实现 /sessions 创建、读取、清空（最小实现即可）
H4将 /chat 支持 sessionId（服务端拼上下文）
H5用 2 个对话场景验证裁剪是否影响回答（记录差异）
D2（约 5h）：Redis 缓存与键设计
小时任务完成
H1接入 Redis 客户端并抽象 cache service
H2设计缓存 key：model + promptVersion + inputHash + sessionSliceHash
H3实现 /chat 缓存命中与 TTL（仅对确定性场景启用）
H4日志记录 cacheHit/cacheKeyPrefix/cacheTtl
H5验证 10 次请求的命中率与 token 成本下降（写一段结论）
D3（约 5h）：超时、重试、降级
小时任务完成
H1定义“可重试错误”范围（网络/超时/限流），避免逻辑错误重试
H2实现统一超时控制（请求级、模型调用级）
H3实现降级策略：主模型失败→备用模型/简化 prompt/返回可解释错误
H4为降级路径单独打日志字段（fallbackUsed、fallbackReason）
H5模拟失败：断网/超时/429，验证服务表现与错误信息质量
D4（约 5h）：结构化日志与 traceId 贯通
小时任务完成
H1确定日志字段标准：traceId、sessionId、route、latency、token、model、errorCode
H2实现 traceId 注入（请求头/生成），并贯穿到 LLM 调用层
H3对 /chat、/chat/stream、/extract-intent 补关键日志点
H4补“请求摘要日志”：入参摘要、输出长度、cacheHit、fallbackUsed
H5写一段“如何用日志定位问题”的小 runbook（docs/）
D5（约 5h）：指标与 Token 成本统计
小时任务完成
H1实现 token 统计（prompt/completion/total）并记录到日志
H2增加基本 metrics：请求数、错误数、P95（可先用日志聚合代替）
H3接入 OpenTelemetry（最小实现：span 包住模型调用）
H4把“检索/工具调用/生成”预留成独立 span 名称（为后续做准备）
H5跑一轮对比：缓存前后 token 成本与延迟变化（写结论）
D6（约 5h）：文档与重构收口
小时任务完成
H1整理配置项清单（模型、超时、缓存、日志等级、trace 开关）
H2整理错误码与错误信息规范（对调用方友好）
H3补 5 条集成测试覆盖 session/cache/fallback 路径
H4重构：把 LLM、日志、配置、API 层边界清晰化
H5复盘：写 1 页“W2 交付说明”（能直接用于面试表达）
W3：RAG v1（入库、切分、向量检索、引用溯源） 目标：把公告/规则文档导入 pgvector，并实现“回答必须带引用”
0/0
D1（约 5h）：准备知识源与规范
小时任务完成
H1确定知识源范围：20~30 份公告 + 5~10 份规则（先小批量）
H2制定文件命名与来源元数据规范（source、ticker、date、docType）
H3建立 raw_docs/ 存放策略与校验（重复文件、空文件、编码问题）
H4整理 20 个典型问题清单（后续用作 RAG 手工验收）
H5把规范写进 docs/：数据源说明、命名规则、元数据字段表
D2（约 5h）：PDF 解析与文本标准化
小时任务完成
H1实现 PDF 提取（PyMuPDF）：按页提取文本并保留 pageNo
H2实现文本标准化：去页眉页脚/多空格/换行断句（先规则版）
H3将解析结果落盘为 JSON（pages[]），便于调试与回放
H4加入解析质量检查：空页比例、总字符数、异常文档列表
H5选 3 份文档人工对照：页码与文本是否一致（记录问题）
D3（约 5h）：切分策略与 chunk 元数据
小时任务完成
H1定义 chunk schema：chunkId、docId、pageNo、text、tokenEstimate、sectionTitle
H2实现切分：按标题/段落优先，兜底按长度切（避免过碎）
H3实现 chunk 质量统计：长度分布、空 chunk、重复 chunk
H4用 10 个问题做检索试验：topK 里是否出现关键段落（记录）
H5把切分策略写进 docs/（为面试解释做准备）
D4（约 5h）：pgvector 表结构与 embedding 入库
小时任务完成
H1设计表：documents、chunks（含 vector 字段）、ingest_jobs
H2为 pgvector 启用扩展与索引（IVFFlat/HNSW 任选其一先跑通）
H3实现 embedding 管道：批量生成向量、失败重试、写入 DB
H4实现 /ingest：触发导入任务并返回 jobId（异步可后做）
H5导入首批文档并核对：documents 数、chunks 数、索引是否生效
D5（约 5h）：检索接口与引用组装
小时任务完成
H1实现 /retrieve：query→embedding→topK chunks（返回分数与元数据）
H2实现 citations 结构：docTitle、pageNo、chunkText、sourceUrl/filename
H3增加去重策略：同一 doc 相邻 chunk 合并或只保留最相关片段
H4日志打点：retrievalTopK、retrievalLatency、retrievalDocDiversity
H5用 10 个问题验证：引用是否“真的来自文档”而不是胡编
D6（约 5h）：/ask（RAG 问答）与手工验收
小时任务完成
H1实现 /ask：检索→拼上下文→生成（回答必须带 citations[]）
H2在 prompt 中加入“只能基于引用回答/没有依据就说不知道”约束
H3补 20 条手工验收：记录好例/坏例/缺失引用的例子
H4修 2 个最明显 badcase（切分/检索/topK 调参任选）
H5写一页“RAG v1 交付说明”（可以直接面试讲）
W4：RAG v2（混合检索 + 重排 + 评测） 目标：能“量化证明”优化有效，并能解释取舍
0/0
D1（约 5h）：关键词检索（Postgres tsvector）
小时任务完成
H1为 chunks 增加 tsvector 字段与 GIN 索引（中文分词先简化）
H2实现 keyword search：query→tsquery→topK（返回 rank）
H3为关键词检索做去噪：停用词/短词过滤/同义词（先小集合）
H4补对比用例：同一问题分别跑向量/关键词，记录差异
H5把检索结果结构统一：scoreVector/scoreKeyword/scoreFinal
D2（约 5h）：混合检索融合策略
小时任务完成
H1实现融合：向量 topK 与关键词 topK 合并、去重、归一化
H2确定融合公式（如 weighted sum / rank fusion）并写成可配置
H3增加 doc 多样性：限制单文档最大 chunk 数，提升覆盖面
H4记录融合参数：kVector/kKeyword/alpha；写入日志
H5用 20 个问题跑 A/B：纯向量 vs 混合（保留对比结果）
D3（约 5h）：重排（rerank）接入
小时任务完成
H1选择 rerank 方案（API 或轻量模型）并封装成 Reranker
H2实现 rerank：对融合后的候选做重排并返回 scoreRerank
H3限制 rerank 成本：候选数上限、超时、失败回退（不影响可用性）
H4对比 10 个问题：重排前后 top3 引用片段变化（截图记录）
H5把 rerank 的开关与参数写进配置与日志
D4（约 5h）：评测集构建（50~100 条）
小时任务完成
H1按类别整理问题：公告问答、规则问答、对比问答、计算/校验问答
H2为每条问题补 expected：关键引用文档/页码/关键词（可粗略）
H3定义评测输出结构：retrieval hits、citation precision、refusal rate
H4把评测集存为 JSONL（便于扩展/回归）并写说明
H5抽样 10 条做人工校验：expected 是否合理（修正）
D5（约 5h）：评测脚本与指标输出
小时任务完成
H1实现 eval runner：逐条问题调用 /ask 并收集输出与日志
H2计算基础指标：hit@k、citation precision、空答率/拒答率
H3输出报告（Markdown/CSV）：按类别分组 + Top badcase 列表
H4跑 2 组配置对比：纯向量 vs 混合 vs 混合+重排
H5把评测命令写进 README（保证可复现）
D6（约 5h）：badcase 修复与优化报告
小时任务完成
H1挑 3 类 badcase：召回缺失/引用错位/过度发挥（分类）
H2对每类 badcase 找根因：切分/检索/融合/提示词/重排哪个环节
H3修复并回归：至少让 10 条 badcase 指标变好（记录）
H4写优化报告：改了什么、指标怎么变、典型案例截图
H5把“取舍点”写成面试话术：成本/延迟/质量三角
W5：Agent v1（工具调用 + LangGraph 工作流） 目标：Plan-Act-Check 形成闭环，工具可控、链路可回放
0/0
D1（约 5h）：工具边界与计算工具
小时任务完成
H1定义工具白名单与调用规则（哪些问题必须走工具）
H2实现计算工具：输入表达式/参数 → 输出数值（含异常处理）
H3为计算工具定义 JSON schema（参数类型、范围、必填）
H4为工具增加幂等键/重试策略（避免重复副作用）
H5写 10 条工具测试用例（含错误入参）
D2（约 5h）：规则校验工具（贴近证券规则场景）
小时任务完成
H1选一个规则：如公告必备字段校验/违规条款匹配/日期有效性
H2实现规则校验工具：输入文本/结构→输出命中条款与解释
H3定义工具 schema 与返回结构（matchedRules[]、confidence、notes）
H4加失败兜底：规则库缺失/解析失败时返回可解释错误
H5写 10 条规则测试用例（含边界情况）
D3（约 5h）：LangGraph 状态图设计
小时任务完成
H1定义状态：Plan、Retrieve、Tool、Check、Final、Fail
H2定义状态输入输出 schema（保证可追踪与可回放）
H3实现 Plan：判定是否需要 RAG/工具、选择工具、生成行动计划
H4实现 Act：执行检索或调用工具（加超时、重试、参数校验）
H5写 5 个端到端场景跑通：工具/检索/混合
D4（约 5h）：Check 阶段与结构化输出
小时任务完成
H1定义最终输出 schema（回答 + 引用 + 结构化结论）
H2实现 Check：JSON 校验、引用存在性校验、工具结果一致性校验
H3实现 Repair：校验失败→补充检索/重试/切换模板（一次即可）
H4把每一步输入输出记录为“执行轨迹”对象（便于回放）
H5为轨迹加 traceId 并写日志（Plan/Act/Check 分开计时）
D5（约 5h）：错误兜底与可解释失败
小时任务完成
H1定义工具失败分类：参数错/超时/外部故障/规则库缺失
H2实现失败策略：可重试→重试；不可重试→降级为纯 RAG 或拒答
H3为失败输出统一解释字段：reason、nextStep、traceId
H4补 10 个异常用例（工具失败/无引用/JSON 不合法等）
H5写一页“Agent v1 交付说明”（能复述清楚链路）
D6（约 5h）：Demo 场景与演示脚本 v1
小时任务完成
H1准备 3 个演示场景：纯检索问答、工具计算、规则校验
H2为每个场景写“提问脚本 + 期望输出点 + 引用来源”
H3录一段 10 分钟 demo（先自测，不需要完美）
H4补 README：如何跑 demo、如何看轨迹、如何复现失败
H5复盘：写“我为什么这样做工具边界”的面试话术
W6：Agent v2（质量门禁 + Prompt 回归 + 拒答兜底） 目标：改 Prompt 不靠感觉，靠回归；无依据不强答
0/0
D1（约 5h）：Prompt 版本治理
小时任务完成
H1为 prompts 建立版本号与目录结构（v1/v2 或日期版本）
H2实现 prompt loader：按版本加载并写入请求日志（promptVersion）
H3写 prompts/CHANGELOG：每次修改记录目的与影响范围
H4制定“必须回归”的变更类型：输出结构/工具 schema/拒答策略
H5把版本策略写进 README（面试加分点）
D2（约 5h）：Prompt 回归测试框架
小时任务完成
H1整理回归集：结构化输出样例 + RAG 样例 + 工具样例（各 10~20）
H2实现 regression runner：对每条样例调用接口并保存结果
H3断言规则：必须字段、JSON schema、引用数量、是否拒答
H4输出回归报告：通过/失败列表 + 失败原因摘要
H5把回归命令加入 CI（可先本地脚本，后续上 GitHub Actions）
D3（约 5h）：结构化输出校验与自动修复
小时任务完成
H1实现 JSON schema 校验器：不合法直接标记失败
H2实现自动修复策略：用“修复 prompt”重试一次（只修结构）
H3对工具调用输出也做 schema 校验（参数错直接拒绝执行）
H4把校验失败原因写入日志（validationError、repairTried）
H5用回归集跑一轮：统计修复成功率与失败类型
D4（约 5h）：拒答策略与“无依据不强答”
小时任务完成
H1定义拒答触发条件：无 citations/相似度低/超范围/敏感内容
H2实现 groundedness check（简版）：最少引用数 + 相似度阈值
H3拒答返回结构：reason、建议补充信息、traceId
H4补 15 条“必须拒答”的测试用例（写进 regression）
H5复盘：整理 5 条最容易误答的问题类型与防线
D5（约 5h）：工具失败兜底与熔断
小时任务完成
H1实现工具调用超时与并发限制（避免拖垮主线程）
H2实现熔断/降级：连续失败 N 次→短时间禁用该工具
H3为熔断加日志与指标：toolDisabled、coolDownSeconds
H4补 10 条“工具异常”回归用例（让系统输出可解释失败）
H5写一页“质量门禁说明”：上线前必须满足哪些指标
D6（约 5h）：全量回归与稳定性收口
小时任务完成
H1跑一次全量回归：结构化 + RAG + Agent + 拒答
H2修复 5 个最不稳定用例（提示词/参数/阈值）
H3整理“可复现失败案例”：输入、输出、日志、修复提交
H4把质量门禁与回归流程写进 README（面试亮点）
H5复盘：写 10 条“面试追问→你的项目证据”映射
W7：交付与稳定性（Docker + 压测 + 观测） 目标：新机器按文档能启动，能压测，能排障
0/0
D1（约 5h）：Docker 化与 Compose
小时任务完成
H1编写应用 Dockerfile（瘦身、分层缓存、只拷贝必需文件）
H2编写 docker-compose：app + postgres(pgvector) + redis
H3把配置全部通过 env 注入（禁止写死在镜像里）
H4补 healthcheck：数据库连通、redis 连通、模型连通（可选）
H5从零 compose up 演练：确保一键启动成功并能 /health
D2（约 5h）：启动自检与迁移
小时任务完成
H1实现启动自检：pgvector 扩展/表存在/索引存在/版本一致
H2实现最小迁移脚本（init.sql 或 alembic 任选）
H3对 ingest/ask/agent 路径加超时上限与并发控制（先简单）
H4实现限流（按 IP 或 API key）：防止被刷爆成本
H5写“启动失败排查”说明：最常见 5 类错误及修复
D3（约 5h）：观测链路完善（可复盘一次请求）
小时任务完成
H1把检索/重排/工具调用/生成分成独立 span 并记录耗时
H2为关键步骤记录参数：topK、alpha、rerankCandidates、toolName
H3把一次请求的“执行轨迹”落到日志（可按 traceId 聚合）
H4增加成本字段：token、估算费用（可先粗估）
H5写“如何定位慢请求”流程（从日志/trace 到根因）
D4（约 5h）：压测与瓶颈定位
小时任务完成
H1选择压测工具（k6/locust 任一）并写最小脚本（/ask）
H2压测 3 组并发：1/5/10（记录 P50/P95/错误率）
H3拆解耗时：检索 vs 生成 vs 工具（用 trace 验证）
H4做 1 个优化：缓存/连接池/topK/并发限制（选最明显的）
H5形成压测报告：数据、结论、瓶颈与下一步
D5（约 5h）：故障演练与恢复策略
小时任务完成
H1演练：模型不可用（超时/5xx）→降级输出与告警日志
H2演练：数据库慢/断开 → 友好失败与重试策略
H3演练：Redis 不可用 → 缓存降级（不中断主链路）
H4为每类故障补 runbook：症状、定位、缓解、永久修复
H5把 runbook 写进 docs/ 并在 README 链接（面试亮点）
D6（约 5h）：交付文档收口
小时任务完成
H1写部署步骤：从零到可用（含 .env 示例与注意事项）
H2写数据导入说明：样本文档放哪、如何 ingest、如何验证
H3写“常见问题”FAQ：5~10 条（复制粘贴可解决）
H4整理交付物清单：compose、脚本、评测、runbook、demo
H5复盘：形成“上线后最可能出的问题”与对策列表
W8：作品集与面试冲刺（表达收口） 目标：10 分钟讲清“需求→方案→取舍→评测→上线问题→复盘”
0/0
D1（约 5h）：README 重写（让人 3 分钟看懂价值）
小时任务完成
H1README 结构定稿：背景/能力/架构/运行/评测/部署/排障
H2补“为什么这样选技术栈”的一页解释（Python、pgvector、LangGraph）
H3补快速开始：5 分钟跑起 demo（含样本文档）
H4补评测结果展示：表格/截图（前后对比）
H5补“常见问题”与“排障入口”（把 W7 runbook 链接上）
D2（约 5h）：架构图与流程图（可讲清）
小时任务完成
H1画一张系统架构图：API→RAG→Agent→Tools→DB/Redis/LLM
H2画一张时序图：一次 /ask 或 /agent 的步骤与耗时点
H3画一张状态图：Plan-Act-Check-Repair 的转移条件
H4为每张图写 3 句解释（面试时直接照讲）
H5把图嵌入 README 或 docs/ 并确保链接正常
D3（约 5h）：10 分钟 Demo 脚本
小时任务完成
H1写 Demo 结构：背景 1min→能力 6min→稳定性 2min→Q&A
H2准备 3 个问题：引用溯源、工具调用、拒答/兜底（含预期）
H3准备 1 个故障演示：工具失败/模型超时，系统如何解释并降级
H4录屏/截图：作为作品集附件（可选）
H5对着脚本讲 2 遍：把卡壳点改掉（文字化优化）
D4（约 5h）：高频面试问答库
小时任务完成
H1整理 20 个问题：RAG、评测、工具、稳定性、成本、安全
H2每题写“结论一句话 + 项目证据 + 取舍说明”
H3准备 5 个追问：为什么 topK 这么选、为什么拒答阈值这么定等
H4把问答库写进 docs/ 并能快速检索（目录/锚点）
H5做一轮自测：随机抽 10 题限时回答（补短板）
D5（约 5h）：简历项目描述与投递材料
小时任务完成
H1写简历项目条目：一句话业务价值 + 技术栈 + 结果指标
H2补“关键贡献”3~5 条：评测、优化、稳定性、部署、排障
H3准备 STAR 故事 3 个：badcase 修复、线上故障演练、性能优化
H4整理作品集链接（GitHub/Pages），确保无敏感信息与 key
H5准备投递版本 README（简洁版）与面试版本（完整版）
D6（约 5h）：最终收口与再次部署
小时任务完成
H1全量自测：demo 走一遍、回归跑一遍、compose 起一遍
H2清理仓库：删除大文件/日志/临时数据，确保可公开
H3最终部署到 Cloudflare Pages（或更新部署）
H4把“导出进度”文件保存一份（防止浏览器清理导致丢失）
H5做一轮 mock：按 JD 提问自己并记录答案（查漏补缺）

主项目设计

主项目建议命名为 证券/金融文档问答 Agent。它不需要做复杂前端，也不需要一上来做多 Agent 协作。重点是用一条完整链路把你在岗位里最可能被问到的能力串起来：知识源导入、RAG 检索、引用溯源、工具调用、结构化输出、日志链路、回归和部署。

模块 建议范围 这样设计的原因
知识源 上市公司公告、交易所规则 PDF 公开可获取、结构真实、贴近岗位偏好
RAG 向量检索 + 关键词检索 + 引用溯源 足够体现检索质量与工程能力
工具 计算工具、规则校验工具 简单但贴近金融规则场景
输出 自然语言回答 + 结构化结论 便于展示结构化输出与二次消费能力
质量控制 拒答、引用校验、回归、异常兜底 体现“能上线”而不是“会跑 Demo”
运维 容器化、trace、压测、限流 把后端稳定性优势迁移进 AI 项目
控制边界

前 8 周不建议做复杂前端、多 Agent 协作、长链外部工具集成或 K8s 级别的发布体系。求职阶段最重要的是把单项目做深，把质量、解释能力和交付感做出来。

项目结构

下面这套目录结构足够支撑你从 W1 一直用到 W8，不会随着功能增加而失控。它的核心思想是把服务骨架、RAG、Agent、Prompt、测试和评测分开，让后期做回归和排障时更轻松。

ai-agent-app/
├─ app/
│  ├─ api/                 # FastAPI 路由
│  ├─ core/                # 配置、日志、异常、依赖注入
│  ├─ llm/                 # 模型调用封装
│  ├─ rag/
│  │  ├─ ingest/           # 文档导入与切分
│  │  ├─ retrieve/         # 检索、融合、重排
│  │  └─ citations/        # 引用组装
│  ├─ agent/
│  │  ├─ graphs/           # LangGraph 工作流
│  │  ├─ tools/            # 工具定义
│  │  └─ guards/           # 拒答、结构校验、兜底
│  ├─ schemas/             # Pydantic 模型
│  └─ services/            # 业务编排
├─ prompts/                # Prompt 模板与版本
├─ scripts/                # 导入、初始化、评测脚本
├─ tests/
│  ├─ unit/
│  ├─ integration/
│  └─ regression/
├─ eval/                   # 评测集与结果
├─ docs/                   # README、架构图、优化记录
├─ docker/
├─ docker-compose.yml
└─ README.md

第一周开工清单

如果现在就开始动手，第一周不需要再继续搜集大量资料。最好的做法是边搭骨架边学，先把项目跑起来，再用真实问题倒逼你补缺口。下面是一份可以直接执行的开工顺序。

  1. 建立项目目录和 FastAPI 基础应用。
  2. 完成环境配置、日志初始化和异常处理中间件。
  3. 封装模型调用，先只做一个 chat 方法。
  4. 实现 /chat 与 /chat/stream。
  5. 增加一个结构化输出接口，例如“提取问题意图”。
  6. 把 Prompt 抽到 prompts/ 目录中。
  7. 写 5 条基础接口测试。
  8. 补 README 的启动说明与当前能力说明。
第一周完成标志

本地可以稳定启动；模型接口能通；流式输出能返回；至少一个接口输出结构化 JSON；测试能跑；README 写清楚如何启动。只要这 6 件事完成，第一周就算合格。

面试表达重点

后续每一周复盘时，都建议围绕固定问题整理笔记。这样第八周就不需要临时拼凑话术，项目过程本身就会沉淀成面试材料。

  1. 为什么选择 Python 主线，而不是继续把 .NET 当主语言。
  2. 为什么选择 pgvector，它在项目里承担了什么角色。
  3. 你如何证明 RAG 优化真的有效，而不是主观感觉更好。
  4. 工具调用失败或没有依据时，系统如何拒答和兜底。
  5. 如果部署在客户环境，最容易先出什么问题，如何定位和缓解。

只要你能围绕这 5 个问题，把项目中的设计、取舍、指标、坏例子和故障处理讲顺，岗位匹配度就会非常高。对你来说，真正的竞争力不是“我也学过 AI”，而是“我能把 AI 应用做成一个可交付、可排障、可迭代的工程系统”。