企业官网建设流程全解析

我不是做模型训练的，我平时主要写前端页面和交互。这句话不是我自谦，而是很多前端同行第一次听到“Agent 开发”这四个字时的心里话：完了，这是算法工程师的活，跟我不搭边。前阵子某内部系统提了个需求，说要做一个能自动处理工单的智能助手，我第一反应也是慌——我不会训练模型啊。后来把需求聊透才发现，对方要的根本不是“训练一个模型”，而是“把已有的大模型能力接入我们的业务系统”。Agent 开发不是模型训练，它依然是软件开发，只是把模型推理当成一个外部服务来调用，跟你调数据库、调支付接口是同一类工种。这篇文章我就把这几个月从零上手 Agent 开发的完整认知讲透：它到底在做什么、前端功底哪些能直接用、上手最短路径是什么、以及那些文档里查不到的坑。

1. 先把这个误解掰开：Agent 开发到底是不是训练模型

1.1 需求的真相：对方要的不是算法，而是业务流程

我接到那个工单助手需求的时候，需求方描述得非常含糊，原话大概意思是“搞个 AI，能看懂工单，自动分一下类，最好还能自动回复”。听起来很高大上，但你把这句话翻译成软件需求，其实就是：接收一段用户描述 → 判断工单类型 → 查一下历史工单 → 调用分配接口 → 组织一段回复文案。这中间没有任何一个环节需要“训练一个新模型”。

真正要训练的模型是那些需要新知识、新能力的场景——比如让模型学会某个专业领域的私有知识，或者需要一个市面上不存在的新能力。但绝大多数业务里要的“AI 助手”，都是把已经训练好的通用大模型，接进你的业务流程，让它在正确的时间做正确的决策。这件事的复杂度不取决于模型本身，而取决于你的业务流程有多绕。

所以我后来跟团队立了一条规矩：接到 AI 需求，第一件事不是查模型怎么训，而是画业务流程图。把“用户输入”到“最终输出”之间所有步骤列出来，标出哪些步骤人可以写规则，哪些步骤必须靠模型理解。图一画完，需求就清晰了一大半，你也自然会发现，自己根本不需要碰训练。

1.2 训练和 Agent 开发的分界线在哪

我习惯用一个类比来跟同行解释：模型训练像“培养一个员工”，Agent 开发像“给这位员工安排岗位、理顺工作流程”。

• 模型训练关心的是这个员工聪不聪明、知识储备够不够、能不能从数据里学会新本领。这需要数据、算力、训练框架，成本高、周期长，是算法工程师的主场，而且不是每个团队都有这个资源和必要。
• Agent 开发关心的是这个员工进入公司之后怎么干活：岗位职责是什么（系统提示词）、手上有哪些工具（Function Calling）、遇到不会的怎么办（兜底逻辑）、怎么跟客户沟通（输出编排）。这需要的是工程能力，是软件工程师的主场。

说白了，训练是“把人培养成专家”，Agent 开发是“让专家融入你的团队，把工作流理顺”。前端做的是后者，几乎全部是后者。

不过这里要补一句公道话：不训练模型，不代表你可以完全不懂模型。你需要了解你要用的那个大模型的“脾气”——上下文窗口多大、擅长什么不擅长什么、一次调用多少钱、流式响应怎么接。但这些属于“读文档就能搞明白”的工程知识，和“训练模型才会懂”的算法知识之间隔着一整座山。我刚开始就是被这座山吓住了，绕了不少弯路。

2. 前端技能迁移地图：哪些功底能直接复用

很多前端同行做 Agent 时最大的心理障碍，是觉得自己要从零学一门新学科。实际上，你积累的工程能力在 Agent 开发里一大半都能直接用，只是换了一层皮。我把最有迁移价值的三个方向单独拎出来讲。

2.1 状态管理思维迁移：Agent 记忆就是一套状态机

前端每天都在跟状态管理打交道：页面上那个按钮在不在 loading、表格数据有没有更新、弹窗要不要显示，全是状态。Agent 的“记忆”本质上就是一套状态管理，只不过名字从“store”换成了“上下文”。

一次对话里，模型能“看到”的内容无非两个来源：一是上下文窗口里放进去的历史消息，相当于前端组件的 props，只在本次会话里有效；二是你在外部维护的持久化数据，比如数据库里的用户偏好、历史工单记录，相当于全局 store，跨会话长期保存。想明白这两层，Agent 的记忆设计就已经完成了一半。

我自己的习惯是把所有状态画成一张表，列清楚：哪些数据必须在每轮对话都进上下文，哪些只在特定操作时才动态塞进去，哪些完全不需要进上下文而是靠自己查。这张表画完之后，你会发现这就是你做前端时画的“组件数据流图”，一模一样。你不需要研究什么梯度下降、反向传播，只需要把写各种前端状态库时那套数据流思维搬过来，就已经比大半初学者想得清楚了。

