企业官网建设流程全解析

我搞前端差不多五年，写过组件库、调过性能、也带过小团队，但这两年AI Agent的风刮得太猛了，说实话有点焦虑。直到有一天一个做企业服务的客户找到我，提了一个很真实的需求：他们想做一个自动整理销售线索的智能助手，但找了一圈外包团队，要么只会套模板做demo，要么压根不接这种“非纯UI”的活。我那天晚上想了很久，第二天跟老板说，这个项目我来接，前端转Agent开发，就拿这个真实需求开刀。

这一篇就把我从“前端工程师”切换到“Agent开发者”的完整过程记录下来：怎么把企业模糊的需求翻译成技术方案，怎么选框架，怎么设计LLM调用链，以及真正上线时会踩哪些坑。希望能给同样在前端岗位焦虑、想往AI应用方向走的同行一点真实参考，而不是满屏的“零基础七天转AI”。

1. 为什么前端转Agent开发，切入点必须是“真实企业需求”

1.1 从焦虑到下决心：只学概念永远转不了行

前端转Agent，很多人第一步就错了。市面上各种LangChain教程、ReAct论文解读、Multi-Agent框架对比刷了一圈，一搜热词全是“agent项目”“agent架构”“agent智能体开发教程”，但真到动手的时候，连一个“给谁用、解决什么痛点、数据从哪来”的问题都答不上来。

我之前也这样，收藏了一堆链接，买了两个课，吭哧吭哧跑通了官方的ReAct示例，拿OpenAI的API做了一个能算数、能查天气的demo，发到朋友圈觉得自己行了。结果客户一问“那你能不能把我CRM里几千条Excel导出的杂乱备注，自动归类成有效商机”，我当场卡住——数据清洗要什么步骤？字段映射规则怎么定？LLM幻觉导致分类错了怎么办？这些问题，教程一个都没教。

所以我今天最想分享的第一句话就是：前端转Agent，别从“学会框架”开始，要从“接一个真实需求”开始。真实需求会逼你面对脏数据、模糊指令、成本控制、结果校验这些demo里永远碰不到的问题。这些问题才是Agent工程师的护城河。

1.2 前端背景到底哪里值钱：界面交互直觉就是Agent的交互设计基础

很多人觉得前端转Agent开发是“抛弃老本行”，我不这么看。Agent产品的本质是“对话式交互系统”，而前端最懂交互。传统软件的用户是鼠标键盘，Agent的用户是自然语言；传统前端要考虑按钮怎么摆、反馈怎么给，Agent要考虑Prompt怎么组织、工具结果怎么展示、异常要怎么追问。

我实际做的这个销售线索Agent，最终形态是一个嵌入企业工作台的聊天面板。用户直接对它说“把最近一周里提到‘预算已批’并且采购量超过1000的线索抽出来”，这句话背后其实就是一次前端路由匹配：意图识别相当于路由，参数抽取相当于query解析，工具调用相当于请求后端API，最终结果渲染相当于setState后视图更新。把前端那套“状态机 + 数据流 + 边界处理”的思维平移过来，你会发现Agent开发并没有那么神秘，只是数据从JSON变成了自然语言，从确定的API返回变成了概率性的模型输出。

1.3 定位目标：这篇博文到底解决什么

如果你现在的情况和我当时类似——前端基础OK，会调用API，了解基本HTTP和异步流程，但没系统做过LLM应用开发，想找一个能写进简历的实战项目——这篇文章非常适合你。

我会沿着一条真实企业需求的主线走：客户要给销售团队做一个“智能线索清洗与分类Agent”。我会讲清楚需求怎么拆、架构怎么选、代码怎么写、上线怎么调，最后把最容易踩的坑和排查思路也整理出来。学完这个案例，你会有一套完整的方法论，而不是只会跑别人写的示例。

2. 企业需求如何从“几句话”变成一个Agent项目

2.1 原始需求的迷人与模糊：一场需求澄清实录

客户原话大致是这样的：“我们销售每天要花两三个小时整理客户信息，把各种渠道来的线索录进系统、打标签、判断有没有戏。你们能不能做个机器人，把这些活干了？”

听着好办，实际上全是坑。我得先搞明白三件事。

