企业官网建设流程全解析

1. 为什么一个写了十年前端的人会盯上AI Agent

先交代一下背景：我本职是前端团队的Leader，React、Vue、Node写过一轮又一轮，业务组件库、性能优化、工程化基建这些事基本都摸到了天花板。真正让我开始认真考虑AI Agent的，不是铺天盖地的新闻，而是一次具体的工作体验。

当时团队接到一个需求，要给内部运营做一个数据周报的自动解读功能。传统做法是：后端把数据吐出来，前端画图表，再写一堆文本模板把结论拼进去。但我们发现，运营真正想要的不是“数据展示”，而是“你直接告诉我这周该关注什么、为什么、下一步怎么调”。这个需求用固定模板根本做不出来，因为解读的逻辑依赖上下文、依赖历史数据、依赖业务目标，完全是动态的。当时我就意识到，这类问题已经不是传统前后端分工能优雅解决的了，它需要一种能自主理解、规划、调用工具的智能体。也就是从那一刻起，我决定认真学AI Agent。

坚持到第72天，我最大的感受是：前端工程师往AI Agent方向走，并没有想象中那么远的距离，但也绝对没有网上说的那么轻松。这篇内容就当是给自己做个阶段性复盘，也希望给同样在职、想往这个方向靠的同学一些真实参考。我不会聊那些“AI要取代程序员”的焦虑，只聊这一百多天里我实际做了什么、踩了什么坑、哪些前端经验能直接用、哪些必须推翻重来。

2. 前两周最大的弯路：把AI Agent当成了另一个框架去啃

2.1 我犯的第一个错误：从LangChain源码开始学

很多有工程背景的人学新东西，都有一个惯性：先看官方文档，再啃源码，搞明白原理再动手。我前两周就是这么干的，结果非常低效。

我当时的计划是“先把LangChain核心组件吃透”，于是每天下班后看两个小时的文档和源码，看ReAct、看Chain、看Memory、看Tool。但问题是，我没有一个具体场景去承载这些概念。文档看得再多，也只是在脑子里堆名词。你可以想象一下，一个刚从C++转Java的人，不去写项目而是先把Java集合源码全看一遍是什么感受——看的时候觉得都懂了，合上电脑什么都写不出来。

两周下来，我唯一记住的东西就是：Agent的本质是“让大模型能调用工具、能自我规划”的一套运行时框架。但具体怎么设计Prompt、怎么接Tool、怎么处理模型返回的各种意外，我完全没有概念。

2.2 转折点：把目标从“学会框架”改成“做出一个能回答业务问题的机器人”

第三周我彻底调整策略，不再看框架文档，而是锁死一个场景：做一个“团队内部知识库问答机器人”。这个场景足够小，但又足够完整，它天然需要走完一条链路：文档解析、向量化、检索、Prompt组装、大模型调用、结果返回。这就是RAG（检索增强生成）的完整闭环。

我把这个机器人当成了一个真实的上线项目来做，而不是学习练习。然后我发现，整个学习速度完全不一样了。因为每遇到一个问题，都是真实业务逼着我去解决，比如：

• 文档PDF有表格，解析出来是乱的，怎么处理？
• 检索回来的片段太多了，塞进Prompt会超token上限，怎么办？
• 用户问的表述和文档关键词对不上，怎么提高召回率？
• 模型答非所问的时候，怎么让Prompt里的指令更有效？

这些问题没有一个是看文档能看出来的，全都是动手之后才会暴露的。大概到第四周，这个机器人已经能比较准确地回答我团队的入职文档问题了。那一刻我才有了一种“我确实在学新东西”的实感。

2.3 给后来者的一条血泪建议：先定场景，再选技术栈

我现在回头看，前两周的弯路本质上是“技术思维”的惯性害了我。AI Agent这个领域和传统软件开发最大的不同是：传统开发的复杂度主要在代码和架构上，而Agent开发的复杂度主要在场景拆解和不确定性处理上。你不把一个场景跑通，就永远不知道问题会出在哪个环节。