2.2 异步与流式处理：你早就是个流式处理专家

前端最擅长的就是异步。发一个请求，等响应，更新页面，这套流程吃透了。Agent 开发里的核心交互也是异步，而且比普通接口更考验人——因为大模型的响应是流式的。

普通接口是“你等一会儿，一次性拿到全部数据”，大模型接口是“像打字机一样一个字一个字蹦出来”。你要是不做流式处理，用户就得对着空白界面干等十几秒，体验非常糟糕。这要求你的代码支持边接收边渲染，每来一个片段就追加一次页面内容。

好消息是，浏览器原生就有流式读取能力。如果你做过长列表分页加载、做过图片懒加载、做过实时通知推送，那么你对“数据分块到达、逐块渲染”这件事已经非常熟悉。我之前观察到一个有意思的现象：不少后端出身、没怎么写过前端的同事，第一次做 Agent 时反而在这里卡壳，要查半天文档；而前端出身的我，几乎没费什么劲就接上了。因为这种事情，前端在日常开发里早就玩烂了。

2.3 上下文预算：把性能优化思维搬过来

写前端的时候，我们天天在算“这个页面不能一次渲染一万条数据，得分页、虚拟滚动”。Agent 开发里也有同样的资源约束，只不过把“DOM 渲染性能”换成了“上下文窗口大小”。

上下文窗口是模型单次能“看到”的文本总量，超过上限会直接报错，或者把最早的内容悄悄丢掉。所以每一轮对话，你要把哪些内容放进上下文、哪些不放进，完全是一个预算取舍问题。我以前写页面时有个坏习惯，觉得“能拿到的数据全都塞进 store 里，反正又不吃亏”，后来做 Agent 才发现这是大忌——上下文里塞满无关内容，既烧钱，又干扰模型判断。

后来我给自己立了一条规矩：每条要进上下文的信息，都必须回答“它对模型当前决策有什么帮助”这个问题；回答不上来的，一律别进。这条规矩帮我省了不少 token，也明显提升了输出质量。这个思路，和你在前端做性能优化时的取舍逻辑是完全一致的——资源有限，抓大放小。

3. 从零搭一个最小可用 Agent：前端视角的完整实操

理论说再多，不如亲手搭一个。下面是我第一次完整跑通“工单自动分类与回复”小 Agent 的全过程，把每一步的真实做法都交代清楚。

3.1 为什么第一版不要用框架

市面上已经有不少 Agent 开发框架和编排工具，各有卖点，但我给所有初学者的建议是第一版先别上框架，直接用大模型厂商提供的原始 API 调一遍。原因有三条：

第一，框架会把很多细节藏起来。你很难理解提示词是怎么组装的、工具调用是怎么解析的、上下文超长时框架偷偷做了什么手脚。一旦出了问题，你只能对着黑盒瞎猜。

第二，原始 API 的调用方式简单得令人发指，本质上就是一个 HTTP 请求。前端理解这个毫无门槛，比你在浏览器里调一个常见的 REST 接口还简单，因为连鉴权、签名这些步骤都简化了。

第三，等你用原始 API 跑通了整条链路，再去看任何框架，会发现里面的概念全是眼熟的，无非是“帮你封装好了 API 客户端、消息管理、流式解析、上下文裁剪”。那时你再学框架，效率是最高的。

我当时选的就是一家平时就在用的云服务商提供的大模型对话接口，注册账号、拿 API 密钥、开通服务，五分钟搞定。费用按 token 计，前期测试阶段一天几块钱，完全可接受。

3.2 核心链路只有三条：提示词、工具、函数调用

一个最小可用 Agent 的核心链路其实特别简单，只有三步：

第一步，把系统提示词和用户输入一起发给模型。系统提示词就是模型的工作守则，你想让模型扮演什么角色、遵守什么规则、按什么步骤思考，全写在这里。

第二步，模型根据输入决定要不要调用某个工具。这个机制在行业里的标准叫法是“函数调用”。你可以先给模型声明好一批工具，比如“查询工单详情”“把工单指派给某个处理组”，模型在推理时会自己判断“这个任务需要查一下工单数据”，然后在回复里带上一个标准格式的工具调用请求。

第三步，你拿到工具调用请求，自己去执行对应的函数或接口，把结果再回传给模型，让模型基于真实数据生成最终回复。

我当时的系统提示词大致长这样：

你是一个工单助手，你可以使用以下工具：queryTicket(id) 查询工单详情；assignGroup(id, groupName) 将工单指派给对应处理组。当用户描述包含工单编号时，先调用 queryTicket 获取详情，再根据工单类型调用 assignGroup 完成指派。缺少必要信息时，必须向用户提问，禁止猜测。

