Python Agent 能力提升计划

目标与边界

• 当前状态：Python 基础已学，LangChain/LangGraph 概念能理解和口述，但主要依赖 AI 生成代码；FastAPI、asyncio 和工程排障是当前最明显短板。
• 当前阶段：不中断投递和面试，先用 14 天降低技术交流中的暴露风险，再用 4 周形成一个能独立修改、调试和讲解的项目闭环。
• 时间假设：工作日每天约 3 小时，周末一天 5-6 小时；若当天有面试，使用文末“沟通日最小计划”。
• 项目策略：企业知识库 Agentic RAG 作为唯一主项目，BI Text2SQL 作为第二项目；Multi-Agent 和政务助手只保留概览，不平均投入。
• 学习策略：不要求脱离 AI 写完整项目，但核心流程必须先自行设计、能够修改、能够制造故障并定位。

现有材料分工

• FastAPI 基础：公开知识站 guide/fastapi-basics，重点覆盖 Pydantic、Depends、错误处理和 async/await。
• Python 工程：公开知识站 guide/python-engineering，重点覆盖协程、阻塞调用、超时、并发限制和 pytest。
• Tool Calling：公开知识站 guide/agent-tool-calling，重点理解模型只产生调用意图、工具由程序执行。
• LangGraph：公开知识站 guide/agent-langgraph，重点掌握 State、Node、条件边、循环终止、checkpoint 和 HITL。
• SSE：公开知识站 guide/agent-streaming，重点完成 FastAPI 服务端流式输出和错误降级。
• BI 项目：公开知识站 guide/agent-text2sql，重点掌握 SQL 生成、校验、失败回环和终止条件。
• 本站 12 · 核心技术要点 Q&A 只用于检验，不把阅读答案当作当天学习成果。
• 本站 10 · 方案口述概述 用于口述训练，每天只练一个版本并录音。
• 实操基于 fullstack-road/projects/agentic-rag/，不另找课程或新框架。

每日固定模板

每天 3 小时固定分配，顺序不能颠倒：

1. 20 分钟：闭卷回答昨天的 3 道题，答完才看材料。
2. 100 分钟：编码或排障，只完成当天指定的一个垂直任务。
3. 30 分钟：对着当天代码口述“输入、流程、失败、处理、取舍”，录音并回听一次。
4. 30 分钟：投递、记录交流反馈、把新问题加入弱项清单。

AI 使用规则：

• 先自行写接口契约、数据结构、伪代码和失败分支，再让 AI 补局部实现。
• AI 一次只处理一个函数或一个明确错误，不让它整体重写项目。
• AI 给出的代码必须运行测试，并主动改一个需求，确认自己能维护。
• 第二天闭卷复述核心流程；不要求逐字重写样板代码。

前 14 天：基础止血期

第 1 天：建立基线

• 运行现有项目测试：cd projects/agentic-rag && uv sync && uv run pytest。
• 启动项目并打开 /docs，实际调用一个健康检查或开发鉴权接口。
• 闭卷回答：FastAPI 做什么、Pydantic 做什么、async def 解决什么问题。
• 产出：一张弱项表，分为“不会”“会说不会改”“能独立处理”。

第 2 天：Pydantic 与接口边界

• 自己写一个最小 FastAPI 应用：POST /chat，请求包含非空 question 和 1-20 的 top_k。
• 验证正常请求、422、404 三种响应。
• 写至少 3 个接口测试。
• 口述：为什么校验放在 Schema，而不是全部写进路由函数。

第 3 天：亲眼看到事件循环被阻塞

• 写 /blocking 使用 time.sleep(2)，写 /non-blocking 使用 await asyncio.sleep(2)。
• 并发请求两个接口，记录完成时间差异。
• 把同步阻塞函数改成 await asyncio.to_thread(...)，再次比较。
• 口述：异步不让单次模型请求更快，它提高的是等待期间的并发能力。

第 4 天：异步模型调用

