如果你在技术社区待过一段时间大概对“套壳”这个词不陌生。它通常带着点调侃外面包一层自己的注册逻辑里面全靠别人的模型能力没什么技术含量。我最初做的一个内部小工具就是标准的套壳MCP——给大模型接上“搜索资料”“读取文档”“保存纪要”三个工具仅此而已。三个月后再看我竟然在自己的设计文档里写下了“研究决策系统”这个名字。这篇文章想复盘的就是这个演变过程一个工具壳如何被真实需求一步步逼成带状态、带流程、带权限的决策系统。如果你正在用MCP做工作流集成或者你只是想搞清楚“一个简单封装是怎么长成复杂系统的”这篇应该对你有用。1. 起因当初只想给模型装几个“外挂”1.1 最初的需求和第一版结构一切来源于一个具体的痛点我们团队需要对一批技术资料做快速调研。传统的做法是人工开十几个网页、逐篇摘录、再做横向对比表。这套流程又慢又容易漏赶上材料一多人的耐心先没了。所以第一版很朴素我选了一个支持MCP协议的大模型客户端在中间起了一个MCP server把三个内部接口包装成模型可调用的工具。模型说“搜索一下XXX”server就转发到检索服务模型说“读一下这份文档”server就把文件解析结果丢回给模型。界面层负责渲染对话调用层负责转发整体代码量不大大部分时间耗在处理回调里的loading状态。那时候我管这个叫“套壳”没有任何心理负担。因为MCP的核心设计就是提供一套统一协议让模型与外部工具解耦。模型不需要知道内部接口是HTTP还是gRPC不需要关心鉴权细节我只需要照协议实现tools/list和tools/call再描述清楚每个工具的作用和参数Schema就算完成了一个合格的工具壳。1.2 第一轮测试暴露的尴尬真正的问题出现在第二轮测试。模型在一个小时内把同一个关键词搜索了四遍因为每次生成摘要候选时它都觉得自己缺资料读PDF读到后面前面提到的关键结论又忘了。我一开始觉得是模型能力不行换了一个更贵的模型结果只是从“很笨”变成“稍微聪明一点但还是重复劳动”。这不是模型的锅而是我的工具设计没有流程意识。搜索、读取、保存三个动作在全局视角上看应该是强耦合的先有搜索才会命中证据有证据才会写纪要。但我把它们设计成了三个孤立的“外挂”模型面对它们时只能在上下文窗口里临场发挥。上下文窗口一长前面查过什么、验证到什么程度全都变成它记忆里的模糊印象。我后来把问题归纳成三类这三类几乎决定了系统后来的所有主要走向无状态研究行为只活在某一次会话里下次新建对话就是一张白纸。无对象工具之间传递的是原始文本流不是结构化的研究单元。无反馈模型完成一步动作之后不知道自己下一步该干什么更不知道这一步做得对不对。这三类问题单靠MCP协议本身解决不了。因为MCP定义的是“模型怎么和工具握手”不是“业务流程怎么推进”。于是我开始琢磨在这层壳的内侧需要长出一个业务内核。这就是套壳MCP走向研究决策系统的第一个关键转折。1.3 一点基础概念补充如果你对MCP比较陌生这里补一句MCP中文常被称为“模型上下文协议”它规定了模型客户端如何发现工具、调用工具、读取资源、注入提示词。把它理解成一个插线板协议就行模型是设备工具是电器协议规定了插头的形状。我的项目一开始只是做了一根延长线把其他接口转成协议标准接口。2. 从工具调用到流程编排研究任务不是单发函数2.1 拆开“研究”二字开始看见决策的链条研究决策不是“我问一句答案就出来”的对话。真实的调研链路是提出研究问题、收集线索、识别候选假设、交叉验证证据、比较可选方案、最终做出决策。模型若想完整回答一个复杂的调研问题绝对不可能靠一次工具调用完成它需要在不同动作之间反复切换、来回修正。第一版里我用系统提示词约束模型“请先搜索再读文档最后总结。”表面上像是给它规定了一二三四实际上提示词只能描述理想行为不能维护状态也不能在失败之后自动恢复。有一次检索服务超时模型直接把“检索失败”当成“没有资料”写进了结论这个错误方向还被后续所有动作继承了。所以第二版我做了重要转变把这条链拆成阶段化的流程。每个阶段不是函数而是一个带目标和出口的模块。比如“线索收集”阶段的目标是拿到不少于若干条有出处的候选事实出口条件是候选线索达到阈值“方案比较”阶段的目标是让每个候选方案都有对应的证据列表和评分表。MCP在这里退回到它最擅长的那一层——执行动作。模型在某个阶段里具体调用的仍是搜索、保存这些工具而“接下来该进入哪个阶段”由编排层决定。2.2 状态机是怎么嵌进MCP server的实际操作里我没有把MCP server推倒重来而是让它变得更厚。server除了暴露工具还会暴露三类半结构化的资源当前研究上下文、候选清单、决策日志。模型调用任何工具之前server先在状态机里查一下当前阶段判断这个动作是否被允许。一个很典型的例子在“交叉验证”阶段如果模型尝试直接提交最终结论server会拒绝调用返回的提示不是“错误”而是“当前阶段是交叉验证你还有两个候选证据未完成可信度标记”。模型看到这个提示通常就会回去补动作。这个设计很微妙从模型视角看它依然在和MCP工具对话从业务视角看背后的编排层已经悄悄接管了流程节奏。状态机的状态转移并不复杂五态循环新建、采集、验证、比较、决策。真正复杂的是每个状态里工具可用性的差异。我把这个可用性矩阵放在了一份被MCP资源暴露的JSON配置里server每次响应工具列表请求时会根据当前状态动态过滤tools。这样做的好处是模型永远只看到自己当前能用的工具大大减少了乱调用的概率。2.3 MCP原语的新分工演进过程中我对MCP三件套——工具、资源、提示词——的用法有了新的理解在这里一并写清楚工具只用来做有副作用或消耗外部资源的动作比如检索、保存、提交。资源只用来传递系统当前状态快照比如候选清单、当前阶段、验证进度。提示词用来把阶段目标、出口条件、评价维度注入到模型上下文里替代那些不太可靠的系统提示词。前期的坑几乎都踩在“用工具传上下文”和“用资源执行动作”这两件事上。工具传上下文模型会越聊越糊涂资源执行动作权限边界就形同虚设。到后期我把这三者严格区分开整个系统的行为突然就稳定下来了。3. 决策系统的支柱记忆、证据与评分机制3.1 从会话记忆到“研究底稿”无状态的问题在第二版只解决了一半。我把状态存进了MCP server的内存里模型在当前进程内还能记得之前做过什么可一旦server重启所有上下文烟消云散。后来我设计了一张底稿式的存储表。每次研究行为都会在表里追加一条记录记录带类型、来源、时间戳和游标上下文。类型包括线索、假设、证据、评分、决策这五类。模型每完成一个动作底稿自动增加一行。这表面上是增加了存储和序列化逻辑实际上它带来了两个真正有价值的能力可追溯和可恢复。新对话开始的时候MCP server会把“本轮相关底稿”作为资源挂载给模型。模型开局就知道上次做到了哪一步上次查过哪些关键词哪些候选方案还没有评分。加了这一层之后重复搜索率从一小时四次直接降到了零因为模型能看到“已检索关键词”这样的元资源不需要靠记忆猜。3.2 证据链设计让每个结论都有回源路径第二版还有个问题叫“无对象”。工具之间传的是文本流没有结构化的研究单元。我到第三版正式解决这个问题重新设计了一个证据单元结构原始文本片段来源URL或文件路径采集时间初步可信度评分所支持的候选结论ID列表这个结构由MCP server在验证阶段提供给模型所有研究底稿不再保存模型中间输出的全部废话只沉淀成一条条可以被引用的证据单元。证据链带来的变化是整个项目层面最大的。决策评审的时候大家不再争论“模型说得对不对”而是争论“证据够不够支持这个结论”。这是两种完全不同的讨论方向后一种更接近研究决策的本质。而且在界面侧只需要点击某个结论就能看到它引用了哪些证据证据又来自哪个源整个判断过程对人是透明的。3.3 评分机制不让模型既当运动员又当裁判研究走到了方案比较阶段模型的一个偏向性问题开始突出它倾向于给自己的方案打高分。我做了个简单的对照测试同样的两份方案让同一个模型既生成又评价自己生成的那份平均分高出其他方案将近20%。这不一定是作弊而是它对自己的生成内容天然更有信息优势。所以我在评分链路上做了分离设计。每个候选方案先送给一个独立的轻量模型它只负责做两件事列出支持证据列出反对证据各自标注强度。规则层再按三个维度加权计算最终得分维度权重说明相关性0.5方案与研究问题的匹配程度可信度0.3来源权重与交叉验证情况时效性0.2材料时间越新权重越高单项得分都控制在1到5分之间。可信度来自来源类型权重一手来源默认0.9二手转载0.5带冲突标注的证据再乘0.7。规则层只做算术模型只做证据提取二者互不污染。这套公式不复杂但它保证了评分的可解释性——任何人打开决策日志都能清楚地看到为什么方案A排在了方案B前面。4. 团队协作倒逼出的权限与评审模块4.1 单人过滤器撑不住多人协作当这个系统只供我一个人使用时就算底稿乱一点、权限模糊一点也能容忍。可当它被放进一个小型协作团队之后混乱立刻放大。A同学想改候选清单B开发者想删除某条证据模型在同一个会话里收到了两个相互矛盾的意图状态机频繁报错。最严重的一次事故系统在没有经过评审的情况下直接进入了“决策完成”状态把底稿锁住了。排查了很久发现模型在某个中间步骤里自己调用了“变更状态”工具跳过了评审。原因是我把状态变更工具暴露给了普通采集角色。这表明研究决策系统不能只处理“人对内容的操作”还必须处理“人对系统流程的控制”。4.2 角色建模把权限直接映射到工具集合解决方案是给MCP工具增加一层角色注册表。每个角色能调用的工具集合不同具体规则如下信息采集者只能调用检索、采集、标注可信度这类工具。方案设计者可以在候选集上增加方案草稿但无权修改证据。评审者才能调用提交评审和变更状态这两个敏感工具。模型不再扮演全知全能的角色而是跟随当前登录人的岗位权限来行动。每次工具调用之前server都会根据“当前用户角色”做一次权限校验权限之外的调用直接返回“当前角色无权调用该工具”。这个逻辑本身就十几行代码它对系统行为的影响却非常大。4.3 评审状态机从草稿到决策不再自由发挥状态机被进一步收敛成五态草稿、评审中、修改中、已决策、已归档。MCP暴露一个“变更状态”工具但它的调用权限只绑在评审者角色上并且每次调用必须附带评审意见ID。这个ID对应底稿里某条具体的评审记录所以系统里不会出现没有原因的决策。这里有个特别重要的设计原则状态迁移规则写在编排层模型能修改的只是自己上下文里的文字改变不了数据库中的状态记录。即便模型在对话里疯狂暗示“已经决策了”server检查到的状态还是“评审中”它会继续按评审中阶段过滤工具列表。模型被约束在了它该在的地方。从这时候开始系统内部已经出现了权限、状态、审计三个关键词。任何一个工程师看到这三个词同时出现在一个项目里都能意识到这已经不是几个工具函数了而是一个业务流程系统。5. 这套“壳”到底变成了什么以及适可而止的边界5.1 用户感知不到MCP的存在面向终端用户他们打开的是一个干净的网页界面。输入研究问题看到任务依次进入“收集线索”“交叉验证”“方案比较”这些阶段最后拿到一份支持回源的分析报告。整个过程中没有任何用户需要直接和MCP协议打交道协议变成了背后的适配层和集成层。我们内部常调侃这套东西宏观上还是“套壳”最外面套着界面最里面套着MCP。但这句玩笑只说对了一半被套的并不是模型的能力而是研究者的心智模型。我把做调研时脑子里那一套流程固化成了系统里的状态机、底稿表和评审规则。5.2 MCP在这个系统里到底贡献了什么MCP在这套系统里的真实定位是集成边界。它解决了模型调用内部服务时的协议统一问题不需要每个服务单独给模型开一套接口也不需要模型侧感知不同服务的鉴权细节。模型通过一套统一协议消费工具、资源和提示词这就够了。但如果你试图把业务对象本身装进MCP工具描述JSON里把复杂的流程状态也塞进去维护成本会直线上升。工具描述字段是为了让模型识别功能用途不是为了存储研究报告。我见过很多MCP项目走到一半卡死就是因为什么数据都想通过工具参数传结果模型理解不了超长参数含义系统也失去了对流程的控制力。MCP在这里最适合扮演的角色是“最后一百米”动作从编排层发出来由它翻译成模型能调用的形式再把结果回传。它不该成为唯一的业务载体。5.3 什么情况下不应该长成系统写到这里我必须泼一盆冷水不是所有套壳MCP都应该变成研究决策系统。如果你只是个人偶尔用模型查资料就不要建底稿表不要引入评审状态机更不要设计复杂的角色权限。我做这些改变是因为真实场景里研究过程高度重复、结论需要多人复核、协作时冲突频发三个条件至少占了两个。缺了这些前提那么做出来的不是系统是一堆没有维护价值的过度工程。这个判断标准也可以用来检查你自己手头的项目如果你发现某个工具的重复调用率很高、模型老是忘掉之前的结果、协作成员经常改乱彼此的记录这个时候才值得升级流程和状态管理。如果这些迹象都不明显老实说维持一个轻量套壳就够了。5.4 给想走这条路的人几条实在经验最后分享几条我从这套系统里沉淀下来的实操经验先让模型自由调用工具跑两周把失败样本记录下来再根据失败设计状态机不要一上来就凭空想一套流程。流程应该是现实的映射不是理想的重写。不要在MCP工具返回体里放长文本。模型很容易读过即忘。要做分层摘要先给结论和要点详情按需读取。评分时把生成者和评价者彻底分开。否则模型会自卖自夸评分失去参考价值。状态机的拒绝提示措辞很重要。与其返回“操作被拒绝”不如返回“你还有两个证据未验证”。要给模型一条修正路径它才能自己把闭环走通。尽早把审计日志当成一等公民。决策系统的价值很大程度体现在复盘时能完整还原“当时为什么这么做”。这个项目现在还在迭代最近在做的是把底稿表改造成支持多任务并行版本。每改一次我都会想起最初那个写着一行注释、只挂了三个工具的套壳MCP——它长成今天这样不是因为我一开始就想得很清楚而是因为真实的研究决策需求一直在对技术架构提出新问题。这种“被需求推着生长”的过程让整个系统每一步都有据可依。
