企业官网建设流程全解析

1. 第66天，我从前端Leader的工位上“长”出了Agent触角

Day 66。晚上十一点，合上电脑，我给自己写了这段复盘。白天的身份还是那个前端Leader，主持周会、排需求、评审组件方案；夜晚的身份则切换成一个磕磕绊绊学AI Agent的普通开发者。这个双线作战的状态已经持续66天。为什么坚持？因为我在前端这条路上能摸到的技术天花板越来越清晰：组件库、微前端、性能优化、工程规范，每一样都做过几轮，再往下大多是重复。而AI Agent正在重新定义软件的交互方式和自动化边界，作为天天跟UI、交互、SDK打交道的的前端，这个时候不参与进去，以后大概率只能站在旁边看别人重构我们熟悉的领域。这篇文章就是写给两类人看的：一类是想转AI Agent、但又怕丢掉前端积累的同学；另一类是正在带前端团队、想给团队找新方向的Leader。内容全部来自我这一步一步踩出来的记录，不鸡汤，也不装高深。

66天放在学习周期里其实很尴尬：第一周兴奋得睡不着，第二周开始怀疑自己是不是从零学错了方向，第三周到第六周在“要不要报个班”和“算了还是自己啃吧”之间反复横跳。真正出现质变是在第五十天之后，我开始能像拆前端需求一样，把一个Agent拆成“模型调度、工具执行、状态维护、异常兜底”四个部分来讨论，而不是把它当成一团魔法黑盒。第66天，我觉得可以做一个阶段性存档，把摸索出来的学习路径、认知迁移、实战经验和踩过的坑写清楚。先给结论：前端转AI Agent不是从零开始，而是把过去十年积累的工程化思维、组件抽象能力、异步交互经验，整体迁移到一个新载体上，只是这个载体跑起来比以前的前端应用更聪明，也更难控制。

1.1 前66天的学习清单：我没有一上来就啃LangChain

很多前端朋友听到我想做Agent，第一反应是问：你天天在啃LangChain文档吧？真不是。我前面整整两周都在干一件特别“土”的事：把大模型API当成一个普通HTTP服务来调。先手动搞定请求、流式输出（SSE）、并发控制、重试机制和超时处理。推理很简单：Agent跑得再花哨，和外界通信的底层就是HTTP请求和事件流，前端本来就熟悉请求/响应模型，这块几乎是无缝衔接。两周之后，我才开始接触LangChain和LangGraph，而且不是逐字读文档，是拿一个小项目边跑边查，报错一次查一次，效率远高于系统啃官方教程。

我的学习主线大致是四块：第一，Function Calling / Tool Calling，这是Agent的灵魂，必须亲手调通；第二，提示词工程，不是写营销文案那种提示词，而是把System Prompt当成“页面入口文件”来设计，控制上下文、注入约束；第三，Agent框架，LangGraph这类偏工程化编排，ReAct循环偏原理；第四，Rust社区里的Agent实现，用来补性能和并发这块的课。66天里我实际手敲的代码量不算大，但阅读量非常大：看了阿里云AI Agent白皮书、主流开源框架的系统设计文档、还有一堆源码仓库，一边看一边做笔记，把别人的选型理由吃透。这个方法很适合在职的人，时间零碎，没法一条龙学完，但你有前端底子，只要抓主干就能快速跑通。至于LangChain全家桶，我的建议是真不要作为第一站，它的抽象层级太多，初学者很容易花几周时间学框架API，最后却说不清Agent内部的循环到底长什么样。先手搓一个最小助手，再去看框架，你会恍然大悟：哦，原来框架只是在替我做这些事。

1.2 为什么前端Leader转Agent是“顺路”而非“跳崖”

