说自己在做"智能体 SEO"的团队，大多数其实只是在聊天窗口里贴了一段很长的提示词。第一次跑还行。到第二次就出问题了：输出结构变了，数据还是一周前的，而且没人分得清是数字动了，还是提示词飘了。
真正能长期跑下去的版本，只在一个地方不同：方法写在文件里，而不是写在你的消息里。流程写一次，交给智能体，之后不管你有没有记得要求，同一套检查每次都会执行。
这就是全部思路。下面是具体怎么搭、哪个任务该交给哪个智能体，以及它会在哪里悄悄坏掉。
"智能体化"到底改变了什么
可以自动化的东西有三种，而它们并不是同一件事。
工作流自动化 | AI 辅助 SEO | 智能体 SEO | |
|---|---|---|---|
谁决定步骤 | 你提前决定 | 你每次对话决定 | 你一次性以书面方法决定 |
数据来自哪里 | 预先接好的集成 | 你粘贴进去的东西 | 智能体自己去取 |
遇到意外输入时 | 直接崩掉 | 看你的措辞 | 按既定规则处理，或升级上报 |
每次运行的一致性 | 完美但死板 | 低 | 高，同时还能适应 |
最适合的场景 | 大批量、不变的任务 | 探索和一次性问题 | 需要判断的重复性分析 |
实际差别体现在你不再做的事情上。在聊天式工作流里，你要一遍遍重新解释网站、受众、优先级规则和输出格式。每解释一次，就多一次漏掉某项的机会。在智能体式工作流里，这些东西都在智能体每次都会读取的文件里，提示词缩短成一句话：跑一下 9 月的内容衰退检查。
代价也是真实存在的。如果这个任务每次真的都不一样，那就没有可写下来的方法，搭建它只是没有回报的负担。检查 5 万个 URL 的状态码是脚本的活，不是智能体的活。分界线在于：这个任务是否会重复，以及是否需要判断。两条都成立，智能体式就赢。有一条不成立，就别折腾。
四个层次，以及各自的作用
能活下来的智能体 SEO 配置，永远由同样四个部件组成。少一个，就会出现特定形式的失败。
项目上下文。一个存放不变内容的文件夹：网站、服务市场、谁为什么买、什么算转化、真正的竞争对手是谁、编辑规则。它阻止智能体在不理解业务的情况下写出泛泛之谈。跳过这一层，你会得到自信、合理、但毫无用处的输出。
技能。写下来的流程。每一个都说明：什么时候用、需要什么数据、步骤顺序、评分规则、输出格式，以及哪些操作需要你批准。让工作流可复现的就是这一层，而大多数团队跳过的也是这一层。
实时数据接入。让智能体自己去取当前数字，而不是等你导出再粘贴。看自己的表现用 Search Console。看行为数据用分析工具。看自己站点看不到的部分用排名或 SERP 数据源。看页面级事实用爬虫或 CMS 连接。没有这一层，你只是得到一个拿着上个月表格干活的优秀分析师。
提示词。本次任务，仅此而已。如果你的提示词在承载上下文或方法，那它们属于第一层和第二层。
四个层次设置一次，每周的运行就只剩一行。结果不对时，先查是哪一层出了问题，再去改提示词。
Auspia 的观点： 四层模型是这个领域里最有用的概念，同时也是大多数团队过早停下的地方。他们建了上下文文件夹，跳过了技能，最后得到一个消息灵通的聊天机器人。真正的产品是技能。其余都是管道。
哪个任务交给哪个智能体
这是我们被问得最多的问题，而诚实的回答是：差异没有配置差异那么重要。只要使劲推，下面这些几乎都能做大部分 SEO 工作。真正拉开差距的，是各自"最不别扭"的地方，而这决定了三周后你还在不在用它。
智能体 | 最擅长 | 接入方式 | 合适的第一个 SEO 任务 |
|---|---|---|---|
Codex | 代码仓库工作、定时运行、可评审的改动 | 本地文件、终端、git、自动化 | 把每周快照存进仓库，并开一个带报告的拉取请求 |
Claude Code | 依据明确书面策略做长上下文评审 | 终端、项目记忆文件、MCP 连接 | 读取 Search Console 导出和页面源码，给出有依据的判定 |
Hermes Agent | 跨会话记忆的可重复技能 | 带技能体系和持久记忆的开源智能体 | 装一个技能，按同样的节奏跑同样的工作流 |
OpenClaw | 在严格权限下采集浏览器证据 | 浏览器优先，其次本地文件 | 采集移动端搜索实际返回什么，然后停下 |
Pi Agent | 几个月后依然小巧、可预测 | 极简内核，Markdown 技能作为扩展点 | 在你想审计它全部能力时，跑一个范围窄、可读性强的流程 |
两点提醒。这个领域每月都在变，所以让团队选定一个之前，先去各家官方文档核对当前的限制和价格。另外这张表是起点，不是上限。
每种智能体的新手安全版入门方法，我们都单独写了指南：Codex、Claude Code、Hermes Agent、OpenClaw。四个的形态一样：先只读，一次只批准一个改动，上线前先验证。
实际的选择规则取决于你的工作现在在哪里。网站放在 git 仓库里、页面改动就是代码改动，那就从 Codex 或 Claude Code 开始。工作主要是导出、对话和判断，那就从基于技能的智能体开始。你需要看到真实浏览器返回什么，那就需要浏览器接入和严格的权限边界。你想要一个能一口气从头读到尾的最小表面，Pi Agent 的极简内核正是为此设计，代价是你需要的东西都得自己加进技能里。
三个问题就能把五个智能体收敛到一个。先回答它们，再去比较功能清单。
最值得先交出去的任务
别从有趣的那个开始。从无聊、按周期重复、产出物有人读的那个开始。这些回本最快。
内容衰退分诊。拉取同比和环比表现，丢掉低于重要性阈值的项，先查收录状态再看排名、需求、链接和关键词蚕食。你会得到一张 URL 表：流失的点击、可能的原因、支撑证据，以及首选和备选动作。掉了排名的页面需要重写。掉了需求的页面什么都不用做。丢了 canonical 的页面五分钟就能修。团队经常把这三者搞混，而这个混淆并不便宜。
技术问题分诊。按根本原因而不是问题类型来归组，把受影响的 URL 与流量和排名关联，按影响对工作量打分，写修复清单之前先在真实页面上验证排在最前的几项。价值就在这个归组方式上。十行"临时重定向"通常只有一个根本原因，修一个模板胜过修十个 URL。
竞争对手动向。把流量变化背后的页面和关键词切出来，区分品牌词和非品牌词，把每个变化对照一个具名因素去验证：新内容、排名提升、季节性、迁移，或数据伪影。答案是因素和置信度。一个置信度低的大数字，是去细看的理由，不是去反应的理由。
内链和孤岛页面。从已经获得排名或链接的页面里建候选池，找到与每个目标页直接相关的段落，套用读者价值测试：读到这句话中间的人，真的会想点过去吗？输出里关于结构的那一半，价值常常高于链接本身。发现第二大的页面没有任何内链指向它，是一个五分钟就能修、效果却很大的问题。
引用缺口映射。把提示词按主题和购买阶段归组，找出被引用最多的域名和页面，区分来源类型，再读被引用的页面，弄清到底什么才能拿到提及。要有心理准备：输出里有相当一部分来源，正确答案是根本不去联系。论坛和竞争对手自有的资产不是外联目标。
发布后回归检查。用相同设置对比发布前后的抓取，在比对之前先确认两者可比，然后把每处差异归类为"预期内""预期内但实现错了"或"计划外"。这个分类才是报告可用的原因。没有它，你只会得到一堵差异墙和一个做不了的判断。
最常出现的几项，我们写了更详细的流程：每周排名报告、每日监控、外链档案工作，以及不会把你淹没的告警设计。
从一个技能开始，而不是一个部门
最常见的失败，是在一次都没跑过之前，先搭好八个技能、七个连接和一个调度器。结果什么都不工作，而且十六个部件里到底是哪个出问题也说不清。
换成这个顺序来做。
挑一个产出可见的任务。最快能验证的是技术问题分诊，因为你可以直接指向已有的抓取，几分钟内就能判断结果。如果你有 Search Console 历史数据，内容衰退是第二容易的。
在接任何东西之前，先把技能写出来。技能文件应该能放进一页纸，并回答六个问题：什么时候用、需要什么数据、步骤顺序、评分或阈值规则、输出格式，以及哪些操作需要批准。如果一页写不完，说明这个任务还没定义到可以自动化的程度。
只接一个数据源。就是那个技能真正需要的。用不上的连接只会扩大表面，不增加价值。
以只读方式运行，并人工检查输出。挑两条结论，对着源数据自己验证。如果智能体的解释和你看到的对不上，问题在技能，不在模型。
在加第二个技能之前，先加上审批门。所有写操作（发布、重定向、删除、改代码、合并、对外发送）都应该停下来等批准。趁风险还只是一个技能的时候，把这个习惯建立起来。
让它不出错的护栏
这些是我们第一天就会写进项目指令的规则。故意做得很无聊，这正是重点。
- 在你批准写操作之前，生产工具保持只读。
- 任何多步工作流开始前，先让它给出计划。
- 用接好的工具去取证据，而不是靠假设。
- 有对应技能时，遵循该技能，而不是临场发挥。
- 工具调用失败先重试一次，仍然失败就把错误暴露出来，不要绕过去。
- 每条结论都用一句话说明支撑证据。
- 在输出里把已确认的结论和假设分开。
- 缺数据和低置信度的结论要标出来，而不是把空缺填满。
- 超过约定的 URL、行数或 API 用量上限就停下。
- 发布、重定向、删除、改代码、合并或对外发送之前，先请求批准。
其中两条比其余的更有用。把已确认结论和假设分开，能让输出可信到可以据以行动。用量上限则能防止一个配置错误的循环在一夜之间烧掉 API 预算。
它会在哪里坏掉
转化数据太薄。一个把所有 URL 分成保留、更新、合并、重定向、删除或待查的内容组合决策引擎，需要转化数据才能下判断。如果追踪没配好，它会返回一大堆零，报告在修好之前都没用。智能体做了它该做的。错的是输入。
结构判断。智能体能找出人类简报漏掉的四点，比如一个会带出完全不同类型搜索结果、因此不该放在这个页面上的关键词。但它决定不了文章该怎么组织。这个判断留在人手里，假装不是这样，产出的内容读起来就像零件拼的。
静默的解释错误。智能体在数据环节会大声失败，在解释环节会安静地失败。导出文件缺失会报错。一个自信的错误原因不会报错。这就是为什么"每条结论附证据"这条规则比看起来更重要。
你没预料到的工具缺口。有些数据根本接不进来。排名数据连接可能无法创建抓取项目、触发抓取，或导出完整的已抓取 URL 集合。要围绕连接实际能返回什么来设计工作流，否则技能会卡在中途。
在信任这个循环之前，先验证结果
前三次跑这个检查，之后每月一次。
- 随机挑两条结论，对着源数据人工验证。
- 确认所有依赖数据的说法，智能体都标注了来源和日期。
- 确认至少有一条结论被标为低置信度。对什么都自信的智能体，说明它没有在分辨。
- 确认输出结构和上一次一致。如果飘了，说明技能文件变了，或者智能体不再遵循它。
- 确认没有任何东西在审批步骤未触发的情况下被写入、发布或发送。
如果五项连续三次都通过，你就有了一个工作流。任何一项失败，去修造成它的那一层，而不是重写提示词。
常见问题
什么是智能体 SEO？智能体 SEO 是把一个定义好的 SEO 工作流交给 AI 智能体，由它自行获取数据、遵循书面方法，并在每次运行时返回结构一致的分析。决定性特征不是自主性，而是可复现性：方法存在于对话之外，所以不管你记不记得要求，同一套检查都会生效。
它和 AI 辅助 SEO 有什么区别？区别在于谁决定下一步发生什么。在 AI 辅助 SEO 里，你在每次对话中选择步骤并粘贴数据。在智能体 SEO 里，你一次性定义方法，智能体自行获取数据，遇到意外输入时遵循书面规则。工作流自动化是第三种：一致性完美，但没有适应性。
我需要编码智能体吗？不需要。当修复是代码改动，或者网站就在代码仓库里时，Codex 和 Claude Code 这类编码智能体更合适。如果你的工作主要是导出、分析和判断，基于技能的智能体不用碰终端就能覆盖。
一开始应该建几个技能？一个。挑一个产出可见的任务，把技能写到一页纸以内，只接它需要的数据源，以只读方式跑到输出可信为止。一个都没跑就建八个的团队，通常会放弃这个项目。
智能体 SEO 工作流能自己发布内容吗？能，但不应该。把发布、重定向、删除、改代码、合并和对外发消息都放在明确的审批门之后。工作流的价值在于它拼装出的证据，而不在于它被授予的权限。
运行成本是多少？取决于数据源，而不是智能体。Search Console 对自己的站点是免费的。持续成本在排名数据、SERP 数据和抓取服务上，而且它们大多有免费额度，足够在正式投入之前验证一个工作流。
作者：Aaron Wolfe（亚伦·沃尔夫），Auspia 拥有 15 年 SEO/GEO 经验的自然增长系统设计师。他撰写关于团队如何把 AI 智能体、数据和评审环节整合进能跨过季度规划周期依然有效的搜索工作流。
