企业官网建设流程全解析

今天是前端Leader身份下，学习/转行AI Agent的第70天。昨天白天还在开需求评审，晚上十点终于把一个“多角色协同处理单据流程”的端到端Demo跑通了，日志最后一行打出了task completed，我盯着屏幕愣了几秒。70天前，我只会对着大模型聊天窗口问问题，现在居然能自己做出一套带工具调用、记忆管理和多代理拆分的原型系统。这个节点值得写一篇复盘。

这篇文字主要做三件事：给自己留一个阶段存档；给同样在职、同样带团队、同样在观望AI Agent的前端同行一份偏实操的过程记录；把踩过的坑整理清楚，免得组里后续接Agent项目时重复交学费。内容不按教材写，就按一个普通人的70天流水账加技术心得来。如果你也是前端背景，正在纠结要不要花时间学Agent，这篇应该能给你一些具体参照。

1. 第70天的来路：动机、节奏和每天两小时的学习闭环

1.1 想转AI Agent，不是因为不想写前端

坦白说，我不是那种对前端失去热情想跑路的人。做前端Leader这几年，我每天面对的事情里有一大半是重复劳动：同类页面的轮番适配、权限判断、状态同步、数据回填；团队里四个前端同学每周都要被各种“改个字段”“换个排序”的迭代消耗掉将近三分之一的时间。我一直觉得这里面一定有办法能做端到端的自动化，但传统脚本和规则引擎都被试过，边界太硬、场景一多就崩。

AI Agent真正吸引我的点，是它不强依赖“穷举所有分支”，而是靠大模型的推理能力去理解用户意图，自己去调用工具、查数据、生成结果，最后把一条流程串起来。这正好打在重复劳动的要害上：高频、有规则、但规则又会变。与其说是逃离前端，不如说是把“写页面”这个动作升级成“编排系统完成页面背后的整个事务”。

我给自己定的目标也很朴素：70天之后，能独立搭出一个能解决真实业务问题的Agent原型，而不是只会跑别人的Demo。带着这个目标，节奏就出来了。

1.2 70天三轮递进：我的学习节奏和阶段产出

很多人学新东西喜欢按“从基础到高级”的线性顺序，但我用的是三轮递进：每一轮都做出一个能跑的Demo，再做下一轮。这个设计很重要，因为只有看到东西跑起来，后面学的东西才有承接点。

实际执行中当然经常被打断：出差、版本上线、孩子生病，都有。但我不追求每天都满额，只求节奏连续。连续比强度重要，哪怕某天只读了半小时文档，也胜过断一周再回来重看。

1.3 每天两小时的纪律：先文档，再复现，后复盘

我的学习闭环固定三步：先读官方文档或系统材料，理解设计意图；再用最小代码复现，验证自己的理解；最后把出错的地方记成笔记，第二天回看。这个方法是从以前学前端框架时带过来的，但用在Agent学习上尤其有效。

举个例子，学习结构化输出时，我读文档以为只要在系统提示里写了“请输出JSON”就能拿到干净结果，结果实际跑的时候总会夹带解释文本。后来才发现，真正起作用的是在请求参数里显式声明响应格式。这种“文档理解-实际运行”之间的落差，才是学习最有价值的部分。每天的复盘笔记里，我专门记这类落差，不记概念定义。

2. 前端背景是“吃老本”还是“换血”？我的真实结论

2.1 前端老本里最值钱的三样东西

第一个是异步与事件循环。Agent每跑一步，本质上就是一个异步决策链：发请求、等返回、再发下一个请求。前端同学对promise、事件回调、竞态处理几乎是条件反射，这套底子在Agent开发里直接能用，我写多代理协作时，处理并发状态的感觉和写前端联调接口特别像。

第二个是状态管理。做过复杂前端项目的人都有体会，全局状态一旦失控，页面行为就会变得不可预测。Agent的上下文管理也是同一个问题：模型能记住什么、忘记什么、从哪取回什么，本质上就是在做状态管理。你懂Redux或Pinia那套单向数据流思路，理解起记忆模块会非常顺畅。

第三个是产品直觉和流程梳理。Leader岗位逼着我每天把业务语言翻译成技术方案，我知道用户在一个工具链里卡在哪一步、哪些环节最痛。这个能力在做Agent场景选型时是刚需：模型不是万能的，能不能选对“让AI替人干活”的切入点，决定项目生死，而这个判断力来自业务理解，不来自模型知识。