所以如果你也是刚入门，我的建议很简单：不要从框架文档开始，不要从大模型的API文档开始。先找一个你日常工作里真正烦人的、重复性的文字处理任务，把它做成Agent。哪怕只是“自动把会议纪要整理成任务清单”这种级别的需求，都足够你跑通第一遍全流程。跑通了，再回来读框架文档，你会有完全不同的体验——那些名词会变得鲜活。

3. 前端技能迁移地图：哪些能直接用，哪些必须推翻重学

3.1 能直接迁移的：组件化思维、状态管理、API设计

先说好消息。前端工程师有几项能力在AI Agent开发里不仅有用，而且是稀缺的。

第一是组件化思维。深度求索这类大模型的API本身返回结构化数据，但你要真正做出一个像样的Agent产品，依然需要把“能力的边界”拆得很清楚。比如一个Agent系统里，知识检索器、工具调用器、对话记忆模块、输出格式化模块，本质上和前端组件一样需要高内聚、低耦合。我在设计Agent的工作流时，习惯画组件树，这套方法论无论是写React还是写Agent，底层是相通的。

第二是状态管理。Agent的核心就是“多轮状态下的决策循环”。模型每次回复之后，上下文怎么累积、工具返回结果怎么注入、哪些历史信息要压缩，这些问题和你做Redux、Zustand时思考的“状态从哪里来、到哪里去、怎么变”完全是一回事。前端多年的状态管理经验让我在理解Agent记忆机制时几乎没有障碍。

第三是API设计。Agent要接各种Tool，本质就是设计函数接口——入参、出参、错误处理、幂等性。这跟前端对接后端接口是同一个思维模型。我前几周写Agent的工具调用时，几乎不需要额外学习。

3.2 必须推翻重学的：从确定性思维到概率性思维

这是我这72天里最难跨越的一道坎。前端开发里，代码逻辑是确定的：输入相同，输出必然相同。但Agent不一样，模型每一次返回都有概率性，哪怕Prompt完全一样，上一轮能跑通的流程，下一轮可能就在某个环节出了幺蛾子。

举个具体例子。我做代码审查Agent的时候，设定好了Tool让模型去读取一个文件的内容并输出修改建议。第一次测试完全正常，但第二次跑同样的代码，它跳过读取文件的步骤，直接编造了一个“可能是问题”的内容。原因就是模型在决策路径上选择了另一条路——它觉得自己不读文件也能回答。这在传统工程里几乎是不可想象的Bug类型。

所以做Agent开发，你不可能像以前一样追求“功能正确”，而是要把重心放在“流程韧性”上。具体来说：

• 每一步模型输出都要做校验，格式不对就重试或者降级。
• 关键操作要有“人工确认”的兜底，尤其是有写入、删除这类不可逆动作的时候。
• 设计Prompt时就要给模型“不知道就说不知道”的选项，让它避免胡编。

我花了大概一周时间，才从“代码必须一次跑对”的心态切换成“跑对是运气，跑错是常态，我的工作是把跑错的概率从30%降到5%”。这个心态转不过来，Agent开发会非常痛苦。

3.3 前端经验被严重低估的地方：交互直觉

还有一个角度可能很多人没想过：Agent产品最终是要面向用户的，而这个“用户界面”恰恰是前端工程师最擅长设计的。市面上一堆Agent产品之所以难用，不是模型能力不行，而是交互设计很糟糕：用户不知道怎么给Agent下指令，不知道它现在在干什么，不知道它为什么做这个决定。

我给团队做Demo的时候，特意设计了类似浏览器DevTools的“Agent行为透视面板”，让用户能看到当前Agent正在思考什么、准备调哪个工具、已经拿到了什么信息。这个设计让内部试用者的信任度提升了一大截。你看，这就是前端经验的价值：你比纯后端或者算法背景的人更理解“人怎么才愿意信任一个AI系统”。这种能力放到Agent产品里，非常稀缺。

