这个项目最开始其实特别不起眼说难听点就是个“套壳”把几个搜索引擎的API、一个网页抓取服务、一个本地文件读写工具统一包成一个MCP Server丢给大模型用。可三个月之后再回头看它已经变成了一套带有检索、筛选、交叉验证、置信度评估、最终推荐的研究决策系统。MCP本身只是协议层的东西按理说它不该“长”出业务逻辑来但现实是它确实长出来了而且长得还挺顺理成章。这篇文章就从头复盘一下这个“套壳MCP”到底经历了什么才会一步步变成研究决策系统。我尽量讲得实在一点把中间层的设计、上下文管理的权衡、评估体系的搭建还有那些踩过的坑都说清楚。不管你是打算做个简单的MCP工具还是想让MCP承担更复杂的任务这里面都有可以参考的东西。1. 项目是怎么长歪的从一个套壳MCP说起1.1 最初的“套壳”长什么样三个月前的第一版功能列表用一行字就能写完大模型没有实时信息所以我把搜索和网页抓取能力用MCP暴露给它。核心就三个工具web_search、fetch_page、save_note。大模型收到用户问题后自己决定要不要调用搜索拿到搜索结果后自己去抓网页最后把要点存到本地Notes里。整个过程全部由模型自由发挥服务器端不掺和任何判断。当时选MCP而不是直接给每个模型写Function Calling纯粹是出于一个很自私的理由我不想在四个不同的模型API里各写一遍工具定义。MCP等于把我这边的工具调用逻辑标准化了模型那边只要能连MCP Client就能拿到我这边同一套工具。今天换个模型配置不用动明天加个工具模型那边也感知不到代码变化。说白了最开始选MCP就是图的省事。这一版的运行模式可以概括为“模型主导、工具执行”。模型说搜什么就搜什么抓到什么网页就抓什么网页存不存Notes也看模型心情。在大多数简单问答场景下这套东西是够用的。你问“2025年的某个技术大会到底哪天开”模型调一下搜索抓两个页面答案就出来了。1.2 为什么一开始非要选MCP这里稍微展开说下MCP是什么因为它决定了后面所有演化的方向。MCP全称是Model Context Protocol模型上下文协议可以理解成给大模型和外部工具之间定的一套标准USB接口。以前每个模型厂商都有自己的插头你得给ChatGPT配一个转接头给Claude配一个转接头给国产模型再配一个转接头MCP出来之后大家都用同一个插头工具方只要做一次适配所有支持MCP的模型都能用。这套协议里最核心的几个概念就是工具、资源和提示词。工具是给模型执行的动作比如搜索、抓网页、读文件资源是暴露给客户端去读的静态数据比如文档、表格、目录列表提示词则是预先写好的模板负责引导模型按某个套路干活。最初我基本只用工具这一个能力资源和提示词都是后面被逼着用起来的。很多做MCP的人和我一样一开始都是只盯着Tools觉得这就够了后来才发现资源的用处被严重低估了。还有一点MCP Server不挑语言Python、Node、Go都能写只要有官方SDK或者按JSON-RPC 2.0自己实现一版就行。我当时图省事用了Python的mcp官方SDK几行代码就能暴露一个工具。这也为后面快速迭代打下了基础毕竟改一个工具函数比改一套独立服务要快得多。1.3 失控的信号用户开始问“你推荐哪个”真正的转折点是第一批真实用户用了一周之后。他们不再满足于“给我几篇资料”而是开始问“你推荐哪个”“如果只能选一个你选什么”“结合我们目前的约束条件直接给结论”。这类问题一出现原本的套壳架构就撑不住了。原因很简单给用户罗列五个候选方案和五个来源看起来信息充分实际上是把判断负担全甩给了用户。我真正想要的输出是一个带倾向性的结论在A和B之间综合考虑成本、维护难度、团队熟悉度之后系统建议选哪个理由是什么风险在哪里。而要做这种研究型决策单靠大模型临场发挥是不行的因为模型每次调用只能看到当前窗口里的内容它没法像人一样先收集资料把资料归档过几天再回来综合判断。于是这个套壳MCP开始往“系统”的方向转变这已经完全超出了套壳的范畴。2. 拆解“研究决策系统”的成型过程不是设计出来的是长出来的2.1 从单轮调用到多阶段管线第一件事是把原来“模型自由发挥”的模式改造成固定阶段的研究管线。我参考了现实里做调研报告的工作方式先收集线索再筛选信源然后深读关键材料接着做交叉验证最后给出结论。对应的系统也划分成了几个阶段检索阶段根据问题拆解出多个搜索词分别去搜收集原始链接和摘要。筛选阶段根据标题、摘要、域名权重过滤掉明显不相关的链接。深度阅读阶段对筛选后的关键页面抓取正文生成摘要。交叉验证阶段把不同来源的信息放在一起比对找矛盾点和共识点。决策阶段综合前面所有材料按预设的评估维度打分给出推荐结论。每个阶段在MCP Server里就是一个或者几个工具模型按照一套流程依次调用。这一步做完套壳的性质就变了它不再是“给模型加个手”而是“给模型加了一套工作方法”。工具还是那些工具但组合方式从自由发挥变成了流水线。有人可能会问为什么不直接让模型自己规划这五个阶段答案是模型会的但不是每次都会。同样的模型状态好的时候能规划得很好状态差的时候上来就抓一堆垃圾页面。把管线固化在服务器端等于把“靠谱”这件事从模型身上剥离出来变成系统层面的确定性。这也让我后来深刻理解了一件事研究决策系统的核心不是模型能力而是流程约束。2.2 关键转折点中间结果落盘与上下文管理管线化之后立刻遇到一个致命问题上下文放不下了。检索阶段返回几十个链接深度阅读阶段每个页面正文动辄上万字如果全部塞给模型窗口早就爆了。MCP官方文档里有一个很关键的设计理念服务器只提供数据但如何选择性地把数据暴露给模型是服务器端要主动控制的事。解决办法是引入中间结果存储。所有阶段的中间产物都不直接写进对话上下文而是落盘存储做成可检索的、独立的资源。第一阶段生成的候选链接存进表格第二阶段筛选出来的重要页面单独存成Markdown文档第三阶段的阅读摘要按来源编号保存。模型在每个阶段看到的只是这个阶段最必要的输入和可操作的下一步动作。这里我用到了MCP的资源能力。以前我总觉得MCP的Resource是个鸡肋工具不够用吗为什么要暴露资源真实场景里才发现研究管线的中间结果是天然的资源。它们既不是给模型执行的工具也不是临时性的对话内容而是一类可以反复读取、按需调用的结构化数据。比如决策阶段模型只调用read_dataset读完筛选结果而不需要从对话历史里翻找早期内容。这样一来上下文窗口的压力大大下降模型每阶段的输入都变得精简可控。落盘方案本身也很简单没有上数据库就是本地目录加JSON文件。搜索阶段的结果存成round_1_candidates.json阅读阶段存成round_2_notes.md。简单可靠中途崩了也能从文件恢复。到后面如果需要支持多人协作再考虑迁到独立的存储服务也不迟。2.3 评估与置信度让系统敢说“不确定”第三个关键变化是引入了置信度和评估维度。这是“研究决策系统”和“高级搜索工具”之间最明显的一道分水岭。普通搜索工具把十条链接排好序给你就完事了研究决策系统则必须回答一个问题给出这个结论之前你对这个结论有多大的把握依据是什么证据链是否完整我在Server端设计了一个generate_assessment工具让模型在进入决策阶段之前先按几个固定维度给出评估信息覆盖度关键信源是否都已覆盖有没有明显缺失的维度。来源一致性多个来源之间是否达成共识还是存在显著分歧。时效性材料是否足够新有没有过期的可能。可验证性核心结论能否通过一级信源验证。综合置信度一个0到100的分数低于60分时系统要明确告诉用户“这个结论不建议直接用于决策”。这一层设计最反直觉的地方在于它不是在追求“结论更聪明”反而是在逼系统承认自己不知道。可实际跑下来效果很好。因为用户需要的并不是一个永远自信的AI而是一个能说“这个答案我只能有六成把握因为一手信源太少主要依据来自二手博客”的系统。置信度机制一旦建立整个系统的可信度反而大幅上升。3. 核心实现细节三个层到底怎么搭3.1 工具层每个工具只做一件事整个系统里最容易写坏的就是工具层。很多人做MCP Server时喜欢把工具做得又大又全一个函数里又是搜索又是解析又是存储。这样短期省事但后期灾难。搜索失败时你分不清是哪个环节出了问题模型调用时也容易因为参数太长而报错。我这边反着来每个工具只负责一件极小的事情。拿检索链举例拆成了四个独立的工具search_engine_query只执行一次搜索返回标题链接摘要不做任何过滤。chunk_filter_candidates传入一批候选链接按规则过滤返回保留/剔除的原因。page_fetch_markdown抓取单个页面只输出正文转Markdown的结果。extract_key_points基于页面正文输出固定格式的要点列表。这种颗粒度的好处有三个。第一可调试。哪个环节返回了垃圾数据一眼定位。第二可复用。page_fetch_markdown不光给研究管线用任何时候模型需要读网页都可以直接调。第三可测试。每个环节都是纯函数式的输入输出我可以在不连接大模型的情况下单独跑一遍全链路测试。工具定义时描述要写得极其具体。MCP工具的描述不是给用户看的是给模型看的。同一个search_engine_query如果描述写成“搜索互联网”模型调用时可能不知道什么时候用如果写成“当用户需要最新信息、实时数据或外部网页内容时调用每次搜索返回最多10条结果”模型就很容易判断适用条件。这个细节我个人认为是整个MCP工程里性价比最高的一项优化。3.2 决策层把“研究”变成可计算流程决策层是这套系统最核心的部分它负责把开放式的研究过程变成可计算、可复现的判断流程。我的实现思路是不是在对话里让模型“想一想然后回答”而是让模型按固定的节奏产出一份结构化的决策报告。具体来说决策阶段有一个专用的提示词模板里面规定了报告的结构背景重述、候选方案列表、评估维度、各维度打分、矛盾点罗列、最终建议、置信度说明。这几个模块必须按顺序产出缺失哪个模块Server端会直接报错要求补齐。评估维度这块我允许用户动态传入而不是写死在系统里。技术选型场景默认用“成本、上手难度、社区活跃度、扩展性、风险”采购决策场景则可能换成“报价、交付周期、售后响应、合规、可替代性”。维度变化时不需要改代码只需要在问题里带上维度列表系统就会把它作为决策框架使用。可计算性还体现在中间产物上。候选方案会统一转成标准格式包括名称、来源、关键论据、正反方观点。这样做是方便后续交叉验证也方便打分。打个比方这就像把一堆散乱的投资建议整理成同一张Excel表格每个方案一行维度是列打分明明白白不存在模糊地带。3.3 接口层让大模型按节奏调用有了工具层和决策层还差最后一步让大模型愿意按节奏调用。这层看似简单实际上决定了管线能不能顺利跑完。MCP Client在模型那边会暴露工具列表如果模型乱序调用、跳过关键环节管线就形同虚设。我用了两个手段来控制节奏。第一在不同的阶段只暴露当前阶段相关的工具。检索阶段时Server端只向客户端暴露搜索相关工具进入评估阶段时才暴露评估相关工具。MCP本身支持动态更新工具列表我就在管线推进时主动刷新。模型看不到的工具自然就不会误调用。这个做法的好处是模型的注意力被强制集中在本阶段任务上不容易跑偏。第二利用提示词模板块。MCP支持在Server端注册提示词模板客户端可以通过prompts/list拉取。我把每个阶段的引导语都封装成模板阶段切换时要求模型必须重新加载对应提示词再继续。比如筛选阶段加载的提示词里会强调“宁缺毋滥不要为了凑数保留低质量信源”交叉验证阶段则强调“必须指出来源间的矛盾不能只选取与预设结论一致的内容”。模板化管理让我可以随时调整整个系统的工作风格而不需要去改模型的系统提示词。3.4 实操参数上下文预算与评分公式说完层再给一版实际跑通的参数供参考。这些参数不是拍脑袋定的都是压力测试之后调出来的。最大候选链接触发数25条。超过会强制截断因为太多了后面的深度阅读根本看不过来太少了又容易漏掉关键信息。深度阅读页面上限8个。一次决策最多深读8个页面按权重排序取前8其余只保留摘要。单页正文上限12000字符。超长页面截断只保留前12000字符基本能覆盖正文主体又不会撑爆Token预算。置信度阈值65分。低于65分时系统必须在回复开头声明低置信度并给出需要补充的信息清单。评分公式也分享一个简化版。某项维度的分数不是模型直接拍出来的而是结合证据强度计算维度得分 基础判断分 * 0.4 信源强度分 * 0.3 一致性分 * 0.2 时效性分 * 0.1配合这套公式模型就不是在凭空打分而是在做加权计算。基础判断分来自模型对材料的理解信源强度分看是不是一手资料、域名权重是否够高一致性分看多个来源的结论是否趋同时效性分看发布时间距今多久。总分落在0到100之间再由分数决定最终建议的置信区间。这套参数用在大多数调研场景下都够用。如果你要处理更复杂的金融研报、医学临床信息那阈值和权重都得改我这里只是给出一个平衡性比较好的起点。4. 从配置到跑通一个完整的决策流程实录4.1 环境与MCP Server配置要点整个系统跑起来之后最常被人问起的是两个问题MCP Server到底怎么配以及哪一步最耽误时间。配置方面因为MCP现在已经成了事实上的标准几个主流的客户端都支持直接在配置文件里声明MCP Server。我本地用的是一个通用的配置结构路径和参数按自己项目改即可{ mcpServers: { research-server: { command: uvx, args: [research-mcp-server], env: { SEARCH_API_KEY: your-key, OUTPUT_DIR: ./research_output, MAX_CANDIDATES: 25 } } } }这里有几个容易踩坑的点。第一环境变量里的密钥千万不要硬编码进仓库用环境变量注入。第二command字段建议用uvx或者npx这种包运行器省去手动管理虚拟环境的麻烦。第三OUTPUT_DIR一定要指定不然中间落盘文件会写到当前目录目录一乱后面排查问题就头疼。另一个很实用的排查技巧先用MCP Inspector这类工具把Server单独跑起来直接在调试界面里测试工具调用确认搜索、抓取、评分等工具全部返回正常再接大模型客户端。大部分人遇到“Codex找不到MCP”或者“模型一直报工具不存在”的问题十有八九是Server根本没起来或者环境变量没注入成功。先用调试工具验证一遍能排除掉一大半问题。4.2 一个真实案例技术选型研究跑一个实际案例来看这个系统怎么工作。假设问题是“我们团队想做本地优先的文档库需要支持全文搜索和Markdown编辑想在A、B、C三个开源项目里选一个综合维护活跃度、协议风险、二次开发成本给出建议。”检索阶段系统会拆出两组搜索词一组是“项目A markdown 全文搜索 自托管”另一组是“项目A license 协议 风险”。之所以要拆是因为一次搜索往往只能覆盖一个维度维度混在一起结果质量会明显下降。第一阶段最终返回约25条候选链接。筛选阶段系统会根据摘要和域名去重、剔除明显过时的内容保留大概12条。深度阅读阶段抓取8个页面包括官方文档、GitHub仓库主页、两个社区评测帖。交叉验证阶段发现了一个关键矛盾项目C在Reddit上的社区活跃度很高但实际GitHub提交频率很低。系统在矛盾的标记里明确写了一句“社区讨论热度与代码维护活跃度不一致建议以代码仓库真实数据为准。”决策阶段系统按“维护活跃度、协议风险、开发成本”三个维度分别打分。项目A在协议风险上得分最高因为它是宽松许可证项目B功能最全但最近三个月提交频率下降明显项目C社区呼声最高但一手证据偏弱。综合加权后系统给出的建议是项目A置信度78分并附带一句提醒“如果团队未来强烈依赖导出功能建议再关注项目B的路线图该项存在隐性风险。”这就是整套系统该有的产出有结论有理由有矛盾点标记有置信度。最重要的是这些不是模型一次性生成的而是经过五个阶段每一阶段都有据可查复现成本极低。4.3 踩坑实录与排查技巧从套壳到决策系统一路踩坑踩出几个很有代表性的问题整理成表格供参考。问题现象根本原因解决办法模型跳过检索阶段直接胡编工具列表一次性全暴露模型不知道搜索何时触发分阶段动态更新工具列表只暴露当前阶段工具中间结果文件丢失、决策时找不到输出目录不固定且文件命名带时间戳导致混乱固定输出目录按轮次命名每轮维护一个索引文件抓取的网页正文夹杂大量导航和广告直接抓HTML后转文本没做正文提取引入只提取正文的解析逻辑保留标题和段落结构交叉验证阶段模型顺着用户预设观点走提示词里没有强调“必须指出矛盾”在提示词模板中强制要求列出矛盾点否则视为报告不完整搜索接口偶尔限流导致整个流程中断单次失败直接抛异常没有重试机制给HTTP类工具加指数退避重试三次失败才真正放弃模型同时发起多个写文件操作导致并发冲突工具本身不是线程安全的在文件写入工具上加进程级锁串行化写操作这里我想多说一句排查技巧里最值钱的其实不是你掌握了多少调试命令而是你给每个中间环节留下了足够的可观测性。我把每个阶段的关键决策都追加到一条日志里包括筛选时剔除某个链接的具体原因、打分时各维度的输入值。出了问题打开日志就能还原当时模型的每一步判断。没有这一步系统一旦跑偏排查成本会非常高昂。5. 复盘什么项目适合长成这样什么不适合5.1 五个判断标准经历这次演化之后我对“要不要把MCP做成研究决策系统”这件事有了一个比较清醒的判断。并不是所有套壳MCP都该长成决策系统甚至可以说大部分MCP项目就应该停在套壳阶段。下面这五个标准至少满足三条再考虑往决策系统方向演进用户的输出物是一种“结论”而不只是“信息”。如果用户拿到搜索结果就够了那搜索套壳就到头了。问题具备多源交叉验证的必要。单一信源能给答案的问题不值得上五阶段管线。答案一旦错误代价是可感知的。技术选型错了、采购选错了、方案推荐错了后续成本很高才有必要引入评估与置信度机制。输入信息是动态的、时效性强的。如果答案是静态知识大模型自己就是专家不需要研究过程。你有意愿维护一套中间状态的管理机制。很多人忽略了这条决策系统需要管状态管失败管恢复不维护的话流程很快就会腐化。反过来如果只是给企业内部数据库写个查询接口或者包装一下内部API老老实实做个套壳就很好。用决策系统的复杂度换一个简单查询场景纯属杀鸡用牛刀。5.2 成本账Token、延迟、复杂度继续劝退一波。研究决策系统的成本比大多数人预想的要高。Token消耗上一次完整研究流程平均烧掉2万到4万Token其中大头在深度阅读阶段。相比套壳MCP动辄几百Token的调用这完全不是一个量级。延迟上全流程跑完通常在40到90秒之间因为要连续执行搜索、抓取、多轮生成。用户如果只想快速找个答案这个延迟是没法接受的。维护复杂度上从单文件套壳变成多阶段系统代码量至少翻三倍测试量更是翻五倍不止。我保留了完整的回归测试集因为改一处评估逻辑很可能影响后续所有决策案例的输出格式。没有自动化验证这套系统根本不敢频繁迭代。所以上这个系统之前先算清楚这笔账。如果结论错了代价小或者用户就是想在几秒内拿到参考资料那决策系统反而是伤害体验的。5.3 一点个人体会写到这里想用我在实际维护过程中最深的一条心得收尾。MCP协议本身确实很轻轻到给任何人解释十分钟就能上手写工具。但它真正的威力恰恰是轻之外的那一层当工具、资源、提示词、上下文管理这些标准能力组合在一起你就有了一个可以把“做事方法”固化下来的沙盒。我的项目从套壳演进成研究决策系统本质上不是协议在推着我走而是用户的需求一次次提出了新的问题MCP只是很争气地接住了这些问题。如果你也在做一个看似简单的MCP套壳我的建议是不急着按研究决策系统来设计先把最简单的那一版跑通然后用真实用户的问题去蹂躏它。当套壳连续三次回答不了“那你推荐哪一个”的时候你就知道下一步该往哪长了。那时候MCP的协议基础已经帮你把路铺好了你只需要顺着走下去。