企业官网建设流程全解析

一天涨983星——“AI开始自己做SEO”这个信号，值得每一个站长征、每一个SEO从业者、每一个做自动化工具的人停下来认真看一眼。事情的主角叫Hermes，一个开源的AI智能体项目，它在接入了MCP协议之后，不再只是陪你聊天、帮你写文案，而是能够直接打开浏览器、读取页面结构、诊断title和meta、修改JSON-LD结构化数据、提交代码修改，整个流程不需要人守在旁边。

这个标题里藏着三个关键角色：Hermes是执行体，MCP是让它“长出手脚”的协议层，SEO则是它第一个被验证的真实商业场景。这篇文章我从头到尾拆一遍：Hermes到底是什么、MCP解决了什么问题、AI又是怎么一步步自己把SEO跑起来的，最后再把实际操作中踩过的坑和排查经验一并交代清楚。无论你是想给自家站点加一个自动化SEO巡检，还是单纯在观望Agent落地的可能性，这篇都能给你一个可以抄作业的完整路径。

1. 983星背后：这不是一次普通的涨星

1.1 数据信号如何解读

回到“一天983星”这个数字本身。对开源项目来说，单日拿到将近一千个star，几乎等于在技术圈投下了一颗信号弹。很多小团队做了一整年的开源工具，累计stars可能都还不到1000。而Hermes之所以能在一天之内拿到983，说明有大量的人在某个瞬间感知到了它的价值，并且心甘情愿地点下那颗星，而不是刷到之后就划走。

为什么是“这个瞬间”？因为Hermes过去在圈内算是一个相对小众的Agent框架，定位更像是“能跑本地大模型的个人助理”。它有skill机制，能挂载一些工具，能完成多轮对话，但多数人用完之后的感觉是“这不就是个聊天机器人嘛”。直到它接上MCP，把能力真正释放给了浏览器——让AI去“看”网页、“点”按钮、“读”源码、“改”内容，故事一下子就变得完全不一样了。一个能自己操作浏览器干活的Agent，和只能输出文字建议的Agent，是两个物种。

这种爆发也直接反映在社区的热度分布上。热词里出现了大量“hermes怎么安装”“hermes桌面版如何配置”“hermes agent怎么使用”这类入门问题，也出现了“hermes接入企微bot”“hermes agent obsidian”“codex无法找到mcp”这类进阶与生态联动问题。一个项目一旦让新手开始追着问安装步骤，让老手开始研究横向集成，它就真正跨过了“自嗨”阶段，进入了主流视野。

1.2 这波星标背后的真实信号

我拉了一下时间线，发现这次爆发跟“AI Agent自主操作浏览器”整个赛道的升温是同步的。海外几个大厂都推出过类似的computer use能力，但要么闭源，要么对运行环境有严格的限制。Hermes走了一条更接地气的路：开源、本地部署、通过MCP不管是接DeepSeek还是别的模型都能跑通。这就让大量开发者、独立站长、SEO外包团队看到了一个“可控的自动化SEO助手”的可能性——不用把站点数据交给一个黑盒云端服务，而是自己掌握全部链路。

同时，MCP协议本身的普及速度也在肉眼可见地加快。热词里能看到X32DBG有人做MCP插件，Cheat Engine有人做了MCP桥接，Dify接浏览器MCP的教程满屏都是，同花顺这种金融终端都开始对外接MCP，Codex接入Figma、蓝湖更是把MCP用成了常规操作。这说明MCP早已不是一个躺在GitHub README里的协议名词，而是AI操作真实世界的“通用插座”。Hermes接MCP并不是孤例，它只是生态成熟到这个节点之后，一个恰好长在流量风口上的必然产物。

2. Hermes、MCP和SEO三者是怎么咬合的

2.1 一次说清Hermes是什么

热词里有人问“hermes agent怎么安装”“hermes studio下载”“ubuntu安装hermes”，说明很多新手对这个项目还停留在“听说过，但不知道从哪下手”的阶段。Hermes本质上是一个开源的AI Agent运行时，你可以把它理解为“AI的躯壳”：它本身不负责“思考”，但负责调度模型、管理上下文、调用工具、维护任务状态。它支持通过API方式接DeepSeek、GPT、Claude等各家大模型，也支持本地模型，这让它既灵活又没什么绑定成本。