2.2 最难迈过的坎：从同步UI思维到token流思维

老本虽好，但有一道坎卡了我整整两个星期：思维模式切换。前端的界面逻辑本质是同步的、可控的：事件触发后，我们明确知道接下来会发生什么，页面状态是确定的。而Agent不一样，它是token流，是概率性的：同一个提示词，模型这次可能选工具A，下次可能选工具B，甚至可能在两个工具之间来回横跳。

我第一次写函数调用时，下意识想用状态机把模型的所有行为路径都约束死，结果prompt又长又笨，模型反而频繁出错。后来我才明白，在大模型面前，正确的姿势是“给边界，不锁路径”：明确告诉它哪些能做、哪些不能做、做完结果怎么返回，但不要尝试枚举它每一步必须怎么做。这个“从可控到概率”的心态转变，比任何具体API都重要。

2.3 一张帮助我做思维迁移的对照表

学到一个东西，我都会问：它对应前端里的什么？这张表是我第40天整理出来的，现在回头看，它基本概括了我的迁移路径。

这张表帮我在前端组讲课时省了很多力气，后面带团队切入Agent时，它就是一套现成语义翻译器。

3. Day30到Day60反复磨的三块硬货：工具调用、上下文记忆、多代理协作

3.1 工具调用：本质是给模型一张“接口菜单”

函数调用是我认为Agent最核心的机制，没有之一。它的原理一句话就能说清：大模型本身不执行任何函数，它只是在需要外部能力时，输出“我要调用哪个工具、参数是什么”的结构化指令，真正执行的是你的代码，执行完再把结果返回给模型继续推理。

这就像一个前端组件：模型是组件使用者，工具是onChange回调，回调结果会再次驱动组件重新渲染。关键在于，你一定要把工具描述写得像一份靠谱的接口菜单。我常用的工具描述结构是这样的：

