前端转 AI 全栈，到底应该按什么顺序学？

最近，"前端已死，全栈永生" 又开始在技术圈流行。

支付宝体验技术部已经解散并完成拆分，原有人员分流到各条业务线。这件事传开以后，很多人又往下推一步，变成 "前端作为独立工种肯定会消失"。

更准确的事实是，支付宝体验技术部 AFX 作为典型的前端中台，已经被打散进业务线。公开信息里，岗位名称从前端工程师统一调整为 Agent 开发全栈工程师。这不是支付宝不需要前端了，而是中台模式在 AI 落地期碰到了边界。

过去七八年，中台把通用技术和能力集中起来，是为了少重复造轮子、统一标准，也确实养出过高峰期的大团队。AFX 先后孵化出 Ant Design、AntV、Egg.js、语雀等至今仍被大量使用的产品，说明中台曾经有效。争议也一直在，离业务太远时，响应慢、决策链条长，业务一进入快迭代，中台就容易变成瓶颈。

大模型把这个矛盾推到明处。AI Agent 正在改写用户与产品的交互方式，传统前端边界被拉开，工程师还要补上大模型调用、逻辑编排和服务端对接。集中供给很难跟上这种变化，把人沉到业务线，反而更容易贴着场景改。过去两年，多家头部公司已经对中台做过缩减或打散。支付宝这次变动不是孤例，更像行业转向的一个缩影。

组织边界可以调整，工程问题不会一起消失。AFX 公开主页仍在更新面向 AI 流式输出的小程序 Markdown 渲染器、移动端 UX 缺陷诊断多模态模型、Agent 记忆、Rust 工具链，以及围绕 AI 工程展开的基础设施。前端工作还在，但它不再只围绕页面、组件和接口联调展开。

同样的变化也出现在 Next.js 。Next.js 团队在 2026 年发布了 Building Next.js for an agentic future，明确提出要把 Coding Agent 当成框架的一等用户。框架开始主动向 Agent 提供版本匹配文档、运行时错误、浏览器日志、路由信息和调试能力，而不是只等待模型根据训练数据猜测项目行为。

支付宝 AI 付也已经提供面向 Coding Agent 的文档和 Skill 安装方式，开发者可以通过 npx 安装支付宝支付 Skill ，再让 Cursor 、Claude Code 等工具读取规则并辅助完成接入。这说明 AI Coding 正在从个人效率工具，进入框架、SDK 、支付和企业服务的正式交付链路。

前端接下来要补的，不是换一个框架名，也不是在简历里多写 "会调用大模型"。更现实的顺序大致如下：

• 先把 AI Coding Agent 用进日常开发
• 再把项目规范、Skills 和验证流程写清楚交给它
• 同时补上服务端、数据库和部署
• 然后进入 AI 本体：先懂大模型架构，再学解码参数、结构化输出与缓存
• 接着做 Prompt 、Context 、记忆，再学 Embedding 、BM25 、RAG 和 Function Calling
• 工具暴露分清进程内工具、CLI 和 MCP ，再把 Skills 接到 Agent ，用 LangChain 、LangGraph 编排
• 确有需要时再上意图识别、Supervisor 与多 Agent
• 上线前补评估与 AI 监测，分清 Promptfoo 、Langfuse 、LangSmith 、Helicone 、Phoenix 各自管哪一段

名词记全没用，缺了哪块会卡住、用错会出什么事故，最好都能在自己的项目里验一遍。

前端框架正在同时服务人类开发者和 Coding Agent

过去评价一个前端框架，主要看它能不能让开发者更快地写页面、组织路由、请求数据和完成构建。

接下来还要增加一个判断标准：

Coding Agent 能不能准确理解这个项目，并在真实运行环境里修改和验证代码？

Agent 可以读取文件，却不一定知道浏览器中发生了什么。开发者看到 Hydration Error 时，可以观察页面、控制台和错误覆盖层； Agent 默认只能看到源码和终端输出。当用户只告诉它 "修复页面报错"，它很可能连具体错误都没有拿到，只能从代码结构中猜测。

Next.js 因此开始把运行状态暴露给 Agent 。DevTools MCP 可以让支持 MCP 的 Coding Agent 访问开发服务中的错误、路由、渲染信息和运行状态。根据 Next.js AI Coding Agents 指南，框架还会把与当前安装版本匹配的文档放进 next 包，并通过项目根目录中的 AGENTS.md 引导 Agent 先阅读本地文档，避免依赖已经过期的训练知识。

框架把这些能力补出来以后，前端工程师的日常也会跟着变。自己读文档、写代码、修 Bug 还在，但又多了一层工作：