它的形态也有好几种：桌面版适合个人在Windows或Ubuntu上交互式使用，v0.21引入的bot mode则适合无人值守的自动化任务。你可以在终端里用命令行启动一次任务，也可以让它作为后台服务常驻，定时醒来干活。从安装角度，很多人卡在“怎么指定安装目录”上——实际上Hermes支持通过安装参数指定目录，也可以直接下载免安装包解压后运行，配置文件一般落在用户目录下的.hermes目录，windows版则在安装目录下找config文件夹即可。

Hermes的架构核心是三件事：模型槽位、skill机制、MCP Client。模型槽位解决“用什么脑子想”，skill解决“按什么流程做”，MCP Client解决“用什么手操作”。这三者配合好了，它就不再是一个只会张嘴说建议的聊天框，而是一个真的能按SOP执行任务的数字员工。

2.2 MCP：AI Agent的USB-C口

“MCP是软件协议还是硬件协议？那个概念叫什么来着？”——这是热词里一条特别真实的提问。准确回答：MCP（Model Context Protocol，模型上下文协议）是一个应用层软件协议，和HTTP、WebSocket处在同一概念层级，它解决的核心问题是“AI模型如何标准化地请求外部工具、获取外部上下文”。

打个比方。以前想让AI用搜索引擎，你得为它单独写接口调用代码；想让AI读本地文件，又要再写一套文件访问层；想让AI操作浏览器，那就得更复杂地封装自动化脚本。每一个能力都要定制，每一种Agent和工具之间都是“点对点”的关系。MCP干的事情，就是把所有外设统一成了USB-C接口——工具方只要实现一个MCP Server，Agent方做好MCP Client，两者就能自动握手、交换能力描述、执行工具调用、返回结构化结果。一个工具封装好，任何支持MCP的客户端都能直接用，不再需要为每个Agent各写一套适配。

这和传统function calling的区别一定要搞懂。Function calling是模型厂商私有API方案，你用了OpenAI的function calling，换到别的模型就要重写；MCP是开放协议，只要工具实现了，Claude Desktop能用、Codex能用、Dify能用、Hermes也能用。这也是为什么Hermes接入MCP之后能调用的“设备”数量暴涨——浏览器、数据库、搜索引擎、Git仓库、企业IM，一个配置文件全部接上，而且不是每个工具单独写代码，只是往配置里加一段JSON。

2.3 SEO与Agent天然是CP

抛开那些复杂的技术名词，回到一个朴素的问题：为什么偏偏是SEO成了第一个被AI“自己做”的典型场景？因为SEO工作有一个极其鲜明特征：重复、繁琐、大量看页面、大量改标签、频繁验证结果。人做SEO最耗时间的不是定策略，而是执行——打开一个页面看title是不是超了60字符，检查H1是不是唯一，确认canonical有没有指错，meta description是否丢失，JSON-LD里有没有语法错误，sitemap更新没有，404链接有多少……

这些动作恰好是Agent最擅长的：规则明确、有反馈闭环、改完可以重新抓取验证。而且SEO的整个操作过程高度依赖网页交互，浏览器MCP正好提供了点击、滚动、填写表单、读取DOM的能力。Hermes接上MCP之后开始“自己做SEO”，本质上不是发明了什么新方法论，而是把一条原本靠人力堆出来的RPA流水线，升级成了“理解意图+自主执行+自动验证”的智能流程。

3. 核心落地路径：Hermes如何自动做SEO

3.1 先把SEO任务拆成Agent能理解的五步

要让Agent干活，第一步不是写代码，而是把人类脑海里的SEO工作流程拆解成机器可执行的任务序列。我建议拆成五个环节，这也是我在实际项目中验证过的结构。

第一，数据采集：访问目标页面，读取页面标题、meta描述、H1到H6的标签层级、canonical链接、结构化数据JSON-LD、图片alt属性、内链外链状态。到这一步为止，Agent和人做的动作是一样的，只是它不用开几十个浏览器标签页。

第二，诊断分析：对照SEO最佳实践库，逐项找出问题。比如title过长或缺失、meta描述为空、H1重复、正文里没有H2分割、图片缺alt、sitemap未更新、页面存在大量404链接等。这里的关键是规则库要足够细，不能只写“检查标题”，还要写明“标题在50到60字符之间最佳，缺失或超过会被判失败”。

第三，生成修改方案：针对每个诊断出的问题，生成可落地的修复方案。比如“把这段标题改成XXXX”“给这个页面补充meta描述”“给这个图片加上alt文本”“在页面底部插入一段FAQPage JSON-LD”。方案必须具体到可以直接执行，而不是模糊的“优化一下”。

第四，落地修改：直接修改页面源码、提交Git commit，或者调用CMS接口更新内容、生成一个修改清单让后台编辑审核。这一步要看你给Agent开放了多大的权限，建议从生成PR开始，人工确认后再合并。

