企业官网建设流程全解析

今天是我系统学习 AI Agent 的第 61 天。白天我刚开完前端团队的季度技术规划会，晚上坐在电脑前整理这一个多月的笔记时，忽然觉得应该把这些东西写下来。我做了八年前端，带团队两年，在别人眼里是标准的“资深开发”，但只有自己清楚：前端这个岗位的技术边界正在被 AI 快速重绘，而 Agent 就是那支最粗的画笔。

写这篇文章不是因为焦虑，恰恰相反，正是因为想清楚了一些事情，才敢在这个节点做个阶段性总结。如果你也是前端开发者，或是正在犹豫要不要了解 Agent 的技术人，这篇文可以帮你少走不少弯路。我会把这 61 天里学了什么、踩了什么坑、做了哪些实战项目、以及一个前端 Leader 为什么要转向 Agent 的逻辑，一次性讲透。

1. 第61天回望：一个前端Leader为什么开始学AI Agent

1.1 前端岗位的天花板，比想象中来得更早

先说说我自己的处境。在转学 Agent 之前，我日常的工作大概可以概括为：拆需求、定技术方案、排研发计划、review 代码、处理线上事故、陪产品经理聊边界。带团队之后，我写代码的时间肉眼可见地在减少，取而代之的是大量的“决策”和“沟通”。这个变化本身没什么问题，但它暴露了一个事实：前端技术栈的成长空间，已经支撑不起一个 Leader 的长期增量了。

你不妨回想一下，从 2020 年到 2025 年，前端的主流技术栈有什么本质变化吗？从 jQuery 到 Vue/React 是一次跨越，从 Webpack 到 Vite 是一次提速，微前端、Server Components、RSC 这些概念确实不断出现，但它们都还在“如何把页面做得更好”这个框架里打转。当一个领域的技术红利逐渐见顶，行业的关注点就会转向“用更少的人做更多的事”——这时候 AI 来了。

我不否认前端岗位的价值，但如果你在一个岗位上已经很难找到“非线性增长”的机会，那就必须给自己找一个新载体。2025 年到 2026 年，Agent 形态的产品正在从“聊天机器人”向“自动化工作流”进化，大量企业开始搭建自己的智能体。这个赛道缺的不是算法专家，而是能把 Agent 做成“产品”的人——这恰恰是前端工程师的机会。

1.2 我为什么不直接转后端，而是选择 Agent

决定转方向的那天，我认真列过几个选项：转后端、转算法、转产品经理、转 AI Agent。后端对我来说成本太高，Java/Go 那套高并发体系不是一年半载能补齐的；算法更是重灾区，数学基础摆在那里，硬啃不现实；产品经理倒是可以转，但多年的技术直觉告诉我，纯做产品会丢掉自己最大的优势——亲手把想法变成现实的能力。

最后我锁定了 AI Agent。

原因很直接：Agent 是一种“对话即应用”的新交互范式，它的外延是理解用户意图、拆解任务、调用工具、返回结果。这套逻辑和前端做的事情在本质上惊人地一致：前端也是在理解用户意图之后，把数据和状态翻译成用户能理解的界面。前端工程师做 Agent 有一个暗藏的优势——我们对“交互”和“状态流转”有天然的直觉。语音助手为什么难用？因为用户不知道它能做什么。怎么让 Agent 的能力可见、可控、可纠错？这是交互设计问题，而前端就是做这个的。

所以我的策略不是“放弃前端”，而是“给前端技能找一个不会被时代抛弃的载体”。

2. 前60天学习路线：从Prompt到大模型再到Agent框架

2.1 第一阶段（第1-15天）：先不急着写代码，把概念磨透

刚开始那几天我犯了一个典型的工程师范错误：一上来就想找一个 Agent 框架赶紧跑通一个 demo。结果看 LangChain 的文档看得一头雾水，什么是 Chain、什么是 Tool、什么是 Memory，全在脑子里打架。后来我停下来，先用一周多时间专门补基础概念。

