SEO智能体为什么大多不靠谱？可靠技能这样搭

先把话说死：市面上九成的“SEO智能体”只是一段包装过的提示词，跑demo很漂亮，上真站就乱报、漂移、一本正经地编。真正能交付的智能体不是更长的提示词，而是一套工程——技能是一个文件夹而不是一段话，里面有工具、记忆、模板和一个独立的审查层；第一个该建的不是干活的agent而是审查它的；每个发现都要过“开发能不能照着改、放客户会上能不能站住”这种硬关。这篇拆的是怎么把SEO自动化做成出不了错的技能，不是该不该自动化，也不是流水线怎么搭CI。

保哥去年自己动手搭过一个技术审计智能体，想让它扫完站点直接吐出可交付的问题清单。第一版用的就是当时最流行的玩法：写一段很长很详尽的提示词，把检查项全塞进去。demo阶段确实唬人，跑真实客户站当场翻车——它报了一批“canonical配置错误”，开发去查，发现根本没问题，是智能体没渲染JS、拿到的是空壳就下了结论。那一刻保哥才想明白：问题不在提示词不够长，在这压根不是写提示词能解决的事。

这篇就把“怎么把一个SEO智能体做到能真给客户交付”这件事拆开。它不讲该不该上自动化，也不讲流水线层面的CI，只讲技能这一层的工程纪律——这恰恰是大多数人跳过、然后在真站上栽跟头的那一层。

为什么市面上的“SEO智能体”大多只是个提示词？

先纠正一个最贵的认知错误：把“技能”等同于“一段提示词”。提示词能让模型在对话里表现得像个SEO专家，但它没有工具去真正抓页面、没有记忆把上一次的结论带到下一次、没有模板保证每次输出格式一致、更没有一个独立的东西去审查它说的对不对。少了这四样，它在demo里像专家，在真站上像个会一本正经胡说的实习生。

这也是这篇和站内几篇相邻文章的分工，先讲清楚免得混。SEO自动化该怎么画边界那篇回答的是“哪些任务值得自动化、哪些别碰”；Claude Skills官方技能怎么用那篇拆的是现成技能的能力边界和调用；这篇都不是——这篇假设你已经决定要自建一个干特定SEO活的智能体，专讲怎么把它的内部结构搭得可靠、不乱报、能交付。一个是选题，一个是用现成的，这个是从零造一个靠得住的。

记住一句判断标准：如果你的“智能体”删掉提示词就什么都不剩，那它就只是个提示词；如果它有工具、有记忆目录、有输出模板、有一个会驳回它的审查者，它才开始算技能。下面逐层拆这四样到底怎么搭、为什么非这么搭不可。

技能是一个文件夹，不是一段提示词？

把技能当成一个有结构的文件夹，是这套工程的地基。一个能交付的SEO技能，目录大致长这样，每一层都对应一个它必须解决的失败模式：

关键不在于文件叫什么名，而在于为什么必须把这些拆成独立的、文件化的东西，而不是全堆进一段提示词。原因有三个，每个都直击大模型的固有弱点。其一，提示词里的东西是“说一次”，文件化的东西是“每次都按这个来”——把输出格式写进模板文件，比在提示词里反复强调“请保持格式一致”可靠得多，因为前者是结构约束，后者是祈求。其二，把判定标准放进参考目录，标准就和模型的临场发挥解耦了，今天和下个月跑出来的判断口径才能一致。其三，把执行历史放进记忆目录，是为了让第二次运行能站在第一次的结论上，而不是每次都从零开始、每次都犯同样的错。一段再长的提示词都给不了这三样，因为它本质是无状态的一次性输入。

指令文件和原则文件，到底该怎么写才管用？

文件夹结构里最容易被写废的，是指令文件和原则文件。多数人把它们写成又一段长提示词——“你是一个专业的SEO专家，请仔细认真地……”，这等于没写。它们要解决的是“行为可预期”和“质量有底线”，写法和提示词完全不是一回事。

