前端Leader的AI Agent 71天转型复盘：从RAG到Function Calling的工程实践

DAY71这个数字对我来说不是打卡游戏里的计数而是一个在职前端Leader在每天早上七点和晚上十一点之间硬挤出来的学习日志。我做了很多年前端团队不大但事情不少需求评审、排期、答疑、上线几乎把每个白天都切成碎片。今年年初我突然意识到如果不主动换一条增长曲线后面五年大概就是把前五年的经验重复一遍。于是我开始系统学习AI Agent到今天刚好71天终于能说一句这不是一时冲动而是一次认真的工程转型。这篇文字不是什么成功学日记也不是“零基础三个月转行”的速成指南。它是我从一个带过项目、写过组件、被业务反复折磨的前端Leader视角对过去71天学习AI Agent的一次完整复盘。我会把每个阶段踩过的坑、验证过的路径、算过的成本账都写出来。如果你也是前端也考虑过把AI Agent当成下一个技术方向这篇文章应该能给你省下不少试探成本。1. 前端Leader为什么转行学AI Agent先说说这三个真实原因1.1 前端的天花板不是技术是问题域太窄我在一线写代码的时间超过十年从切图到工程化从单页应用到大前端几乎所有前端技术浪潮都赶上了。但这两年我越来越清楚地感觉到一件事前端技术的复利效应在递减。组件化、微前端、可视化搭建这些东西做来做去解决的依然是“如何把界面更快更好地呈现给用户”。问题是当业务增长放缓产品形态稳定界面呈现这件事本身能创造的价值会越来越有限。作为Leader我每天的工作重心早就从“怎么写好一个组件”变成了“怎么让团队产出更稳定”。需求评审、排期、跨部门沟通、线上问题跟进这些事务性工作占据大量时间。我可以熟练地画架构图也能手写一套发布流程脚本但夜深人静的时候我发现自己已经很久没有解决过“业务真正疼”的问题。前端很靠近用户却很难深入业务决策。看板上的数据就摆在那里运营同事想从中得出结论还得靠后端写SQL、靠分析同学跑报表。这种隔阂一直在提醒我问题域太窄能力就没有杠杆。AI Agent给了我一个完全不同的角度。它不关心你写的是React还是Vue也不关心你的页面像素是否完美。它关心的是“一个目标能不能被自动拆解、执行、校验、交付”。这让我第一次感受到技术可以越过界面直接作用于业务流程本身。1.2 所谓转行其实是把前端能力迁移到新的载体上很多人听到“前端转AI Agent”会觉得跨度很大我自己在DAY1的时候也这么想。但真正学下来之后我的结论是这不是转行而是同一套工程能力换了一个载体。前端的本质是什么是把复杂的信息结构和交互逻辑转译成用户能理解、能操作的产品。AI Agent的本质是什么也是把复杂的业务目标和工具能力转译成模型可调用的流程与上下文。两者都需要做需求拆解都需要设计边界条件都需要处理异常分支。我这些年写前端锻炼出来的能力——对用户意图的敏感、对状态管理的执念、对异常路径的警惕——在Agent工程里全部用得上。我做的最快一个验证是把前端团队平时最烦的发布检查流程写成一个Agent。原来我们要在发布前人工核对有没有未提交的代码、有没有未通过的检查、接口变更是否通知下游。这些规则逻辑其实非常简单但要用代码写成一个“会主动巡检、会汇总结果、会提醒人”的小系统我发现自己前面十年的前端经验没有浪费。状态管理、异步流程、错误处理简直是为这场景量身准备的。所以想转行AI Agent的前端同行们完全可以放下“我是不是要从零开始”的焦虑。你要补的是大模型、Prompt、 Function Calling、RAG这些新知识但你的产品感、工程化能力、对用户体验的直觉都是别人短期学不走的优势。1.3 DAY71意味着什么已过冲动期还在继续学习这件事最怕的是头七天的热情和第七十天的倦怠。DAY71对我来说是一个有说服力的节点第1天我可能只是刷了几篇科普文章第7天我可能还在琢磨API怎么调第30天我差点因为一个诡异的Token报错放弃第60天看到网上层出不穷的新Agent项目又开始自我怀疑。但我还在写代码还在记日志还能把项目往前推这说明我已经不是靠新鲜感在撑而是把它当成了一个新的专业方向在经营。2. DAY1到DAY70完整学习路线我用七周从零跑通一个Agent2.1 前30天先把大模型当黑盒用起来别急着研究原理学习AI Agent最容易犯的第一个错误就是上来就啃Transformer论文、注意力机制、反向传播。不是说这些不重要而是对一个在职的、还有业务压力的人来说这个切入点太容易劝退。我前30天只坚持一条原则先把大模型当黑盒把它当成一个“很聪明但偶尔会犯糊涂的外部服务”尽快跑通所有基础的API调用。我第一周主要在做最笨的事注册、鉴权、发起一次对话请求然后处理返回。接着开始研究消息结构。很多人不重视这个其实system、user、assistant这三层消息结构决定了你后面能不能做出稳定效果。我的理解是system放的是这个AI的角色、任务边界和输出格式要求user放的是当前用户的诉求assistant放的是模型自己之前生成的内容。多轮对话就是不断把新的user消息和旧的assistant消息拼进同一个数组再发过去。第二三周我开始处理流式输出、超时重试、并发限制。这一步相当磨人。你会发现一个接口在不同网络环境下表现差异很大你以为模型卡住了其实是连接超时或者服务端限流。我当时用TypeScript写了一个简单的封装函数把“发请求、收流、解析完整文本、自动重试”这几件事包进去。这个封装后来成了我自己Agent项目的底层模块虽然简陋但每一行都是自己踩坑踩出来的。第四周我把目标收敛到一个能用的东西上一个命令行工具。给它一段需求描述它调用大模型返回一份结构化的前端任务拆解包括改动点、涉及组件、风险项。功能很糙但第一次真正感受到“模型代码”能替代一部分管理动作时我被震到了。这个阶段我没有碰任何Agent框架因为我知道如果连裸API的脾气都没摸清框架反而会成为黑盒。2.2 中间20天补原理才敢动手搭Agent工程前30天让我有了一些手感但也让我很不踏实我不知道为什么同样的Prompt有时候返回稳定有时候乱飘不知道Token消耗为什么这么快不知道把一堆文档塞给模型为什么会变成一本正经地胡说八道。第31天开始我给自己补了大概20天的原理课。最先补的是Token和上下文的关系。我印象很深有一次我向模型提问仅仅因为历史消息没做裁剪单次请求的Token数就翻了四倍响应速度明显变慢费用也肉眼可见地涨。Token不是“字数”而是模型内部的一种基本单位。这也解释了一个常见现象你问一个长问题时它突然“变笨”因为前面的长文本把它有限的上下文窗口占满了。搞懂这个你才会主动去控制每次请求到底塞了多少内容。接着是Embedding和向量检索。我当时的实用场景很明确公司内部有几十份操作文档我想让模型回答“某某功能怎么配置”。如果每次都把全部文档塞进Prompt既不现实也浪费。用Embedding把文档切成小块并转成向量用户提问时先把问题转成向量在向量库里做相似度检索把最相关的几段取出来拼进上下文这个流程就是RAG的雏形。我拿这个思路做了一个小工具把团队历史故障文档做好索引运维和开发同学提问时它能自动给出“可能是哪里出了问题、上次是怎么修复的”。效果谈不上惊艳但至少回答有出处我可以做到“答案后面附上引用来源”。这一步我第一次理解了为什么RAG是Agent落地中的重要拼图因为模型的知识有截止时间但企业内部的实时知识必须通过检索喂给模型。2.3 后20天从写Demo到搭Agent骨架前50天做完我还在跟单轮问答较劲。真正让我觉得自己在“做Agent”而不是“做大模型调用工具”的是后面这20天。我开始研究Function Calling也就是让模型在回答过程中主动声明“我需要调用某个工具参数是什么”而由你的代码去实际执行这个工具再把结果返回给模型。这个机制太关键了。它把模型从一个“只能输出文字的系统”变成“可以操作外部世界的系统”。我第一次实现的时候模型说“我要查天气”我的代码就去查天气接口然后把结果拼回去模型再基于真实天气数据生成一段像模像样的回答。那一刻我很清楚这就是Agent的基本单元。随后我逐步加上循环模型提出目标、拆解步骤、调用工具、观察结果、修正下一步。一个完整的Agent骨架就是“目标、工具、记忆、执行循环”。我开始理解那些网上流行的Agent项目为什么能做那么多看似神奇的事其实底层都是这个循环只不过它们加了更多工具、更多记忆机制、更多包装。在这个阶段我也开始看一些Agent框架的设计思路。我故意没有直接用框架而是先看它帮你封装了什么Tool的注册方式、Memory的存储策略、Orchestrator的执行顺序。看完之后我再用几十行原生代码去复刻一个最小版本。这个“复刻”的过程非常值因为你会意识到框架解决的是通用问题而你的业务场景往往需要定制化裁剪一旦没有底层理解出了问题就只能靠猜。3. DAY71实操复盘一个带记忆的数据分析Agent是怎么卡壳的3.1 当前任务做一个“能记住上下文”的对话式数据分析Agent71天这个节点我在做的项目是一个面向运营同事的对话式数据分析Agent。场景很具体运营同学在后台输入“上周每天的新增用户是多少”或者“用户从注册到下单的转化漏斗在哪一步流失最多”Agent自己把自然语言转成SQL查数再把结果用自然语言呈现出来。我选这个场景是因为它同时踩中了几个核心点第一这是真实高频需求第二它需要理解数据库Schema第三它需要调用执行SQL的工具第四多轮对话中用户很可能会追加条件比如“不算测试账号”“只看iOS端”这对记忆管理是个考验。作为一个前端Leader我太喜欢这种能直接嵌入业务场景的题目了。3.2 具体实现工具注册、上下文裁剪、多轮记忆我先处理的是工具层。Agent需要两个核心工具一个是查表结构一个是执行SQL。为了让模型不直接面对满屏的库表信息我维护了一份字段字典提前把常用表名、字段名、注释、常见筛选值整理好。用户提问后Agent第一步是调用“查表结构”工具只检索最相关的几张表和字段再把结果拼进上下文。这里有个关键设计SQL执行工具加了安全护栏。账号是只读账号SQL强制加LIMIT超时设置为10秒禁止执行INSERT、UPDATE、DELETE。对内部工具来说安全措施做得再多都不为过。如果模型生成了超出限制的语句工具会返回一条错误说明模型根据错误信息自己修正。多轮记忆是我这次的主攻方向。一开始我图省事每轮都把完整对话历史重放给模型。结果第5轮对话的Token消耗就已经很难看而且模型会被早期错误信息带偏。我换了一个思路维护一个结构化状态记录“当前已经确定的筛选条件”和“用户最新问题”。每次请求只把状态摘要和当前问题发给模型不再重放全部历史。效果立刻不一样。下面是我当天写的核心循环用TypeScript写的跑通之后很有成就感interface AgentState { filters: Recordstring, string[]; lastQuestion: string; lastResult?: string; } async function runAnalysisAgent(question: string, state: AgentState) { const plan await client.chat({ role: system, content: readSystemPrompt(), role: user, content: buildContext(question, state), }); for (const step of plan.tools) { if (step.name query_meta) { const metas await queryFieldDict(step.arguments); return client.chat({ role: user, content: formatMeta(question, metas) }); } if (step.name execute_sql) { const rows await executeReadonlySql(step.arguments.sql); state.lastResult summarizeRows(rows); return client.chat({ role: user, content: state.lastResult }); } } }抽象思路不复杂实际调起来问题不少下面单独说。3.3 当天踩的坑与排查过程第一坑模型生成的SQL字段名完全不对。它把user_id写成了uid把created_at写成了create_date。原因很好理解大模型训练数据里常见命名和小写风格跟我们的库表完全不一样。我的解决方案是两步走一是在查表结构工具返回的字段字典里明确标出“这个字段在业务里一般怎么称呼”“在哪个页面上叫什么”让模型有依据二是要求模型在生成SQL前先把涉及到的表名、字段名列出来跟字典做个核对确认无误再执行。这样虽然多了一步但准确率提升非常明显。第二坑多轮对话状态下Token膨胀很快。我把历史记录全部重发之后第五轮已经超过两万个Token。排查时发现每一轮都带着上一轮完整的SQL结果这些结果特别占空间。我把它改成“只把SQL结果摘要成三行关键数据”比如总数、均值、最大最小值。对于不涉及数值的查询就只保留“查询成功未返回内容”这个状态。这一刀下去上下文长度直接砍掉了四分之三。第三坑Function Calling的循环重试。某一次工具返回SQL执行超时模型没有换思路反而用同样的SQL重试了三次浪费了时间和Token。我在排查日志里看到这个循环才发现我的循环逻辑里少了“最大迭代次数”和“错误分级”。后来我规定同一个工具错误最多重试两次第二次失败后模型必须换一种方案比如改写SQL或者直接向用户说明当前无法查询。这个限制需要在系统提示里写清楚代码也要在循环层做硬保护不能只依赖模型自觉。排查这类问题的心法是让Agent的每一步都可观测。我习惯在关键节点打结构化日志当前问题是什么、调用了哪个工具、工具返回了什么、下一次模型请求的上下文有多长。有了这些中间产物定位问题就不是玄学而是像以前调前端接口一样看请求、看响应、看状态。4. 模型、框架和成本控制Leader视角的工具选型账本4.1 模型选择API、开源、本地推理怎么平衡作为一个管理者我选模型的时候会先问三个问题数据能不能出内网性能要求是多高单位成本预算是多少这三个问题的答案决定了选型方向。如果业务场景涉及用户隐私或内部敏感数据最稳妥的做法是把数据本地化。这种情况下开源模型加私有化部署就是必选项。哪怕模型效果比一线商业API差一点但“数据不出域”这一条就值回运维成本。反过来如果是一些相对通用的办公场景比如写周报、拆需求、翻译文档那直接调用商业API反而更划算因为自建一个高性能推理服务的前期投入可能要分摊到大量调用上才能回本。我个人的策略是“分级用模型”简单分类、信息抽取、意图识别这类任务用参数小、成本低的模型复杂推理、代码生成、多步规划这种任务才用能力更强的模型。Agent内部也可以分区比如第一步识别用户意图用便宜模型后面的SQL生成和结果解释用旗舰模型。这个思路跟后端做技术选型一样不存在一个万能方案只有与场景匹配的取舍。4.2 框架用不用我的取舍标准是复刻一遍再看缘分关于Agent框架我的态度经历了一个从怀疑到理解再到怀疑的循环。刚开始我觉得框架实在太方便几行代码就注册好工具和记忆后来发现框架帮你隐藏了大量细节一旦遇到依赖报错、状态冲突、自定义工具不生效排查成本极高现在我处于“能少用就少用用也要先理解原理”的阶段。我的判断标准很简单如果一个功能我用原生代码五十行内能写出来那我就不引入框架。比方说一个简单的“模型判断意图、调用工具、返回结果”的管线最核心的部分可能只要几个函数犯不着为了它去学一套抽象概念。但如果是多Agent协作、复杂记忆策略、并发任务调度这种高复杂度场景我会认真考虑要不要站在成熟框架的肩膀上。关键不是“用不用”而是“你对它的运行机制有没有把握”。没有把握的东西一旦出问题就是深夜流调现场。4.3 给团队算一笔账Token、缓存、按需调用成本控制看起来是管理和财务的事但工程上如果设计不当它会变成一笔完全失控的费用。我给一个后台数据分析Agent算过一笔账。一次完整查询请求系统提示词大约要消耗两千个Token查表工具返回的字段描述大约三千SQL执行结果如果全量塞回去又是五千再加上历史状态和模型输出一次对话轻松过万。如果一个运营团队有二十个人每人每天问二十次一个月下来成本就会变成可观的数字。所以我在工程层面加了几个降本设计。第一是缓存高频问题的SQL结果缓存十分钟相同问题在缓存有效期内不再调用模型生成Embedding结果也做持久化避免每次重复计算。第二是工具结果摘要把SQL结果裁剪成关键统计值再送回模型。第三是限制输出长度模型生成的自然语言答复控制在几十个Token以内只回答结论和关键数据不做长篇解释。从成本分摊角度我建议每个Agent项目在初期就接入用量追踪。谁在调、调了多少次、平均Token数是多少、哪个场景最烧钱这些指标必须一眼能看到。否则等月底账单出来再心痛就来不及了。5. 给同样想转行AI Agent的前端同行的三个误区和五点建议5.1 最容易掉进去的三个误区第一个误区是认为Agent就是写Prompt。我见过不少前端同学学习一周就开始研究各种花哨的提示词技巧以为“提示词写得好Agent就强”。实际做下来Prompt只是入口Agent的稳定性来自工程化工具的边界是否清晰、数据准备是否充分、错误处理是否健全、链路是否可观测。同样一个Prompt在有严格工具约束的工程里和裸奔的对话框里表现天差地别。第二个误区是只收藏不实践。网上的Agent教程、框架文档、案例分享多得看不过来但如果你没有亲自把一个小项目跑到线上所有的知识都只是“看过”。我会强迫自己每个阶段都要交付一个能用的小东西哪怕只是命令行工具只要它真实运行过就能引出大量书本上看不到的问题。第三个误区是盲目追求新工具。每隔一阵子就有新的Agent框架、新的模型、新的“神器”出来。如果你总在追赶最新的玩具就很容易陷入“每天学新东西但没一个深入”的循环。我的做法是锁定一个主线项目所有新技术都在这个项目里验证验证通过才引入。主线项目是一根锚能帮你过滤掉很多噪音。5.2 学习节奏和精力管理在职学习最难的不是技术而是精力。我带团队的时候白天几乎每半个小时就被打断一次根本不可能进入深度状态。我的节奏是工作日的晚上固定留出90分钟给Agent项目周末至少留出半天做整块开发。碎片时间用来读文档、看案例、想方案但是写代码这种需要连续思考的事情必须放到不被打扰的时间段。另外一个很有效的策略是把学习目标拆小。每个晚上只给自己定一个不超过一小时就能验证的任务比如“给工具增加一个超时处理”“把系统提示词里的一层逻辑抽出来”。完成一个小任务的正反馈比追逐一个宏大目标更能支撑长期坚持。5.3 让学习成果落地作品集、复盘和公开输出我一直鼓励身边的同事把学习过程公开记录下来。这不是为了展示自己而是因为“讲清楚”是“理解透”的最好验证。每周我都写一篇技术复盘内容包括这周做了什么、遇到了什么问题、怎么排查的、结论是什么。回过头看这些笔记比很多课程都更有价值因为它们记录了我当时的真实思考而不是事后整理的光鲜总结。作品集也不需要多高级关键是要能展示完整链路。哪怕是一个“日报自动生成Agent”只要它能调用外部数据、处理用户输入、生成结果并配置了错误处理就已经比一百个Demo都更有说服力。面试官或者合作方想看到的不是你背了多少概念而是你是否有把一个不确定的东西一步一步变成确定工程的能力。6. 写在DAY71之后我还在继续的原因如果要说这71天最大的变化我觉得不是技术上的而是我对“能力边界”的理解变了。以前我是看着浏览器窗口想问题现在我是看着一个目标、一组工具、一段上下文在想怎么让系统帮我完成闭环。前端Leader的经验没有浪费它只是被重新组装了。我还会继续学下去并且接下来的方向很明确把数据分析Agent从内部Demo做成一个真正有人天天在用的工具。让运营同事真的通过对话拿到日报让开发同学真的通过提问定位线上问题。这个过程肯定会碰到更多麻烦但Day71教会我的事情是不要怕麻烦怕的是你把麻烦当成尽头。