这一步我建议大家不要省。至少要把下面这些概念彻底搞明白，否则后面调框架全是在抄代码。

Token 与上下文窗口：Token 是模型计费和长度计算的最小单位，一个汉字大约消耗 1-2 个 token。上下文窗口决定了一次能塞进多少信息。做 Agent 的时候为什么要关注它？因为你在设计提示词的时候，要时刻知道当前任务的“预算”是多少——系统提示词写了 2000 字，文档塞了 3000 字，用户问题写了 300 字，剩下还有多少空间留给模型输出？这个账一定要会算。

Temperature 与结构化输出：Temperature 控制模型的随机性。做 Agent 的场景里，如果你要模型输出 JSON 给程序解析，temperature 一定要调低，建议在 0.1 到 0.3 之间。我见过很多新手用默认温度跑结构化输出，结果模型花式给你编字段名，解析直接崩溃。

RAG（检索增强生成）的基本链路：把文档切成块，用嵌入模型转成向量，存进向量数据库；用户提问时，先做向量检索找出相关片段，再把片段拼进提示词一起发给大模型。这个链路前端理解起来完全不困难，因为它的本质就是一个“本地缓存 + 动态模板渲染”。

这一阶段我还做了一件比较重要的事：把要看的资料收敛成两个主源。一个是官方文档（比如 LangChain 的官方教程和 API 参考），另一个是大模型厂商的提示词工程最佳实践文档。少刷短视频平台的碎片教程，那些东西看着过瘾，但信息密度太低，看多了反而焦虑。

2.2 第二阶段（第16-35天）：理解Agent的核心循环，而不是只会调框架

概念补完之后进入框架学习。这里我先踩了一个大坑：花了很多时间研究框架的细节 API，但忽略了 Agent 本身的运行机制。后来我才认识到，所有框架的底层都是一套循环：感知（收到用户请求与上下文）→ 规划（决定下一步做什么）→ 行动（调用工具或直接生成回复）→ 观察（获取行动结果）→ 反思（决定是继续还是结束）。

我建议每一位前端同行都先亲手用代码实现一遍这个循环，哪怕是最原始的版本。我当时写了一个十几行的 Python 脚本，手动模拟“用户提问 → 模型决定调用函数 → 执行函数 → 把结果回传给模型 → 模型给出最终回答”的流程。就这么一小段代码，比我看十篇框架教程都管用——因为它把抽象概念变成了你能掌控的状态流转。

框架层面我当时对比了四个主流方案，各有各的定位：

我的建议是，如果你有编程基础，直接用 LangChain 入门，然后尽快切到 LangGraph。LangChain 最大的问题是做小 demo 很顺，一旦任务复杂，隐式的链式调用会让你难以调试。LangGraph 把流程画成一张图，状态一目了然，这对有工程化洁癖的前端来说非常友好。

2.3 第三阶段（第36-60天）：用三个小项目驱动，不看视频只看输出

学到这里，我已经不甘心只做笔记了。从第 36 天起，我给自己定了一条规矩：每个知识点，必须用一个能跑起来的小项目去验证。前前后后做了三个练手项目，难度递增，非常适合拿来检验自己的掌握程度。

第一个是知识库问答 Agent。把团队的内部技术文档喂进去，做一个能回答问题的机器人。这个项目让我把 RAG 全链路跑通了，包括文本切片、向量化、检索、提示词拼接。做完这个之后，我才真正理解了为什么切片大小和检索 TopK 对回答质量影响这么大。

第二个是自动周报 Agent。让它读取我这一周的 Git 提交记录、会议纪要、待办清单，自动生成一份周报草稿。这个项目让我第一次接触了工具调用（Function Calling）——Agent 通过调用预设函数获取数据，再根据数据生成文案。这个体验非常关键，因为它把 Agent 从“聊天”拉到了“做事”的层面。

