企业官网建设流程全解析

上个月我把自己的自动化工作台彻底重构了一遍，起因其实特别朴素：我不想每天起床第一件事变成打开五六个网页挨个问AI“昨天有什么值得看的”“这个方案哪里有问题”“待办里哪些该优先干”。所以我开始找一种能“自己运转”的AI协作应用，让它7×24小时常驻，到点干活、干完汇报，而不是等我提问才动弹。

陆陆续续试了几款所谓All-in-One工具之后，我最后定下来的方案既不是一个闭源商业软件，也不是一个昂贵的订阅制服务，而是一套由开源应用加个人API密钥组合出来的协作体。所以标题里的“免费”我特意打了引号——软件授权确实零成本，但服务器和模型调用还是有一笔小开销。不过算下来一个月大概就是一杯咖啡的钱，比任何“Pro会员”都便宜得多。这篇就把我的完整思路、搭法、账单和踩坑记录都摊开讲，给想折腾同样东西的人做个参考。

1. 先搞清楚一件事：24/7的AI协作应用，到底在协作什么

很多人的第一反应是：AI协作应用不就是把ChatGPT挂到网页上，然后一直开着吗？不是。那是聊天窗口，不是协作体。

真正的协作，指的不止是一个模型在工作，而是多个承担不同职责的Agent（智能体）围绕同一个目标轮流接力、相互配合。我常用一个编辑部比喻来解释这件事：

• 采集员：负责盯信息源，定时去抓取网页、RSS、邮件、数据库变更，把原始材料搬回来。
• 编辑：负责理解原始材料，做摘要、分类、提炼观点，把散乱信息整理成结构化要点。
• 主编：负责根据要点做决策，判断今天应该推进哪些任务、哪些内容值得保存、哪些需要提醒我。
• 校对/执行：负责格式化输出、写入知识库、发送通知。

单个大模型当然也能完成所有这些步骤，但它同一时间只能处理一段上下文，而且没有人替它“盯着时间”。当我需要每天凌晨抓取20个信息源、早上8点前生成报告、白天再根据报告自动拆解任务时，单靠一个聊天窗口是完全做不到的。24/7的意义就在这里：让不同Agent按计划接力，而不是所有事都堆在用户提问这个触发点上。

还有一个很关键的点：协作不只是模型之间的“对话”。真正跑起来之后，你会发现协作的底层其实是任务队列、状态存储和消息路由。Agent A产生的结果，要能被Agent B正确读取；Agent B要能调用外部工具去执行动作；执行结果还要能回流到工作流里形成闭环。这已经不再是“提示词工程”能覆盖的范围，而是轻量级系统编排。

我用一个很直白的类比：单个AI是“一个很聪明的实习生”，你问什么他答什么，但你不催他他不会主动干。多个Agent协作起来之后，等于是“一个不受上下班限制的编辑部”，有人负责盯梢、有人负责写稿、有人负责签发，你只需要每天看最终版。这也是为什么标题敢于写“24/7”——它不是挂着不退出，而是真的有定时任务在跑。

2. “免费”的真实含义：免费层、自托管和个人API成本

2.1 免费Plan究竟免了什么

市面上的AI应用，绝大多数都提供免费Plan，但仔细看条款会发现“免费”后面跟着三行小字：每日消息数限制、模型速度降级、高级功能锁住。我用过几个之后的基本体感是：单聊场景下免费层完全够用，但一旦要做自动化流水线，免费层会遇到两个硬伤。

第一个硬伤是频率限制。很多免费层限制每小时请求数，而一个定时工作流经常需要在几分钟内连续调用十几次模型接口，很容易触发限流，导致任务中途失败。第二个硬伤是函数/工具调用权限。Agent能不能真正去发请求、查数据库、回写文件，往往属于付费功能。没有这个权限，Agent就只能在对话里“纸上谈兵”，协作无从谈起。

所以纯云端的免费Plan，对于24/7协作这件事来说，基本是“看起来免费，用起来卡脖子”。

