从MCP套壳到研究决策系统：AI工具链的进化实录

说实话“套壳MCP”这个说法最开始是有点自嘲的。当时我们内部需要一个能查资料、能跑批处理、还能顺手整理汇总的小工具MCPModel Context Protocol正好火官方 SDK 和社区封装都成熟我就写了 一个 server把几个网络检索、文档解析、JSON 处理能力包了一层标准接口。代码量不大三五个工具函数纯粹是“给大模型配外设”。但做到后面这东西已经不再是个外设。它自己长出了一套完整链路查询改写、多源采集、可信度评估、决策建议输出甚至开始有研究决策系统的味道。回过头看工具接口解决的是“模型能不能触达信息”的问题而研究决策系统解决的是“信息怎么变成判断”的问题。前者是手后者是脑和规则。这篇文章就把这段演化过程完整拆开讲讲当初为什么选 MCP 套壳、中间碰到的三个关键转折、现在的系统长什么样以及踩过的坑。1. 先说清楚MCP“套壳”是什么为什么要从它入手1.1 MCP 的基本盘一个类似 USB-C 的协议MCP 全称 Model Context Protocol它的核心价值不是“又多了一个框架”而是把“给模型提供工具”这件事标准化了。在没有 MCP 的时候每个应用都得自己定义函数调用格式自己写参数解析自己管上下文传参。模型 A 用一套 JSON Schema模型 B 又换一套接入外部工具时每个项目都来一遍“搬砖”工作。MCP 做的事情就是把这些全部定义成一套统一协议工具长什么样、参数怎么写、结果怎么返回、怎么处理流式响应大家按同一个标准来。打个比方以前每台设备都有自己的充电口于是包里塞满各种线。MCP 相当于 USB-C工具是一个独立的 MCP Server任何支持 MCP 的 Host机器人客户端、IDE、自动化框架都可以直接调用不用关心对方是什么模型、什么语言、什么平台。一个 MCP Server 的核心就三个概念工具声明tools/list告诉客户端“我有什么工具、参数是什么结构”工具调用tools/call客户端按声明传参服务端执行并返回结果资源与提示resources/prompts可选的用于给模型提供额外上下文或预设模板这三个概念就是我们最开始“套壳”的全部骨架。我只需要把已有的检索函数、解析函数、文件读取能力包装成标准接口声明宿主应用就能用自然语言直接调度它们。1.2 为什么选 MCP 而不是别的方案做这个选择之前我把三个方案放在一起对比过原生 Function Calling、直接 HTTP 调用、以及 MCP。方案优点缺点适合场景原生 Function Calling简单直接模型原生支持响应快强绑定单一模型厂商切换模型要改代码快速验证、单模型内部工具调用直接 HTTP 调用外部 API完全可控想怎么调就怎么调每次都要写参数解析、错误处理、上下文拼接工具数量少、不需要通用性MCP Server协议统一一次封装多处复用模型可替换初期有学习成本调试链路多一层工具较多、需要长期演进、希望与生态互通我最终选 MCP理由有三个。第一是统一接口带来的复用性。我把检索封装成 MCP 工具之后它不只是给某一个模型用公司里其他项目的 Agent、我自己的自动化脚本甚至社区里别人写的 Host 应用都可以直接连上来用。一次封装多处受益。第二是模型可替换性。用 MCP 之后模型只是 Host 里的一个组件。今天用模型 A明天换更合适的模型 B工具层完全不用改动。这节省的是长期的维护成本。第三是生态效应。MCP 的规范是开放的官方 SDK 和大量社区封装都在持续迭代。哪怕我今天只写了三个工具过两天社区发布了新的检索型 Server我可以直接拿来用不用自己造轮子。1.3 一个能跑起来的最小 MCP Server回到实操。我用的技术栈是 Python社区里比较顺手的是fastmcp这类库底层还是官方 SDK但把工具注册、参数校验、输入输出转换这些样板代码大大简化了。一个最小可用的 MCP Server核心代码量非常少大概长这样from fastmcp import FastMCP mcp FastMCP(research-basic) mcp.tool() def search_web(query: str, top_k: int 5) - list[dict]: 在网络资源库中搜索指定查询返回标题、摘要和来源链接供后续分析使用。 # 这里是实际检索逻辑可以对接任意搜索服务 results query_engine(query, top_ktop_k) return [{title: r[title], snippet: r[snippet], url: r[url]} for r in results] mcp.tool() def extract_text(url: str) - str: 抓取链接正文并提取纯文本去掉导航、广告等噪音内容。 html fetch_page(url) return readability_extract(html) if __name__ __main__: mcp.run()这一步就是全部“套壳”的内容把已有能力包成工具声明模型输入自然语言Host 负责解析意图调起对应工具工具把结果返回给模型做加工。但这里有个问题立刻暴露出来模型能调用工具了不代表它能把结果用对。比如我让它做一个技术选型调研检索工具会把一批混杂着官方文档、个人博客、营销软文的链接甩回来。模型拿到这些结果很容易被排名靠前的低质内容带偏甚至把一篇软文当成权威结论复述出来。这个问题的根子不在模型能力而在信息链路里缺少质量裁判。于是我开始琢磨光有手还不够得加脑子。2. 真正让它“系统化”的三个转折2.1 转折一检索结果不等于信息质量第一个让我意识到“这不能只是工具封装”的时刻是一次竞品分析。我用最原始的方式让模型去查某类产品的市场份额数据。检索工具确实返回了十条链接有行业报告摘要、有自媒体文章、甚至还有几年前的旧数据。模型最终给出的回答里把某个自媒体数值当成了“最新权威统计”。后来我手动点开链接发现那篇文章连数据来源都没写。这个场景太典型了。大模型本身没有判断信息质量的能力你喂给它什么它就消化什么。想让结果可信必须在工具链里内置一整套来源质量分级机制。我的初始方案非常朴素在检索结果返回时增加一个质量评估字段由一小段规则逻辑对每个链接打分。def score_source(source_info: dict) - dict: # 加权域名权威度、内容完整度、发布时间新鲜度、引用来源明确度 score ( domain_credit(source_info[url]) * 0.4 article_depth(source_info[snippet]) * 0.2 freshness(source_info[publish_date]) * 0.2 citation_quality(source_info[references]) * 0.2 ) source_info[quality_score] round(score, 2) return source_info这套规则不复杂但它第一次把“信息可信度”纳入了处理流程。模型在总结时会被告知优先采信质量分高的来源低分来源只能作为佐证不能作为结论依据。这一步做完后输出的靠谱程度明显提升但也让我看到更头疼的问题单条信息的质量问题好解决多条信息之间互相矛盾时怎么办2.2 转折二单点答案变成证据链做研究决策跟普通问答最大的区别是单一来源的回答永远只能算线索不能算结论。比如你问“某种方案在大型团队里是否可行”搜出来的结果必然是两极的——有人说好用到不行有人说坑到没法用。模型如果只取其中一条结果就是掷骰子。我开始意识到真正必要的是让系统把信息组织成“证据链”而不是给单个答案。证据链的意思是同一问题至少要采集多个独立来源然后做交叉验证把用户问题拆成若干子问题对每个子问题从不少于三个维度的信息源采集观点汇总时先按观点分组统计支持/反对各有多少再结合来源质量加权给最终判断加上“证据强度”标签比如问“方案 X 适不适合中小团队”系统内部会构建出这样一条证据链立场观点摘要来源数加权后可信度支持部署简单学习成本低免费额度够用30.71反对性能在数据量大时下滑明显客户支持响应慢20.58中立社区活跃但文档更新滞后10.42最终生成结论时模型看到的不是一堆杂乱链接而是整理好的、带权重的立场分布。它判断“是否适合”时就有据可依。这个转折是质的飞跃。因为从这一刻起系统做的不再是“帮你找答案”而是“帮你评估有哪些答案、哪些更可信、为什么更可信”。2.3 转折三总结报告变成决策建议第二个转折做完之后系统的输出已经像一份小型调研报告了。但我在使用中发现报告归报告最后做决定的时候使用者还是得自己默默消化一大堆利弊分析然后凭感觉拍板。于是第三个转折顺理成章输出不能止步于分析要转化成可执行的行动建议。我给系统的输出设计了一套固定结构强迫模型按决策语言说话核心结论用最多两句话回答“所以到底怎么选”关键依据支撑结论的 2-3 条最强证据附来源说明风险提示结论可能不成立的情况或者选择后需要注意的隐患建议动作接下来第一步应该做什么、第二步做什么这一步做法的本质是把“信息处理”的终点从“理解”推进到“行动”。模型的角色从“研究助理”变成了“决策参谋”。当然“决策参谋”这个定位容易让人误以为系统能替人做决定。我在设计里特别要求模型在输出建议时必须在“风险提示”里明确写出“本建议基于当前可用资料的合理解读不构成确定性判断”。不是因为它不负责任而是因为在信息不完整的情况下任何过度自信的建议都会误导使用者。研究决策系统的价值是帮你缩小选择范围不是替你消除所有不确定性。三个转折走完之后原来的套壳 MCP 工具已经回不去了。它从“几个工具函数”长成了一个有采集、有评估、有综合、有建议的四层系统。下面把现在的架构展开讲讲。3. 研究决策系统的核心架构与实现细节3.1 整体框架四层分工现在的系统大概分成四层每层职责单一上层只管调用下一层的能力不越界第一层是接入层负责接收用户问题完成意图识别和问题画像。系统会判断这是一个“事实查询型”问题还是“决策评估型”问题因为两类问题的处理流程差别很大。第二层是采集层负责根据问题类型生成检索策略决定查哪些库、搜什么关键词、需要多少个独立来源。采集完成后把原始信息清洗、去重、结构化。第三层是研判层核心是证据评估。系统会为每条信息打分按观点聚合形成正反两方的证据对比并计算整体可信度。第四层是决策层把研判结果转化为结构化输出套用结论、依据、风险、建议的格式生成最终答案。用一句大白话概括这四层接入层决定怎么理解问题采集层决定看哪些材料研判层决定信哪些材料决策层决定怎么把材料变成行动。3.2 几个关键模块的实现要点查询改写模块用户原话往往不适合直接拿去检索。比如“帮我看看现在做这块还有没有机会”这种模糊表达原始检索的效果很差。查询改写模块做的就是把模糊问题拆成具体子问题。我实际用的策略是两轮处理。第一轮让模型把用户问题改写成 2-3 个不同的检索式尽量覆盖问题的不同侧面第二轮对每个检索式切分为“核心实体 限定条件 分析角度”再做一次扩展。一个用户问题最终可能生成 6-8 个检索任务分发给不同的数据源。这一步看似开销大但它是证据链多源性的基础设施。没有足够的并行检索后面的交叉验证就是空中楼阁。证据评估模块证据评估是系统里最花心思的模块也是跟普通 RAG 检索最大的分水岭。RAG 通常的做法是“检索-嵌入-拼接-回答”把最相似的段落扔给模型。这套做法在知识问答场景很好用但在决策场景有致命弱点它只看“相关度”不看“可信度”和“立场分布”。一堆精心包装的营销内容RAG 照样会觉得它高度相关。我的证据评估模块对每条结果输出六个字段{ source_id: url-hash, source_type: 官方文档 / 技术博客 / 论文 / 社区讨论, publish_date: 2024-06-12, author_reputation: 0.85, originality: 一手实测 / 二次转述 / 观点评论, stance: 支持 / 反对 / 中立, quality_score: 0.72 }其中stance立场这个字段很关键。它让模型在做总结时能够按立场聚合而不是把正反观点混在一起说。实际操作中立场识别如果让模型自己判断偶尔会出错尤其碰到阴阳怪气或者反讽的文章。我的补救办法是先让模型输出“支持/反对/中立”再抽取原文关键句做二次验证两次不一致的标注为“未知”。决策输出模块最新版本的决策输出底层是一套基于结构化模板的解析逻辑。我要求模型返回 JSON然后在外部对 JSON 里的每一项做完整性和格式校验不合法就重新生成。这种做法的好处是格式正确性不依赖于模型自律。即使某个模型总想“自由发挥”输出也会被兜底逻辑纠正。这比直接在提示词里说“一定要按格式输出”可靠得多。核心 JSON 接口长这样{ conclusion: 结论方案 A 在当前调研条件下更适配中小团队的轻量需求, evidence_level: 中等强度, key_evidence: [ {summary: 部署复杂度低已有成熟社区教程, source_credit: 0.82}, {summary: 数据量超过预期时性能下降明显, source_credit: 0.71} ], risks: [若日均数据写入量超过 5 万条需引入额外缓存层], action_plan: [ 用真实业务数据做 48 小时压测, 校验批量写入场景下的吞吐量, 与运维确认扩容方案后再正式立项 ] }3.3 跟踪一次完整的处理流程我拿一个实际碰到的调研问题来走一遍全流程。问题是“我想搭一个内部的文档问答系统是选择直接用成熟产品还是自研一个轻量方案”接入层把它判定为“决策评估型”不是“事实查询型”。查询改写模块生成了一组检索任务内部文档问答 成熟产品 对比 自研轻量级 RAG 方案 开源 工具链文档问答 延迟 准确率 评测自研文档问答 投入 成本 维护采集层并行跑完这些查询汇总了 30 多条链接去掉重复、质量分低于阈值的 20 条保留 12 条进入研判层。研判层按立场聚合的结果是8 条支持“用成熟产品优先”理由集中在上线快、无需维护检索链路3 条支持“轻量自研”理由在数据可控性和灵活定制1 条中立观点是“取决于文档规模和更新频率”。决策层结合证据强度最终输出的核心结论是“文档规模中等且无复杂权限需求时优先选用成熟产品但需要保留自研备选以应对定制化场景”。同时给出了具体的验证动作先拿内部真实文档小规模压测测完再定。这个流程走下来总共耗时大约 40 秒。比起自己手动翻十几个网页效率的提升是实打实的。4. 实测中踩过的坑与排查记录4.1 上下文爆炸问题这是最早遇到的坑。MCP 工具把检索结果返回给模型时如果一次性把 10 条链接的全文都塞进上下文很快就把上下文窗口撑爆了。我的第一版实验里模型经常聊到一半就“失忆”因为前面的关键信息全被挤掉了。解决办法有两步。第一步是分层摘要摘要与观点分开放模型只接收每篇文章的“摘要 立场 质量分”原文存入本地缓存只在必要时调取全文。第二步是控制并行度不要把采集结果一次性全部暴露给模型按相关度排序后分批注入。注意MCP 工具的设计要预留“是否需要全文”这个参数。默认只返回摘要查询意图复杂或需要深度引用时模型可以再发起一次extract_text调用获取全文。这样既保住上下文空间又保留了深度分析的可能。4.2 MCP Server 超时问题MCP 的标准传输方式有 stdio 和 SSE 两类。stdio 模式适合本地开发但做服务化部署时确实会遇到超时和并发连接的问题。我经历过最蛋疼的一个场景某个数据源接口响应特别慢单次检索耗时超过 60 秒而外部 Host 的默认超时只有 30 秒。结果就是客户端先断开服务端还在吭哧吭哧跑最后报一堆错。后来做了三个处理所有外部调用统一加超时控制上限 20 秒超时走降级策略数据源接口按响应速度分优先级别快的先返回慢的异步补采Host 侧把 MCP Server 的超时参数调大同时服务端自身不做长时间同步阻塞另外要把工具设计成幂等的。模型可能会因为网络抖动重复调用同一个工具如果工具有副作用比如写文件、发消息重复调用会很危险。检索类工具天然幂等但如果你在 MCP 里挂了一些操作类工具务必让它们支持幂等否则早晚出事。4.3 证据冲突时的策略最经典的问题两个来源一个是官方文档一个是资深从业者的实测分享观点恰好相反。这时候信谁一开始我偷懒把冲突交给模型判断。结果有时候模型根据“语气强弱”来选边站谁写得更自信就信谁这显然不科学。改成规则优先之后系统按这样的优先级处置冲突一手实测数据优先于二手转述官方技术文档与一手实测冲突时看场景匹配度文档描述的是通用设计实测可能针对特定条件时间更新的一手数据优先于时间更早的总结性观点双方都有依据时保留分歧不强行决策针对这个场景的实践技巧评估信息时先看数据类型再看来源渠道最后看发布时间。数据类型的权重高于渠道因为“一个普通用户自己的实测数据”虽然渠道不算权威但它是一手经验对于某些决策来说比官方文档更贴近真实使用情况。4.4 输出不稳定与幻觉残留用惯了原始的 MCP 工具链都有一个体会同样的工具结果多问几次模型回答的细节经常不一样偶尔还会冒出检索结果里根本不存在的“事实”。这其实是模型在自由生成时的标准问题但在决策系统里是致命的。决策者依据你给的数据做选择结果数据本身不稳定这不靠谱。我的处理办法是在决策层加了事实一致性检测把模型产出的 JSON 里的每条依据回源到原始检索证据里做比对如果摘要内容在原文里找不到明确支持就标记为“待验证”不允许进入核心结论。这个一致性检测本身也是一种工具调用它在更大模型或规则逻辑层执行专门审核输出。加了这层之后系统输出的核心结论基本能做到“每一句都有出处每一个结论都在证据链上有锚点”。虽然做不到 100% 杜绝幻觉但至少把幻觉关进了笼子里不让它接近决策主干。4.5 踩坑速查表现象根因解决方案模型多次回答细节不一致自由生成缺乏约束决策层强约束 JSON 输出 回源检验上下文越来越长然后失忆全量结果注入分层摘要默认只给摘要和分析维度工具调用经常超时Host 端超时设置短服务端有慢调用超时控制 快速源优先 降级策略搜索结果里有大量营销内容检索排序被 SEO 干扰质量分过滤低质量来源只能做旁证不同来源观点冲突被忽视只做了拼接加工没做立场聚合证据链模式立场聚合 冲突处置策略JSON 解析偶尔失败模型输出格式漂移外部校验逻辑 不合法就重新生成5. 这套系统现在能做什么以及我的一些新理解5.1 边界它不适合做什么长到这个规模之后反而是它的局限性越来越清晰。它不适合做实时交易型决策比如股票买卖点位的判断。采集层的延迟决定了它拿到信息时市场可能已经变了。它也不适合处理高度依赖隐性经验的判断比如团队管理里某个微妙的人事决策这类问题根本没有公开证据可采集。系统可以做的是把公开可见的信息梳理清楚给决策者节省时间但最后拍板所需的那部分“手感”仍然来自决策者自己。还有一个边界是信息源的盲区。任何检索方案都只能覆盖能被搜索引擎收录的信息。真实情况中大量的关键信息存在聊天记录、会议纪要、私人文档里这些它拿不到。所以系统的定位始终是“辅助决策”不是“替代决策”。5.2 对 MCP 和 AI 工具链的一点观察从这个项目里我对 MCP 生态有了更实际的理解。MCP 解决的是互操作的问题它让工具不再是某个模型的后花园而是整个 Agent 生态的公共设施。这是它对的方向。但协议层只解决“能不能调用”不解决“调用之后怎么用”。工具输出的质量评估、多源整合、证据权衡这些都要在上层业务逻辑里自己做。这也是为什么“套壳 MCP”会长成研究决策系统的深层原因当一个 Agent 真正进入真实工作流时它需要的不是一个工具而是一条有质量控制的处理链。工具是链条上的一环但链条本身需要业务设计和领域规则来打磨。如果你也想从工具封装往系统方向演进我建议不要在协议上花太多心思多把时间放在信息质量和决策逻辑上。协议是公共的标准信息处理和判断逻辑才是你系统的真正壁垒。5.3 如果你想复现建议从哪开始别一上来就想要完整决策系统会消化不良。建议按三个阶段走。第一阶段只做一个检索类 MCP Server摸清工具声明、参数校验、Host 接入这些基础操作目标是把模型以外部的检索能力。第二阶段加一个质量评分和立场标注模块让检索结果带上结构化标签这阶段你的工具已经开始有点“脑子”了。第三阶段再把多源交叉验证和决策输出模板接上完成从工具到系统的蜕变。每个阶段的工作量都不大但每完成一个阶段你都会对 AI 工具链有更深的理解。尤其是第二阶段它几乎是整个系统的分水岭。我个人在实际操作中最大的体会是工具和系统的分界线不在于代码复杂度而在于有没有形成“信息采集 - 质量评估 - 证据整合 - 行动建议”的闭环。没有闭环再多的 MCP 工具也只是一堆高级 API有了闭环哪怕底层只是几个简单的函数封装它也已经是一个能真正辅助决策的系统。最后再分享一个小技巧给系统起名字的时候不要叫“XX 助手”或者“XX Agent”叫“XX 研究决策系统”反而会让你在设计时更严肃地对待信息的质量评估和决策边界。名字会影响设计预期这个我实测下来很准。你的工具长成什么很大程度上取决于你把它当成什么来对待。