指令文件的核心是把模糊意图翻译成可判定的规则。坏规则是“尽量给出有价值的建议”，好规则是“每条发现必须包含：问题定位（具体URL或模板）、量化证据（来自脚本的实测值）、修复动作（开发可直接执行的指令）、影响范围；四项缺一不输出”。前者模型怎么发挥都算合规，后者给了模型一个能自检的清单。原则文件解决的则是另一类问题——什么时候该克制。这里要写死一条最反直觉、却最值钱的纪律：没有确凿证据时，宁可漏报也不要误报。对一个要交付给客户的SEO智能体，一条错误发现砸掉的信任，远不是十条正确发现能补回来的。把“拿不准就不报，并标注为待人工确认”写成铁律，比任何“请务必准确”的祈使句都有用。

还有一个常被忽略的点：这两个文件是会演化的资产，不是一次写死。每次智能体在真站上犯了一个新错，正确的反应不是去改提示词，而是把这个错抽象成一条规则补进指令或原则文件，让它再也不犯同一类错。一个成熟的SEO技能，它的原则文件本质是一份用真实事故喂出来的踩坑清单，这也是它比任何通用提示词都难被复制的原因——别人抄得走你的结构，抄不走你用翻车换来的那几十条规则。

为什么第一个该建的不是干活的agent，而是审查它的？

这是整套方法里最反直觉、也最值钱的一条。正常人的顺序是：先把干活的智能体做出来，跑跑看，发现质量不行再加审查。这个顺序几乎注定返工——因为你没有审查者的时候，根本不知道它报的一百条里有多少是错的，你是在拿客户的真实站点当试错场。

正确的顺序是反过来的：先建审查者，再建干活的，让干活的产出永远先过审查者那一关，两边一起迭代。审查者是一个独立的智能体（或独立环节），它唯一的职责是拿着一套硬标准去驳回不合格的发现。先有它，你才有一把尺子能客观衡量干活那个到底行不行，迭代才有方向，而不是凭感觉。如果你要建的是一组智能体，那么第一个该建的永远是审查者。

保哥后来给一个美妆个护DTC客户搭内容审计技能时就先做了审查者。第一版干活的智能体扫出一批“标题缺核心词”的问题，审查者按“开发能不能照着这条直接改”这把尺子一卡，驳回了将近一半——那些条目只说了“标题不好”，没说改成什么、依据是什么。要不是审查者先在，这半批没法落地的噪音就直接进客户报告了，那才是真正砸招牌的事。审查者先行，本质是把质量问题拦在内部，而不是拦在客户会议上。

一个发现能不能发出去，拿什么卡？

审查者那把“尺子”具体是什么，是这套工程的核心资产。一个SEO发现能不能发出去，要同时过四关，缺一条就毙掉重写。这四关用SEO的场景说清楚：

• 同行专家关：假设客户那边有个在搜索引擎核心团队干活的内行，他看到这条会点头说“对，这确实是个真问题”，还是会皱眉？过不了这关，说明你报的可能是个伪问题或者过时认知，直接不发。
• 开发可复现关：一个开发不问你任何一句追问，能照着这条直接动手吗？“修一下你的canonical”过不了关；“把生产环境配置里的规范域名从http改成https，影响这一批列表页”才过关。判断标准就一句：收到这条的人需不需要回来问“具体指哪、改成啥”。
• 客户会上关：这条发现，你愿意在客户会议上当着他们技术负责人的面解释并辩护吗？如果你想到要跟一个懂技术的人解释这条会觉得心虚，那就砍掉。它衡量的是这条经不经得起追问。
• 可落地关：它具体到能直接动手了吗？不是“提升一下页面速度”，而是“首屏那个英雄视频3.4MB、占了整页七成多体积，给移动端发压缩版，文件在这”。把问题、量化依据、具体动作、可用资源一次给全，才算过。

这四关里，开发可复现关和可落地关是最容易被糊弄、也最值钱的两关。智能体天然倾向于输出听起来专业但落不了地的话——“优化你的内链结构”“改善索引覆盖”，这种话过不了这两关，因为开发拿着没法直接动手。把这两关的标准写进审查者的判定文件，逼着干活那个智能体把每条都写到“开发不用回头问”的颗粒度，输出质量会发生质变。这也是为什么审查者必须先建：没有这套硬标准在前面挡着，干活的智能体会一直产出这种正确的废话，而你浑然不觉。

