前端转Agent开发，先放下模型训练，这些工程技能才是核心

第一次被问到“Agent 开发是不是要训练模型”的时候，我愣了好几秒。问的人是个写了好几年前端的朋友，技术底子不差，React、Node.js 都玩得挺溜，突然想转来做 Agent，结果第一反应是“那我是不是得先去补深度学习”。我说你先别急，这个理解从根上就偏了。Agent 开发本质上是工程问题，不是算法问题，更不是模型训练问题。你真正要补的，不是反向传播和损失函数，而是工具封装、上下文管理、工作流编排这一整套应用层的东西——而这些恰好是前端工程师最容易迁移过去的技能。

如果你也是个前端，正琢磨着要不要入局 Agent 开发，或者已经在看相关的东西但被“模型训练”四个字劝退了，那这篇就是写给你的。我会把 Agent 开发到底是什么、和模型训练的界限画在哪、前端怎么把自己的技能迁移过来，以及我在实际开发里踩过的坑，一五一十讲清楚。

1. 先把认知掰正：Agent 开发是造车，不是炼油

1.1 模型训练和 Agent 开发，压根是两条赛道

模型训练是一套完全不同的工作：你得准备数据集、清洗数据、设计训练目标、调超参数、跑分布式训练、看 loss 曲线、做评测，最后还要部署模型服务。这套链路里全是算法工程师和机器学习工程师的地盘，涉及的每一环都是独立的学科。前端工程师从零开始学这些东西，不说三五年，至少也是一两年的沉浸期，而且学完了大概率发现自己只是学会了“训练”这个动作，离做出一个能用的 Agent 还差十万八千里。

Agent 开发做的事情则完全在另一个层面。它是在一个已经训练好的、能用的模型之上，把模型包装成一个能干活、会调用工具、能记住上下文、可以完成多步任务的智能体。你写的是调度逻辑、工具接口、状态存储、异常处理、提示词结构，全部是软件工程的经典内容。模型是别人炼好的“发动机”，你要做的其实是“造车”——设计底盘、接上方向盘、挂好发动机、铺好电路，最后让这辆车能上路跑起来。

用个更直白的类比：模型训练像是酿酒，你得研究发酵的微生物、控制温度湿度、等时间沉淀；而 Agent 开发像是调酒师，酒是现成的基酒，你要做的是设计配方、把握比例、掌握摇壶的手法和出品的节奏。一个酿酒的师傅未必会调酒，但一个好的调酒师完全可以把现有的基酒调出一杯出色的鸡尾酒。前端转 Agent 开发，学的不是酿酒，是调酒。

1.2 为什么“Agent 开发不是模型训练”这个认知如此重要

这个误区带来的最大危害不是“学错了知识”，而是“被吓退了”。我见过不少前端同行，被“大模型”“Agent”术语轰炸之后，觉得这玩意不是自己能碰的，于是干脆放弃。但真相是，Agent 开发的门槛恰恰被那些吓人的术语拉高了。你不需要知道 Transformer 的注意力机制是怎么算的，只要你懂得把一个 JSON 传给接口、能理解返回结果、能管理好几个异步任务的先后顺序，你就已经具备做 Agent 开发的核心能力了。

在团队协作的层面，这个认知同样关键。如果一个前端转过来做 Agent 开发，却把精力投入到研究怎么训练模型，那他大概率会陷入漫长的学习停滞期，既没产出业务价值，也打击了自己的信心。相反，如果他明白自己要做的是应用层开发，他可以很快上手，两周内就能写通一个像样的 Agent demo，然后基于这个 demo 和算法同事聊需求时，双方也更容易对齐——你负责的是 Agent 的行为逻辑，算法负责的是模型本身的能力，这两件事本来就可以分工协作，互不干扰。

1.3 前端做 Agent 开发的天然优势，比你想象中大

很多人以为前端和 Agent 开发八竿子打不着，实际上前端的核心技能有一大半可以直接平移过来。

