企业官网建设流程全解析

花两小时装了ai agent。本来只是想周末随便试试，结果真给跑通了，而且整个过程比我预想的顺很多。这篇文章就把我这两个小时里做了什么、踩了哪些坑、Agent底层到底是什么逻辑，一次性说清楚。适合刚接触AI Agent、被各种概念绕晕的人，也适合想自己搭一个但不知道从哪下手的朋友。我会把Agent和LLM、DeepSeek这类模型的关系讲明白，再把搭建过程和核心组件拆开揉碎，最后附上我实际遇到问题的排查记录，你跟着走基本能少走一半弯路。

1. 先搞明白：Agent到底是个啥，和DeepSeek有什么区别

1.1 一句话版本：LLM是大脑，Agent是长了手脚的大脑

很多人第一次接触Agent都会懵，因为网上资料一上来就抛概念：规划、记忆、工具调用、多智能体协作……听着像什么高深的人工智能框架。但用大白话讲，Agent就是一个“会干活的AI”，而DeepSeek、GPT这类模型本身只是“会说话的AI”。

具体区别我习惯用一个类比：你把DeepSeek当成一个刚从名校毕业的高材生，脑子确实好使，知识面也广，但把他关在没有电脑、没有电话、没有资料的房间里，你问他什么他都能聊，可如果你让他“帮我把这周的销售数据整理成报表发到邮箱”，他是做不到的，因为他没手没脚，碰不到数据，也碰不到邮箱。Agent干的事情，就是给这位高材生配上电脑、配上网络、配上各种工具，让他能真正把活儿干完。

所以一句话总结：LLM是决策大脑，Agent是这个大脑加上工具、记忆、执行流程之后组成的完整系统。它们不是竞争关系，是上下层关系——Agent内部往往就装着一个甚至多个LLM来帮它思考。

1.2 从“聊天”到“干活”，Agent到底多做了什么

咱们再往下拆一层。用传统的聊天机器人（比如直接用网页版DeepSeek）和Agent对比，差别主要体现在三个动作上。

第一是自主规划。你给传统聊天机器人一个目标，它只能基于当前这轮对话内容给你输出一段文字作为回应，你说一句它答一句。而Agent会自己把一个复杂目标拆成若干步骤：比如“帮我在网上调研一下智能门锁的竞品情况”，Agent会先想调研需要哪些信息维度，然后决定先搜什么、再查什么、最后怎么汇总，它不需要你一步步指挥。

第二是工具调用。这是Agent和普通聊天最核心的区别。Agent接到任务后，可以主动调用外部API、执行代码、读写文件、查询数据库。比如它能自己调用一个天气查询接口，拿到实时数据之后再结合大模型的表达能力把结果说得像人话。这个“调用工具”的动作，在大模型领域里叫Function Calling，是实现Agent能力的关键机制之一。

第三是循环反思。Agent执行完一步之后会检查结果对不对，如果发现不对或者没达到目标，它会调整策略再来一轮。这个“计划→执行→观察结果→再计划”的循环，才是Agent真正强大的地方。普通聊天是一次性问答，Agent是多轮自我迭代的执行过程。

用一张对比表看得更清楚：

1.3 DeepSeek属于哪一层，别再搞混了

所有搜索引擎里都在搜“DeepSeek是Agent吗”，答案很明确：不是。DeepSeek是LLM，属于大语言模型这一层，它解决的是“理解和生成语言”的问题，它的输入是文字，输出也是文字。

但是DeepSeek可以作为Agent的“大脑”来使用。什么意思呢？就是说你搭一个Agent，思考的活儿交给DeepSeek来做，Agent负责给它配上工具和行动能力。市面上大多数开源Agent框架，比如Dify、n8n、Coze、LangChain，都支持把DeepSeek这类模型作为底层推理引擎接进去。

所以它们的关系可以这样理解：模型层（DeepSeek、GPT、Claude等）负责思考，Agent层负责行动，应用层负责面向用户的具体场景。以后你再看到“XX Agent”这个词，第一反应应该是：这是基于某模型做的、能调用工具完成任务的自动化系统，而不是某个新出的模型。这个认知一旦建立，后面看任何Agent相关的教程都不会晕。

2. 两小时搭建实录：我到底装了什么

2.1 路线选择：为什么我选了“编排工具+模型API”这条路

