被同事问得最多的一句话是“你不是说只做个套壳MCP吗怎么越写越像一个研究决策系统了”起先我还会解释几句后来问的人多了我干脆把整个演进过程重新捋了一遍发现这事本身就挺有意思明明一开始只打算给AI加一个搜索能力结果一层一层往上补补出了一个带任务规划、多源验证、结果沉淀的小系统。今天这篇就把我的设计思路、关键节点、踩过的坑一次说清楚给准备从MCP入手做工具的同行一个参考。先交代背景。这个项目的起点非常朴素团队内部想把已有的检索接口、知识库和几个第三方数据源接入到日常使用的AI助手里让它在回答问题时能查真实资料而不是凭空生成。当时选MCP就是因为它是当前最主流的模型上下文协议生态成熟、接入成本低把现成API“套一层壳”就能让AI调用。我预期半天搞定结果做着做着发现AI能搜索和AI能做好一次研究中间隔着的距离比想象中大得多。这篇博文不吹“套壳”有多高级只讲从套壳到研究决策系统中间到底发生了什么。1. 先说初衷一个MCP“套壳”到底想解决什么问题1.1 所谓“套壳MCP”通常长什么样很多朋友一开始接触MCP第一反应都是“这不就是个接口封装吗”。这种理解不准确但也不是全错。MCP的核心价值是把AI应用与外部工具、数据和模板之间的连接方式标准化你可以把它理解成AI世界里的USB接口只要两边都遵守同一个协议模型就能统一调用各种千奇百怪的服务不需要为每个服务单独写一套私有连接代码。而“套壳MCP”最常见的形态就是把团队已有的HTTP接口、内部数据库查询、第三方数据API封装成MCP Server暴露出的工具Tool。比如我最初做的版本核心就是这样一个东西from mcp.server.fastmcp import FastMCP import requests mcp FastMCP(research_search) mcp.tool() def search(query: str, top_k: int 5) - str: 搜索指定关键词返回结果列表 results requests.get( http://internal-search-service/search, params{q: query, limit: top_k}, timeout10 ).json() return \n.join( f[{item[title]}] {item[snippet]}\n来源: {item[url]} for item in results[items] ) mcp.tool() def fetch_article(url: str) - str: 获取指定链接的正文内容 ...用过MCP SDK的朋友应该很熟悉这种写法。声明一个mcp.tool()装饰器定义函数名、参数类型、返回字符串AI模型就能在对话中按需调用。整个过程技术难度不高和写普通Python函数差不多这也是MCP能迅速普及的原因——它把“让AI调用工具”的门槛降到了几乎为零。这个阶段的项目定位非常清晰给AI接上外部信息源。目标用户就是我们自己团队里需要查资料做技术调研的工程师使用场景也从一开始就限定在“能联网搜索的问答助手”。1.2 原型跑通之后问题来了套壳版本上线第一天效果确实比裸模型强不少。问“某框架最新版本有哪些新特性”这类问题AI会主动调用搜索、查官网、读文档回答里开始出现真实链接和具体版本号。当时我还在群里颇为得意觉得MCP套壳这条路走对了。但用了大概一周问题开始集中暴露。团队里有人拿它做“某技术方案与另一技术方案的选型对比”时AI的表现就非常不稳定有时只搜了一两个关键词就急着下结论有时搜了一大堆资料但抓不住重点更有好几次它把不同来源里互相矛盾的数据摆在一起既不验证也不说明直接丢给我一份看似完整其实经不起推敲的结论。那时候我突然意识到一个扎心的事实搜索只是一个动作研究是一整套流程。套壳MCP只解决了“AI能调用搜索工具”的问题完全没有触及“AI如何完成一次可靠研究”的问题。后者需要任务理解、拆解、规划、调度、验证、权衡、沉淀而这些能力一个孤零零的搜索工具是不可能提供的。2. 从套壳到系统研究决策到底需要哪些“超出预期”的能力2.1 单工具调用和“研究任务”之间隔着一整个流程如果把一次正经的研究任务展开流程大概是这样的先理解用户的真实需求把模糊的大问题拆成若干可以独立验证的子问题然后针对每个子问题多路检索资料从不同来源中提取观点和数据再做交叉比对看是否互相矛盾筛选出可信度较高的证据最后综合各方信息形成有依据的结论并将整个推演过程留下可追溯的记录。这个过程和“AI调一次搜索工具”之间差得非常远。最直观的例子用户问“国产新能源汽车的电池技术路线未来两年谁更有潜力”。这个问题表面是一个问题实际上至少包含“当前主流电池技术有哪些”“各路线近两年的关键进展”“产业链成熟度对比”“头部企业的布局方向”“研究机构对趋势的判断”等五六个子问题。任何一个子问题都需要单独的检索和验证任何一个结论都需要多个独立来源支撑。如果只给AI一个搜索工具它很容易陷入两个极端。一种情况是浅尝辄止搜到两三篇看起来相关的文章就开始长篇大论把“相关”当成“充分”结论自然偏颇。另一种情况是低水平重复模型反复搜索同一批关键词每次都返回类似内容因为缺少全局状态管理它不知道自己已经查过什么、还缺什么。2.2 缺口一任务规划与状态管理做套壳MCP的时候每次工具调用都是独立的模型自己决定下一步做什么没有任何机制保证它能系统地覆盖研究目标的各个维度。一旦任务复杂度上来模型就会“迷路”在不同子问题之间跳来跳去或者在某一个分支上钻牛角尖。解决方向是在系统里增加一个规划器。研究任务启动时先把用户的初始问题交给规划器让它产出一组带依赖关系的子任务。子任务要有明确的状态待执行、执行中、已完成、失败、被跳过。整个任务的生命周期也要有独立的存储不随单次对话结束而消失。这样一来AI面对的不再是一个平面上的“要不要再搜一下”而是一张可以随时查看进度的任务地图。这套做法本质上就是把传统软件工程里的任务拆解和状态机思想搬进AI应用层。规划器不能只靠模型自由发挥必须有约束。我后来在系统里给每个研究任务都设置了深度和规模上限比如最多拆出多少个叶子子任务、每个子任务最多调用多少次检索、整轮研究的总时长预算是多少。没有这些约束长任务很容易失控输出一堆重复信息。2.3 缺口二多工具调度与编排能力单一工具的研究模式是“模型→工具→模型→工具”的线性对话看起来自然但效率很低。真实的研究流程需要并行检索多个来源、对同一主题做多角度验证、把不同工具的结果组装在一起互相印证。这意味着系统层必须有一个调度器而不是把调度权完全交给模型临时发挥。调度器在三层意义上介入。第一层是并发控制同一时间最多允许几个检索请求在跑超出部分排队防止把底层服务打爆。第二层是去重与缓存同一个检索词十来个子任务里很可能重复出现完全没必要每次真的去搜一遍命中缓存直接返回。第三层是超时与重试策略外部接口偶尔抖动不能因为一次失败就让整个子任务挂掉该重试的重试该降级的降级。这些功能听起来都很“基础设施”但恰恰是它们决定了系统在高负载下是稳定还是在用户面前连环报错。只做套壳的时候根本不会考虑这些问题可一旦要承载完整的研究任务它们就变成了刚需。2.4 缺口三证据验证与可信度控制这是我从“套壳心态”转向“系统心态”最关键的一步。套壳版本里AI把搜索到的内容当论据直接写进回答。但网络资料的质量参差不齐一条刚发布的个人博客、一篇带明显倾向的推广文、一份过时的文档对模型来说都是平等的文本它没有能力自动判断权威性和时效性。研究决策系统必须在证据层面做控制。我的做法是在检索和汇总之间加一个独立的验证模块从多个来源抽取出关于同一主题的关键信息先做程序层面的实体对齐、数字比对、发布时间过滤发现明显冲突时把冲突内容单独标记出来再决定是追加检索还是交给模型解释。绝不能跳过验证直接把最热门的结果交给模型当“事实”。这个模块的价值在对比测试中非常明显。同样一个问题套壳版本给出的回答里经常混着过时数据和前后矛盾的说法而带着验证器的系统版本会把“多个来源一致”的结论和“存在争议需要进一步确认”的部分明确分开用户一眼就能看出哪些结论可以放心用。2.5 缺口四结果沉淀与决策痕迹保存普通问答场景里AI回答完就结束了。但研究决策场景不一样用户可能会根据这份调研结论去做后续安排过程中需要回溯、需要引用、需要确认某个判断到底基于哪些资料。这就要求系统不能只输出一份最终报告还要把中间过程完整保存下来。我在设计里增加了任务记录层每个研究任务从创建到完成规划器生成的子任务列表、调度器的调用记录、验证器发现的冲突项、最终报告引用的每条来源全部落到库里。用户随时可以按任务ID调出“这份结论是基于哪些资料得出的”完整链路。这一步做完这个项目就不再是“带搜索功能的聊天机器人”而是一个有完整工作流和数据闭环的小型决策支持系统。3. 系统落地把研究决策流程拧进MCP协议里3.1 设计原则什么放Tool、什么放Resource、什么放Prompt研究决策系统模块很多但在MCP协议框架内设计原则可以简化成一条有副作用、需要执行动作的做成Tool只读数据、用来提供上下文的做成Resource固定流程、需要复用的指令模板做成Prompt。举个例子。启动一个研究任务、查询任务状态、获取最终报告这三个都必须做成Tool因为每次调用都会触发后端服务执行动作。而团队内部知识库里的行业综述文档、历史项目的复盘报告这些是静态数据做成Resource更合适模型可以按需读取但不会因为它们产生副作用。至于报告的结构模板比如“请按照背景、现状对比、证据链、结论与建议四段式输出”固定且通用放在Prompt里最省事。初学MCP的朋友容易犯一个错误把所有东西都做成Tool不管它是动态操作还是静态内容。结果就是Tool列表膨胀到几十个模型选工具时反而无所适从。把静态数据、固定模板从Tool里剥离出去Tool数量立刻下降模型决策负担也小很多。3.2 核心链路实现规划-调度-验证-沉淀整个系统的运行链路是固定的收到用户问题后先启动研究任务规划器把问题拆成子任务调度器按依赖关系执行一批子任务每个子任务的结果进入验证器做可信度处理全部完成后汇总成报告并保存。MCP Server在这条链路里主要承担“对外的门面”真正的业务逻辑放在独立的编排服务里。这里有一个我特别想强调的设计决策不要把编排逻辑塞进MCP的tool函数内部。MCP Server适合做薄薄的一层协议适配如果直接把任务循环、并发控制、状态推进全部塞进mcp.tool()装饰的函数里短期内能跑但一旦系统出问题你会在协议适配层和业务逻辑层的边界上反复拉扯调试成本极高。我最终对外暴露的MCP Tool非常收敛核心就三个start_research、get_task_status、get_report。所有复杂流程都在编排服务里完成MCP这层保持轻薄。mcp.tool() def start_research(question: str, area: str general, max_depth: int 3) - str: 启动一次研究任务返回任务ID task_id orchestrator.start(question, area, max_depth) return f研究任务已创建task_id{task_id} mcp.tool() def get_task_status(task_id: str) - str: 查询研究任务当前执行进度 status store.get_status(task_id) if status is None: return 任务不存在请检查task_id return f当前状态: {status.state}完成子任务: {status.finished}/{status.total}进度: {status.percent}% mcp.tool() def get_report(task_id: str) - str: 获取研究任务最终报告未完成则返回进度提示 report store.fetch_report(task_id) if not report: return 报告尚未生成请先查询任务状态 return report为什么启动任务后返回task_id而不是直接返回研究报告因为一次完整的研究任务可能耗时几十秒甚至更久如果tool函数同步等待所有子任务跑完再返回MCP请求会被长时间占用容易导致客户端超时。异步任务ID模式更稳创建任务后立即返回客户端通过轮询状态接口获取进度跑完后拉取报告。这个模式在研究决策这类长耗时任务里几乎是必须的。3.3 规划器让“怎么研究”这件事变得可管理规划器是研究决策系统的大脑。它每次运行时会接收用户原始问题输出一份结构化的任务清单。为了保证输出稳定我给规划器定义了严格的JSON Schema子任务必须包含描述、类型检索型、对比型、验证型、总结型、依赖关系、状态四个字段。规划器用两步走的方式避免模型自由发挥。第一步调用模型生成候选子任务列表第二步用规则引擎过滤明显不合理的项目比如和主问题无关的跑题项、粒度太碎不值得单独开工的项、重复度很高的相似项。过滤完成后剩下的合法子任务才会进入调度器排队。有读者会问为什么不直接让模型一次性生成最终的任务清单实测下来模型一次生成的质量不够稳定要么遗漏关键维度要么产生大量冗余小任务。加一道规则过滤器之后质量明显提升代价只是多了几十行过滤逻辑非常值得。3.4 调度和验证程序能做的事不要交给模型调度器的核心维护一张任务依赖图某个子任务的所有依赖都完成后才允许进入执行队列。执行时用信号量限制并发数量比如同时只跑3个检索类任务避免瞬时请求过多。相同检索词走缓存单位时间内的总检索次数也设硬上限超出的请求直接返回“配额已用尽请稍后再试”。验证器这块可能是整个系统里最不“AI”但最实用的模块。它做的事都是程序逻辑比对多个来源的发布时间、抽取出文章里的核心实体、检测数字和日期是否冲突、对指向同一结论的证据进行计数。只有程序层的初筛通过后模型才被允许对剩余内容做语义层面的综合。这样的设计传递出一个明确态度关键事实核查不能指望模型自觉。模型擅长的是总结和推理但“这两个来源的数据是否一致”“这条信息的发布时间是否太旧”这类确定性判断程序处理又快又准不应该把这类任务外包给模型去做。4. 实操中的高频问题与排查记录4.1 我遇到过的高频问题速查表研究决策系统比普通套壳MCP复杂很多运行过程中问题也是五花八门。我把最常遇到、也最有代表性的问题整理成一张表方便后来者直接对照排查。现象原因解决方案MCP请求长时间无响应客户端超时Tool函数同步等待外部服务长任务阻塞请求改为异步任务模式启动时返回task_id状态轮询任务完成后单独取结果模型反复搜索同一批关键词不往下走缺少全局任务状态模型不知道自己已检索过什么维护任务上下文子任务完成后回写摘要模型每次决策前先加载状态上下文越拉越长很快用完搜索结果以完整原文形式返回占大量token在服务端先将结果抽成标题、要点、时间、来源的结构化摘要再送给模型结论与引用证据对不上验证逻辑完全交给模型判断把交叉验证和冲突检测写成程序逻辑模型只负责解释程序标记过的差异外部接口偶尔超时导致整体失败没有重试和熔断机制给工具调用统一加超时、重试如3次退避和熔断开关多个并发子任务打爆底层检索服务调度层没有配额控制引入信号量限制并发数缓存相同检索词设置单位时间请求上限4.2 坑一把MCP当成RPC框架把长任务塞进Tool有段时间系统频繁出现客户端“卡死”排查了一下午才发现问题出在start_research这个Tool的处理方式上我一开始在里面同步等待整个任务树跑完再一次性返回最终报告。一次理想的短任务确实能跑完返回但研究任务里总有几个子任务特别慢或者某个外部接口迟迟不返回整个MCP请求就僵住了。排查时一度怀疑是MCP SDK的问题后来把请求链路拆开才意识到问题不在协议层而在Tool的编程模型。MCP的Tool调用在逻辑上应该是“一次请求一次响应”短小精悍拖着长任务不放手等待超时是必然的。改成异步模式之后就再没出现过这个问题。这个坑的教训是协议边界是设计的一部分。不能因为MCP看起来像函数调用就把所有耗时任务都做成同步函数。设计Tool接口时要想清楚每个Tool的语义边界哪些操作应该立刻返回哪些操作应该先创建任务再异步跟踪。4.3 坑二让模型直接判断“结果可不可信”最初版本的验证逻辑非常偷懒把多个来源的内容一并塞给模型让它自己判断哪些可信、哪些不可信。测试场景少的时候看起来还不错因为模型对常见的矛盾内容还是有一定敏感度的。但一旦碰到来源之间没有直接文字冲突、而是隐含数据不一致的情况模型就抓瞎了。最典型的翻车案例是让系统对比两个不同厂家的产品参数两个来源都写着“功耗降低”但一个的依据是实验室环境测试另一个的依据是实际生产环境统计。仅凭自然语言表面判断模型区分不了这种差异背后的可信度层次会笼统地把两者都当成有效证据。后来我把所有结构化校验职责从模型中剥离出来程序先做基础检查模型只负责更深层的语义分析。每个证据都会自动附加“证据来源类型”“发布时间”“是否与主流结论一致”这些程序生成的标签模型基于这些标签再决策准确率高了很多。关键原则在于凡是能代码验证的就不要让模型去“感觉”。4.4 坑三没有给研究任务设“止损线”研究决策系统还有一个特别容易忽视的问题任务爆炸。用户提一个看似简单的问题规划器拆成了二十个子任务每个子任务再触发几路检索最后导致几十个外部请求耗时和资源都远超预期。有次一个同事用系统调研“某个新出现的芯片架构方向”规划器拆出来的子任务多到排队排了几分钟部分检索接口开始限流报错整轮研究的产出质量也受影响。那次之后我给系统全面加上了止损机制最大子任务数、最大检索次数、单任务总时间预算以及最重要的——达到资源上限时的降级策略。比如“当总检索次数已超过预算但还没有形成结论时停止新检索改用已有结果生成报告并在报告中注明覆盖范围受限”。宁可交付一份明确标注边界的研究报告也不要无限膨胀下去。4.5 实测效果给了什么启示把上述几个模块全部跑通之后系统从功能上看已经完全脱离了当初“套壳MCP”的定位。有一次我用它调研“某类数据库在特定工作负载下的选型对比”整个过程中的子任务拆解合理、多个来源的冲突信息被明确标出、最终报告里每条结论都带着来源链。这绝不是因为模型变聪明了而是因为流程变严谨了规划器保证了覆盖调度器保证了效率验证器保证了可信度记录模块保证了可追溯。5. 这类项目后面还能怎么走研究决策系统做到这个阶段它的形态已经比较清晰MCP在最外层做协议标准化内部坐着一个同时具备规划、执行、验证、记忆能力的工作流引擎。这样的底座结构天然适合继续扩展方向我个人觉得有几个延伸路径很值得尝试。第一个方向是沉淀为团队通用的研究流程引擎。目前系统里的规划器、调度器、验证器都是通用模块不依赖具体业务场景。只要更换底层数据源和Prompt模板就可以把同一套流程用于行业调研、竞品分析、论文综述、政策解读等不同场景本质上是把做研究和做决策的方法论固化成了可复用基础设施。第二个方向是接入更多私有知识源让研究结论不只是依赖公开网络内容还能结合团队内部沉淀的经验文档和复盘数据形成“外部公开信息与内部私有经验互相印证”的输出机制。第三个方向是输出决策记录的可视化和复盘能力因为目前已经有完整的任务痕迹再做一层统计和视图就能让用户直观看到自己在一次决策中覆盖了哪些维度、忽略了哪些维度。最后说一点个人体会。很多人看到MCP的第一反应是“我也可以做一个套壳”这没错MCP套壳确实是低成本高回报的入门方式。但做工具和做系统是两条路套壳解决“AI能不能调用它”系统解决“AI用得好不好、稳不稳、可不可信”。如果你也打算用MCP做研究类产品我的建议是先别急着写Tool先把研究任务的完整流程画出来想清楚哪些环节该由程序控制哪些环节该让模型发挥再把流程的边界和MCP的接口对齐。工具挂载只是入场券真正决定系统价值的永远是流程设计和数据控制能力。
被同事问得最多的一句话是“你不是说只做个套壳MCP吗怎么越写越像一个研究决策系统了”起先我还会解释几句后来问的人多了我干脆把整个演进过程重新捋了一遍发现这事本身就挺有意思明明一开始只打算给AI加一个搜索能力结果一层一层往上补补出了一个带任务规划、多源验证、结果沉淀的小系统。今天这篇就把我的设计思路、关键节点、踩过的坑一次说清楚给准备从MCP入手做工具的同行一个参考。先交代背景。这个项目的起点非常朴素团队内部想把已有的检索接口、知识库和几个第三方数据源接入到日常使用的AI助手里让它在回答问题时能查真实资料而不是凭空生成。当时选MCP就是因为它是当前最主流的模型上下文协议生态成熟、接入成本低把现成API“套一层壳”就能让AI调用。我预期半天搞定结果做着做着发现AI能搜索和AI能做好一次研究中间隔着的距离比想象中大得多。这篇博文不吹“套壳”有多高级只讲从套壳到研究决策系统中间到底发生了什么。1. 先说初衷一个MCP“套壳”到底想解决什么问题1.1 所谓“套壳MCP”通常长什么样很多朋友一开始接触MCP第一反应都是“这不就是个接口封装吗”。这种理解不准确但也不是全错。MCP的核心价值是把AI应用与外部工具、数据和模板之间的连接方式标准化你可以把它理解成AI世界里的USB接口只要两边都遵守同一个协议模型就能统一调用各种千奇百怪的服务不需要为每个服务单独写一套私有连接代码。而“套壳MCP”最常见的形态就是把团队已有的HTTP接口、内部数据库查询、第三方数据API封装成MCP Server暴露出的工具Tool。比如我最初做的版本核心就是这样一个东西from mcp.server.fastmcp import FastMCP import requests mcp FastMCP(research_search) mcp.tool() def search(query: str, top_k: int 5) - str: 搜索指定关键词返回结果列表 results requests.get( http://internal-search-service/search, params{q: query, limit: top_k}, timeout10 ).json() return \n.join( f[{item[title]}] {item[snippet]}\n来源: {item[url]} for item in results[items] ) mcp.tool() def fetch_article(url: str) - str: 获取指定链接的正文内容 ...用过MCP SDK的朋友应该很熟悉这种写法。声明一个mcp.tool()装饰器定义函数名、参数类型、返回字符串AI模型就能在对话中按需调用。整个过程技术难度不高和写普通Python函数差不多这也是MCP能迅速普及的原因——它把“让AI调用工具”的门槛降到了几乎为零。这个阶段的项目定位非常清晰给AI接上外部信息源。目标用户就是我们自己团队里需要查资料做技术调研的工程师使用场景也从一开始就限定在“能联网搜索的问答助手”。1.2 原型跑通之后问题来了套壳版本上线第一天效果确实比裸模型强不少。问“某框架最新版本有哪些新特性”这类问题AI会主动调用搜索、查官网、读文档回答里开始出现真实链接和具体版本号。当时我还在群里颇为得意觉得MCP套壳这条路走对了。但用了大概一周问题开始集中暴露。团队里有人拿它做“某技术方案与另一技术方案的选型对比”时AI的表现就非常不稳定有时只搜了一两个关键词就急着下结论有时搜了一大堆资料但抓不住重点更有好几次它把不同来源里互相矛盾的数据摆在一起既不验证也不说明直接丢给我一份看似完整其实经不起推敲的结论。那时候我突然意识到一个扎心的事实搜索只是一个动作研究是一整套流程。套壳MCP只解决了“AI能调用搜索工具”的问题完全没有触及“AI如何完成一次可靠研究”的问题。后者需要任务理解、拆解、规划、调度、验证、权衡、沉淀而这些能力一个孤零零的搜索工具是不可能提供的。2. 从套壳到系统研究决策到底需要哪些“超出预期”的能力2.1 单工具调用和“研究任务”之间隔着一整个流程如果把一次正经的研究任务展开流程大概是这样的先理解用户的真实需求把模糊的大问题拆成若干可以独立验证的子问题然后针对每个子问题多路检索资料从不同来源中提取观点和数据再做交叉比对看是否互相矛盾筛选出可信度较高的证据最后综合各方信息形成有依据的结论并将整个推演过程留下可追溯的记录。这个过程和“AI调一次搜索工具”之间差得非常远。最直观的例子用户问“国产新能源汽车的电池技术路线未来两年谁更有潜力”。这个问题表面是一个问题实际上至少包含“当前主流电池技术有哪些”“各路线近两年的关键进展”“产业链成熟度对比”“头部企业的布局方向”“研究机构对趋势的判断”等五六个子问题。任何一个子问题都需要单独的检索和验证任何一个结论都需要多个独立来源支撑。如果只给AI一个搜索工具它很容易陷入两个极端。一种情况是浅尝辄止搜到两三篇看起来相关的文章就开始长篇大论把“相关”当成“充分”结论自然偏颇。另一种情况是低水平重复模型反复搜索同一批关键词每次都返回类似内容因为缺少全局状态管理它不知道自己已经查过什么、还缺什么。2.2 缺口一任务规划与状态管理做套壳MCP的时候每次工具调用都是独立的模型自己决定下一步做什么没有任何机制保证它能系统地覆盖研究目标的各个维度。一旦任务复杂度上来模型就会“迷路”在不同子问题之间跳来跳去或者在某一个分支上钻牛角尖。解决方向是在系统里增加一个规划器。研究任务启动时先把用户的初始问题交给规划器让它产出一组带依赖关系的子任务。子任务要有明确的状态待执行、执行中、已完成、失败、被跳过。整个任务的生命周期也要有独立的存储不随单次对话结束而消失。这样一来AI面对的不再是一个平面上的“要不要再搜一下”而是一张可以随时查看进度的任务地图。这套做法本质上就是把传统软件工程里的任务拆解和状态机思想搬进AI应用层。规划器不能只靠模型自由发挥必须有约束。我后来在系统里给每个研究任务都设置了深度和规模上限比如最多拆出多少个叶子子任务、每个子任务最多调用多少次检索、整轮研究的总时长预算是多少。没有这些约束长任务很容易失控输出一堆重复信息。2.3 缺口二多工具调度与编排能力单一工具的研究模式是“模型→工具→模型→工具”的线性对话看起来自然但效率很低。真实的研究流程需要并行检索多个来源、对同一主题做多角度验证、把不同工具的结果组装在一起互相印证。这意味着系统层必须有一个调度器而不是把调度权完全交给模型临时发挥。调度器在三层意义上介入。第一层是并发控制同一时间最多允许几个检索请求在跑超出部分排队防止把底层服务打爆。第二层是去重与缓存同一个检索词十来个子任务里很可能重复出现完全没必要每次真的去搜一遍命中缓存直接返回。第三层是超时与重试策略外部接口偶尔抖动不能因为一次失败就让整个子任务挂掉该重试的重试该降级的降级。这些功能听起来都很“基础设施”但恰恰是它们决定了系统在高负载下是稳定还是在用户面前连环报错。只做套壳的时候根本不会考虑这些问题可一旦要承载完整的研究任务它们就变成了刚需。2.4 缺口三证据验证与可信度控制这是我从“套壳心态”转向“系统心态”最关键的一步。套壳版本里AI把搜索到的内容当论据直接写进回答。但网络资料的质量参差不齐一条刚发布的个人博客、一篇带明显倾向的推广文、一份过时的文档对模型来说都是平等的文本它没有能力自动判断权威性和时效性。研究决策系统必须在证据层面做控制。我的做法是在检索和汇总之间加一个独立的验证模块从多个来源抽取出关于同一主题的关键信息先做程序层面的实体对齐、数字比对、发布时间过滤发现明显冲突时把冲突内容单独标记出来再决定是追加检索还是交给模型解释。绝不能跳过验证直接把最热门的结果交给模型当“事实”。这个模块的价值在对比测试中非常明显。同样一个问题套壳版本给出的回答里经常混着过时数据和前后矛盾的说法而带着验证器的系统版本会把“多个来源一致”的结论和“存在争议需要进一步确认”的部分明确分开用户一眼就能看出哪些结论可以放心用。2.5 缺口四结果沉淀与决策痕迹保存普通问答场景里AI回答完就结束了。但研究决策场景不一样用户可能会根据这份调研结论去做后续安排过程中需要回溯、需要引用、需要确认某个判断到底基于哪些资料。这就要求系统不能只输出一份最终报告还要把中间过程完整保存下来。我在设计里增加了任务记录层每个研究任务从创建到完成规划器生成的子任务列表、调度器的调用记录、验证器发现的冲突项、最终报告引用的每条来源全部落到库里。用户随时可以按任务ID调出“这份结论是基于哪些资料得出的”完整链路。这一步做完这个项目就不再是“带搜索功能的聊天机器人”而是一个有完整工作流和数据闭环的小型决策支持系统。3. 系统落地把研究决策流程拧进MCP协议里3.1 设计原则什么放Tool、什么放Resource、什么放Prompt研究决策系统模块很多但在MCP协议框架内设计原则可以简化成一条有副作用、需要执行动作的做成Tool只读数据、用来提供上下文的做成Resource固定流程、需要复用的指令模板做成Prompt。举个例子。启动一个研究任务、查询任务状态、获取最终报告这三个都必须做成Tool因为每次调用都会触发后端服务执行动作。而团队内部知识库里的行业综述文档、历史项目的复盘报告这些是静态数据做成Resource更合适模型可以按需读取但不会因为它们产生副作用。至于报告的结构模板比如“请按照背景、现状对比、证据链、结论与建议四段式输出”固定且通用放在Prompt里最省事。初学MCP的朋友容易犯一个错误把所有东西都做成Tool不管它是动态操作还是静态内容。结果就是Tool列表膨胀到几十个模型选工具时反而无所适从。把静态数据、固定模板从Tool里剥离出去Tool数量立刻下降模型决策负担也小很多。3.2 核心链路实现规划-调度-验证-沉淀整个系统的运行链路是固定的收到用户问题后先启动研究任务规划器把问题拆成子任务调度器按依赖关系执行一批子任务每个子任务的结果进入验证器做可信度处理全部完成后汇总成报告并保存。MCP Server在这条链路里主要承担“对外的门面”真正的业务逻辑放在独立的编排服务里。这里有一个我特别想强调的设计决策不要把编排逻辑塞进MCP的tool函数内部。MCP Server适合做薄薄的一层协议适配如果直接把任务循环、并发控制、状态推进全部塞进mcp.tool()装饰的函数里短期内能跑但一旦系统出问题你会在协议适配层和业务逻辑层的边界上反复拉扯调试成本极高。我最终对外暴露的MCP Tool非常收敛核心就三个start_research、get_task_status、get_report。所有复杂流程都在编排服务里完成MCP这层保持轻薄。mcp.tool() def start_research(question: str, area: str general, max_depth: int 3) - str: 启动一次研究任务返回任务ID task_id orchestrator.start(question, area, max_depth) return f研究任务已创建task_id{task_id} mcp.tool() def get_task_status(task_id: str) - str: 查询研究任务当前执行进度 status store.get_status(task_id) if status is None: return 任务不存在请检查task_id return f当前状态: {status.state}完成子任务: {status.finished}/{status.total}进度: {status.percent}% mcp.tool() def get_report(task_id: str) - str: 获取研究任务最终报告未完成则返回进度提示 report store.fetch_report(task_id) if not report: return 报告尚未生成请先查询任务状态 return report为什么启动任务后返回task_id而不是直接返回研究报告因为一次完整的研究任务可能耗时几十秒甚至更久如果tool函数同步等待所有子任务跑完再返回MCP请求会被长时间占用容易导致客户端超时。异步任务ID模式更稳创建任务后立即返回客户端通过轮询状态接口获取进度跑完后拉取报告。这个模式在研究决策这类长耗时任务里几乎是必须的。3.3 规划器让“怎么研究”这件事变得可管理规划器是研究决策系统的大脑。它每次运行时会接收用户原始问题输出一份结构化的任务清单。为了保证输出稳定我给规划器定义了严格的JSON Schema子任务必须包含描述、类型检索型、对比型、验证型、总结型、依赖关系、状态四个字段。规划器用两步走的方式避免模型自由发挥。第一步调用模型生成候选子任务列表第二步用规则引擎过滤明显不合理的项目比如和主问题无关的跑题项、粒度太碎不值得单独开工的项、重复度很高的相似项。过滤完成后剩下的合法子任务才会进入调度器排队。有读者会问为什么不直接让模型一次性生成最终的任务清单实测下来模型一次生成的质量不够稳定要么遗漏关键维度要么产生大量冗余小任务。加一道规则过滤器之后质量明显提升代价只是多了几十行过滤逻辑非常值得。3.4 调度和验证程序能做的事不要交给模型调度器的核心维护一张任务依赖图某个子任务的所有依赖都完成后才允许进入执行队列。执行时用信号量限制并发数量比如同时只跑3个检索类任务避免瞬时请求过多。相同检索词走缓存单位时间内的总检索次数也设硬上限超出的请求直接返回“配额已用尽请稍后再试”。验证器这块可能是整个系统里最不“AI”但最实用的模块。它做的事都是程序逻辑比对多个来源的发布时间、抽取出文章里的核心实体、检测数字和日期是否冲突、对指向同一结论的证据进行计数。只有程序层的初筛通过后模型才被允许对剩余内容做语义层面的综合。这样的设计传递出一个明确态度关键事实核查不能指望模型自觉。模型擅长的是总结和推理但“这两个来源的数据是否一致”“这条信息的发布时间是否太旧”这类确定性判断程序处理又快又准不应该把这类任务外包给模型去做。4. 实操中的高频问题与排查记录4.1 我遇到过的高频问题速查表研究决策系统比普通套壳MCP复杂很多运行过程中问题也是五花八门。我把最常遇到、也最有代表性的问题整理成一张表方便后来者直接对照排查。现象原因解决方案MCP请求长时间无响应客户端超时Tool函数同步等待外部服务长任务阻塞请求改为异步任务模式启动时返回task_id状态轮询任务完成后单独取结果模型反复搜索同一批关键词不往下走缺少全局任务状态模型不知道自己已检索过什么维护任务上下文子任务完成后回写摘要模型每次决策前先加载状态上下文越拉越长很快用完搜索结果以完整原文形式返回占大量token在服务端先将结果抽成标题、要点、时间、来源的结构化摘要再送给模型结论与引用证据对不上验证逻辑完全交给模型判断把交叉验证和冲突检测写成程序逻辑模型只负责解释程序标记过的差异外部接口偶尔超时导致整体失败没有重试和熔断机制给工具调用统一加超时、重试如3次退避和熔断开关多个并发子任务打爆底层检索服务调度层没有配额控制引入信号量限制并发数缓存相同检索词设置单位时间请求上限4.2 坑一把MCP当成RPC框架把长任务塞进Tool有段时间系统频繁出现客户端“卡死”排查了一下午才发现问题出在start_research这个Tool的处理方式上我一开始在里面同步等待整个任务树跑完再一次性返回最终报告。一次理想的短任务确实能跑完返回但研究任务里总有几个子任务特别慢或者某个外部接口迟迟不返回整个MCP请求就僵住了。排查时一度怀疑是MCP SDK的问题后来把请求链路拆开才意识到问题不在协议层而在Tool的编程模型。MCP的Tool调用在逻辑上应该是“一次请求一次响应”短小精悍拖着长任务不放手等待超时是必然的。改成异步模式之后就再没出现过这个问题。这个坑的教训是协议边界是设计的一部分。不能因为MCP看起来像函数调用就把所有耗时任务都做成同步函数。设计Tool接口时要想清楚每个Tool的语义边界哪些操作应该立刻返回哪些操作应该先创建任务再异步跟踪。4.3 坑二让模型直接判断“结果可不可信”最初版本的验证逻辑非常偷懒把多个来源的内容一并塞给模型让它自己判断哪些可信、哪些不可信。测试场景少的时候看起来还不错因为模型对常见的矛盾内容还是有一定敏感度的。但一旦碰到来源之间没有直接文字冲突、而是隐含数据不一致的情况模型就抓瞎了。最典型的翻车案例是让系统对比两个不同厂家的产品参数两个来源都写着“功耗降低”但一个的依据是实验室环境测试另一个的依据是实际生产环境统计。仅凭自然语言表面判断模型区分不了这种差异背后的可信度层次会笼统地把两者都当成有效证据。后来我把所有结构化校验职责从模型中剥离出来程序先做基础检查模型只负责更深层的语义分析。每个证据都会自动附加“证据来源类型”“发布时间”“是否与主流结论一致”这些程序生成的标签模型基于这些标签再决策准确率高了很多。关键原则在于凡是能代码验证的就不要让模型去“感觉”。4.4 坑三没有给研究任务设“止损线”研究决策系统还有一个特别容易忽视的问题任务爆炸。用户提一个看似简单的问题规划器拆成了二十个子任务每个子任务再触发几路检索最后导致几十个外部请求耗时和资源都远超预期。有次一个同事用系统调研“某个新出现的芯片架构方向”规划器拆出来的子任务多到排队排了几分钟部分检索接口开始限流报错整轮研究的产出质量也受影响。那次之后我给系统全面加上了止损机制最大子任务数、最大检索次数、单任务总时间预算以及最重要的——达到资源上限时的降级策略。比如“当总检索次数已超过预算但还没有形成结论时停止新检索改用已有结果生成报告并在报告中注明覆盖范围受限”。宁可交付一份明确标注边界的研究报告也不要无限膨胀下去。4.5 实测效果给了什么启示把上述几个模块全部跑通之后系统从功能上看已经完全脱离了当初“套壳MCP”的定位。有一次我用它调研“某类数据库在特定工作负载下的选型对比”整个过程中的子任务拆解合理、多个来源的冲突信息被明确标出、最终报告里每条结论都带着来源链。这绝不是因为模型变聪明了而是因为流程变严谨了规划器保证了覆盖调度器保证了效率验证器保证了可信度记录模块保证了可追溯。5. 这类项目后面还能怎么走研究决策系统做到这个阶段它的形态已经比较清晰MCP在最外层做协议标准化内部坐着一个同时具备规划、执行、验证、记忆能力的工作流引擎。这样的底座结构天然适合继续扩展方向我个人觉得有几个延伸路径很值得尝试。第一个方向是沉淀为团队通用的研究流程引擎。目前系统里的规划器、调度器、验证器都是通用模块不依赖具体业务场景。只要更换底层数据源和Prompt模板就可以把同一套流程用于行业调研、竞品分析、论文综述、政策解读等不同场景本质上是把做研究和做决策的方法论固化成了可复用基础设施。第二个方向是接入更多私有知识源让研究结论不只是依赖公开网络内容还能结合团队内部沉淀的经验文档和复盘数据形成“外部公开信息与内部私有经验互相印证”的输出机制。第三个方向是输出决策记录的可视化和复盘能力因为目前已经有完整的任务痕迹再做一层统计和视图就能让用户直观看到自己在一次决策中覆盖了哪些维度、忽略了哪些维度。最后说一点个人体会。很多人看到MCP的第一反应是“我也可以做一个套壳”这没错MCP套壳确实是低成本高回报的入门方式。但做工具和做系统是两条路套壳解决“AI能不能调用它”系统解决“AI用得好不好、稳不稳、可不可信”。如果你也打算用MCP做研究类产品我的建议是先别急着写Tool先把研究任务的完整流程画出来想清楚哪些环节该由程序控制哪些环节该让模型发挥再把流程的边界和MCP的接口对齐。工具挂载只是入场券真正决定系统价值的永远是流程设计和数据控制能力。