第一是组件化思维。你在 React 里写的组件，本质是一个带输入输出接口、内部封装了状态和逻辑的单元。Agent 里的工具（Tool）也是同一个思路：你给模型提供一组“函数”，每个函数都有名字、描述、参数协议，模型会根据任务需要来“调用”它们。你设计工具的视角，和你设计 React 组件 props 的视角几乎一模一样——接口清晰、职责单一、行为可预测。

第二是异步编程的经验。Agent 的一个核心循环就是“模型决定调用哪个工具 -> 程序执行工具 -> 把结果交还给模型 -> 模型决定下一步”，这个过程中，多个工具可能要并行执行、失败要重试、超时要兜底。你如果在前端处理过 Promise.all、race、超时控制和竞态问题，处理起这些来几乎是无缝衔接。

第三是状态管理的心智模型。前端的 Redux、Zustand 那套全局状态管理，用在 Agent 里就变成“记忆管理”。Agent 需要把对话历史、工具调用结果、用户意图的中间状态串起来，形成一个连贯的上下文。状态管理的核心难点——数据流的单向性、状态的单一数据源、避免状态不一致——放到 Agent 里依然成立，你踩过的那些坑，换个场景还是那些坑，只是数据的形态变成了消息列表和工具输出。

2. Agent 的本质拆解：不是玄学，是一套工程结构

2.1 Agent 的四块拼图：大脑、手脚、记忆、调度

把 Agent 拆开看，它其实是四个基础模块的组合。理解这四个模块，比背任何概念都重要。

第一是“大脑”，也就是大模型本体。它负责理解用户的指令、判断需要做什么、生成回复或决策。但模型本身是“知道很多但行动很弱的”，它不会真的去查数据库、调用 API 或操作文件，它只会“说”它想怎么做，也就是输出一段结构化文本，声明它想调用哪个工具、传什么参数。

第二是“手脚”，也就是工具集（Tools）。工具是 Agent 真正能对外界产生影响的手段，比如一个查天气的接口、一个发邮件的函数、一段执行 SQL 的代码。每个工具都需要用模型能理解的语言描述自己：它是干什么的、需要什么参数、参数的类型和约束是什么。这部分的本质工作是“把程序函数翻译成模型能读懂的自然语言接口”。

第三是“记忆”。Agent 需要跨对话、跨步骤记住信息。短期记忆就在消息列表里，每轮对话的历史都会作为上下文传给模型；长期记忆则通常存在外部存储中，比如向量数据库，把重要的历史信息检索出来拼进当前上下文。对前端来说，你只需要把它理解成“缓存 + 状态”，只不过读取和写入的时机需要精心设计。

第四是“调度”，这是 Agent 开发真正花心思的部分。模型说“我要调工具A”，你的程序就去调；工具A返回结果后，你决定这个结果要不要塞回上下文、塞多少、以什么格式塞；如果模型连续要调用工具五次，你的循环怎么设计才能既不死循环、又不烧太多 token；如果用户中途改了需求，你怎么打断当前的执行链。这些调度细节，决定了 Agent 是真能干活还是只会聊天。

2.2 用前端的语言重新翻译这四个模块

如果你对上面四块还是有一点抽象，我用前端术语帮你重新翻译一下。

“大脑”就像是你的核心业务逻辑层。它不负责具体的 IO 操作，只负责任务分解和决策。在 Agent 里，模型唯一的输出通道是文本，但你要做的是把这个文本输出当成“指令”而不是“显示文案”，所以你会设计一套解析逻辑，从模型输出的文本里提取出“要调用哪个函数、参数是什么”。

“手脚”对应的是前端的 API 层。你写前端时不会在组件里直接 fetch 到处撒，而是集中封装成一个 api.ts 模块，统一管理请求地址、参数类型、错误码。Agent 的工具层也是一样的角色，只不过消息的格式变成了模型协议要求的 JSON Schema，让每个函数对模型来说是“可发现、可理解、可调用”的。