• 使用 httpx.AsyncClient 封装一个假模型 HTTP 调用。
• 加连接/读取超时、异常转换和最多 2 次重试。
• 测试成功、超时、不可重试错误。
• 口述：异步客户端、to_thread、独立 Worker 分别适合什么情况。

第 5 天：Depends、401 与 403

• 写一个读取 Bearer Token 的 Depends。
• 区分未登录 401 和无权限 403。
• 给 /chat 加权限依赖并写对应测试。
• 口述：依赖注入和中间件的职责差异。

第 6 天：SSE 最小闭环

• 写 POST /chat/stream，依次发送 start、token、done 事件。
• 中途抛出一次模拟工具异常，确保流内返回可识别的 error 事件。
• 能从浏览器或命令行看到逐段输出，而不是最后一次性返回。
• 口述：为什么该场景选 SSE 而不是 WebSocket。

第 7 天：第一次闭卷重建与问答演练

• 用 90 分钟从空目录重建：FastAPI、Pydantic、Depends、一个异步调用、一个测试。
• 不要求记住 import；允许查官方 API，但不复制自己的旧代码。
• 进行 30 分钟问答演练，问题只从 Python 异步和 FastAPI 两节抽取。
• 复盘只记录三项：答错、答虚、缺少项目例子。

第 8 天：手写最小 Agent Loop

• 不使用 LangChain/LangGraph，实现“模型决定工具 → 执行工具 → 回填结果 → 再问模型 → 最终回答”。
• 至少包含两个假工具，并正确关联 tool_call_id。
• 使用假模型响应，避免把时间消耗在 API 配置上。
• 口述完整消息流，不看代码也能讲清每一步。

第 9 天：Agent Loop 失败控制

• 增加 max_steps、总超时、工具超时、Token/成本预算。
• 检测连续重复的“同工具 + 同参数”。
• 达到上限后返回可解释的降级结果，不能静默退出。
• 测试工具参数错误、工具超时、重复调用和正常结束。

第 10 天：从 Loop 迁移到 LangGraph

• 将第 8-9 天流程改成 State、Node、Edge 和条件边。
• State 至少包含 messages、retry_count、last_error 和 final_answer。
• 验证校验失败回到生成节点，达到次数后进入失败节点。
• 口述：为什么这里使用 LangGraph，而不只说“分支很多”。

第 11 天：正确理解 checkpoint 与 HITL

• 在 SQL 执行或敏感工具执行前加入人工确认节点。
• 保存 checkpoint，模拟暂停后恢复。
• 明确区分：重试上限负责终止；checkpoint 负责保存和恢复状态。
• 闭卷回答 checkpoint、thread_id、interrupt 三个问题。

第 12 天：BI Text2SQL 小图

• 画出并实现简化图：问题改写 → Schema 召回 → SQL 生成 → SQL 校验 → 执行/重试/失败。
• SQL 校验至少覆盖只读限制、表白名单和强制 LIMIT。
• 不接真实大模型也可以，重点验证分支和失败回环。
• 用 2 分钟讲清为什么不能让模型直接执行 SQL。

第 13 天：主项目代码认领

• 从 projects/agentic-rag/app/main.py 进入，沿一个 API 跟到 Schema、业务函数和返回结果。
• 再沿一个问答请求跟到 LangGraph、检索、引用校验和 SSE。
• 亲自修改一个小需求并补测试，例如新增字段校验或一种错误响应。
• 产出一张“我能证明的项目链路图”，每个节点写对应文件或测试。

第 14 天：正式评估

• 完整运行 uv run pytest 和 uv run ruff check .。
• 完成 45 分钟问答演练：FastAPI 3 题、异步 3 题、Agent/LangGraph 4 题、项目追问 3 题。
• 录制主项目 2 分钟介绍和 5 分钟深挖版。
• 根据结果决定进入后 4 周；不因某题答错而重学全部内容。

第 3-6 周：能力稳定期

第 3 周：RAG 主链路