{ "name": "query_order_status", "description": "查询订单的实时处理状态。当用户询问‘订单到哪了/多久能好’等含义时使用；不要用于查询历史订单列表。", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，形如SO-2025-0001" } }, "required": ["order_id"] } }

菜单写得越清楚，模型就越不容易乱点菜。我总结出三条实践经验：工具名要稳定，改了名会让历史上下文全部失效；描述里一定要写清楚“什么时候用它、什么时候不要用它”，这比参数定义还重要；一次给模型塞的工具不要太多，五个以内最好，超过八个模型的选择准确率会肉眼可见地下降。工具返回的内容也要克制，把无关字段全部裁掉，因为返回的每一个字都在烧token，也会干扰模型下一步决策。

3.2 上下文记忆：token预算、摘要和长期存储

写Agent的人迟早会撞上“记忆墙”：模型不是没能力，而是上下文窗口有限，塞不下所有信息。我处理记忆问题的方式，和前端处理缓存完全是一个套路：短期记忆留在会话里，长期记忆落到外部存储，需要时再取回。

短期记忆最简单的做法是滑动窗口：只保留最近N轮对话，再往前的内容压缩成摘要。长期记忆则靠摘要加向量化，把历史对话的要点提取出来写入外部存储，下次用户再提相关需求时，通过检索把它拉回上下文。你可以把这三层理解为浏览器缓存、localStorage和远程数据库。

我实践下来，有三种记忆值得认真设计：会话内短期记忆、会话外长期记忆、以及工作记忆。工作记忆最容易被忽略，它指的是当前任务的目标、已完成步骤、待办事项。我的做法是在每次工具调用返回后，同步把状态写入一个外部“任务清单”，让模型每轮决策前能读到当前进度。这个机制类似前端把临时状态提升到全局Store，效果立竿见影，能明显减少反复询问和重复操作。

上下文还有一个绕不开的资源问题：token预算。我常用的分配参考是这样的：

这不是定死的标准，但它强迫我养成“每一块内容都要有预算”的习惯。上下文不是无限的内存，它是成本，也是瓶颈。

3.3 多代理协作：让“三个实习生”配合，比堆“三个专家”更稳

Day50之后我开始碰多代理。一开始特别兴奋，觉得让一个模型当规划者、另外几个当执行者，一起干活很酷。但试了两周才明白，多代理不是堆更多模型，而是把职责拆到可以独立测试的粒度。

我的切身体会是：先单Agent跑通，再拆多Agent。你连一个工具调用都没调稳，不要急着上多代理。拆的时候，优先用“主管-执行者”模式：一个规划代理负责理解用户真实意图、拆任务、分发子任务；多个执行代理各自只负责一个非常窄的领域，比如解析、核验、写结果。每个执行代理的工具越少越好，我甚至会把它们限制在两到三个工具以内，因为工具少，出错的概率就少。

还要守一条纪律：执行代理之间不要互相调用。以前我天真地让核验代理直接去调用解析代理的结果，结果两个模型互相等待、反复确认，日志刷屏。正确做法是所有子结果都汇总给主管，由主管统一判断、统一输出。这就像带实习生，你宁可让每个实习生只负责一小块，把结果交给你来做最终整合，也不要让实习生之间来回对接。经过调整，我的单据流程Demo稳定了很多，返工率从每十单返工三四单降到一单以内。

4. 70天里最值得写的四个踩坑现场

4.1 案例一：模型在同一个工具上反复空转

现象很典型：日志里连续十几轮都是同一个工具调用记录，模型像着了魔一样，一遍遍查同一张订单的状态，任务永远走不到下一步。第一晚我怀疑是系统提示约束不够，把“不要重复查询”写进了prompt，还是没用；又怀疑工具返回格式不对，把返回结果直接打印出来比对，格式正常。

最终定位到的原因让我有点意外：工具返回结果里包含的原始文本太长了，长到模型每次更新上下文时，注意力都被细节淹没，反复确认“自己是不是漏了什么信息”，于是选择再查一遍。解法也很简单：把工具返回压缩成关键字段摘要，并明确在系统提示里写“一次查询后如果状态未变化，直接结束子任务”。这个坑的核心教训是：模型不会天然止损，你必须为它设计终止条件，它才会停下。

{ "round": 9, "tool_call": "query_order_status", "tool_return": "order SO-2025-0001, status: processing, 7 fields returned", "assistant": "仍未变更，继续查询以确认" }

看到这条“继续查询以确认”，我和熬了一整晚的自己面面相觑。从那以后，凡是涉及轮询类工具，我都会先问一句：如果结果没变化，下一步该做什么？

4.2 案例二：聊到一半，模型把最初需求忘干净了

第二个坑是在长对话里踩的。用户对话超过30轮后，模型突然开始按照一套偏离最初目标的标准去做判断，最初明确的用户参数全部失效。排查很久才发现，是上下文窗口装不下前面全部消息，早期消息被静默截断了。

这就是前面提到的“失忆”问题。修复思路分两层：底层，每轮结束把关键参数和当前目标写入外部存储，并在每轮开始时以“当前任务”的形式注入系统提示；上层，定期把历史消息压缩成摘要，而不是全部保留原文。现在的Demo里，开头用户给的“订单类型”“处理优先级”“截止时间”等关键信息全部外置，模型几乎不会再出现“聊着聊着忘了来干嘛”的情况。这个改造也加深了我对记忆模块的理解：状态必须持久化，不持久的状态等于不存在。

4.3 案例三：RAG召回了“相似但无关”的片段，回答一本正经胡说

接入RAG后，出现了一种更隐蔽的错误：模型引用的知识看起来都相关，但组合出来的结论完全不对。后来我在调试面板里看召回结果，发现召回的前几条片段只是在字面上相似，在领域里毫无关系。原因出在分块方式和检索过滤上：我把整页文档切成大块塞进了向量库，没有给每块打上文域标签，检索时自然什么相似拉什么。

解决方案分三步：一是把切片大小从整页降到按语义段落切，每块控制在200到400字；二是给每个切片打上项目、模块、时间等元数据，检索时先做元数据过滤，再向量召回；三是设置一个相关性阈值，低于阈值的检索结果干脆不返回，让模型明说“资料不足”，而不是硬编。现在系统里凡是回答涉及具体流程的，都会带上来源引用，这个习惯和前端做埋点一样，是Agent落地的基础设施。

4.4 调试姿势：把Agent当系统来观测

前面几个坑能快速定位，靠的不是肉眼盯着聊天窗口猜，而是把每一轮调用过程完整记录成日志。我做的第一件事，是在每个入口和工具返回处打点，把当前提示词、模型输出、工具调用、工具返回、耗时全部落到结构化日志里。问题出现时，直接回放“模型为什么在那一刻选了那个工具”。

另外两个小动作也很有用：复现问题时把temperature设为0，让模型输出尽可能稳定；改prompt或者工具表之后，用一组固定的历史测试用例跑回归，比较答案变化，绝不裸改上路。说白了，这就是把前端监控和持续集成的习惯平移到Agent开发里。没有评测集的Agent优化，等于没有监控系统的线上项目，你敢上线，就敢被炸蒙。

5. Leader视角的落地思考：前端团队接Agent之前，先想清楚三件事

5.1 先分清“做个技术演示”还是“改造一条端到端流程”

现在各种Agent大模型Demo很热闹，很容易让人产生“什么都该马上自动化”的错觉。我在选场景时给自己定了几个硬条件：高频、规则相对清晰、容错可接受、数据相对结构化。完全开放的创意类任务，现阶段不适合当第一个落地场景，因为失败率太高。

以我们正在试点的方向为例，选的是高频单据类业务的自动解析和核验流程。这类场景数据相对规整，出错可以被人类快速发现并纠正。我还坚持一个原则：先以“人机协同”为目标，不追求“无人驾驶”。你要让业务部门接受一个90%自动、10%人工兜底的流程，比让他们一开始就承诺“全自动”容易得多。

5.2 两周试水的最小闭环怎么搭

给团队的前端同学做Agent入门，我不建议从理论开始，而是直接搭一个两周内能交付的内部工具。具体步骤我整理过一份，基本照着走就能出东西：

1. 选一个高频但低风险的内部场景，定义清楚的输入和输出。场景越小越好，比如把某个数据同步助手的异常汇总自动生成周报。
2. 接入一个商用大模型API，先用现成接口，不碰微调。微调不是新手需要做的事，多数场景用正确提示词加工具调用就够。
3. 写四个以内的工具，把所有外部操作包在工具里。前两周千万不要追求复杂编排，能跑通一条路径就很好了。
4. 人工旁跑一周，记录每一次成功、失败和失败原因。这些样本就是后面优化提示词的数据集。
5. 根据失败样本迭代，但每次只改一处。我见过太多人同时改五个地方，最后都不知道是哪个修复起的作用。

这个最小闭环的验收指标只有三个：说的操作次数有没有变少、任务完成率是不是可接受、出问题时有没有可靠的兜底出口。不要关心它够不够花哨。

5.3 第70天之后的账：时间成本与真实瓶颈

算一笔时间账：70天，平均每天两小时，周末再加一些，合计大概150个小时。这时间对Leader来说不算小数目，但换来的能力是质的：从“看得懂概念”变成“能独立搭原型”。这150个小时里，真正消耗我最多时间的不是写代码，而是理解“模型为什么那样选”和“上下文为什么会失控”。这些经验光看教程是学不来的，必须在调试日志里泡出来。

真正限制Agent落地的瓶颈，我现在的判断不在模型推理能力，而在四个基础工程问题：数据是不是足够结构化、流程有没有标准化到可以被拆解、评测集有没有沉淀下来、以及有没有给失败留好兜底线。这四个问题没有一个靠调prompt能解决，都需要业务方、产品和技术一起坐下来梳理。这也是我觉得前端团队特别适合切入Agent项目的原因——前端同学天然站在产品和用户中间，最懂流程哪里疼。

再说组内推广的事，我走的路是先让一两个有自驱力的同学组成先锋小组，选一个小场景打样板，而不是让全组同时转型。等样板跑通，把过程和踩坑整理成内部文档，再逐步扩大。强行让所有人同时学，只会同时分心，什么产出都没有。技术选型上，我们目前尽量选开放生态的通用大模型接口，避免被单一平台绑死，同时也方便在不同模型间切换做效果对比。

最后，给自己留的一句话

真要说第70天最想分享的经验，还是一句话：把prompt和工具表当作代码来管理。它们要进版本管理、要打标签、要留变更记录，每次改动后用同一组历史用例跑回归。这个习惯是我从前端工程化里带来的，但放到Agent开发里，它比管理代码本身还重要。第70天刚好是一个节点，接下来10天的计划是给Demo补一套更完整的评测集，把多代理的返工次数也接进监控指标里。等跑完这一轮，希望还能写一篇有数据对比的续集放出来。