“记忆”对标的是前端的全局状态管理。前端应用的状态一乱，整个 UI 就跟着乱；Agent 的上下文一乱，模型的输出也跟着乱。你会设计一套“哪些信息需要长期保存、哪些只要当前轮次能用就行”的策略，对应前端就是“哪些状态进 store、哪些用局部 state”。

“调度”更不用说了，它就是前端的路由和控制器。入口请求进来之后，要走哪条流程、哪些步骤可以并行、哪些步骤有依赖关系、失败之后退回哪里，这些你在写前端路由守卫、写 Redux 中间件时早就练过了。Agent 只是把这个流程从“用户点击按钮”换成了“模型输出一个意图”。

2.3 建立正确心智模型：模型是协作者，不是被调用的对象

还有一个很重要的心智转换，前端刚接触 Agent 时很容易搞反：你平时写代码，函数是你的下级，你让它干什么它就干什么，结果 100% 可以预期。但模型不是这样，它是协作者，甚至可以说是一个有点轴、偶尔会理解错的实习生。你告诉它“这个工具只接受数字类型的参数”，它还是有概率传一个字符串进来；你告诉它“要先查天气再决定要不要出门”，它也有概率直接跳过查天气那一步给出建议。

所以 Agent 开发的很多工作，不是在写“100% 正确的逻辑”，而是在设计“在不确定性的前提下依然能兜底的系统”。你要做的是把工具的 Schema 写得足够清楚、把模型的输出校验做在前面、把失败重试的路径铺好，并且在提示词里给足明确的边界。这个心智模型的转变，比学会任何具体 API 都重要。

3. 手把手：前端从零写一个带工具的 Agent Demo

3.1 先用一张技能地图，看清楚前端和 Agent 开发的对应关系

在写代码之前，我把前端技能和 Agent 开发需要的技能做了一张对照表，你可以对着这张表检查自己的知识储备。你会发现大部分内容你其实已经会了，欠缺的只是“换个语境再认一遍”：

这张表的意思很明确：你不是从零开始，你只是把已有的技能换个对象用。接下来我用一个实际项目（某信息收集小助手）来演示核心流程。

3.2 项目背景与功能定义

某信息收集小助手，目标用户是运营人员。这个 Agent 要做的事情是：用户给它一句自然语言请求，比如“我想去某城市玩两天，帮我规划一下景点和预算”，它需要自己去查景点信息、计算预估费用，然后输出一份结构化的行程建议。

整个 Agent 不训练任何模型，只用现成的大模型 API。它需要有两个工具：

• 搜索景点：输入一个城市名，返回该城市的热门景点列表（包括景点名、门票价格、建议游玩时长）。
• 计算预算：输入景点列表和游玩天数，返回一个预算估算结果。

这两个工具都用本地函数模拟实现，不涉及真实的外部 API，这样你能一次性看清 Agent 的完整骨架。

3.3 核心代码实现：工具定义、消息循环、结果校验

我用 TypeScript 来实现，Node.js 环境下直接能跑。首先是工具定义部分。每个工具本质上是一个带 Schema 的函数描述，模型看到这个描述后，才知道有这些东西可以用：

