码农早餐 · 2026-10-26

Claude Code 的 SEO 插件装了 26 个子技能和 19 个子代理

GitHub 上出现一个叫 claude-seo 的开源项目，作者是 AgriciDaniel，MIT 许可，定位是给 Claude Code 用的 SEO 插件。按 README 的说法，它由 26 个子技能和 19 个 specialist agent 组成，最多 17 个 agent 同时跑一个站点，输入一个网址，10 到 15 分钟出一份完整 SEO 审计，再给一份按优先级排序的行动清单。覆盖范围包括技术 SEO（抓取、索引、sitemap、robots.txt、重定向、Core Web Vitals）、E-E-A-T 内容质量、Schema.org 结构化数据、面向 AI 搜索的 GEO、外链、本地与电商 SEO、Google API，以及 PDF/Excel 报告。另有 9 个可选扩展用来接实时 SEO 数据。项目当前在 Trendshift 上标着 GitHub Trending 第 12 名。

README 里有两组数字需要分开看。第一组是项目自己给的成绩：官方站点 claude-seo.md 从上线第一天起就用这套工具审计，前 12 周拿到 10.8K 次 Search Console 点击、324K 次展示，移动端 PageSpeed 99 分。这是单个站点、单一来源、由项目自己公布的数据，没有对照组，也没有说明这 12 周里除审计之外还改了什么。第二组是首屏那句「三个 bot 从 #48 爬到 #1」——原文只出现在 hero 图里，没有对应的站点、关键词、时间区间和排名截图，正文的 Real results 一节也没有复述这个说法。标题式的排名承诺和可核验的数据之间，对不上。

项目结构上有一处可以对照。19 个 agent 的表格里列了角色、模型和命令，模型一栏只有 Sonnet 和 Opus 两种，几个偏判断的岗位（内容编辑、AI 搜索分析、主题策略、搜索体验设计）标的是 Opus，其余多是 Sonnet。也就是说这套东西的成本不是固定的，一次全站审计会按 agent 数量乘以模型单价走。本站 10 月 7 日写过 SemiAnalysis 的测算，同价位订阅折算出的 API 等价价值随「计划 + 模型 + 工作负载」三者变化，credit 消耗比例和 API 价格比例并不一致。把 17 个 agent 并行塞进一次审计，正好落在那个会大幅波动的区间里，README 没有给单次审计的 token 消耗估算。

这类「给 Claude Code 装一套领域技能」的做法最近不少见。本站 10 月 20 日写过 Claude Code 的多会话编排：--worktree --tmux 能一条命令起 worktree 加 tmux session，但它不管多 agent 同屏、不管判断哪个 agent 卡住了，那部分还得自己用 send-keys 和 capture-pane 写。claude-seo 走的是另一条路——把编排封在插件内部，对外只暴露 /seo 一类子命令，用户看不到 17 个 agent 之间怎么调度、失败怎么重试。10 月 17 日那篇写 Anthropic 自己审 Claude Code 的流程时提到，他们的每个 finding 在给人看之前要先由一组 agent 交叉投票验证，够票数才发出来，风格类 finding 直接丢掉。审计工具给出的建议要不要经过类似的过滤，决定了输出是清单还是噪音，README 里没写这一层。

README 的 badge 显示 1077 个测试通过，CI 状态正常，说明工程侧有基本维护。但「Real results」只有一个自建站点，9 个实时数据扩展的接入方式、是否需要各自的 API key 和额度，正文没有展开。这个项目目前在 Trending 上，实际审计质量和上面那两组数字的差距，要等第三方站点跑过之后才有材料判断。

来源：

• github_trending · AgriciDaniel

---

本文从过去 24h 的 X / Hacker News / GitHub Trending 共 49 条信息中选出这一件事展开。内容由 LLM 辅助生成并经事实校对，来龙去脉部分参考了本站往期内容，文末附原始来源链接，重要决策请交叉验证。