第五，验证与复盘：重新爬取修改后的页面，确认修改真的生效，title变成预期值了，meta描述出现在页面代码里了，JSON-LD通过语法校验了。最好把修改前后的指标变化记录下来，形成一份可视化报告，这样既能给自己看，也能给团队或老板交代。

实际上你只需要给Hermes下一条指令，比如：“检查首页、关于页、博客列表页的SEO健康度，修复所有发现的title、meta、H1和结构化数据问题。”接下来它会按照Skill里定义好的流程，自己调用MCP工具去执行。这五个环节里，最容易被低估的是第五步验证——很多AI生成的内容看似没问题，但实际写进页面之后可能因为转义问题、编码问题导致结构化数据失效，所以验证环节必须写进流程，并且建议每次都在真实浏览器渲染状态下再验一次。

3.2 这套链路里每个MCP都有明确的分工

要实现上面这套流程，以下几类MCP server基本是标配。我直接给出一份参考选型表格：

在这张表格里，浏览器MCP最容易被忽视，但恰恰是最关键的。Fetch MCP拿到的只是服务器返回的原始HTML，遇到大量JS渲染的现代站点，很多关键信息是拿不到的——动态生成的H1、lazy-load的图片alt、SPA路由切换后的内容、基于用户交互才出现的模块，这些都需要真实浏览器执行完JavaScript之后再读取。Playwright MCP会用Chromium打开页面，等待网络空闲，读取渲染后的DOM，这一点更接近用户实际看到的样子，也更接近搜索引擎爬虫最终索引到的状态。

3.3 配置实例：一份可以直接抄的mcpServers文件

下面给出一份我在Ubuntu环境里实际跑过的Hermes配置示例。安装好Hermes之后，配置文件位于~/.hermes/config.json，Windows版本则在安装目录下的config目录里。编辑这个文件，把MCP server列表填进去：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }, "fetch": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-fetch"] }, "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/var/www/mysite"] }, "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://username:password@localhost:5432/seolab"] } } }

这里有三个细节需要单独说。第一，npx方式的好处是免安装、首次运行自动拉包，坏处是首次启动慢、且依赖网络；生产环境建议用npm install -g把每个server装成全局命令，然后config里直接写命令名，启动时间会快不少。第二，filesystem server的目录参数一定要只授权站点源码目录，不要图省事授权整个根目录，否则Agent在任务过程中误读写系统关键文件的风险会成倍增加。第三，postgres的DSN连接串里如果有特殊字符，比如@符号或冒号，记得做URL编码，不然解析会出错，这是我实际踩过的坑。

配置完成后，重启Hermes，终端里执行hermes mcp list，会看到所有server的连接状态。如果显示failed，多半是node版本过低或者依赖没拉下来，升级Node到18以上基本能解决。

3.4 Skill机制：把“知道怎么做”变成“按SOP做”

有了MCP连接，Agent手上有了工具，但如果没有操作手册，它仍然可能会自由发挥。Hermes的skill机制就是用来解决这件事的。一个skill本质上是一个带步骤说明的文件夹，里面告诉AI：什么场景下使用这个技能、先做什么后做什么、每步调用哪个MCP工具、输出什么格式的结果。

我自己常用的一个SEO巡检skill目录结构是这样的：

seo-audit/ SKILL.md checklist.yaml templates/ title-pattern.txt faq-schema.jsonld

SKILL.md是给Agent读的核心文档，里面写着：

• 输入：一个URL或一组URL
• 步骤1：用playwright打开页面，等待5秒，截图保存到/tmp/seo_shots
• 步骤2：读取document.title、meta[name=description]、h1、h2、link[rel=canonical]、所有script[type=application/ld+json]
• 步骤3：按checklist.yaml逐项打分
• 步骤4：把报告输出为Markdown，每条修复建议附上具体的HTML片段或JSON-LD代码

checklist.yaml是规则表，我习惯把它做成可配置的样子：

rules: - name: title_length description: Title标签长度应该在50-60字符之间 query: "return document.title.length" pass: "value >= 50 && value <= 60" - name: meta_description_exists description: 必须有meta description且长度不小于80字符 query: "return document.querySelector('meta[name=description]')?.content || ''" pass: "value.length >= 80" - name: unique_h1 description: 页面只能有一个H1 query: "return document.querySelectorAll('h1').length" pass: "value === 1" - name: canonical_exists description: 页面必须有canonical指向自身 query: "return document.querySelector('link[rel=canonical]')?.href || ''" pass: "value === document.location.href"

