一开始我就是想做套壳MCP一个好看的界面把几个MCP服务器给我围起来、统一管理、点两下就能调用那种。结果半年过去这个本该安安静静当壳的项目长出了信息检索、证据交叉验证、决策置信度评估这些功能模块连前端都多了一块结论溯源面板。朋友看到Demo都开玩笑说你这不是壳这是研究决策系统。我回头复盘了一下发现这种演化不是拍脑袋而是每个MCP生态里做应用的开发者迟早都会踩到同一条路上。这篇文章把我这段过程完整摊开讲包括最初为什么想套壳、MCP里哪些设计注定了它适合被进一步包装、我从壳到系统做了哪三次重构、关键实现里哪些细节决定成败以及我在实际调试中踩过的坑和排查思路。如果你正在折腾MCP客户端或者想把多个MCP工具拼成一个真正干活的系统这篇应该能给你省不少试错时间。1. 一开始只想套个壳怎么越做越重1.1 壳的定义与起步目标先交代背景。MCPModel Context Protocol模型上下文协议是这几年AI工具集成里越来越常见的标准化协议。它的核心思路是把外部工具、数据源和提示词统一成一种可被模型调用的资源。你可能见过几种叫法支持MCP的客户端、MCP服务器、MCP工具。不管哪一种站在开发者的角度MCP做的事情就是让模型可以按一个约定好的格式去访问外部能力比如搜网页、查数据库、读文档、调接口。套壳MCP我当时的定义特别朴素做一个网页左边是会话列表下边是输入框右边是工具状态面板。用户在这里选择要用哪个MCP服务器给模型发一条消息模型按需调用工具然后把结果回填到聊天里。这个壳不承担任何业务判断它只是把MCP协议的能力平移到浏览器里。第一版确实不复杂。用一个现成的SDK接MCP客户端SDK写一个后端服务做统一入口前端用WebSocket推流式响应。工具列表从服务器的声明里动态拉取参数表单根据JSON Schema自动生成。大概两周壳子就立起来了。当时我心里想这就够了MCP行业还在发展界面统一就是价值。1.2 从壳到系统的第一根刺转折点来自一次真实使用。我让模型帮我做一个竞品调研逻辑上需要它自己拆解成几个步骤先确认行业背景再搜主要竞品然后对比功能差异最后生成结论。结果是模型确实会调用搜索工具但它只搜了一轮把前三条链接的摘要读了一遍就草草收尾。我问它为什么不多查几个信息源它说第一轮结果已经足够支撑初步判断。这个回答让我很不舒服。因为我知道这个判断的证据明显不足。当时的壳没有任何机制告诉模型“你的信息量不够应该继续查”也没有任何机制统计证据之间的冲突。也就是说壳子只是把工具推到了模型面前却没有帮助模型把工具用好。从那之后我开始意识到真正需要做的不是界面而是让这个系统开始“研究工作”。所谓的壳必须内生出研究和决策支持否则它面对复杂任务时就是把模型的短板用漂亮UI包装得更明显。2. 研究这门手艺到底缺了哪三块零部件2.1 研究不是一次搜索是多次迭代做过正经调研的人都知道研究很少是一锤子买卖。你先搜一个宽泛的关键词看摘要发现行业术语再搜更精确的术语查到一个可疑数据需要去原始出处确认两个资料来源不一致需要再找第三方佐证。整个流程里充满了反馈循环行动、评估、调整、再行动。通用大语言模型本身很擅长单次推理但如果没有任何外部控制让它自行完成多轮研究它往往会贪图省事。搜索一次、读两个摘要、生成结论这是最能快速结束任务的路径但不是最能保证质量的路径。要让模型真正做研究系统必须有一套机制去规划步骤、追踪证据、识别缺口、触发补充查询。2.2 MCP提供的是一嘴巴牙齿不是咀嚼系统MCP服务器的价值在于它把外部世界的接口浓缩成模型能直接使用的工具。理论上只要工具足够多模型想查什么都能查到。但这里有个常见的误解工具多不等于研究能力强。打个生活化的比方给你一把剪刀、一把菜刀、一个磨刀器你依然不一定能做出好菜。工具是被动资源研究过程需要的是主动控制。哪些关键词值得深挖、哪些结果需要怀疑、哪些信息来源优先级更高这就是决策系统需要补上的部分。MCP把牙齿给了你但咀嚼的逻辑得自己长出来。所以我在第二版架构里加了一个很土但很管用的东西研究规划器。它不直接调用MCP工具而是负责拆解任务、生成搜索计划、评估当前证据覆盖率再指示执行器去调用MCP工具。规划器本身也是一个语言模型调用但它和模型的日常聊天有本质区别——它的输出是结构化的步骤清单而不是自然语言回复。2.3 决策需要置信度不能只给结论调研的最后一步一定不是“我给你一份报告”而是“我给你一个判断并说明为什么这么判断”。传统的套壳MCP生成结论时只输出文本。但研究决策系统里的结论需要附上置信度、证据引用、反方观点和未解决的不确定性。置信度这个东西我一开始觉得很玄其实实现起来就是让模型在生成结论之前先做一次显式的证据盘点。它需要列举我一共找到了哪些独立证据源、哪些结论得到多个来源支持、哪些结论只有一个来源、哪些证据之间相互矛盾。在这个盘点的基础上模型给出的置信度才不是拍脑袋。解码侧还可以做一点辅助让模型先生成一个 conclusion.json里面包含 verdict、confidence、evidence_ids、uncertainties再由系统把它渲染成结论卡片。这块我后面细讲。3. 从壳到研究决策系统的三次重构3.1 第一跳引入规划与执行分层第一次重构其实动作不大。我只是把原本“一条消息进来直接丢给模型调用工具”的流水线改成两个阶段先让规划器拆步骤再让执行器按步骤逐个走。刚开始我把规划结果做成纯文本步骤让执行器去读。效果很糟糕模型经常把步骤理解偏。后来改进成JSON结构{ objective: 调研三款主流笔记工具的API能力差异, steps: [ {id: 1, action: search, query: 笔记工具 A API 文档 能力, source: web}, {id: 2, action: search, query: 笔记工具 B API 文档 能力, source: web}, {id: 3, action: compare, targets: [step1, step2], criteria: [同步, 嵌入, 权限]} ] }规划器的输出被校验之后存成一个研究任务对象执行器只负责从任务对象中取步骤、执行、回填结果。这一层分离的价值在后续迭代里越来越明显——因为决策系统需要知道每一步到底基于什么证据。3.2 第二跳多源证据汇编与冲突识别第二跳才是真正把它变成系统的一步。我增加一个证据数据库对每一条工具返回的信息都做了抽取、清洗和入库处理。入库的信息结构大概是{ evidence_id: ev_0001, content: 工具A支持本地存储但API无官方同步接口, source: 工具A官方文档, retrieved_at: 2025-06-10T08:30:00Z, tool: doc-reader-mcp }有了证据库之后执行器搜索到的新信息就会先和已有证据做关联系统尝试做两件事找重复找矛盾。重复信息可以做去重和聚合矛盾信息则被标记出来在最终生成结论时强制要求模型给出解释。这一步极大改变了用户的体感。以前搜索完给一段文字用户要自己判断哪些信息可信现在系统可以直接展示“这个结论有4条独立证据支持但有一条反方证据”之类的结构化汇总。用户不需要把所有原始链接重新读一遍就能对结论质量有个初步判断。3.3 第三跳决策置信度评估与可回溯性第三次重构是把决策逻辑固化下来。我加了一个decision模块专门负责生成结论和置信度评估。它读取证据库按照预置标准执行评估支持结论的独立证据数量不能少于两条。若证据中出现矛盾必须展现说服力并声明剩余不确定度。如果证据冗余度高系统会下调结论的置信度。结论最终会渲染成结构化卡片每一句话后面都能跟着证据引用。用户点击引用就能看到原文、来源和时间。这个“可回溯性”听起来很学术其实对使用体验的提升是决定性的。人不愉快的是满篇结论但不知道哪来的有了证据溯源怀疑的时候直接钻下去反而能建立信任。4. 关键实现这些技术细节决定成败4.1 工具注册与能力声明MCP服务器会返回工具列表每个工具带参数Schema。第一版我直接把这些信息展示在界面上第二版开始就发现不够用了。因为研究决策系统需要知道的不只是“有什么工具”还包括“这个工具适不适合当前步骤”。我给每个工具建了一份能力元数据除了原始Schema还额外标注工具的典型用途。查询延迟预期。数据新鲜度。是否适合作为独立证据源。这些元数据会作为上下文的一部分传给规划器让它在决定“用哪个工具”时有一个参考坐标系。比如规划器知道某个搜索工具平均需要6秒返回它就不会让执行器做一次性的等待而是让多个查询并行发出。4.2 搜索回调与上下文灌装研究任务和普通聊天的区别之一是信息量很大。直接把所有搜索结果拼进上下文很快就会把模型窗口撑爆而且会让模型注意力失焦。我试过几次之后确定了一个灌装策略执行器不从搜索工具拿回所有内容而是要求工具返回摘要加关键字段系统端做裁剪后只把结构化结果送到执行器。举个实际例子。搜索一个关键词MCP工具返回10条结果每条约500字。系统会先做粗提取留下标题、来源域名、摘要、发布时间再送到执行器那里。执行器如果觉得其中某一条需要看全文再单独调用一次文档读取工具。这种两级读取模型极大减少了无效上下文的占用也给证据库留下干净的数据。4.3 置信度与不确定性处理置信度不是从天上掉下来的。我在实现里让模型在评估阶段先输出一个自评文档文档里必须列出自己的推理过程、每个关键结论对应的证据ID、无法访问到的资料清单。有了这些系统才能把置信度划分成可解释的区间而不是让模型随便给个百分数。这里有个特别容易踩的坑语言模型输出的百分数往往受过拟合偏好影响你让它打分它倾向于偏高。我的折中方案是不要直接问它“你有多确信”而是让它做反方观点搜索后再打分。当模型亲眼看到矛盾证据时分数通常会更贴合真实证据强度。这一招实测下来效果非常明显。4.4 前端呈现的差异化架构升级之后前端也不能再是简单的聊天窗口了。我后来把界面分成四个区域研究面板流程状态和步骤时间线、证据区检索到的证据卡片和关联关系、对话区执行器的每一步动作和思考、结论卡最终决策与置信度。每一个区域都有Filter用户可以按工具类型、证据来源、时间范围来梳理信息。有一次我在演示时旁观的同事说了一句话我印象很深以前这个页面看起来像聊天软件现在看起来像一个内部数据监视控台。我觉得这描述很准确研究决策系统需要的不只是问答更是过程追踪和多维审视。5. 踩坑记录与问题排查手册5.1 工具超时导致整个任务卡死最早期的时候执行器对MCP工具的调用都是同步串行。一旦某个搜索工具挂起整条任务就卡住界面很久不动用户非常恼火。后来我在执行器里引入两层机制。第一层是超时控制每个工具根据元数据里的预期延迟设置超时上限超出就返回一个工具不可用的结构化错误。第二层是并行调度多个独立查询可以同时跑不互相阻塞。只做了这两件事任务的完成时间和稳定性都有了质的提升。5.2 模型在中间步骤陷入低质量循环研究的反馈循环理论上很美好但不对模型做约束的话它会陷入一种低质量循环反复搜索相似关键词拿到相似结果还觉得自己在做深度调研。我的对策是给规划器加了“新鲜度护栏”每轮搜索之前先对比证据库里的已有证据如果新查询的关键词和已有证据的重合度超过阈值规划器必须换关键词或者换搜索视角。这个护栏不复杂但它非常有效能把搜索损耗压下去不少。5.3 工具返回结果互相矛盾怎么选这是研究系统里最棘手的问题。不同来源的信息互相矛盾模型有时候会默认相信最后一个返回的或者权重平均结果稀里糊涂。现在我在系统里定义了一个矛盾处理流程先获取矛盾双方的原始出处再提供这些来源的可信度参考最后要求模型做一次裁决并保留双面证据。系统最终的结论里会同时保留“主流观点”和“少数据支持的反驳观点”用户自己决定采纳程度。这个设计符合真实研究场景也避开了系统妄图替用户拍板的尴尬。5.4 误把聊天状态当作研究状态早期版本有个很隐蔽的Bug整个研究过程的进展和聊天历史是共用一个状态空间的。用户一旦在研究中发一条无关消息研究状态可能被覆盖任务就乱了。后来我把研究状态和对话状态彻底解耦。研究任务有独立的Session包含规划步骤、证据入库、决策评估等字段。聊天只是任务执行时的临时交互视图不会反过来污染核心状态。这个重构看着不起眼但让系统的稳定度提升了一个档次。常见问题根因解决措施搜索工具超时串行调用无超时超时上限 并行调度模型反复搜同质关键词反馈循环无新鲜度护栏证据重合度检查强制换词矛盾证据被无视模型默认信任最后来源矛盾处理流程保留双方证据研究状态被聊天覆盖状态空间耦合研究任务独立Session6. 如果你也想做套壳MCP建议先想清楚四件事6.1 套壳和系统的分界线在哪套壳本身没有错。如果你只是想在多个MCP工具上面做一个统一入口那套壳是性价比最高的方案。它不需要你碰任何业务逻辑只是界面工程的功夫。但一旦你的用户问出这个问题结论怎么来的靠什么信息支撑为什么和另一个来源不一致套壳就开始不够用了。研究决策系统和套壳的分界线就是系统开始承担证据管理和决策解释责任的那一刻。你可以在纸上先画一条自己对这条线的理解然后等需求逼到你的时候再考虑升级。6.2 研究决策系统的前提条件不是所有需求都需要决策系统。如果你的任务场景是“用户明确知道自己要调哪个工具”那套壳就够了。需要系统化方案的场景一般有这几个共同点任务需要多轮才能完成、结论依赖多个信息源、来源之间存在质量差异、用户需要看到推理过程。我建议做之前在需求文档里把这些条件写清楚。否则容易被自己的系统绑架把简单场景复杂化。我见过一些人拿到MCP后直接照抄所谓深度研究系统的架构结果体量巨大但最适合用户的还是轻量套壳这就是没想清楚边界。6.3 别推卸给模型系统要承担结构责任还有一个特别容易犯的错把所有能力都交给语言模型期望它靠prompt就能完成研究。大模型确实能完成一部分但真正的系统责任要落在代码上任务步骤要落在对象里证据要落在数据库里矛盾要落在冲突标记里。模型可以负责做判断但做判断的原材料必须由系统来经手。6.4 稳定优先界面后置我一路做下来最深的体会是研究决策系统的核心资产其实是数据结构和状态管理。前端漂不漂亮反而是次要的。你可以先用一个简朴的接口跑通全流程再去优化视觉。反过来如果先把界面做得花团锦簇再回头补证据链路会很痛苦因为前端视觉和应用结构的耦合远比你想的要重。7. 最后分享一点我在反复调整中的实际心得如果你问我这个项目最后带给我什么可复用的东西我会说一个稳定运行的研究任务对象模型比漂亮的壳子值钱得多。具体而言在代码里把研究任务建模成独立于会话的实体包含状态、步骤、证据集合和决策记录。这个模型一旦稳定住后面加什么功能都不太会乱。我一共重构过三次这部分的带队思路第一版是字段全在聊天上下文里找第二版拆成任务对象和证据库第三版加了规划和评估两个子模块。每往前一步系统稳定性都肉眼可见地增长。另外一支特别值得投入的是证据去重。看起来简单但跨工具去重难在维度差异同一个信息一个MCP工具返回的可能是标题摘要另一个返回的可能是完整正文。如果去重只做字符串匹配几乎等于没做。我用的是内容指纹加语义相似度双策略效果才算及格。说回标题那个问题一个套壳MCP为什么长成了研究决策系统站在今天再看我觉得原因是当工具足够多、能力足够密的时候用工具的人自然会问出那些更深层的问题。他们不满足于“能调”而是开始要求“调得对、调得可靠、调得有依据”。一旦用户提出这个要求系统的形态就已经注定要从壳向大脑进化了。希望这篇复盘能帮你少走一些弯路。不管你是只想做一个轻量壳还是已经准备往研究决策系统方向走把边界想清楚、把任务状态管好这两个点做到位了后面的事都会顺不少。