今天是在职学习AI Agent的第67天。

前端的第8个年头，我第一次觉得“前端技术栈本身”不是最值钱的东西了。这话有点狠，但我劝你先别急着反驳。过去三个月，我们团队用Vue3维护一套物联网管理后台，业务方提的需求，已经从“这个表格能不能加个筛选”，变成了“这两个告警能不能自动合并，然后让大模型帮我写一份处理摘要”。需求变化背后，是一个正在发生的范式转移：前端开发依然存在，但业务价值的中心，正在从“人操作界面”转移到“Agent自动完成任务”。

这篇文章是我Day 67的复盘。写它有几个目的：一个是梳理这67天我的认知变化，另一个是给和我一样身处前端、又对AI Agent又爱又怕的同路人，提供一个真实样本——一个带团队的前端Leader，到底是怎么学习/转行AI Agent的，中间踩了哪些坑，哪些前端经验能直接迁移，哪些东西必须从头学。

1. 为什么一个带团队的前端Leader，非要折腾AI Agent

1.1 前端Leader的尴尬位置

我见过太多前端Leader的生存状态：白天开需求评审会，晚上写页面，周末还得担心团队成员的绩效。往上走的路真的不多。转管理？团队才六个人，管理动作没那么丰富。转架构？要和后端云原生那群人卷，人家一个容器编排面试题就能让你怀疑人生。转全栈？体力消耗和时间成本直接翻倍。AI Agent的出现，相当于给了一条新路：把前端积累的交互、边界、用户体验的理解，迁移到一个新物种身上。

这几年低代码平台和AI生成界面工具，也在挤压传统前端的存在感。一个简单的后台管理页面，丢给AI生成器，几分钟就能出一个能看的版本。如果我们的价值还停留在“把UI稿变成页面”，那被替代是迟早的事。但Agent不一样，Agent需要有人设计任务流、设计人在回路、设计异常处理。这些设计工作，恰恰需要懂交互、懂状态、懂边界的人来干。前端人如果补上Agent的原理和工程知识，会成为这类设计的稀缺力量。

1.2 让我真正下定决心的三个瞬间

第一个瞬间是面试。我和另一个前端Leader聊天，发现今年收到的简历里，十个里有三个会写“熟悉大模型，用LangChain搭过Agent”。虽然面下来八成是背概念，但市场信号很明显：新的技术范式已经开始渗透到前端岗位的人才市场。

第二个瞬间是团队内部的小项目。我们后端同事用大模型做了个客服反馈自动分类Agent，三天跑通，效果不错。我配合做了个前端页面，把分类结果展示出来。业务方看完说：页面挺好看，但这个系统我们只需要每天看一眼结论。换句话说，我花在展示层上的那些心思，在业务眼里几乎等于零。那天我是有点受刺激的，也第一次认真思考“前端在一个Agent系统里，到底应该承担什么职责”。

第三个瞬间是老板在规划会上问的一个问题。他说现在新增了一个需求，要根据用户的自然语言描述自动生成设备配置模板，现有规则引擎完全搞不定，能不能做成“Agent模式”？当时会议室没人敢接。规则引擎至少可解释、可回滚，Agent是概率性的，你敢让它自动改配置吗？但反过来想，别人不敢接，我如果研究明白了，这就是我的机会。

提示：想转AI Agent的前端，第一件事不是All in，而是先承认“前端技能依然重要，但它在新的技术范式里开始变成配角”。承认这一点，后面学习才不会有那么多心理内耗。

1.3 到底是“转行”还是“技能叠加”

我最后的答案是技能叠加。理由很简单：AI Agent要成为一个生产级产品，不可能没有前端。管理界面要做，任务编排画布要做，审核台要做，流式输出要做，多Agent协作的可视化工作台更要做。这些都是前端的活，而且没人比前端更懂怎么做“复杂系统里的交互”。