• 给 Agent 准备准确的项目上下文
• 写清哪些目录可以改、哪些不能动
• 把框架版本和项目规范写进机器可读文件
• 让 Agent 能看到浏览器错误和运行日志
• 把常见任务沉淀成项目 Skills
• 用类型检查、测试和浏览器验证兜底
• 审查 Agent 有没有扩大修改范围
• 对最终合进主分支的结果负责

这些环节缺一块，生成代码就容易返工。上下文不够、框架版本拿错、看不到运行时报错、测试没拦住、Review 没盯住，都会把结果打回去重来。

方便 Agent 写代码，不等于工程师可以少懂框架。缓存策略用错、服务端数据泄漏到客户端、鉴权被破坏、Bundle 被撑大，这些问题还是得人先认出来。

以后前端更常做的，是把边界定清楚，让人和 Agent 一起把结果交出去，而不是亲手敲完每一行。

第一阶段：先把 AI Coding 变成项目能力

这一步先别急着学 LangChain ，也别先背 Transformer 、Embedding 和向量库。先把 AI Coding 工具用进真实项目。国外常见的有 Claude Code 、Codex 、Cursor 、Gemini CLI ，国内也要把 Trae 、通义灵码、文心快码、CodeBuddy 这类工具练熟。工具界面不一样，项目级用法是同一套。

很多人已经在用，但还停在 "帮我写个页面"、"帮我修个 Bug"。这适合试用，不适合长期维护。Agent 不知道项目为什么这样设计，不清楚哪些文件不能动，也不知道什么叫完成，很容易改错业务边界。

这一阶段要练的是项目级用法，按下面几步推进。

先摸清 Agent 的权限和工作方式

动手前先搞清楚它当前能做什么：

• 能读哪些目录
• 能不能直接改文件
• 能不能跑 Shell ，哪些命令要人工批准
• 能不能访问网络、环境变量和密钥
• 是否跑在沙箱或独立 Worktree
• 会话中断后怎么恢复
• 改完后 Diff 在哪里看
• 用什么证据证明任务做完

不同工具的审批开关、沙箱和 Worktree 叫法可能不同，但这些问题都要先答清楚，再让它动真项目。

进陌生项目时，先别开大功能，按这个顺序练：

• 只读摸底：说明入口、模块、状态管理、数据流、依赖、测试命令和高风险目录，推测必须标出来
• 小范围改动：只动指定功能，禁止碰公共组件和无关文件，改前说影响范围和验证计划，改后跑检查并列出未解决风险
• 固定节奏：先证据、再计划、后修改、最后验证。Agent 说 "已经完成" 不算结束

这三步跑通以后，再谈项目规则和 Skill 。权限没摸清就开大功能，后面很难收场。

把项目规则写进仓库

别每次开新会话都重新口述技术栈、目录和测试命令。把长期稳定的知识写进仓库，例如 AGENTS.md、CLAUDE.md、架构说明、开发规范、测试说明、安全边界和数据约束。国内工具如果另有项目说明文件，同样放进仓库，别只留在聊天记录里。

写进去的内容要短，只留每次任务都必须遵守的东西：

• 技术栈和目录职责
• 状态与数据怎么流转
• 常用开发、检查和测试命令
• 哪些模块不能随便改
• 哪些操作必须人工确认
• 完成前要跑哪些验证
• 哪些密钥和配置不能进仓库

手册式长文会浪费 Token ，也会把真正重要的约束冲淡。长期规则放项目上下文，某一类任务的做法再沉淀成 Skill 。

把重复任务沉淀成 Skill

项目规则管每次都要守的边界，Skill 管一类可重复任务怎么做，当前 Prompt 只描述这一次目标。按 Anthropic 的 Agent Skills 说明，Skill 可以按需加载，项目里可以有很多，但每次只拉相关的那几个。国内工具如果提供项目级技能、规则包或工作流模板，按同样边界来沉淀即可。

开源 Skill 大多是通用能力，或者只适配某个特定场景。能拿来参考，但不能指望装一套就覆盖自己的项目。真正要写的，是按项目需求定制的 Skill：你们的业务边界、禁止改动的目录、验收标准和失败时怎么停，只有自己最清楚。

这一步要做的是：

• 先从自己项目里挑反复出现的任务，例如单位适配、Bug 定位、Review 、发布检查
• 每个 Skill 写清触发条件、要读什么、工作顺序、能动哪里、不能动哪里、怎样算完成、不确定时何时停下
• 开源 Skill 只当模板或对照，改成贴合本仓库的规则后再用
• 用几类任务测触发：该用的能命中，不该用的不误触，碰到禁区要停下来追问
• 能用脚本拦住的确定性检查交给脚本，别全丢给模型判断

Claude Code 里项目级 Skill 一般放在 .claude/skills/，个人通用的可以放在 ~/.claude/skills/。其他工具放到各自约定目录即可。具体文件怎么写，跟官方文档走，这一阶段先把边界和流程立住。

