第一章：为什么你要学 AI Agent？—— 从"切图仔"到全栈的进化之路 为什么你要学 AI Agent？—— 从"切图仔"到全栈的进化之路 先讲个故事 假设你叫小陈，一个写了三年 Vue3 的前端。你的日常是：接需求、排页面、调接口、改 Bug。偶尔写写 Composable，用 ref 和 reactive 管理状态，用 watch 监听变化，日子过得挺稳。 直到有一天，老板在周会上突然说： "咱们要做个智能客服，能自动回答使用者问题的那种。小陈，你研究一下，两周后给我方案。" 你当时脑子里大概是这样的： 智能客服？ AI？ 我只写过 Vue3 啊... 后端是 NestJS，但那是老王写的，我不熟啊... AI 接口？啥是 LLM？啥是 RAG？ 这是要让我一个前端去搞 AI 开发？？ 你打开搜索引擎，输入"前端怎么开发 AI 应用"。结果出来的全是什么"基础模型微调""Transformer 架构""Attention 机制"——每个字都认识，连在一起就完全看不懂了。你又搜"AI Agent 开发教程"，出来的全是 Python 代码、Google Colab 笔记本、Jupyter 环境配置，看得你脑壳疼。 然后你开始怀疑人生： 我一个写页面的，搞 AI 是不是跨度太大了？ 是不是得先去学半年 Python，再学半年机器训练，才能摸到 AI 的边？ 说实话，这种困惑我太理解了。我当年第一次接触 AI Agent 的时候，也是这种感觉——打开 GitHub，看到一堆 Python 方案，每个项目都有几十个依赖，README 里写着各种我听都没听过的术语。我当时就想：这玩意跟前端有关系吗？我一个写 Vue 的，能搞懂吗？ 但后来我发现，我完全想错了。AI Agent 开发的核心，不是"训练模型"，而是"编排逻辑"。而"编排逻辑"这件事，前端每天都在做——把组件组合起来，把信息流转起来，把用户体验打磨好。等到我真正理解了 Agent 的本质之后，我才意识到： 前端做 AI Agent 开发，不是跨界，而是降维打击。 如果你有类似的困惑，那这一章就是为你写的。我先告诉你结论： 前端在 AI 时代反而有天然优势，甚至比纯后端更容易上手 AI Agent 开发。 这不是鸡汤，下面我会一条条掰开讲。等你看完这一章，你不会再觉得 AI Agent 是遥不可及的东西，而是会想："哦，原来就这么回事，我好像也能搞。" 不过在此之前，我想先帮你理清一个认知上的误区。很多人一听到"AI 开发"，脑子里浮现的画面是：一个博士坐在电脑前，屏幕上全是数学公式，面前摆着几块 GPU 显卡，训练一次模型要跑三天三夜。这种画面不能说错，但那叫 模型研发 ，不是 AI 应用开发 。打个比方： 模型研发 就像在实验室里发明一种新药——需要深厚的化学、生物学知识，需要昂贵的设备，需要漫长的实验周期。这是科学家做的事。 AI 应用开发 就像在药店里根据处方配药——你不需要发明新药，你只需要知道哪种药治什么病，怎么搭配，什么剂量。这是药剂师做的事。 我们这本小册做的事，就是"药剂师"的工作：用现成的 AI 模型（药），搭配助手调用、记忆管理、工作流编排（配方），做出能解决实际问题的 AI Agent 应用。你不需要懂 Transformer 的原理，不需要懂损失函数怎么算，甚至不需要知道"梯度下降"是什么——这些是模型研发人员的事，不是应用工程师的事。 好了，理清了这个认知，我们来看看，为什么前端工程师在"药剂师"这个角色上，反而比别人更有优势。 为什么前端在 AI 时代反而有优势？ 很多人觉得 AI 开发是计算方法工程师的专利，得会 Python、懂深层学习、能训练模型。这个印象也不能说错——如果你要做模型层的工作，比如训练一个大模型、做微调、搞 RLHF，那确实需要深厚的 ML 背景。但问题是， 99% 的 AI 应用开发者根本不需要碰模型层。 打个比方：你开一家餐厅，不需要会种地，只需要会用食材做菜。AI Agent 开发也一样：你不需要自己训练模型，你只需要"用好"现成的模型。种地是农民的事（OpenAI、Anthropic、DeepSeek 这些公司），做菜是厨师的事（你，应用开发者）。 搞 AI Agent，本质上是在做应用层开发，而不是模型层开发。 而说到应用层开发，前端工程师有几个看家本领，在 AI 领域简直是降维打击。 1. 流式渲染：你每天都在写的东西，AI 聊天刚好需要 你有没有用过 ChatGPT？打字的时候，回复是一个字一个字蹦出来的，不是一下子全出来。这种"流式输出"的效果，在 AI 应用里几乎无处不在——因为 LLM 生成文本本身就是一个 token 一个 token 往外蹦的过程，逐字输出是最自然的交互方式。 而实现这种效果，工艺上叫什么？叫 Server-Sent Events（SSE） 或者 Streaming HTTP 。前端同学应该不陌生——你写大文件分片上传、WebSocket 实时消息、进度条轮询，本质上都是在处理"数据流"。数据不是一次性返回的，而是一段一段来的，来了你就更新 UI。 举个例子，下面这段代码，前端同学看着应该很眼熟： // 调用 AI 接口，流式读取响应 // 这跟处理大文件上传的进度回调，本质上是同一件事 const response = await fetch ( '/api/chat' , { method : 'POST' , headers : { 'Content-Type' : 'application/json' }, body : JSON . stringify ({ message : '你是谁？' }) }) const reader = response. body !. getReader () const decoder = new TextDecoder () while ( true ) { const { done, value } = await reader. read () if (done) break // 每收到一段数据，就拼到消息上，UI 自动更新 const chunk = decoder. decode (value, { stream : true }) // Vue3 响应式：改了 messages，DOM 自动更新 messages. value [messages. value . length - 1 ]. content += chunk } 这不就是前端最熟悉的"数据来了，更新 DOM"吗？只不过以前是 API 返回 JSON，现在是 AI 返回文字流，本质上没区别。你甚至会发现， AI 对话的流式渲染，比很多前端项目里的复杂交互还要简单。 在 Vue3 里，我们用 ref 或者 reactive 就能轻松接住这些流式数据。Vue 的响应式系统天生就是做这个的——数据变了，UI 自动跟着变，你不用手动操作 DOM。 而且，你还可以把这段流式读取逻辑封装成一个 Composable，以后任何 AI 项目都能复用： // composables/useStreamChat.ts // 封装了流式聊天逻辑，以后任何 AI 项目都能直接用 import { ref } from 'vue' export function useStreamChat ( ) { const messages = ref< Message []>([]) const isStreaming = ref ( false ) async function sendMessage ( content: string ) { messages. value . push ({ role : 'user' , content, id : crypto. randomUUID () }) isStreaming. value = true const aiMessage = { role : 'assistant' as const , content : '' , id : crypto. randomUUID () } messages. value . push (aiMessage) try { const response = await fetch ( '/api/chat' , { method : 'POST' , headers : { 'Content-Type' : 'application/json' }, body : JSON . stringify ({ message : content }) }) if (!response. ok ) throw new Error ( `HTTP ${response.status} ` ) const reader = response. body !. getReader () const decoder = new TextDecoder () while ( true ) { const { done, value } = await reader. read () if (done) break aiMessage. content += decoder. decode (value, { stream : true }) } } catch (err) { aiMessage. content = '抱歉，AI 响应出错了，请稍后重试。' console . error ( '流式聊天错误:' , err) } finally { isStreaming. value = false } } return { messages, isStreaming, sendMessage } } 封装成 Composable 之后，你在任何 Vue3 组件里都能用 const { messages, sendMessage } = useStreamChat() 一行代码搞定流式聊天。这就是前端工程化的力量—— 把复杂的逻辑封装起来，暴露简单的接口 。这个能力，在后端 AI 开发场景里同样关键——你封装得越好，后续维护成本越低。 而且，Vue3 的 watch 和 computed 还能帮你做更多事情。比如： // 用 watch 监听消息变化，自动滚动到底部 watch ( () => messages. value . length , () => { nextTick ( () => { chatContainer. value ?. scrollTo ({ top : 999999 }) }) } ) // 用 computed 计算当前对话的 Token 用量 const tokenUsage = computed ( () => { return messages. value . reduce ( ( sum, msg ) => sum + msg. content . length , 0 ) }) 这些操作，你写 Vue3 的时候天天都在用，搬到 AI 应用里完全复用。 2. 状态管理：你的 Pinia 经验可以直接复用 一个 AI Agent 对话界面，背后牵涉的状态其实不少，而且比普通的 CRUD 页面要复杂一些： 对话历史 ：用户说了什么，AI 回了什么，每一条都得存着。而且对话一长，你得考虑怎么管理"上下文窗口"——也就是 AI 能记住前面多少内容。前端的分页、虚拟滚动这些技术，直接就能用上。 Agent 思考状态 ：Agent 不是每次都秒回的。有时候它要调工具，有时候它要查数据库，有时候它卡住了。你得告诉用户"正在查询中，请稍等"，而不是让用户对着一个空白页面干等。这就需要精细的状态管理—— idle 、 thinking 、 calling_tool 、 responding 、 error ，每个状态对应不同的 UI 表现。 工具调用状态 ：Agent 调用了哪些工具？调用成功了吗？返回了什么结果？这些信息你得展示给用户（至少展示给开发者自己看），不然出了问题你都不知道是哪一步出错了。 多会话管理 ：用户可以同时开多个对话，每个对话有独立的上下文。这跟聊天软件的"多窗口聊天"一模一样，你写过的。 用户偏好 ：Agent 可能需要在多次对话之间记住用户偏好。比如用户说"我不喜欢太啰嗦的回答"，下次对话 Agent 就应该简洁一点。这些偏好信息也需要在前端持久化。 这些状态管理问题，用 Pinia 一个 Store 就搞定了。你每天都在做的事情，换个场景而已。 // 一个典型的 Agent 对话 Store —— 看看跟你平时的 Pinia Store 有啥区别？ import { defineStore } from 'pinia' import { ref, computed } from 'vue' export const useChatStore = defineStore ( 'chat' , () => { // 当前会话的消息列表 const messages = ref< Message []>([]) // Agent 当前的思考状态 const agentStatus = ref< 'idle' | 'thinking' | 'calling_tool' | 'responding' | 'error' >( 'idle' ) // 当前正在执行的工具调用 const currentToolCalls = ref< ToolCall []>([]) // 用户偏好设置 const userPreferences = ref< Record < string , any >>({}) // 多会话列表 const conversations = ref< Conversation []>([]) // 计算属性：当前会话的 Token 用量估算 const estimatedTokens = computed ( () => { return messages. value . reduce ( ( sum, msg ) => sum + Math . ceil (msg. content . length / 4 ), 0 ) }) async function sendMessage ( content: string ) { messages. value . push ({ role : 'user' , content, id : crypto. randomUUID () }) agentStatus. value = 'thinking' try { const response = await fetch ( '/api/agent/chat' , { method : 'POST' , headers : { 'Content-Type' : 'application/json' }, body : JSON . stringify ({ messages : messages. value , preferences : userPreferences. value }) }) // 流式读取响应，逐字更新到 UI const reader = response. body !. getReader () const decoder = new TextDecoder () const aiMsg = { role : 'assistant' as const , content : '' , id : crypto. randomUUID () } messages. value . push (aiMsg) agentStatus. value = 'responding' while ( true ) { const { done, value } = await reader. read () if (done) break aiMsg. content += decoder. decode (value, { stream : true }) } agentStatus. value = 'idle' } catch (err) { agentStatus. value = 'error' console . error ( 'Agent 调用失败:' , err) } } return { messages, agentStatus, currentToolCalls, userPreferences, conversations, estimatedTokens, sendMessage } }) 你看，这不就是 Pinia 的常规操作吗？唯一的区别是，以前你调的是 CRUD 的 REST API，现在你调的是 AI Agent API。 状态管理的内核没变，只是数据来源变了。 该用 ref 用 ref ，该用 computed 用 computed ，该用 watch 用 watch ——都是你写了三年的东西。 而且，Pinia 的 $subscribe 和 $onAction 在 Agent 场景下特别好用。比如： // 监听 Agent 状态变化，自动记录日志（方便调试） const chatStore = useChatStore () // 每当 agentStatus 变化时，打印日志 chatStore.$subscribe( ( mutation, state ) => { if (mutation. storeId === 'chat' ) { console . log ( `[Agent] 状态变更: ${state.agentStatus} ` , { messageCount : state. messages . length , toolCalls : state. currentToolCalls }) } }) // 拦截 sendMessage action，记录每次请求的耗时 chatStore.$onAction( ( { name, after } ) => { if (name === 'sendMessage' ) { const start = Date . now () after ( () => { console . log ( `[Agent] sendMessage 耗时: ${ Date .now() - start} ms` ) }) } }) 这些 Pinia 的高级特性，在 Agent 应用的调试和监控中非常实用。你不需要额外引入什么监控工具，Pinia 自带的 API 就能搞定。这就是"用你熟悉的工具做新事情"的好处——你不用去学新开发框架，只需要把旧工具用在新场景。 3. 用户体验：前端最懂用户想要什么 AI 应用最怕什么？ 最怕用户不知道 AI 在干嘛。 你见过那种点了按钮之后啥反应都没有的 APP 吗？是不是很想摔手机？AI 对话也一样。如果用户发了一条消息，等了 5 秒钟啥都没看到，他的第一反应不是"AI 在处理"，而是"是不是我网断了？是不是系统挂了？" 前端工程师天天跟用户体验打交道，这些东西你闭着眼睛都知道怎么处理： Loading 状态 ：AI 思考的时候，显示一个"正在思考..."或者跳跃的三个点动画。简单的骨架屏、动态的思考步骤展示，都能明显降低用户的焦虑感。这些动画效果，你写 CSS 或者用 Vue 的 组件就能搞定。 错误处理 ：AI 接口超时了怎么办？返回了乱码怎么办？Token 用完了怎么办？调用频率被限制了怎么办？每一种错误，你都得给用户一个友好的提示，而不是一个红色的 500 Internal Server Error 。这跟普通表单提交的错误处理逻辑一模一样，只是错误类型多了几种。 思考过程可视化 ：这是 AI Agent 特有的需求。Agent 在"思考"的过程中，可能会调用工具、搜索知识库、做推理。把这些步骤展示出来——比如"正在搜索知识库..." → "找到 3 条相关文档" → "正在生成回答..."——用户会觉得"哇，这个 AI 好聪明，它真的在做事"，而不是"怎么还没好？" 引导式交互 ：用户第一次用 AI 应用的时候，往往不知道能问什么。一个好的引导面板（比如"试试问这些问题"），或者一些预设的快捷指令，能极大降低使用门槛。 断点续传 ：用户在对话过程中刷新了页面，回来之后对话还在吗？如果对话进行到一半，Agent 正在思考，刷新之后能恢复吗？这些细节，前端都需要考虑。 这些细节，纯后端工程师可能觉得"能用就行"，但前端知道—— 体验好，用户才愿意用；用户愿意用，作品才有价值。 而 AI 应用的用户体验，目前整个行业都还在摸索阶段。你现在进来，正好是"开荒"的时候，你的每一个体验增强，都可能成为行业标准。 举个例子，现在很多 AI 对话产品的"思考过程可视化"做得很粗糙——要么只显示一个"思考中..."，要么干脆什么都不显示。但如果你能做成像下面这样： 用户：帮我研判一下上个月的销售数据 Agent： [1/4] 正在理解你的需求... ✓ [2/4] 正在查询数据库... 找到 847 条记录 ✓ [3/4] 正在分析数据趋势... 发现 3 个异常点 ✓ [4/4] 正在生成分析报告... ▊ 用户看到这个，心里就有底了——"Agent 在做事，不是卡住了"。而且每步完成之后打勾，给人一种"进度在推进"的感觉。这种细节， 前端天生就比后端敏感 。因为前端天天跟用户打交道，知道什么样的反馈能降低用户焦虑。 再比如，Agent 的"思考步骤"其实可以做成可交互的。用户点击某个步骤，可以展开看详细信息——比如"查询数据库"这一步，展开后能看到执行的 SQL 语句、返回的记录数、耗时。这些信息对普通用户可能没用，但对开发者调试非常有用。而且，把"调试信息"自然地融入"用户界面"，这正是前端组件化设计的长处。 4. 组件化思维：Agent 前端就是一堆组件的组合 Vue3 的组件化思维，和 AI Agent 应用的前端架构简直是天作之合。你想想，一个 Agent 应用的前端，大概需要哪些组件？拆开来看： ChatPanel ← 对话面板，核心交互区 ├── MessageBubble ← 单条消息气泡（用户/AI/系统） │ ├── 用户消息：右对齐，蓝色背景 │ ├── AI 消息：左对齐，包含 Markdown 渲染 │ └── 系统消息：居中，灰色小字 ├── ThinkingSteps ← Agent 思考步骤展示 │ ├── 步骤列表：搜索中 → 分析中 → 生成中 │ └── 每步有状态图标：进行中/完成/失败 ├── ToolCallCard ← 工具调用结果卡片 │ └── 可折叠，展示工具名、参数、返回结果 └── MessageInput ← 输入框 ├── 文本输入（兼容 Shift+Enter 换行） ├── 文件上传按钮（图片、PDF 等） └── 发送按钮 SidePanel ← 侧边栏 ├── ConversationList ← 历史对话列表（可搜索、可删除） ├── AgentSettings ← Agent 配置面板 │ ├── 模型选择（GPT-4 / Claude / DeepSeek） │ ├── Temperature 滑块 │ └── System Prompt 编辑 └── KnowledgeBase ← 知识库管理入口 Dashboard ← 仪表盘 ├── UsageStats ← Token 用量统计（今日/本周/本月） └── ConversationLogs ← 对话日志（用于调试和审计） 这跟写一个后台管理系统有什么区别？ 都是组件拆分、数据流转、状态管理，套路一模一样。 每个组件接收 props，发出 emits，通过 Pinia 共享全局状态。你完全可以把你之前写后台管理系统的经验，平移到 AI Agent 应用的 UI 开发中。 而且，因为 AI 对话的 UI 模式相对固定（消息列表 + 输入框），你甚至可以写一套通用的 Agent UI 组件库，以后做任何 AI 项目都能复用。一套组件，所有 AI 项目通吃，这不比每次都从零写 CRUD 页面爽？ 说到组件库，其实 Vue3 生态里已经有一些可以直接用的 AI 对话组件了，比如 Vue Chat UI 、 Naive UI 的 Chat 组件 等。但我建议你前期还是自己手写一遍——因为只有自己写过，才知道流式渲染的细节、Markdown 渲染的坑、消息滚动定位的边界情况。等你自己写过一遍之后，再用现成的组件库，就能理解它们内部做了什么，出了问题也能自己排查。 还有一个细节点，前端可能没意识到： Markdown 渲染在 AI 对话里是刚需。 LLM 返回的内容经常包含代码块、表格、列表、加粗、链接。你写的消息气泡组件，需要支持 Markdown 渲染。而前端对 Markdown 渲染太熟了—— marked + highlight.js ，或者直接用 markdown-it ，三行代码搞定。你在技术博客、文档站里早就用过无数次了。 // AI 消息气泡组件 —— 支持 Markdown 渲染 // MessageBubble.vue import { marked } from 'marked' import { computed } from 'vue' const props = defineProps<{ message : ChatMessage }>() // 用 marked 把 Markdown 转成 HTML const htmlContent = computed ( () => { if (props. message . role === 'assistant' ) { return marked (props. message . content , { breaks : true }) } return props. message . content }) < template > < div :class = "['message-bubble', message.role]" > < div v-if = "message.role === 'assistant'" v-html = "htmlContent" /> < div v-else > {{ message.content }} 你看，Markdown 渲染、代码高亮、深色模式适配——这些前端做了无数遍的事情，在 AI 对话里全部需要。而且前端做这些，比后端快得多、好得多。因为 前端是离用户最近的人，最知道什么样的交互体验是好的 。 小结 AI Agent 应用的前端开发，本质上就是"流式数据渲染 + 状态管理 + 用户体验优化 + 组件化拆分"这四件事。而在这四件事上，前端工程师已经积累了多年的经验。所以，不要觉得自己是"写页面的"就搞不了 AI——恰恰相反，AI 应用最缺的就是能把用户体验做好的前端。你的技能树，在 AI 应用开发里是非常稀缺的。 AI Agent 不是魔法，就是一个"能自己做事的程序" 聊到 AI Agent，很多人脑子里会浮现出科幻电影里的画面：一个无所不能的 AI，能跟你聊天、帮你订机票、替你写代码、甚至还能跟你谈恋爱。坦白说，这种想象也不算错，但离我们现在的技术现实还有点距离。 现在能落地的 AI Agent，本质上就是一个 "能自己做事的程序" 。它和普通程序的区别在于：普通程序只会按你写的 if-else 执行，而 Agent 能自己"思考"下一步该做什么。 打个比方，你把一个普通程序想象成一个"听话的机器人"——你给它一个遥控器，按"前进"它就前进，按"左转"它就左转。你不按，它就不动。而 Agent 是一个"智能机器人"——你说"去厨房帮我拿瓶水"，它自己就知道：先识别"厨房"在哪，然后规划路线走过去，打开冰箱，拿水，再走回来。 用更具体的场景对比一下： 场景 普通程序 AI Agent 用户问"明天北京天气怎么样？" 你得先写死"天气"这个关键词，然后调用天气 API。如果用户换了个问法"明儿北京热不热？"，就识别不了了。你得写一个庞大的关键词匹配表，用户问法一变，程序就崩。 Agent 理解用户意图，自己决定"我需要查天气"，然后调用天气 API，最后用自然语言回复用户。不管用户怎么问，只要意图是"查天气"，Agent 都能处理。 用户说"帮我订一张明天去上海的机票，要早上的，便宜点。" 你得写一个表单，让用户填：出发地、目的地、日期、时间段偏好、价格区间。然后一步步提交。用户得先理解你的表单逻辑，而不是反过来。 Agent 理解"明天""去上海""早上""便宜"，自动提取参数，调机票 API，返回结果。如果信息不全（比如没说出城市），Agent 还会反问用户确认。 用户说"帮我把上周的销售数据写成报告，发邮件给老板。" 你得分别写三个子系统：数据查询接口、报告模板渲染、邮件发送接口。而且每一步都要用户手动触发，流程之间没有关联。 Agent 自己查数据库 → 分析数据 → 生成报告 → 调用邮件 API 发送。全过程自动化，用户只需要说一句话，Agent 自己规划步骤并执行。 看到区别了吗？ 普通程序是"死"的，你写什么它就做什么；Agent 是"活"的，它能理解用户意图，自己决定该做什么，然后调用工具去执行。 那 Agent 是怎么做到"自己思考"的呢？其实拆开来看，就四个核心组件，缺一不可： Agent 的四个核心组件 1. 大脑（LLM —— 大语言模型） ：负责理解用户意图，做决策。比如 ChatGPT、Claude、DeepSeek、通义千问这些。你把用户说的话发给它，它告诉你"用户想干嘛"以及"该调哪个工具"。 2. 工具（Tools） ：Agent 的手和脚。能查天气、发邮件、搜数据库、调 API——任何能通过代码做的事情，都可以包装成 Agent 的工具。工具是 Agent 能力的边界，工具越多，Agent 越强大。 3. 记忆（Memory） ：短期记忆是对话历史（刚才说了什么），长期记忆是存到数据库里的知识（用户偏好、历史总结）。有了记忆，Agent 才能记住你之前说过什么，不会每次都像第一次见面。 4. 规划（Planning） ：复杂任务要分步走。比如"帮我写一份竞品分析报告"，Agent 需要先搜索竞品信息，再整理数据，再生成报告，最后输出。它得自己规划"先做啥，后做啥"。 把这四个组件拼起来，就是一个能用的 Agent 了。听起来是不是没那么玄乎？ 而且，实现一个最简版的 Agent，代码量比你想象的要少得多。我们直接写一个： // 一个最简单的 AI Agent，不到 50 行代码 // 特性：用户问天气，Agent 自动调用天气 API 回答 // 运行前需要：npm install openai import OpenAI from 'openai' const client = new OpenAI ({ apiKey : process. env . OPENAI_API_KEY }) // 第一步：定义 Agent 可以用的工具 // 每个工具包含：名称、描述、参数定义（JSON Schema 格式） const tools = [ { type : 'function' as const , function : { name : 'get_weather' , description : '获取指定城市的天气信息' , parameters : { type : 'object' , properties : { city : { type : 'string' , description : '城市名称，如"北京"' } }, required : [ 'city' ] } } } ] // 第二步：实现工具的实际逻辑 // 实际项目中这里会调用真实的天气 API async function getWeather ( city: string ): Promise < string > { // 模拟返回天气数据 // 生产环境替换为：fetch(`https://api.weather.com?city=${city}`) return ` ${city} 今天晴，25°C，湿度 60%，适合出门` } // 第三步：Agent 主循环 —— 这是 Agent 的核心逻辑 async function agentRun ( userMessage: string ) { const messages : any [] = [{ role : 'user' , content : userMessage }] // 把用户消息发给 LLM，让它决定要不要调工具 const response1 = await client. chat . completions . create ({ model : 'gpt-4' , messages, tools // 告诉 LLM 有哪些工具可用 }) const toolCall = response1. choices [ 0 ]. message . tool_calls ?.[ 0 ] // 如果 LLM 决定要调工具 if (toolCall && toolCall. function . name === 'get_weather' ) { // 解析 LLM 提取的参数（比如 city: "北京"） const args = JSON . parse (toolCall. function . arguments ) const weatherResult = await getWeather (args. city ) // 把工具执行结果发回给 LLM，让它生成最终回复 messages. push (response1. choices [ 0 ]. message ) // LLM 的"我要调工具"决策 messages. push ({ role : 'tool' , tool_call_id : toolCall. id , content : weatherResult // 工具返回的结果 }) const response2 = await client. chat . completions . create ({ model : 'gpt-4' , messages }) return response2. choices [ 0 ]. message . content } // LLM 觉得不需要调工具，直接返回它的回复 return response1. choices [ 0 ]. message . content } // 试试效果 const answer = await agentRun ( '北京今天天气怎么样？' ) console . log (answer) // 输出："北京今天天气不错！晴，25°C，湿度 60%，很适合出门哦~" 你看，就这么几十行代码，一个能自动调用工具的 Agent 就搭好了。没有魔法，没有黑盒，就是 "LLM 做决策 → Agent 执行动作 → LLM 生成回复" 三步循环。这个循环，就是 Agent 最核心的工作原理。后面所有章节讲的"工具调用""工作流编排""多 Agent 协作"，本质上都是这个循环的扩展和变体。 当然，这个例子太简陋了，实际项目里你得处理很多细节： 错误重试 ：LLM 调用失败了怎么办？重试几次？间隔多久？指数退避（Exponential Backoff）是标准做法。 超时处理 ：LLM 响应太慢了怎么办？设置多长的超时时间？GPT-4 有时候要等 30 秒以上。 多轮对话 ：用户和 Agent 聊了好几轮，怎么管理对话历史？对话越来越长，Token 成本和上下文窗口都是问题。 工具调用串并行 ：Agent 可能同时需要调多个工具，有些可以并行（比如同时查北京和上海的天气），有些必须串行（比如先查用户 ID，再查订单详情）。 流式输出 ：让用户看到字一个字蹦出来，而不是干等。这需要 SSE 或者 WebSocket。 Token 用量控制 ：对话长了之后，Token 消耗会很大。GPT-4 的输入是 $0.03/1K tokens，一场长对话可能花掉几块钱。需要做摘要压缩和上下文裁剪。 但这些细节，后面每一章都会掰开揉碎了讲。你现在只需要记住一件事： Agent 的本质很简单，就是让 LLM 拥有"动手"的能力。 它不是魔法，就是一段程序——一段你完全能写出来的程序。 对了，看到上面那个 Agent 代码里 get_weather 这个工具的定义了吗？注意它的参数格式： { type : 'function' , function : { name : 'get_weather' , description : '获取指定城市的天气信息' , parameters : { type : 'object' , properties : { city : { type : 'string' , description : '城市名称，如"北京"' } }, required : [ 'city' ] } } } 这个格式叫 JSON Schema ，是 OpenAI 定义的 Function Calling 规范。你不需要手写这个 JSON，但你需要理解它的含义——它告诉 LLM："嘿，你有一个叫 get_weather 的工具可以用，它需要一个 city 参数，是字符串类型。"LLM 看到这个描述，就知道当用户问天气的时候，它应该调用这个工具，并且把城市名作为参数传进去。 这个机制，就是 AI Agent 能够"做事"的底层原理。它不是什么神奇的黑箱，就是一个 定义清晰、格式规范的接口约定 。你作为开发者，要做的就是定义好工具、实现好工具，然后把工具列表发给 LLM，LLM 自己会决定什么时候该用哪个工具。 技术栈选择：Vue3 + NestJS + TypeScript 为什么是绝佳组合？ 市面上的 AI Agent 教程，十本有九本用 Python。这本身没问题，Python 生态确实在 AI 领域最成熟——LangChain、LlamaIndex、AutoGen 这些框架最早都是 Python 版的。但问题是—— 你是前端，你最熟的是 JavaScript/TypeScript，不是 Python。 让你一边学 Agent，一边学 Python，还要一边学 Python 的 Web 框架（FastAPI、Flask），还要学 Python 的异步编程（asyncio），还要学 Python 的类型系统（Pydantic），还要学 Python 的部署方式（Gunicorn、Uvicorn）……这学习曲线陡得跟悬崖一样。而且学完之后，Python 代码跟你现有的前端项目是割裂的——你没法在一个项目里同时用 TypeScript 写前端和 Python 写后端，或者说能做，但维护成本太高，类型定义要写两套。 所以在这本小册里，我们选择了一条 对前端最友好的技术路线 ： 前端：Vue3（Composition API + TypeScript + Pinia） └── 你已经在用了，不用多学，直接用你熟悉的工具 后端：NestJS（Node.js 公司级框架） └── 用 TypeScript，跟前端同一门语言，装饰器风格像 Vue3 的 这个组合有几个硬核优势，一条条说： 优势一：全栈 TypeScript，类型安全贯穿始终 你有没有遇到过这样的场景：后端改了接口返回格式，前端没跟着改，结果上线之后前端报了一堆 undefined is not a function ，排查半天发现是字段名变了？这就是前后端类型不统一的代价。 用 TypeScript 全栈，你可以把类型定义抽成一个共享包： // shared/types.ts —— 前后端共享的类型定义 // 放一个单独的包里，前后端都 import 这个包 /** 聊天消息 */ export interface ChatMessage { id : string role : 'user' | 'assistant' | 'system' | 'tool' content : string toolCalls?: ToolCall [] createdAt : string } /** 工具调用记录 */ export interface ToolCall { id : string name : string arguments : Record < string , any > result?: string status : 'pending' | 'running' | 'done' | 'error' } /** Agent 配置 */ export interface AgentConfig { model : string // 使用的模型 temperature : number // 0-2，控制随机性 maxTokens : number // 最大输出 Token 数 systemPrompt : string // 系统提示词 tools : ToolDefinition [] // 可用工具列表 } /** 工具定义 */ export interface ToolDefinition { name : string description : string parameters : Record < string , any > } /** Agent 响应（流式） */ export interface AgentStreamChunk { type : 'text' | 'tool_call' | 'tool_result' | 'error' | 'done' content?: string toolCall?: ToolCall error?: string } 前端用 ChatMessage 渲染消息列表，后端用 ChatMessage 构建 LLM 请求。如果后端改了 ChatMessage 的字段，前端编译就会报错，根本不会等到上线才发现。 类型安全从开发阶段就保证了前后端的一致性。 优势二：NestJS 的模块化，天生适合 Agent 架构 NestJS 是一个用 TypeScript 写的 Node.js 框架，设计上借鉴了 Angular 的依赖注入和模块化思想。它的核心概念是 Module、Controller、Provider ，正好对应 Agent 的各个组件： NestJS 概念 Agent 组件 职责说明 AgentModule Agent 主控 协调 LLM、工具、记忆，处理用户请求的主入口 LlmModule 大脑（LLM） 封装 OpenAI / Claude / DeepSeek 等模型调用，统一接口 ToolModule 工具（Tools） 注册和管理 Agent 可以调用的工具，支持动态注册 MemoryModule 记忆（Memory） 对话历史存储、向量数据库集成、长期记忆管理 ChatModule 对话接口 提供 SSE 流式接口、WebSocket、REST API 每个模块各司其职，互不干扰。要加新功能？新建一个 Module 就行。而且 NestJS 的依赖注入让你能轻松替换实现——比如从 OpenAI 换成 DeepSeek，只需要改 LlmModule 里的 Provider，其他地方完全不用动。这个设计哲学，跟 Vue3 的"组合式 API，职责分离"是一样的。 来看一个实际的 NestJS Agent 模块长什么样： // ─── agent.module.ts ─── // Agent 模块的入口，声明依赖关系 import { Module } from '@nestjs/common' import { AgentController } from './agent.controller' import { AgentService } from './agent.service' import { LlmModule } from '../llm/llm.module' import { ToolModule } from '../tool/tool.module' import { MemoryModule } from '../memory/memory.module' @Module ({ imports : [ LlmModule , ToolModule , MemoryModule ], controllers : [ AgentController ], providers : [ AgentService ], exports : [ AgentService ] }) export class AgentModule {} // ─── agent.controller.ts ─── // 对外暴露的 API 接口 import { Controller , Post , Body , Sse } from '@nestjs/common' import { AgentService } from './agent.service' import { Observable } from 'rxjs' @Controller ( 'api/agent' ) export class AgentController { constructor ( private readonly agent: AgentService ) {} // SSE 流式接口 —— 前端用 EventSource 或 fetch 消费 @Sse ( 'chat' ) chat ( @Body () body : { message : string ; sessionId : string }): Observable < any > { return this . agent . chatStream (body. message , body. sessionId ) } // 普通 REST 接口（非流式） @Post ( 'chat/sync' ) async chatSync ( @Body () body: { message: string ; sessionId: string } ) { return { reply : await this . agent . chat (body. message , body. sessionId ) } } } // ─── agent.service.ts ─── // Agent 核心逻辑 import { Injectable } from '@nestjs/common' import { LlmService } from '../llm/llm.service' import { ToolService } from '../tool/tool.service' import { MemoryService } from '../memory/memory.service' import { Observable } from 'rxjs' @Injectable () export class AgentService { constructor ( private readonly llm: LlmService, private readonly tool: ToolService, private readonly memory: MemoryService ) {} // 非流式对话 async chat ( userMessage : string , sessionId : string ): Promise < string > { // 1. 加载历史记忆 const history = await this . memory . getHistory (sessionId) // 2. 让 LLM 决策：要不要调工具？ const decision = await this . llm . decide (userMessage, history, this . tool . getDefinitions ()) // 3. 如果需要调工具，执行工具调用 if (decision. needsTool ) { const toolResult = await this . tool . execute (decision. toolCall ) // 保存工具调用记录到记忆 await this . memory . saveToolCall (sessionId, decision. toolCall , toolResult) // 把工具结果发给 LLM 生成最终回复 return this . llm . generateFinalResponse (userMessage, toolResult, history) } // 4. 不需要工具，直接返回 LLM 的回复 await this . memory . saveMessage (sessionId, { role : 'user' , content : userMessage }) await this . memory . saveMessage (sessionId, { role : 'assistant' , content : decision. content }) return decision. content } // 流式对话（SSE） chatStream ( userMessage : string , sessionId : string ): Observable < any > { // 返回 Observable，NestJS 自动处理 SSE 格式 return new Observable ( ( subscriber ) => { this . llm . streamDecide (userMessage, this . tool . getDefinitions ()) . subscribe ({ next : ( chunk ) => subscriber. next ({ data : chunk }), error : ( err ) => subscriber. error (err), complete : () => subscriber. complete () }) }) } } 结构清晰，职责分明，Vue3 的前端同学一看就懂—— 这不就是后端的"组件化"吗？ Module 就是组件，Provider 就是 Composable，Controller 就是路由。每个组件管好自己的事，通过依赖注入（类似 Vue 的 inject ）互相协作。 优势三：学习成本低，一条技术栈走天下 我们算一笔账，看看两种路线的学习成本： 需要学的内容 Python 路线 TypeScript 路线（本小册） 编程语言 Python 语法、装饰器、上下文管理器、生成器 已经会了 Web 框架 FastAPI 或 Flask，路由、中间件、依赖注入 NestJS（新学一个框架，但概念跟 Vue3 相通） 异步编程 asyncio、async/await（Python 的异步模型跟 JS 不同） 已经会了（JS 的 async/await） 类型系统 Pydantic、Type Hints 已经会了（TypeScript） 包管理 pip、poetry、虚拟环境 已经会了（npm/pnpm） 部署 Gunicorn + Uvicorn + Nginx PM2 / Docker + Nginx（跟 Node.js 部署一样） AI 框架 LangChain（Python） LangChain.js（API 几乎一样，只是语言不同） 用 TypeScript 路线，你只需要学 NestJS 这一个新东西。Vue3 你已经会了，TypeScript 你已经会了，Node.js 生态你已经很熟了（npm、ESLint、Prettier、Vite、Vitest）。换句话说， 你付出的学习成本，80% 都用在了 Agent 开发本身，而不是花在学一门新语言 + 新框架 + 新生态上。 换个角度想：如果你现在用 Python 学 Agent，你每天的时间分配大概是： Python 路线的时间分配： 30% 学 Python 语法和生态（pip、venv、asyncio、Pydantic） 25% 学 FastAPI 框架（路由、中间件、依赖注入） 25% 学 Agent 本身（工具调用、记忆、RAG、工作流） 20% 踩坑（Python 和 TypeScript 的思维差异导致的 Bug） TypeScript 路线的时间分配： 15% 学 NestJS（一个框架，但概念跟 Vue3 相通） 65% 学 Agent 本身（工具调用、记忆、RAG、工作流） 20% 踩坑（Agent 开发本身的坑，跟语言无关） 一目了然——用 TypeScript 路线，你有 65% 的时间都在学 Agent 本身，而不是在学语言和框架。对于时间宝贵的前端来说，这太重要了。你白天还要上班，晚上和周末才能学，每一分钟都不能浪费。 而且还有一个隐藏优势： 你学 NestJS 的过程，本身就是一次"后端思维"的训练 。以前你可能只写前端，对后端的依赖注入、中间件、数据库 ORM 这些概念不太熟悉。但学完 NestJS 之后，你不仅会写 Agent，还会写后端了——这相当于买一送一，学一个技能，拿两个技能。 一个真实的学习对比 假设你要学"用 Agent 调用工具"这个功能。 用 Python 路线，你需要：先学 Python 的 async/await（跟 JS 的模型不同，容易踩坑），再学 FastAPI 怎么定义路由和依赖注入，再学 Pydantic 怎么定义参数校验模型，再学 asyncio 怎么处理并发调用。光这些前置知识，可能就要花一两周。 用 NestJS 路线，你只需要：在 NestJS 的 Controller 里写一个 @Post() 装饰器，在 Service 里写 async/await（跟 Vue3 里的 API 调用一模一样），在 Module 里声明依赖关系。你第一天就能写出能跑的 Agent API。 这不是 NestJS 有多好，而是 你对 TypeScript 生态已经足够熟悉了，只需要把已有的知识迁移到新场景 。 额外福利：AI SDK 生态对 TypeScript 越来越友好 2024 年到 2026 年，TypeScript/JavaScript 的 AI 生态推进得非常快。以前很多 AI 工具只有 Python 版，现在几乎都有 TypeScript 版了： Vercel AI SDK ：Vercel 上线运营的 AI 开发工具包，支持 OpenAI、Anthropic、Google 等多个模型提供商，原生支持流式输出和 Vue3/React 组件。而且它的 useChat hook 直接封装了流式聊天逻辑，你只需要一行代码就能接入 AI 对话。 LangChain.js ：LangChain 的 TypeScript 版本，API 跟 Python 版几乎一样，文档也越来越完善。第 8 章会专门讲它。 OpenAI Node.js SDK ：官方维护的 TypeScript SDK，类型定义完整，用起来跟 Python 版一样流畅。 Anthropic TypeScript SDK ：Claude 的官方 TypeScript SDK，支持流式输出和工具调用。 说白了，TypeScript 的 AI 生态已经足够成熟了，你完全不需要为了做 AI 开发去学 Python。 用你最熟悉的语言，做最前沿的事情 ——这是这本小册的核心设计理念。 当然了，如果你以后有兴趣，学 Python 也不是坏事。Python 在数据处理、模型训练、科学计算方面确实比 TypeScript 强。但那是"进阶"之后的事，不是"入门"的时候该考虑的。先把 TypeScript 这条路线走通，等你对 Agent 开发有了完整的理解，再学 Python 就是锦上添花，而不是雪中送炭。 这本小册会带你做什么？—— 路线图总览 这本小册一共 15 章，分成四个阶段。每一章都围绕一个核心概念展开，有代码、有比喻、有踩坑记录、有"我当初在这里卡了多久"的真实经历。我不会堆砌一堆理论，而是带你 从头到尾，手把手搭出一个能跑的 AI Agent 应用 。 以下是完整的路线图： 第一阶段：打好地基（第 1-3 章） 这一阶段我们先不写复杂代码，而是把概念理清楚。很多人一上来就撸代码，结果连 LLM 是什么、Token 是什么都没搞明白，写到一半卡住了，进退两难。磨刀不误砍柴工，这三章就是"磨刀"。 章节 内容 你会搞懂 第 1 章（当前） 为什么你要学 AI Agent？ 前端在 AI 时代的优势、技术栈选择、学习路线全景图 第 2 章 AI Agent 到底是个啥？ 用送外卖、炒菜、订机票这些生活场景，把 Agent 的四个核心概念（大脑、工具、记忆、规划）讲清楚，保证看完就能跟朋友解释 第 3 章 大语言模型：Agent 的"大脑" Token、温度（Temperature）、上下文窗口、System Prompt 这些概念，用 TypeScript 代码跑一遍，彻底搞懂 LLM 的"脾气" 第二阶段：核心技能（第 4-7 章） 这一阶段是 Agent 开发的"内功"。学完这四章，你就掌握了 Agent 开发的全部核心套路，能自己搭一个功能完整的 Agent 了。 章节 内容 你会写出 第 4 章 提示词工程：怎么跟 AI 好好说话 一个可复用的 Prompt 模板系统，支持角色设定、防注入、动态参数、Few-shot 示例 第 5 章 工具调用：Agent 的"手" 一个工具注册中心，Agent 能自动发现并调用工具，支持查天气、搜网页、发邮件、操作数据库 第 6 章 记忆系统：Agent 的"脑子" 对话历史管理 + 向量数据库集成（Chroma/Pinecone），Agent 能记住你说过的话，跨会话保持记忆 第 7 章 RAG：给 Agent 接上你的知识库 一个文档问答系统，把 PDF/文档/网页喂给 Agent，让它能回答只有你公司内部才知道的专业问题 第二阶段学完后的"里程碑" 到第 7 章结束，你就能写出一个"能查资料、能调工具、有记忆的智能客服"了。虽然界面可能还比较简陋，但核心逻辑已经完备。这个 Demo 作为你的项目经验，写在简历上绝对加分。 第三阶段：实战进阶（第 8-11 章） 这一阶段开始上强度，用 LangChain.js 和 LangGraph 搭真正的生产级 Agent。学完这四章，你的 Agent 就不再是"玩具"，而是能处理复杂业务逻辑的"工具"。 章节 内容 你会搭出 第 8 章 LangChain.js 入门 用 LangChain.js 的 Chain 和 Agent 抽象，快速搭建 Agent 原型，理解为什么需要框架 第 9 章 NestJS 搭建 Agent 后端 一个完整的 NestJS Agent API 服务，支持流式 SSE 响应、JWT 鉴权、请求限流、日志记录 第 10 章 LangGraph 工作流编排 用"图"的方式编排复杂 Agent 任务，支持条件分支、循环、暂停/恢复、人机协作 第 11 章 多智能体协作 多个 Agent 分工携手：一个负责搜索、一个负责分析、一个负责写报告，像团队一样高效 第四阶段：全栈闭环（第 12-15 章） 最后一步，把 Agent 包装成一个完整的全栈应用，从开发到部署，打通全链路。 章节 内容 你会搞定 第 12 章 MCP 协议：AI 世界的 USB-C 统一工具调用标准，手写一个 MCP Server，让 Agent 接入任意 MCP 兼容的工具生态 第 13 章 Vue3 全栈实战：前后端联动 一个完整的 AI 对话界面，SSE 流式响应，实时展示 Agent 思考过程、工具调用、Markdown 渲染 第 14 章 部署上线：把 Agent 跑在生产环境 Docker 容器化、Redis 缓存、Nginx 反向代理、API 成本控制、日志监控、灰度推出 第 15 章 下一步怎么走？ 2026 年 AI Agent 趋势、进阶学习路线、推荐资源、社区驱动项目、社区 整个路线图，从概念到代码，从单机到生产， 每一步都有对应的 TypeScript 代码 。你不需要去学 Python，不需要去啃论文，不需要去读晦涩的学术文章。跟着敲一遍代码，就能从零到一掌握 AI Agent 开发。 怎么读这本小册最高效？ 给你几个实在的建议，帮你少走弯路： 不要跳章 ：前 7 章是基础中的基础，概念是一环扣一环的。跳了第 4 章（提示词），你写第 5 章（工具调用）的时候就会困惑"为什么 LLM 不好好调我的工具？"跳了第 6 章（记忆），你写第 7 章（RAG）的时候就会困惑"为什么 Agent 记不住前面说过的话？" 一定要动手敲代码 ：看代码和写代码是两码事。这本书里的每个代码示例，你都应该亲手敲一遍。哪怕只是复制粘贴然后改几个参数，也比光看有效得多。肌肉记忆比视觉记忆可靠。 遇到报错别慌 ：AI 开发特别容易遇到各种奇怪的报错——LLM 返回格式不对、API 超时、Token 超限、工具调用失败。这些都是正常的，不是你的问题。每次解决一个报错，你对 Agent 的理解就深一层。 先跑通，再优化 ：不要一开始就追求完美。先写出一个能跑的 Demo，哪怕代码很丑、功能很简陋。跑通之后，再回来优化代码结构、加错误处理、增强性能。很多人在"追求完美"的过程中卡住了，最后什么都没写出来。 做好笔记 ：每学完一章，用自己的话总结一下核心概念。如果你能跟一个不懂技术的朋友讲清楚"什么是 Agent"，那才是真的懂了。 另外，这本小册里会有很多"踩坑记录"——这些都是我在实际开发中真的踩过的坑。比如"为什么 LLM 不调我的工具？""为什么 RAG 搜出来的结果不相关？""为什么 Token 消耗这么快？"看到这些踩坑记录的时候，不要跳过——每一个坑，都能帮你省掉至少半天的时间。而且，踩坑记录里通常包含了"为什么会这样"和"怎么解决"两部分，理解了"为什么"，你以后遇到类似问题就能自己排查。 还有一个小建议： 找一个学习搭子。 如果你身边有同事或朋友也在学 AI Agent，拉上他一起。两个人互相督促、互相答疑，学习效率能翻倍。如果实在没有搭子，也可以在 GitHub 仓库的 Issues 区提问，或者在相关的技术社区里找同路人。一个人走得快，一群人走得远，这句话在学新技术的时候尤其适用。 学完这本小册，你能做什么？ 学完 15 章之后，你不再是一个"只会写页面的前端"，而是一个 能独立开发 AI 应用的全栈工程师 。具体来说，你能搞定下面这些真实场景： 场景一：智能客服系统 这是最经典的 AI Agent 应用，也是最多公司正在做的。把你的产品文档、FAQ、历史工单、客服话术全部喂给 Agent，它就能自动回答用户问题。遇到解决不了的问题，自动转人工客服，并且把对话摘要一起发给人工客服，无缝衔接。 而且因为它有记忆，能记住用户之前问过什么，不会问一次回答一次，像个失忆的金鱼。比如用户说"我上次问的那个订单，物流到哪了？"，Agent 能回溯到之前的对话，找到订单号，然后查物流。 技术要点：RAG 知识库 + 工具调用（查订单状态、查物流）+ 多轮对话记忆 + 人机协作。 场景二：数据分析助手 "帮我分析一下上个月的销售数据，找出销量下降最严重的三个品类，然后给一些改进建议。"——用户说一句话，Agent 自动查询数据库、生成图表、写分析报告，一条龙服务。 这个场景特别适合内部工具。以前数据分析师要花半天写 SQL、做图表、写报告，现在说一句话就搞定了。而且 Agent 还能追问——"你觉得下降的原因可能是什么？要不要我进一步分析一下竞品数据？" 技术要点：工具调用（SQL 查询、图表生成）+ 多步骤工作流编排 + LangGraph。 场景三：代码审查助手 把 Git 仓库接给 Agent，每次提交 PR 的时候，Agent 自动 review 代码，指出潜在问题、给出优化建议、检查代码风格，甚至能帮你自动生成单元测试。前端同学最懂前端代码的痛点——你写的 Agent 肯定比通用工具更懂前端的实际需求。 比如，Agent 能识别出"这个 watch 没有加 immediate: true ，可能导致首次渲染时状态不一致"，或者"这个 Pinia Store 的 action 里直接操作了 DOM，应该抽到组件里"。这些都是前端特有的坑，通用 AI 工具不一定能识别。 技术要点：工具调用（Git API、代码静态分析）+ 自定义 Prompt 模板 + 知识库（团队编码规范）。 场景四：个人知识管家 把你平时收藏的文章、写的笔记、读书摘录、会议记录全部喂给 Agent，它就是你专属的"第二大脑"。你问"我上次看到那个关于 Vue3 响应式原理的文章在哪？大概讲的是 Proxy 和 Reflect 的？"——Agent 秒回，比你自己翻收藏夹、搜笔记快多了。 更进一步，你可以让 Agent 帮你总结——"帮我总结一下我最近三个月看的所有关于 AI 的文章，提炼出 5 个关键趋势。"——Agent 自动检索你的知识库，做归纳总结。 技术要点：RAG + 向量数据库 + 长期记忆管理 + 文档解析。 场景五：自动化工作流 "每天早上 9 点，帮我汇总昨天的用户反馈，按紧急程度排序，然后发到团队群里。"——Agent 定时执行，自动调多个工具，读取反馈数据库，用 LLM 分析紧急程度，格式化成消息，发到飞书/钉钉/企业微信。 这个场景的关键是"可靠"——Agent 不能出错，万一某天没发，你得能收到告警。所以需要加上错误处理、重试机制、状态监控。 技术要点：定时任务（Cron）+ 工作流编排 + 多工具串联 + 错误处理 + 监控告警。 除了这五个场景，其实还有很多可能性。比如做一个"AI 面试官"帮 HR 筛简历，做一个"AI 家教"帮学生答疑，做一个"AI 运维"自动处理服务器告警。一旦你掌握了 Agent 开发的核心套路， 任何一个需要"理解自然语言 + 执行操作"的场景，你都能用 Agent 来解决 。这就是 Agent 开发的魅力——它不是某个具体的技术，而是一种全新的"解决问题的方式"。 更重要的是，这些场景不是"未来才会发生"的事情。现在，2026 年，已经有大量的公司在落地这些应用了。电商在用智能客服，金融在用数据分析助手，教育在用 AI 家教，医疗在用 AI 问诊。你学完这本小册，就能直接参与到这些项目中去。而如果你不学，五年后你可能还在写 CRUD 页面，而你的同龄人已经在带 AI 产品团队了。 而且这些场景不是"学完 15 章才能做" 从第 5 章开始，每学完一章，你就能写出一个能跑的小 Demo。比如学完第 5 章（工具调用），你就能写一个"帮你查天气的 Agent"。学完第 7 章（RAG），你就能写一个"问你的文档"的 Agent。学完第 9 章（NestJS），你就能把这个 Agent 包装成 API 服务。不是 15 章学完才能动手，而是 边学边做，每章都有产出，每个产出都能直接写到简历上 。 在开始之前，你需要准备什么？ 就三样东西，你应该已经有了： Vue3 基础 ：会用 Composition API，理解 ref 、 reactive 、 computed 、 watch ，用过 Pinia。不需要很精通，能写业务代码就行。如果只是用过 Options API 没写过 Composition API，花半天时间看一下官方文档就够了，不难。 TypeScript 基础 ：会定义 interface 、 type ，会用泛型，能看懂类型标注。不用太深入，不需要懂什么"协变逆变""条件类型"这些高级特性。这本小册里的 TypeScript 代码，都是最基础的用法。 Node.js 基础 ：会用 npm/pnpm 装包，知道 async/await 怎么用，用过 fetch 或 axios 调接口。不需要会 Express 或 Koa——NestJS 会从零教起。 如果你对 NestJS 完全零基础，也别担心。第 9 章会专门讲 NestJS 的基础，从路由、中间件、Guard、Interceptor 到依赖注入，保证你能跟上。而且因为你已经会 Vue3，NestJS 的很多概念和 Vue3 是通的： NestJS 的 Module 就像 Vue 的 组件 ——封装一块功能，有自己的 imports、exports NestJS 的 Provider/Service 就像 Vue 的 Composable ——封装可复用的逻辑 NestJS 的 依赖注入 就像 Vue 的 provide/inject ——上层注入，下层使用 NestJS 的 Decorator （ @Get() 、 @Post() ）就是声明式的路由定义，跟 Vue Router 的配置异曲同工 另外，你需要一个能调用 LLM API 的账号。推荐用 OpenAI （GPT-4o 或 GPT-4o-mini）或者 DeepSeek （便宜很多，效果也非常不错，尤其是中文场景）。实在不想花钱，也可以用本地的 Ollama 跑开源模型（比如 Llama 3、Qwen 2.5），第 3 章会教你怎么配。API 调用费用不用担心——开发阶段用最便宜的模型就够了，一个月几块钱的事。 最后，还有一件事： 这本小册的代码仓库 。每一章的完整代码都可以在 GitHub 上找到，你不需要从头新建项目，直接 clone 下来就能跑。如果你在某个章节卡住了，或者某个代码示例跑不通，去仓库里找对应章节的代码，对比一下就能发现问题。仓库地址在本书的首页。 另外，本小册里的所有代码示例，我都尽量保持"独立可运行"。也就是说，你把一个代码块复制出来，稍微改一下 API Key 和配置，就能直接跑。不需要先理解前面 5 章的内容才能看懂第 6 章的代码——每章的代码示例都是自包含的。当然，概念上还是建议按顺序读，因为后面的概念建立在前面的基础上。 开发环境建议 虽然上面说了"只需要三样东西"，但我还是想分享一下我自己觉得好用的开发环境配置，供你参考： 编辑器 ：VS Code 或 Cursor（后者有 AI 补全，写 Agent 代码的时候特别方便，因为 AI Agent 开发里有很多模板化的代码，AI 补全可以帮你省掉大量重复劳动）。 Node.js 版本 ：推荐 Node.js 20 LTS 或更高版本。NestJS 和 LangChain.js 都对 Node.js 18+ 有要求，20 LTS 是最稳妥的选择。 包管理器 ：推荐 pnpm。这本小册的代码示例都用 pnpm，因为它快、省磁盘空间，而且对 monorepo 支持好（如果你想把前后端放在一个仓库里的话）。 API 调试工具 ：Postman 或 Bruno 或 VS Code 的 REST Client 插件。Agent 开发中你会频繁调试 API 接口，有个好用的 API 调试工具能事半功倍。特别推荐 Bruno，它是本地优先的开源工具，数据存在本地文件夹里，可以用 Git 管理。 数据库 ：开发阶段用 SQLite 就够了（不需要额外安装），生产环境切到 PostgreSQL。NestJS 的 TypeORM 和 Prisma 都支持这两种数据库，切换只需要改一行配置。 向量数据库 ：如果你只是想快速体验 RAG（第 7 章），推荐用 Chroma 或者 Pinecone 的免费版。Chroma 可以本地跑，不需要注册账号。Pinecone 有免费额度，足够开发阶段用。 这些工具都不需要你提前安装，用到的时候我会在对应章节提醒你。提前写在这里，是让你心里有个底： Agent 开发的工具链，跟你平时写 Vue3 项目的工具链高度重合 ，没有什么是你完全陌生的。 关于 AI 焦虑，说两句真心话 我知道很多前端同学最近很焦虑——"AI 会不会取代前端？""我是不是该转行？""前端是不是没前途了？" 我的看法是： AI 不会取代前端，但会用 AI 的前端会取代不会用 AI 的前端。 这不是贩卖焦虑，这是事实。就像十年前，会移动端开发的人取代了只会 PC 端开发的人；五年前，会用 Vue/React 的人取代了只会 jQuery 的人。每一次技术浪潮，淘汰的都不是某个职业，而是某种落后的技能组合。 你现在学 Agent，不是"转行"，而是 升级你的技能树 。你依然是前端，只是你的武器库里多了一把叫"AI Agent"的利器。这把利器能让你从"实现需求"进化到"创造产品"，从"切图仔"进化到"能独立交付 AI 应用的全栈工程师"。在招聘领域上，一个"会写 AI Agent 的前端"，和一个"只会写 CRUD 页面的前端"，竞争力是天壤之别。 而且，AI Agent 开发这个赛道，现在还处于早期。你越早进来，越容易建立优势。等一两年后大家都开始学了，你再学，就晚了。现在很多公司正在从"要不要用 AI"转向"怎么用好 AI"，这个过程中需要大量的 AI 应用开发者——而这些人，目前非常稀缺。 所以，放轻松，但别偷懒。这本小册的每一章都会陪你走，每一步都有代码可以抄、可以跑。你只需要跟着做，15 章之后，你就是那个"会用 AI 的前端"。 现在，让我们开始吧 好了，写了这么多，总结一下这一章的核心观点。记住这五句话就行： 其实这五句话，每一句都可以展开成一章。但你现在不需要记住所有细节——你只需要记住一个感觉： "AI Agent 开发，我好像也能搞。" 带着这个感觉进入下一章，学习效率会高很多。因为最难的从来不是技术本身，而是"我能不能学会"这个心理障碍。一旦你跨过了这个障碍，剩下的就是按部就班地学。 AI Agent 开发是应用层开发，不是模型层开发。 你不需要会训练模型，只需要会用模型。就像你不需要会种地，只需要会用食材做菜。 前端在 AI Agent 开发中有天然优势。 流式渲染、状态管理、用户体验、组件化思维——这些都是你每天都在做的事情，搬到 AI 应用里完全复用。 AI Agent 不是魔法，就是一个"能自己做事的程序"。 核心就四个组件：大脑（LLM）、工具（Tools）、记忆（Memory）、规划（Planning）。把它们拼起来，就是一个能用的 Agent。 Vue3 + NestJS + TypeScript 是前端学 Agent 的最优路线。 全栈 TypeScript，前后端类型安全，学习成本最低，80% 的精力都能花在 Agent 开发本身。 15 章，四个阶段，边学边做，每章都有产出。 从第 5 章开始就能写出能跑的 Demo，学完就能写在简历上。 这五个观点，其实也是这本小册的"核心设计理念"。我写这本小册的目的，不是为了让你成为 AI 研究员，而是让你成为一个 能用 AI 解决实际问题的全栈工程师 。所以这本书里不会有复杂的数学公式，不会有晦涩的学术论文引用，只有"能跑通的代码"和"看得懂的比喻"。如果你觉得哪里看不懂，那一定是我没讲清楚，不是你的问题。 如果你看完这一章，心里的想法从"我搞不了 AI"变成了"好像也没那么难"，那这一章的目的就达到了。AI Agent 开发的门槛，比你想象的低得多。你缺的不是能力，而是正确的入门路径和一套好的教程——而这两样东西，这本小册都给你准备好了。 最后，我想用一句话收尾： "不要等到 AI 成熟了再学，那时候别人已经跑了很远了。 现在就是最好的时机，因为你已经具备了一切必要的基础。 剩下的，只是往前走一步。" 下一章，我们来聊聊"AI Agent 到底是个啥？"——用送外卖、炒菜、订机票这些生活场景，把 Agent 的四个核心概念掰开揉碎了讲。保证你看完就能跟朋友吹牛："AI Agent？我懂，其实就是……"