// tools.ts // 工具定义的核心数据结构：给模型看的“说明书” export interface ToolDefinition { name: string; description: string; parameters: { type: string; properties: Record<string, unknown>; required?: string[]; }; } // 模拟的景点数据 const citySpots: Record<string, Array<{ name: string; ticket: number; hours: number }>> = { "某古城": [ { name: "古城墙", ticket: 0, hours: 4 }, { name: "博物馆", ticket: 30, hours: 2 }, { name: "老街", ticket: 0, hours: 3 }, ], "某海滨城市": [ { name: "沙滩公园", ticket: 20, hours: 5 }, { name: "海洋馆", ticket: 180, hours: 3 }, { name: "灯塔景区", ticket: 45, hours: 2 }, ], }; // 工具1：搜索景点 export const searchSpotsTool: ToolDefinition = { name: "search_spots", description: "根据城市名搜索热门景点，返回景点名称、门票价格和建议游玩时长", parameters: { type: "object", properties: { city: { type: "string", description: "城市名称" }, }, required: ["city"], }, }; // 执行函数：和定义一一对应 export function searchSpots(args: { city: string }) { const spots = citySpots[args.city]; if (!spots) { return JSON.stringify({ error: `未找到 ${args.city} 的景点数据` }); } return JSON.stringify({ city: args.city, spots }); } // 工具2：计算预算 export const calcBudgetTool: ToolDefinition = { name: "calc_budget", description: "基于景点列表和游玩天数，估算门票总费用和每日平均费用", parameters: { type: "object", properties: { spotNames: { type: "array", items: { type: "string" }, description: "景点名称列表" }, days: { type: "number", description: "游玩天数" }, }, required: ["spotNames", "days"], }, }; export function calcBudget(args: { spotNames: string[]; days: number }) { const totalTicket = args.spotNames.reduce((sum, name) => { for (const spots of Object.values(citySpots)) { const found = spots.find((s) => s.name === name); if (found) return sum + found.ticket; } return sum; }, 0); const dailyAverage = Math.round(totalTicket / Math.max(args.days, 1)); return JSON.stringify({ totalTicket, dailyAverage, days: args.days }); }

然后是 Agent 的主体逻辑。这里最关键的是那个“循环”：模型返回一个 Tool Call 请求，程序就执行对应工具，把结果追加到消息列表，再交给模型；直到模型不再请求工具，直接给出最终答案，循环才结束。这个循环看似简单，实际上就是 Agent 的“心脏”：

// agent.ts // 为了让不依赖具体平台，这里用一个简化的 chat 函数抽象模型调用 type ChatMessage = | { role: "system"; content: string } | { role: "user"; content: string } | { role: "assistant"; content?: string; toolCalls?: ToolCall[] } | { role: "tool"; content: string; toolCallId: string }; interface ToolCall { id: string; name: string; args: Record<string, unknown>; } // 模拟模型响应：System prompt + 工具定义会让模型“决定”调用哪个工具 async function callModel(messages: ChatMessage[], tools: ToolDefinition[]): Promise<ChatMessage> { // 在真实项目中这里会调用大模型 API。 // 为了演示，我写一个简化的模拟逻辑： // 如果用户消息中包含“城市”，且还没有查过景点，就调用 search_spots； // 如果已经拿到景点列表，且还没有算过预算，就调用 calc_budget。 const lastUser = [...messages].reverse().find((m) => m.role === "user"); const hasSearched = messages.some((m) => m.role === "tool" && m.toolCallId?.startsWith("search")); const hasBudgeted = messages.some((m) => m.role === "tool" && m.toolCallId?.startsWith("budget")); if (lastUser && hasSearched === false) { const cityMatch = lastUser.content.match(/某[^\s]+城市|某古城|某海滨城市/); if (cityMatch) { return { role: "assistant", toolCalls: [{ id: "search_1", name: "search_spots", args: { city: cityMatch[0] } }], }; } } if (hasSearched && hasBudgeted === false) { return { role: "assistant", toolCalls: [{ id: "budget_1", name: "calc_budget", args: { spotNames: ["古城墙", "博物馆"], days: 2 }, }], }; } // 如果工具调用都完成了，返回最终答案 return { role: "assistant", content: "查完景点和预算了，最终建议如下：\n...（格式化行程）" }; } // 核心循环：模型决策 -> 工具执行 -> 结果回填 -> 再次决策 export async function runAgent(userInput: string) { const messages: ChatMessage[] = [ { role: "system", content: "你是旅行规划助手。你需要先搜索景点，再计算预算，最后给出完整建议。", }, { role: "user", content: userInput }, ]; const tools: ToolDefinition[] = [searchSpotsTool, calcBudgetTool]; for (let round = 0; round < 5; round++) { const response = await callModel(messages, tools); // 如果模型返回的是最终回复，直接返回 if (response.toolCalls == null || response.toolCalls.length === 0) { return response.content; } // 如果模型请求调用工具，逐个执行并把结果放回消息列表 messages.push(response); for (const call of response.toolCalls) { let result: string; if (call.name === "search_spots") { result = searchSpots(call.args as { city: string }); } else if (call.name === "calc_budget") { result = calcBudget(call.args as { spotNames: string[]; days: number }); } else { result = JSON.stringify({ error: "未知工具" }); } messages.push({ role: "tool", content: result, toolCallId: call.id }); } } return "已达到最大循环次数，需要检查是否陷入死循环。"; }

