2. 写在DAY68一个前端Leader为什么要折腾AI Agent今天是我记录自己从在职前端Leader逐步转向AI Agent方向的第68天。前端开发干了八年多从jQuery时代一路走到Vue3、微前端qiankun、前端组件库搭建带过团队、扛过H5活动、啃过前端安全、处理过worker上传大文件这类边角料问题说实话前端这个行当的生存空间正在变得越来越微妙。先说一个最直观的感受现在打开招聘软件前端岗位的要求里出现“AI Agent”“大模型应用”“LangChain”这类词条的频率比两年前高了不知道多少倍。而另一方面AI Agent开发这个方向正在以一种极其粗暴的方式改写软件工程的游戏规则——以前我们写代码是“人指挥机器机器执行逻辑”现在写Agent是“人定义目标模型拆解任务工具负责执行”。这两套思维模型的差异比React和Vue的差异大得多。我的一个很直接的判断是前端开发者转AI Agent不是跨界而是顺势。因为Agent的落地场景——对话界面、状态反馈、流式渲染、工具调用的UI化——恰恰是前端最擅长的领域。但光有前端那套还不够Agent的核心能力在于“编排”和“自省”这需要一套全新的思维框架。这篇文章是我DAY68的阶段总结把这段时间踩过的坑、想通的事、验证过的方案一次性写清楚。内容涵盖为什么前端背景适合做Agent、Agent的主流架构拆解、我自己搭的一个实际案例包含代码级细节、以及大量实测中遇到的坑和排查思路。全文没有“手把手教你三天转行”的鸡汤只有我在Day 1到Day 68之间真实经历的技术判断和工程取舍。3. 内容和设计思路拆解前端背景转AI Agent的真实优势与思维陷阱3.1 你以为前端转Agent是“降维”其实是“换维度”很多前端同行觉得AI Agent不就是调API、拼提示词吗这活儿看起来比写组件简单多了。这个认知是我前两周最大的误区。先说前端这边有什么优势。Agent落地必然要有一个交互层不管是网页端的对话面板、管理后台的任务编排界面还是移动端的语音交互入口这些都是前端的活。我在团队里做过实时语音转写的前端适配做过基于Web Worker的大文件上传做过基于qiankun的微前端治理这些经验在Agent应用里全部用得上——尤其是流式输出。Agent思考是流式的工具调用状态是流式的LLM吐字也是流式的没有前端把这块捋顺后端再强用户都感受不到。但真正的门槛不在这里。Agent的难点在于让模型“正确地做决策”。前端开发的核心逻辑是“确定性的”——你给我输入我保证输出符合预期。而Agent的核心逻辑是“概率性的”——模型每一步决策都可能偏离目标你需要在架构层面不断纠偏。这两者之间差的不是技术栈是思维方式。我自己最大的转变是写代码从“追求正确”变成“追求容错”。以前写一个函数我考虑的是边界条件、异常分支现在写一个Agent我考虑的是“假设模型这一步理解错了系统如何自愈”。这个思维模型的切换比学任何框架都费劲也是这68天里最核心的收益。3.2 为什么选择“Python 前端H5”这套组合而不是all in某个重框架这段时间我调研了市面上主流的Agent开发框架包括LangChain、LlamaIndex、AutoGen还有基于Rust语言写的Agent框架比如Solana和Candle生态里的一些项目。各家都在抢生态位但说实话框架的迭代速度太快今天的最佳实践明天可能就被废弃。我最终选择了一条比较务实的路线核心逻辑用Python写但交互层和业务接入全部走前端H5服务端只暴露一套HTTP接口。选择Python的原因很简单生态最成熟不管是接大模型API、做文本切分、向量检索Python的工具链都是最完整的。而交互层用前端H5是因为Agent应用的核心场景是“人机协同时刻在发生”——用户需要实时看到Agent的思考过程、工具调用结果这种体验只有H5页面能低成本实现。这里有个细节值得说说我没有直接使用LangChain这类重框架而是自己手写了一个轻量的Agent调度核心。原因有三条框架抽象层太厚出了问题排查成本高尤其对于我这种半路出家的人黑盒越少越好Agent的开发范式远没稳定自己写核心可以随用随改不会被框架的设计哲学绑住手脚我在团队里是Leader这个转型迟早要落地成团队方案自研核心意味着团队未来可以完全掌控技术栈当然如果是从零开始的个人项目直接用LangChain可以省很多事。这个选择没有对错看你的目标是“快速出活”还是“深度掌控”。4. Agent的核心架构拆解从“模型调用”到“自主决策”的五个关键模块4.1 Agent不是“聊天机器人”它是“目标驱动的自主系统”这是我在前两周最大的认知修正。很多人以为Agent LLM API 提示词 上下文然后就能自动干活了。实际上一个能真正落地的Agent至少需要五个模块协同工作模块职责类比模型接入层管理不同LLM的调用、参数、API密钥相当于前端的网络请求层上下文管理层维护短期记忆和长期记忆处理Token上限相当于前端的全局状态管理但比Vuex复杂得多工具调用层定义Agent可以使用的函数/API并解析模型输出相当于前端的接口联调层决策编排层决定下一步执行什么动作、是否需要追问用户相当于前端的路由系统结果验证层检查操作结果是否符合预期决定是否重试相当于前端的表单校验但维度不同其中最容易忽略的是“结果验证层”。写前端的时候一个接口返回错误你弹个Toast展示给用户就够了但在Agent里工具执行失败后Agent需要自己判断是重试、换工具还是修改计划。这一步没有做好Agent就会陷入“自说自话”的死循环。4.2 Token到底是什么——“Agent的记账单位”决定你的成本焦虑热词列表里有“ai agent token是什么意思”这个问题我Day 15才彻底搞明白。Token是模型处理文本的最小单位。一个Token大约相当于0.6-0.7个英文单词中文字符则通常1-2个字符占一个Token。你发给模型的所有内容系统提示词、用户消息、历史记录加上模型返回的内容全部按Token计费。但这个问题的关键不在于“Token是什么”而在于“Agent是Token消耗大户”。一次简单的小红书自动发消息任务看起来只是让Agent写一段文案实际上它可能经历了理解任务指令→规划步骤→生成文案→检查文案质量→确认发布→处理发布结果每个环节都要调用模型一轮下来消耗几千Token是家常便饭。在实践中我总结出一个Token管理公式单次任务Token消耗 ≈ 系统提示词Token数 历史上下文Token数 工具定义Token数 模型输出Token数控制Token的核心手段只有两个压缩历史上下文、精简工具定义。前者靠“滑动窗口关键摘要”后者靠“只暴露当前任务需要的工具”。这两个手段后面在案例里会具体展示。4.3 记忆系统Agent能不能“记住你”取决于你怎么设计上下文前端开发里有LocalStorage、有Vuex/Pinia但Agent的记忆比这复杂得多。原因很简单LLM的上下文窗口是有限且昂贵的你不能把所有历史都塞进去需要在“记住什么”和“忘掉什么”之间做决策。我这里用的是两级记忆架构短期记忆在当前任务上下文窗口内保留完整的对话历史和工具调用记录任务结束后清空。它的作用是保证当前任务的连贯性。长期记忆通过向量数据库我用的是轻量级的Chroma存储用户偏好、历史任务结果、关键结论。新任务启动时通过相似度检索把相关的长期记忆注入短期上下文。这个架构等价于前端里的“组件局部状态 全局缓存”但有一个关键差异前端缓存失效顶多是数据旧了Agent记忆如果注入错了模型的决策会整体跑偏。所以长期记忆的检索结果我通常会让模型先确认“这些记忆是否与当前任务相关”而不是直接无脑注入。5. 实操案例从零搭一个“让小红书自动发消息”的Agent5.1 场景定义与需求拆解热词列表里有“ai agent, 让小红书自动发消息”这其实是一个非常好的入门案例因为它的链路足够短理解任务→生成内容→调用接口→反馈结果但同时又涉及Agent最有代表性的“工具调用”环节。我的最终目标是给Agent一句“帮我在小红书上发一条关于前端学习笔记的帖子”它能自动完成内容生成、内容审核、接口发布、结果反馈全部流程。先拆解成技术步骤接收用户的自然语言指令从指令中提取关键参数内容主题、发布账号、发布时间调用内容生成工具生成符合小红书风格的文案标题、正文、话题标签调用内容审核工具检查敏感词和平台规范调用发布接口工具执行发布动作返回发布结果给用户这六步里只有第3步和第4步需要调用大模型其他步骤靠传统代码就能完成。这就是Agent开发的一个核心思想能用确定性代码解决的就不用模型去猜。5.2 核心代码实现一个轻量Agent调度核心先看这个Agent最核心的调度逻辑我用Python写了一个很简化的版本# agent_core.py import json from llm_client import call_llm from tools import TOOL_REGISTRY def run_agent(user_message, toolsNone, max_iterations5): Agent主循环决策→执行→观察→再决策 messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_message} ] for step in range(max_iterations): # 第一步让模型决策下一步动作 response call_llm( messagesmessages, toolstools or TOOL_REGISTRY, # 把可用工具的定义传给模型 ) content response[content] # 第二步如果模型输出的是普通文本说明任务完成 if content and tool_calls not in response: return content # 第三步如果模型要求调用工具解析并执行 tool_calls response.get(tool_calls, []) for call in tool_calls: tool_name call[function][name] tool_args json.loads(call[function][arguments]) # 执行工具 result TOOL_REGISTRY[tool_name](**tool_args) # 把工具执行结果反馈给模型 messages.append({ role: assistant, content: , tool_calls: [call] }) messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(result, ensure_asciiFalse) }) # 超出最大轮次强制返回 return 任务执行达到最大迭代次数未完成全部步骤这段代码的核心就是“工具调用循环”模型不直接执行动作而是输出一个结构化的“工具调用请求”由代码去真实执行再把结果返回给模型继续决策。这里面有一个前端背景的人很容易看出的设计messages就是这个Agent的“全局状态”每一轮思考和工具执行都往里面追加消息相当于前端的action日志。而判断“任务是否结束”完全看模型是否不再发起工具调用这个语义非常像HTTP重定向——如果响应里没有Location工具调用你就认为请求终止了。5.3 工具定义与注册让模型“知道”它能干什么工具定义是Agent开发里最考功力的部分。模型本身并不知道你提供了哪些能力你需要把每个工具的名称、描述、参数结构告诉它它才能在你需要的时候“想起来”调用。我自己实现了一个简单的工具注册机制# tools.py import datetime import json TOOL_REGISTRY {} def register_tool(name, description, parameters): 装饰器把函数注册为Agent可用工具 def decorator(func): TOOL_REGISTRY[name] func return func return decorator def get_tool_schemas(): 生成模型需要的JSON Schema工具定义 schemas [] for name, func in TOOL_REGISTRY.items(): # 从注册信息生成工具定义 schemas.append({ type: function, function: { name: name, description: func._tool_description, parameters: func._tool_parameters } }) return schemas register_tool( generate_post_content, 根据用户提供的主题生成一条适合小红书发布的文案包含标题、正文和话题标签, { type: object, properties: { topic: {type: string, description: 内容主题}, style: {type: string, enum: [干货分享, 日常记录, 经验总结]} }, required: [topic] } ) def generate_post_content(topic, style干货分享): # 这个函数内部会调用大模型生成文案 # 但对外表现为一个普通Python函数 ...为什么工具定义要这么讲究因为模型对工具的使用完全依赖描述文本。我在实测中发现工具描述里带上“什么时候用这个工具”“不用会有什么后果”这类引导性信息模型选对工具的概率会显著提高。这跟前端写组件时的“注释文档”道理相通但是重要程度高一个量级。5.4 让Agent学会“追问”最简单有效的纠偏机制实际操作中我发现一个很实用的小技巧在系统提示词里显式告诉Agent“当任务信息不完整时先向用户追问不要瞎猜”。比如用户说“帮我发一条小红书”但没有说发什么主题。没有这个限制时模型会自作聪明地编一个主题然后直接发布。这在前端思维里是不可想象的——哪个正经的前端会在表单没填完的情况下直接提交但模型就会。在系统提示词里加一段话效果立竿见影如果用户的指令缺少关键信息比如内容主题、目标账号、时间要求你必须先向用户提问确认 不得假设或自行补充缺失信息。提问时一次问完所有需要确认的问题避免来回对话消耗Token。加上这个约束后整个Agent的行为逻辑立刻变得“可靠”了很多。这个经验可以推广到任何Agent项目你越是不给模型自由发挥的空间它的输出就越稳定可控。这和前端里“表单校验严格一点脏数据就少一点”是一模一样的道理。6. 前端视角下的Agent落地从“数据展示”到“意图交互”6.1 为什么要用H5做Agent的交互层我在团队里做过几个Agent的落地项目最深的体会是Agent的后端能力再强没有好的交互前端用户根本感知不到它的价值。举个例子Agent在执行工具调用的过程中往往需要几秒甚至几十秒的等待时间。如果你只给用户一个“正在处理...”的loading页用户大概率会以为系统卡死了。但如果你用前端把Agent的思考过程实时展示出来——比如“正在分析任务...”“正在生成文案...”“正在检查敏感词...”“正在发布...”用户的耐心会显著增加。这种流式状态展示本质上是把串行等待拆解成有进度的过程技术上其实就是EventSource或WebSocket推送 前端局部刷新!-- agent-status.vue 简化版 -- template div classagent-status div v-forstep in steps :keystep.id classstep-item span classstep-icon :class{ active: step.status running } {{ step.status done ? ✓ : • }} /span span{{ step.label }}/span /div /div /template script setup const props defineProps({ agentId: String }) const steps ref([]) const ws new WebSocket(wss://your-backend/agent/${props.agentId}/status) ws.onmessage (event) { const data JSON.parse(event.data) // data: { type: tool_call, name: generate_post_content, status: running } steps.value.push({ id: data.name, label: toolLabel[data.name], status: data.status }) } /script我实测下来的前端友好设计方案是后端把Agent每一步的动作推送给前端前端只负责展示不做任何业务判断。这样前端逻辑保持极简Agent的核心决策全部留在后端两边各干各擅长的活。6.2 流式输出从“等完整结果”到“边算边渲”如果你用过ChatGPT一定注意到回答是逐字蹦出来的。这种“流式输出”体验对Agent应用来说同样重要甚至更重要——因为Agent的输出往往分好几个阶段每一阶段的产出都值得让用户即时看到。流式输出的前端实现并不复杂核心就是使用fetch的ReadableStream接口逐段读取// 流式接收Agent返回内容 async function streamAgentResponse(url, body) { const response await fetch(url, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(body), }); const reader response.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); // 按换行符切分SSE格式的数据块 const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { if (line.startsWith(data: )) { const payload JSON.parse(line.slice(6)); // appendToContent(payload.content); updateUI(payload); } } } }这里有一个比较隐蔽的坑SSEServer-Sent Events数据流不能保证每次网络包都恰好以一个完整的data:行结束所以必须做“缓冲区按行切割”的处理否则在数据量大时很容易出现JSON解析错误。这个坑我当时排查了很久最后发现是缓冲区处理不严谨导致的。6.3 前端安全Agent应用的新威胁面热词里有“前端网络安全”“怎么在前端进行防止爬虫”这些话题说实话在传统前端语境下这类防护基本是“防君子不防小人”。但在Agent应用里安全问题的性质变了。为什么因为Agent应用多了一个核心资产你的工具调用权限。如果攻击者通过XSS注入一段恶意指令诱导Agent去调用某个危险工具后果可能比单纯窃取用户数据严重得多。我在自己项目的交互层做了几道基础防护对用户输入做明确的“意图识别”标记区分“给Agent的指令”和“给工具的参数”工具层的权限校验做在后端前端永远不直接持有敏感工具的调用凭证对Agent执行结果做敏感信息脱敏日志中隐藏API Key等关键信息这些做法算不上高深但很多从传统前端直接转Agent开发的人会忽略。因为传统前端的安全职责是“保护页面”而Agent前端的安全职责是“保护Agent的能力边界”这两者需要一起设计不能等出了问题再补。7. 实际踩坑记录Token超限、无限循环与“幻觉式决策”7.1 最崩溃的一次Agent陷入“工具调用死循环”大概在Day 40左右我做的Demo突然出现一个诡异的现象Agent在调用“内容审核”工具时审核结果返回“存在疑似敏感词”Agent决定修改文案后再次调用审核结果还是返回同样的问题于是它继续修改、继续审核……循环了十几次都没有跳出Token消耗直接爆炸。后来定位到的原因很有意思审核工具的返回值里写的是“存在疑似敏感词XX”但没有告诉Agent具体是哪个词。模型看不到具体问题就只能瞎猜、瞎改、瞎再审形成一个死循环。解决方案分两步修改审核工具让它在返回值中明确给出“具体哪个词、为什么不合格”在系统提示词里加一条“同一工具连续调用超过3次仍未成功时必须停止尝试并向用户汇报失败原因”这个教训非常深刻你给模型反馈的信息质量直接决定了它的决策质量。就像前端调试时console.log打印的信息不完整你怎么也定位不到bug一样。7.2 Token超限历史记录太多导致直接报错另一个高频问题是上下文超限。当任务比较复杂、工具调用次数多时messages数组里堆积的内容很容易超过模型的上下文窗口比如8K或32K Tokens请求直接报错。我的处理思路是“摘要压缩法”def compress_messages(messages, max_tokens6000): 当消息过长时把早期对话压缩成摘要 total_tokens estimate_tokens(messages) if total_tokens max_tokens: return messages # 保留最近的完整消息 recent messages[-8:] # 把更早的消息压缩成摘要 early messages[:-8] summary summarize_messages(early) # 调用模型生成摘要 return [ {role: system, content: SYSTEM_PROMPT}, {role: system, content: f早期的对话摘要{summary}}, ] recent这个方法等价于前端里的“虚拟滚动”——只渲染可视区域的内容超出可视区域的DOM节点被释放从而保证性能。Agent的记忆管理也是一样的逻辑窗口只保留最近最相关的信息远处的信息压缩成摘要需要细节时再通过检索找回。7.3 “幻觉式决策”模型觉得自己干了活实际上什么都没干这是我遇到的最“玄学”的问题模型在响应中输出了“已调用发布工具内容发布成功”但实际上工具根本没有被执行。原因在于模型确实生成了tool_calls但前端代码解析时没处理到位恰好跳过了工具执行部分而模型自己并不知道这个“跳过”。这个问题说到底是模型生成和代码执行之间的“状态不同步”。我的排查思路是在工具执行返回结果后给模型回传的不只是“执行结果”还要带上“执行状态码”{ status: success, result: ... }如果工具没执行就回传{ status: skipped, result: null }同时在系统提示词里明确告知模型“只有收到status为success的工具执行结果才能向用户确认步骤已完成。”加上这层约束后“假成功”的情况基本绝迹了。7.4 前端适配问题讯飞实时语音转写与Agent结合时的格式冲突热词里有一条“讯飞实时语音转写大模型前端适配”这个我恰好做过。语音转写拿到的中间结果和最终结果格式不同如果直接塞给Agent当用户指令很容易出现语义割裂。我当时的处理方式是在前端做了一层“指令熔断”只有当语音转写稳定停顿超过1秒且文本长度大于某个阈值时才把这段文本作为完整指令发送给Agent。否则只做预展示不触发Agent调用。这其实暴露了Agent应用前端的一个常态性挑战真实世界的输入是多模态、不规范的你不能假设用户总会给你结构良好的文本指令。8. 一些体制化的思考前端Leader带团队转Agent的实操路线8.1 不要全员转型先搞“尖兵模式”作为团队Leader我面临一个现实问题团队里有人对Agent感兴趣也有人觉得这是泡沫。我的处理方式是搞“尖兵模式”——找两三个对Agent真正有热情、学习能力强的同学先形成一个小型攻坚组用业余时间把核心技术路径打通然后产出内部工具和文档再逐步向全团队推广。这个策略的好处有三个控制转型成本不会因为全团队扑上去而耽误现有业务形成内部标杆用实际产出说服观望者积累的经验文档比外部课程更贴合团队的实际技术栈8.2 前端团队的Agent学习路径建议如果你也是一名前端开发者正在考虑要不要往Agent方向靠我给出我走过一遍后觉得可行的路径第一周理解Token机制和上下文窗口概念手动调用一次大模型API搞清楚请求和响应结构第二周实现一个最简单的“模型工具调用”循环就是上文那个run_agent函数级别不要碰框架第三周做一个垂直场景的小Demo比如“自动生成周报”“自动整理收藏夹”一定是要能用起来的实际需求第四周研究一下记忆管理和上下文压缩方案把Demo升级成多轮任务后面持续做把Agent接入现有的前端项目里做成一个真实可用的功能说句实在话转Agent这件事技术门槛并没有想象中高但思维门槛确实存在。前端的逻辑是“写死逻辑保证不出错”Agent的逻辑是“写活逻辑允许出错但能自纠”。这两种模式没有谁高谁低但在不同业务场景下有完全不同的适用性。8.3 我还在犹豫的几件事不要看我把经验写得很轻松实际上Day 68的我依然有很多没想明白的问题。比如Agent的评测体系怎么建立——前端有单元测试、E2E测试但Agent“输出质量”怎么量化再比如多Agent协作时的任务分配机制目前市面上的方案都还不够成熟。还有浏览器端的本地推理方案WebLLM这类项目看起来很美但实际跑起来性能还是不够理想。这些问题我打算在后面的Day 80、Day 100阶段陆续攻克到时候再回来更新笔记。但至少到目前“Web UI即Agent的交互层”“工具定义质量决定Agent上限”“前端人是天生的Agent交互设计师”这三个判断我已经通过自己的项目验证过了——它们不是空谈。如果你也是前端同行也在观望Agent方向我的建议只有一句话不要等“准备好”再开始直接拿你手头最重复、最机械的一个小需求试着用Agent去做做完你再判断这条路值不值得走下去。我的Day 68就是这么来的。