这些能力一起转起来以后，项目级 AI Coding 才算成形，而不是只装了一个 CLI ，也不是只堆了一堆开源 Skill 。

这一阶段怎样算过关，不是看装了多少工具。新会话起来后，Agent 能读到项目规则，匹配到相关 Skill ，先说计划，只改允许范围，跑完规定检查，并交出能人工核验的 Diff 和测试证据，这一阶段就算完成。

第二阶段：后端先判断 Node 和非 Node ，不必一次选完所有语言

前端补后端时，最容易把时间耗在语言比较上：Node 、Go 、Java 、Python 到底学哪个。标准其实很简单，无论 Node 还是别的语言，能让你最快入门、最快跑通一个端到端项目的，就是更好的方案。

不必先定未来十年用什么语言。先按现实约束选一条走通：

• 没有明确限制时，优先走 Node ，复用已有的 JavaScript 或 TypeScript ，少换一个变量
• 公司、岗位或现有业务已经绑在非 Node 技术栈上，就直接跟那条栈，别为了全栈人设硬切语言

两条路都能入门，关键是选完就动手，别两边同时铺开。

没有硬约束时，Node 通常入门更快

前端已经熟悉 TypeScript 和 npm 时，继续用 Node ，可以把精力先放在真正缺的后端问题上：

• HTTP 和鉴权怎么进服务
• 数据库怎么建模，事务失败怎么处理
• 缓存何时失效，异步任务怎么重试
• SSE 断开后怎么恢复
• Agent 状态保存在哪里，工具调用怎么审计

很多 AI Coding 工具和 Agent 工具链也跟 Node 、npm 走得近。Claude Code 的 入门文档 就长期提供 npm 安装，并列出 Node.js 运行环境。这不是说必须选 Node ，只是说明第一次转型时，少学一门新语言，通常能更快碰到真实工程问题。

已有生产约束时，跟现有栈更快

目标团队的权限、交易、数据和基础设施已经建在 Go 、Java 、Python 或其他栈上，继续沿用通常比另起 Node 服务更快。部署、协作和上线路径都现成，入门成本往往更低。

模型调用、流式响应、结构化输出、Prompt 、缓存、RAG 、Tool Calling 、Agent 状态、任务编排、评估与监控，都不绑定 Node 。换语言可以，但学习重点仍是数据库、事务、并发、权限、消息和部署。只换语法重写 CRUD ，不算补上后端。

选路线时只看三件事：

• 哪条路能让当前项目更快交付端到端结果
• 目标团队真实生产系统用什么
• 现在卡住的是语言本身，还是后端基础不够

长期比较语言却不做出可运行项目，是这条路上最常见的浪费。

Node 可以是低成本切入服务端的路，非 Node 可以是直接进入真实生产系统的路。标准不是哪门语言更高级，而是哪条路让你更快上手、更快交付。后面岗位和业务变了，技术栈还可以再调。

第三阶段：先补普通全栈，不要用 AI 掩盖后端基础

AI 产品首先仍然是软件产品。用户、组织、权限、数据库、文件、任务和日志没处理好，模型接进来只会多出一堆说不清的故障。

这一阶段先做一个不包含模型的任务系统，把普通全栈能力跑通。可以用 Next.js 的 Route Handlers 、Server Actions 建立服务端体感，但别把它当成绕过后端的捷径。真正要补的是这些：

• HTTP 请求生命周期、参数校验和异常处理
• 身份认证、权限控制和多租户数据隔离
• 关系型数据库：表设计、唯一约束、事务、并发更新、索引和分页
• Redis：缓存、会话、限流、分布式锁，以及缓存失效怎么处理
• 消息队列和异步任务：投递、消费、重试、去重、失败死信
• 文件上传、SSE 或长连接，以及断开后任务状态怎么恢复
• Docker 部署、结构化日志和基础监控告警
• 单元测试与集成测试，密钥和敏感配置不进仓库

数据库别只停在会用 ORM 。表怎么拆、哪些字段要唯一、一对多和多对多怎么表达、哪些写操作必须进同一事务、并发更新如何避免覆盖、权限条件怎样进查询，这些都要自己想清楚。项目里可以先建用户、组织、成员、项目、任务、文件和审计日志，再主动构造重复提交、并发修改、权限越界和任务失败，看系统怎么表现。

消息队列和 Redis 也一样，重点不是会调 API ，而是弄清什么该同步、什么该异步，消息重复消费怎么办，服务重启后未完成任务还有没有明确状态。监控则要能回答一次请求失败时，日志里能不能定位原因。

这一阶段怎样算过关，可以按这些标准检查：