但只有前端技能是不够的。你至少得懂Agent的运行逻辑：模型怎么调用、上下文怎么管理、工具结果怎么处理、失败怎么重试、token成本怎么控制。如果不懂这些，你写的界面就只是一个空壳，就像当年只切图的页面仔。所以在我眼里，这不是一场“抛弃前端”的转行，而是一次“前端技能+Agent工程”的叠加升级。前端是底图，Agent是新增的等高线。

2. DAY67这一周，我的实战复盘：从零搭一个内容自动发布Agent

2.1 为什么选“内容自动发布”当练手项目

第60天的时候，我给自己定了一个阶段性硬目标：在Day 67之前，搭出一个真正能跑通闭环的Agent小系统。题材选的是“小红书自动发消息”。为什么选这个？原因有三个。

第一，它覆盖了Agent最常见的完整循环：获取内容、大模型改写、决策发布、失败重试、人工兜底。第二，它涉及真实平台接口的鉴权、限流和风控，能逼我去处理工程问题，而不是只调API玩。第三，这个工具我家属是真用得上的。她做运营，每天要写几十条文案，还要在多个平台发布，如果这个Agent能自动生成草稿、自动排队，她至少能省一半时间。真实需求带来的动力，比任何学习打卡都管用。

我也见过程序员朋友学Agent，一上来就复现ChatBot，跑通了就发朋友圈，然后就没有然后了。没有真实用户、没有业务反馈的练手项目，大概率会在第20天就默默烂尾。所以特别建议选题时先问自己：这个东西做完，谁会真的用？

2.2 系统架构：四层结构，前端在哪一层

系统整体分四层：

• 数据源层：RSS订阅源，加一个内部后台的导出API。
• 处理层：先做文本抽取，再用LLM改写成适合平台调性的文案，同时做敏感词过滤。
• 执行层：调用发布接口，带鉴权和频率控制。
• 展示层：一个Web审核台，运营可以预览、编辑、确认或丢弃Agent生成的每条内容。

前端选型是Vue3 + uni-app的H5版本。为什么不用小程序？因为审核台需要快速登录，uni-app的登录模块加后端签发JWT，一周就能拿下。我特别想说的是：组件库、登录框、状态管理这些老技能，在Agent应用里不是没用了，只是换了个宿主。以前组件绑定的是“表单字段”，现在绑定的是“Agent任务状态”。我做审核卡片列表时，用的还是老一套的分页、筛选、状态标签，但背后的数据已经变成Agent的待执行任务队列了。

视频素材的处理是这一周比较大的工程点。自动发布不能不支持带视频的内容，而一条短视频动辄几百MB，直接走普通接口上传必挂。我的方案是老技术：Web Worker分包加断点续传。前端把视频切片后并发上传到对象存储，再把存储地址交给处理层，由Agent生成标题和封面。这个技术在Agent系统里的意义完全变了——它不再是“前端性能优化”，而是“数据进入智能处理流水线的安全入口”。

顺带说一句，我现在看直播H5相关的技术也特别有代入感。如果做实时Agent助手，音视频链路完全可以接讯飞实时语音转写这类能力，给直播间提供实时字幕和话术建议。这个方向最近很热，前端在音视频上的积累会派上大用场。

处理层的关键逻辑，我用伪代码描述一下，方便和前端同学对齐思路：

function rewriteContent(raw): summary = extract_rule_based(raw) # 规则抽取摘要，省token prompt = build_rewrite_prompt(summary) # 拼装系统提示词 output = llm_call(prompt) # 调用大模型 plan = parse_json_with_retry(output) # 解析发布计划，带重试 if plan is None: plan = need_human_review() # 连续解析失败转人工 return plan

这段逻辑看起来很简单，但这周我改了三版：第一版把raw全文丢给LLM，第二版加了摘要，第三版加了重试和人工兜底。每一步都在解决真实问题，不是为炫技。

2.3 踩坑：token、风控和“格式化幻觉”

这一周踩得最深的坑有三个。

