企业官网建设流程全解析

DAY71，这个数字对我来说不是打卡游戏里的计数，而是一个在职前端Leader在每天早上七点和晚上十一点之间硬挤出来的学习日志。我做了很多年前端，团队不大但事情不少，需求评审、排期、答疑、上线，几乎把每个白天都切成碎片。今年年初我突然意识到，如果不主动换一条增长曲线，后面五年大概就是把前五年的经验重复一遍。于是我开始系统学习AI Agent，到今天刚好71天，终于能说一句：这不是一时冲动，而是一次认真的工程转型。

这篇文字不是什么成功学日记，也不是“零基础三个月转行”的速成指南。它是我从一个带过项目、写过组件、被业务反复折磨的前端Leader视角，对过去71天学习AI Agent的一次完整复盘。我会把每个阶段踩过的坑、验证过的路径、算过的成本账都写出来。如果你也是前端，也考虑过把AI Agent当成下一个技术方向，这篇文章应该能给你省下不少试探成本。

1. 前端Leader为什么转行学AI Agent：先说说这三个真实原因

1.1 前端的天花板不是技术，是问题域太窄

我在一线写代码的时间超过十年，从切图到工程化，从单页应用到大前端，几乎所有前端技术浪潮都赶上了。但这两年我越来越清楚地感觉到一件事：前端技术的复利效应在递减。组件化、微前端、可视化搭建，这些东西做来做去，解决的依然是“如何把界面更快更好地呈现给用户”。问题是，当业务增长放缓，产品形态稳定，界面呈现这件事本身能创造的价值会越来越有限。

作为Leader，我每天的工作重心早就从“怎么写好一个组件”变成了“怎么让团队产出更稳定”。需求评审、排期、跨部门沟通、线上问题跟进，这些事务性工作占据大量时间。我可以熟练地画架构图，也能手写一套发布流程脚本，但夜深人静的时候，我发现自己已经很久没有解决过“业务真正疼”的问题。前端很靠近用户，却很难深入业务决策。看板上的数据就摆在那里，运营同事想从中得出结论，还得靠后端写SQL、靠分析同学跑报表。这种隔阂一直在提醒我：问题域太窄，能力就没有杠杆。

AI Agent给了我一个完全不同的角度。它不关心你写的是React还是Vue，也不关心你的页面像素是否完美。它关心的是“一个目标能不能被自动拆解、执行、校验、交付”。这让我第一次感受到，技术可以越过界面，直接作用于业务流程本身。

1.2 所谓转行，其实是把前端能力迁移到新的载体上

很多人听到“前端转AI Agent”会觉得跨度很大，我自己在DAY1的时候也这么想。但真正学下来之后，我的结论是：这不是转行，而是同一套工程能力换了一个载体。

前端的本质是什么？是把复杂的信息结构和交互逻辑转译成用户能理解、能操作的产品。AI Agent的本质是什么？也是把复杂的业务目标和工具能力转译成模型可调用的流程与上下文。两者都需要做需求拆解，都需要设计边界条件，都需要处理异常分支。我这些年写前端锻炼出来的能力——对用户意图的敏感、对状态管理的执念、对异常路径的警惕——在Agent工程里全部用得上。

我做的最快一个验证是：把前端团队平时最烦的发布检查流程写成一个Agent。原来我们要在发布前人工核对有没有未提交的代码、有没有未通过的检查、接口变更是否通知下游。这些规则逻辑其实非常简单，但要用代码写成一个“会主动巡检、会汇总结果、会提醒人”的小系统，我发现自己前面十年的前端经验没有浪费。状态管理、异步流程、错误处理，简直是为这场景量身准备的。

所以，想转行AI Agent的前端同行们，完全可以放下“我是不是要从零开始”的焦虑。你要补的是大模型、Prompt、 Function Calling、RAG这些新知识，但你的产品感、工程化能力、对用户体验的直觉，都是别人短期学不走的优势。

1.3 DAY71意味着什么：已过冲动期，还在继续

学习这件事，最怕的是头七天的热情和第七十天的倦怠。DAY71对我来说是一个有说服力的节点：第1天我可能只是刷了几篇科普文章，第7天我可能还在琢磨API怎么调，第30天我差点因为一个诡异的Token报错放弃，第60天看到网上层出不穷的新Agent项目又开始自我怀疑。但我还在写代码，还在记日志，还能把项目往前推，这说明我已经不是靠新鲜感在撑，而是把它当成了一个新的专业方向在经营。

