01. 整体学习路线

一、整体学习路线：从后端视角看 AI 接入¶

很多人学 Go 后端和 AI 应用时会越学越散。语言学了一些，框架看了一些，RAG、Tool Calling、Agent 也都碰过一点，可一到真正做系统，脑子里还是没有一条稳定主线，不知道该先补哪一层，也不知道什么问题该交给后端基本功，什么问题才真的属于 AI runtime。路线一旦没立起来，后面越努力，返工通常越多。

这一章先把路线掰直。先把岗位位置放正，再把学习顺序排直，最后收成一个能持续演进的主项目。这样后面读 Go、后端、中间件、RAG、Tool Calling 和 Agent 时，你看到的就不再是一堆平行知识点，而是一层层往系统里长出来的复杂度。

先把岗位位置放正¶

这个岗位的本质是：具备 Go 后端工程基础，能将模型能力接入现有业务系统的工程师。核心要求仍是后端工程能力——请求链路、数据库、超时控制、权限、日志、排障、可观测性。AI 的引入只是在原有系统之上增加了模型调用、结果约束和风险控制，并不替代这些基础工作。

正确的定位会自动校正学习重心。注意力会自然落在服务稳定性、资源控制、状态建模和风险治理上。学习重心一旦偏到"哪个 Agent 框架更聪明"，做项目时最先卡住的不会是模型，而是数据库连接池、请求取消、工具审批和错误排查。面试中被追问"超时怎么办""误调用工具怎么办"，这种偏差会立刻暴露。

面试时的表述也很直接：核心能力是后端工程，目前正在把这套能力往 AI 应用侧延展。对有后端背景的人来说，这个定位自然准确。

为什么学习顺序不能反过来¶

这个顺序直接决定是否会在后面反复返工。Go 基础必须先补，因为很多后端和 AI 应用里的故障最后都会回到语言层基本语义上。值传递还是指针传递、slice 底层数组是否共享、map 并发下为什么不安全、context 为什么不能丢进结构体——这些没想清楚，服务一复杂就会出问题。表面在写 HTTP handler 或 RAG 链路，实际是用 Go 的值语义、错误链和并发模型支撑整个系统。

语言基础站稳后，再学 Go 后端工程就顺了。后端工程不是”学个框架”，而是把请求从入口一路安全地带到数据库、下游服务和返回路径。考验的是请求生命周期、中间件、超时、取消传播、连接池、事务边界、日志、测试和优雅退出。语言基础不稳，后端工程就会处于”好像会写，但一出事就不知道为什么”的状态。context 会传但不知何时 cancel，goroutine 会开但没有退出路径，数据库能连但不知连接池为何排队。在此基础上堆更复杂的基础设施和 AI 能力，系统只会更脆。

补中间件与基础设施，是为了把”单体服务能跑”推进到”系统能扛住真实链路”。数据库只能解决一部分问题：热点读写靠缓存，异步解耦和回放靠消息队列，全文检索和语义检索要分开设计，大文件不该硬塞进数据库，多服务协作会把配置、注册发现和健康检查推到前台。写出了 handler 和 service 却在峰值流量、任务积压、索引延迟、配置漂移上发虚，差的就是这一层基础设施心智。

AI 应用最后学，因为它是原有后端链路中插入的概率型、不完全可信、成本敏感的模型节点。传统后端和中间件越熟练，越容易理解真正的难点：模型输出需要结构化约束和服务端校验，流式输出必须接住取消，Tool Calling 不能只靠模型”自觉”，RAG 远不是把文档塞进 prompt。这些本质都是工程问题。学习顺序正确，就能把 AI 自然接回已熟悉的后端主线。

先想清这个岗位到底在替系统解决什么¶

“把模型接进服务”是技术动作，不是业务问题。这个岗位解决的是：公司内部有大量知识、流程和决策链路散落在文档、系统和人工经验里。模型提供了一种让系统更快理解问题、组织信息和协助执行的新方式。模型本身不可靠，工程师要做的就是把这种不稳定的能力收进一个稳定、可控、可审计的业务系统。

业务侧对应四种现实痛点：信息找不到——制度、SOP、知识文档都在，但需要答案时仍要翻页面、问同事、提工单。流程太碎——一次处理要跨知识库、审批、工单和聊天窗口。重复工作太多——消耗精力的往往不是高难度决策，而是重复解释制度、反复查询状态。模型风险大——答错、越权、乱调工具、放大成本，风险没被服务端接住时，模型能力越强，事故越大。

企业买单不是因为”用了 AI”，而是因为系统能更快找到答案、减少重复劳动、稳定完成流程，同时压低错误率和人工负担。把岗位理解成”把不确定的模型能力变成可控的业务能力”，学习重点自然会落到服务稳定性、数据边界、权限审计、工具副作用控制和可观测性上。

企业客服业务只关心三件事：能不能快速给靠谱答案，会不会乱查乱改，出问题后能不能复盘谁在什么时候触发了什么工具。围绕这三件事组织学习，方向不会跑偏。

能力结构为什么一定是分层的¶

从工程落地角度，这个岗位需要的能力是几层彼此咬合的结构，不是平铺的知识点。

最底层是服务端基础能力。必须真的会写 Go 服务，知道 HTTP 请求怎样进入系统，数据库连接怎样被管理，goroutine 怎样启动和退出，超时、取消、日志、测试和排障怎样形成日常工程纪律。这不是”基础分”，而是整个岗位的承重墙。AI 功能运行在真实服务里，这层不稳，模型能力接得越多系统越脆。