谁来审查那个审查者？

审查者先行解决了“拿什么衡量干活的”，但马上引出一个新问题：审查者本身也是个会幻觉的模型，凭什么信它的驳回和放行？这个问题想不透，整套审查就是自欺。

答案是给审查分层，把能确定性判定的部分从模型手里拿走。一个发现该不该过，里面有相当一部分是机械可判的：有没有附量化证据？修复动作里有没有具体URL或路径？影响范围字段空不空？这些用脚本做硬性门禁，不合格的发现根本到不了模型那一关——这一层完全不依赖任何模型判断，是确定的。只有过了硬门禁的发现，才进入需要语义判断的那一关（这条洞察是不是真问题、表述是否经得起内行追问），这一关才用模型。顺序是确定性门禁在前、模型判断在后，能用规则判的绝不交给模型。

那剩下那层模型判断怎么保证可信？两个办法。其一，审查者同样受“证据绑定”约束：它驳回一条发现时，必须指出具体违反了哪条标准，不能只说“这条质量不高”，这逼着它的判断也可复核。其二，用前面那个答案已知的沙盒去回归审查者本身——把一批你已知“好”和“坏”的发现喂给它，看它的放行和驳回对不对。审查者不是免检的，它和干活的智能体一样要过沙盒回归。把这两层搭好，“谁审查审查者”就不再是无限递归，而是终结在确定性门禁和已知答案的沙盒上。

智能体最爱在哪些地方骗你？

搭这类技能踩过的坑，归类下来就那么几种，每一种都有对应的工程解法，不是靠“提示词里多嘱咐一句”能解决的。

这张表最该记住的规律是：凡是“事实”，都不能让模型自己产出，必须由确定性的脚本去拿；模型只负责把脚本拿到的事实解释成人能读的发现。把这条边界划死，上面一半的坑当场消失。剩下一半，靠记忆目录（解决知识不传递）、模板文件（解决格式漂移）、审查层（解决自信地错）兜住。每一条解法都对应前面那个文件夹结构里的某一层，这不是巧合——那个结构本来就是为这些失败模式设计的。

怎么逼智能体只说有据可查的话？

前面反复说“事实只能来自脚本”，但具体怎么在工程上逼它做到，值得单独拆，因为这是误报率能不能压下来的命门。光在提示词里写“请不要编造”是没用的，模型不知道自己在编。

真正有效的是三个结构性约束，叠起来用。第一个是证据绑定：规定每一条发现都必须挂上产生它的那段脚本原始输出，没有附据的发现一律视为无效、不予输出。这相当于要求它“凡下结论必须出示物证”，没物证的话根本进不了报告。第二个是隔离原始数据：让模型尽量不直接吞整页HTML去“自己看”，而是由脚本把页面解析成结构化的检测结果（标题取到了什么、canonical指向哪、状态码多少），模型只对这些已确定的字段做解释。模型没机会“想象”页面，因为它根本没拿到可供想象的原料。第三个是工具输出做格式校验：脚本返回的结果先过一道结构校验，字段不全或类型不对直接判这次抓取失败、本条不出结论，而不是让模型拿着半截脏数据硬解释。

这三条的共同逻辑是：把“别幻觉”从一个对模型的道德要求，变成一个它结构上没法违反的硬约束。模型再想编，没有挂得上的脚本物证它就出不了这条；想象不出页面，因为它只拿到了脚本嚼碎的结构化字段；想拿脏数据硬撑，校验那关先把这次结果作废了。误报率不是靠把提示词写得多严厉降下来的，是靠这种“想错都没机会”的结构降下来的。这也是为什么前面说时间该花在取数和校验工具上——它们才是误报率的真正阀门。

工具为什么要迭代五版才稳？

智能体里那些“去真正抓页面”的脚本，是最容易被低估的部分。很多人以为抓个网页是小事，结果一个抓取工具在真实站点上往往要迭代好几版才稳。一个典型的演进路径是这样的：