第一个坑是token预算失控。AI Agent token是什么意思？直白说，token就是大模型读写内容的计量单位，也是上下文窗口的计数单位，更直接点，就是钱包里的余额。一个汉字大约1到2个token，一个英文单词大约1个token。最开始我的处理层直接把抓取到的长文丢给LLM改写，结果每篇长文光输入就要消耗几千token，一天下来账单涨得飞快。后来改成“先用规则引擎把长文压成摘要，再让LLM基于摘要扩写”，成本一下子砍掉70%。核心经验是：在Agent里，每一次token消耗都要算性价比，能靠规则榨出来的信息，就不要花token让模型读。

第二个坑是平台风控。自动发消息这事没有想象中美好。发布接口调用频繁后，先是出现滑块验证，然后IP被限流，再后来被告知需要额外授权。我一度以为是平台的爬虫反制太强，后来想明白了：任何在公网上运行的自动化操作，都必须设计“人机协同”的节奏。妥协方案是在展示层增加人工审核队列，所有Agent生成的稿件先进“待发布”状态，由运营在审核台上确认，再由后端定时器控制节奏去发布。这个改动看似降低了自动化程度，但从工程角度看，它才让Agent系统有了长期存活的基础。

第三个坑是“格式化幻觉”。大模型输出并不总是一段合法的JSON。我让处理层输出发布计划，偶尔缺个逗号，偶尔中途截断，偶尔在JSON外面套一层markdown代码块。解决方案分三层：正则提取出疑似JSON的部分，用容错解析器解析，连续失败两次就转人工。这套兜底没有技术含量，但少了它，整个Agent就是一台三天两头停机的机器。

为了方便阅读，我把这一周的坑整理成了一张表：

2.4 结论：Demo能跑和能上线是两回事

这个项目在Day 67当天跑通了。第一版的样子是：早上从RSS抓到5条行业新闻，LLM改写成小红书的文案风格，生成标题、正文和话题标签，全部进入待审核队列；家属在手机H5上点确认，系统再按随机节奏发送。听起来挺美，但它只证明了“能跑”，离“能长期用”还有十万八千里：文案风格不稳定、偶尔出现事实性错误、平台规则一变就要改适配层。

但恰恰是这些不完美，教会了我最重要的一件事：Agent系统里，90%的工程问题不是模型不够聪明，而是流程设计不够稳。token怎么省、审核怎么加、重试怎么幂等、频率怎么控制、失败了怎么通知人，这些才是长期价值。这也验证了1.3节说的那句话：不要把学AI Agent变成“会调API”，而是要成为“能把Agent从实验室带到生产环境的人”。

3. 前端技能迁移地图：这些老本行在Agent世界里依然值钱

3.1 技能对照表

我差不多花了两个星期，把团队日常技能和AI Agent开发需求做了个对照，发现重叠度比想象中高得多。整理结果如下：

说三个印象最深的。

前端SDK这行，迁移难度最低。你以前看别人的SDK文档、封装请求层、处理错误码，到了Agent世界，同一套方法论：看LangChain或各厂商的Agent SDK文档，封装工具调用，处理模型返回的错误。组件库也一样，以前封装表格、表单，以后封装“Agent状态条”“任务卡片”“工具调用历史时间线”。这些组件很快会像今天的UI库一样，成为Agent应用的基础设施。

微前端这行，比想象中更能复用。前端团队搞过qiankun的话，一定熟悉“主应用定底座、子应用独立部署、统一鉴权、按需加载”这套模式。多Agent系统里几乎一模一样：你要有一个控制台负责统一入口和监控，每个Agent是一个独立模块，有自己的版本、配置、运维权限。我在做自动发布项目时，甚至直接把审核台设计成了可插拔模块，以后接新的Agent任务，只要把新的子模块注册进去就行。