我反复被团队同事问：你去学AI Agent，是不是等于放弃前端了？我的回答是：不是放弃，是升级应用场景。Agent的本质是什么？是一个循环，循环里有一个大模型负责推理，有一组工具负责执行，有一些状态需要维护。你把这个结构拆开看：推理、执行、状态维护，这不就是前端应用一直干的事吗？前端页面的本质是一个状态机，用户交互是事件，页面渲染是副作用。Agent的循环同样可以理解为“收到事件，模型决策，工具执行，状态更新，再次决策”。唯一的区别是，原本的“用户点击”变成了“模型调用”，原本的“DOM更新”变成了“工具副作用”。想通这点，前端那套“状态管理 + 事件驱动”的经验就直接平移过去了。

作为Leader，我转Agent还有一个隐形的优势，就是系统设计视角。当一群人在讨论怎么让Prompt更聪明时，我习惯先想清楚网关层、权限层、日志链路和异常兜底。举个例子：前端调用后端接口经常做超时、重试、降级，我在Agent的工具调用里同样设计了超时和降级策略，模型调某个工具超时就主动返回“暂时不可用”，再引导用户换一条路径。这种习惯不是我转型之后才学的，是过去几年做前端架构沉淀下来的。所以我越来越觉得，前端转Agent不是“跨界转行”，而是把做UI的功力，转移到了做行动层和表现层的Agent产品上，这个过程中真正稀缺的，恰恰是工程化而非魔法化的AI能力。

2. 前端十年，原来都在为Agent做预演

2.1 组件化思维和Agent编排思维是同一套方法论

我在前端团队里推行组件化很多年：一个按钮组件，对外只暴露props和事件，内部状态自己维护；一个业务组件，组合多个基础组件，对外提供更语义化的接口。这套方法论放到Agent世界里，几乎可以原样迁移。你看Agent的编排：一个工具函数就是一个“组件”，入参是JSON Schema，相当于props；出参是一个结果对象，相当于emit事件。一个子Agent就是一个“业务组件”，内部可以调用多个工具，对外只暴露角色描述和能力清单。想通这件事之后，我设计Agent工具库的方式和设计前端组件库完全一样：先定义接口，再实现内部逻辑；工具之间不直接互相调用，全部通过调度层转发；每个工具自带错误码和重试策略。这样维护成本极低，因为新增能力只是加一个“组件”，而不是改一堆面条代码。

反观一些纯后端转来的开发者，没有组件化习惯，容易把Agent工具写成一个巨大的函数，里面塞满各种if else分支，Agent一复杂就彻底失控。要我说，能用props和事件讲清楚的东西，就不该写在全局变量里；能用组件边界约束的东西，就不该让模型自由发挥。前端Leader做Agent编排，熟悉的味道全回来了。还有一个特别像的点，就是Token管理。我经常提醒新人控制组件体积，避免一个页面塞一堆无关依赖；在Agent里同样有“上下文体积”问题，每次调用都会把System Prompt、工具描述、历史消息一起打包发给模型。你可以把Token消耗理解成页面加载体积，把上下文窗口理解成移动端内存，只是优化手段从压缩JS变成了压缩Prompt、精简工具描述、做历史消息摘要。放一张对比表，大家感受会更直观：

这张表我打印出来贴在工位上，每次看都更确信一件事：前端人做Agent，不是从零开始，是把语法换了一套，思维模型还是那套。

2.2 前端SDK、组件库经验在Agent开发中怎么用

热搜词里有一串前端关键词：前端SDK、直播H5、大文件上传、微前端qiankun、组件库。这些看起来和Agent毫不相关，实际上都是Agent能力的地基。举个例子，我最近在做“直播数据智能播报Agent”的实验：它要读直播间的实时状态，然后生成一段主播可以照着念的话术。这个Agent真正的难点不是Prompt，而是怎么稳定拿到直播数据、怎么处理WebSocket消息的乱序和断线重连、怎么把半结构化数据清洗成模型容易理解的文本。这恰恰是前端SDK和H5适配最擅长的事。没有前端经验的人走到这一步会非常痛苦，我要做的只是把现有直播SDK封装一层，再加一个数据清洗函数，就能把数据干干净净地喂给模型。AI前端这个话题，不是让前端去做AI，而是让前端做AI的感官和手脚。