这段提示词就是一个典型的“角色 + 工具清单 + 决策规则”模板。你不需要任何算法知识，只需要像写业务文档一样把它写清楚就行。难点其实在于怎么把“模型想要调工具”这件事从响应里准确解析出来，以及怎么处理模型“不按规矩出牌”的情况，这部分我在后面第四节细讲。

3.3 最简可运行代码与逐步拆解

下面是一段极度简化后的 JavaScript 伪代码，展示的就是上面说的三步链路：

// 极度简化的 Agent 调用骨架 async function runAgent(userInput) { // 1. 组装消息：系统提示词 + 用户输入 const messages = [ { role: 'system', content: systemPrompt }, { role: 'user', content: userInput } ]; // 2. 调用大模型接口，支持流式返回 const response = await callModel(messages, { tools: toolDefinitions }); // 3. 判断模型是否要求调用工具 if (response.toolCall) { const { name, args } = response.toolCall; // 执行你注册的真实工具函数 const result = await executeTool(name, args); // 把工具执行结果放回消息列表 messages.push({ role: 'function', name: name, content: JSON.stringify(result) }); // 4. 带着工具结果，让模型生成最终回复 return await callModel(messages); } // 4'. 没有工具调用，直接返回模型原回复 return response.content; }

真实项目里这段骨架至少还要加三样东西：错误重试（模型接口偶尔抽风）、超时处理（不能让用户无限等）、上下文裁剪（对话太长时做历史摘要）。但核心思想就是上面这些——模型不是万能的，它需要“手”（工具）和“眼睛”（数据），而你作为工程师的任务，就是给模型装上这两样东西。这套思路对前端来说，本质上就是“给页面接一个数据接口，再把返回数据渲染出来”，两者的差异真的没有想象中那么大。

4. 调试 Agent 与排查问题：一份来自实战的速查经验

Agent 开发里最折磨人的不是写代码，是调试。普通代码出了问题，参数、返回值、报错都是确定的，翻翻栈就能定位；模型输出是概率性的，同样的输入两次结果可能不一样，报错信息还经常含糊。我把这几个月踩过的坑整理成了一份速查表，每一条都亲自验证过。

4.1 高频问题速查表

这张表里最值得记的是第一行的“四要素”，我几乎每次遇到“模型答非所问”都是因为提示词写得太随意。你得像给新同事写工作交接文档一样写系统提示词：角色（你是谁）、任务（你要干什么）、边界（什么情况下你不能做）、输出格式（回复长什么样）。四要素缺一项，模型就会开始在“自由发挥”的边缘试探。

4.2 三个反直觉的坑

除了常规问题，有三个坑属于“不撞一次根本想不到”的类型，我单独拿出来讲，希望你能绕过去。

第一个坑，模型会一本正经地编造信息。这里不是说模型故意骗人，而是当它缺少关键信息时，会倾向于“脑补”一个听起来合理的答案。我早期的工单助手，用户没提供工单编号，模型居然回复“工单 12345 已经处理完毕”，把我吓了一跳。解决办法不是跟模型讲道理，而是从工程上堵死：一是在提示词里明确“缺少必要信息时必须向用户追问，禁止猜测”；二是在代码层面做校验，比如检查模型回复里出现的工单编号在对话历史里是否存在，不存在就直接拦截，要求模型重新生成。我把这套做法叫做“输出安检”，前端出身的理解起来就是“表单提交前做校验”，核心思路一模一样。

第二个坑，工具调用参数经常“飘”。模型理解自然语言确实强，但在严格按 JSON 格式传参这件事上，偶尔会犯低级错误——字符串和数字不分、字段名大小写随手改、多传一个没声明的参数。起初我以为是大模型接口返回格式的统一 bug，后来发现不同模型、不同版本，出错风格还不一样。我的兜底方案是在执行工具函数之前加一层参数校验和格式修正，宁可多写几十行防御代码，也不要让一个格式小错把整条链路打断。现在这套参数清洗逻辑已经是我所有 Agent 项目里的标配了。

第三个坑，上下文历史越长，模型反而越“犯迷糊”。我想当然地以为给模型的信息越多，它就越懂用户，结果发现历史消息积累到一定程度后，模型反而会忽略最近的指令，甚至把早期的信息当成当前状态。后来我学会了两招：一是每隔几轮就把前面的对话做一次摘要，压缩成一小段放回上下文；二是把最重要的指令放在系统提示词最前面，并在关键位置重复强调，因为模型对开头和末尾的内容注意力总是最强。这个规律跟你写前端页面时“重要按钮放在首屏、关键文案放在显眼位置”是同一个道理。