这段代码虽然是模拟模型返回的，但结构是真实项目里的标准写法。你把模拟的回调替换成真实的模型 API 调用，就立刻能让它跑在真实模型上。这里有一个非常关键的工程思维：模型的决定是不可预测的，但你的程序结构必须是可控的。所以循环要有上限，工具定义要清晰，取回来的模型输出要校验，不能盲目信任。

3.4 从这个 Demo 里，前端应该提炼出的四个关键点

第一，消息列表是整个 Agent 的“数据总线”。所有信息——用户的请求、模型的中间决策、工具的返回结果——都通过消息列表往返传递。模型看到什么，完全取决于你往消息列表里放了什么。这个和前端状态管理里的单一数据源思想完全一致。

第二，工具定义的核心是“描述”，不是“实现”。一个搜索函数本身很简单，工作量大的是它的描述和参数 Schema。写描述时要像写一份给实习生看的操作手册：说清这个工具是干什么用的、什么时候该用、参数是什么意思、参数之间有没有依赖关系。前端写组件文档的经验在这里能直接用。

第三，上下文管理是成本和质量的关键。每次调用模型，消息列表里所有内容都会被计费，还会占满模型能看到的上下文窗口。如果你的工具返回了很长的数据，你得决定是完整回填，还是只截取关键字段。在这个 Demo 里景点数据是有限的，但在真实场景里，搜索结果可能几万字符，不加截断策略，第二个工具调用时上下文就撑爆了。

第四，可观测性非常重要。我在开发前端时习惯给每个组件写日志、做调试面板，做 Agent 也一样。每一次模型返回了什么、选择了哪个工具、传了什么参数、工具返回了什么结果，这些节点全部要能追踪。没有可观测性，Agent 一旦行为异常，你连排查的方向都没有。

4. 给前端的投入指南：哪些该学，哪些不该碰

4.1 明确说不：这些现在不需要学，学了对做 Agent 帮助也不大

如果你当前的目标是快速上手 Agent 开发，我建议你先别碰下面这些东西：

第一，深度学习理论基础。什么 Transformer 的注意力机制、多头机制、残差结构，知道它们存在就行，真不用去翻论文啃公式。你做 Agent 开发遇到问题时，绝大多数都出在上下文管理、工具协议、流程编排上，而不是模型内部的数学原理。

第二，模型微调和训练工具链。PyTorch、TensorFlow、分布式训练、数据标注流水线，这些是算法工程师的领域。除非你的产品对模型的输出格式有极其特殊的定制需求、或者你所在团队连算法同事都没有，否则你不应该在入门阶段碰这些。

第三，GPU 资源管理和推理优化。什么半精度推理、KV Cache 优化、显存批处理，这些是 MLOps 的活。用现成的模型 API 时，底层推理完全不归你管。

我见过有些前端花了大半年去学 PyTorch，最后发现 Agent 项目里根本用不上，还要靠学工程化的知识把时间补回来。如果你真想长期往 AI 方向深入，模型训练可以作为后续的第二技能，但绝不是你从“前端”转“Agent 开发”的第一站。

4.2 明确说该学：真正的 Agent 开发核心技能清单

那该学什么呢？按优先级排序，真正需要投入时间的是这些：

第一，提示词工程。不是会写几句指令就叫会提示词。你要能理解 System Prompt 和 User Prompt 的分工，会写结构化提示词，懂得把“使约束、步骤、边界”放进 System Prompt 里。比如说“你必须先调用 search_spots 拿到数据后再回答问题”这句话写没写，效果差距极大。