4. 第30天到第60天：我实际跑通的三个Agent项目复盘

4.1 项目一：内部知识库问答Bot（RAG链路）

这个项目就是我前面说的入门项目，技术栈选择了LangChain框架加开源的向量数据库来支撑文档检索流程。整个链路是这样：把团队的文档（Markdown和PDF）批量解析成纯文本，按固定字数切片，每片做向量化之后存入向量库。用户提问时，先向量检索出最相关的几段文本，再把这些文本和用户问题一起交给大模型生成答案。

这套系统跑通本身不难，难的是质量优化。最开始检索回来的片段经常不相关，我当时排查了很久才发现问题出在切片策略上——我用固定字数来切文档，导致一个完整的技术概念被拦腰截断，向量化之后语义变得很奇怪。后来改成按标题层级感知的方式切片，即优先按Markdown的二级标题作为边界来切分，实在超过阈值再往下切，相关的准确率一下就提上来了。

另外一个坑是大语言模型本身的“幻觉”问题。我最初没有在Prompt里明确要求“如果检索到的资料中没有答案，必须直接拒绝回答”，结果它经常一本正经地编造公司制度内容。后来加上了一条强约束指令，并把它放在Prompt靠后的位置（有相关实践表明大模型对指令的末尾内容更敏感），幻觉率才显著下降。

4.2 项目二：自动化代码审查Agent（工具调用链路）

第二个项目是和本职工作的结合，一个自动审查Pull Request的Agent。需求很明确：每次新提交PR的时候，自动拉取变更代码，针对每个文件调用模型去检查潜在问题，输出分类列表。

这个项目的核心难点在于工具调用的稳定性。Agent需要完成一系列动作，比如读取PR信息、拉取文件内容、逐文件分析、汇总报告。每一个动作在模型看来都是一次“要不要调用工具”的决策，而模型经常会在某一步犯迷糊，比如重复调用同一个工具，或者调用了工具却不处理返回值。

我把这个问题的处理思路说详细一点，也许对你有用。我采取的是“强约束工作流”方案：把流程拆成四个阶段，每个阶段用独立的LLM调用，而不是让一个Agent从头跑到尾。阶段一负责提取变更摘要，阶段二负责逐个文件做审查，阶段三负责把单文件结果汇总成分类报告，阶段四负责最终润色和格式化。虽然这样丧失了“全自动规划”的灵活性，但换来的是可控性。对于工具开发场景，可控远比炫技重要。

4.3 项目三：多Agent协作的实验性Demo（多角色设计）

第三个项目是我最感兴趣的方向，多Agent协作。我搭了一个两角色协作的实验系统：一个“研究员Agent”负责分析问题、检索文档、整理信息，另一个“审查员Agent”负责质疑它的结论、检查引用来源、指出漏洞。两者把各自的输出汇总后，再由一个“决策者Agent”生成最终结论。

说实话，这个项目的效果比预期要好。让两个Agent互相“挑刺”之后，生成的方案质量比单一Agent明显高出一截，尤其是幻觉比例降低了不少。但问题也很明显：成本翻倍还不止，响应时间从3秒变成了8秒，而且两个Agent偶尔会陷入“无意义的自我否定循环”——审查员说有问题，研究员修改，审查员又说有问题，但问题是同一个。后来我不得不加了一个“最大迭代轮数”的硬性限制，并让审查员每轮只能提出最高优先级的一个问题。

这个项目我并没有直接应用到团队生产环境中，但它的实验价值很大。它让我实证理解了为什么AI Agent领域把“编排（Orchestration）”看得那么重——多个智能体协作，表面上像是开会讨论，实际上更像是一个“有收敛条件的分工流程”。如果每个人开会时不知道什么时候停止争论、谁做最终拍板，那会议就会无限延长。这跟多Agent协作的困境是完全一样的。

5. 第61天到第72天：从“会做Demo”到“能上线”之间的那些坑