第一，“各种渠道”到底是什么？问下来发现是：企业微信群闲聊记录、销售手动填写的一个Excel登记表、还有官网表单提交过来的结构化JSON。三种来源，格式完全不一样。第二，“判断有没有戏”是什么意思？销售主管解释，他们内部有套粗定义：线索分为A（有预算、有时间、有决策权）、B（有兴趣但条件不成熟）、C（暂时联系不上或无效）。但这套定义从没写成文档，全在老销售脑子里。第三，“把活干了”到什么程度？是完全自动化，还是人工复核？这个需求直接决定了Agent的权限边界和用户接受度。

2.2 从用户故事到Agent能力边界：三个角色的模糊交互梳理

需求澄清后，我给自己画了一张简单的交互图，纸上画的，一直没有做成任何正式文档，核心就是三个角色怎么来回配合。这里我还是用文字描述，大家用纸笔画一画就清楚了：

• 销售用户：向Agent输入原始线索（文字、图片截图、Excel片段），询问线索质量，要求生成跟进建议。
• Agent本体：负责解析输入、判断意图、决定是直接调工具还是先问用户、组装回复。
• 后端工具层：我给Agent准备了三个工具：线索数据结构化、用户资料查询、标签映射规则查询。Agent自己不具备业务判断能力，所有跟业务相关的判定都要通过工具调用拿到数据后才能下结论。

这套设计有一个前端工程师特别容易理解的类比：Agent就是前端组件，工具层就是后端接口，Intent就是路由。前端绝不会自己瞎改后端数据，Agent也绝不能凭空编造客户信息和评分。边界一旦划清，后面写代码的逻辑就顺了。

2.3 可落地的最小版本与进阶版本的界定：MVP的威力

真实企业项目最忌讳一上来就“全能”。我把这个项目切成了三个版本：

• V1（两周上线）：只做“线索结构化 + 基础标签分类”，输入一段原始备注，输出格式化的客户信息和A/B/C意向等级，附一句判断依据。
• V2（一个月）：加入“批量处理Excel”和“与CRM系统对接”，能够一键处理几百条线索，并把结果写回销售后台。
• V3（季度目标）：加入“主动跟进提醒”，比如某线索超过7天没跟进，Agent会主动推送提醒；支持销售用语音输入。

我特别强调一下这个切法的价值。V1我实际上只用了五天就做完了，第六天就去客户那边演示。为什么这么快？因为我把所有跟业务深度耦合的需求都砍到了V2。客户看到V1能跑起来，马上就会给出V2最真实的反馈——比如“啊，我们其实还有第四个线索来源”。如果没有V1的快速交付，这些信息你永远拿不到。

3. 技术选型：不是所有Agent框架都值得你投入时间

3.1 框架选择实录：LangChain vs LlamaIndex vs 自研编排

选型的核心考量是什么？我的答案是：团队维护成本、可控性、以及对现有前端技能的复用度。

• LangChain：生态最全、教程最多，但抽象层太重。我初学的时候就被各种Chain、Router、Memory搅得头疼，调试起来像在解套娃。适合需要快速接入大量外部工具的团队，但对我来说，熟悉它的底层原理所花的时间，足够我自己写一套轻量编排了。
• LlamaIndex：在“文档问答、知识库检索”这个单点场景确实强，但我们的场景更偏向“结构化数据抽取 + 业务规则判断”，知识库不是核心，所以没有选它。
• 自研编排（最终选择）：我基于TypeScript写了一个不到三百行的Agent循环核心，包括工具注册、消息历史管理、函数调用解析、错误重试。为什么选自研？因为我们的Agent功能边界极其清晰，就三个工具，用不着重型框架；而且自研之后，整个调用链路的每一行代码我都了如指掌，出了问题能在半小时内定位，这对企业项目的长期维护是至关重要的。

3.2 为什么选择OpenAI函数调用（Function Calling）而不是纯Prompt

这可能是整个项目中最关键的一个技术决策：让Agent学会“调用工具”，我选了OpenAI的Function Calling能力。

早期我也试过纯Prompt方案，意思是在系统提示词里写：如果用户想查客户资料，请输出“查客户资料：客户名”。然后我再用正则去解析模型的输出。这种方案在测试集上表现尚可，一旦遇到复杂一点的用户表达就崩了。比如用户说“你看看那个姓张的，上周提了预算的那个”，模型可能输出“查客户资料：张姓客户，上周提预算”，这个“上周提预算”我正则解析就傻眼了。