• 最初版直接用最朴素的命令行抓取，结果被CDN和防护当成机器人直接拦。
• 第二版换成无头浏览器去渲染，能过防护了，但一碰到大站就内存爆掉或超时崩溃。
• 第三版加了限速防崩，又发现重度依赖JS的站点抓回来还是空壳。
• 第四版上完整浏览器渲染，内容能拿全了，但同一个页面多抓几次结果不一致，没法做可信判断。
• 第五版把抓取参数和清洗规则模板化、把站点特征写进记忆，才终于稳定到能进生产。

这个过程的真正教训不是“抓取很难”，而是智能体的可靠性下限，是由它最弱的那个工具决定的，不是由提示词写得多漂亮决定的。一个会偶尔抓到空壳的工具，会让上面所有审查关都失效——因为审查者审的是发现，发现基于事实，事实来自这个工具，源头脏了后面全脏。所以搭这类技能，时间花在哪很关键：花在打磨提示词上回报递减，花在让取数工具在各种烂站况下都稳定输出上，回报最高。需要多个智能体协作、把抓取和分析编排起来时，用n8n搭SEO智能工作流那篇给了可参照的编排骨架，但编排再好也救不了一个不稳的底层工具，顺序不能反。

为什么有的技能一次就成，有的逼你重构三遍？

一批一批搭下来会发现一个规律：同样的方法，有的技能第一版就能稳定交付，有的反复推倒重来好几次才勉强可用。差别不在你那次状态好不好，而在任务本身的性质。看懂这条，能帮你排期、也能帮你别在错的任务上死磕。

这张表的实战价值有两点。其一，排期时先做上面两类，它们回报快、能快速建立你对这套方法的信心和那套规则资产；把多源和重判断的留到后面，等你的审查者和取数工具都磨利了再碰。其二，那些“逼你重构三遍”的任务，重构的往往不是提示词，而是文件夹结构——多源任务逼你认真设计记忆目录怎么存中间结论，重判断任务逼你把原则文件写厚。真正教会你这套架构的，恰恰是那几个一开始做砸的技能，顺利的那些只是验证了方法，做砸的那些才让你知道结构为什么得这么搭。所以别怕某个技能反复翻车，那是这套工程里最值钱的学费，前提是你每次翻车都把教训沉淀回规则文件而不是又去拧提示词。

没有沙盒，你根本不知道智能体在乱报什么？

这是区分“玩具”和“能交付”的硬分水岭。你怎么知道你的智能体报得准不准？在真客户站上你不知道答案，没法判断它漏报了什么、误报了什么。唯一的办法是自己造一个“答案已知”的测试站。

具体做法：搭一个故意埋好问题的站。比如一个常见CMS架构的站，埋进去几十个已知的SEO问题（标题缺失、canonical指错、死链、被noindex的重要页等等，数量和位置你自己记着）；再搭一个重度依赖JS渲染的单页应用类型的站，埋进去更多、更刁钻的问题——经验上单页应用那个站要埋的问题数量往往是常规站的三倍还多，因为渲染时序、客户端路由、懒加载这些只在JS站才有的坑会衍生出一大类常规站根本不存在的失败模式，正好用来逼出智能体在渲染一致性上的真实短板。然后让智能体去扫这两个站，拿它的报告和你埋的答案逐条对。

这把尺子能量出两个最关键的指标：漏报率（你埋的问题它没找到的比例）和误报率（它报了但其实站上没有的比例）。误报率高，说明它在制造噪音、会砸客户信任；漏报率高，说明它不可靠、不能替代人工。两个都压到可接受范围之前，这个技能不该碰任何真实客户站。沙盒还有个隐性价值：每次改动智能体后，先在沙盒上回归一遍，确认没把原来能找到的问题改丢了——这等于给智能体配了回归测试，没有它你每次迭代都是在客户站上赌。

记忆和模板，凭什么决定输出稳不稳定？

记忆目录和模板目录看着不起眼，却是“跑demo像专家、跑真站像实习生”这个落差的解药，值得单独说透。

