在你的产品里内置 MCP server：五个决策

给自己的编辑器加一个 MCP server，是五行配置的事，影响范围就是你自己这台机器。而把它放进别人运行的产品里则是另一种决策。你继承了这个服务器的权限、它的单次成本和它的故障模式，并且是替每一位用户承担；当它编造出一个来源时，那个假链接上署的是你产品的名字，不是模型的。

我们刚做完这件事。LightAudit Score 是一个免费开源的控制台，它对 localhost、staging 以及 VPN 后面那些 PageSpeed Insights 够不到的主机运行 Lighthouse。点开一个偏低的分数，AI 会读取真实的审计数据并给出按优先级排序的修复建议。只有在接入了研究用 MCP server 时，这些建议才会带引用——而 CrawlForge 就是被点名的那个选项。

这篇文章讲的是架构，不是推销。五个决策，每一个都会有人在你的安全评审上问到。

**LightAudit Score 即将发布。**仓库很快就会公开，公开时即为免费并采用 MIT 许可——无需注册账号、无需授权、不设用量上限。想在上线当天收到通知，到 lightauditscore.com 留下你的邮箱：只发一封邮件，内含仓库地址和快速上手指南，再无其他。

目录

• 为什么 AI 功能需要一个研究服务器
• 决策一：默认关闭，缺失时保持诚实
• 决策二：二十九个 tools 里只开放十个
• 决策三：用户的 key 绝不接触你的应用
• 决策四：锁定版本，别在启动时解析
• 决策五：点名一个服务器，兼容任何服务器
• 每次分析的成本
• 通用形态

为什么 AI 功能需要一个研究服务器

Lighthouse 给出 71 分，只告诉开发者哪里出了问题。它不会说四十项审计中该先动哪一项，更不会说为什么。这正是 AI 面板要填的空缺：读懂审计树，指出成因，把修复排出先后。

一旦这些修复建议开始引用 web.dev 或 developer.chrome.com，你面对的问题就与模型质量无关了。你要求模型给引用，它就会生成看起来合理的 URL，无论它是否真的打开过。你要求它别这么做，它大多数时候会照办——直到某一次没有照办，而那一次恰好就是客户点进去撞上 404、从此不再信任整个面板的时候。

研究服务器靠机制而不是靠指令来闭合这个环。模型只能引用它通过 tool 调用真正抓取过的来源，因为引用是由 tool 的返回结果拼装出来的，而不是来自模型对这个网页的记忆。这与通用网页数据服务器在尽职调查工作中发挥作用的可追溯性是同一种属性：价值不在数据本身，而在从结论回溯到页面的那条可审计路径。

决策一：默认关闭，缺失时保持诚实

研究服务器是设置里的一个开关，而且初始状态是关闭的。

关闭时，分析仅依据审计数据得出，结果会带上一个朴素的未进行网页研究标记。每一次分析还会标注产出它的提供方和模型。没有任何东西会悄悄降级，也不会为了填上本该是引用的位置而编造来源。

这是大多数团队做反了的决策。直觉是把集成设为必需，好让功能永远呈现最佳状态；后果却是你这个功能的可信度从此取决于第三方是否可达。应该让它可见地降级。看到未进行网页研究的用户,清楚知道自己在读什么。而看到一条后来被发现是编造的引用的用户,学到的关于你产品的东西要糟糕得多。

决策二：二十九个 tools 里只开放十个

CrawlForge 暴露二十九个 tools。LightAudit 的分析路径拿到其中十个：搜索、抓取、提取、摘要。站点爬虫、批量任务、浏览器自动化和深度研究一律直接拒绝。

原因是单次成本，不是疑神疑鬼。一次引用检索需要找到一个页面并读它。它不需要爬遍一个域名，而这个差别会体现在用户的账单上：

deep_research 是最有启发的一个。就研究性问题而言，它是整个目录里最好的 tool，而它被拒绝了。一个在每个低分上都伸手去拿它的模型，会把 11 credits 的分析变成 10 credits 起步再加上扇出的分析，而点击分数环的那个人并没有要求做一个研究项目。你的 agent 最爱用的那个 tool，未必是你的产品该开放给它的 tool。

如果这篇文章你只带走一点：把你开放的 tools 逐个列出来。一个 MCP server 的目录代表的是它作者心目中的"有用"，而与你这个功能的职责的交集，通常只有其中三分之一。