第三个是多角色协作 Agent——用一个编排层同时管理“需求分析 Agent”和“代码审查 Agent”，让它们接力完成一个任务。这个项目踩了很多坑，但也让我真正理解了多 Agent 协作的难点：任务边界怎么划分、上下文怎么共享、结果怎么校验。这个经验后来直接用在了我给团队搭建的工具上，这部分我在第四章详细讲。

这三个项目做完，最大的感受是什么？是“跑通”和“能用”之间的鸿沟。demo 只需要证明路径可行，生产级还需要考虑稳定性、成本、权限、错误恢复。新手往往卡在“跑通”这一步就觉得自己会了，实际差得远。等到你做一个功能，需要考虑几十个并发、重复请求、模型随机失败的时候，工程的难度才会真正展露出来。

3. 前端背景在Agent开发里的真实优势：不是写页面，而是写交互

3.1 前端Leader的核心能力，恰好是Agent最需要的东西

很多前端同行考虑转 Agent 的时候容易自卑，觉得自己不会 Python、不懂机器学习，是不是没戏了？其实完全不是这样。经过了 61 天的学习，我越来越确信，Agent 产品当前最稀缺的能力不是算法调优，而是“如何让用户信任并高效使用一个 AI 系统”。

举个例子。你让一个 Agent 帮你规划一场旅行，它给出一个方案。用户面临几个问题：Agent 为什么要这么规划？它掌握了哪些信息？哪些条件是它猜的？如果我中途改变主意怎么纠正它？这就是交互设计问题。前端最擅长的渐进式披露（Progressive Disclosure）、状态可见性、异常态处理，全都是 Agent 产品需要补的课。

我在学习过程中做过一个很受启发的实验：给一个纯文本交互的 Agent 加了一层极简的可视化状态面板，让用户能看到“当前 agent 正在调用什么工具、检索了什么资料、生成了几个候选方案”。效果惊人，测试者对这个 Agent 的信任度明显上升，甚至愿意让它执行更复杂的任务。这背后的道理很简单：用户不怕系统笨，怕的是系统在暗处自作主张。前端工程师做 Agent，就应该把自己的思维方式带进去——让 Agent 的每一步行为都变得可见、可理解、可干预。

3.2 前端开发者转Agent最容易踩的3个坑

当然，八年的前端惯性也会带来一些思维定式，这些定式在 Agent 开发里可能会变成坑。

坑一：把 Agent 当成一个 UI 项目来做。刚开始我写 Agent 的时候，总是不自觉地先想“界面长什么样”“组件怎么拆分”，然后才开始设计业务流程。但在 Agent 项目里，核心是推理链路和工具编排，UI 只是入口。顺序应该是先想清楚 Agent 怎么决策、怎么调用工具、怎么处理异常，再考虑这些过程如何呈现在界面上。我见过不少项目，界面做得很漂亮，但底层 Agent 的规划逻辑一塌糊涂，用户一用就露馅。

坑二：过度抽象，一上来就封装各种 Class。前端工程师做项目习惯了高内聚低耦合，组件拆得细、抽象层套得多。但 Agent 学习阶段，我强烈建议先写能跑的直白代码，不要急着封装。Agent 的行为链路本身还不够稳定，过早抽象会让你在调试时多翻好几层包装，平白增加心智负担。我踩过这个坑——写了一个 500 行的 Agent 工具类，结果模型输出格式一变，我修了一个下午。

坑三：用“视觉反馈”代替“数据反馈”。前端做页面，好不好看、交互顺不顺滑，肉眼可见。但 Agent 的反馈是日志、是 token 消耗、是准确率、是用户留存。我刚上手的时候很不习惯，做出来的东西感觉不错，但不知道它实际效果如何。后来强迫自己学会建立评估集：准备几十条典型问题，每次改完都跑一遍，比较前后答案质量。没有这套流程，Agent 开发就和盲人摸象没有区别。

