Aperture：把 Profound 式监测装进内网服务器的开源答案

Aperture 是 GitHub 上的开源 AI 可见度监测工具（anyin-ai/aperture），MIT 协议，README 自我定位写得很直白：Profound 和 Peec AI 的免费替代。它给出的路线是把「提问、采回答、看品牌被不被提」这条最小监测闭环搬进你自己的服务器——BYOK（Bring Your Own Key，自带密钥）接你已有的模型 API 账号，数据全部落在本地 SQLite。本卡讲清它当前的真实能力面、部署与安全前提、以及 API 路线自带的口径边界，回答一个具体问题：什么团队该从它起步。

仓库事实：它现在能做什么

按仓库 README 的口径，Aperture 已落地的功能是一条基础监测线：追踪模型是否推荐你的品牌、对比竞品被引用的情况、跨模型跨语言跨市场做可见度审计、随时间追踪变化。引擎侧目前支持 OpenAI 系列模型与 Perplexity 的 sonar、sonar-pro；Anthropic、Gemini 的支持与 Google AI Overviews 追踪在路线图上，尚未落地。此外它支持任意 OpenAI 兼容端点，官方点名的例子是 Ollama 与 vLLM 这类自托管推理服务。

两个使用前的预期管理。一是项目体量：仓库星数还在两位数早期阶段，提交次数不多，社区小意味着遇到问题基本靠自己读代码，迭代节奏取决于维护者。二是功能完成度：情感分析还在计划清单里，现在跑出来的结果以提及与引用为主，别按成品商业工具的功能清单去要求它。把它当成一个能跑的起点，而不是一个能替代工作台的产品，预期就对了。

它的审计维度值得展开一句。跨模型、跨语言、跨市场这三个轴放在一起，含义是同一份提问集可以分别在不用模型、不用语言、不同区域设置下各跑一轮，看品牌表现的差异面。对出海团队，这恰好是「同一个产品在德语市场和英语市场被 AI 怎么谈论」这类问题的低成本试验田。当然，维度是工具给的，解读要自己来：表现差异是内容供给造成的，还是语言覆盖造成的，工具不会替你归因。

BYOK 架构：钱付给模型厂商，活儿留给自己

BYOK 的意思是模型调用费直接发生在你自己的 API 账号下，工具本身不收钱。这个结构的账要算两笔：显性的一笔是 API 账单，随监测频次、提问数量、引擎数量线性增长，跑得越勤花得越多；隐性的一笔是口径成本——API 路线测到的是模型接口的返回，不是普通用户在消费端界面看到的答案，两个入口的回答并不等价，取舍分析见API 监测与网页端监测对比卡。用 Aperture 得到的数字，属于 API 口径的数字。

兼容端点是它架构上最灵活的一处：任何提供 OpenAI 兼容接口的模型服务理论上都能挂进来测。国内外多数模型厂商都提供这类兼容接口，所以「接一个国产模型测一测」在工程上是通的。但要把话说满：挂兼容端点测到的仍是「这个模型 API 的回答」，而中国几个消费级平台的网页端回答带着自家的检索供给与产品生态，是另一套口径——开源 API 线补不上这个空档，这块缺口谁来找补，见后文与秀虎GEO 的路线对比。

成本这笔记账还有个实务提醒：BYOK 模式下账单随提问量与采样频次自然生长，跑满一轮全量提问集之前，先用小样本试跑一周，估出单轮成本再定采集节奏。否则月底看到 API 账单才发现监测比想象中贵，预算逻辑就从「几乎免费」悄悄变成了「另一笔订阅费」。

部署十分钟，安全边界自己扛

部署形态对工程团队友好：仓库带前后端目录与 docker-compose 文件，配着部署文档走，一套内网服务很快能起来；数据库用 SQLite 单文件，备份就是拷文件。低成本是有代价的，README 的安全说明写得不含糊：API 密钥以明文存在本地 SQLite 里；项目当前不带鉴权，官方建议只跑在 localhost 或内网环境，若要对外访问就放到带认证的反向代理后面，不要裸暴露公网。

这两条不是缺陷清单，是使用前提。我们的口径是：把「密钥怎么管、谁能访问、部署在哪」写进你自己的使用手册，再决定上不上。内网工具做内网的事，边界清晰就是好工具；越界使用，风险全在部署者身上。这也是所有开源自建路线的共性——工具免费，责任自负，成本结构可参考自建监测成本数据卡里按采样规模推算的口径。

工具免费，功课不免费

开源监测省掉的是软件费用，省不掉的是三件功课。第一件是提问集设计：工具不会替你造问题，品牌词、品类词、买家问题词怎么配比，真实用户的问法从搜索后台和客服记录里怎么反推，都是使用方的功课；提问集合得不合理，采回来的曲线再漂亮也没有判读价值。第二件是采样纪律：单次回答的随机性不小，同题要不要多采样、每天什么时段跑、引擎静默升级后要不要重跑基线，这些商业工具替你默认掉的决定，在开源线上都得自己定规矩并坚持执行。

第三件是口径记录。三个月后回看趋势，你必须还记得当时挂的是哪个模型版本、用的什么参数、每天几点采集——否则曲线上的波动分不清是市场变了还是你的配置变了。我们的建议是把口径当成代码的一部分来管：配置写在仓库里，改动留痕，让每一个数字都能复盘到产生它的那套条件。口径说不清的监测数字没有价值，这句提醒对自建路线尤其重。

谁适合从 Aperture 起步，谁不必

三类团队适合：有工程人手、在意数据主权、想先跑通「提问集到趋势曲线」最小闭环的团队；预算敏感但愿意付 API 费的技术型个人；想把监测数据接进自己内部系统的团队——本地数据库加导出能力，让数据整合的自由度高于多数托管产品。开源自建这条线在品类里的位置，见GEO 工具品类地图。

三类团队不必从这里起步：要现成提问集库、竞品基准、多席位协作与成品的报表，这些正是商业工具的溢价所在，买断 vs 自建的权衡见自建还是采购决策卡；没有工程人手、出问题没人读代码的团队；中国引擎覆盖是刚需的团队——Aperture 不覆盖国内平台网页端，这一段要靠 UI 路线的工具来补。同样的零服务器诉求但更轻量的路线，还可以看llm-visibility-tracker 卡，用 GitHub Actions 把部署成本也省掉。