• 不同组织的数据不能相互读取
• 重复请求不会生成两份业务数据
• 异步任务失败后能够重试，不会静默丢失
• SSE 断开或服务重启后，任务状态仍然可查
• 核心接口有集成测试，失败能靠日志定位
• 密钥和敏感配置不会进入仓库

这些问题还过不了，后面接 Agent 时，普通工程错误很容易被包装成 "模型不稳定"。

第四阶段：正式进入 AI 学习，按这条顺序推进

普通全栈补完以后再进入 AI 本体，别一上来就堆框架和多 Agent 。更稳的顺序是先搞清模型怎么工作，再学控输出、喂上下文和记忆，接着做检索、Function Calling ，以及把能力暴露给 Agent 的几种方式，然后接 Skills 和编排，最后才到意图识别、Supervisor 与多 Agent 。

推荐按这条线推进：

• 大模型架构与基本概念
• 解码参数、流式调用、结构化输出与 Prompt Cache
• Prompt Engineering
• Context Engineering
• 工作记忆、短时记忆与长时记忆
• Embedding 、BM25 与 RAG
• Function Calling 、Tool Calling
• 工具暴露方式：进程内工具、CLI 、MCP
• 把 Skills 接到 Agent 上
• LangChain 与 LangGraph
• 意图识别、Supervisor 与多 Agent

前面没懂，后面很容易把工程问题误判成模型能力问题。

先搞清大模型在干什么

先建立工程向的直觉，不必从零推公式，至少要弄清：

• Token 、上下文窗口、输入输出怎样计费
• Transformer 直觉：模型如何根据已有 Token 预测下一个 Token
• 预训练、微调、对齐各自解决什么问题
• 为什么会幻觉、为什么会遗忘中间约束、为什么长上下文不一定更好
• 聊天模型、推理模型和嵌入模型分别适合什么场景

目标不是成为算法研究员，而是后面调参数、写 Prompt 、做记忆和 RAG 时，知道系统边界在哪里。

再学解码参数、流式调用、结构化输出与 Prompt Cache

会调 API 不等于会控输出，这一步要把常见控制项练熟：

• temperature、top_p、max_tokens、stop 对结果稳定性和多样性的影响
• 流式输出、超时、限流、重试和请求取消
• 结构化输出与 Schema 校验，字段缺失、类型错误时要重试、修复或失败返回
• 输入输出 Token 、首字延迟和单次成本怎么看

这里也要把 "缓存" 先拆开。Prompt Cache 只解决重复前缀的计算成本，不是业务记忆。以 Claude 为例，它通常遵循工具定义、系统规则、消息前缀的层级，稳定内容放前面、变化内容放后面才更容易命中。提示缓存说明 也要求用响应里的缓存写入和读取 Token 判断是否真的命中，只开开关不看命中率、延迟和成本，等于没做。

然后把 Prompt 当成接口来设计

很多人把 Prompt Engineering 理解成找万能提示词，例如指定角色、要求逐步思考，再补一句 "请认真回答"。这对单次聊天有用，却撑不起应用。

Prompt 在系统里更接近接口契约，至少要写清：

• 任务目标和成功标准
• 输入从哪里来，哪些是可信事实，哪些只是用户请求
• 模型能做什么、不能做什么
• 何时发起 Function Calling 、何时追问、无法完成时怎样返回
• 输出结构和失败处理

Anthropic 的提示工程概述 把明确的成功标准、可执行评估方法和初始 Prompt ，列为开始优化前的条件。没有测试样本，所谓优化通常只是根据某一次回答改措辞。

落地时先做分类、信息抽取、内容摘要这类边界清楚的任务，再碰开放式 Agent 。输出要过 Schema ，不能把模型结果直接拼进 SQL 、Shell 、文件路径、支付金额、权限参数或设备控制。Prompt 要按用途版本化，改完跑固定测试，而不是手动问两三个问题。

接着做 Context Engineering

Prompt 只是上下文的一部分。真实请求还会带上项目规则、会话历史、检索结果、工具定义、工具返回、任务状态和安全约束，这些不能无条件全塞进窗口。

Context Engineering 要回答的是当前步骤真正需要哪些信息、哪些可信、哪些过期、怎样组织。常见错误是把聊天记录、全部文档和全部工具一次性扔给模型，上下文越长并不代表效果越好。

每次组装上下文前先判断：

• 当前步骤目标是什么
• 哪些事实会影响下一步
• 信息来自用户、数据库还是模型推测
• 数据是否仍有效、是否有权限
• 该留原文还是只留摘要
• 步骤结束后哪些信息要写回状态或记忆层

答不清就不该把整段资料原样塞进去。稳定前缀适合 Prompt Cache ，动态检索和当前问题按步骤构建。