决策三：用户的 key 绝不接触你的应用

LightAudit 不向研究服务器转发任何东西。CrawlForge 用它自己的配置进行认证，那份配置由它自己的安装向导写入，因此用户的 API key 从不经过这个受益于它的应用。

这句话在安全评审里的分量，胜过任何篇幅的静态加密说辞，因为它是把问题消除掉而不是回答掉。你不是第三方凭据的保管人。你的数据库里没有会泄露的 key，日志里没有要脱敏的 key，支持包里没有 key，也不必为一个你无法控制的供应商写事件响应段落。

一般化的说法是：当一个集成能够自行完成带外认证时，就让它自己来。你的产品代用户保管的每一份凭据，都是你为了省掉他们一步配置而给自己揽下的风险。

决策四：锁定版本，别在启动时解析

几乎所有你会从 README 里复制的 MCP 配置都长这样：

{
  "mcpServers": {
    "crawlforge": {
      "command": "npx",
      "args": ["-y", "crawlforge-mcp-server"],
      "env": {
        "CRAWLFORGE_API_KEY": "cf_live_YOUR_API_KEY_HERE"
      }
    }
  }
}

这对你自己的机器是正确配置，对要交付的产品则是错误配置。-y 会跳过安装确认，而一个不带版本号的包名会解析成启动那一刻的最新版本——这意味着你的客户明天运行的代码，是你团队里没有任何人读过的代码。这是一个伪装成便利参数的供应链决策。

把它锁定：

{
  "mcpServers": {
    "crawlforge": {
      "command": "npx",
      "args": ["-y", "crawlforge-mcp-server@5.6.6"]
    }
  }
}

然后把版本升级挪进你常规的依赖评审流程，让人先读过 changelog，你的用户才会拿到新行为。这个做法的代价是每几周多一个 pull request。另一种做法的代价是一次你无法复现的线上事故，因为造成它的那个版本已经不是 latest 现在解析到的东西了。

决策五：点名一个服务器，兼容任何服务器

LightAudit 在文档里点名 CrawlForge，同时不捆绑分发任何东西。任何在标准 .mcp.json 中声明的研究服务器，都会被改为驱动。

这不是利他，而是你如何熬过一场采购谈判。一个买方无法替换的 MCP 依赖，在你将来参加的每一场企业评审里都是一道供应商锁定的问答题。因为 MCP 是协议而不是 SDK，遵守标准配置文件几乎不花你什么成本，却能把"你们被绑在哪家供应商上"变成"你们更喜欢哪家就用哪家"。

它同时也让你保持诚实。一个被点名却可以被替换的默认选项，必须靠实力持续保持是最优选择。

每次分析的成本

一次分析就是一次搜索加几次读取：

分析结果与运行记录一同存储，因此重新打开报告不产生任何费用——第二个读同一份报告的开发者花费零 credits。新的 CrawlForge 账号有 1,000 免费 credits，无需绑卡，大约相当于九十次带引用的分析，足够在任何人做出采购决定之前用完。按 tool 计价见价格页。

这个数字要在接入服务器之前算清楚，而不是之后。你的功能开放了哪些 tools、以及它调用了多少次，是你客户账单上的两个变量，而第一个在设计阶段就已经定死了。

通用形态

去掉 Lighthouse 相关的细节，同样这四个问题适用于你放进交付产品中的任何 MCP server：

1. **影响范围有多大？**逐个列出开放的 tools，其余按名字拒绝。
2. **凭据由谁持有？**如果服务器能自行认证，就别替它保管。
3. **单次成本是多少？**按用户的每一次操作算，不要按月算。
4. **它不在时会怎样？**要可见地降级。缺失的功能还能补救；编造出来的功能补救不了。

这些都不是什么高深内容。它和你对热路径上任何第三方调用会采取的纪律是同一套——只不过在 MCP server 上往往被跳过，因为配置只有五行，感觉像改了个设置，而不像引入了一个依赖。

**LightAudit Score 即将发布。**它免费、采用 MIT 许可、完全在你自己的机器上运行，仓库很快就会公开。如果你想看到这套模式实际跑起来而不只是被描述出来，官网上有完整的功能说明和一份抢先体验名单，会在上线当天把链接发给你——而它点名的那个研究服务器，正是你刚刚读到的这一个。