2.2 自托管为什么更符合“免费”的定义

我最终采用的是自托管开源应用 + 个人模型API的组合。开源应用本身不需要License费用，部署在自己的服务器或旧电脑上，随便跑几个进程，没有按席位收费一说。等于把“软件”这一层的成本清零了。

需要掏钱的只有模型API调用费。模型API目前普遍是按Token计费，用量少的时候一个月的成本低到可以忽略。加上现在的开源模型和新一代国产模型的API价格已经压得很低，日常文字处理类任务一天跑几百次调用，也就是几块钱的事。

我不太建议为了追求绝对“零成本”去本地跑大模型。除非你手头有24GB以上显存的显卡并且不在乎推理速度，否则本地小模型在长文本摘要和复杂工具调用上的效果会明显打折扣。个人实践下来的性价比方案是：应用层自托管，模型层用商业化API。这样既拿到了自托管的免费和可控，又能保证模型质量。

2.3 我每个月的真实账单

这里要强调一个容易误导人的地方：我说“免费”，不是指一分钱不花，而是指没有固定订阅费，花多少完全由自己掌握。我挑一个月的数据，列成一张表：

对比一下商业协作工具的个人版订阅，一个月怎么也要几十到上百元。而我这套方案一个月30块，还是因为我把模型API当“按量付费”的算力资源用，省着点甚至能压到20块以内。如果哪天彻底不用了，关掉进程就零成本，不存在“绑定的年费”。

3. 手把手搭出来：一套可持续运行的AI协作工作台

3.1 我先整体说一遍数据流，再拆细节

整套系统没有用一个神秘的“AI总控大脑”，而是四个角色互相配合，分别是采集任务、理解任务、决策任务、通知任务。数据从信息源出发，经过每个Agent的处理，最终落回数据库和消息通道。

日常工作流是这样的：凌晨两点，定时触发器醒来，通知“采集员”去抓取我配置好的RSS源和网页；采集到的原始内容扔进一个统一的消息中心；早上6点半，“编辑”从消息中心取出待处理队列，逐条生成摘要并打标签；7点，“主编”把摘要汇总成一份晨报草案，根据我预设的规则给出今日重点建议；7点05分，通知模块把晨报推到飞书群里，同时把结构化结果写入知识库，方便我白天去检索。

3.2 Agent 1：定时采集器

采集器负责的是“定时执行外部请求”的能力。我用开源自动化工具n8n来承担这个角色，你可以把它理解成一个带调度器的乐高积木。它不需要写太多代码，靠节点连线就能完成定时触发、HTTP请求、数据解析和入库。

我的n8n工作流里有三个最关键节点：

• Schedule Trigger：定义cron表达式，比如0 2 * * *代表每天凌晨2点整触发。
• HTTP Request：向目标RSS或网页发出GET请求。
• Function：把HTML或XML转成纯文本，过滤广告和导航噪音。

这里有几个容易踩的坑，第一是目标站点反爬。很多网站对高频抓取会返回403，我的处理方式是在请求头里带上正常的User-Agent，并且把抓取频率控制在每个源至少间隔10分钟以上。第二是编码问题，中文网站经常出现乱码，需要显式声明UTF-8解码。第三是失败重试，网络请求没有百分百成功的道理，n8n里要给HTTP节点配一个“错误时重试”的规则，不然某天源站临时抽风，整个流水线当天就罢工了。

3.3 Agent 2：内容理解与摘要器

抓回来的内容是脏的、长的、重复的，直接丢给大模型不仅费Token，效果也差。所以第二个Agent负责清洗和结构化。

我用的核心平台是Dify，开源版的Agent工作流引擎。在这里创建了一个名为“summarize_news”的自定义Agent，然后把n8n采集到的文本通过HTTP请求传给它。这个Agent内部做三件事：

先用一个“预处理”步骤把文本截断到合理长度，去掉多余空白。然后进入大模型节点，我写的System Prompt大致是这样：