把记忆单独学清楚，别和缓存、RAG 混为一谈

很多项目把 "把聊天记录全塞回去" 当成记忆，这不够。工程上至少要分清三层：

• 工作记忆：当前这一轮 Agent 循环里的临时状态，例如正在执行的步骤、中间工具结果、待确认项
• 短时记忆：本次会话里仍然有效的对话摘要和关键结论，受上下文窗口限制，通常要压缩、截断或摘要，不能无限追加原文
• 长时记忆：跨会话仍要保留的事实，例如用户偏好、项目约定、历史决策摘要，落在数据库或专门的记忆存储里，用时再取回

同时还要和另外三件事划清边界：

• Prompt Cache：省的是重复前缀的计算成本，不负责记住用户是谁
• RAG：取的是外部知识文档，不等于个人或任务记忆
• Checkpoint：保存的是任务执行进度，方便中断恢复，也不等于长期记忆

这一步要练的是写入、读取、更新、遗忘和权限。哪些内容值得进长时记忆，哪些只能留在短时摘要，哪些工具结果用完就丢，什么时候摘要、什么时候原文，都要有规则，否则 Agent 要么失忆，要么把过期、越权和噪声信息一起记住。

再学 Embedding 和 BM25 ，并把 RAG 做成数据系统

有了上下文和记忆之后，再做外部知识接入。检索至少要会两条路：

• Embedding 向量检索：适合语义相近、说法不同但意思接近的问题
• BM25 等关键词检索：适合错误码、接口名、产品编号、专有名词这类需要精确命中的查询

两条路解决的问题不一样：只上 Embedding ，精确词容易漏；只上 BM25 ，换种说法又可能找不到。真实项目通常做混合检索，让向量召回和 BM25 召回并行，再视情况做 Metadata Filter 、结果融合和 Rerank 。

RAG 远不止 "文档切片、写入向量库、相似度检索"，而是一条持续维护的数据链路：

• 文档解析与清洗，保留标题、来源、版本和页码
• 按文档类型切片，而不是只按字符数切
• Embedding 召回加 BM25 召回，必要时做 Metadata Filter 、融合和 Rerank
• 权限在检索前生效，不能先召回再让模型决定能不能看
• 文档更新、删除后，向量、全文索引和缓存同步清理
• 建立固定问题集，检查召回、引用、拒答和权限隔离

初期用 PostgreSQL 加 pgvector，再配合全文检索或 BM25 做混合搜索就够了，不必一上来堆多个向量库。能问出答案只是 Demo ，能更新、删除、隔离、引用和评估，才算 RAG 系统。

明确学会 Function Calling 、Tool Calling

OpenAI 生态里常叫 Function Calling ，Anthropic 和其他文档里常叫 Tool Use 或 Tool Calling ，说的是同一件事：模型不会真的查库、发邮件或改订单，它只会返回一份结构化的函数或工具调用请求，由应用读取请求、校验参数、执行函数，再把结果作为下一条消息交回模型。

边界要先立住：模型负责提出要调哪个函数、传什么参数，业务系统负责决定能不能执行。自己先手写一轮最小循环，把这些契约写清楚：

• 函数或工具的名称、用途、输入输出 Schema
• tool_choice 一类控制：强制调用、自动选择还是禁止调用
• 是否支持并行调用多个函数
• 超时、权限、是否有副作用、是否要人工审批
• 失败结果、重试和幂等方式
• 最大循环次数、Token 预算、终止条件和审计记录

金额计算、权限判断、库存扣减、状态变更交给确定性程序，模型适合意图识别、文本理解、候选方案和非结构化整理。没有这些约束，Agent 很容易在失败分支里反复调同一个函数，或把 "没有报错" 当成任务完成。

工具怎么暴露给 Agent：进程内工具、CLI 和 MCP

Function Calling 解决的是模型怎么提出动作，不解决工具以什么形态接进来。这一层至少要分清三种暴露方式，它们不是升级关系，更不是 "MCP 比 Function Calling 更高级"：

• 进程内工具：应用进程里注册函数，模型一调用就本地执行，延迟低、好调试，适合核心业务动作
• CLI 、Shell：给 Agent 终端能力，直接跑 git、gh、rg、kubectl、测试和自定义脚本。Coding Agent 里很常见，模型对 CLI 训练充分，组合管道强，Token 开销通常更低
• MCP：用统一协议发现和调用外部能力，适合跨客户端复用、结构化 Schema 、需要统一鉴权和审计的外部系统。见 MCP 服务端概念

选型可以按场景判断：

• 高频、本地、已有成熟命令的，优先 CLI ，不必硬包一层 MCP
• 要跨 Cursor 、Claude Code 、自建 Agent 共用同一套外部能力，或需要强类型发现时，再上 MCP
• 核心业务写库、支付、权限校验，优先进程内工具加网关，不要只靠模型拼命令

