基于边缘计算的MCP服务器集群:为AI Agent构建低成本、高可用的专业工具箱
1. 项目概述一个基于边缘计算的AI代理服务器集群如果你正在为你的AI应用无论是Claude、Cursor还是其他AI Agent寻找一个稳定、可扩展且成本可控的后端服务架构那么你很可能已经听说过或正在寻找MCPModel Context Protocol服务器。今天我想分享的是我在过去一年里从零开始构建并投入生产环境运行的一套名为“OpenClaw”的MCP服务器集群。这套系统目前承载了9个不同功能的MCP服务器部署在超过229个Cloudflare Worker上并且完全运行在免费额度内。它不是一个简单的玩具项目而是一个经过了1073次测试验证服务于真实AI工作流的生产级系统。简单来说OpenClaw MCP Servers 是一个为AI代理Agents提供专业化、模块化上下文服务的工具箱。想象一下你的AI助手不再是一个“通才”而是一个配备了专业顾问团队的“指挥官”。当它需要分析代码安全时可以调用“安全扫描”顾问当它需要理清复杂信息关系时可以求助“知识图谱”顾问当它需要确保内容合规时又有“合规审查”顾问待命。OpenClaw就是为你的AI打造的这个顾问团队通过MCP协议以标准化、低延迟的方式提供这些专业能力。这套系统特别适合三类开发者一是正在构建复杂AI Agent应用需要集成多种外部能力的团队二是希望为自己的AI工具如Cursor、Windsurf添加私有化、定制化功能的独立开发者三是任何对Serverless架构、边缘计算以及如何在高并发下保持AI服务稳定性和低成本感兴趣的技术爱好者。接下来我将深入拆解这个项目的设计思路、技术实现细节以及我在实战中积累的经验与教训。2. 核心架构与设计哲学2.1 为什么选择“多脑集群”与边缘计算在项目初期我面临一个核心抉择是采用传统的中心化服务器如AWS EC2或容器集群还是拥抱新兴的边缘计算范式我最终选择了后者并构建了一个由7个逻辑“大脑”组成的集群运行在全球分布的Cloudflare Worker边缘节点上。这个决策背后有几个关键考量。首先延迟是AI交互体验的杀手。当用户与Claude或Cursor交互时每一次调用MCP服务的等待都直接影响流畅度。中心化服务器无论带宽多高物理距离带来的延迟尤其是跨洲际是无法忽视的。而Cloudflare的全球边缘网络可以将计算动态调度到离用户最近的节点通常能将延迟从几百毫秒降低到几十毫秒甚至更低。这对于需要频繁、实时交互的AI Agent场景至关重要。其次成本与可扩展性的平衡。AI服务的负载往往是突发且不可预测的。一个爆红的提示词模板可能瞬间带来百倍流量。传统的服务器方案需要提前预留资源以应对峰值导致大部分时间资源闲置成本高昂。Cloudflare Workers的Serverless模型实现了真正的按需付费在我们的使用量下甚至完全免费并且具备毫秒级弹性伸缩能力。当流量洪峰来临时边缘网络会自动调度更多实例无需人工干预。最后是架构的韧性。我设计的“7-brain cluster”Claude, YEDAN, yeren, rendan, GOLEM, rensin, dansin并非七个独立的物理实体而是一套逻辑上的责任分离与故障隔离机制。每个“大脑”被赋予特定的职责范围或数据类型处理偏好。例如有的专门处理结构化JSON的解析与验证有的擅长流式文本的生成与摘要。这种设计有两个好处一是单一服务的故障不会导致整个系统瘫痪请求可以被路由到其他功能相近的“大脑”二是在进行A/B测试或灰度发布新模型逻辑时可以非常灵活。实操心得边缘计算的冷启动问题尽管边缘函数有诸多优点但其“冷启动”Cold Start延迟是需要精心优化的点。一个未常驻内存的Worker被首次调用时需要经历初始化过程这可能增加50-200ms的延迟。我的解决方案是为每个MCP Server设置一个轻量的“保活”触发器定期如每5分钟发送一个健康检查请求确保核心服务实例处于“热”状态。同时将依赖的模块尽可能打包精简减少初始化时的加载负担。2.2 MCP协议AI世界的“通用插座”Model Context Protocol (MCP) 本质上是一套标准化的通信协议它定义了AI模型如Claude与外部工具、数据源之间如何安全、高效地对话。你可以把它想象成AI世界的USB-C接口或者电源插座标准。在没有MCP之前每个AI模型接入外部服务都需要定制化的适配器开发效率低且难以复用。OpenClaw的9个服务器都严格遵循MCP协议规范进行开发。这意味着它们不仅能被Claude Desktop原生支持也能被任何实现了MCP客户端的AI平台如Cursor、Windsurf即插即用。协议的核心是围绕“资源”Resources和“工具”Tools两个概念构建的。资源代表AI可以读取的静态或动态数据源。例如我们的“知识图谱”服务器会向AI暴露一个名为kg://entities/{id}的资源URIAI通过MCP协议请求该URI就能获取到特定实体的详细信息。工具代表AI可以执行的操作。例如“安全扫描”服务器会提供一个名为run_owasp_scan的工具AI通过调用这个工具并传入代码片段就能获得一份OWASP Top 10的安全审计报告。在实现上每个OpenClaw MCP Server都是一个独立的TypeScript项目它导出一个符合MCPServer接口的对象。这个对象明确定义了该服务器提供哪些resources和tools以及对应的处理函数。下面是一个高度简化的示例展示了一个“内容审查”工具的基本骨架// 示例一个简单的MCP服务器结构 import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new Server( { name: openclaw-content-moderation, version: 1.0.0, }, { capabilities: { tools: {}, resources: {} } } ); // 定义一个工具内容安全评分 server.setRequestHandler(ToolsCallRequestSchema, async (request) { if (request.params.name content_safety_score) { const { text } request.params.arguments as { text: string }; // 这里是实际的业务逻辑调用内部模型或API进行评分 const score await calculateSafetyScore(text); return { content: [ { type: text, text: 安全评分: ${score}/100。${score 60 ? 内容可能存在风险建议复审。 : 内容安全。}, }, ], }; } throw new Error(Unknown tool: ${request.params.name}); }); // 启动服务器通过标准输入输出与AI客户端通信 const transport new StdioServerTransport(); await server.connect(transport);这种标准化带来的最大好处是生态互操作性。一旦你的服务按照MCP实现它就自动进入了Claude、Cursor等日益壮大的MCP生态圈无需为每个平台单独开发插件。3. 九大生产服务器深度解析3.1 安全扫描服务器将OWASP原则注入AI工作流这是我最先开发的服务器之一灵感来源于看到开发者在AI辅助下编写代码时可能无意中引入安全漏洞。这个服务器的核心目标是让AI在建议代码、审查代码或生成配置时能实时引用权威的安全知识库。核心实现服务器内嵌了OWASP AI Top 10专为AI应用设计的安全风险列表的详细规则库。当AI调用run_owasp_scan工具时服务器并非简单地进行字符串匹配而是执行一个轻量级的静态分析流程代码解析对输入的代码片段进行简单的语法分析识别出函数调用、API端点、数据库查询语句、依赖引入等关键元素。模式匹配将解析出的元素与OWASP规则库中的风险模式进行匹配。例如检测是否存在未经验证的用户输入直接拼接成SQL查询SQL注入风险或是否在提示词中过度暴露了系统指令提示词注入风险。上下文风险评估结合AI正在执行的“任务”上下文例如是在生成一个用户登录API还是在编写一个数据导出脚本对匹配到的风险进行优先级排序。生成审计报告最终以清晰的结构化文本格式返回给AI指出具体风险点、潜在影响、以及修复建议通常附带代码示例。一个典型的使用场景开发者在Cursor中询问“帮我写一个用户登录的Express.js端点。” AI在生成代码的过程中会同步调用安全扫描服务器。生成的代码可能会附带一条来自服务器的注释“⚠️ 检测密码使用了明文比对。建议使用bcrypt进行哈希加盐处理。参考OWASP A2:2023 - Cryptographic Failures。”避坑指南误报与性能的权衡深度静态分析非常消耗资源尤其在边缘函数环境中。我最初尝试使用更复杂的AST分析工具导致冷启动时间飙升。最终方案是采用正则表达式与关键词规则库相结合的轻量级方案并针对常见漏洞模式如XSS、路径遍历、硬编码密钥进行了高度优化。虽然这可能会带来极低的误报率例如将一段教学示例代码标记为风险但通过为AI提供“此代码仅为示例实际环境需加固”的上下文可以有效缓解。我们的原则是宁可轻微误报提醒也不漏报关键风险。3.2 知识图谱服务器为AI装配“长期记忆”与推理引擎AI模型本身是“无状态”的每次对话的上下文窗口有限。知识图谱服务器的目标就是为AI提供一个外部的、结构化的、可查询的“记忆体”。我们的图谱目前包含了7879个实体包括技术概念、API接口、项目模块、最佳实践条目等以及它们之间的关系。技术栈选择我选择了Cloudflare D1基于SQLite的Serverless数据库作为图谱的存储后端。原因有三D1与Workers同属Cloudflare生态访问延迟极低它支持完整的SQL语法便于执行复杂的图查询如多跳关系查询并且在免费额度内提供了充足的存储和读/写次数。图谱的构建与更新图谱数据并非完全手动维护。我们建立了一个半自动化的管道初始种子从项目文档、代码注释、架构图中提取实体和关系。AI增强定期让AI如Claude分析新的对话日志、提交的Issue和PR描述自动识别出新的技术术语、问题解决方案并将其作为候选实体建议给维护者。人工审核维护者通过一个简单的管理工具对AI建议进行审核、修正和确认最终入库。反向链接每当图谱被查询系统会记录“哪些实体在解决什么问题时常被一起提及”这些共现关系会作为权重信息反哺图谱优化后续的查询推荐。对AI的价值当AI在处理一个关于“如何优化Cloudflare Worker连接D1数据库”的问题时它可以查询知识图谱。图谱不仅返回“D1”、“Worker”这两个实体还会返回“索引优化”、“批量写入”、“事务使用”等相关实体及其关联的文档片段或代码示例。AI将这些信息整合进回答其准确性和深度远超仅依赖自身训练数据。3.3 合规检查服务器应对AI监管的“自动法务”随着欧盟AI法案等法规出台AI应用的合规性成为不可回避的话题。这个服务器是一个规则引擎它内嵌了我们对主流合规框架以EU AI Act为蓝本的关键要求解读。工作原理它提供诸如check_ai_act_compliance这样的工具。AI在生成内容特别是面向用户的产品描述、免责声明、数据使用条款或建议功能时可以调用此工具。服务器会基于以下维度进行分析风险分类判断所述AI应用属于“不可接受风险”、“高风险”、“有限风险”还是“最小风险”类别。透明度检查检查内容是否包含必要的披露如“此为AI生成”、“可能产生错误”等。数据与隐私检查建议的功能是否涉及敏感数据处理并提醒需要遵守GDPR等数据保护条例。生成合规文本根据分析结果自动生成合规性声明草案或修改建议。实际案例当用户要求AI“为我的图像生成AI写一段服务条款”时AI会先调用合规检查服务器。服务器可能返回“根据当前描述您的服务涉及个人生物特征数据面部图像处理可能属于‘高风险’系统。建议条款中加入1) 明确的数据处理法律依据如用户明确同意2) 数据保留期限3) 用户删除其数据的权利4) 人工监督机制说明。” AI将这些要点融入生成的条款中。4. 基于Cloudflare Workers的实战部署与优化4.1 从零到一部署你的第一个MCP Server让我们抛开理论直接上手。假设你已经有了一个用TypeScript编写好的MCP服务器代码例如一个简单的天气查询工具。以下是将其部署到Cloudflare Workers并让Claude Desktop识别的完整流程。步骤1初始化Wrangler项目Wrangler是Cloudflare的官方CLI工具。首先确保你已安装Node.js和npm。# 全局安装wrangler npm install -g wrangler # 登录到你的Cloudflare账户 wrangler login # 在项目目录下初始化如果尚未初始化 wrangler init my-mcp-server --typetypescript这会在目录下生成wrangler.toml配置文件。步骤2配置wrangler.toml这是最关键的一步配置决定了Worker的行为。一个针对MCP优化的配置示例如下name openclaw-security-scanner # Worker名称全局唯一 main src/index.ts compatibility_date 2024-08-01 # 使用模块格式这是MCP SDK推荐的 format modules [build] command npm run build [[build.upload]] format service-worker # 绑定D1数据库如果你的服务器需要 [[d1_databases]] binding DB # 在代码中通过env.DB访问 database_name my-kg-database database_id your-database-id-here # 环境变量用于存储API密钥等敏感信息 [vars] OPENAI_API_KEY your-secret-key-here # 限制资源避免超出免费额度重要 [limits] cpu_ms 50 # 单次请求最大CPU时间毫秒关键配置解析compatibility_date: 指定Worker运行的API版本建议使用较新的日期以获得稳定特性。format modules: MCP的服务器SDK通常使用ES模块此配置必须匹配。[limits]:这是控制成本的核心。Cloudflare Workers免费计划每日有100,000次请求和最多10ms CPU时间的限制但10ms对AI服务通常不够。这里设置为50ms是一个安全值确保大部分简单查询能完成同时避免复杂操作耗尽资源。你需要根据自己服务器的逻辑复杂度精细调整。步骤3编写适配Worker环境的入口点在Cloudflare Worker中你的代码需要导出一个默认的fetch事件处理函数。你需要将MCP服务器的Stdio通信适配到HTTP请求。// src/index.ts import { Server } from modelcontextprotocol/sdk/server/index.js; import { MCPTransport } from ./mcp-transport-adapter.js; // 需要一个自定义适配器 export default { async fetch(request: Request, env: Env, ctx: ExecutionContext): PromiseResponse { // 1. 解析请求获取MCP协议消息通常放在请求Body中 const mcpMessage await request.json(); // 2. 创建或复用MCP服务器实例 const server createMCPServer(env); // 3. 使用自定义适配器处理消息 const transport new MCPTransport(request, server); const responseMessage await transport.handleMessage(mcpMessage); // 4. 返回响应 return new Response(JSON.stringify(responseMessage), { headers: { Content-Type: application/json }, }); }, }; // 注意MCP SDK的StdioTransport不能直接在Worker的HTTP环境中使用。 // 你需要实现一个简单的适配器MCPTransport将HTTP请求/响应体转换为MCP的消息流。 // 这是一个简化示例实际实现需处理连接、心跳、多轮对话等。步骤4本地测试与发布# 本地开发 wrangler dev # 部署到生产环境 wrangler deploy部署成功后你会获得一个类似https://openclaw-security-scanner.your-username.workers.dev的URL。步骤5在Claude Desktop中配置在Claude Desktop的设置中找到“开发者”或“MCP服务器”设置添加一个新的服务器配置{ mcpServers: { openclaw-security: { command: npx, args: [ -y, mcp-client-http-proxy, // 需要一个客户端代理工具 --server-url, https://openclaw-security-scanner.your-username.workers.dev ] } } }这里需要一个额外的桥接工具如一个本地的HTTP到Stdio的代理因为Claude Desktop默认通过命令行调用本地进程。社区已有一些开源工具可以完成这个桥接工作。4.2 性能、成本与可靠性优化实战将200多个Worker管理得井井有条同时保持零费用靠的是一系列细致的优化策略。1. 请求合并与批处理许多AI交互是“对话式”的短时间内可能触发多个关联的MCP调用。例如AI在编写一个函数时可能先后调用“代码风格检查”和“安全扫描”。我们在客户端或一个网关Worker实现了简单的请求队列和合并逻辑将短时间内对同一服务器的多个请求合并为一个批处理请求在服务器端并行处理后再拆分返回。这显著减少了Worker的调用次数。2. 智能缓存策略我们为每个MCP服务器设计了多层缓存边缘缓存CF Cache对于变动不频繁的数据如知识图谱的实体基础信息、合规条款文本利用Cloudflare自身的CDN缓存设置较长的TTL如1小时。这直接将请求拦截在边缘节点零计算成本。D1数据库缓存层对于查询复杂但结果在一定时间内有效的数据如某个复杂安全扫描的结果摘要我们会将结果写入一张专门的cache表并建立快速的键值查询。D1的读取速度非常快且免费额度充足。内存级缓存Worker Memory利用Worker全局作用域Global Scope的变量在同一个Worker实例的生命周期内缓存极热的数据。注意此缓存无法在多个Worker实例间共享适用于会话级数据。3. 基于队列的异步处理并非所有操作都需要实时响应。例如“内容生成引擎”处理一篇长文润色任务可能需要十几秒。对于这类任务我们采用“快速响应回调”模式AI调用工具Worker立即返回一个{ status: “accepted“, taskId: “xxx” }。Worker将实际的重型任务推送到Cloudflare Queue中。另一个专用于处理的“后台Worker”消费者从队列拉取任务并执行。执行完成后通过一个Webhook URL由调用方提供或写入一个可查询的状态存储通知任务完成。 这样网关Worker始终能快速响应避免了超时和资源占用。4. 监控与告警免费额度虽高但并非无限。我们使用Cloudflare Workers自身的分析面板监控每日请求数、CPU时间、错误率。自定义日志与度量在每个Worker的关键路径上使用console.log输出结构化日志并利用Worker的fetch能力将聚合的度量数据发送到一个免费的监控服务如Better Stack进行可视化。额度预警编写一个定时触发的WorkerCron Trigger每天检查各项资源的使用量当达到免费额度的70%时自动发送通知到Discord或邮箱。5. 开发中的典型问题与排查实录在开发和维护这样一个分布式MCP服务集群的过程中我遇到了无数个坑。以下是几个最具代表性问题的排查思路和解决方案希望能为你节省大量时间。5.1 问题一MCP连接不稳定AI客户端频繁断开现象在Claude Desktop中配置了MCP服务器后连接时好时坏经常出现“服务器无响应”的错误尤其是在执行耗时较长的工具调用时。排查过程检查超时设置首先怀疑是网络或服务器响应慢。检查了Worker的fetch事件处理函数没有设置明确的超时控制。Cloudflare Worker默认有30秒的执行时间限制免费计划。如果MCP工具处理超过30秒Worker会被强行终止导致连接中断。检查客户端适配器我们使用的HTTP到Stdio的代理客户端可能也有自己的超时设置。查看其源码发现默认读超时是10秒。模拟长任务在服务器端添加一个sleep(15秒)的测试工具。调用该工具10秒后客户端超时断开但Worker仍在运行直到30秒后被系统终止。这证实了是客户端超时先于服务器超时发生。解决方案服务器端优化对所有可能耗时的工具进行性能剖析确保绝大多数操作在5秒内完成。对于确实需要长时间运行的任务必须改造为异步模式如前文所述的队列模式。客户端配置修改代理客户端的启动参数增加超时时间例如设置为25秒为网络延迟留出余量但必须小于Worker的30秒限制。实现心跳机制在MCP协议层对于长任务服务器定期向客户端发送“心跳”或“进度更新”消息保持连接活跃避免客户端因收不到任何数据而超时。核心教训在Serverless环境中你必须对“时间”有极强的敏感度。所有环节客户端、代理、服务器、下游API的超时设置必须匹配并且最终要服从于平台如Cloudflare Worker的硬性限制。设计工具时要优先考虑异步和快速响应。5.2 问题二D1数据库查询在高峰期变慢甚至超时现象知识图谱服务器在访问量稍大时响应时间从平均50ms飙升到1-2秒甚至出现“Database is locked”错误。排查过程分析查询语句检查慢查询日志发现有几个复杂的图谱遍历查询涉及多表JOIN和LIKE模糊匹配在数据量增长到几千条后性能急剧下降。理解D1的并发模型D1是SQLite虽然Cloudflare做了分布式优化但本质上对一个数据库的写入操作是串行化的。高并发下的写竞争会导致“锁”等待。检查读写模式发现我们的“记录查询日志”功能在每次只读查询后都会执行一条INSERT语句来记录日志。这导致了大量的微写入与主查询争抢锁。解决方案查询优化为频繁查询的字段如实体名称、类型添加索引。CREATE INDEX idx_entity_name ON entities(name);将复杂的LIKE%keyword%查询改为使用更高效的全文搜索FTS扩展或者引入简单的搜索索引表。避免N1查询使用JOIN或批量IN查询一次性获取数据。写入优化将非关键的写入操作如查询日志、更新访问计数异步化。改为先写入一个内存队列或KV存储再由后台任务批量写入D1。使用D1的批量写入Batch功能将多个INSERT语句合并为一个事务提交大幅减少锁竞争。架构拆分对于读写都非常频繁的核心实体表考虑将其拆分为“只读从库”定期从主库同步和“主库”。读请求优先路由到从库。核心教训即使是无服务器数据库也要像对待传统数据库一样进行性能优化。索引、避免N1查询、读写分离这些经典原则依然适用。在高并发场景下要特别警惕“写放大”效应。5.3 问题三跨服务器工具调用的循环依赖与死锁现象在构建“统一内存系统”时设计了一个场景内容生成服务器在创作时需要调用知识图谱服务器获取背景信息而知识图谱服务器在更新实体时又可能需要调用内容生成服务器来生成摘要描述。在测试中偶尔会出现两个请求相互等待最终双双超时的情况。排查过程绘制服务依赖图快速画出一个所有MCP服务器之间工具调用的依赖关系图立刻发现了几个潜在的循环调用链。日志追踪在请求头中添加唯一的request-id并透传所有服务。当发生超时时通过追踪这个ID可以清晰地看到请求在A-B-A的循环中卡住。分析业务逻辑发现某些“智能”调用逻辑过于激进。例如知识图谱服务器在发现某个实体的描述过于简短时会自动尝试调用内容生成服务器去“丰富”它而这个触发条件可能在一次查询中被多次满足。解决方案建立调用规则制定团队规范禁止同步的跨服务器循环调用。如果服务A需要服务B的能力那么要么A直接包含该能力的简化版本要么通过一个中间事件总线进行异步解耦。实现调用链检测与熔断在每个服务器处理请求前检查当前请求的调用链通过透传的ID列表。如果发现自己的服务ID已经出现在链中则立即拒绝此次调用并返回一个错误提示“检测到循环调用”。重构业务逻辑将“自动丰富描述”这种非核心、耗时的功能从同步路径中移除改为异步任务。知识图谱服务器只负责返回现有数据并附带一个“描述可优化”的标记。由前端或一个调度器在后台异步触发优化任务。核心教训在微服务或分布式Serverless架构中循环依赖是系统稳定性的隐形炸弹。在设计阶段就要严格审视服务边界优先采用单向依赖和异步通信。为关键路径添加防御性代码防止雪崩效应。6. 安全与策略引擎为AI套上“紧箍咒”在让AI获得强大外部工具的同时必须建立牢靠的安全边界。OpenClaw内置了一个“宪法策略引擎”它由8条“永不”规则和7条“始终”规则构成所有经过服务器的请求和响应都必须通过这个引擎的检查。“永不”规则示例永不执行未经净化的系统命令任何工具调用中如果包含直接执行shell命令的意图无论上下文如何一律拒绝。永不返回原始数据库错误信息服务器内部错误如SQL语法错误必须被捕获并转换为通用的“服务器内部错误”消息避免泄露表结构、字段名等敏感信息。永不绕过内容安全策略对于用户生成的内容必须经过安全扫描服务器的检查标记为高风险的内容不会被传递给AI或返回给用户。永不在无授权下访问外部用户数据工具调用如需访问第三方API如GitHub、Jira必须显式提供由用户配置的OAuth Token服务器自身不存储任何全局密钥。“始终”规则示例始终验证输入结构使用Zod或类似的Schema库严格校验所有工具调用的输入参数类型、范围、格式不符立即拒绝。始终记录审计日志所有工具调用包括调用者、参数、时间、结果状态都会以脱敏形式记录到安全的审计日志中用于事后分析和问题排查。始终进行速率限制基于调用者IP或API Key实施速率限制防止滥用和DDoS攻击。引擎的实现这个策略引擎被实现为一个高阶函数Higher-Order Function包装了每一个工具的处理函数。async function withPolicyEnforcement(originalToolHandler, toolName, context) { // 1. 检查“永不”规则 if (violatesNeverRules(context.request)) { throw new PolicyViolationError(“Request violates security policy: Never Rule #X“); } // 2. 应用“始终”规则输入验证、速率限制等 await applyAlwaysRules(context); // 3. 执行原始工具逻辑 const result await originalToolHandler(context); // 4. 对输出结果进行后置检查例如防止工具返回了意外敏感信息 const sanitizedResult sanitizeOutput(result); // 5. 记录审计日志 await logAuditTrail(toolName, context, sanitizedResult); return sanitizedResult; }这个策略引擎是我们系统稳定运行的基石。它确保了我们赋予AI的能力不会被滥用也保护了用户和系统自身的安全。在开发你自己的MCP服务器时我强烈建议将安全策略作为首要考虑因素进行设计而不是事后补救。