用Function Calling之后，模型会直接输出一个结构化的JSON，类似：

{"name": "query_user_profile", "arguments": {"keywords": "张姓客户 预算"}}

这个JSON和前端调API时的request body没什么区别，我只要做一层validator就能安全通过。实测下来，意图识别的鲁棒性提升了一个量级。我觉得这也是Agent开发最核心的认知转变：不要用人能理解的方式跟模型对话，要用模型最擅长的方式（结构化约束）跟模型对话。

3.3 模型选型背后的成本账：GPT-4o与国产模型的取舍

真实企业项目，成本是绕不开的坎。我做了两组实测：一组是GPT-4o全流程，一组是国内某主流大模型API + 规则兜底方案。

结果是：GPT-4o在复杂意图识别上的准确率确实高一截（94% vs 87%），但价格大约是国内模型的四倍。我们的场景是每天大概两百次调用，每次平均一千五百个token，算下来用GPT-4o每个月的API成本约在600元左右，用国产模型只要150左右。

最后方案是“混合路线”：核心线索分类用GPT-4o，因为它涉及多条件判断，准确率直接关系销售信任度；批量Excel处理这种机械性提取任务走国产模型，因为数据格式固定、Prompt简单，用便宜的模型性价比更高。这个思路前端应该很熟悉：静态资源走CDN，核心接口走专线。大模型API就是你的带宽，成本优化本质是流量调度。

3.4 前端环境下的Agent调试工具：从Postman到LangSmith

我平时调试接口用Postman，但调试Agent链路的时候Postman就力不从心了。因为Agent的每一次回答涉及多次模型调用，你不仅要知道最终返回了什么，还要看中间每一步：模型第一次理解了用户的什么意图、第二次调工具时传了什么参数、工具返回了什么、模型看到工具返回后如何组织最终回复。

这里我强烈建议花点时间搭一个可以记录“完整轨迹”的调试面板。我自己就是用React写了一个极简的可视化链路面板，左边显示消息历史（用户说了什么、助手调用了什么工具、工具返了什么），右边显示当前选中的完整Prompt/响应内容。有了这个面板，调试效率至少翻了一倍。这也是前端转Agent开发一个“降维打击”的点：你自己就能写出需要的调试工具，这就是前端技能带来的直接杠杆。

4. 实操过程与核心代码：从零搭建销售线索清洗Agent

4.1 环境准备：Node.js + TypeScript的项目骨架

我整个Agent服务用Node.js 20 + TypeScript 5.5开发，部署在客户内网的Docker容器里。为什么用Node而不是Python？因为做Agent开发相关的开源工具链虽然Python最多，但是这个后端服务后续要跟前端团队共用一套代码规范，我们团队全员TypeScript，这比什么都重要。项目结构如下：

agent-service/ ├── src/ │ ├── agent/ │ │ ├── index.ts # Agent主循环 │ │ ├── messages.ts # 消息历史管理 │ │ ├── tools.ts # 工具注册表 │ │ └── validator.ts # 工具参数校验 │ ├── tools/ │ │ ├── structureLead.ts # 线索结构化 │ │ ├── queryProfile.ts # 用户资料查询 │ │ └── classifyLead.ts # 线索分级分类 │ ├── llm/ │ │ └── client.ts # LLM调用封装 │ └── server/ │ └── index.ts # Express入口 ├── data/ │ └── seeds/ # 测试数据 └── package.json

每个工具进来都对应一个文件，和前端把组件拆成多个文件夹是一样的道理。工具内部再依赖独立的service层，Service层里再去调外部API或者读数据库，这样Agent的“大脑”和“手脚”隔离了，非常容易测试。

4.2 Agent主循环：用不到100行实现核心编排逻辑

很多新手总觉得Agent框架很神秘，但核心编排说白了就是这样一个循环：拿到用户消息，带上工具定义，发给模型；模型如果决定调用工具，就返回一个工具调用请求；系统执行工具、把结果拼进消息上下文，再发给模型；模型拿到工具结果后生成最终回答。我贴一下核心实现：