2. DAY1到DAY70完整学习路线：我用七周从零跑通一个Agent

2.1 前30天：先把大模型当黑盒用起来，别急着研究原理

学习AI Agent最容易犯的第一个错误，就是上来就啃Transformer论文、注意力机制、反向传播。不是说这些不重要，而是对一个在职的、还有业务压力的人来说，这个切入点太容易劝退。我前30天只坚持一条原则：先把大模型当黑盒，把它当成一个“很聪明但偶尔会犯糊涂的外部服务”，尽快跑通所有基础的API调用。

我第一周主要在做最笨的事：注册、鉴权、发起一次对话请求，然后处理返回。接着开始研究消息结构。很多人不重视这个，其实system、user、assistant这三层消息结构决定了你后面能不能做出稳定效果。我的理解是：system放的是这个AI的角色、任务边界和输出格式要求；user放的是当前用户的诉求；assistant放的是模型自己之前生成的内容。多轮对话就是不断把新的user消息和旧的assistant消息拼进同一个数组再发过去。

第二三周我开始处理流式输出、超时重试、并发限制。这一步相当磨人。你会发现一个接口在不同网络环境下表现差异很大，你以为模型卡住了，其实是连接超时或者服务端限流。我当时用TypeScript写了一个简单的封装函数，把“发请求、收流、解析完整文本、自动重试”这几件事包进去。这个封装后来成了我自己Agent项目的底层模块，虽然简陋，但每一行都是自己踩坑踩出来的。

第四周我把目标收敛到一个能用的东西上：一个命令行工具。给它一段需求描述，它调用大模型返回一份结构化的前端任务拆解，包括改动点、涉及组件、风险项。功能很糙，但第一次真正感受到“模型+代码”能替代一部分管理动作时，我被震到了。这个阶段我没有碰任何Agent框架，因为我知道如果连裸API的脾气都没摸清，框架反而会成为黑盒。

2.2 中间20天：补原理，才敢动手搭Agent工程

前30天让我有了一些手感，但也让我很不踏实：我不知道为什么同样的Prompt有时候返回稳定有时候乱飘；不知道Token消耗为什么这么快；不知道把一堆文档塞给模型为什么会变成一本正经地胡说八道。第31天开始，我给自己补了大概20天的原理课。

最先补的是Token和上下文的关系。我印象很深，有一次我向模型提问，仅仅因为历史消息没做裁剪，单次请求的Token数就翻了四倍，响应速度明显变慢，费用也肉眼可见地涨。Token不是“字数”，而是模型内部的一种基本单位。这也解释了一个常见现象：你问一个长问题时它突然“变笨”，因为前面的长文本把它有限的上下文窗口占满了。搞懂这个，你才会主动去控制每次请求到底塞了多少内容。

接着是Embedding和向量检索。我当时的实用场景很明确：公司内部有几十份操作文档，我想让模型回答“某某功能怎么配置”。如果每次都把全部文档塞进Prompt，既不现实也浪费。用Embedding把文档切成小块并转成向量，用户提问时先把问题转成向量，在向量库里做相似度检索，把最相关的几段取出来拼进上下文，这个流程就是RAG的雏形。

我拿这个思路做了一个小工具：把团队历史故障文档做好索引，运维和开发同学提问时，它能自动给出“可能是哪里出了问题、上次是怎么修复的”。效果谈不上惊艳，但至少回答有出处，我可以做到“答案后面附上引用来源”。这一步我第一次理解了为什么RAG是Agent落地中的重要拼图：因为模型的知识有截止时间，但企业内部的实时知识必须通过检索喂给模型。

2.3 后20天：从写Demo到搭Agent骨架

前50天做完，我还在跟单轮问答较劲。真正让我觉得自己在“做Agent”而不是“做大模型调用工具”的，是后面这20天。