第二，Function Calling 协议。这是最核心的工程能力。你得理解模型是怎么根据工具描述去生成工具调用请求的、参数怎么传、如果模型传错参数你该怎么兜底。每一个主流模型平台的 Function Calling 格式都有一点点差异，但你掌握了核心那一套，其他都能快速迁移。

第三，上下文与记忆管理。什么信息要放、什么信息要丢、什么历史要截断、什么结果要压缩。前端程序员习惯于“数据都在浏览器里，随取随用”，但 Agent 的上下文是要花钱的、窗口是有限的，所以你要学会做“上下文节流阀”。

第四，典型工作流模式。包括 ReAct 模式（思考-行动-观察循环）、多步工具编排、人工确认节点（比如涉及付款/发邮件时先停下来让用户确认）。这些模式有非常成熟的工程范式，花时间学习和实践它们，比研究模型本身收益大得多。

第五，成本和性能意识。模型调用是按 token 计费的，同样的功能，代码实现不同，成本可能差几十倍。前端开发往往不太在意一两次网络请求的代价，但 Agent 的每一步循环都意味着钱和延迟，你要养成“每次调用前先想清楚值不值得”的习惯。

4.3 什么时候才需要回头补模型训练的知识

我也不是一刀切说模型训练永远用不上。实战中确实会遇到这些情况：你有一个固定的输出格式，模型怎么提示都不稳定；或者你的业务里全是专业术语，通用模型不认识；又或者你长期高频调用，成本高到不如自己微调一个轻量模型划算。到了这些节点，你可以考虑微调一个模型，但即便如此，也不是你亲自去训，而是你能提出明确的“数据需求 + 效果验收标准”，交给算法同事或外部服务去处理即可。

所以更准确的说法是：前端入局 Agent 开发，前期完全不需要碰训练；到后期，你要掌握的是“判断什么时候需要训练”的能力，而不是“自己动手训练”的技能。

5. 实战避坑实录：我踩过的五个典型坑

5.1 上下文无限膨胀，token 费用像漏水

我最早做 Agent 时，每轮循环都不清理中间的工具返回结果，结果发现一次简单任务链调用模型十几次，每次都在传越来越长的历史消息。半个月后看账单，数字吓了我一跳。

后来养成了一个习惯：每次组装消息列表时审视一遍，工具返回的原始数据如果很长，就只截取关键字段或者做一个摘要。比如搜索接口返回了 50 条景点，我只取 top 5 的名字和价格回填。这个“回填瘦身”的动作，成了我所有 Agent 项目里的标配。

5.2 模型不按套路出牌，工具参数传错

有一回我让 Agent 调用一个可以传“日期范围”的工具，模型直接把字符串传成数字格式，程序一执行就报错。后来我把参数类型从字符串改成字符串格式说明，加了枚举校验，并在提示词里明确写了“严格按 YYYY-MM-DD 格式”，问题才解决。

这件事让我意识到，工具定义写得好不好，直接决定 Agent 稳定性。你不能指望模型真的“理解人类语言”，它只是按照工具描述去猜你想要的参数，你得把描述写得像 API 文档一样精确，而且一旦发现模型频繁传错，第一反应应该是去改描述和 Schema，而不是去怪模型。

5.3 死循环：Agent 不停地调用同一个工具

有一次 Agent 在执行一个“搜索信息并总结”的任务时，总是搜索完成后不进入总结阶段，而是继续搜索。日志显示，问题出在工具返回结果里带了一段“提示语”，模型把那段提示语当成“还需要再搜索”的信号，于是循环反复。

后来我在 System Prompt 里加了硬性规则：“当已完成至少一次搜索且结果非空时，严禁再次调用搜索工具，必须直接生成回答。”同时，我在主循环里加了最大轮次限制和重复工具调用的检测机制，双保险兜住。Agent 开发和传统编程最大的不同就是你没法完全预测模型的行为边界，所以保护机制要提前布置好。