搭建Agent目前主流有三条路线，我根据自己的情况权衡了一下，最后选了最适合快速跑通的一条。

第一条是纯代码路线，用LangChain、LlamaIndex这类框架写Python代码来组装Agent。优点是灵活度高，什么都能定制；缺点是对新手不友好，你得先懂Python基础，还得理解框架的各种抽象概念，两小时大概率连环境都没配完。

第二条是低代码/无代码平台路线，用n8n、Dify、Coze这类可视化工具来编排Agent。优点是上手快、调试直观，大多数节点拖拖拽拽就能连起来；缺点是灵活性不如代码路线。但对我就是想快速验证想法、了解Agent工作机制的需求来说，这个缺点完全可以接受。

第三条是直接调用现成的Agent产品（比如某些集成了Agent能力的商业工具），这种其实是“用别人做好的Agent”，适合业务用户，但不适合想搞懂Agent原理的技术人员。

权衡之后我的选择非常明确：用n8n加Docker，模型接DeepSeek的API。原因有三个：第一，n8n自带了OpenAI对话模型节点和Agent节点，而DeepSeek的API和OpenAI格式兼容，可以直接复用生态；第二，n8n内置了很多工具节点，比如HTTP请求、数据库操作、文件读写，不用自己写代码就能给Agent加上工具；第三，Docker部署非常干净，不会污染本地环境，干完活不想用了直接容器一删就完事。

2.2 第一小时：环境准备和核心组件安装

第一个小时的活儿相对机械，但也很关键，主要分成两块：跑起n8n，配好模型连接。

n8n我用Docker Compose部署，写了一个最小的docker-compose.yml：

version: "3.8" services: n8n: image: docker.n8n.io/n8nio/n8n container_name: n8n-ai restart: unless-stopped ports: - "5678:5678" environment: - N8N_BASIC_AUTH_ACTIVE=true - N8N_BASIC_AUTH_USER=admin - N8N_BASIC_AUTH_PASSWORD=your_password_here - GENERIC_TIMEZONE=Asia/Shanghai - TZ=Asia/Shanghai volumes: - n8n_data:/home/node/.n8n volumes: n8n_data:

这里有几个细节值得说一下。第一，容器需要持久化数据卷，不然你配置好的工作流、凭证信息一重启容器就全没了。第二，我打开了基础认证，虽然是在本地跑，但n8n默认没有任何登录保护，如果端口映射到了公网上，等于裸奔，很容易被扫到然后被塞挖矿脚本，这个坑网上案例太多了。第三，GENERIC_TIMEZONE建议还是设置一下，不然后续Agent里凡是涉及时间计算的节点都会出现时区偏差。

容器起来之后，浏览器访问http://localhost:5678就能进入n8n界面。首次进入会让你创建管理员账号，按提示填就行。

接下来是配置模型连接。我进n8n的Credentials（凭证管理）页面，新建了一个OpenAI类型的凭证。这里不用背参数名，n8n界面都帮你填好了，就两个东西：

API Key: 填写你从模型服务商获取的密钥 Base URL: 填写API兼容地址（DeepSeek格式兼容，直接填官方地址即可）

这个兼容性是非常重要的一个细节：DeepSeek的API设计成了和OpenAI几乎一样的调用格式，所以n8n里那些写着“OpenAI”的节点，通过改Base URL就能直接接DeepSeek。你甚至可以在同一个工作流里让不同节点用不同模型，比如用DeepSeek做主要推理，用OpenAI做辅助判断，只需要建多个凭证就行。

验证连接是否成功也很简单：在工作流里拖一个“OpenAI”节点（n8n新版里叫“Chat Model”节点），模型名填deepseek-chat，写一句“你好，回复OK”，执行一下，能看到正常返回就说明模型通道已经打通了。

2.3 第二小时：组装第一个Agent，让它学会用工具

环境通了，第二个小时就开始玩真的了。我在n8n里新建了一个空白工作流，按照“输入→Agent大脑→工具→输出”的结构搭了一个最简单的Agent。

大概的节点结构是这样的：

[Webhook节点] → [Agent节点] → [HTTP Request工具节点] → [Respond to Webhook节点]