先说模板。大模型的输出本质是概率生成，你不约束结构，它每次的小标题、字段顺序、详略程度就会飘——单看每次都还行，放在一起对比就乱，下游想拿它的输出做自动化处理几乎不可能。把输出结构固化成模板文件，让模型只负责往固定槽位里填内容、不负责设计结构，输出就从“每次手写一份”变成“每次套同一张表”，稳定性是质变。再说记忆。没有记忆的智能体每次都是失忆的新人：上次判断过这个站的某个特征、踩过某个坑，这次全忘，重新犯一遍。把执行历史和站点特征写进记忆目录，第二次运行就能站在第一次的结论上增量推进，而不是原地重启。

这一层往深了走，就和把SEO自动化当软件工程来做是同一套思想。SEO自动化为什么总烂尾那篇讲的幂等、可回放、状态显式化，落到智能体技能这一层，具体抓手就是模板（保证可重复）和记忆（保证可累积、可回放）。区别在于那篇讲的是流水线整体怎么不烂尾，这篇讲的是单个技能内部怎么搭才稳——一个是系统层，一个是组件层，组件不稳系统再好也白搭。

多个智能体怎么把知识可靠地传给下一个？

单个技能跑稳之后，真实项目里往往是好几个智能体接力：一个抓取、一个分析、一个写报告。这时最容易塌的地方是知识传递——上一个的结论到下一个手里要么丢了、要么被重新理解歪了。靠对话上下文传是最不可靠的方式，必须有协议。

可靠的做法是把传递物结构化、文件化，而不是让一个智能体“讲给”下一个听。几个要点。其一，传的是结论和证据，不是原始过程：下一个智能体需要的是“这页canonical指向了X，证据是这段脚本输出”，不是上一个智能体啰嗦的思考过程，过程越多越容易被误读。其二，结论要带时效和来源标记：哪个站、哪次运行、什么时候抓的，因为站点会变，上周的结论这周可能已经失效，没有时效标记的记忆是定时炸弹。其三，记忆要可失效、可覆盖：发现站点结构变了，旧的站点特征记忆要能被显式标记为过期，而不是和新结论混在一起让下游分不清新旧。这套和把自动化当软件工程做里强调的“可回放、状态显式”是一脉相承的，只是落到了智能体之间这个更细的接缝上。

一句话原则：智能体之间传知识，要像系统间传数据一样定协议，而不是像人之间聊天一样靠默契。靠默契的那一刻，你就又回到了demo能跑、规模一上就乱的老路。

这套和“该不该自动化”“怎么做CI”是什么关系？

把三件事的边界一次性钉清楚，你做决策时就不会用错框架。该不该把某个SEO任务交给智能体，是任务选型问题，标准是任务的结构化程度和容错空间，决定了你值不值得为它建技能。技能内部怎么搭得可靠、不乱报、能交付，是本篇讲的组件工程问题。多个技能、多次运行怎么编排成稳定可维护的流水线、怎么做监控和回放，是系统工程问题。三层的失败长得不一样：选错任务是“自动化了一件根本不该自动化的事”；技能没搭好是“该自动化的事被它干砸了”；系统没做好是“单次能跑、长期烂尾”。这篇只负责中间那层，但中间这层恰恰是最多人直接跳过、然后把锅甩给“AI不靠谱”的一层——其实不是AI不靠谱，是技能没当工程来搭。

从零搭一个可靠SEO技能，最小路径是什么？

把前面拆开的东西收成一条能照着走的最小路径：

• 先定任务边界：挑一个结构化程度高、容错空间够的具体SEO任务（如技术体检、内链建议），别一上来做大而全的全能体。
• 先建审查者：把四关标准（同行专家、开发可复现、客户会上、可落地）写成审查者的判定文件，这是你后面所有迭代的尺子。
• 搭文件夹骨架：指令、原则、脚本、参考、记忆、模板六层先立起来，哪怕每个先放最简版本。
• 死磕取数工具：把抓取/检测脚本在尽可能多的烂站况下打磨到稳定输出，这里的投入回报最高。
• 造沙盒做回归：埋好已知问题的测试站，用漏报率和误报率量化，每次改动先过沙盒回归。
• 带审查上真站：干活的产出永远先过审查者，两边一起迭代，指标盯审查通过率和“开发可直接执行”的条目占比。