我开始研究Function Calling，也就是让模型在回答过程中主动声明“我需要调用某个工具，参数是什么”，而由你的代码去实际执行这个工具，再把结果返回给模型。这个机制太关键了。它把模型从一个“只能输出文字的系统”变成“可以操作外部世界的系统”。我第一次实现的时候，模型说“我要查天气”，我的代码就去查天气接口，然后把结果拼回去，模型再基于真实天气数据生成一段像模像样的回答。那一刻我很清楚，这就是Agent的基本单元。

随后我逐步加上循环：模型提出目标、拆解步骤、调用工具、观察结果、修正下一步。一个完整的Agent骨架就是“目标、工具、记忆、执行循环”。我开始理解那些网上流行的Agent项目为什么能做那么多看似神奇的事，其实底层都是这个循环，只不过它们加了更多工具、更多记忆机制、更多包装。

在这个阶段我也开始看一些Agent框架的设计思路。我故意没有直接用框架，而是先看它帮你封装了什么：Tool的注册方式、Memory的存储策略、Orchestrator的执行顺序。看完之后，我再用几十行原生代码去复刻一个最小版本。这个“复刻”的过程非常值，因为你会意识到框架解决的是通用问题，而你的业务场景往往需要定制化裁剪，一旦没有底层理解，出了问题就只能靠猜。

3. DAY71实操复盘：一个带记忆的数据分析Agent是怎么卡壳的

3.1 当前任务：做一个“能记住上下文”的对话式数据分析Agent

71天这个节点，我在做的项目是一个面向运营同事的对话式数据分析Agent。场景很具体：运营同学在后台输入“上周每天的新增用户是多少”或者“用户从注册到下单的转化漏斗在哪一步流失最多”，Agent自己把自然语言转成SQL，查数，再把结果用自然语言呈现出来。

我选这个场景是因为它同时踩中了几个核心点：第一，这是真实高频需求；第二，它需要理解数据库Schema；第三，它需要调用执行SQL的工具；第四，多轮对话中用户很可能会追加条件，比如“不算测试账号”“只看iOS端”，这对记忆管理是个考验。作为一个前端Leader，我太喜欢这种能直接嵌入业务场景的题目了。

3.2 具体实现：工具注册、上下文裁剪、多轮记忆

我先处理的是工具层。Agent需要两个核心工具：一个是查表结构，一个是执行SQL。为了让模型不直接面对满屏的库表信息，我维护了一份字段字典，提前把常用表名、字段名、注释、常见筛选值整理好。用户提问后，Agent第一步是调用“查表结构”工具，只检索最相关的几张表和字段，再把结果拼进上下文。

这里有个关键设计：SQL执行工具加了安全护栏。账号是只读账号，SQL强制加LIMIT，超时设置为10秒，禁止执行INSERT、UPDATE、DELETE。对内部工具来说，安全措施做得再多都不为过。如果模型生成了超出限制的语句，工具会返回一条错误说明，模型根据错误信息自己修正。

多轮记忆是我这次的主攻方向。一开始我图省事，每轮都把完整对话历史重放给模型。结果第5轮对话的Token消耗就已经很难看，而且模型会被早期错误信息带偏。我换了一个思路：维护一个结构化状态，记录“当前已经确定的筛选条件”和“用户最新问题”。每次请求只把状态摘要和当前问题发给模型，不再重放全部历史。效果立刻不一样。

下面是我当天写的核心循环，用TypeScript写的，跑通之后很有成就感：

interface AgentState { filters: Record<string, string[]>; lastQuestion: string; lastResult?: string; } async function runAnalysisAgent(question: string, state: AgentState) { const plan = await client.chat({ role: "system", content: readSystemPrompt(), role: "user", content: buildContext(question, state), }); for (const step of plan.tools) { if (step.name === "query_meta") { const metas = await queryFieldDict(step.arguments); return client.chat({ role: "user", content: formatMeta(question, metas) }); } if (step.name === "execute_sql") { const rows = await executeReadonlySql(step.arguments.sql); state.lastResult = summarizeRows(rows); return client.chat({ role: "user", content: state.lastResult }); } } }

抽象思路不复杂，实际调起来问题不少，下面单独说。

3.3 当天踩的坑与排查过程