MCP 的 Tools 规范 也强调敏感工具要能拒绝，服务端要校验和限流，客户端要确认、超时和审计。无论走 CLI 还是 MCP ，权限、幂等和审计都不能省。生产里更稳的结构仍是 Agent 提出调用，网关解析身份，业务服务再校验权限和状态，高风险走人工确认，执行后写审计，再把结构化结果返回。

把 Skills 接到 Agent 上

Function Calling 解决的是单次动作，Skills 解决的是一类可重复任务怎么做。第一阶段里为 Coding Agent 写的项目 Skill ，和这里给业务 Agent 接的 Skill ，是同一套思路：把触发条件、必读资料、步骤、边界和验收写清楚，让 Agent 按需加载，而不是每次靠口头 Prompt 从头讲。

接入时重点练这几件事：

• Skill 元数据怎么注册：名称、描述、适用场景，保证 Agent 能靠描述命中，而不是把全部 Skill 一次性塞进上下文
• 命中后怎样加载：先读摘要，确认相关后再加载完整 SKILL.md、参考资料和脚本
• Skill 与工具怎样配合：Skill 规定流程和边界，真正改数据、查库、发消息仍走 Function Calling ，具体执行可以是进程内工具、CLI 或 MCP
• 开源 Skill 只当模板，最终要改成贴合本项目规则的版本
• 用该触发、不该触发、该停下来追问三类任务，验证接入是否正确

Skills 没接稳就上多 Agent ，只会把混乱的流程复制成多份。

再用 LangChain 组装，用 LangGraph 管长任务

单 Agent 、Function Calling 、工具暴露方式和 Skills 跑通后，再引入框架。LangChain 适合快速组装模型、Prompt 、结构化输出、工具和短任务 Agent ，LangGraph 更适合长时间运行、有状态、可恢复的任务，重点是 State 、条件分支、Checkpoint 、Interrupt 、人工批准和失败恢复。

学习顺序也固定：先对应自己手写过的函数调用和 Skill 加载，看框架替你挡了什么；需要跨请求保存运行事实、等待审批或中途恢复时，再上 LangGraph 。确定性流程继续用普通程序，只有下一步确实要靠语义和当前状态动态判断时，才交给 Agent 决策。

再学意图识别、Supervisor 与多 Agent

大多数项目先把一个可靠的单 Agent 做稳，等任务边界清楚、单 Agent 已经频繁在多种职责间打架时，再拆多 Agent 。

这一步按这个顺序练：

• 意图识别：先判断用户要查知识、改数据、走售后还是闲聊，再决定路由到哪条链路或哪个 Agent
• Supervisor：由一个主管 Agent 负责任务拆解、分派、汇总和终止，子 Agent 只做自己的窄职责
• 多 Agent 协作：明确各自工具、Skills 、上下文和权限，约定交接格式、共享状态和结果合并规则
• 失败与冲突：子 Agent 失败时谁重试、谁升级、谁对用户负责，都要事先写清

没有意图识别和 Supervisor ，多 Agent 很容易变成互相抢话、重复调用工具、结果无法合并。只有任务能明确拆分，并且合并规则清楚时，才值得引入。

这些能力串起来以后，AI 本体这条线才算立住，可以用一张总览图把学习顺序钉死。

这一阶段怎样算过关，不是装了多少框架，而是能按上面顺序讲清每一步解决什么问题，并说清 Function Calling 、CLI 、MCP 各自管哪一层。自己的项目里要做出可控的模型调用、可测试的 Prompt 、可解释的上下文、分层记忆、带权限的 RAG 、带契约的 Function Calling 、按场景选择的工具暴露方式、可按需加载的 Skills ，以及在确有必要时才上的意图识别、Supervisor 和多 Agent 。

第五阶段：评估、AI 监测和安全决定 Agent 能不能上线

普通接口返回 200 ，通常说明请求执行成功。AI 系统返回 200 ，只能说明模型响应成功，既不能证明答案正确，也不能证明工具调用安全，所以评估和监测都不能拖到项目最后临时补。

这一步要同时盯住三件事：组件和任务有没有固定评估，线上有没有可追查的 AI 监测与 Trace ，高风险动作有没有按副作用分级的权限门禁。

组件级评估至少覆盖分类正确率、Schema 解析成功率、RAG 召回、引用正确性、工具选择、工具参数和拒答结果。任务级评估则要看 Agent 是否完成目标、路径是否合理、有没有多余工具调用、有没有越权、是否正确停止、失败后能否恢复，以及最终结果是否符合业务要求。

工具不要一上来全装，先分清离线评估和线上监测：