// src/agent/index.ts import OpenAI from "openai"; import { toolRegistry } from "./tools"; const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY }); export interface AgentRequest { messages: OpenAI.Chat.Completions.ChatCompletionMessageParam[]; maxSteps?: number; // 防止死循环 } export async function runAgent({ messages, maxSteps = 5 }: AgentRequest) { const runningMessages = [...messages]; for (let step = 0; step < maxSteps; step++) { const response = await openai.chat.completions.create({ model: "gpt-4o", messages: runningMessages, tools: toolRegistry.getOpenAIToolDefinitions(), tool_choice: "auto", }); const choice = response.choices[0]; const message = choice.message; // 模型结束生成，正常返回 if (!message.tool_calls || message.tool_calls.length === 0) { return { finalMessage: message, trace: runningMessages }; } runningMessages.push(message); // 逐个执行工具调用 for (const call of message.tool_calls) { const result = await toolRegistry.execute(call.function.name, JSON.parse(call.function.arguments)); runningMessages.push({ role: "tool", tool_call_id: call.id, content: JSON.stringify(result), }); } } throw new Error("Agent exceeded max steps"); }

这段代码其实就干了四件事：把用户消息发给模型、判断模型是要继续要工具结果还是直接回答、执行工具、把结果回传。企业的Agent核心就是这样一个循环，剩下的事情全在“工具质量”和“Prompt质量”上。

4.3 线上核心工具实现：线索结构化工具与所钟的参数校验细节

工具是整个Agent的能力上限，我来展示“结构化学会线索”这个最核心的工具实现。这个工具输入是一段乱七八糟的销售备注（来自微信聊天、Excel单元格等），输出是一个结构化客户对象。

工具的“工厂函数”长这样：

// src/tools/structureLead.ts import { z } from "zod"; const LeadSchema = z.object({ company_name: z.string().describe("客户公司完整名称"), contact_name: z.string().describe("客户联系人姓名，如果没有则为空字符串"), phone: z.string().describe("联系电话，去除空格和横线"), mentioned_budget: z.boolean().describe("是否提到预算"), budget_amount: z.number().nullable().describe("预算金额（万元），没提到则为null"), timeline: z.enum(["immediate", "quarter", "year", "unknown"]).describe("采购时间意向"), raw_source: z.string().describe("线索原始来源"), keywords: z.array(z.string()).describe("从原文中提取的关键特征词"), }); export async function structureLead(input: string) { const completion = await openai.chat.completions.create({ model: "gpt-4o", messages: [ { role: "system", content: "你是销售线索结构化引擎，从销售备注中提取字段。无法提取的字段设为null或unknown。不猜测任何信息。" }, { role: "user", content: input }, ], response_format: { type: "json_object" }, }); const parsed = JSON.parse(completion.choices[0].message.content || "{}"); const validated = LeadSchema.safeParse(parsed); if (!validated.success) { // 解析失败时返回结构化错误信息，而不是抛异常 return { status: "error", issues: validated.error.issues }; } return { status: "success", data: validated.data }; }

这里有两个细节值得多写两笔。一是response_format强制JSON格式输出，避免模型偶尔输出散文导致JSON.parse报错。二是zod做schema校验，模型输出的字段类型、枚举值全部严格检查，校验失败时返回错误结构而不抛异常。为什么这么设计？因为Agent的执行环境天然是“概率性的”，你永远要假定模型会出错，然后把出错处理写好，而不是赌它一定对。这一点和前端处理后端返回的数据是一样的思路——后端也可能给null，你总不能直接崩。

4.4 企业需求中最有说服力的“杀手锏”：批量Excel拖拽处理

V1演示的时候只有单条处理，销售总监看了说“还行，但我每天要处理几十条”。于是V2第一个功能就是批量处理Excel。

前端这边我做了个拖拽上传界面，本质上就是上传文件到后端，后端用SheetJS解析Excel，逐行调用同一个structureLead工具，再把结果生成一个新Excel返回。听起来简单，这里面有个特别容易忽视的性能问题：假设一单Excel有200行，每行都调一次大模型API，串行执行的话，一次跑完可能要十几分钟。用户根本等不了。

优化方案是“并发 + 限流”。因为API有每分钟调用次数限制，我用了p-limit这个库控制并发数在5，200行分成约40批，每批5个并行，总时间从十几分钟优化到两分半左右。前端这边用Web Worker处理Excel文件的解析和预览，主线程不卡。上传大文件、展示进度的经验在这里全部迁移过来，前端积累的那些性能优化技巧，在Agent应用里全都能用上。这就是为什么我一直说，前端转Agent不是转行，是跨界复用。