5.4 只给模型工具名，不给调用边界

早期我犯过一个经验主义错误，以为只要把工具函数写出来，模型自然知道怎么调。结果是模型经常“猜”一个不在工具列表里的函数名，或者把多个参数混在一起传。后来我开始在工具定义里加入“示例”字段，给出一个具体调用示例，效果立竿见影。对模型来说，一个真实的 JSON 示例，比一大段描述性文字有效得多。

5.5 多轮对话状态混乱，短期记忆串味

做信息收集类 Agent 时，用户可能在第一轮问了景点，第二轮问预算，第三轮要求换个城市。如果 Agent 不更新城市状态，就会出现“问着新城市、算着旧城市”的错乱。我当时的解法是维护一个“任务状态单”，每次新用户输入都先抽取和更新这个状态单，再基于最新状态去组织工具调用。这个状态单就相当于 Redux 里的 reducer 中心，所有中间信息都汇总到这里，各步骤只从这个状态单取值。

5.6 常见问题速查表

6. 阶段式学习路径：前端怎么一步步长成 Agent 开发者

6.1 阶段一：会用模型 API，能封装自己的“工具函数”

第一个目标周期大约两三周。你要做到的是：不看文档也能靠着记忆拼出一个带工具调用的最小 Agent。具体动作包括：申请一个模型 API 的 Key、了解消息列表结构、写一段代码调用模型并打印出原始返回、给这个模型挂上一个自定义工具、验证模型能自主决定调用工具并完成一次完整的“用户问题 -> 工具执行 -> 最终回答”链路。

这个阶段最容易犯的错是“死记硬背框架代码”。真要理解工具调用协议里的每个字段是干嘛的，尤其是工具调用的 ID 怎么和 tool 消息关联。你不理解这层关联，后面做多工具并行时一定会踩坑。

6.2 阶段二：能把单次调用扩成复杂工作流

当你把单个 Agent 循环写顺手之后，要开始做更复杂的编排。比如给 Agent 加“规划 -> 执行 -> 复查”三个阶段：先让模型生成执行计划，再按计划调用多个工具，最后做一个汇总校验。或者设计一个“用户确认节点”，让 Agent 在发送邮件或扣款前，先输出一个待确认摘要，等用户说“确认”才继续。

这个阶段的关键是培养“流程设计”意识。你不再是写一个函数响应一次，而是设计一条可以容纳多轮交互、多次工具调用、有人工干预的状态机。前端做过新手引导流程、做过表单向导，其实都是同一个套路。

6.3 阶段三：懂 RAG、记忆与多智能体协作

再往后，你要开始解决更复杂的信息管理问题：Agent 需要访问团队内部的文档、需要跨会话记住用户的偏好、需要把一个大任务拆给多个子 Agent 协同完成。这时候你会用到向量检索、会话摘要压缩、子任务的消息广播与结果汇聚等方案。这些技术听起来很高大上，但本质还是“存储 + 检索 + 拼接上下文”的工程问题。

我没法认定一个人的学习速度能有多快，但从我的实际经验来看，如果每天能保证两三小时投入，三个月左右做到阶段三，完全在合理范围内。这个速度的前提就是别再往模型训练那个方向跑偏。

6.4 最后想说的一些体会

我在这一路做下来之后，最大的一个感受是：Agent 开发给前端带来的不是一个“新饭碗”，而是一套“新的表达方式”。你之前面对的是浏览器和用户，现在面对的是一个语言模型和需要模型去帮你完成的任务。本质上，你还是在做“把需求翻译成程序行为”这件事，只不过“程序行为”的形态从“渲染一个页面”变成了“编排一堆工具调用”。

所以如果你是一个前端，看到 Agent 相关的招聘需求或技术讨论，别再被“训练模型”四个字吓住了。你真正需要做的，是坐下来，写一个最简的带工具调用的 Agent，让它帮你搜索一个词、算一个数、整理一段话。跑通那一次循环，你会发现自己其实早就站在门里了。剩下的，只是在往里走更远一点的问题。