有了skill之后，你连长长的Prompt都不用写，直接说一句“跑一遍seo-audit，对象是/products/下所有页面”，Hermes就会自己去读skill、调工具、出报告。实际用下来，skill的价值不光是让AI不乱来，更在于团队内部可以沉淀和复用——你新招一个实习生，不需要他背SEO规范，他只要会用Hermes跑skill就行。

3.5 实战案例：FAQPage结构化数据是怎么被AI自动修好的

热词里有一条“谷歌seo的faqpage结构化数据是怎么回事”，正好拿它做一次完整示范。FAQPage是Google搜索结果里那一类可展开的手风琴式问答卡片，它的实现方式是在页面上嵌入JSON-LD结构，schema.org类型为FAQPage，核心字段是mainEntity，里面包含一组Question和acceptedAnswer。前几年大家一窝蜂地给所有页面都堆FAQ，后来Google改了政策，只有页面上真实存在问答内容时才适合用它，滥用会被标记并直接失去富媒体展示资格。

AI在这个场景里能做什么？它可以批量检查全站：每个带FAQPage的页面是否真的有问答内容、JSON-LD格式是否合法、每个Question是否都有acceptedAnswer、回答是否比题目本身更有信息量。发现问题之后，它会直接生成修正后的JSON-LD文本并替换原有片段。

比如下面这段就是典型的失败结构：