5. 常见问题与排查技巧实录

5.1 模型总是不按预期调用工具？多半是工具定义写得像人话

这是我在调试过程中遇到最多的问题。一开始我写的工具描述是“结构化学会线索”，模型经常不调用，或者乱调。后来我发现问题在于：工具的JSON Schema描述用的太口语化或者太模糊，模型不知道该在什么情况下调用它。

后来我把每个工具都写成“前置条件 + 触发场景 + 期望输入”三段式，效果立竿见影。举个例子：

{ "name": "query_user_profile", "description": "仅当用户提到现有客户、或要求查看客户资料时调用。如果用户只是想登记线索，不应调用。", "parameters": { "type": "object", "properties": { "keywords": { "type": "string", "description": "客户名称、联系人姓名、电话等任意可定位用户的线索关键词，可组合" } }, "required": ["keywords"] } }

工具描述就好比前端的接口文档，前端调用接口时，如果没有标注好“何时该调、何时不该调”，对接的后端同事也会一头雾水。给模型写工具定义，本质就是给一个极其较真的“初级开发”写API文档，要把触发条件、边界情况、参数语义全部写清楚。

5.2 Agent执行中途报错：从“execution terminated”到稳定恢复

热词里有“agent execution terminated due to error.”这条，说明很多人在跑Agent时都遇到过类似问题。我在项目里也遇到过：某次批量处理，跑到第87条的时候，OpenAI API突然报429限流错误，整个Agent循环抛异常，已处理的86条结果全部“视为整批失败”。

这个教训很深刻。我后来做了三项改造：

一是把每一条线索的处理状态写进SQLite数据库，单条处理成功就标记success，失败标记failed并记录错误原因，最后重试失败项，而不是整体回滚。二是所有调用都包了一层带重试的fetch，遇到429或5xx错误时指数退避重试三次。三是在Excel导出结果里加了一个“处理状态”列，让用户能直观看到哪几条失败了、为什么失败。

这三项改造之后，批量任务的稳定性提升了不止一个档次。我想说的是，Agent项目的容错设计，比前端的容错设计重要得多——前端一个请求失败了用户刷新一下就好，Agent批量处理跑十分钟，中途崩了，这个用户体验是不可接受的。

5.3 模型幻觉与业务谎言：真实企业场景下如何逼Agent“说实话”

前端开发有一个铁律：页面展示的数据必须来自接口，绝不能在前端写死。Agent开发里也有一条对应的铁律：Agent能查到的业务数据，绝不猜测，猜不到就明说“我不知道”。

我遇到过最严重的一次“幻觉事故”，模型在处理一条线索的时候，客户公司名写错了一个字。结果销售拿着这个“不存在的公司名”去联系客户，闹了个尴尬。当时模型给出的判断依据里赫然写着“该公司是某行业的龙头企业”——这句话完全是模型编出来的，业务规则里根本没有这一条。

从那以后，我在所有涉及业务数据的System Prompt里强制加了一句：“你只能基于工具返回的内容作判断，任何没有数据支持的观点都不得输出。如果信息不足，说明你缺少哪些信息、如何补充这些信息。”同时在后端做了“分级审核”：A/B类线索人工抽检，C类线索自动归档但附置信度分数。模型自己判断不确定的时候会输出“信息不足以判断等级”，而不是硬猜一个结果。

5.4 前端常见兼容性坑：SignalR、WebSocket与Agent流式输出

真实企业的Agent产品往往要跟工作台里的各种历史模块打通。我们这个项目就遇上过一次：客户想把Agent的“处理结果实时通知”接到他们的信鸽推送系统里，他们用的是SignalR。我一开始以为在前端接一下SignalR客户端就行，结果发现SignalR的Token认证规则和现有系统的JWT机制对不上，折腾了两天。

后来我直接转换了思路：不让前端直连SignalR，而是Agent后端自己作为SignalR Client连上企业通知服务，后端收到Agent处理完成消息后，再通过一个轻量WebSocket推送给前端页面展示结果。相当于在后端和前端之间加了一层很薄的适配层。这个方案一出来，前端只负责用原生WebSocket监听消息，一套代码解决，不用管企业里那套复杂的认证体系。所以Agent工程化里面的“连接”，往往是“多个系统之间做适配”，这一点前端经验同样管用。