Webhook节点负责接收外部请求，相当于Agent的“入口”——我给这个节点配了一个测试URL，模拟用户给Agent发消息。Agent节点是整个工作流的核心，它干三件事：接收用户消息、调用大模型做推理、决定是否调用工具。HTTP Request节点则是Agent的“手”，我给它配了一个可以查询城市天气的免费API接口。

关键配置在Agent节点里面。n8n的Agent节点需要指定三样东西：一是使用的模型（我选了DeepSeek，配置好的凭证自动带出来了）；二是工具（把HTTP Request节点作为工具挂载进去）；三是系统提示词。系统提示词非常关键，它决定了Agent知道“自己有哪些工具、什么场景该用哪个工具、输出格式应该是什么”。我给的提示词大致是：

你是一个智能助理。当你需要查询天气时，必须调用天气查询工具。工具会返回JSON格式数据，请用自然语言把温度、天气状况等信息整理后回复用户。如果工具调用失败，请明确告知用户暂时无法获取天气信息。

这个提示词看着简单，但信息密度很高：它告诉Agent工具存在的场景边界、工具返回格式的预期、以及失败时的处理方式，这就避免了Agent乱用工具或者拿错误结果硬编答案的问题。

配置完执行测试。我用Webhook调试功能模拟用户说了一句“北京今天天气怎么样”，Agent的完整执行流程是：先理解意图→判断需要调用天气工具→HTTP请求发出→拿到JSON数据→交给DeepSeek整理成自然语言→通过Webhook返回结果。整个过程在n8n的日志里一步不落全部能看到，哪个环节慢、哪个环节报错都一目了然。

跑通的那一刻，说实话还是有点成就感的——不是因为它多复杂，而是因为它第一次让你直观感受到AI不只是“说话”，而是真的能“做事”了。整个搭建流程和逻辑本身很简单，但背后组件的协同方式，就是现代AI Agent应用的标准范式。

3. Agent核心组成结构：Skill、Memory、MCP到底都是啥

3.1 Skill——把“会做的事”打包成技能卡

搭建过程中我发现，网上讨论Agent时有一个高频词绕不开：Skill（技能）。所谓Skill，本质上是把一组“提示词描述+工具定义+流程编排”打包成一个可复用的能力模块。你可以把它理解成给Agent做了一套“技能卡”，需要的时候直接插进去用，不需要的时候抽走，Agent就“不会”这项能力了。

举个例子。我想让Agent具备“行业分析”能力。传统做法是把一大段分析框架写进系统提示词，让Agent每次自己发挥。但这样有个问题：提示词越长，模型越容易丢失重点，而且每次对话都要占用上下文窗口。用Skill的思路，我会把“行业分析”拆成几个标准步骤：先搜索行业背景→再找主要玩家→然后看市场规模数据→最后按照固定报告模板输出。每一步配好了对应的工具和提示词，打包成一个子工作流。Agent要对某个行业做分析时，只需要调用这个Skill，不需要重新理解一遍流程。

在n8n里实现Skill有两种方式。简单的可以用“子工作流”节点，把一组固定流程封装成可以被主Agent调用的节点，Agent收到相关任务时就跳到子工作流里去执行。复杂一点的做法是给Agent配置多个不同的工具节点，每个工具节点内部包含特定的提示词和API调用，Agent根据任务类型自己选择调用哪个工具。

我实际测试下来，Skill设计的好坏对Agent表现的影响，比模型本身还大。一个边界清晰、工具描述准确、输出格式明确的Skill，能让Agent的准确率提升一大截。反过来，Skill描述含糊，Agent就会频繁误用或者不知道什么时候该用，效果还不如不加。

3.2 Memory——让Agent记住事

第二个绕不开的概念是Memory（记忆）。Agent的记忆大概分两个层次：短期记忆和长期记忆。

短期记忆就是当前会话内的上下文，比如你和Agent连续对话，它能记住你刚才提到过“我在上海工作”，这个信息不需要额外处理，大模型的上下文窗口天然支持。但短期记忆有天花板——上下文窗口是有限的，一旦对话太长，早期信息就被挤掉了。所以遇到长任务的场景，需要做上下文压缩或者摘要，把旧对话浓缩成几条精华信息继续携带。