5. 工具链与框架选型：什么时候上手、什么时候别碰

等你用原始 API 做过两三个小 Agent，就会自然产生一个念头：这些重复性代码能不能抽象出来复用？这时候再去接触框架，理解会和一开始完全不同。但框架水很深，选错了不仅没省事，反而拖慢进度。

5.1 框架的三条路线怎么选

目前主流 Agent 开发框架大致分三类，我按复杂度和适用场景帮你拆开看：

• 轻量脚手架类：主要负责封装 API 调用、消息管理、流式解析、上下文裁剪这些重复劳动，本质上是一个“很好用的模型客户端”。适合单个 Agent、逻辑不复杂的项目，学习成本低。
• 流程编排类：让你用节点连线的方式组织步骤，比如“先判断意图，再决定走哪条子流程”。适合流程固定、分支繁多的业务，比手写一大堆 if/else 清爽得多。
• 全功能平台类：集成模型管理、提示词版本管理、日志监控、数据回流等功能，适合团队协作和企业级项目，但配置项非常多，个人项目用它属于杀鸡用牛刀。

我的建议是按项目复杂度动态选：单个简单 Agent 用轻量脚手架；流程很绕、分支很多的场景用编排类；团队多人协作、需要持续迭代维护的，直接上全功能平台最省心。别一上来就追求最重的框架，那是给自己增加维护负担。

提醒：选框架之前，先花十分钟看两件事——社区活跃度和文档完整度。Agent 开发是个快速演进的领域，框架迭代速度极快，一个文档残缺、维护停滞的框架，哪怕设计得再优雅，迟早变成维护者的噩梦。这个判断标准，和你选前端组件库时一模一样。

5.2 有些时候真的不该上框架

这里我想说一个反主流观点：框架不是必需品。我见过不止一个团队，业务逻辑明明很简单，非要上一个重框架，结果为了迎合框架的规范，硬写了一大堆配置和胶水代码，收益完全覆盖不了成本。

我总结了三种“不该上框架”的情况：

• 你的 Agent 只有一个模型调用加一个工具调用，几十行代码就能搞定；
• 你的业务有很强的定制需求，框架的抽象反而碍手碍脚；
• 团队里没人熟悉这个框架，现学现卖的成本已经超过手写代码的成本。

只要踩中其中任意一条，手写一个迷你 Agent 壳，反而是更聪明的选择。前端圈早就有个朴素共识：“不要为了用框架而用框架”，这句话在 Agent 开发里同样成立。框架是用在“重复次数多、逻辑模式统一”的地方的，而不是用来让自己显得专业的。

6. 一点个人体会：前端做 Agent 的底气从哪来

6.1 从“能跑”到“好用”，前端还能做什么

很多人以为做 Agent 就是把模型接口调通、响应渲染出来就算完事，但实际交付一个“好用”的 Agent，考验的全是前端基本功。

比如对话流里要展示中间过程，模型在思考时用户能看到什么？调用工具的进度怎么表示？出错时怎么给用户一个不吓人的提示？流式输出时打字机效果会不会引起页面性能抖动？长时间对话后历史越来越长，界面怎么折叠和清理？这些问题没有一个涉及模型训练，全是你在前端页面里已经做过无数遍的交互设计、性能优化和异常处理。

我自己的体验是，把 Agent 从“能跑”打磨到“好用”，前端的价值反而是最重的。模型能力再强，交互体验一塌糊涂，用户照样不买账。这就像再好的后端接口，配上个卡顿的白屏页面，用户一样骂。所以别觉得前端在 AI 时代要被取代，至少在 Agent 应用这一层，前端是把技术变成产品的那双手。

6.2 写给同行的一句话

最后想说点掏心窝的话。学科壁垒这个东西，很多时候真的是自己吓自己。我做前端做到第五六个年头的时候，一度觉得自己到了天花板，每天就是写页面、调接口、修 bug，仿佛一眼望到头。开始接触 Agent 之后，我最大的收获反而不是掌握了什么“前沿技术”，而是重新找回了“用技术解决一个真实问题”的成就感。原来那些年被同事调侃“只会写页面”的功底——对状态的敏感、对异步的熟练、对交互细节的执着——到了 Agent 开发里全部变成了优势。

如果你也是前端，也想往 Agent 方向走，我给的最实在的建议是：别先囤书，别先报课，先拿一个真实的、哪怕很小的需求，用云厂商的原始 API 调通“用户输入 → 模型推理 → 工具调用 → 回复输出”这一整条链路。快的话一天时间，你就能完成这次认知跨越。到时候你会发现，Agent 开发不是模型训练，它只是软件开发的一种新形态，而你早就具备胜任它的全部基础。