你是信息摘要专家。你收到的内容是采集自多源的原始文本，可能包含重复段落。 处理要求： 1. 提炼5-8个关键要点，每点不超过40个字； 2. 判断这篇内容的主题类别，从[技术, 产品, 行业动态, 个人成长, 其他]中选择； 3. 识别是否包含数据、结论或可执行建议； 4. 输出JSON格式，包含title, category, summary, action四字段。 不要编造原文没有的信息。

注意这里要求输出固定JSON结构，而不是自由作文。固定结构的好处后面会体现——下一个Agent直接解析JSON，不用再靠大模型猜字段。

然后是一个校验节点，我让另一个小模型或同模型做一次“格式自检”，如果发现JSON解析失败就重试一次。这样处理完之后，n8n那边拿到的是一个干净、稳定的结构化对象，而不是又长又乱的对话文本。

3.4 Agent 3：决策与分发器

有了一批结构化的“新闻条目”之后，还缺一个角色决定哪些该告诉我、哪些该入库、哪些该触发后续动作。这个角色就是决策器。

我给它定的规则很清楚：凡是包含项目关键词（比如我关注的几个技术方向）且摘要里出现“发布”“开源”“变化”“案例”等行为词的内容，标记为“高优先级”，直接进晨报首屏；其他内容按分类入库，只保留标题和摘要，不推进当日晨报；如果某个来源一天内连续三条以上都是低质量重复内容，就自动降低这个源一周的抓取权重。

这种规则看起来不复杂，但它把“AI的判断”和“人的偏好”结合起来了。不是让模型自由发挥今天想推荐什么，而是让模型在我划定的规则框架内做选择。说白了，AI负责干重活，我负责定标准。这套思路避免了模型“过度发挥”带来的不可控感，尤其在长期无人值守运行时，规则比感觉可靠。

3.5 通道与入口：不用打开后台看

一个7×24跑着的系统，最怕的就是“跑是跑了，但结果没人知道”。所以通知模块非常重要。我选择用飞书机器人作为主要出口，理由不复杂：手机推送稳定、群机器人接口开放、免费额度对个人完全够用。

n8n里新增一个“飞书发送消息”节点，把决策器输出的一段Markdown直接推到我的群里。格式大致是：

📌 今日AI协作晨报 2025-06-10 1. [技术] 开源Agent框架更新，新增工具调用优化 摘要：……（略） 建议：值得安排时间试用 2. [行业动态] 某云厂商发布新的模型API 摘要：……（略） 建议：关注价格变化，按量成本可能下调 ……

再配合一个Web管理页面，我偶尔想手动触发任务或者改关键词时，在网页上改完配置，第二天自动生效。手动和自动之间留了一道口子，避免完全黑盒。

3.6 配置细节：一份可直接参考的协作配置项

如果只想快速启动，我觉得最少需要三样东西：

• 一个能设置定时任务的工作流工具（我用n8n）
• 一个能创建Agent并暴露API的开源LLMOps平台（我用Dify）
• 一个能推送消息的群机器人或邮件通道（我用飞书）

消息从n8n到Dify的请求怎么发呢？Dify里创建一个“工作流应用”之后，拿到API密钥和API端点，请求路径通常是/v1/workflows/run。n8n的HTTP节点里这样设置：

{ "method": "POST", "url": "https://你的域名/v1/workflows/run", "headers": { "Authorization": "Bearer app-你的密钥", "Content-Type": "application/json" }, "body": { "inputs": { "raw_text": "{{ $json['content'] }}" }, "response_mode": "blocking", "user": "daily-robot" } }

其中{{ $json[’content‘] }}是n8n里引用上一步节点的语法，具体字段名要根据你的数据流改。反正核心逻辑很直白：把原始文本作为参数传过去，Dify跑完整个Agent工作流，返回结构化JSON，n8n再决定入库还是发通知。

还有一点要提醒：API密钥千万别硬编码到触发条件里，更别推到前端页面。我一开始图省事，把密钥写在工作流的Header里，后来发现日志会记录完整请求头，有泄露风险。后来我改成了环境变量引用，n8n也支持，改起来不麻烦。

