★ FEATURED ARTICLE 去年下半年开始我连续收到过几个让我有点坐不住的问题。不是来自老板画饼而是几个做产品的朋友随口问起的“你们前端团队现在有没有用 AI Agent 来改代码”第一次被问我还能打个哈哈说“正在调研”。第二次被问我意识到再不给出一个像样的答案就不只是面子问题了。作为一个带着七八个人前端团队的 Leader我对 React 组件设计、微前端、工程化、性能优化这些领域自认还是有点发言权的。但面对“AI Agent”这个词我当时的真实水平是能跟风聊几句但“Agent 到底跑在哪一层、怎么和业务系统连接、token 消耗怎么控制”我基本讲不清楚。于是 Day1 就这么开始了。我给自己定了一个看起来有点笨的计划每天至少投入两小时连续一百天不依赖二手转述直接对着模型 API 文档、开源项目源码和真实业务场景做实验。现在时间走到 Day70我想把这 70 天里学到的东西、走过的弯路和踩过的坑认真整理一遍。这篇文章既是给我自己的一份阶段性复盘也写给所有正在观望、或者已经启动但有点迷茫的前端同行。我不会讲太多“AI 改变世界”之类的空话。只讲一个前端 Leader 在 70 天里真实遇到的选择题、把前端经验迁移到 Agent 开发的思路以及哪些过去引以为傲的惯性思维反而成了我转方向路上的障碍。1. 从被问倒到决定下场转 AI Agent 不是赶风口1.1 那次让我印象深刻的对话引发我 Day1 的导火索是一次很简短的交流。朋友所在的公司正在用一套 Agent 做客户工单的自动分类和回复他们遇到的问题是模型经常把工单的优先级判断错想让我们前端团队帮忙做一个“人工确认界面”。听起来是个常规需求——把模型的判断结果展示出来让用户点确认或修改。但我顺着多问了一句你们现在的 Agent 是怎么调度的对方说了一个我听过的架构名词然后我发现自己接不上话。我只知道这单能做界面却不知道判断逻辑所在的 Agent 循环长什么样、是谁在控制它调用哪些工具、人工纠错之后的数据又是怎么回流的。这件事真正触动我的点在于如果 AI 应用的形态正在变成“页面只是外壳Agent 才是内核”那我过去十年积累的东西会逐渐退化成“只负责做皮”的工具人。一个前端 Leader 的安全感本来应该是建立在对整个数据流的掌控上的但那天我发现自己对 AI Agent 这条新链路几乎处于失控状态。1.2 我为什么没有一上来就冲 Agent 开发框架决定学之后我的第一反应是去网上搜“AI Agent 主流架构”。结果发现社区里已经形成了一套基本共识模型调度、工具调用、记忆管理、编排引擎、可观测性……每个词背后都有对应的框架和方案。LangGraph、AutoGen、各种编排平台的文章铺天盖地光看标题就有种“再不学就掉队”的焦虑感。但我没有直接上手框架。原因是我见过太多前端同事学框架的误区会用 Vue 但说不清响应式原理会搭 webpack 但搞不懂模块联邦的边界。学 Vue 不追源码没事但用 Agent 框架如果不理解背后的模型交互协议出现一个诡异报错时你根本无从排查。所以我选择了一条比较笨的路线先抛开框架从单个模型的 API 调用开始把 Prompt、结构化输出、Function Calling 逐一跑通再回到框架层面看它们到底做了什么封装。这个选择在后来被证明是划算的。因为市面上多数 Agent 框架的报错信息本质上都是在帮你翻译某个模型的 HTTP 协议。你裸调过一次 API再去看框架代码基本就是“外层的轮子”。2. DAY1 到 DAY70 的学习路径每个阶段踩对的关键节点2.1 Phase 1DAY1-DAY15把 Prompt 当成一门“语言”来学前 15 天我的精力几乎都花在 Prompt 上。刚开始很自然地把 Prompt 当成了“搜索关键词的扩展版”觉得只要把需求写详细点模型就能稳定输出。后来才意识到Prompt 更像是一门结构化的语言它有语法有约定有“接口设计”的味道。我最常用的一套组合是System Prompt 定义角色和边界Few-shot 给出两到三个输入输出示例再在 User Message 里给出当前任务和输出格式要求。这三层配合比单纯写一大段“你是一个资深的某某专家”要稳定得多。这个阶段做的第一个小实验是让模型输出一个固定 key 结构的 JSON里面包含“意图”和“参数”。当时我只是为了验证“输出可控性”没想到这一步直接为后面的 Function Calling 打下了直觉。现在回看前端背景的人在这里其实有一个天然优势我们在 JSX 里写 props、slot、children 的经验可以平移理解为“给模型预留接口”。接口设计得好模型就不容易跑偏。2.2 Phase 2DAY16-DAY35Function Calling 是前端和 Agent 的“协议层”到了第 16 天左右我开始接触 Function Calling函数调用。这个名字容易让人误解以为模型真的会去执行你的代码。实际上模型只是根据对话内容输出一个结构化的“调用意图”它想调用哪个函数、传什么参数。真正执行函数并拿到结果回填给模型的是你的程序代码。做前端的人可以这样类比你在 React 组件里写onClick{() doSomething()}组件本身并不知道 doSomething 内部怎么执行它只是声明了“用户点击时应该触发这个”。Function Calling 就是模型在对话流里写下的onClick声明——模型负责决定“该调用”程序负责执行。我找了一个周末抛开框架用 Node.js 裸调了一次函数调用 API。我定义了两个工具一个返回实时日期一个根据城市返回天气代码。模型在用户问“明天北京适合穿什么”时会自动先调用天气工具拿到结果后再组织回答。这一步跑通的瞬间我对 Agent 的敬畏感少了一大截——它不是一个黑盒它只是按照我提供的工具清单做选择题。2.3 Phase 3DAY36-DAY50ReAct 循环让模型从“话痨”变成“执行者”Function Calling 跑通之后我进入了一个更核心的环节理解 ReAct 模式。ReAct 是 Reasoning Acting 的缩写意思是模型在每一轮里先推理再决定行动观察行动结果后再推理。这是现代 Agent 循环的基石。我当时用一个很简单的伪代码把这个逻辑刻进了脑子里循环 把用户问题 历史消息 工具清单发给模型 模型返回一个消息 如果消息里包含工具调用请求 执行对应工具把结果追加进消息历史 继续下一轮循环 否则 把这个消息作为最终答案返回给用户 退出循环就是一个带状态的循环。模型负责思考工具负责行动消息历史负责记忆。这个模型一旦跑通Agent 编程的骨架就清楚了。用前端的语言来说它有点像 React 的状态驱动渲染状态messages变化组件Agent 循环重新执行副作用工具调用被触发然后状态再次更新。只不过前端的副作用是改 DOM、发请求Agent 的副作用是查库存、写文件、发邮件、调三方接口。2.4 Phase 4DAY51-DAY70记忆、向量检索与工程化收尾进入第 50 天之后我开始补两块内容记忆机制和向量检索。记忆这块我目前的实践方案分两层。短期记忆就是用上下文窗口里的历史消息相当于工作台的桌面随用随取长期记忆则把重要的历史结论、用户偏好、项目文档做摘要或向量化在需要的时候检索出来拼进上下文。前端有 localStorage 与内存的直觉类比理解起来不费劲向量库是长期存储上下文窗口是短期内存。我跑了一个简单的检索增强生成RAG实验把团队一份约 20 页的内部工程规范文档切成几百个片段用 Embedding 接口向量化存进本地向量库。以后 Agent 在回答“我们的组件命名规范是什么”时不是把整个文档塞进去而是先做相似度检索把最相关的几段拼进上下文再让模型回答。效果确实好回答速度快了很多token 成本也低不少。最后两周我把注意力放在工程化上流式输出的合理处理、超时和重试机制、并发限流、token 用量日志、错误分类。这些对前端工程师来说简直是老本行——前端处理接口不可靠性、做可观测性的经验几乎可以一比一平移到 Agent 服务端。直到这一步我才敢说这条路我走通了。3. 用前端经验重新翻译 AI Agent它没那么黑盒3.1 Agent 等于一个“永不结束的页面”加状态机我观察到很多前端同行不敢碰 Agent核心原因是觉得它太底层、太神秘。但用前端的经验去翻译一下会发现它的本质并不难理解。传统前端页面的生命周期是用户打开页面等用户操作用户离开页面销毁。而 Agent 的生命周期是接收一个任务主动思考调用工具观察结果再思考直到任务完成或被中止。两者都是事件驱动的只是 Agent 的“事件”主要来自模型输出。我刚上手时就一直把这个类比放在心里Agent 循环就是一个什么时候都不关掉的页面它不依赖用户点击而是依赖外部消息驱动。微信里收到一个来自员工的请求、GitHub 上来了一个 PR 事件——这些就是它的 onClick。这样一想接入外部系统的思路就通了。3.2 Token 是钱上下文窗口是缓存“AI agent token 是什么意思”这个话题在社区里热度一直很高。Token 是模型处理文本的基本单位也是计费的最小粒度。它可能是半个汉字也可能是一个英文单词的一部分。你每次调用模型消耗的 token 数等于你发进去的内容加上模型返回的内容。我的建议是把 token 想成带宽费用把上下文窗口想成浏览器内存。带宽是花钱的所以要省着发内存是有限度的塞满了就崩。很多 Agent 项目“跑着跑着就不对了”排查下来不是模型变笨了而是消息历史越堆越长token 成本翻了几倍模型反而被无关信息干扰。实操上有两个很有效的动作一是做输入裁剪把文档、代码、日志里与当前问题无关的部分去掉二是做历史摘要每几轮就把老消息压缩成一段小结而不是无限往 messages 里塞。3.3 组件化思维迁移到工具注册表做前端的人对“组件库”和“设计系统”特别熟悉。我最近发现Agent 世界的“工具注册表”和“函数描述清单”本质上就是组件库的另一种形态。在一个 Agent 系统里你给模型提供的每个工具都需要一份结构化的描述名称、用途、参数 JSON Schema、返回值说明。这和组件库里的 props 声明如出一辙。props 定义得清晰调用方就不容易出错工具定义得清晰模型就不容易在参数上翻车。我甚至发现可以把团队的旧系统接口包装成 Agent 可调用的工具——只要写一份机器可读的接口描述老接口就能被模型当作工具来用。这件事的工程价值不亚于写一套漂亮的组件文档因为“机器能读懂的接口契约”正在成为 AI 时代最重要的工程资产。4. 两个真正跑起来的 Demo一个给团队一个给自己4.1 Demo 1代码评审 Agent帮我盯 PR第一个项目的出发点非常实际团队每天的 PR 评审很耗时我想让 Agent 先过一遍代码帮我标注可疑点。实现思路很简单在 GitHub Webhook 上接收 PR 触发拉下 diff把 diff、仓库 README、一份十行的代码规范片段拼成 Prompt发送给模型要求输出结构化 JSON。JSON 的格式是问题位置文件名行号、严重级别critical/warning/suggestion、问题描述、修改建议。这个 Agent 的强项是抓空值判断、重复代码、明显的边界条件遗漏基本能把“一眼就能看出的问题”快速筛出来。但它也会误报比如把符合团队惯例的写法判成隐患。所以我在前端展示层做了人工确认按钮把 Agent 的每条建议都标记为“确认/忽略”确认结果再回流到数据库。这个 Demo 给了我一个信心前端团队完全有能力自建 AI 辅助工具不是只有等官方插件才能有 AI 能力。我们可以自己定义工具范围、数据格式和交互兜底。4.2 Demo 2基于 Rust 的轻量 Agent 原型第二个 Demo 是给自己的技术好奇心买单。我当时看到“基于 Rust 语言 AI Agent”的讨论热度不低就想着用 Rust 把已经跑通的 Agent 循环重写一版。内部我把它叫 micro-agent不依赖任何重量级框架只有一个消息数组贴合 Agent 循环配一个工具分派器用 reqwest 调模型 HTTP 接口用 sqlite 存消息记录。之所以选 Rust一是想看看同样的逻辑在不同运行环境下的性能差异二是想尝试更小的内存占用和更快的启动速度方便以后以常驻服务的方式部署。实际做下来发现Agent 核心循环本身非常小真正值钱的部分在循环之外上下文管理、质量评估、权限控制、日志追踪。就像写前端React 组件本身不复杂复杂的是状态管理、路由、鉴权和数据同步。4.3 两个 Demo 带来的认知修正这两个项目让我完成了一次心态上的修正。过去我做前端习惯以“页面交互”为中心思考问题现在做 Agent重心变成了“任务闭环”。页面只是结果展示的一环而任务的拆解、工具的选择、结果的验证、失败的回退才是真正需要投入设计精力的地方。“结果可验证、失败可追溯”这八个字是我这 70 天里最深的心得。Agent 的每一次工具调用、每一条模型输出都必须可以被记录下来、被复现出来。没有可观测性的 Agent本质上就是一个你不敢上线给用户的定时炸弹。5. 70 天里踩过的三个坑想转的同学请直接绕开5.1 坑一用写业务代码的思路去写 Prompt我刚开始写 Prompt 时带着强烈的业务开发惯性。做前端系统我习惯了在代码里把异常分支、边界情况全部列清楚如果用户没传参怎么办、如果接口超时怎么办、如果返回数据字段缺失怎么办。于是我会在 Prompt 里写上一大段“如果……那么……”。结果模型还是会在我没覆盖到的地方自由发挥。这种“创造力”在业务代码里是 bug但在模型输出里是常态。后来我的做法变了不再尝试用自然语言穷举所有边界而是用 System Prompt 明确目标用 Few-shot 给出黄金样例用 JSON Schema 做硬约束剩下的交给后置校验代码来兜底。模型不需要被教成“防御性编程大师”它只需要做好选择和生成剩下的检查交给程序。5.2 坑二把上下文窗口当内存无限往里塞这是我踩得比较深的一个坑。为了让 Agent 回答得更全面我一度把整个项目 README、工程规范、之前所有对话记录一股脑塞进 messages。结果 token 成本翻了几倍回答速度明显变慢更糟糕的是模型反而“分不清主次”了开始在一些低价值信息上较劲。上下文窗口不是数据库它更像一张工作台。东西堆得太多真正要用的那把扳手反而找不到了。调整后的方案是只塞和当前任务相关的内容文档类信息走向量检索只取 Top3 相关片段历史对话定期摘要老消息压缩成一小段“之前聊到哪了”。这三个动作做完回答质量和稳定性都上来了成本也下来了。5.3 坑三在选型上纠结太久失去了写代码的节奏Day30 到 Day40 那段时间我陷入了选型焦虑。今天看到一份“多 Agent 比单 Agent 强”的文章明天看到一套“某框架遭弃用”的讨论翻来覆去地对比框架特性代码却没推进几行。事后看这是最浪费时间的一段时间。正确的路径应该是先用最朴素的方式把单 Agent 跑通让整个循环跑起来然后在一个真实业务场景里找到具体痛点再根据痛点去选框架或自研。多 Agent 编排不是目的只是手段它解决的问题主要是角色隔离带来的上下文清晰和权限控制不是为了炫技或者追并发。如果让我给 Day1 的自己捎句话我会说先写一个最小的循环让模型回答一句你好然后让它学会调用一个工具再让它学会把工具结果回答给用户。这个循环通了其他都是外围工程。6. 回到 Leader 的位置前端团队怎么接住 AI Agent 这波机会6.1 前端团队在 AI Agent 链路里真正的优势很多人以为前端转 AI Agent 要重新学一堆东西其实我们手里已有的技能在这个新领域里刚好是稀缺资源。前端团队最擅长的是什么是处理用户与系统的实时交互是把后端和模型的输出变成人类能看懂、能操作的界面是对复杂的浏览器环境做兼容和降级处理。这套能力放到 AI Agent 场景里对应的是流式输出体验、人工确认兜底、错误状态展示、方案对比界面、Agent 运行日志可视化。这些都是 Agent 落地过程中绕不开的前端工作。更关键的是工程文化。前端 Leader 大多经历过工程化改造的阵痛组件规范、构建流程、代码评审、监控告警。Agent 开发同样需要这套工程纪律。一个没有日志、没有版本管理、没有质量回退机制的 Agent 项目和我们十年前没有 eslint、没有 CI 的前端项目一样危险。6.2 我给我们团队规划的渐进路径我目前给团队规划的是三个月的渐进路线不搞全员转型也不搞一刀切。第一个月是“人人有个 Demo”。核心成员每人挑一个具体的业务痛点做一个最小可用的 Agent 原型方向不限。有人做文档问答有人做代码评审有人做接口变更提醒。目的不是产出多厉害的产品而是让团队建立对模型能力和局限的共同认知。第二个月是“试点真实业务”。从 5 个 Demo 里挑 2 个真正有业务价值的做深做透。我的选择标准只有一个这个任务是不是我们团队每周都在做的重复劳动。第三个月是“嵌入工程流水线”。把验证好的 Agent 能力接入现有的开发流程比如在提交代码时自动补充测试建议在发布时自动生成变更日志在工单进来时自动分类。这一步的产出直接决定团队能不能把 AI Agent 从“玩具”变成“工具”。6.3 给想转方向的初中级前端的一句实话如果你是一个工作一到三年的前端正在纠结要不要转 AI Agent我的建议是你不用先去学 Python也不一定需要换掉 React 或 Vue。当前阶段的“转 AI Agent”更多是“掌握 Agent 工程化能力”而不是“成为算法工程师”。前端训练出来的调试能力、编程基础和对接口的敏感度都已经足够支撑你在这个方向上起步。真正的门槛在于愿不愿意和模型的“不确定性”共处愿不愿意把一部分对输出的控制权交给结构化协议和校验代码。前端工程师习惯的世界是确定的——输入啥输出啥页面错位一定有原因。Agent 的世界里模型可能信誓旦旦地给出一个错误结论你要做的是给它周身套上足够结实的约束。对我来说Day70 不是终点。接下来的重心是把 ReAct 循环的可靠性和可观测性做得更深同时把团队里这一轮 Demo 的经验沉淀成内部文档。如果让我给 Day1 的自己捎一句话大概会是别怕模型乱说话因为你总会学会给它套上结构化的缰绳也别等读懂所有论文才动手先把一个循环跑起来问题的答案会在反复的调试中慢慢浮出水面。
阅读完成 · 觉得有帮助？
