我的应用程序对人工智能代理不可见——以下是我采取的应对措施

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

我是一名独立应用开发者和氛围编码者。我已经发布了三十多款小型企业应用——包括发票管理、库存管理、装箱单生成和税务追踪。而现在， apparently 还成了一个用于人工智能代理的开放标准。

连我自己都对最后这一点感到惊讶。

我一直遇到的问题在于：即使是最优秀的人工智能代理，在查看网页应用时也会产生幻觉。它们会猜测点击位置，调用错误的工具，并且自信满满地静默失败。我有三十款实际应用存在，但代理们就是无法识别它们。

因此，我构建了蓝图协议。这是一种位于应用根目录下的 blueprint.txt 文件，它能精确告知代理该应用具备哪些功能、应调用哪些工具、哪些操作仅限人类执行，以及如何逐步完成每个流程。无需模型上下文协议（MCP）支持。它适用于任何试图导航任何网页应用的代理。

随后，我进行了一项基准测试，发现它还能将模型上下文协议（MCP）的发现开销降低百分之七十八。

它对模型上下文协议（MCP）的具体作用
模型上下文协议（MCP）包含两个调用。tools/list 返回服务器暴露的所有工具。tools/call 则按名称调用特定工具。

在没有蓝图的情况下，代理会先调用 tools/list，阅读所有 N 个工具定义，选择一个，然后再调用它。

有了蓝图，代理已经知晓工具名称和确切参数。它会直接调用 tools/call。根本不会发生 tools/list 调用。

这不仅仅是更廉价的发现过程。这是彻底消除了一次完整的往返通信。

基准测试
我在四种模型——Claude、GPT-4o、Gemini 和 Grok——上进行了受控测试，涉及五个候选模型上下文协议（MCP）服务器，其中只有一个正确匹配。代理被要求高效地找到最佳服务器。测试框架指令中未提及任何蓝图相关内容。发现过程是完全自然发生的。

模型 无蓝图 有蓝图 降低幅度
Claude 58 分 13 分 ~78%
GPT-4o 58 分 28 分 ~54%
Gemini 23 分 9 分 ~61%
Grok 58 分 58 分 0%
开销评分依据加权资源检查成本计算——llms.txt 计为 10 分，blueprint.txt 计为 1 分，以反映典型的现实世界文档大小。

Grok 的 0% 是一个诚实的结果。并非所有模型目前都能遵循发现信号。这在预期之内——robots.txt 和 llms.txt 在最初推出时也未能在所有地方生效。

v3.0.0 —— 代理优先结构
该规范刚刚更新至 v3.0.0 版本。有两项变更对模型上下文协议（MCP）至关重要：

第一行带有 [MCP] 标记——代理可即时确认服务器可用性
格式 B 能力索引——根文件约为 150 个令牌，代理仅获取其所需的那一个能力文件（约 350 个令牌）。总计：约 500 个令牌，而相比之下 tools/list 可能产生数千个令牌
立即尝试
规范：https://github.com/Explorer-64/blueprint-protocol

在线参考实现：https://imagcon.app/blueprint.txt

基准测试结果：https://stackapps.app/mcp-blueprint-results

开放标准。采用麻省理工学院许可证授权。无需额外工具。无论是否使用模型上下文协议（MCP）均可工作。如果您拥有一个网页应用或一个模型上下文协议（MCP）服务器，创建一份蓝图大约只需十分钟。