安全这行，是我最近特别注意的。前端一直讲“用户输入不可信”、防XSS、防爬虫、防查看源码，这些经验放到Agent上不但不过时，还更有价值：Agent暴露在公网上，可能被恶意Prompt注入、被偷密钥、被滥用工具调用。各家云厂商陆续出的Agent安全白皮书，核心就几条：身份认证与授权、输入过滤与输出脱敏、工具调用鉴权、审计日志。前端的“边界意识”在这里可以直接平移，你只需要补充一条新认知：模型输入同样不可信。

3.2 前端人做Agent有天然优势，别浪费

举两个真实例子。

一个是我团队里的小朋友，工作才一年，主要做H5活动页。我让他试着做一个“Agent任务流可视化编辑器”的原型，类似流程图编辑器，把Agent的节点拖拽连起来。他一开始很慌，说没写过这种。我告诉他，你就把它当成复杂表单组件，节点就是一个带状态和参数的自定义组件。结果他两周就做出了第一版，还加了撤销重做和自动布局。后端同事看到原型后很惊讶，说前端已经能直接操作Agent流程了。其实他没意识到，后端在纠结调度引擎的时候，前端天生就在跟“状态加交互”打交道，可视化编排正是我们的主场。

另一个例子是调试习惯。后端排错靠日志，前端排错靠界面上的状态反馈。Agent这种“异步、多中间态、偶尔需要人去确认”的系统，恰恰需要把每一步的意图、观察、结果可视化地暴露出来。谁最会做这种可视化？前端。与其说AI Agent在替代前端，不如说它在把前端推到更核心的位置。

3.3 哪些前端经验迁移不了，要老老实实重学

只讲“前端好迁移”，那是鸡汤。我也必须说实话，有三样东西真的要从头学。

第一是“概率性思维”。前端习惯确定性：一个点击事件就该有明确结果。Agent不一样，同一个Prompt、同一套参数，结果可能每次都不一样。设计和调试都要接受这种不确定，并为此增加校验、兜底和人工介入。

第二是“上下文与记忆管理”。前端处理的是页面状态，Agent处理的是模型上下文窗口。你能把页面状态做成全局Store，但上下文窗口塞不下无限历史，必须设计摘要、裁剪、检索。这是一个全新的抽象层次。

第三是“成本意识”。前端页面多加载点图片，顶多是流量费；Agent多传一段文本，就是模型账单。这三个认知，比任何框架学习都重要，也是我第67天最大的思维变化。

4. AI Agent主流架构拆解：从“调API玩具”到“生产级系统”

4.1 先理解token，它是Agent的货币

我前面已经提过token，这里展开讲透。token就是大模型处理文本的最基本单位，你可以把它理解成“字符块”，英文单词按空格切，中文按字或词组切。模型按token计费，同时上下文窗口也有token上限。

生产级Agent里，一次调用通常不止用户的一句话。它至少包括：系统提示词、用户消息、历史会话摘要、工具调用结果、模型中间推理。我算过一笔账：一个自动化发布任务，如果设计不合理，一次任务可能消耗4万token；设计合理，可能只要5000 token，差距8倍。前端同学最容易犯的错，是像处理页面资源那样不心疼“内容传输大小”。我建议刚开始做Agent的人去开一个token用量监控报表，盯一周，你就会对提示词产生敬畏。

4.2 主流架构：单Agent、流程编排、多Agent协作

现在打开任何一家大厂的Agent白皮书，术语都很唬人。拆掉术语壳子，主流架构基本是三层半：

• 内核层：大模型本身，负责理解和生成。
• 能力层：工具调用（Function Calling）、知识库与记忆（RAG、向量数据库）、外部API。
• 协作层：单Agent循环（观察→计划→行动），或多Agent协作（规划Agent、执行Agent、审查Agent）。
• 支撑层：可观测、安全、评估、缓存、限流、人工介入。

单Agent循环我前面已经用到了。多Agent场景更复杂，比如“规划Agent”负责拆解目标，“执行Agent”负责调用工具，“审查Agent”负责检查结果。不是所有场景都需要多Agent，我见过很多团队为了架构好看硬上多Agent，结果token成本翻倍、错误更难追踪。常见原则是：任务链路短、依赖少，单Agent就够；任务复杂、需要不同角色质检，才考虑多Agent。