第一坑：模型生成的SQL字段名完全不对。它把user_id写成了uid，把created_at写成了create_date。原因很好理解：大模型训练数据里，常见命名和小写风格跟我们的库表完全不一样。我的解决方案是两步走：一是在查表结构工具返回的字段字典里，明确标出“这个字段在业务里一般怎么称呼”“在哪个页面上叫什么”，让模型有依据；二是要求模型在生成SQL前，先把涉及到的表名、字段名列出来，跟字典做个核对，确认无误再执行。这样虽然多了一步，但准确率提升非常明显。

第二坑：多轮对话状态下，Token膨胀很快。我把历史记录全部重发之后，第五轮已经超过两万个Token。排查时发现，每一轮都带着上一轮完整的SQL结果，这些结果特别占空间。我把它改成“只把SQL结果摘要成三行关键数据”，比如总数、均值、最大最小值。对于不涉及数值的查询，就只保留“查询成功，未返回内容”这个状态。这一刀下去，上下文长度直接砍掉了四分之三。

第三坑：Function Calling的循环重试。某一次工具返回SQL执行超时，模型没有换思路，反而用同样的SQL重试了三次，浪费了时间和Token。我在排查日志里看到这个循环，才发现我的循环逻辑里少了“最大迭代次数”和“错误分级”。后来我规定：同一个工具错误最多重试两次，第二次失败后模型必须换一种方案，比如改写SQL，或者直接向用户说明当前无法查询。这个限制需要在系统提示里写清楚，代码也要在循环层做硬保护，不能只依赖模型自觉。

排查这类问题的心法，是让Agent的每一步都可观测。我习惯在关键节点打结构化日志：当前问题是什么、调用了哪个工具、工具返回了什么、下一次模型请求的上下文有多长。有了这些中间产物，定位问题就不是玄学，而是像以前调前端接口一样，看请求、看响应、看状态。

4. 模型、框架和成本控制：Leader视角的工具选型账本

4.1 模型选择：API、开源、本地推理怎么平衡

作为一个管理者，我选模型的时候会先问三个问题：数据能不能出内网？性能要求是多高？单位成本预算是多少？这三个问题的答案决定了选型方向。

如果业务场景涉及用户隐私或内部敏感数据，最稳妥的做法是把数据本地化。这种情况下，开源模型加私有化部署就是必选项。哪怕模型效果比一线商业API差一点，但“数据不出域”这一条就值回运维成本。反过来，如果是一些相对通用的办公场景，比如写周报、拆需求、翻译文档，那直接调用商业API反而更划算，因为自建一个高性能推理服务的前期投入可能要分摊到大量调用上才能回本。

我个人的策略是“分级用模型”：简单分类、信息抽取、意图识别这类任务，用参数小、成本低的模型；复杂推理、代码生成、多步规划这种任务，才用能力更强的模型。Agent内部也可以分区，比如第一步识别用户意图用便宜模型，后面的SQL生成和结果解释用旗舰模型。这个思路跟后端做技术选型一样，不存在一个万能方案，只有与场景匹配的取舍。

4.2 框架用不用？我的取舍标准是复刻一遍再看缘分

关于Agent框架，我的态度经历了一个从怀疑到理解再到怀疑的循环。刚开始我觉得框架实在太方便，几行代码就注册好工具和记忆；后来发现框架帮你隐藏了大量细节，一旦遇到依赖报错、状态冲突、自定义工具不生效，排查成本极高；现在我处于“能少用就少用，用也要先理解原理”的阶段。

我的判断标准很简单：如果一个功能我用原生代码五十行内能写出来，那我就不引入框架。比方说，一个简单的“模型判断意图、调用工具、返回结果”的管线，最核心的部分可能只要几个函数，犯不着为了它去学一套抽象概念。但如果是多Agent协作、复杂记忆策略、并发任务调度这种高复杂度场景，我会认真考虑要不要站在成熟框架的肩膀上。关键不是“用不用”，而是“你对它的运行机制有没有把握”。没有把握的东西，一旦出问题就是深夜流调现场。

4.3 给团队算一笔账：Token、缓存、按需调用

成本控制看起来是管理和财务的事，但工程上如果设计不当，它会变成一笔完全失控的费用。我给一个后台数据分析Agent算过一笔账。一次完整查询请求，系统提示词大约要消耗两千个Token，查表工具返回的字段描述大约三千，SQL执行结果如果全量塞回去又是五千，再加上历史状态和模型输出，一次对话轻松过万。如果一个运营团队有二十个人，每人每天问二十次，一个月下来成本就会变成可观的数字。

