★ FEATURED ARTICLE 今天是前端Leader身份下学习/转行AI Agent的第70天。昨天白天还在开需求评审晚上十点终于把一个“多角色协同处理单据流程”的端到端Demo跑通了日志最后一行打出了task completed我盯着屏幕愣了几秒。70天前我只会对着大模型聊天窗口问问题现在居然能自己做出一套带工具调用、记忆管理和多代理拆分的原型系统。这个节点值得写一篇复盘。这篇文字主要做三件事给自己留一个阶段存档给同样在职、同样带团队、同样在观望AI Agent的前端同行一份偏实操的过程记录把踩过的坑整理清楚免得组里后续接Agent项目时重复交学费。内容不按教材写就按一个普通人的70天流水账加技术心得来。如果你也是前端背景正在纠结要不要花时间学Agent这篇应该能给你一些具体参照。1. 第70天的来路动机、节奏和每天两小时的学习闭环1.1 想转AI Agent不是因为不想写前端坦白说我不是那种对前端失去热情想跑路的人。做前端Leader这几年我每天面对的事情里有一大半是重复劳动同类页面的轮番适配、权限判断、状态同步、数据回填团队里四个前端同学每周都要被各种“改个字段”“换个排序”的迭代消耗掉将近三分之一的时间。我一直觉得这里面一定有办法能做端到端的自动化但传统脚本和规则引擎都被试过边界太硬、场景一多就崩。AI Agent真正吸引我的点是它不强依赖“穷举所有分支”而是靠大模型的推理能力去理解用户意图自己去调用工具、查数据、生成结果最后把一条流程串起来。这正好打在重复劳动的要害上高频、有规则、但规则又会变。与其说是逃离前端不如说是把“写页面”这个动作升级成“编排系统完成页面背后的整个事务”。我给自己定的目标也很朴素70天之后能独立搭出一个能解决真实业务问题的Agent原型而不是只会跑别人的Demo。带着这个目标节奏就出来了。1.2 70天三轮递进我的学习节奏和阶段产出很多人学新东西喜欢按“从基础到高级”的线性顺序但我用的是三轮递进每一轮都做出一个能跑的Demo再做下一轮。这个设计很重要因为只有看到东西跑起来后面学的东西才有承接点。阶段学习内容每天投入阶段产出Day 1-21大模型API调用、提示词基础、结构化输出1.5-2小时一个带工具调用的问答DemoDay 22-49RAG、向量库、Agent编排框架、函数调用2小时周末一个单据解析Agent原型Day 50-70多代理协作、上下文记忆、Trace、评测2小时一个端到端的单据流程Demo实际执行中当然经常被打断出差、版本上线、孩子生病都有。但我不追求每天都满额只求节奏连续。连续比强度重要哪怕某天只读了半小时文档也胜过断一周再回来重看。1.3 每天两小时的纪律先文档再复现后复盘我的学习闭环固定三步先读官方文档或系统材料理解设计意图再用最小代码复现验证自己的理解最后把出错的地方记成笔记第二天回看。这个方法是从以前学前端框架时带过来的但用在Agent学习上尤其有效。举个例子学习结构化输出时我读文档以为只要在系统提示里写了“请输出JSON”就能拿到干净结果结果实际跑的时候总会夹带解释文本。后来才发现真正起作用的是在请求参数里显式声明响应格式。这种“文档理解-实际运行”之间的落差才是学习最有价值的部分。每天的复盘笔记里我专门记这类落差不记概念定义。2. 前端背景是“吃老本”还是“换血”我的真实结论2.1 前端老本里最值钱的三样东西第一个是异步与事件循环。Agent每跑一步本质上就是一个异步决策链发请求、等返回、再发下一个请求。前端同学对promise、事件回调、竞态处理几乎是条件反射这套底子在Agent开发里直接能用我写多代理协作时处理并发状态的感觉和写前端联调接口特别像。第二个是状态管理。做过复杂前端项目的人都有体会全局状态一旦失控页面行为就会变得不可预测。Agent的上下文管理也是同一个问题模型能记住什么、忘记什么、从哪取回什么本质上就是在做状态管理。你懂Redux或Pinia那套单向数据流思路理解起记忆模块会非常顺畅。第三个是产品直觉和流程梳理。Leader岗位逼着我每天把业务语言翻译成技术方案我知道用户在一个工具链里卡在哪一步、哪些环节最痛。这个能力在做Agent场景选型时是刚需模型不是万能的能不能选对“让AI替人干活”的切入点决定项目生死而这个判断力来自业务理解不来自模型知识。2.2 最难迈过的坎从同步UI思维到token流思维老本虽好但有一道坎卡了我整整两个星期思维模式切换。前端的界面逻辑本质是同步的、可控的事件触发后我们明确知道接下来会发生什么页面状态是确定的。而Agent不一样它是token流是概率性的同一个提示词模型这次可能选工具A下次可能选工具B甚至可能在两个工具之间来回横跳。我第一次写函数调用时下意识想用状态机把模型的所有行为路径都约束死结果prompt又长又笨模型反而频繁出错。后来我才明白在大模型面前正确的姿势是“给边界不锁路径”明确告诉它哪些能做、哪些不能做、做完结果怎么返回但不要尝试枚举它每一步必须怎么做。这个“从可控到概率”的心态转变比任何具体API都重要。2.3 一张帮助我做思维迁移的对照表学到一个东西我都会问它对应前端里的什么这张表是我第40天整理出来的现在回头看它基本概括了我的迁移路径。前端概念Agent开发概念共通点事件监听工具调用Tool Schema都是“触发-响应”但前者确定后者概率性组件树工具集与代理结构都需要清晰边界避免耦合全局状态管理会话上下文与长期记忆都是数据的读写与同步Agent多了成本和遗忘路由与权限守卫意图识别与任务规划都是根据输入决定走哪条分支前端埋点和监控Trace与评测都是为了发现问题、定位原因响应式布局多路径容错提示词都是为了应对不确定的环境这张表帮我在前端组讲课时省了很多力气后面带团队切入Agent时它就是一套现成语义翻译器。3. Day30到Day60反复磨的三块硬货工具调用、上下文记忆、多代理协作3.1 工具调用本质是给模型一张“接口菜单”函数调用是我认为Agent最核心的机制没有之一。它的原理一句话就能说清大模型本身不执行任何函数它只是在需要外部能力时输出“我要调用哪个工具、参数是什么”的结构化指令真正执行的是你的代码执行完再把结果返回给模型继续推理。这就像一个前端组件模型是组件使用者工具是onChange回调回调结果会再次驱动组件重新渲染。关键在于你一定要把工具描述写得像一份靠谱的接口菜单。我常用的工具描述结构是这样的{ name: query_order_status, description: 查询订单的实时处理状态。当用户询问‘订单到哪了/多久能好’等含义时使用不要用于查询历史订单列表。, parameters: { type: object, properties: { order_id: { type: string, description: 订单号形如SO-2025-0001 } }, required: [order_id] } }菜单写得越清楚模型就越不容易乱点菜。我总结出三条实践经验工具名要稳定改了名会让历史上下文全部失效描述里一定要写清楚“什么时候用它、什么时候不要用它”这比参数定义还重要一次给模型塞的工具不要太多五个以内最好超过八个模型的选择准确率会肉眼可见地下降。工具返回的内容也要克制把无关字段全部裁掉因为返回的每一个字都在烧token也会干扰模型下一步决策。3.2 上下文记忆token预算、摘要和长期存储写Agent的人迟早会撞上“记忆墙”模型不是没能力而是上下文窗口有限塞不下所有信息。我处理记忆问题的方式和前端处理缓存完全是一个套路短期记忆留在会话里长期记忆落到外部存储需要时再取回。短期记忆最简单的做法是滑动窗口只保留最近N轮对话再往前的内容压缩成摘要。长期记忆则靠摘要加向量化把历史对话的要点提取出来写入外部存储下次用户再提相关需求时通过检索把它拉回上下文。你可以把这三层理解为浏览器缓存、localStorage和远程数据库。我实践下来有三种记忆值得认真设计会话内短期记忆、会话外长期记忆、以及工作记忆。工作记忆最容易被忽略它指的是当前任务的目标、已完成步骤、待办事项。我的做法是在每次工具调用返回后同步把状态写入一个外部“任务清单”让模型每轮决策前能读到当前进度。这个机制类似前端把临时状态提升到全局Store效果立竿见影能明显减少反复询问和重复操作。上下文还有一个绕不开的资源问题token预算。我常用的分配参考是这样的内容占用比例建议系统提示与角色说明15%-25%历史会话与摘要35%-45%工具返回结果20%-30%当前用户指令10%-20%这不是定死的标准但它强迫我养成“每一块内容都要有预算”的习惯。上下文不是无限的内存它是成本也是瓶颈。3.3 多代理协作让“三个实习生”配合比堆“三个专家”更稳Day50之后我开始碰多代理。一开始特别兴奋觉得让一个模型当规划者、另外几个当执行者一起干活很酷。但试了两周才明白多代理不是堆更多模型而是把职责拆到可以独立测试的粒度。我的切身体会是先单Agent跑通再拆多Agent。你连一个工具调用都没调稳不要急着上多代理。拆的时候优先用“主管-执行者”模式一个规划代理负责理解用户真实意图、拆任务、分发子任务多个执行代理各自只负责一个非常窄的领域比如解析、核验、写结果。每个执行代理的工具越少越好我甚至会把它们限制在两到三个工具以内因为工具少出错的概率就少。还要守一条纪律执行代理之间不要互相调用。以前我天真地让核验代理直接去调用解析代理的结果结果两个模型互相等待、反复确认日志刷屏。正确做法是所有子结果都汇总给主管由主管统一判断、统一输出。这就像带实习生你宁可让每个实习生只负责一小块把结果交给你来做最终整合也不要让实习生之间来回对接。经过调整我的单据流程Demo稳定了很多返工率从每十单返工三四单降到一单以内。4. 70天里最值得写的四个踩坑现场4.1 案例一模型在同一个工具上反复空转现象很典型日志里连续十几轮都是同一个工具调用记录模型像着了魔一样一遍遍查同一张订单的状态任务永远走不到下一步。第一晚我怀疑是系统提示约束不够把“不要重复查询”写进了prompt还是没用又怀疑工具返回格式不对把返回结果直接打印出来比对格式正常。最终定位到的原因让我有点意外工具返回结果里包含的原始文本太长了长到模型每次更新上下文时注意力都被细节淹没反复确认“自己是不是漏了什么信息”于是选择再查一遍。解法也很简单把工具返回压缩成关键字段摘要并明确在系统提示里写“一次查询后如果状态未变化直接结束子任务”。这个坑的核心教训是模型不会天然止损你必须为它设计终止条件它才会停下。{ round: 9, tool_call: query_order_status, tool_return: order SO-2025-0001, status: processing, 7 fields returned, assistant: 仍未变更继续查询以确认 }看到这条“继续查询以确认”我和熬了一整晚的自己面面相觑。从那以后凡是涉及轮询类工具我都会先问一句如果结果没变化下一步该做什么4.2 案例二聊到一半模型把最初需求忘干净了第二个坑是在长对话里踩的。用户对话超过30轮后模型突然开始按照一套偏离最初目标的标准去做判断最初明确的用户参数全部失效。排查很久才发现是上下文窗口装不下前面全部消息早期消息被静默截断了。这就是前面提到的“失忆”问题。修复思路分两层底层每轮结束把关键参数和当前目标写入外部存储并在每轮开始时以“当前任务”的形式注入系统提示上层定期把历史消息压缩成摘要而不是全部保留原文。现在的Demo里开头用户给的“订单类型”“处理优先级”“截止时间”等关键信息全部外置模型几乎不会再出现“聊着聊着忘了来干嘛”的情况。这个改造也加深了我对记忆模块的理解状态必须持久化不持久的状态等于不存在。4.3 案例三RAG召回了“相似但无关”的片段回答一本正经胡说接入RAG后出现了一种更隐蔽的错误模型引用的知识看起来都相关但组合出来的结论完全不对。后来我在调试面板里看召回结果发现召回的前几条片段只是在字面上相似在领域里毫无关系。原因出在分块方式和检索过滤上我把整页文档切成大块塞进了向量库没有给每块打上文域标签检索时自然什么相似拉什么。解决方案分三步一是把切片大小从整页降到按语义段落切每块控制在200到400字二是给每个切片打上项目、模块、时间等元数据检索时先做元数据过滤再向量召回三是设置一个相关性阈值低于阈值的检索结果干脆不返回让模型明说“资料不足”而不是硬编。现在系统里凡是回答涉及具体流程的都会带上来源引用这个习惯和前端做埋点一样是Agent落地的基础设施。4.4 调试姿势把Agent当系统来观测前面几个坑能快速定位靠的不是肉眼盯着聊天窗口猜而是把每一轮调用过程完整记录成日志。我做的第一件事是在每个入口和工具返回处打点把当前提示词、模型输出、工具调用、工具返回、耗时全部落到结构化日志里。问题出现时直接回放“模型为什么在那一刻选了那个工具”。另外两个小动作也很有用复现问题时把temperature设为0让模型输出尽可能稳定改prompt或者工具表之后用一组固定的历史测试用例跑回归比较答案变化绝不裸改上路。说白了这就是把前端监控和持续集成的习惯平移到Agent开发里。没有评测集的Agent优化等于没有监控系统的线上项目你敢上线就敢被炸蒙。5. Leader视角的落地思考前端团队接Agent之前先想清楚三件事5.1 先分清“做个技术演示”还是“改造一条端到端流程”现在各种Agent大模型Demo很热闹很容易让人产生“什么都该马上自动化”的错觉。我在选场景时给自己定了几个硬条件高频、规则相对清晰、容错可接受、数据相对结构化。完全开放的创意类任务现阶段不适合当第一个落地场景因为失败率太高。以我们正在试点的方向为例选的是高频单据类业务的自动解析和核验流程。这类场景数据相对规整出错可以被人类快速发现并纠正。我还坚持一个原则先以“人机协同”为目标不追求“无人驾驶”。你要让业务部门接受一个90%自动、10%人工兜底的流程比让他们一开始就承诺“全自动”容易得多。5.2 两周试水的最小闭环怎么搭给团队的前端同学做Agent入门我不建议从理论开始而是直接搭一个两周内能交付的内部工具。具体步骤我整理过一份基本照着走就能出东西选一个高频但低风险的内部场景定义清楚的输入和输出。场景越小越好比如把某个数据同步助手的异常汇总自动生成周报。接入一个商用大模型API先用现成接口不碰微调。微调不是新手需要做的事多数场景用正确提示词加工具调用就够。写四个以内的工具把所有外部操作包在工具里。前两周千万不要追求复杂编排能跑通一条路径就很好了。人工旁跑一周记录每一次成功、失败和失败原因。这些样本就是后面优化提示词的数据集。根据失败样本迭代但每次只改一处。我见过太多人同时改五个地方最后都不知道是哪个修复起的作用。这个最小闭环的验收指标只有三个说的操作次数有没有变少、任务完成率是不是可接受、出问题时有没有可靠的兜底出口。不要关心它够不够花哨。5.3 第70天之后的账时间成本与真实瓶颈算一笔时间账70天平均每天两小时周末再加一些合计大概150个小时。这时间对Leader来说不算小数目但换来的能力是质的从“看得懂概念”变成“能独立搭原型”。这150个小时里真正消耗我最多时间的不是写代码而是理解“模型为什么那样选”和“上下文为什么会失控”。这些经验光看教程是学不来的必须在调试日志里泡出来。真正限制Agent落地的瓶颈我现在的判断不在模型推理能力而在四个基础工程问题数据是不是足够结构化、流程有没有标准化到可以被拆解、评测集有没有沉淀下来、以及有没有给失败留好兜底线。这四个问题没有一个靠调prompt能解决都需要业务方、产品和技术一起坐下来梳理。这也是我觉得前端团队特别适合切入Agent项目的原因——前端同学天然站在产品和用户中间最懂流程哪里疼。再说组内推广的事我走的路是先让一两个有自驱力的同学组成先锋小组选一个小场景打样板而不是让全组同时转型。等样板跑通把过程和踩坑整理成内部文档再逐步扩大。强行让所有人同时学只会同时分心什么产出都没有。技术选型上我们目前尽量选开放生态的通用大模型接口避免被单一平台绑死同时也方便在不同模型间切换做效果对比。最后给自己留的一句话真要说第70天最想分享的经验还是一句话把prompt和工具表当作代码来管理。它们要进版本管理、要打标签、要留变更记录每次改动后用同一组历史用例跑回归。这个习惯是我从前端工程化里带来的但放到Agent开发里它比管理代码本身还重要。第70天刚好是一个节点接下来10天的计划是给Demo补一套更完整的评测集把多代理的返工次数也接进监控指标里。等跑完这一轮希望还能写一篇有数据对比的续集放出来。
阅读完成 · 觉得有帮助？