• Promptfoo：偏上线前的离线评估和 CI 门禁，用固定用例、断言、多模型对比，甚至红队探测，拦住明显回退再发版
• Langfuse：偏生产监测，开源可自托管，负责 Trace 、Prompt 管理、评分、Token 与成本延迟
• LangSmith：同样覆盖 Trace 、数据集和线上评估，和 LangChain 、LangGraph 集成更深
• Helicone：偏网关代理式监测，改 baseURL 就能记请求、延迟和花费，适合先把成本看清楚
• Arize Phoenix：偏 OpenTelemetry 路线，适合已有 OTel 体系、要框架中立 Trace 和评测工作流的团队

常见闭环是：Promptfoo 管发布前回归，Langfuse 、LangSmith 或 Phoenix 管线上真实链路，Helicone 一类网关先把花费和延迟摊开。失败样本再回流进离线测试集，而不是只靠人工点几次 Demo 。

AI 监测和普通服务监控也不完全一样。除了错误率和可用性，还要持续看这些信号：

• 请求级：模型、Prompt 版本、输入输出、Token 、首字延迟、总延迟、缓存命中、失败原因
• 链路级：检索召回、工具选择与参数、工具结果、状态跳转、审批与人工接管
• 质量与成本：用户反馈、拒答率、幻觉相关投诉、单次任务成本、日预算告警、模型降级次数

Trace 记录的是执行事实，不是事后总结。一条完整 Trace 至少要能串起用户输入、Prompt 版本、模型、上下文来源、检索结果、工具名称与参数、工具结果、状态变化、审批记录、Token 、Prompt Cache 命中、延迟、最终输出和用户反馈。没有这些信息，线上出错时往往只能看到最终答案，很难判断问题来自模型、检索、Prompt 、工具还是状态管理。

权限要按副作用分级。只读搜索和普通知识检索风险较低，修改数据、发送消息、执行代码、控制设备、发布内容和发起支付具有真实副作用，需要更严的控制。至少要有工具白名单、最小权限、参数校验、超时、调用次数限制、Token 和费用预算、沙箱、人工审批、审计日志，以及回滚或补偿。生产闭环可以收成一张风险门禁图：

这一阶段怎样算过关：Promptfoo 能拦住发布前的明显回退，Langfuse 、LangSmith 、Helicone 或 Phoenix 一类监测能定位一次线上失败并解释成本与延迟，高风险操作能被拦截，中断后能恢复，新版本能通过固定测试证明没有明显回退。

第六阶段：用一个主项目串起整条路线

学习路线不能拆成十几个互不相关的 Demo 。

Node 写一个 Todo ，Prompt 做一个翻译器，RAG 做一个 PDF 问答，Agent 再调用一次天气接口，每个项目都能运行，但能力之间没有形成连接。

更有效的方法，是选一个主项目一直往上加能力。例如我们最近做的 Coding Agent 桌面工作台，早期只是 pnpm Monorepo 和 Electron 壳能跑起来，后面才一点点补 Agent 循环、权限沙箱、Skills 、上下文压缩、完成校验和中断续跑。面试时你讲的是这个项目怎么长大，不是五个小 Demo 各吹一遍。

共享包里的目录也得跟着职责长，agent、context、permission、prompt、skills、provider 各管一段，打开就能知道改权限去哪、改提示词去哪，而不是让 AI 按需求往一个大文件夹里堆文件，过两周自己都找不着北。

主项目能长期加能力，靠的就是这种边界还在，而不是功能清单越写越长、目录却越来越糊。

意图识别也一样。刚开始做单意图分类就够了，可用户真会说 "这个项目有什么内容啊，要多少次更新啊，都是谁提交的啊"。一句话里项目内容、提交次数、贡献者都要，硬贴一个标签肯定漏，后面才改成先拆成多条意图，能并行的一起查。

拆开之后，一条去读 README，一条去数提交，一条去列作者，比假装只有一个 "查项目" 意图靠谱得多。

Coding Agent 的 Prompt 也翻过车。刚开始觉得 system prompt 写得越全越好，把 Skills 全文、项目说明、安全规则一股脑塞进去，用户才问两轮上下文就爆了，有时还把内部指令复述出来。后来才改成 prompt 里只放 Skills 索引和底线规则，正文用 UseSkill 按需加载，AGENTS.md 单独走指令装配，不跟记忆混在一块。

也不用一上来就按完整产品开干。仓库和进程边界先稳住，模型能改文件、跑命令再说。权限和沙箱往往是翻车之后才补的，上下文爆了、做到一半断了、它自己说做完但测试没过，这些坑踩到了再加压缩、记忆、校验和续跑，比空想一张大架构图实在。

开源的话，别人打开仓库得能看懂你做了什么；闭源的话，至少得给人能用的入口，安装包、在线演示或可申请的试用都行。