所以我在工程层面加了几个降本设计。第一是缓存：高频问题的SQL结果缓存十分钟，相同问题在缓存有效期内不再调用模型生成；Embedding结果也做持久化，避免每次重复计算。第二是工具结果摘要：把SQL结果裁剪成关键统计值再送回模型。第三是限制输出长度，模型生成的自然语言答复控制在几十个Token以内，只回答结论和关键数据，不做长篇解释。

从成本分摊角度，我建议每个Agent项目在初期就接入用量追踪。谁在调、调了多少次、平均Token数是多少、哪个场景最烧钱，这些指标必须一眼能看到。否则等月底账单出来再心痛，就来不及了。

5. 给同样想转行AI Agent的前端同行的三个误区和五点建议

5.1 最容易掉进去的三个误区

第一个误区是认为Agent就是写Prompt。我见过不少前端同学，学习一周就开始研究各种花哨的提示词技巧，以为“提示词写得好，Agent就强”。实际做下来，Prompt只是入口，Agent的稳定性来自工程化：工具的边界是否清晰、数据准备是否充分、错误处理是否健全、链路是否可观测。同样一个Prompt，在有严格工具约束的工程里和裸奔的对话框里，表现天差地别。

第二个误区是只收藏不实践。网上的Agent教程、框架文档、案例分享多得看不过来，但如果你没有亲自把一个小项目跑到线上，所有的知识都只是“看过”。我会强迫自己每个阶段都要交付一个能用的小东西，哪怕只是命令行工具，只要它真实运行过，就能引出大量书本上看不到的问题。

第三个误区是盲目追求新工具。每隔一阵子就有新的Agent框架、新的模型、新的“神器”出来。如果你总在追赶最新的玩具，就很容易陷入“每天学新东西但没一个深入”的循环。我的做法是：锁定一个主线项目，所有新技术都在这个项目里验证，验证通过才引入。主线项目是一根锚，能帮你过滤掉很多噪音。

5.2 学习节奏和精力管理

在职学习最难的不是技术，而是精力。我带团队的时候，白天几乎每半个小时就被打断一次，根本不可能进入深度状态。我的节奏是：工作日的晚上固定留出90分钟给Agent项目，周末至少留出半天做整块开发。碎片时间用来读文档、看案例、想方案，但是写代码这种需要连续思考的事情，必须放到不被打扰的时间段。

另外一个很有效的策略是把学习目标拆小。每个晚上只给自己定一个不超过一小时就能验证的任务，比如“给工具增加一个超时处理”“把系统提示词里的一层逻辑抽出来”。完成一个小任务的正反馈，比追逐一个宏大目标更能支撑长期坚持。

5.3 让学习成果落地：作品集、复盘和公开输出

我一直鼓励身边的同事把学习过程公开记录下来。这不是为了展示自己，而是因为“讲清楚”是“理解透”的最好验证。每周我都写一篇技术复盘，内容包括这周做了什么、遇到了什么问题、怎么排查的、结论是什么。回过头看，这些笔记比很多课程都更有价值，因为它们记录了我当时的真实思考，而不是事后整理的光鲜总结。

作品集也不需要多高级，关键是要能展示完整链路。哪怕是一个“日报自动生成Agent”，只要它能调用外部数据、处理用户输入、生成结果并配置了错误处理，就已经比一百个Demo都更有说服力。面试官或者合作方想看到的不是你背了多少概念，而是你是否有把一个不确定的东西一步一步变成确定工程的能力。

6. 写在DAY71之后：我还在继续的原因

如果要说这71天最大的变化，我觉得不是技术上的，而是我对“能力边界”的理解变了。以前我是看着浏览器窗口想问题，现在我是看着一个目标、一组工具、一段上下文在想怎么让系统帮我完成闭环。前端Leader的经验没有浪费，它只是被重新组装了。

我还会继续学下去，并且接下来的方向很明确：把数据分析Agent从内部Demo做成一个真正有人天天在用的工具。让运营同事真的通过对话拿到日报，让开发同学真的通过提问定位线上问题。这个过程肯定会碰到更多麻烦，但Day71教会我的事情是：不要怕麻烦，怕的是你把麻烦当成尽头。