4. 连续跑一个月后，我踩过的坑和调优记录

4.1 半夜任务全失败：根因是机器休眠和网络重连

第一次部署完毕后，我兴冲冲地连跑两天，第三天早上起来一看晨报是空的。排查链路是这样的：

先看n8n的执行记录，发现凌晨2点那次触发的状态是“失败”。再看错误日志，报的是“无法连接主机”。我第一反应是目标RSS源挂了，但手动用浏览器打开那个源又完全正常。后来我蹲到凌晨2点守着看，才发现问题根本不在目标网站，而在我家这台迷你主机：系统默认在无人操作时会休眠，任务触发时机器已经睡了，网络唤醒没配置好，自然什么都抓不到。

修复方案有两层。第一层是把操作系统电源计划改成“永不睡眠”，同时关闭网卡的省电模式。第二层是给关键进程加了守护，用systemd把n8n和Dify都托管成服务，设置Restart=always，这样即使进程崩溃或机器重启，服务也会自动拉起来。从那次之后至今，我还没有因为“机器睡了”导致任务漏跑的情况。

这件事给我的教训是：24/7系统最大的敌人不是AI不够聪明，而是运行环境不可靠。真要追求稳定，宁可用一台云上最便宜的虚拟主机，也不要依赖一台连睡眠模式都管不住的电脑。如果你不想折腾家里硬件，云上几块钱一个月的轻量服务器反而更省心。

4.2 Agent卡在“工具调用”循环里出不来

第二个坑发生在加了“网页搜索”工具之后。我给决策器接了一个搜索工具，希望它在碰到陌生主题时先搜一下再下结论。结果某天我查看任务队列，发现同一个任务重复执行了27次，白白烧了上万Token。

排查后发现是典型的Agent循环问题：搜索工具返回的内容不含决策器想要的信息，决策器觉得“数据不够”，又发起搜索；搜索回来后跟之前结果差不多，它又觉得不够，如此反复。很多Agent框架默认的绕圈机制就是“工具调用没有达到预期就再来一次”，在无人值守场景下简直就是吞金兽。

我的修复方案是三层：

1. 在工具调用节点上设置最大迭代次数，超过3次就强制结束，把当前已有信息作为结果返回。
2. 在搜索工具的Prompt里追加一句：“如果搜索两次后仍无关键信息，停止搜索并明确回答信息不足”，给模型一个合法的“放弃出口”。
3. 开启耗时监控，任何单次Agent执行超过5分钟就告警并自动终止。

这个坑其实非常有代表性。大模型本身并不具备天然的“止损意识”，它倾向于顺着指令继续执行。编排层必须替它踩刹车，否则一个坏任务就能拖垮一整天的额度。

4.3 上下文膨胀导致摘要质量变差

跑了一个星期后，我拿晨报和人工核对，发现摘要质量出现肉眼可见的下滑：有些要点开始重复，有些明明很关键的细节漏掉了。我起初怀疑模型温度参数或Prompt不稳，后来仔细看才发现是Dify会话里的上下文越积越长。因为我把多日的内容约到同一个会话里处理，模型每回答一次要读的历史信息都在增加，这既拖慢速度，又稀释了对当前正文的关注度。

调整思路很直接：让各Agent之间的交接是“结构化数据传输”，而不是“对话历史传递”。换句话说，Agent B不需要知道Agent A之前聊了什么，它只需要每次拿到一条独立任务记录。我在Dify里给每个任务都创建独立会话，不跨任务复用History；同时在n8n里定期清理历史记录表，超过7天的原始数据自动归档到本地文件存储。

调整之后效果立竿见影，摘要准确度和生成速度都回来了。这也印证了一点：在长期运行的体系里，别让系统背太多包袱，每一次任务尽量“无状态”，会让稳定性显著提升。

4.4 免费模型API频控被打爆

我的主力API虽然便宜，但免费配额和低档套餐都有速率限制。刚开始我把所有Agent的调用都部署在一个API Key上，结果早上一堆任务同时起来，瞬间并发超过限制，返回429错误，任务像多米诺骨牌一样接连失败。