3.3 AI Agent也在反过来改变前端开发的方式

聊到这里，必须提一下“前端开发 skills”这个热词。2026 年的语境里，它有两层含义。一层是指 AI 辅助前端开发的技能包，比如让 Agent 帮你生成代码、审查代码、写单测、搭组件；另一层是指前端工程师自身需要掌握的新技能——怎么去定义 AI 的工作流、怎么把专业经验变成 Agent 可以使用的工具。

我自己在团队里做过一个试验：让一个代码审查 Agent 参与前端的 MR 评审。它的职责很单一——读取 diff，按团队规范检查命名、组件体积、是否有遗留调试代码、是否缺少错误处理。跑了一段时间后，效果是可见的，但离“完全替代人工评审”还差得远。这个试验更大的意义在于，它让我看到了前端岗位未来的走向：一部分重复性的代码工作会被 Agent 接手，而前端工程师的核心价值会转向定义规则、评估质量、处理异常。

所以我对“前端会被 AI 取代吗”这个问题的回答是：会被取代的是重复劳动，不会被取代的是对业务的理解和对用户体验的判断。90% 的页面都可以让 AI 生成，但“这个功能在这个场景下应该怎么设计才不让人困惑”这个问题，依然需要人来回答。

4. 第61天实战：从0到1搭建一个前端代码审查Agent

4.1 为什么坚持要亲手做一个“能落地到团队”的项目

学完基础、做完三个练手项目之后，我觉得自己缺的最后一个拼图是——真实业务场景的验证。练手项目的用户只有我自己，问题数量和评价标准都是自己定的，说服力不够。所以第 61 天，我挑了一个团队里真实存在的痛点来搭建 Agent：前端代码审查。

这个选择有几个理由。一是数据容易获取，Git 仓库里的 MR 历史就是现成的数据集；二是判定标准相对客观，代码风格和明显错误是可以枚举的；三是风险低，就算 Agent 判断错了，也只是多了一条评论，不会直接影响线上服务。对第一次做“生产级”Agent 的人来说，这是一个非常安全的试水场景。

选型上，我用了 LangGraph 做流程编排，模型用了 API 调用模式，向量库暂时没上——因为代码审查主要是基于当前 MR 的上下文，还不需要大规模检索。整套架构跑在团队已有的 CI 流程旁边，通过一个 Webhook 接收 MR 事件，异步触发审查任务。

4.2 核心流程设计与参数选择

这个 Agent 的工作流程设计成了四个阶段：

第一阶段是上下文收集。接收到 MR 事件后，从代码仓库拉取变更文件列表和每个文件的 diff，同时读取我们团队的代码规范文档片段。这里有一个关键操作：合并 diff 前先截断——单次提交可塞进提示词的 token 有限，文件过多时按变更行数排序，只保留最值得审查的文件，避免上下文被无关文件占满。

第二阶段是逐文件审查。每个核心文件单独构造一个审查 Prompt，要求模型以 JSON 格式输出发现的问题列表。每个问题包含四个字段：问题类型（可能值有命名规范、性能隐患、错误处理缺失、遗留调试代码、安全问题等）、严重级别（P0 必须修复，P1 建议修复，P2 可选优化）、具体位置（文件和行号）、修改建议。用 JSON 而不是自然语言输出，是为了让结果能稳定地被下游程序解析并渲染成 MR 评论。

第三阶段是汇总与分级。把所有文件的审查结果汇总，按严重级别分组过滤，去掉重复项。汇总这个步骤看起来简单，但实际上它决定了报告的可读性。如果 Agent 每个文件输出 5 条问题，10 个文件就是 50 条，工程师根本不会看。所以我会设定阈值，只保留 P0 和 P1 级别的问题，P2 只统计数量不展示细节。

第四阶段是报告生成与发送。把结构化的问题列表渲染成一段带 Markdown 格式的 MR 评论，@相关的开发者和评审人，并附上一句友好的提示：“本报告由 AI 自动生成，仅供参考，请结合上下文判断。”这句话很重要，它能显著降低团队对 AI 误报的反感度，让工具先被接纳，再被改进。

