后端转 AI Agent 开发，最难的不是学几个新框架，而是接受一个事实：你面对的系统不再保证「同样输入、同样输出」。这篇路线从思维转变讲起，拆解 Agent 开发的四块技能栈，最后给出三个由浅入深的项目选题。

先想清楚要不要转

动手前先诚实回答三个问题：当前后端路径是否已经明显遇到天花板？未来两三个月，每周能不能稳定拿出十小时以上学习？你愿不愿意碰 Prompt、向量库、模型评估这些陌生东西？

三个答案都确定，再认真规划；有一个勉强，就先拿小项目试水。还有一个心态前提：把 Agent 当成能力叠加，而不是身份置换。企业里的 Agent 项目很少是纯 Python 单体，常见形态是 Java/Go 后端管鉴权、并发、业务和部署，AI 服务管模型调用、检索和编排——你本来就在这条链路里，要补的是另一半，不是把底座扔了。

思维转变：从确定性逻辑到概率系统

写 CRUD 时，你默认世界是确定的：参数相同，SQL 查出来的结果就相同；接口返回错了，就是代码有 bug。修 bug 的方式是找到那行错代码，改掉它。

Agent 不按这套规则工作。模型基于当前上下文逐个预测下一个 token，Temperature、上下文顺序、模型版本的细微差别都会改变输出。同样的问题今天答 A 明天答 B，不是 bug，是系统的固有属性。

这个变化带来三个工程后果：

校验从入口移到出口。 过去你校验用户输入，现在更要校验模型输出。让它返回 JSON，它可能少字段、括号不闭合、编造看起来很像真的内容。所有模型输出进入业务逻辑前，必须过格式校验、字段校验和事实核对，该重试重试，该拒答拒答。

正确性从断言变成分布。 传统测试一个 assertEquals 定生死；评估 Agent 要看一批样本上的指标——工具选择准确率、参数正确率、任务完成率、幻觉率。你要习惯用「95% 的 case 正确」而不是「全部正确」来描述系统质量。

流程从写死变成设计边界。 CRUD 的流程是你逐行写的；Agent 的路径是模型在运行时选的。你的工作从「编写流程」变成「设计它做决策的边界」：给它哪些工具、每步最多花多少 token、循环几轮必须停、什么情况必须交给人。Prompt 管不住的事，要靠状态机、权限和预算控制来兜底。

一句话概括：你不再保证系统每一步怎么走，而是保证它无论怎么走都不越界、不失控、可回溯。

Agent 开发的四块技能栈

LLM API 调用层

这是一切的地基。要求不是「跑通 Hello World」，而是按基础设施标准做：流式输出（SSE，注意 Nginx 缓冲会把流式攒成批量）、超时与指数退避重试、结构化输出（JSON Schema / Function Calling / Strict Mode）加服务端校验、多模型适配与 fallback。特别提醒：永远不要在同步 Web 线程里阻塞调模型，也不要在数据库事务里调模型——前者打满线程池，后者耗尽连接池。

工具设计

工具是 Agent 的手。设计好坏直接决定 Agent 靠不靠谱：工具的 Schema 描述要写到模型不会误解的粒度；参数必须强校验，用户说「最近」，模型可能传 "recent" 而你的方法要日期；工具执行要加超时和熔断；写操作要有权限边界和幂等设计。协议层面了解 MCP 即可，趋势值得跟，项目里不必急着全押。

编排与状态管理

常见范式按复杂度排：ReAct（思考-行动-观察循环）最直观，但复杂任务容易兜圈子；Plan-and-Execute 先规划再执行，代价是多一次调用且计划本身可能错；生产上更稳的往往是 Workflow 为主、只在不确定节点嵌入 Agent 子循环。真正的难点在状态：长任务跑到一半服务重启怎么办？每一步都要能作为状态节点持久化、可断点恢复。高风险操作（写库、支付、外发）必须挂 Human-in-the-Loop 审批。记忆机制也要早考虑：短期靠上下文窗口加滑动截断，长期靠向量库沉淀，写记忆时要有置信度过滤和租户隔离。

评估与观测

没有评估体系的 Agent 是在裸奔。至少要建一套 Golden Set 回归评测：工具选对没有、参数编对没有、不必要的调用多不多、失败后恢复没有。观测上每次调用要留 Trace——Prompt 版本、检索片段、工具参数、各步耗时和 token 成本。评测结果必须和 Prompt 版本、模型版本绑定记录，否则线上效果变差时你无法判断是谁变了。

项目驱动的学习路径

只看不练在这个方向行不通，三个项目由浅入深：

项目一：知识库问答 Agent（2~3 周）。 一个能查文档、带会话记忆的最小 Agent，调 2~3 个工具（向量检索、数据库查询、Web 搜索）。验收标准：中断后能恢复上下文继续跑；检索不到证据时会拒答而不是硬编；有一套 30 题以上的评测集，改动前后能对比指标。这个项目会让你踩遍记忆裁剪、工具超时、长返回稀释注意力这些经典坑。

项目二：带审批链路的运维查询助手（3~4 周）。 面向真实后端场景：查慢 SQL、查日志、查订单状态，只读操作自动执行，任何写操作（如 Kill 会话、修改配置）暂停等人工确认。验收标准：权限边界由代码强制而非 Prompt 约束；每次执行可完整回放；工具调用准确率有量化数据。这个项目练的是工具设计、状态机和 Human-in-the-Loop，也是最贴近企业需求的形态。

项目三：长任务工作流（持续迭代）。 选一个多步骤任务，如「根据主题调研并生成带引用的报告」，用 Workflow 编排主流程，在检索、写作、校验节点嵌入 Agent 子循环。验收标准：步骤状态全部落盘，任意节点失败可单独重跑；有 token 预算控制，超预算自动降级；有端到端质量评估和成本归因报表。做到这一步，你已经具备和面试官深聊 Agent 工程化的资本。

几个现实提醒

别把后端经验扔掉——Agent 上线后拼的还是状态、权限、成本、审计这些你熟悉的词。别急着追多 Agent、A2A 这些高阶概念，先把一个单 Agent 做到稳定：它为什么选这个工具、失败重试几次、日志能不能还原全过程，讲得清这些再加复杂度。最后，市场上「会调 API」的人会越来越多，真正稀缺的是能把 Agent 做成稳定服务的人——那恰好是后端训练给你的东西。