架构怎么拆、AGENTS.md 怎么约束、Skills 怎么用、权限怎么拦、完成怎么验、断了怎么续，再留一两个真实翻车记录，该公开的写清楚，不能公开的就在演示和说明里把边界讲明白。

简历里不要只写：

给 Coding Agent 写了一套很长的系统提示词。

更有效的表达是：

Coding Agent 早期把 Skills 全文和项目规则塞进 system prompt ，上下文很快膨胀，后来改成只注入 Skills 索引、按需 UseSkill 加载正文，AGENTS.md 走指令层并与记忆隔离，再用固定改码任务看有没有漏加载、有没有把内部指令泄给用户。

其中所有数字都要来自真实测试，不能为了简历效果编造。

学习过程中最容易走偏的几个地方

路线越长，越容易先堆工具、框架和抽象，却迟迟碰不到一个能反复交付的真实任务。更稳的起点往往是自己正在做的事。例如做抖音内容时，选题、角度、标题、脚本和发布素材会反复出现，步骤一旦稳定，就可以先收成一个 Skill ，把触发条件、素材来源、输出格式和验收标准写清楚，再谈自动化。先跑通 "选题到生成" 这一条链路，比空着手写几十个通用 Skill 更有用。

不要用抽象清单代替真实场景

先选定一个会反复发生的任务，再选一个 Coding Agent ，把上下文文件、权限、Diff 、测试和这个 Skill 跑顺。切换工具很容易，建立项目级使用习惯更难。任务只出现一次、步骤还不稳时，先写进笔记或临时 Prompt ，不要急着封装。

不要用未版本化的 Prompt 凭感觉改

Skill 能跑起来以后，下一处常踩的坑是改 Prompt 。多写两句、换个模型、调一下温度，当场看起来更好了，却说不清比上一版强在哪里，也回不到上一版。Prompt 要按用途版本化，例如 douyin-选题-v3，每次改动保留变更说明和对应测试集。改完先用 Promptfoo 跑离线回归，看选题相关性、标题可用性、脚本结构、敏感词和拒答是否回退，通过后再替换线上版本。没有版本号和固定用例，所谓优化只是在赌下一次手工提问的手感。

回答错误也不等于 Prompt 写坏了。数据没进上下文、RAG 没召回、工具描述不清、权限阻断、状态丢失、模型能力不足、评估标准本身错误，都可能表现为 "答案不对"。先定位环节，再决定改 Prompt 、改检索、改工具还是改验收，而不是每一轮失败都继续堆指令。

不要一开始就学多 Agent ，也不要把框架当必经抽象

大多数项目先需要一个可靠的单 Agent ，加几个边界清楚的工具。多 Agent 会增加上下文同步、状态冲突、Token 成本、结果合并和调试难度，只有任务能明确拆分、交接和合并规则清楚时才值得引入。编排框架同理，先用模型官方 SDK 手写一次结构化输出和工具循环，理解原始调用链后，再判断 LangChain 、LangGraph 是否真能减少重复。否则框架行为和预期不一致时，很难分清是模型问题还是封装问题。

不要为了技术含量过早拆微服务

一个模块化主服务、一个异步 Worker 、数据库和 Redis ，已经足够完成大多数学习项目。只有出现独立扩缩容、故障隔离、运行环境差异或明确团队边界时，再拆服务。

不要相信 Agent 自己宣布完成

任务完成必须由外部证据证明：类型检查通过、测试通过、浏览器行为正确、Diff 没有越界、权限没有放宽、数据没有被破坏，以及真实验收条件成立。对内容类 Skill ，还要能说明选题是否贴合账号定位、脚本是否可拍、有没有触线表述。Agent 的总结只能当参考，不能代替验证。

总结

前端没有因为 AI 消失，变窄的是过去那种只盯页面和接口的职责边界。

Next.js 给 Coding Agent 补 AGENTS.md 和运行时可见性，支付宝把 Skills 放进接入链路，说明 Agent 已经进了正式交付，而不只是个人提效工具。

转 AI 全栈别一上来堆框架。先把 Coding Agent 用进真实项目，规则和 Skills 写清楚，再补后端。语言选 Node 还是别的不重要，HTTP 、鉴权、数据库、缓存、任务、部署这些工程问题逃不掉。全栈底座有了，再按模型、Prompt 、上下文、记忆、RAG 、Function Calling 往下学，工具上分清进程内、CLI 和 MCP ，单 Agent 稳了才谈多 Agent ，最后才是评估、监测、权限和失败恢复。整条路线最好压进一个主项目里长，而不是拆成一堆互不相关的 Demo 。

代码可以让 Agent 写得更快，项目边界、验证标准和最终交付责任还是工程师的事。