5.1 成本与延迟是比正确性更现实的问题

前60天我做的东西都在本地跑，模型调用的浪费程度基本无感。到了第61天，我想把知识库问答Bot真正挂到团队日常使用时，第一个被质疑的问题就是：一次问答要花多少钱、多慢？

我做了个粗略统计：一次完整的RAG问答，大概要消耗输入token约2000多、输出token约500多，按当时使用的模型价格计算，单次成本大概在几分钱。听起来不多，但如果团队200人，每人每天问20次，一天就是数百块规模的成本，自己实验玩和真正生产运营相差巨大。

延迟问题更直接。用户等待回答的时间如果能控制在3秒内，体验感会好不少；而我最初因为“检索+输入拼接”的流程没做优化，首字返回时间经常卡在5秒以上。后来我把检索和模型调用改成流水线并行，同时把向量库索引参数调整了一下，延迟才降到了可接受范围。

这件事给我的启发是：AI Agent工程与传统的“功能开发”不一样，它更接近“系统运营”。上线只是第一步，你得盯着单次成本、并发、超时重试、日志追踪。这也是为什么现在行业内强调Agent工程化，而不是单纯强调模型有多强。

5.2 评估体系缺失会让优化变成玄学

第65天的时候，我尝试优化Prompt，想提高知识库Bot的回答准确率。改完一版Prompt，凭感觉测了几个例子，觉得“好像变好了一些”。但再测几个例子，又觉得“好像变差了”。这时候我才意识到，我根本没有一个可量化的评估体系。

后来我借鉴了一线实践中见过的方法，建立了一个最小可用评估集：把日常团队里高频问的30个问题，连同标准答案，整理成一个固定测试集。每次改Prompt或者调整检索参数之后，都跑一遍这30个问题，按“准确/部分准确/错误”三级打分，用对比结果来量化判断改动是否有效。就这么一个简单的动作，让我的迭代效率起码提升了一倍。之前我花一下午凭感觉调Prompt，效果全凭运气；现在半小时跑一遍测试集，哪里有问题一目了然。

这里我想多说一句：网上很多教程教你“几句Prompt技巧就能提升响应质量”，但到了实际场景里，最重要的不是技巧，而是你有没有一套能证明技巧有效的评估手段。没有评估的优化，本质上就是自信地瞎改。

5.3 日志和可观测性：前端调试经验的一次降维应用

传统前端开发里，我们习惯在浏览器里打开DevTools看网络请求、看控制台报错、看状态变化。做Agent开发时，我发现很多新人根本没有“Trace”的概念——出错了不知道是哪一步出的错，不知道模型当时收到了什么、输出了什么。

我自己因为是前端出身，天然就习惯“找一个能全链路观察的视图”。所以我从第一天接触Agent开始，就养成了给每个关键步骤打印结构化日志的习惯：用户输入了什么、检索到了哪些片段、模型最终返回了什么、用了多长时间。这些日志就是Agent世界的“DevTools”。没有它，排查问题就像闭着眼睛修Bug，基本靠猜。

市面上其实有一些Agent可观测性工具，但我个人经验是：在小规模阶段，不必要引入额外组件，用最简单的本地log文件就够了。等真正需要多人在线协作调试时，再考虑更完整的链路追踪方案也不迟。关键是得有这个意识，而不是等出了生产事故再补。

6. 在职搞转型，Leader身份到底是加分还是减分

6.1 时间从哪里来：我一天的碎片式学习安排

有很多人问我最多的问题是：你还有团队要带，怎么挤得出时间学这么深？我确实没法像全职学习那样有大块时间，所以我的安排很务实:

• 早晨7点到8点半：雷打不动的两个小时，用来读论文节选、研究概念、调试头一天留下的问题。这段时间大脑最清醒，适合做需要专注的事。
• 工作日零碎时间：通勤路上、午休半小时，用来刷相关的技术讨论帖、行业长文，不适合写代码，但很适合积累认知。
• 周末：留出半天以上做项目实战，把本周学到的东西落到代码里。