我当时在几个主流入口之间做了一轮对比，也给前端同行一个参考：

前端的建议是：先在可视化平台跑通业务闭环，再用编程框架按生产标准重写，最后才决定要不要自建。别一上来就挑战最难路线。

4.3 为什么总听到“基于Rust语言做AI Agent”

最近搜索榜上“基于rust语言ai agent”的热度很高，这背后确实有技术逻辑：Rust的性能和内存安全，很适合高并发的Agent运行时。很多Agent基础设施项目后来都用Rust重写了核心组件，主打低延迟和高吞吐。

但我对前端同行的建议是：语言别成为焦虑源。Agent工作的核心难点，是理解任务拆解、工具调用、上下文管理、反馈闭环。你用Python、TypeScript还是Rust，影响的是实现层面的性能，不影响你设计Agent流程的智慧。别人用Rust写核心运行时，我用TypeScript写业务编排，两者可以在同一个系统里共存。语言是工程选型，不是身份标签。

4.4 部署的两种路线：先托管验证，再自建沉淀

部署环节，我初期用托管平台比较多，因为它把模型调用、工具配置、日志监控打包好了，十分钟能跑一个Hello Agent。等练手项目成熟，再考虑自建。自建的好处是数据私有化、成本可控；坏处是自己维护模型运维、向量库和弹性扩展，对前端团队短期不是最优解。

纯前端线上免费部署过静态站点的同学，应该很熟悉“免费额度”这件事。Agent托管平台也类似，很多有免费额度，但只适合调试，不适合生产。等做生产级部署时，至少要考虑模型调用、向量库、服务转发这些费用。对了，再强调一次安全底线：API Key绝对不能进前端包，Agent的密钥、数据库连接、内部接口地址，一律走后端网关。这个底线我从Day 1喊到Day 67，等真的有人把Key泄露出去，你会感谢这句唠叨。

5. 白天带团队，晚上学Agent：一个Leader的转型管理课

5.1 时间从哪来：我的三段式时间管理

在职学习最现实的问题就是时间。我目前固定三段：

• 早晨6:30到7:30：读文档、看架构文章。这个时段大脑干净，适合吸收抽象概念。
• 午休前30分钟：刷社区里Agent实战帖，记录灵感，看到好工具就丢进收藏夹。
• 周末上午完整3小时：专门做动手项目，比如第2章那个自动发布Agent。

为了避免“切换成本”，我把学习资料全部收敛在一个笔记库里，按概念、架构、工具、踩坑、面试五个维度拆好，打开就进入状态，不浪费意志力。另外我刻意在工作日白天保持“完全不碰Agent学习”的纪律——Leader一旦在白天琢磨新技能，很容易被业务节奏拖垮预期。

5.2 把个人学习变成团队资产

一个人偷偷学，越学越容易被当成不务正业。我的解法是把它打开，变成团队实验项目。具体操作不复杂：每周五周会最后10分钟，分享一个本周学到的Agent案例，然后问团队一句：我们哪个业务痛点，适合拿来作为这个思路的实践？

这么做了四周之后，团队认领了两个试点：一个是用Agent做代码评审，自动从PR描述里提取变更影响点；另一个是把客服FAQ问答做成机器人。前者前后端协作，后者纯前端就能做。这些试点不一定都成功，但让每个人开始接触“Agent怎么和业务结合”。团队一起学，比一个人学的好处有两点：一是人多力量大，能相互补位；二是最终交付成果可以向上汇报，让老板看到这不是个人镀金，而是团队能力建设。

5.3 向上管理：用业务难题换学习空间

Leader转型很容易被质疑“心思不在业务上”。我的策略是“用业务难题换学习空间”。