关键的几个参数我单独说一下。模型 temperature 固定为 0.1，因为审查任务需要稳定和保守，不需要创造性。单次审查的 max_tokens 设为 2000，避免单个文件生成超长报告拖慢响应。审查的 system Prompt 我至少迭代了五版才稳定——核心经验是：明确告知模型“只审查你确有把握的问题，不要猜测，不要在不确定时强行给出建议”。这条约束极大地降低了误报率，让报告从“看起来专业但胡说八道”变成了“偶尔疏漏但言之有据”。

4.3 实测效果与真实复盘：这个Agent到底好不好用

第一个版本上线那一周，我每天都会看它写的审查报告。真实的数据用一句话概括：查得出低级问题，查不出高深的逻辑错误。

好的方面是：遗留的 console.log、未使用的 import、明显不符合团队规范的命名、缺少 loading 状态的接口调用，这些高频问题基本能稳定检出。团队里几个初级工程师反馈，这个 Agent 的评论像“一个细心的老同事在旁边提醒”，节省了不少 wait for review 的时间。

不足的方面也很明显。首先是对跨文件逻辑的审查很弱——比如“A 组件修改之后，B 组件因为共享状态而受到的影响”这类问题，单 diff 粒度的审查完全无能为力。其次是误报率偏高，在 20%-30% 左右，主要发生在模型不理解业务上下文时，把一些合理写法误判为潜在问题。还有一个比较恼火的问题：模型偶尔会“幻觉”出不存在的行号，这就需要展示端做一次行号合法性校验，把不存在的位置过滤掉再上屏。

基于这些复盘，我下一步的改进方向也很明确：第一，在审查前引入静态分析工具（ESLint 等）做一次预筛选，让 Agent 只关注静态工具覆盖不到的语义问题；第二，把团队过往的 MR 评审意见做成一个小规模的知识库，用 RAG 的方式给 Agent 补充团队特有的偏好；第三，增加用户的“有用/无用”反馈按钮，把反馈数据回流，持续调整 Prompt。做这个项目最大的收获不是技术方案，而是体验了一次“真实场景中 AI 能力与人性化设计如何结合”的完整闭环。

5. 学习资源与技术选型避坑实录

5.1 学习资源避坑：别让“资料囤积症”拖慢你的进度

学习 Agent 的这 61 天里，我见过最多的一种人不是不学习的，而是学习资源囤积狂。今天收藏一篇“Agent 入门指南”，明天保存一份“Prompt 工程完整手册”，后天买一个“AI Agent 实战训练营”，硬盘空间消耗了不少，真正掌握的没多少。

我的建议是资料不要超过三份。一份大模型基础概念文档，一份你选定的主力框架官方文档，一份优秀的实战案例解析文章集。这三份资料反复精读，读到能不看文档写出代码的程度，远比看过一百个教程有用。判断有没有学懂的标准很简单：能不能把核心概念讲给团队里一个完全不懂 AI 的同事听，并且让对方听懂。我用了这个方法自我检验过，效果奇佳——讲不出来的地方就是还没懂的地方，回去补就是了。

另外一个避坑点是：警惕“框架追新”。AI 领域技术迭代非常快，今天热门的框架可能下个月就换了主力方向。我的做法是选一个成熟稳定的框架（核心不变的那一个），把它学透，而不是每周换一个新框架追热度。底层原理一旦通了，换个框架也就是适应 API 语法的事。

5.2 技术选型避坑：企业级Agent不是调API那么简单

练手可以随便用免费额度跑一跑，但如果你像我一样，最终目标是在团队和公司内部落地一个有点规模的 Agent 系统，技术选型就不能只看代码能不能跑通了。这里有几个问题我在第 61 天才深刻体会到，提前分享给你。