再比如大文件上传：普通开发者关心“传完没有”，前端开发者会关心分片、并发、断点续传、失败重试。你如果要做“文档解析Agent”，让用户上传超大文件然后自动抽取信息，这些前端工程能力就是Agent稳定性的基石。我做Agent调用文件工具时，习惯给工具加“进度事件”和“取消信号”，这就是从大文件上传组件里带出来的肌肉记忆。还有qiankun微前端，里面的“子应用隔离”思想，到了Agent世界就是“插件隔离”：给每个工具独立的权限声明、按需加载工具描述、不让模型接触无关上下文。我甚至觉得，如果要把Agent做成可插拔平台，微前端的注册表、生命周期、沙箱模式都可以直接借鉴，只是把注册“子应用”改成注册“工具技能”而已。前端简历里写的那些“熟悉组件库设计”“熟悉微前端架构”，在转Agent时全都是有效资产，只是名称换成了“熟悉Agent工具库设计”“熟悉Agent插件机制”。

2.3 前端安全视角让我提前意识到Agent的边界

前端安全工作给人的印象是“防不住”：JavaScript是开放的，页面源码随时可以查看，接口可以被抓包，爬虫可以模拟浏览器点击。干了十年前端，我们对“客户端不可信”这件事有刻骨铭心的体会。这个体会放到Agent上，反而成了重要优势：很多Agent开发者默认“模型输出是可信的”，但我的第一反应恰恰相反——“模型的输出不可信，工具的执行结果同样不可信”。我做Agent时的安全清单包括：第一，防提示词注入，用户输入里夹带“忽略之前所有指令”之类的内容，要像防XSS一样处理，过滤敏感指令；第二，工具权限最小化，Agent默认没有删库、没有写入、没有发消息等高危权限；第三，所有高风险操作必须人工审批，绝不安排模型一把梭。

这套思路就是前端“防爬虫、防止源码查看、防止控制台被乱改”思路的升级版——前端做的是“坏人别进来”，Agent做的是“模型别乱跑”。如果你的简历里有两三个前端安全相关的项目，转Agent时不但不亏，反而比很多后端同行更有边界感。举个例子，我做消息助理Agent时，最开始把“发送消息”和“保存草稿”写成一个工具，测试的时候模型直接给一个联系人发了条消息，吓得我立刻把权限拆开。从那以后我就记住了：前端安全教你的不是“什么都能防住”，而是“默认不信任任何输入，重要操作必须拆分和复核”。这句话在Agent世界里同样适用，作用甚至更明显。

3. 主流Agent架构，我按“前端路由”的方式硬啃下来的

3.1 ReAct循环、工作流、多智能体，对应的是前端开发里的哪些概念

我啃Agent架构的时候，脑子里全是前端类比。ReAct循环，英文是Reasoning + Acting，模型先思考，再行动，然后观察结果继续思考。这个循环和前端开发里的“编辑-保存-刷新-看报错”几乎同构：你写一行代码是一个Action，浏览器执行后输出报错是Observation，你根据报错重新修改，一轮轮迭代直到页面正常。理解了这一个循环，你就理解了为什么Agent不是一次性调用API，而是一连串有状态的调用。很多人调通了一次模型API就觉得会做Agent，其实只走出了第一步，后面的循环和工具调用才是重头戏。

工作流（Workflow）强调的是预定流程，比如先做意图识别，再做信息抽取，再调用某个工具，步骤像流水线。这对应前端开发里的“页面生命周期”：页面加载、数据请求、渲染、用户操作、卸载，每一步都有明确顺序和触发条件。多智能体架构则更像微前端拆分：一个大型Agent拆成多个子Agent，每个子Agent有独立职责、独立记忆、独立工具，它们通过消息或共享总线协作。如果你管理过微前端拆分，对多智能体拆分会非常容易上手，因为核心工作一模一样：划清边界、定义接口、处理通信。我强烈建议前端转型者先手搓一个不依赖框架的最小Agent循环：用一个模型API，配合两个纯函数工具，在命令行里跑起来，一步步复现“思考-调用-观察-再思考”。我会用日志打点的方式观察每一次模型请求的输入输出，就像用Network面板看请求链路一样。这个“最小可运行系统”比任何框架教程都管用，跑通一次之后，框架带来的神秘感就消失了。