这套跑顺之后，衡量它成不成的指标要定义清楚，别用感觉。至少盯四个：开发可直接执行条目占比（拿到不用追问就能动手的占总产出多少）、审查一次通过率（干活的产出第一遍就过审查的比例，太低说明它还在产噪音）、误报率（报了但站上其实没有的比例，这个直接挂钩客户信任，要卡得最严）、单次产出可落地工单数（产能，但永远排在前三个质量指标之后看）。质量指标没达标前，产能再高都是负资产，因为它产得越多、错得越多、你和客户之间要清理的信任损耗越大。

还有一笔账多数人开工时没算：运行成本和维护债。每跑一次大量调用模型是有真金白银成本的，所以一个工程上成熟的判断是——能用确定性脚本判的就别调模型，模型只用在真正需要语义判断的环节，这既降误报也降成本，方向一致。维护债则更隐蔽：站点结构会变、防护策略会变、模型会升级，你的取数工具和规则文件得跟着维护，半年不管它就会悄悄退化成又一个“以前能用”的废弃脚本。把它当一个需要持续投入的产品，而不是一次性交付的项目，这个心理预期摆正了，才不会在三个月后对着一个开始乱报的智能体骂AI不靠谱——不是AI变差了，是这套工程没人养了。

最后留一句保哥的判断：搭可靠SEO智能体这件事，难的从来不是让它“能跑出结果”，那一晚上就能搞定；难的是让它跑出来的每一条都经得起开发追问、经得起客户当面质疑。前者是写提示词，后者是做工程。把这两件事分清楚，你就不会再在demo惊艳和真站翻车之间反复横跳了。

常见问题解答

一个SEO智能体技能和一段精心写的提示词到底差在哪？

差在四样东西：能真去抓页面的工具、能跨次运行传递结论的记忆、保证输出不漂移的模板、独立驳回错误发现的审查层。删掉提示词就什么都不剩的，是提示词；有这四样的，才算技能。前者demo像专家，后者真站能交付。

为什么要先建审查者，而不是先把干活的智能体做出来？

没有审查者你就没有衡量质量的尺子，只能拿客户真站试错，迭代全凭感觉。先建审查者，干活的产出才有客观标准可卡，质量问题被拦在内部而不是客户会议上。要建一组智能体时，审查者永远是第一个。

判断一个SEO发现能不能交付，最关键的标准是什么？

开发能不能不追问就直接动手。修一下canonical不合格；把生产配置里规范域名从http改成https、影响哪批页才合格。把问题、量化依据、具体动作、可用资源一次给全，才算可交付，否则就是正确的废话。

没有真实客户站，怎么验证智能体报得准不准？

自己造答案已知的沙盒：搭测试站埋进去一批你记着位置的已知SEO问题，让智能体扫，拿报告对答案，量出漏报率和误报率。两个指标压到可接受范围前，不该碰任何真实客户站。沙盒还能当回归测试用。

智能体最容易在哪类事情上出错？

凡是需要它产出事实的地方：没工具时它会想象页面内容、瞎猜URL、调不存在的接口、跨源汇总出错。铁律是事实只能由确定性脚本去取，模型只负责把事实解释成人能读的发现，这条边界划死，一半的坑当场消失。

这套方法和把SEO自动化当软件工程做有什么区别？

是同一套思想的不同层。软件工程那套讲的是流水线整体怎么幂等、可回放、不烂尾；这篇讲的是单个技能内部怎么靠模板和记忆搭得稳。一个是系统层，一个是组件层，组件不稳系统做得再好也白搭。

抓取工具为什么值得花最多时间打磨？

因为智能体的可靠性下限由它最弱的工具决定。抓取偶尔返回空壳，后面所有审查关都失效，因为发现基于事实、事实来自抓取，源头脏全链脏。打磨提示词回报递减，打磨取数工具在烂站况下稳定输出，回报最高。

小团队没那么多资源，这套能简化吗？

能，但有两样不能省：审查者和沙盒。文件夹各层可以先放最简版本、脚本先覆盖核心检测，但没有审查者你不知道它在乱报，没有沙盒你不知道它漏报多少。这两样是可靠性的地基，省了就回到demo惊艳真站翻车的老路。