长期记忆则是跨会话的。Agent能把重要的用户偏好、历史数据存储到外部数据库里，下次对话时可以主动检索出来。最常见的实现方式是向量数据库，把文字转成向量存起来，用户提到相关话题时，Agent通过语义相似度检索到历史信息再带进上下文。n8n里有专门的向量存储节点，支持Qdrant、pgvector，以及内置的SQLite向量存储，不需要自己部署复杂服务就能体验。

我给Agent接了一个很简单的长期记忆场景：让它记住用户的城市偏好。第一次对话时Agent问用户“你常待的城市是哪里”，用户回答后Agent把这条信息存入向量库。第二次对话用户只说“明天天气怎么样”，Agent自动检索到之前存的城市信息，然后调用天气工具查询。这个过程看着简单，但已经完整覆盖了“存储→检索→利用”的记忆闭环。

3.3 MCP——给Agent插上标准USB接口

再往后就是MCP（Model Context Protocol，模型上下文协议）了。这个概念2024年底开始火，到现在已经是Agent生态里讨论度最高的协议之一。

MCP要解决的问题非常实际：Agent每接一个新工具，都得针对这个工具写专门的代码。接一个GitHub工具写一套，接一个数据库工具又写一套，工具越多维护成本越高。MCP的思路是定义一个统一的“插头标准”，所有工具服务方都按这个标准提供接口，所有Agent框架也按这个标准去调用，接新工具就像USB设备一样即插即用。

为了方便理解，我会把MCP比作一个万能遥控器的红外码库。万能遥控器本身不知道每个电视品牌的红外编码，但它支持从码库里下载对应品牌的编码配置，下载完就能直接控制那台电视。MCP里也有一个“码头”（MCP Server）的概念，它负责把某个具体工具的能力包装成标准接口供Agent调用。

在实际操作层面，MCP的用法是：确认一个MCP Server的地址或配置→在n8n（或支持MCP的客户端）里添加这个MCP服务器→给它配好权限→Agent自动就能发现并调用这个服务器上暴露的工具了。比如我加了一个文件系统的MCP Server，Agent就有了读写本地文件的权限，它可以按我的要求“把刚才的调研结果保存成一个Markdown文件”，这个动作是完全自主完成的，不需要预先把文件操作逻辑写进工作流。

MCP的价值往深了说，是让Agent的能力边界从“开发者预先设计好的”变成了“生态里所有人都可以贡献的”。别人写了一个很好用的MCP Server，你接上就能用，这极大加速了Agent应用生态的繁荣。现在GitHub上已经有大量现成的MCP Server仓库，覆盖浏览器控制、数据库操作、设计工具、地图查询等各个领域。

4. 我踩过的坑和排查技巧实录

4.1 模型API配置类问题，先单独测节点

我在rải模型API配置时踩的第一个坑，就是模型名填错。DeepSeek的模型名是deepseek-chat，但有的教程写的是deepseek-chat-v3，有的写deepseek-reasoner，实际对接时如果用错了名字，API直接报错。这个问题的排查思路其实最基础也最重要：不要直接放到整个Agent工作流里去试错，先把模型节点单独拉出来执行一遍，确认模型本身能跑通，再加其他环节。每加一个环节就执行一次，出了错就定位到具体节点，这比搭完整个流程再从头排查高效得多。这种“节点级调试”的思路是我用n8n之后学会的最有价值的工作习惯。

4.2 工具返回格式和模型预期不一致

第二个坑出在工具调用环节。我给Agent挂了一个HTTP请求工具，结果返回的数据里天气信息混在一大堆JSON字段里，模型解析的时候容易出错，有时还会自己编造不存在的字段。这个问题的本质是工具返回结构和模型预期不一致。

解决方法是给HTTP节点加一步“数据清洗”，把API返回的大JSON只提取出关键字段，重新拼接成简明文本再返回给模型。比如我只保留城市名、温度、天气状况，拼成“北京，温度25度，晴”这种格式，模型处理起来就准确得多。这个思路对所有Agent工具都适用：工具返回给模型的内容越精简、越结构化，模型的判断就越稳。

4.3 Agent陷入循环调用或者超时