3.2 Token、Function Calling和角色Prompt成了我的“新三件套”

Token这个词，前端的第一反应是“登录令牌”，但在大模型语境下完全是另一回事。Token是文本切分的最小单元，可以粗略理解成一个字或一个词。Agent每调用一次模型，都会把一大段文本编码成Token发送过去，Token数量直接决定响应速度和调用成本。前端转Agent必须对Token有体感：一个中文字大约等于1到2个Token；一段完整的工具描述可能占几百Token；一次对话如果带了很长的历史记录，可能轻松上千。我习惯在开发环境里打印每一次调用的Token消耗，像关注首屏包体积一样关注它。有次在讯飞实时语音转写大模型的前端适配实验里，我发现识别文本一长，整个上下文的Token立刻膨胀，响应延迟肉眼可见，这就是典型的“上下文体积失控”。

Function Calling是Agent调用工具的关键机制。你提供给模型一组JSON Schema描述的函数，模型根据用户意图决定调用哪个函数、传入什么参数，但真正的执行发生在你自己的代码里。这一步对前端来说非常亲切：它就像后端给前端SDK暴露接口，远端模型只是“智能参数填充器”。调试Function Calling时，我最常遇到两种问题：模型生成了非法参数，以及模型幻想出不存在的方法名。处理方式与前端做参数校验一模一样：定义JsonSchema时尽量用enum限制取值范围，执行前再做一遍强校验，非法参数直接丢弃并返回错误。角色Prompt则是把Agent调教成稳定助手的第一关：System Prompt负责稳定人格和边界，工具说明负责精确描述能力，人设负责回答语气。前端写页面时，HTML是结构、CSS是样式、JS是行为，这三者的分工跟Prompt的设计逻辑很像。我每周都会改角色Prompt，就像每周改组件代码一样，改完顺手跑一批固定问题做回归——我管它叫“Prompt单测”，方法很土，但非常有效，防止这周改爽了下周又退回原形。

3.3 基于Rust的AI Agent，为什么让我一个前端看得两眼放光

热搜词里有一条“基于Rust语言AI Agent”，我承认我最近也入坑了。一个前端为什么要关心Rust？因为AI Agent早晚要从浏览器里的玩具走向系统级的长时运行任务：高并发工具调用、强资源控制、边缘部署。Python生态虽然方便，但性能、打包、部署都偏软，稍微跑重点任务就气喘吁吁。Rust写出来的Agent可以编译成单一二进制，部署起来极其简单，还能编译成WebAssembly在浏览器侧运行，这本来就是前端玩家的主战场。我在本地跑过一个用Rust写的Agent样板，编译确实慢，但跑起来的内存占用比同等逻辑的Python小了一个量级，并发能力也强很多，那种“硬核”的感觉很对胃口。

前端学Rust的痛我很清楚：所有权、借用检查器、生命周期，第一周直接劝退。我的建议是别把它当“第二语言”去系统性学习，先把它当“工具链”来用：只需要看懂main函数、async/await、结构体、序列化这几个概念，然后照着现有的Rust Agent项目抄作业、改参数。甚至可以先从“看懂别人的代码”开始，慢慢熟悉再动手改。现在很多桌面端Agent软件都是Rust写的，遇到KDE Wayland下输入法前端由kwin启动这种系统级适配问题，也绕不开Rust社区。对前端来说，我建议的路线是先写Agent逻辑，再慢慢啃Rust细节，不要一开始就卡在所有权上。毕竟做Agent的核心竞争力仍然是场景拆解和工程落地，Rust只是让你把这件事做得更稳、更快、更省机器。等哪天你想做一个需要长时间后台运行、对性能敏感的Agent服务，回来看Rust，你会感谢那个曾经被借用检查器骂哭的自己。

4. Day66实战复盘：搭一个半自动社交消息助理Agent

