1. 项目概述当AI智能体需要“信任”一双眼睛想象一下你的AI助手无论是帮你处理日程的Claude还是自动编写代码的GPT Engineer它们突然需要完成一个支付操作。按照既定的工作流它会自动在互联网上搜索可用的“支付处理器”工具找到一个所谓的MCP服务器建立连接然后开始传输交易数据。整个过程行云流水完全自动化。但这里有一个致命的问题被忽略了这个服务器是谁搭建的它提供的代码是否经过作者签名认证有没有其他用户报告过它是恶意的面对这些问题你的AI助手一无所知而作为使用者的你同样被蒙在鼓里。这就是当前AI智能体工具生态中一个巨大且未被充分认知的信任缺口。我们正在将越来越多的决策权和执行权交给AI却让它们在完全“盲选”的状态下接入外部工具和服务。这无异于让一个孩子独自走进一个巨大的、没有监管的玩具市场并允许他随意使用任何看起来有趣的工具。我最近深入调研了整个MCP生态索引了超过1900个来自各大主流注册中心的数据源。结果令人震惊99.4%的MCP服务器是“未签名”的。这意味着它们没有加密身份没有可验证的作者你根本无法从技术上区分一个合法的工具和一个精心伪装的供应链攻击载体。这就是2026年AI智能体工具发现的现状——繁荣背后危机四伏。因此我和团队构建了AgenticSearch。它不是一个工具注册中心也不是一个应用市场。你可以把它理解为一个覆盖在所有现有注册中心之上的“信任层”。它的核心使命很简单为AI智能体提供一个搜索引擎让它们能在接入一个工具之前先看清它的“信任身份证”。搜索结果不再按流行度或SEO排名而是按加密信任等级来排序和预警。2. MCP生态的信任危机我们为何需要AgenticSearch2.1 MCP协议智能体的“手”与“脚”也是最大的风险入口要理解AgenticSearch的价值首先得明白MCP是什么。Model Context Protocol你可以把它看作AI智能体如Claude、GPTs与外部世界交互的“标准插座”。通过MCP智能体可以调用日历API、执行代码、查询数据库、处理支付——几乎任何你能想到的操作。它赋予了AI“手”和“脚”使其从单纯的聊天对话进化为能真正完成任务的数字员工。然而能力越大风险越高。这个“插座”标准是开放的任何人都可以构建一个MCP服务器即一个工具并发布出去。问题在于当前的协议规范主要关注功能互联“它能做什么”而在身份认证和来源可信度“它是谁做的是否可信”方面几乎是空白。这就导致了一个混乱的“西部淘金”景象注册中心林立像mcp-registry、awesome-mcp等项目列出了成百上千个工具。市场推广火热许多平台在推广“最实用的MCP工具包”。信任完全缺失没有一个地方能系统性地回答“我的智能体应该信任这个工具吗”2.2 99.4%未签名一个触目惊心的数据我们的索引扫描覆盖了所有主要的公共注册中心和仓库。当我说99.4%未签名时指的是这些工具缺乏最基本的加密签名。这就像你下载一个软件但它的安装包没有数字签名你无法确认它是否来自声称的开发者也无法确认它在传输过程中是否被篡改。在传统软件开发中代码签名和软件物料清单SBOM已是安全基线。但在新兴的AI智能体生态中这块几乎是荒漠。你的AI助手可能会从某个GitHub仓库自动加载一个“财务分析”MCP服务器。该服务器要求提供数据库凭证以“获取数据”。智能体毫无戒备地交出凭证。结果这个服务器可能是一个窃取凭证的后门。这就是典型的“工具投毒”攻击已被OWASP列为MCP十大安全风险之首。没有信任层每一次智能体的工具调用都是一次潜在的供应链攻击。2.3 AgenticSearch的设计哲学不做替代只做增强我们意识到重建一个全新的、带审核的注册中心是费力不讨好的也会分裂生态。因此AgenticSearch选择了另一条路成为现有生态的“增强现实”眼镜。它不托管任何工具所有工具数据仍来自原始的注册中心如GitHub、NPM、特定Registry网站。它不修改任何协议完全遵循标准的MCP协议与智能体通信。它只做一件事为每一个被索引的工具计算并附加一个基于加密验证的信任分数并在智能体试图连接时提供清晰的警告信息。这种设计让集成变得极其简单无需改变开发者分发工具或用户使用工具的现有习惯只是在中间增加了一个至关重要的“安全检查站”。3. 五级信任模型如何量化工具的“可信度”AgenticSearch的核心是其信任评分系统。我们摒弃了主观的“星级评价”建立了一个客观的、基于加密证据的五级信任模型。这个模型从L0到L4逐级要求更严格的身份证明。3.1 各级别详解与技术要求信任等级名称含义技术实现与证据要求L0未知无任何身份标识。风险极高应极度谨慎。默认状态。工具仅被索引无任何签名或作者注册信息。L1已声明作者已注册身份但未进行加密所有权证明。作者在AgenticSearch提交了名称、联系方式等基本信息但未完成挑战验证。可作为初步过滤。L2已签名核心里程碑。通过ECDSA P-256密钥对验证作者可证明控制该源码。作者在本地生成密钥对对工具仓库的特定内容如README或版本Tag进行签名并完成公开挑战验证。私钥永不离开本地。L3已验证确认了域名或组织身份可信度更高。工具服务于特定域名且作者能通过DNS记录如TXT记录证明对该域名的控制权或通过GitHub组织、公司邮箱等验证组织身份。L4已审计最高级别。已完成第三方安全审计并有公开记录。提供由知名安全审计机构如Trail of Bits, Kudelski Security出具的审计报告链接且审计范围覆盖该MCP服务器的核心代码。3.2 为什么选择ECDSA P-256签名作为L2核心我们将L2已签名定为生态应该追求的第一个实质性安全基线。选择ECDSA P-256算法基于几个务实考量广泛支持与标准化它是NIST标准被TLS协议广泛使用几乎所有编程语言和操作系统都有成熟、高效的库支持。安全性与性能平衡在目前的技术背景下它提供了足够的安全强度128位安全性同时签名和验证速度很快对开发者体验和系统性能影响小。与现有工作流契合签名过程可以很容易地集成到开发者的CI/CD流水线中。例如在GitHub Actions中可以在发布新版本时自动对发布包进行签名。实操心得理解“证明所有权”的关键这里最大的误区是签名不是签“作者的名字”而是证明“这个公钥的控制者同时控制着这个源代码仓库”。验证流程通常是系统给出一个随机数挑战开发者用私钥签名后返回系统用公钥验证。同时这个公钥必须被以某种不可篡改的方式如放在仓库的特定文件里与源码绑定。这样任何能访问该仓库并修改代码的人才能生成有效的签名。这有效防止了“冒名顶替”。3.3 当前生态的信任分布与我们的目标根据我们的索引超过99%的工具停留在L0。这意味着整个生态几乎在“裸奔”。AgenticSearch的目标就是通过提供简单的工具和清晰的收益推动尽可能多的工具开发者至少达到L2级别。即使只有20%的工具完成签名也能让智能体在大多数常见任务中优先选择可信来源大幅降低风险。4. 实战集成让Claude Desktop拥有“安全检查”能力理论说得再多不如实际用起来。AgenticSearch本身就是一个MCP服务器这意味着你可以像添加任何其他工具一样把它添加到你的AI智能体环境中。下面以最流行的Claude Desktop为例展示如何让你的Claude瞬间获得工具信任查询能力。4.1 一步到位的配置Claude Desktop通过一个JSON配置文件来管理其可用的MCP服务器。你只需要编辑这个文件即可。找到配置文件macOS/Linux:~/.config/Claude/claude_desktop_config.jsonWindows:%APPDATA%\Claude\claude_desktop_config.json如果文件或目录不存在直接创建即可。编辑配置文件 将以下配置块添加到文件的mcpServers部分。如果mcpServers不存在就创建它。{ mcpServers: { agentsearch: { command: npx, args: [ -y, proofxhq/agentsearch, serve ] } // ... 你可以在这里继续添加其他MCP服务器 } }重启Claude Desktop保存配置文件后完全退出并重新启动Claude Desktop应用。4.2 集成后的三大工具详解重启后你的Claude就拥有了三个新的工具函数。你可以在对话中直接要求Claude使用它们。4.2.1agentsearch_find信任优先的工具搜索这是最常用的工具。当你的Claude需要完成某项任务时你可以先让它搜索相关工具并根据信任等级做选择。使用场景你“Claude我需要处理一下用户的订阅支付帮我找个可靠的支付工具。”Claude调用agentsearch_find“我找到了几个支付处理工具。根据信任评分排序最推荐的是‘stripe-mcps’它已获得L2签名认证无安全警告。另外还有一个未签名的通用支付网关系统提示其作者未经核实存在风险。建议我们使用第一个。”背后的技术交互 Claude会向本地的AgenticSearch服务器发送一个搜索请求。AgenticSearch服务器会在其索引中查询根据工具描述、能力标签等匹配“payment processing”然后返回一个按信任等级L4 L3 L2 L1 L0排序的结果列表。每个结果都包含了关键信息信任等级、是否签名、能力描述以及任何安全警告。4.2.2agentsearch_check连接前的最终安全复核在决定使用某个特定工具尤其是来自陌生来源前进行最终检查是至关重要的安全习惯。使用场景你在一个论坛上看到一个有趣的“数据可视化”MCP服务器GitHub链接是github.com/xxx/chart-mcp。你想让Claude使用它。你可以指示Claude“在使用这个github.com/xxx/chart-mcp工具之前请先用AgenticSearch检查一下它的信任状态。”Claude调用agentsearch_check“已检查。该工具源ID‘xxx/chart-mcp’当前处于L0状态未签名系统警告‘无加密身份标识’。这意味着无法验证作者身份存在供应链攻击风险。你是否确认要继续使用”实操心得将检查流程化我强烈建议在你的智能体工作流中建立一个固定规则对于任何首次使用的、或来自非官方推荐列表的MCP工具必须在连接前执行一次agentsearch_check。这就像在运行一个陌生.exe文件前先用杀毒软件扫一遍。你可以通过提示词工程将这个规则固化到Claude的“系统指令”或智能体的核心行为准则中。4.2.3agentsearch_stats洞察生态健康度这个工具让你或你的智能体对整体工具生态的安全状况有一个宏观了解。使用场景你作为团队负责人想评估一下为团队智能体引入外部工具的整体风险。你可以让Claude查询统计数据。Claude调用agentsearch_stats“当前AgenticSearch索引共包含1927个工具源。其中已签名L2及以上的工具有12个占比0.6%未签名L0的工具有1915个占比99.4%。生态整体信任基础非常薄弱。”这个数据能有力地说明为什么需要这样一个信任层并帮助你在内部制定安全策略比如“原则上只允许使用L2及以上等级的工具”。5. 开发者指南如何将你的MCP服务器从L0提升到L2如果你是MCP工具的开发者将自己的工具提升到L2已签名是贡献生态安全、同时提升自己工具可信度和采用率的最佳方式。整个过程设计得尽可能简单、安全。5.1 注册与签名全流程整个过程在命令行中完成无需复杂的界面操作。安装与注册 在你的MCP服务器项目目录下运行以下命令开始注册流程。npx proofxhq/agentsearch register your-server-name请将your-server-name替换为你工具的唯一标识符通常与你的GitHub仓库名或NPM包名一致。密钥对生成 命令会首先在你的本地机器上生成一个ECDSA P-256密钥对公钥和私钥。这里有一个至关重要的安全设计你的私钥永远不会离开你的本地环境不会被上传到任何服务器。系统只会要求你上传公钥。所有权挑战 系统会生成一个随机挑战码一串字符。你需要用本地刚生成的私钥对这个挑战码进行签名。提交证明 你将签名结果和公钥一起提交给AgenticSearch的注册服务。服务端会用你提交的公钥来验证签名是否正确。如果验证通过则证明你拥有该私钥。公钥关联 最后你需要将你的公钥以某种公开的、与你的代码仓库绑定的方式存放。我们推荐的方式是在你的GitHub仓库根目录创建一个名为AGENTSIGN.PUB的文件并将公钥内容放入其中。这样任何人都可以到这个仓库查看这个公钥而AgenticSearch在索引你的工具时会验证该公钥是否与注册时提交的一致从而完成“公钥-仓库”的绑定。5.2 集成到CI/CD流水线进阶手动签名适合偶尔的发布但对于活跃的项目最佳实践是将签名集成到自动化发布流程中。以下是一个GitHub Actions工作流的示例片段它在创建新的Git版本标签时自动完成签名和注册验证name: Sign and Register Release on: push: tags: - v* # 当推送v开头的标签时触发 jobs: sign-and-register: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Setup Node.js uses: actions/setup-nodev3 with: node-version: 18 - name: Install AgenticSearch CLI run: npm install -g proofxhq/agentsearch - name: Sign and Register env: AGENTSEARCH_API_KEY: ${{ secrets.AGENTSEARCH_API_KEY }} # 需要在仓库Secrets中配置 run: | # 假设你的工具名是固定的或者可以从package.json读取 TOOL_NAMEmy-mcp-server # 执行注册/签名流程CLI会处理密钥生成和挑战 npx proofxhq/agentsearch register $TOOL_NAME --ci # 将生成的公钥文件提交到仓库 git config user.name GitHub Actions git config user.email actionsgithub.com git add AGENTSIGN.PUB git commit -m chore: add AgenticSign public key for release ${{ github.ref_name }} git push注意事项私钥的安全存储在CI/CD中私钥需要被安全地存储和使用。上述示例是一个简化流程。在生产环境中你应该使用GitHub Actions的加密Secret来存储私钥的加密版本并在流水线中使用专门的签名工具如openssl在内存中完成签名操作避免私钥明文落地。AgenticSearch的CLI工具提供了--ci模式来适应这种无交互环境允许通过环境变量传递必要的密钥材料。5.3 向L3/L4进阶L3已验证如果你的MCP服务器是为特定域名如api.yourcompany.com服务的你可以通过添加DNS TXT记录来证明域名所有权。AgenticSearch会查询该记录进行验证。对于组织项目可以验证GitHub组织所有权或使用企业邮箱域。L4已审计这需要你聘请第三方安全公司对代码进行审计。完成后将公开的审计报告链接提交给AgenticSearch进行验证和记录。这通常是金融、医疗等高敏感领域工具的目标。6. 架构解析AgenticSearch如何工作理解其背后的架构能帮助你更放心地使用它也能明白其设计的巧妙之处。6.1 系统组件与数据流AgenticSearch系统主要由三部分组成爬虫与索引引擎持续扫描各大MCP注册中心、GitHub、NPM等公开来源发现新的MCP服务器。它会抓取源码仓库、README、package.json等并提取关键元数据名称、描述、能力标签、作者信息等。信任评分引擎这是核心大脑。对于每个被索引的工具引擎会执行一系列检查签名验证检查仓库是否存在AGENTSIGN.PUB等公钥文件并验证其签名。所有权挑战对已注册的工具定期或按需重新发起挑战确保密钥仍有效。元数据关联验证作者注册信息与代码仓库提交者、域名WHOIS信息等是否关联。审计报告验证核对提交的审计报告真伪及有效性。 根据检查结果计算并赋予L0-L4的信任等级。MCP查询接口即你本地运行的agentsearch serve服务。它作为智能体和后端索引/评分引擎之间的桥梁。它接收智能体的搜索或检查请求向后端API查询并将格式化的、包含信任信息的结果返回给智能体。6.2 安全与隐私设计无中间人风险你的智能体与本地AgenticSearch服务器通信本地服务器再与后端API通信。你的具体搜索查询和工具使用行为不会完全暴露给后端。最小化数据收集索引引擎只收集公开的源码元数据不收集工具的实际运行数据或用户的使用数据。抗欺骗设计信任模型基于密码学证明而非可轻易伪造的星级或评论。L2及以上等级很难被恶意冒充。7. 常见问题与排查实录在实际部署和使用中你可能会遇到一些问题。以下是我在测试和推广中遇到的一些典型情况及解决方法。7.1 集成与配置问题问题1Claude Desktop配置后没有出现新的工具。检查点1配置文件路径和格式是否正确。确保JSON格式正确没有缺少逗号或括号。可以使用在线JSON校验器验证。检查点2Claude Desktop是否已完全重启有时需要完全退出包括后台进程再重新启动。检查点3查看Claude Desktop的日志。日志位置通常在同级目录的logs文件夹内。查找是否有关于加载MCP服务器的错误信息。问题2运行npx proofxhq/agentsearch serve时报错或无法启动。可能原因Node.js版本过低或网络问题。确保Node.js版本在16以上。尝试使用npm install -g proofxhq/agentsearch全局安装后再运行agentsearch serve。7.2 信任模型与结果疑问问题3为什么我熟悉的、知名的工具显示是L0未签名这完全正常也恰恰说明了当前生态的现状。信任等级不反映工具的功能质量或流行度只反映其可验证的身份信息。一个非常流行但未签名的工具在AgenticSearch看来其信任基础与一个刚创建的匿名工具没有区别。你可以联系该工具的开发者建议他们进行签名注册。问题4L2签名是否意味着工具100%安全绝对不意味着。L2只证明“这个公钥的控制者控制着这个源代码仓库”。它不能保证代码本身没有恶意逻辑或漏洞。它解决的是来源真实性和完整性问题防止代码在分发后被篡改供应链攻击。代码本身的安全性即作者是否作恶需要L4审计、代码审查等其他机制来保障。L2是必要的基础但不是安全的全部。7.3 开发者注册问题问题5在注册时命令行工具卡住或报网络错误。确保你的网络可以访问AgenticSearch的后端API。可以尝试运行curl https://api.agentsearch.cybersecai.co.uk/health检查连通性。检查是否设置了代理环境变量如HTTP_PROXY导致npx连接问题。问题6公钥文件AGENTSIGN.PUB应该包含什么内容文件内容就是注册命令成功后在本地生成的公钥的纯文本字符串通常是PEM格式以-----BEGIN PUBLIC KEY-----开头。直接将其完整复制到新建的AGENTSIGN.PUB文件中即可。不要添加任何额外的注释或格式。问题7更新代码后需要重新注册吗不需要。只要你的私钥保持不变并且公钥文件AGENTSIGN.PUB仍然存在于你的仓库中你的工具就会保持L2状态。签名绑定的是你的仓库和公钥而不是某一次提交。当然如果你发布了新的重大版本重新进行一次签名流程可以使用相同的密钥并更新公钥文件的时间戳是一个好的实践可以显示活跃维护状态。8. 未来展望与生态责任构建AgenticSearch的过程让我们深刻意识到AI智能体的安全不是一个可选功能而是其能否真正走向企业级应用的生命线。我们正处在一个类似互联网早期的“蛮荒”阶段协议和工具先于安全标准出现。IETF互联网工程任务组已经开始起草关于智能体身份和传输安全的草案OWASP的MCP Top 10也明确了风险。行业知道问题所在但行动的速度远跟不上生态爆炸式增长的速度。每天都有新的、未经验证的MCP工具被创建并被智能体在不知情的情况下使用。AgenticSearch是我们抛出的第一块砖它试图用最轻量、最易集成的方式为生态注入第一剂“信任疫苗”。它的成功不取决于我们而取决于整个社区——开发者是否愿意花几分钟时间为自己的工具签名用户是否愿意在提示词中加上一句“使用前请先检查信任等级”。我个人认为为AI工具建立可验证的身份体系将成为下一代软件开发的标配。这不仅仅是安全需求更是责任和合规的要求。当你构建的工具被一个自主的AI用于处理支付、访问数据库或发送邮件时你难道不希望用户知道这个工具确实来自你且未被篡改吗最后分享一个在内部测试中的小技巧我们尝试让Claude在每次自主选择工具后在思考过程中简短记录下选择理由特别是当它选择了一个低信任等级L0 L1的工具时。这不仅能留下审计线索有时还能发现智能体决策逻辑中的盲点。例如它可能仅仅因为某个工具的描述更“华丽”而忽略了高风险警告。通过微调提示词来强化其“安全优先”的决策权重是另一个值得深入探索的方向。信任的建立需要时间但第一步必须从现在迈出。希望AgenticSearch能成为你AI智能体旅程中一位可靠的安全副驾。