• 只学习并验证：切分、Embedding、召回、Rerank、引用、拒答。
• 每天从现有 Agentic RAG 项目选一个模块，先画输入输出，再读代码，再改一个测试。
• 周验收：能解释一次问答从 API 到最终引用的完整调用链；能制造召回为空和引用错误两类失败。

第 4 周：后端可靠性

• 覆盖 SQLAlchemy async、事务边界、任务状态、幂等、重试和 Worker。
• 实际追踪一次“上传 → 提交任务 → Worker → 发布”的状态变化。
• 周验收：能回答同步阻塞如何排查、任务为什么不能只用 BackgroundTasks、重试为什么需要幂等。

第 5 周：安全、部署与可观测

• 覆盖 JWT/RBAC、检索权限过滤、Prompt Injection、Docker、结构化日志和耗时指标。
• 给一个关键请求增加 request ID 和分阶段耗时日志。
• 周验收：能用日志定位一次模拟慢请求，并说出接口层与数据层双重权限约束的理由。

第 6 周：表达转化

• 主攻企业知识库项目，BI 项目作为补充；其他两个项目只保留 30 秒版本。
• 每个主项目准备：1 张架构图、3 个技术取舍、2 个失败案例、1 组可核实指标。
• 至少完成两次 45 分钟问答演练，第二次不能重复第一次的主要错误。
• 根据真实交流反馈更新高频问答，而不是继续无限扩充知识点。

沟通日最小计划

当天有正式交流时只执行 45-60 分钟：

1. 10 分钟：自我介绍和主项目 2 分钟版各说一次。
2. 15 分钟：复习上次答错的 5 道题。
3. 15 分钟：画主项目架构图，讲一个失败案例。
4. 10 分钟：检查目标 JD，只复习简历和 JD 的交集。
5. 交流结束 10 分钟内记录原题、追问、卡点和改进答案。

每周日复盘模板

• 本周真正运行或修改了什么？
• 哪三道题仍然只能背答案？
• 哪个错误是自己定位出来的？证据是什么？
• 简历中哪些“我负责”还没有代码、日志、测试或真实经历支撑？
• 下周只保留哪三个最高优先级弱项？

验收标准

14 天后必须达到：

• 60-90 分钟内从空目录搭出 FastAPI + Pydantic + Depends + 异步调用 + pytest 的最小服务。
• 能解释 422、401、403 的区别，并用测试复现。
• 能通过实验说明 time.sleep、asyncio.sleep 和 asyncio.to_thread 的差异。
• 能实现最小 Agent Loop，并处理最大轮数、超时、参数错误和重复工具调用。
• 能准确区分条件重试、任务终止、checkpoint 和 HITL。
• 主项目 2 分钟介绍不看稿完成，至少扛住三层“为什么”追问。

6 周后必须达到：

• 能沿代码说明主项目一条完整请求链路，并独立修改其中一个节点和测试。
• 能根据日志定位至少一种慢请求或失败工具调用。
• 每个简历核心主张都有真实经历、代码、测试、日志或可核实数据之一支撑；没有支撑的内容降级表述。
• 两次完整问答演练平均达到 7/10，且 FastAPI/异步单项不低于 6/10。

风险与应对

• 风险：继续把阅读和背诵当成学习。应对：每天编码时间固定高于阅读时间，未产生运行结果不算完成。
• 风险：AI 再次代替思考。应对：先写契约和失败分支，AI 只补局部；每段生成代码必须修改需求或制造故障。
• 风险：四个项目平均用力。应对：主项目投入 60%，BI 投入 25%，其余只占 15%。
• 风险：正式交流打断计划。应对：使用“沟通日最小计划”，次日从原进度继续，不重新开始。
• 风险：材料描述超过真实经历。应对：优先核实数字和个人边界；无法举证的第一人称成果必须降级，不靠背诵硬撑。

停止条件

• 不再因为“还没全部学完”推迟投递。
• 达到 14 天验收后，停止重复学习 FastAPI 基础，转为根据反馈补洞。
• 达到 6 周验收后，学习计划转成“真实问题驱动”，不再按技术名词扩张范围。