4.1 需求拆解：先做减法，不做“全自动轰炸”

最近总看到类似“让账号自动发消息”的讨论，我Day66的实战，也做了一个方向接近的实验：半自动社交消息助理。它负责读取指定平台的未读消息，根据预设规则生成回复草稿，但“最终发送”必须由人点一下确认按钮才能完成。我刻意不做全自动发送，原因有两个：一是合规风险，未经核查的AI私信很容易变成骚扰信息，这锅我背不起；二是产品逻辑，全自动发送一旦被提示词注入劫持，后果不堪设想。这个“必须人工审核才能发出去”的设计，其实沿用了我做管理后台时最熟悉的“提交后待审核”模式。Agent可以做99%的工作，但最后1%的风险动作必须留给人。

需求拆成三个子任务：消息采集、意图判断、草稿生成。消息采集负责把未读消息拉下来，并去掉明显重复的内容；意图判断让模型区别这是咨询、投诉、广告还是闲聊；草稿生成则针对不同意图写回复，并自动进入审核队列。这个拆法跟我拆前端业务模块一模一样：数据层、决策层、执行层彻底分离。很多人做Agent一上来就追求全自动闭环，结果在一条垃圾输入上把整个系统坑死。我坚持做减法不是保守，而是工程成熟度。Agent项目能不能长期维护，取决于它的边界是否清楚，而不是它的自动化率有多高。

4.2 工具与代码骨架：我习惯先画接口再写实现

我开发前端时有个执念：先定义接口，再写实现。做Agent我也这样干。先定义一个send_reply工具，入参包括会话ID、回复内容、意图类型，返回一个草稿ID。再定义一个read_messages工具，返回消息列表。这些工具的描述写成类似OpenAPI风格的JSON Schema，模型读到了就知道什么时候该调用、该传什么参数。下面是一个简化版示例：

{ "name": "send_reply", "description": "把AI生成的回复草稿提交到人工审核队列", "parameters": { "conversation_id": {"type": "string"}, "draft_content": {"type": "string"}, "intent": {"type": "string", "enum": ["consult", "complaint", "ad", "chat"]} } }

主循环用Python写，核心流程是：拉取消息列表，让模型判断每条消息的意图和紧急度，调用生成回复的工具，写入审核队列，最后人工在管理面板点击发送。写这段代码的过程中，前端经验一直在起作用：我会自然想到消息列表分页怎么办、超长内容怎么截断、失败重试会不会造成重复回复。于是我给了send_reply工具一个幂等键，用“消息ID加会话ID”生成唯一key，同一消息被重复调度时直接返回已存在草稿ID，不会生成两条回复。这个细节其实是从“防止前端按钮被双击重复提交”里学来的。第二天下午我花了五个小时，调通了主流程。过程中遇到的最大问题是模型把“广告”意图误判成“咨询”，导致生成的回复语气完全不对。我没有靠加提示词硬压，而是给工具增加了一个“意图置信度”输出，低于阈值就不生成草稿、直接转人工。这样一来问题就变成了一个产品规则，而不是反复调Prompt碰运气。

4.3 踩坑清单：这些坑，前端人一眼就能看懂

第一坑是上下文截断。当会话历史超过模型窗口后，我一开始直接把最旧的消息丢掉，结果模型对前面的信息一无所知，回答得牛头不对马嘴。修复方案是做滚动摘要：每次调用前，把太旧的消息用摘要模型压缩成一段摘要，作为历史上下文的一部分。这就像前端长列表不能全部渲染一样，你得做“虚拟滚动”，只保留对当前渲染有意义的部分。第二个坑是工具调用超时。某个采集工具偶尔会卡住，Agent循环就永远卡在那里了。我给工具调用外包了一层超时和重试逻辑，一旦超时就返回“暂时不可用”，模型就会换一条路径接着走。第三个坑是权限。早期我把“发送”和“保存草稿”放进了同一个工具，测试时模型直接发了一条测试消息出去，吓得我立刻拆分工具权限。教训就是：Agent的高风险动作永远要单独一个工具，而且默认需要审批，没有例外。