第三个坑是Agent执行到一半卡死，日志显示它在反复调用同一个工具，或者在两个工具之间来回跳。这通常有两个原因：一是Agent在“反思”环节发现拿到的结果不理想，试图反复重试；二是工具本身响应太慢，触发了超时。解决的方法是给Agent节点设置最大迭代次数（我一般设3到5轮），给工具节点设置超时时间（一般10到30秒）。另外还可以在提示词里明确要求“如果一次调用没有得到结果，不要重试，直接告知用户当前服务不可用”。这些限制看着简单，但能防止Agent在生产环境里空转浪费token。

4.4 常见问题速查表

把这两小时遇到的问题整理成一个速查表，以后遇到类似的直接用：

排查的思路说到底就一条：把一个大问题拆成一个个小环节，逐个环节验证，先确定模型能用，再确定工具能用，最后才组合起来。任何一环出问题，单独跑一遍立刻就能看出来，不要全糊在一起瞎猜。

5. 顺手做了个“AI做凭证Agent”的小案例

5.1 需求拆解：凭证Agent到底要解决什么问题

搭建过程中我在搜索资料时看到不少人搜“AI做凭证Agent”，正好我自己也接触过财务场景，就顺手想试试：能不能让Agent按报销单据自动生成会计凭证草稿。

先把这个需求拆解一下。传统做会计凭证，财务人员需要从原始单据里提取关键信息：日期、金额、费用类型、部门、供应商等，然后根据会计准则判断借贷科目，再录入凭证系统。这个过程重复性高，规则固定，很适合Agent来处理。但要注意的是，凭证涉及财务合规，Agent的能力边界应该是“生成草稿+人工审核”，绝不能完全自动化落库，这是底线。

Agent的流程设计大致分五步：第一步，接收报销单文件（图片或PDF）；第二步，走OCR识别，把票据上的文字提取出来；第三步，用大模型做结构化信息提取，转化成日期、金额、供应商、费用类型等字段；第四步，根据预设的科目映射规则判断借贷科目；第五步，输出一张凭证草稿给财务人员确认。

5.2 实现要点和踩坑实录

真正实现时，我调整了一下方案。OCR部分我没有完全依赖大模型，而是先接了一个专门的OCR节点做文本提取，再用大模型做字段解析和科目判断，这样准确率更可控，也避免了大模型直接读图片带来的高token消耗。

科目判断这一步最有意思，也是最考验Agent能力设计的环节。我整理了一份基础的“费用类型→会计科目”对照规则，比如差旅费对应“管理费用-差旅费”，办公用品对应“管理费用-办公费”，餐费对应“业务招待费”等等，然后把这些规则写进Agent的工具描述里。这样Agent拿到的不是一套模糊的会计准则，而是一张明确的映射表，判断起来快也准。

实际测试了十来张模拟发票，大部分生成结果都是对的，但也有不少翻车案例。最典型的一个是：一笔“快递费”被Agent归到了“运输费”科目，但其实按公司制度应该归“管理费用-快递费”。这个问题的本质是，Agent只理解词语层面的映射，不理解你公司的内部管理口径。后来我在描述里明确写了“快递费一律归管理费用-快递费，不要归运输费”，准确率就上来了。

这个案例虽然只是一个Demo，但很有代表意义——它让我意识到Agent落地到具体行业时，最值钱的部分不是模型和框架，而是这些藏在业务流程里的规则梳理。谁把这些经验规则梳理得越细、越准，谁做出来的Agent就越实用。

最后说点实在的

两个小时的体验下来，我最大的感受是：Agent真正神奇的地方不在于模型本身，而在于把模型、工具、记忆、流程这四样东西有序组合起来的过程。你不需要等模型变强才能做Agent，用现成的API就能把许多以前需要手工操作的活儿自动化起来。

如果你想自己动手尝试，我的建议是别一上来就追求复杂框架，也别一开始就想做一个大而全的系统。先找一个你日常工作里最烦、最重复、最规则化的小场景，比如自动整理会议纪要、自动抓取网站信息、自动给客户发邮件，然后用n8n这类工具把它串起来跑通。一个能用的Agent，往往比一个架构漂亮但躺在GitHub里吃灰的项目有用得多。

最后再分享一个小技巧：搭建Agent的过程中，你会发现系统提示词的调试是个反复迭代的过程，一次写不好很正常，别灰心。我的习惯是每调整一次提示词就随手记录下来调整前后的效果对比，攒几次之后你会对自己的模型和工具脾性了如指掌，写提示词的效率会成倍提升。这比看一百篇教程都有用，真的。