第72天回头看，真正让我坚持下来的不是意志力，而是“让学习产出直接回流到工作里”的正循环。我做的知识库Bot直接让团队找文档的效率提高了，代码审查Agent也实实在在帮我省了一部分Review时间。这些正反馈让我觉得时间不是被偷走的，而是被“投资”了。

6.2 Leader身份的隐性红利：用团队需求倒逼自己学习

说实话，如果我只是一个没有业务场景的个体学习者，可能第30天就放弃了。但作为团队Leader，我天然有一个优势：团队里有大量真实的、重复的痛点可以拿来做Agent的落地场景。我不用凭空想象需求，需求就在身边。

比如我观察团队日常时候发现，新人入职前两个月大量的时间花在翻历史代码、找文档、问同事“这个模块为什么这么设计”上。这些问题的底层模式本质上都是“信息检索和信息综合”，非常适合做成Agent。我就顺理成章把一个“团队项目问答助手”立项成了自己练手的方向。这种用真实需求倒逼学习的方式，比任何学习计划都有效。

6.3 给同样在职想转型的人三个实操建议

如果你也是在职状态，也在考虑要不要往AI Agent方向走，我基于这72天的感受给你三个建议。

第一个建议：不要裸辞，不要全职备考式的学习，边工作边用小场景试。AI Agent领域变化太快，今天学的框架可能下个月就更新了。裸辞全职学反而容易因为失去业务场景而学成“纸上谈兵”，不如在工作中找切入点，让业务来验证你的学习成果。

第二个建议：用一周时间做个最小闭环，再决定要不要深入。比如做一个“会议记录整理Agent”或者“周报生成Agent”，把完整链路跑通一次。如果你觉得这个过程让你兴奋，那你大概率适合继续深入；如果只觉得麻烦和不确定，那AI Agent可能不是你想象的那样，即使转型也要重新评估。

第三个建议：不要只看教程，要建立一个持续关注的技术信息源。这个领域每个月都有新模型发布、新工具推出，没有稳定的信息输入渠道，很容易掉队。我个人的方法是关注几个高质量的技术社区和一线开发者的长文输出，每天固定时间刷，保持认知更新。这比收藏一堆“XX速成课”有价值得多。

7. 第72天的真实心态：焦虑少了，方向清晰了，路还很长

现在回头看我第1天的状态，焦虑是很明显的：担心赶不上这波变化，担心前端经验会作废，担心学不会Python。到了第72天，Python我已经能熟练写日常脚本和Agent项目了，但我反而更平静了。因为我理解了：AI Agent不是一个“学会就毕业”的技能，它是一整套需要持续迭代的工程方法论。

你说一个写前端的人学AI Agent需要精通LLM底层原理吗？我的答案是：基本不需要。你需要的是理解它的能力边界、调用方式、反馈闭环，然后用自己的工程经验去设计稳定可靠的产品。这个定位，恰好是前端工程师最熟悉的领域——“把不可控的东西封装成可控的接口”。

我这72天里最受用的一句话，是一位前辈在某次技术分享上说的：未来的应用开发，核心不再是“页面上画什么”，而是“系统如何理解人、调度资源、完成任务”。前端依然有价值，但它会变成整个智能系统体验层的一部分。我现在做的事，就是让自己在保住前端基本盘的同时，向上摸一摸“系统如何理解人、调度资源”这一层。这种探索本身，就已经让我对工作有了完全不同的热情。

最后再分享一个关于个人学习的小技巧：记录每天的进展，哪怕只有三行字。我的笔记软件里有一个“DAY72”的标签，每天记录当天学到了什么、卡在哪个问题上、解决了没有、下一步计划是什么。这个习惯让我在面对“学了这么多怎么还是不会”的错觉时，能翻到一个月前的记录，看到自己明显的进步。如果你也在转型的路上，强烈建议你这样做——时间会给你答案，但前提是你得留下时间的刻度。