这些都是很小的工程问题，但如果你没有前端处理边缘情况的习惯，很容易在Demo阶段就忽略掉它们。Agent能不能从“玩具”变成“工具”，看的不是一次调用多聪明，而是异常分支兜底得多好。前端Leader在这方面有天然优势，因为我们每天处理的就是用户乱输入、网络抖动、浏览器兼容性爆炸这些脏活。把这些经验迁移过来，比会写几句花哨的Prompt重要一百倍。

5. 白天带前端团队，晚上学Agent：转行节奏真实记录

5.1 我把周会技术分享改造成“Agent+前端”实验场

第66天，我还做了一件让团队气氛不太一样的事：把周会的技术分享从“组件方案评审”调整为“Agent+前端”小实验。我真实的想法是：不是逼全组转行，而是要让每个前端都看清，AI不是来抢工作的，是来吞掉重复劳动的。我们组已经开始用Codex这类编码辅助插件做代码审查之前的预检，虽然偶尔会给出不靠谱的建议，但过滤明显烂代码的效果还行；还有人尝试用Agent给测试组生成用例，准确率还不稳定，但方向是对的。作为Leader，我最大的收获是：团队同学看到Leader在学新东西，焦虑感会下降，对新工具也愿意主动试了。如果Leader天天说“你们要拥抱AI”，自己却一动不动，团队只会觉得是在画饼。

我甚至把前端的“技能清单”直接搬到了Agent开发里。前端开发Skills、前端组件库、qiankun微前端、大文件上传Worker、登录态、传参、安全操作，统一整理成一份内部文档，名字就叫“可Agent化的前端能力”。以后团队想从一个页面工具变成Agent工具，直接从这份清单里挑能力去封装就行。前端Leader转型的最优解，我认为不是一个人闷头学，而是把过去练出来的管团队、定规范、做架构的那套本事，用在“带着团队一起摸Agent”上。一个人走得快，但一个团队一起试错，才能走得更远。Day66的我已经不满足于自己会，我开始想让团队里的每个前端都能用Agent的视角重新看一遍自己的老手艺。

5.2 给还在观望的前端Leader几条实在建议

第一，不要裸辞。在职学习确实痛苦，但你还有稳定的现金流和团队资源，试错成本低，遇到问题可以找团队一起讨论。裸辞之后压力会逼着你速成，反而容易学变形。第二，不要从深度学习原理入门。很多前端一听AI就觉得自己要先学反向传播、Transformer，大可不必。正确路径是“调API、写工具、搭循环”，先让Agent跑起来，再回头补模型原理。第三，每天给自己留两小时，最好在睡前，雷打不动写代码。Day66就是这么来的，不拼单次强度，拼连续天数。中间有几天我加班到很晚还是爬起来写了半小时，不为别的，就为保持手感。第四，找一个真实需求当主线项目。给团队做个周报汇总Agent，或者给客服组做个知识库问答Agent，都可以。真实需求会逼你解决权限、超时、并发、审核这些框架教程里根本不会教的问题，做完一个，比看十篇文档都有用。

最后说句掏心窝的话：学AI Agent最难的其实不是技术，是身份转换。我白天是Leader，说话要谨慎，习惯先给结论再讲依据；晚上是学习者，要接受自己什么都不懂、一遍遍看文档。这种撕裂感在第三十天左右最强烈，我甚至想过放弃。但到了第66天我发现，这两套身份已经开始合流：白天带团队讲Agent架构，晚上学Agent时用Leader的思路管工具边界。这种融合，大概是这66天里最值的一笔收获。Day66不是终点，只是一次存档。接下来我打算继续啃Rust生态的Agent框架，同时把消息助理项目打磨到能真正给用户用。如果你也是前端背景，也在犹豫要不要学AI Agent，我的真实建议是：不必等到准备好再开始，你现在写的那行React代码、修的那个浏览器兼容Bug、设计的那套组件接口，都是未来Agent世界里用得上的硬功夫。我们改天继续。