第一个是权限模型。Agent 调用工具的本质，是替用户执行操作。企业场景里，谁能命令 Agent 执行什么操作、Agent 执行操作之前要不要审批、操作日志存多久怎么审计，这些都不是技术 demo 里能预见的。MCP（模型上下文协议）现在成了 Agent 接入外部系统的标配协议，它虽然标准化了工具接入方式，但权限设计还是要结合企业自己的账号体系来做。这块如果你接触不深，一定会是上线前的硬伤。

第二个是评估体系。写一个 Agent 的代码，一周够了；建立一个评估 Agent 好坏的方法，可能要好几个月。我见过太多团队挣扎在“感觉自己做的 Agent 还行，但说不清哪儿行、哪儿不行”的状态里。建议从第一天起就给项目建一个评估集，维护好测试用例库，每轮改动后跑一次回归。这个习惯越早养成，后面迭代越轻松。

第三个是成本控制。大模型按 token 计费，一个复杂 Agent 跑一次任务可能调用几十次模型接口。如果不加节制，一个几十人的团队每天消耗的 API 费用完全可能远超预期。基本的优化手段包括：缓存重复请求的结果、用小模型处理简单任务大模型处理复杂任务、给上下文瘦身。我在自己的代码审查 Agent 里做了缓存和上下文截断之后，成本直接降了大概 40%。

5.3 在职Leader怎么挤出时间学新东西：我的时间管理心得

文章写了这么长，最后聊一个很现实的问题——在职前端 Leader 每天那么多会，怎么挤出时间学一个新方向？

我的做法谈不上优雅，但很实用。核心是“把学习变成日程里的固定块，而不是剩余时间的消遣”。我给自己定的节奏是：工作日每晚 9 点到 10 点半雷打不动学一个半小时，周末每天上午花大概三小时做项目写代码。平均算下来，一天大约投入两小时。61 天累计约 120 个小时，谈不上很多，但对于建立一套全新知识体系来说足够了。

同时我学会了一个技巧：让团队成为你的杠杆，而不是你的阻力。我会把自己学到的一些 Agent 知识做成简单的分享，在组会上讲给团队成员听，一方面是倒逼自己整理和输出，另一方面也能吸引团队里对 AI 有兴趣的同学一起参与。后面做代码审查 Agent 的时候，组里一个前端同学主动承担了展示端的所有开发工作，我只需要专注在 Agent 逻辑本身。不要试图一个人扛下所有事，做 Leader 的人最该懂这个道理。

还有一点我觉得比时间管理更重要，那就是接受“学不完”的状态。Agent 领域的知识边界比前端还要大，LLM、RAG、多模态、Agent 框架、评估体系、产品设计，每一条线都能往里钻很久。我的策略是：从当前项目需要什么就学什么，以实战拉动学习，而不是试图先精通所有理论再动手。学不完没关系，保持“下一个问题驱动下一步学习”的节奏，你会发现进步反而是最快的。

写在最后

61 天前，我给自己定的目标是“搞懂 AI Agent 到底是什么、能做什么、我应该怎么参与”。现在回头看，这三个问题的答案都在实践中渐渐清晰了。AI Agent 不是某个神秘的技术黑盒，它是一套“用大模型驱动自动化决策与执行”的方法论——而方法论这种东西，最怕的不是理解不了，而是不去亲手碰一次。

对于和我一样背景的前端开发者，我最后想说的是：不要把自己定义成“写页面的人”，要定义成“把复杂系统变得可理解、可使用的人”。Agent 时代需要大量这样的人。前端这些年积累的交互直觉、工程规范、审美判断，放在 Agent 产品里不但不过时，反而是稀缺资产。下一步我打算继续沿着这条路往下走，下一步的目标是把自己做的代码审查 Agent 升级成一个更像“完整产品”的东西，围绕它做一套轻量的运营面板，让团队其他成员也能自定义审查规则。路还很长，但方向已经清楚了。