排查之后的做法是两步：第一，引入令牌桶，把每秒钟的请求量限制在API允许值的60%以内，宁可排队也不猛冲；第二，把不同Agent拆到不同的Key或者不同服务商上，摘要任务走文本模型A，决策任务走模型B，这样并发错峰，互相不影响。

如果你也想复刻这套结构，建议先在后台画一张“谁调用哪个API”的表格，评估早高峰并发量。不要天真地以为一个Key走天下最方便，频控面前人人平等。

5. 如果让我重新选型：工具对比和更稳的起步路径

5.1 选型对比表

我把自己调研并实测过的主流方案整理成了下面这张表，方便你对照自己的条件来选：

我自己选n8n+Dify组合，是因为n8n在定时和集成上很强，Dify在Agent工作流和工具调用上更成熟，两者把各自擅长的事做得很到位。但如果你对维护两个服务感到头疼，纯n8n也能实现大部分功能，只是Agent内部复杂逻辑写起来更麻烦。先想清楚“你最怕什么”：怕配置复杂就选Dify生态；怕服务太多就减少组件，用少数几个服务硬扛；怕花钱就去自托管，但要接受维护成本。

5.2 建议的起步路径：别一上来就搭五个Agent

很多新手拿到这类教程，最容易犯的错就是一次性把所有Agent都配好，然后直接追求“全自动”。结果一出问题，根本分不清是哪个环节挂了。我更推荐下面这个渐进式路线：

第一阶段（第1周）：只搭一个定时的“每日摘要”任务。用n8n抓一个RSS源，用Dify生成摘要，发一条飞书消息。先跑通最小闭环。

第二阶段（第2周）：加入决策器。规定“什么内容进晨报，什么内容只入库”，让系统自己筛选。此时开始体会“规则+AI判断”结合的感觉。

第三阶段（第3周）：加入第二个信息源，开始配置重试、超时、频率限制。这时候你会自然遇到我上文提到的各种坑，解决掉它们才能沉淀出稳定系统。

第四阶段（第4周及以后）：真正引入多个Agent协作，比如研究助手、定时任务生成助手、知识库归档模块。这时候再考虑任务队列、会话隔离和并发控制。

按这个节奏走，遇到问题时你能很清楚地定位到新增环节，而不至于对着几十个节点一脸茫然。我自己就是走得有点快，前期同时配了五六个角色，出了问题要逐节点查日志，吃了不少苦头。

5.3 后续扩展方向：这套结构还能怎么用

现在这套协作体已经不仅限于“每天一份新闻晨报”了。我在上面长出了一系列新玩法：

• 周报生成器：每周日晚让Agent汇总本周所有任务和知识库更新，自动生成结构化周报，再配一段“下周建议”。
• 待办复盘：每天晚上定时让Agent扫描我的任务清单，对超期任务生成风险提示，并把建议动作写回看板。
• 竞品监控：采集竞品官网、公众号和更新日志，只要出现指定关键词，就立即推送告警。这里对时效性要求高，所以要单独给这个Agent提权重。
• 语音/会议记录转写：把录音文件丢进指定目录，Agent自动转写、摘要、提取待办项，然后分发给对应的人或群。

本质上，我搭的这套协作体不是一个固定应用，而是一个“可以不断孵化新任务”的容器。新任务等于一个新的Agent定义加几条定时规则，不需要再买新软件，也不用改底层架构。

最后聊一点个人体会。折腾这套东西最值钱的部分不是省下的那几十块月费，而是你被迫去理解“AI能稳定干活”的前提是什么：稳定的调度、干净的数据、可控的并发、明确的止损规则，以及一个像飞书机器人这样能随时把结果推到你面前的通道。这些东西放在任何商业应用里也都成立。所以如果你也想复制，我的建议是别把注意力全放在“选哪个模型”上，多花点心思研究任务编排和异常处理——那才是7×24系统真正见功夫的地方。