{ "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "你们的发货时间是多久？", "acceptedAnswer": { "@type": "Answer", "text": "" } } ] }

acceptedAnswer的text字段是空的，这种结构绝对是会被搜索引擎打回的。人工要在一个几百个SKU的电商站里找出每一个空answer，工作量非常大。但给Hermes下一条指令，比如“扫描所有含FAQPage的页面，找出answer为空的JSON-LD，对照页面正文提取对应答案，更新到结构化数据中并提交commit”，它能一晚上把成百上千个页面全部改完，并且每个改动都会在commit message里标注对应的页面路径。

实际操作中还有一个额外的收益：AI不仅能修空answer，还能根据页面的正文内容自动生成新的FAQ问答对。比如一个商品详情页里有一段“支持7天无理由退货”的说明，AI就能在整站FAQ结构里增加一条对应问答。不过这里要提醒一句：新增问答对的时候，必须保证内容在页面上真实可见，Google对“页面里没有的内容出现在结构化数据里”这一项查得非常严，审核尺度比人眼还准。

3.6 调度与bot mode：让它晚上自己爬起来干活

Hermes v0.21引入bot mode之后，这件事才真正有了规模化的价值。bot mode意味着你不用开着桌面版盯着它操作，配置好任务队列之后，系统到点自动把Hermes叫起来，它自己打开浏览器、执行巡检、改完代码、发通知，整个流程完全无人值守。我实际体验下来，比较稳的方式是把Hermes作为一个systemd服务常驻，用一个简单的调度器每小时检查一次任务队列，发现待处理任务就启动一条hermes run --task xxx。

这样一来，你等于在团队里多了一名不睡觉的数字运营实习生。它的工作节奏是这样的：每天晚上凌晨2点跑一遍全站SEO巡检，生成报告，把需要修改的页面列出来，按照skill里的规则自动提交PR，早上8点把昨晚的巡检摘要发到企微群里。团队每天早上只需要花十分钟过一遍它提交的PR，确认合并。连续跑一个月，能大量解放人力，而且它不会漏掉页面、不会抱怨活多、不会因为重复工作而走神。

4. 常见问题与排查技巧实录

4.1 高频故障排查速查表

跑这种自动化任务，第一周必然出各种幺蛾子。我把自己遇到的、朋友遇到的典型故障整理成了一份速查表，你可以直接收藏备用：

4.2 三个最有价值的避坑经验

第一个坑一定要讲：别给Agent直改线上文件的权限。虽然技术上它完全可以直接修改生产站点的代码，但这样做风险极大——它可能在一个错误的规则判断下，把整个页面的title和description批量替换成错误内容。我的方案是给GitHub MCP配只读权限，让Agent创建PR而不是直接commit到主分支。所有改动先到PR里，人在GitHub网页上确认、合并。自动化负责干活，人负责把关，这是人机协作里最健康的分工。

第二个坑：反爬是永久的课题。浏览器MCP虽然行为更接近真人，但搜索引擎不会因为你是AI就睁一只眼闭一只眼。实际体验下来，单位时间内的请求量必须压到非常低，否则会触发各种验证页面。我的做法是：在自动化巡检任务里给每个页面请求之间加上2到5秒的随机延迟，并发控制在1到2个浏览器标签页。这样虽然每次巡检耗时变长了，但稳定性明显提升，不会跑了一半就被打断。

第三个坑：日志必须开、必须留。Hermes跑SEO任务经常是深夜无人在场，出了问题只能翻日志。我强烈建议把Hermes的所有输出重定向到一个日志文件，同时在任务结束时生成一份Markdown格式的巡检报告。日志不仅能帮你排查故障，更是给团队证明“AI在干活”的最好证据。每天早上的汇报里，把前一天Agent完成的工作量、修改的页面数、发现的问题数量贴出来，比任何口头描述都有说服力。

4.3 关于模型选择的一个补充建议

Hermes支持接入很多模型，但实际跑SEO自动化任务的时候，模型的选择会影响整个流程的稳定度。我实测下来的经验是：相对轻量的模型适合做数据采集和规则匹配，但在“理解页面语义并生成高质量回答”这类任务上会明显吃力；而更强的大模型虽然理解能力好，但每次调用的token开销大，跑大规模巡检时成本会快速上升。

所以我现在的习惯是分层使用：每天的全站巡检让轻量模型负责，把规则匹配、字段提取这类机械且重复的活交给它；等到需要生成新的FAQ问答对、重写meta描述这类创作型任务时，再切换到更强的模型单独处理。Hermes在这方面的配置比较灵活，你可以在skill里为不同步骤指定不同的模型，这样成本和效果之间能找到一个很舒服的平衡点。

5. 从983星到长期主义：我的体会与扩展玩法

说句实在话，一天983星对项目本身是好事，但对待这件事的心态要放平。star只是一个关注信号，不代表项目已经功能完备、没有严重bug、不会有破坏性变更。我也见过不少开源项目star暴涨之后，issue堆积如山、作者精力耗尽、更新停滞、兼容性破碎的案例。但这不妨碍我们去理解它为什么会火：因为SEO人员普遍不是程序员，而他们的工作却充满了编程式的重复劳动——这正是AI Agent能够补位的最佳场景。一个让AI自己打开浏览器、自己诊断、自己修改、自己提交验证的完整闭环，对任何一个靠SEO吃饭的人来说，都意味着人力成本的极大释放。

如果你想在自己的站点上复现“AI自己干SEO”这件事，我建议按这个节奏循序渐进地来。第一步，先在本地跑通Hermes，配上Playwright MCP，让Agent帮你抓取一个页面的title、meta、H1和结构化数据。第二步，把抓取范围扩大到站点地图内的所有页面，让它输出一份全站体检报告。第三步，选择报告中的某一类问题，比如meta描述缺失，让Agent批量修复并生成PR。第四步，加上定时调度和企微通知，让整个流程每天自动运转起来。到第四步为止，你已经拥有了一套完整的自动化SEO闭环。

扩展玩法也有一些现成的方向。如果你有多个站点，可以让Agent分别巡检并输出对比报告；如果你积累了足够多的历史数据，就可以把PostgreSQL里存下来的巡检指标做成趋势报表，观察页面权重、索引量、排名变化之间的关系；你还可以接入关键词排名监控类MCP服务，让Agent定期追踪核心关键词的排名变化，当排名持续下滑时自动检查页面内容并给出调整建议，甚至直接生成一版优化后的title和meta交给人工确认。结构化数据方面，同样一套流程可以复制到Article、Product、BreadcrumbList、Organization这些类型上，不局限于FAQPage。

我个人的体会是，技术实现反而是最不困难的部分，真正决定这套系统成败的是你给AI画的边界和写清楚的规则。一个好的Skill文件，远比一个强模型本身重要。你需要写明白：哪些场景下允许全自动执行，哪些场景下必须停下来等人确认；哪些字段AI可以自由发挥，哪些字段必须严格遵守品牌规范。这比让AI“自由发挥”可靠得多——它毕竟不知道你的商业底线在哪里。

最后分享一个我一直在用的小技巧：给Hermes的每个SEO任务都加上一个“最终确认”环节，让它在执行完所有修改之后，生成一份diff摘要，发到团队群里。摘要里清清楚楚地标出“改了哪个页面、原内容是什么、改后内容是什么、为什么这么改”。就这一条，能让整个自动化体系在团队里存活得比大多数AI项目都久——因为每个人都能看到它在干什么、为什么这么干，信任感一旦建立起来，这套“AI自己干SEO”的流水线就真正跑成了你自己团队的固定成员。