6. 转型路线与学习规划：前端er怎么一步步变成Agent工程师

6.1 不要重新学Python：TypeScript全栈Agent是可行的捷径

很多前端看到Agent开发教程全是Python，就觉得自己得回去恶补Python。这里我给出完全不同的建议：如果你考虑企业应用落地，完全可以用TypeScript做Agent后端，Node.js生态足够成熟，OpenAI等各大厂商的SDK都有完善的TS版本，LangChain.js也在持续维护，还有很多轻量框架就是JS写的。

我在这个项目里选TypeScript的根本逻辑是：团队的人才结构、代码复用成本、招聘替代性。前端团队全员TS，Agent服务跟前端共用一套类型定义和lint规范，这种一致性带来的维护收益，比“Python生态里的某个库多那么一点功能”值钱得多。

6.2 从“会调用API”到“会设计Prompt”的三个进阶阶段

• 第一阶段（0~2周）：熟悉Function Calling的调用流程、消息结构、工具定义写法。把官方文档里的示例跑熟，能做“调用查询工具回答问题”的demo。这一阶段快速过即可，没必要深挖。
• 第二阶段（2~6周）：做一个端到端的真实小工具，比如“航班信息查询Agent”，模型负责解析意图，运工具负责实时查数据。重点练习：工具描述怎么写、参数校验怎么做、错误如何返回给模型让它自动修正。
• 第三阶段（6周以后）：回到自己的业务领域，找公司里最重复、最耗时、最依赖老员工经验的任务，试着用Agent拆解它。这一步最有价值，也最容易出成果。

6.3 Agent开发需要的前端技能迁移清单

为了扫盲，我整理了一个对照表，前端熟悉的概念在Agent开发里都有对应物。

这么一看，前端转Agent开发并不是在白纸上画画，而是把你已经熟练的那套工程方法，平移到一个更“不确定性”的运行时里。你要学的新知识，本质上是：怎么和大模型协作，怎么用工程手法去抑制概率性输出，怎么把业务经验转成结构化规则。这条路径比从零学后端更容易走通，因为前端天然具备现成的工程素养和产品直觉。

6.4 面试与升值：做过真实Agent项目之后，前端面试题都变味了

那些“2026前端面试题”“前端八股文”我后来反而看得少了。倒不是说基础不重要，而是经验比较之后，面试官更想听的是你怎么解决真实问题。当我能讲清楚“这个Agent怎么在成本只有600元/月的情况下，把销售线索清洗效率提高60%”，这个问题比任何一道算法题都能说明问题。前端基础当然还要扎实，但你的简历上多了“Agent项目实战”这块招牌之后，面试的层次完全不一样了，你不再是被挑题的人，而是主动展示结果的人。

7. 最后分享几个真正提升效率的开发习惯

结尾不打算写什么宏大总结，就分享几个我在这个项目里反复受益的具体习惯。

第一，Prompt和代码要一起提交到Git仓库。我每个工具的System Prompt都写在源码里，改动走PR，出现效果回退可以直接回滚。这比在网页端调Prompt然后截图存档靠谱一万倍。

第二，一定要有离线Mock数据。我没有把大模型API变成开发路径上的硬依赖。项目里准备了Mock模式，所有工具返回都从本地JSON读取。这样开发前端面板、联调接口、写单元测试都不需要实时调用API，既快又不烧钱。App进入Mock模式后，测试环境一天跑几百次也不用花一分钱。

第三，日志打点要足够丰富。我用pino记录每一次LLM请求的完整入参出参、每一步工具调用的耗时、最终结果是否符合预期。这些日志配合自己写的可视化面板，让很多看起来玄学的“怎么会这样”变成了可追溯的“原来是这一步出了问题”。另外我还会定期把模型犯错的案例收集起来，人工修正后做回归测试集，这个测试集会拉高系统的下限，也是后续换模型时的唯一底气。

最后再叮嘱一句：如果你真的打算走前端转Agent开发这条路，别囤课、别刷完整个框架的文档才动手。把身边任何一个真实的、哪怕是办公室内部的重复性需求拿出来，动手做一个小Agent，把它跑通、把它给别人用、把它的问题修完，这种一千遍教程都比不上的经历你自然就有了。