Scrunch AI：给智能体单独渲染页面的激进路线

Scrunch AI 是厂商工具里产品路线最激进的一家：别人做监测，它在监测之外直接改造网站本身。招牌产品 Agent Pages 的机制是在边缘节点识别 AI 爬虫与智能体的访问，给它们返回一版结构化、去装饰、便于机器解析的站点内容，而人类访客看到的页面保持原样。它的整体产品是「AI 搜索 + 智能体」的全套体验管理，2025 年 7 月完成 1500 万美元 A 轮。这条路线把一个老问题重新摆上台面：给机器看的内容和给人看的内容分家，边界在哪里。

先把它的位置放进行业坐标系。这个赛道的多数厂商把「AI 可见度」当成报表生意——采集回答、算出份额、画出曲线，优化动作留给你自己。Scrunch 的赌注是报表生意不够深，真正的瓶颈在站点对机器的开放程度：爬虫读不懂你的页面，报表再漂亮也改变不了被跳过的命运。A 轮融资公告里的叙事也围绕这个判断——「为 AI 消费重建互联网」。这个判断是否成立决定它的天花板，但对选型者来说，判断对错不重要，重要的是它代表了一个真实的产品方向：从「测」走向「修」，而且敢把修的部分产品化收钱。

Agent Pages：解决什么问题，又制造什么问题

Agent Pages 的出发点是真实痛点。现代营销站点大量依赖客户端 JS 渲染，而相当一部分 AI 爬虫不执行 JS——页面在爬虫眼里接近空白，这也是独立测试反复证实过的现象，测试细节见searchviu JS 渲染测试文献卡。Scrunch 的方案是不改人类站点，单独给机器一份干净的可读版本，等于替站点把「机器可读性」外包出去。对 JS 依赖重的站点，这个方案确实击中要害。

但它同时踩进了一片灰色地带。搜索引擎时代，「给爬虫看的内容与给用户看的不同」有个名字叫 cloaking，长期属于灰产手段；AI 时代「为机器提供可读版本」又有正当的一面——llms.txt 协议的精神就是自愿给模型一份说明书。两者的界线本站认为不在「内容是否分版本」，而在「分出去的版本是否同源同真」：从同一事实源生成、内容一致、只是形态不同的机器版，是可读性工程；塞进人类页面没有的承诺、参数与评价的机器版，就是操纵。这条界线两侧的机制辨析见cloaking 术语卡与llms.txt 术语卡。

还有一个工程事实常被忽略：Agent Pages 的前提是放行 AI 爬虫。站点若在 robots 与 WAF 层把主流 AI 爬虫挡了，边缘渲染做得再好也没有观众——先理清自家爬虫策略，见AI 爬虫术语卡。

顺带一提它对「智能体」的押注。Agent Pages 的目标读者不只是爬虫，还有会代用户执行任务的智能体——比价、下单、填表这类场景里，智能体读站点的方式比搜索引擎更挑剔：它要的是结构清晰、步骤可执行的信息，不是关键词密度。如果智能体浏览成为主流购物路径，站点给智能体的体验会像今天的移动端适配一样变成标配。这是 Scrunch 叙事里最有想象力的部分，也是离当前证据最远的部分——把它当远期变量观察，别当近期采购理由。

那个 +364%：未证实案例的正确读法

Scrunch 传播最广的案例是「客户 Akamai 的品牌呈现提升 +364%」。这个数字必须原样标注性质：服务商单方口径，未获公开证实——没有独立第三方复测，案例方法细节也未完整公开，本站把它记为存疑待证，口径档案见Scrunch Akamai 案例数据卡。

不是这个案例有假，而是这类数字天然不可比。「品牌呈现提升」的分子分母都由厂商定义：统计了哪些引擎、多少问句、基线取自哪个月、提升按什么口径算，每一项都有操作空间。读厂商案例的正确姿势是三问：基线是什么时候、什么口径？统计范围有没有择优？同一周期其他客户的分布如何？三问问不出答案，就把它当方向参考——「做了站点改造后可见度上升」的方向合理——而不当效果承诺。任何「做了 X 就涨 N%」的厂商数字都按这个纪律读，与监测报表的口径验收是同一套要求。

把这条纪律用到采购场景更具体：如果 Scrunch 的销售把 +364% 摆在提案第一页，你的正确动作不是反驳这个数字，而是要求一份「你们口径下的我们」——用你们的问句集、你们的基线定义，先测我们站点现在的呈现水平，合同效果条款以这轮实测为基线来写。厂商案例的作用从「证明它有效」变成「定义测什么」，数字的营销属性就伤不到你。

监测加改造的一体化定位与适配边界

Scrunch 的产品栈是监测、审计、内容优化、内容交付四层合体：监测层告诉你 AI 怎么呈现你，审计层检查站点对智能体的可消费性，交付层的 Agent Pages 动手改造。这个组合拳对应的买家画像很清楚：站点技术债重（重 JS 框架、动态渲染）、有工程团队配合、把 AI 可见度当基础设施项目而非营销报表来做的中大型企业。询价制与实施复杂度也印证了这一定位。

反向的画像同样清楚。只想低成本看趋势的团队，监测只是它的配角，为配角买整台戏不划算；对内容分版本有合规顾虑、法务过不了关的团队，核心卖点会卡在内部流程上；中文场景为主的团队则要注意它的覆盖以英语系引擎为主，中文平台要另配方案，选项对比见选型指南。

如果你被它的路线吸引但不想一步到位，有个低风险的中间态：先在自家 CDN 上做一版静态化的机器可读层（语义 HTML、结构化数据、完整的服务端渲染回退），用日志观察 AI 爬虫的抓取变化，效果数据自己留底——这套动作不需要采购任何产品，却能验证「机器可读性改造对我的站点有没有用」这个前提。前提成立，再考虑是否采购商业化方案；不成立，省下的预算就是利润。

最后给这条卡收个口：Scrunch 值得进观察名单的理由，不是它的监测面板，而是它把「AI 时代的站点体验」这个议题推成了产品品类。无论它自己走多远，「机器可读性」与「智能体可操作性」都会成为站点工程的标准科目——就像当年的移动端适配。选型者的收益是提前看到方向，至于是否为方向本身付费，按上面的中间态路线先自证再决定。