比如老板说要做告警自动摘要，我接话：现有规则引擎只能做严重程度分级，摘要工作量大且容易漏，能不能拨一小块后端接口配合我做Agent试点？这种话术的关键在于，始终把Agent定位成“解决业务存量问题的工具”，而不是“我的个人兴趣”。老板看到的目标是降本增效，我看到的额外收益是技能迁移。

建议所有想转型的Leader都养成一个小习惯：每个试点项目都留一个“业务价值”段落放在周报里。不用夸大，就写清楚这个Agent替代了多少人工工时、准确率多少、还有哪些风险。这份记录，将来既是你向上要预算的依据，也是你写简历的素材。

6. 下一个七天计划：从Day 67到Day 74，我要做什么

6.1 把练手项目工程化，而不是停在Demo

自动发布Agent能跑，但代码还是“单体脚本+前端审核台”的糙样。接下来七天，我要做三件事：

一是把处理层从脚本拆成独立服务，加入QPS限制、幂等控制和错误重试。二是给审核台增加基于SSE的“Agent实时日志”，让运营能看着每一步动作进行核查。这既是体验优化，也是可观测性建设。三是补部署文档和回滚方案，尤其是密钥管理和环境变量配置。等这三件事做完，这个项目才算是一个能在简历和面试里真正拿得出手的完整作品。

6.2 把学习笔记整理成面试弹药

前端面试题大家都会刷，但AI Agent岗位的面试题其实有自己的一套。我整理了十几个高频题，比如：

• Agent和传统规则/流程编排的区别是什么？
• RAG是什么？什么时候不需要RAG？
• 工具调用的结果，要不要让模型“看到”？为什么？
• 多Agent协作相比单Agent的代价是什么？
• 如果Agent遇到Prompt注入，你会怎么防御？

每一道题，我都强迫自己用“前端能听懂的类比”写一遍，再讲给团队里的应届生听。能讲明白，才算真会。比如“工具调用的结果要不要给模型看”，可以类比成：前端调接口后把返回结果渲染到页面上，用户看到了，但页面也要决定哪些字段显示、哪些隐藏。模型看工具结果也一样，不是所有原始结果都应该塞回上下文，只摘出要用的信息，否则token和上下文都被浪费。

6.3 给同路人最后五条建议

第一，先别辞职。在职学习的压力反而是筛选器，能帮你看清自己是不是三分钟热度。真想清楚转行，至少坚持120天再考虑下一步。

第二，前端技能不是包袱，是最独特的入口。没有谁规定AI Agent只能长成接口文档的样子，它也需要有人把复杂流程设计得对人类友好，这是前端的老本行。

第三，花钱要花在刀刃上。我记账67天，最值钱的投资不是课程，而是token费。小项目跑十遍，胜过听十节理论课。

第四，远离“焦虑式刷帖”。每次打开搜索，热词都在滚动，刷多了反而不会动手。正确的姿势，是把一个热词变成一个小实验，比如看到“基于rust语言ai agent”，就去查Rust在Agent运行时里到底解决了什么问题，而不是焦虑自己不会Rust。

第五，给自己一个落地场景。内容发布、代码评审、简历匹配都可以，但一定要让真实用户用起来。反馈会逼着你把一个玩具项目，磨成真正的作品。

写到这里，正好是Day 67深夜。说实话，这种感觉很像我10年前第一次学Vue：白天写jQuery，晚上折腾脚手架，兴奋和焦虑对半分。不一样的是，以前焦虑“能不能学会框架”，现在焦虑的是“能不能在范式转移中继续提供价值”。但不管怎样，前端的13年让我学会一件事：任何值得做的事，开始的样子都是乱七八糟的。AI Agent这条路，我大概率还要走几百个Day，但有前端这块地基垫着，我不觉得自己是从零转行，更像是在原来的底图上叠一条新的等高线。

下一步，我打算把自动发布Agent的工程化过程整理成一篇带代码的实战拆解，包含前端审核台、Worker上传和token压缩三块。如果你也在用前端技术做Agent相关项目，欢迎在评论区聊聊你的选型和踩坑。