第二层是数据和状态建模能力。AI 应用最容易出问题的地方不是模型本身，而是状态混乱。请求状态、会话状态、后台任务状态、文档版本状态、工具执行状态、用户权限状态——这些没有明确建模，路径一复杂，回答、缓存、审计和权限就会一起乱。这类问题常被误认为”模型不稳定”，根源是服务端没把状态边界想清楚。

第三层是对概率系统的控制能力。模型不是数据库查询，不会天然稳定，也不会天然遵守业务边界。结构化输出的重要性、服务端校验的必要性、何时重试、何时停止、何时降级或人工接管，都属于这一层。没有这层能力，模型一旦传错参数、答偏题或调用错工具，不稳定性就会被直接放大成业务事故。

第四层是工具与工作流设计能力。只读工具和写入工具的区分、schema 作为硬边界、部分动作需要审批、写工具要考虑幂等和补偿、长流程需要异步任务和人工介入点——这些不是附加项，而是业务系统开始”做事”后的核心能力。模型进入业务后，最重要的价值不再是”会说”，而是”在正确边界内做事”。

第五层是评测和观测能力。没有离线样本集、线上指标、trace、失败样本复盘、版本对比和成本拆解，就无法判断系统是在变好还是只是”看起来像那么回事”。严肃的 AI 应用团队把 Evals、Tracing、Metrics 当成主线，不是上线后再补的装饰品。

最后一层是业务取舍能力。能判断何时用规则、何时用模型、何时用确定性工作流、何时必须引入人工审批。成熟的工程师不是”所有问题都上 AI”，而是知道哪类问题值得交给模型，哪类必须保持确定性实现。这层能力决定了系统是变得更强，还是复杂度堆得更高。

面试表达可以压缩成一句：这个岗位真正需要的，是同时处理服务可靠性、模型不确定性和业务风险的能力。围绕这句话组织学习，零散知识点会自动归位。

框架选择要围着哪几类工程问题转¶

先问”它解决哪一层问题”，再决定框架。Gin、Kratos、LangGraph、MCP SDK 不应被混在一起比较——它们处理不同层次的复杂度。

HTTP 服务效率层：Gin、Chi、Echo、Fiber 组织路由、挂中间件、绑定参数。解决请求如何高效进入系统，不解决数据库设计、Agent 循环治理或工具审批。

服务治理与 RPC 层：Kratos、go-kit、Kitex、Hertz 处理服务边界、协议传输、注册发现、可观测性接入。练手项目不需要，企业内部多服务体系需要统一治理时价值才显现。

模型接入层：openai-go、Ollama 兼容接口或 provider adapter，统一模型请求、流式、结构化输出和 provider 解耦。关键是把外部供应商能力隔离成清晰边界。

Agent 编排与状态控制层：OpenAI Agents SDK、LangGraph、PydanticAI、Eino 解决多步循环组织、状态保存、工具接入、人工审批和中断恢复。流程不再短平快时才需要。

MCP 层：解决跨进程、跨语言、跨部署边界的工具互操作。不天然解决业务权限模型、多租户隔离和高风险审批。

评测与观测层：OpenAI Tracing、LangSmith、OpenTelemetry 不直接创造业务功能，但决定了能不能看清系统在做什么。

框架按复杂度来源选，不按热度选。缺 HTTP 入口效率看 Gin 或 Chi，缺模型统一接入补 provider adapter，缺长流程状态控制看 Agent 框架，缺跨系统工具互操作看 MCP。

为什么别一上来就钻 Agent 框架¶

Agent 框架容易让 demo 看起来完整，但封装太多，会制造”已经理解系统”的错觉。框架做了大量默认决策，一旦线上需求与这些默认决策不一致——需要更细的鉴权、更严格的幂等、更复杂的超时策略——底层没有打通就会立刻暴露。

Agent 框架在原型期和多工具流程变复杂时有价值。但抽象层一厚，排障变难，默认流程未必适合业务边界。很多该被当成工程问题的事会被误包装成”调 prompt 就能解决”。

默认学习路线：先把普通 Go 服务写对，再接模型调用，再补结构化输出、RAG、Tool Calling、流式返回、评测和安全。这些能力各自有明确位置后，再决定是否引入框架。

判断标准：如果问题还是”Go 服务没写稳””超时和取消没打通””数据库和异步任务没有工程感觉”，Agent 框架不是瓶颈。问题变成”多步工具循环难组织””状态和 trace 难看清””人工审批需要被显式建模”，框架才开始显示价值。

选一个能持续长大的主项目¶

把前面知识串成主线，关键是选一个会反复碰到同一条系统主链的项目。项目应同时包含 HTTP 入口、状态存储、异步任务、检索或外部能力接入、流式返回、权限边界和可观测性。每补一层能力，都是在同一条链上继续往下挖。

知识库问答系统是个稳的例子，天然把文档处理、检索、引用、流式回答、权限和评测焊在一起。工单助手、运营审核台、开发型 Agent、文档处理平台也可以。要避免的是每学一个词就重开一个小 demo，最后每个 demo 只证明”见过这个概念”。

默认做法按阶段推进：第一版跑通服务骨架、数据库和最小主链。第二版补异步任务、状态查询和错误收口。第三版补检索、结构化输出、流式返回或工具接入。第四版补评测、观测、缓存和更重的 runtime。每一轮补哪类复杂度很清楚，面试里也更容易把”为什么这样拆、哪里先坏过、怎么收住”讲成完整链路。