从套壳MCP到研究决策系统：工具调用的演进之路

开头——

这项目名起得很轻浮，GitHub 上只有一个文件夹叫mcp-wrapper，备注写的是“MCP 工具调用的薄封装”。结果一年之后，我再打开它的时候，里面已经有证据管理、多模型交叉验证、决策评分、审计日志。换句话说，一个套壳 MCP 的项目，长成了研究决策系统。

我复盘了很久，也反复问自己：到底是哪一步开始“长歪”的？后来想明白了，不是哪一步，而是每一步都在往同一个方向偏移。MCP 给我的只是一个可插拔的工具接口，但“调用工具”这件事本身，天然会引出上下文、记忆、证据、可信度、最终建议。你把这些东西都认真做一遍，就绕不开研究决策系统的四个字。

这篇不是产品宣传，也不是论文解读，就是一个真实项目的演进记录。适合正在做 MCP 中间件、AI 工作流、企业内部知识助手的人看。如果你只是想在模型和工具之间加一个转发层，也可以当个警示：你今天写的call_tool，三个月后可能要撑起一个决策平台。

1. 起点：一个“套壳MCP”是怎么开始的

1.1 MCP套壳到底是什么

MCP 全称是 Model Context Protocol，模型上下文协议。它解决的是“让模型统一调用外部工具”这件事。你可以把它理解为给大模型装了一排插线板，不同的工具服务通过协议插到模型的上下文里。模型决定用什么工具，协议负责把请求发出去、把结果拿回来。

所谓套壳，就是你自己写一层非常薄的封装：向上对接模型，向下通过 MCP 请求工具。说白了，就是一个适配器。我的最初版本只有三个文件，一个负责建立传输连接，一个负责维护工具列表，一个负责把模型请求转发出去。连错误处理都做得潦草，很多异常直接抛给调用方。

当时的想法特别朴素：团队里同时有好几个服务想接大模型，每个服务都想注册自己的工具。如果每个服务都自己去实现一遍“模型如何选工具、如何发起调用”，那代码会重复到没法看。于是我就写了一个公共壳，统一暴露成 HTTP 接口，上层调用方只需要传一条消息和一个用户 ID，剩下的工具发现、参数解析、结果回填都在壳里完成。

这个阶段的“系统”成分约等于零。它不存储任何状态，不做内容理解，所有的智力活动都发生在模型侧。

1.2 当时的需求和初步设计

需求来源很具体：某项目需要让模型同时读取数据库里的业务数据、检索文档库、调用一个计算服务。这三个能力分别由不同的 MCP server 提供，但调用方的代码只需要面对我一个接口。

初步设计极其简单，三步：

1. 客户端启动时连上所有 MCP server，拉取各自的工具列表。
2. 把工具列表转成模型能理解的结构化描述，塞进 system prompt。
3. 模型决定调用哪个工具后，我通过 JSON-RPC 把参数传给对应 server，拿结果再回填给模型。

整个流程里，MCP 协议本身做了最重的工作。它定义了标准化的传输格式、工具发现、工具调用这些机制。我只不过把工具列表组装、请求路由、结果格式归一化这些事接了一下。

代码上更像这样：

class McpWrapper: def __init__(self, servers: List[McpServer]): self.servers = servers self.tool_list = [] for server in servers: self.tool_list.extend(server.list_tools()) def route(self, tool_name: str, arguments: dict): for server in self.servers: if tool_name in server.tool_names(): return server.call_tool(tool_name, arguments) raise UnknownToolError(tool_name)

那段代码看起来清爽，但埋了一个隐患：它对“上下文”这个概念几乎没做任何抽象。模型收到一堆工具，也收到用户消息，但它不知道哪些工具返回的内容来自哪里、可不可信、该以什么优先级参与后续推理。

这个隐患在一开始并不致命，因为 demo 场景下工具调用一两次就结束了。一旦面对真正的研究型问题，问题就会像滚雪球一样越滚越大。

1.3 为什么没直接用现成SDK

当时市面上已经有成熟的 MCP SDK 和框架。我不用，原因有三点。

第一，依赖太厚。框架往往自带服务发现、鉴权、日志、观测面板，我想验证的是核心链路，不想在脚手架里打转。

第二，我想把工具调用的控制权抓在自己手里。套壳阶段不需要太聪明，但我已经预感到后续会加缓存、过滤、权限分级这类逻辑。用别人的封装，这些点会变成框架的配置项；用自己的封装，这些点就是普通代码，改起来没有约束。

第三，跨语言的需求。团队里服务不都是同一种语言，有些工具是其他团队维护的。直接引用某个语言的 SDK，等于把其他调用方锁死在单一技术栈。我自己写一个薄层，反而是最灵活的选择。

现在回头看，这个决定有好有坏。好的地方是，后来长出来的证据链、决策评分模块，确实没有一个通用框架能直接提供，必须自己写。坏的地方是，早期我也踩了不少低级错误，比如对 MCP 协议的超时处理想得太天真，导致线上偶发卡死。

如果让我在“快”和“自己掌控”之间重新选，我可能还是会选后者，但会把协议相关的测试补齐，而不是等到第二轮重构才去补。

2. 转折：从“转发工具”到“上下文管理器”

2.1 单纯转发解决不了“对话记忆”

工具套壳跑通后，很快碰到一个尴尬场景。用户问：“帮我查一下上个月的核心指标趋势，找出为什么订单量下降。”模型先调用了数据库工具，拿到一堆数字，然后生成了一段分析。

接着用户又问了一句：“那对比一下前三个月的数据。”我原样把这句话发给模型，模型完全不知道“那”指的是什么。因为它看到的只是新问题，前面已经生成的历史回答并没有被保留在上下文中。

这不是模型的问题，而是我根本没做会话状态管理。模型是无状态的，每一次请求都是独立推理。之前查询的 SQL、返回的数据、中间结论，如果我没有显式保存并重新注入，它就等于失忆了。

解决办法简单粗暴：为每个会话维护一个 context buffer，把历史消息按顺序追加进去，再在每次请求前拼成完整消息序列送给模型。这算是所有聊天系统的基础设施，但我做的时候多走了一步——没有只存原始对话，而是把“工具返回结果摘要”也存进去了。原因很实际，一次数据库工具返回 50 行数据，全文塞进历史，token 消耗大，也稀释注意力。我要求每次工具调用后，生成一行“关键事实摘要”，和工具名称、调用 ID 绑在一起保存在上下文里。

这一步处理，让项目第一次有了“记忆”的概念。

2.2 上下文组织：记忆、参考、任务状态

简单的消息拼接虽然能解决问题，但很快暴露了另一个问题，不同的内容在上下文里的“地位”不应该是平等的。

我梳理了一下，实际场景里会有三类信息：

• 静态资料，比如工具说明、研究背景、长期偏好。
• 任务状态，比如当前正在回答什么问题、已经做到第几步、哪些问题还悬而未决。
• 过程记录，比如历史问答、工具结果摘要、证据日志。

如果把它们全部混在一个消息列表里，模型很难分辨哪些信息是长期不变的，哪些是当前这个任务临时产生的。于是我把上下文管理改成了分层结构：

class ContextBundle: system_prompt: str task_state: dict evidence: List[EvidenceItem] history: List[Message]

每次拼 prompt 时，先放系统提示，然后放任务状态，再放证据库，最后放历史对话。任务状态用结构化 JSON，比如“当前聚焦问题：订单量下降原因；已验证假设：促销取消；待验证假设：竞品降价”。模型看到这种结构后，回答问题的目的性明显增强，不再东拉西扯。

这一步也埋下了“研究”的种子。因为当你把验证过的假设和待验证假设单独拿出来时，你已经不是在聊天，而是在围绕一个课题做推理了。

2.3 工具注册与调用边界

工具越来越多之后，上下文又遇到了新的压力。假设有 30 个工具，每个工具描述平均 200 个 token，光工具定义就占掉 6000 token。模型上下文窗口再大，也是浪费。

所以我把工具注册改成了分组注册。每个业务场景有一个工具白名单，比如“数据分析”场景只挂数据库和计算类工具，“文献调研”只挂检索和摘要工具。模型每次只能看到当前场景允许的那组工具，看不到的就不会误用。

这个设计有很实际的好处。第一，省 token。第二，减少模型在无关工具之间反复横跳。第三，安全。某公司内部的工具权限可以直接映射到场景，不让模型接触到它不需要的敏感操作。

同时，我给工具调用加了边界检查。某些工具是只读的，某些工具是写操作，写操作必须带审批参数。套壳阶段根本不会想到这事，但用到后面，没人敢让模型直接对生产库执行 delete。

从这时起，“壳”已经开始有“机制”的味道了。

3. 进化：从“上下文管理器”到“研究决策系统”

3.1 研究场景带来的新需求

项目真正“叛变”的时刻，是用户开始拿它做长周期的研究任务。

最早是有人用它整理技术选型材料。问题类似：“对比一下三种消息队列的实现方案，给出选型建议。”这表面上是一个问答，实际却需要多轮动作：

1. 搜索资料。
2. 提取各自的架构特点。
3. 找性能测试数据。
4. 对比优缺点。
5. 结合业务约束得出结论。

如果我只是把这些问题拆成几次工具调用，模型很容易在第一次检索后就急着给答案，后面的对比过程变成脑补。这是第二大转折点：我开始要求模型先输出“研究计划”，再逐步执行，每一步都有中间结论，最后才能形成建议。

研究计划包括：问题拆解、需要收集哪些证据、证据的可靠渠道、验证路径。这个结构不是我从某篇论文里抄来的，而是逼出来的。因为模型在长任务里经常会“迷路”，特别是连续调用工具后，它会忘记最初的目标是什么。只有把目标、步骤、当前状态显式放在上下文里，才能把这条路走完。

从这时起，它的行为已经不是“回答用户问题”，而是“完成一项研究任务”。

3.2 证据链与可信度评估

研究任务最怕两件事：胡编乱造和偏听偏信。模型在综合多个信息源时，如果只是顺着 prompt 里的语境走，很容易把低质量来源和高质量来源一视同仁。

所以我加入了证据链模块。每一次工具调用产生的关键结果，不再只是塞进上下文，而是被转成一个结构化的证据对象：

• 结论摘录：这句话说了什么。
• 来源标识：来自哪个工具、哪份文档、哪个数据库。
• 获取时间。
• 可信度初始分数。

可信度初始分数由来源类型决定：官方文档给 0.9，社区帖子给 0.4，经过人工复核的再额外加权重。这个分数不是用来过滤信息，而是用来在最终决策阶段做加权。低可信度内容允许参与推理，但它的影响程度会被压缩。

这个设计救了项目很多次。比如某次对比两个框架时，社区博客强烈推荐 A 方案，官方文档却暗示 B 方案更适合大规模场景。如果只看文本，模型可能被博客的长篇大论带偏。但有证据链之后，决策模块会展示出来源分布，让你一眼看到结论主要依赖哪类信息。

3.3 多模型多源交叉验证

有了证据链，我还不放心，因为单个模型本身就存在系统性偏见。同样的 prompt、同样的一堆证据，某模型可能更倾向于选择功能多的方案，另一个模型可能更保守。

我本来就有对接多家模型服务的能力。MCP 壳本身没有绑定任何一家模型供应商，只要实现同一个chat()接口，谁都能接。于是我在决策环节加了一个交叉验证层：同一个研究任务，分配两个不同配置的模型分别生成独立分析。它们看到的上下文相同，但 prompt 版本不同，内部采样的温度不同。

两个模型都选了 A 方案，那 A 的可信度上调。意见不一致时，系统不强行融合，而是把分歧点和各自的理由生成一份“分歧报告”，让用户继续补充证据。

这一步，是项目从“帮你查资料”变成“帮你做决策”的分水岭。单纯的信息检索系统不会管两个来源是否打架，但决策系统必须处理冲突。

3.4 从“答案”到“建议”：决策输出层

最后我还改了一种东西：输出格式。

传统问答的输出是一段话。研究决策系统的输出应该是一份有结构的建议。我的最终输出长这样：

• 决策场景描述。
• 推荐选项及综合评分。
• 各个选项的证据支持度。
• 风险点。
• 需要人工确认的问题清单。

这个格式最开始很不习惯，模型总想把它写回流畅的文章。后来我在 system prompt 里强制指定输出 schema，并给了一个示例，它才稳定下来。

结构化输出的意义不只是好看，而是它让结论可以被验证。哪个选项的证据不足、哪个观点存在冲突，都直接暴露在界面上。人不需要盲目相信模型给出的结论，而是能看到结论背后的一整套推理路径。

到这一步，我再也无法自欺欺人地说这是个“套壳”了。它有状态管理、有证据体系、有评估逻辑、有输出规范，这就是一个研究决策系统的雏形。

4. 核心实现拆解：关键模块设计与代码思路

4.1 MCP客户端封装层

无论上层长成什么样子，最底下仍然是对 MCP server 的调用。我没有用现成 SDK，而是保留了一个自己维护的 client。

这个 client 的核心是定义 transport 和 message handler。靠近实际生产的实现比前面的 demo 更复杂，我加了如下几个东西：

class McpClient: def __init__(self, transport_type: str, endpoint: str, timeout=10): self.endpoint = endpoint self.timeout = timeout self.transport = self._create_transport(transport_type) self.request_id = 0 self.pending_requests = {} async def list_tools(self) -> List[Tool]: return await self._request("tools/list") async def call_tool(self, name: str, args: dict) -> ToolResult: req_id = self._new_request_id() self.pending_requests[req_id] = asyncio.get_event_loop().create_future() await self.transport.send("tools/call", req_id, name, args) return await self.pending_requests[req_id]

关键点是pending_requests这个字典。MCP 底层是异步消息，但上层业务需要同步等待每一个调用结果。如果不做请求 ID 到 Future 的映射，并发工具调用会互相错乱。

后来我又在 transport 外层包了一层“自动重连 + 请求重放”逻辑，但这里不展开，后面踩坑部分会细说。

4.2 上下文编排器

上下文编排器是整个系统的大脑入口。它接收用户问题，结合会话状态，生成一次模型调用需要的完整上下文。

我定义一个Composer类，负责把不同来源的内容按规则组装。核心思路是“分层灌注”：基础信息永远有，证据和任务状态按需注入。

class ContextComposer: def compose(self, task: ResearchTask, evidence_store: EvidenceStore, history: List[Message]): tokens = self.estimate_tokens(task.system_prompt) if tokens < TASK_STATE_LIMIT: tokens += self.append_task_state(task) if tokens < EVIDENCE_LIMIT: tokens += self.append_top_evidence(evidence_store) if tokens < HISTORY_LIMIT: tokens += self.append_recent_history(history) return PromptBundle(...)

写的时候要注意 token 预算。我的做法是给 evidence 部分设置一个动态上限，按照当前工具返回的总量压缩到原来的 20%，并且只保留相关性最高的一批。相关性由模型在上一次调用时打标，这也算一个轻量 rerank。

没有这个策略，很早就把上下文窗口塞爆了。尤其当工具返回的是一整页文档时，原始内容根本不可能全量进入 prompt。

4.3 决策引擎实现

决策引擎不是一个复杂的统计模型，而是把证据聚合方式变成了一种可解释的加权计算。

每条证据被处理成这样的结构：

{ "claim": "A方案在千节点规模下吞吐量更高", "source": "官方压测报告", "score": 0.95, "weight": 0.8, "side": "pro_A" }

按下 option 维度聚合，计算加权支持度：

def aggregate_score(options, evidence_items): total = {opt: 0 for opt in options} weight_sum = {opt: 0 for opt in options} for item in evidence_items: opt = item.side total[opt] += item.score * item.weight weight_sum[opt] += item.weight result = {opt: total[opt] / weight_sum[opt] if weight_sum[opt] else 0 for opt in options} divergence = compute_disagreement(evidence_items) return result, divergence

divergence用来衡量当前证据是否互相矛盾。如果高高，系统会提示“当前证据分歧明显，建议补充第三方来源后再决策”，而不是硬给出一个结论。这个机制在混沌的信息环境里非常有用，它本质上是在告诉用户：目前这些问题没有共识性答案，不要盲信系统。

决策引擎的价值不在于算法高深，而在于“果链可以追溯”。任何结论都能反查到它支持了哪几条证据，哪条证据来自哪个来源。这一点比模型自己输出的黑盒结论可靠得多。

4.4 存储与可追溯性

没有存储的系统，随时可以推翻自己的历史。研究决策系统必须有可审计性。

我用 SQLite 存结构化数据，用文件目录存原始记录。每个会话一个文件夹，里面有：

• 全部输入输出消息。
• 每次工具调用的请求与响应原文。
• 证据对象的中间态。
• 最终决策的评分表。

目录长这样：

sessions/2024-11-12-abc123/ messages.json tools_invoke.log evidence.jsonl decision_report.json

加上这层之后，每次出问题都能回溯到具体某一次工具调用。比如用户质疑“这个结论怎么来的”，我可以直接翻出决策评分表，告诉他这个结论主要由哪两条证据支撑，其中一条来自哪个文档，可信度多少。这种透明性，是研究决策系统区别于普通问答助手的核心能力。

5. 踩坑记录与排查方法

5.1 MCP传输层超时不稳定

最早期，线上出现过一批偶发故障：工具调用发起后，客户端一直等不到响应。日志看起来像服务端没返回，但到服务端查，它明明返回了。后来定位到是传输层超时设置不合理。

MCP 长连接环境下，SSE 连接可能会因为空闲而断开。我原本以为重连接口就能好，但断连瞬间发出的请求会被丢失，而客户端已经把这个请求标记成待处理。结果就是悬挂请求永远不会被唤醒。

解决方案有三步：

1. 给传输层加心跳检测，每 15 秒发一次 ping。
2. 请求带上唯一的 request_id，重连后允许客户端按 ID 查询结果。
3. 所有调用通过异步超时器包裹，超过 30 秒直接标记失败，不无限等待。

这三步之后，服务端偶发断连就不再会拖垮整个会话。

5.2 工具返回内容过大导致上下文爆炸

有一个搜索工具，返回的不是摘要，而是完整的网页文本。某次研究型任务里，模型连续调用了三次搜索，全文内容加起来超过了上下文窗口的上限。结果底层模型直接报错，整个会话崩了。

我给工具响应定义了一个规范：所有外部内容进入上下文前，必须经过“标准化摘要”。摘要器提取核心事实，控制长度。原始完整内容不进入模型上下文，而是存储在证据库里，通过引用 ID 在需要深度分析时再读取。

这样做会损失一些细节，但换来了稳定性。另外，我还在工具调用后补了一个步骤：提醒模型不要因为摘要信息不足就强行推断。如果摘要信息不够，应该继续追加工具调用，而不是脑补。

5.3 决策模块出现“假共识”

交叉验证上线后，我遇到一个诡异场景：两个独立模型都选了同一个方案，给出的理由也一致。用户却觉得不对，后来人工查证，发现自己提交的研究资料里有一篇影响力很大的错误文章，两个模型都阅读了同一份资料，被它带偏了。

这个经历让我认识到，多模型一致不一定等于正确。它们可能共享有偏见的证据源，形成“假共识”。我随后在决策模块加入了“对立证据强制生成”机制：如果所有选项都只有正面证据，系统会自动生成反方提示，让模型从对立角度审视证据链。

同时，决策报告里增加了一个字段：证据来源多样性。如果所有支持结论的证据都来自同一个 domain，系统会提示“证据单一，请补充独立来源”。这个机制之后帮我拦下了不少看似合理、实则脆弱的判断。

5.4 升级后的版本管理问题

功能迭代很快的时候，prompt 模板、评分策略、上下文组装规则一直变。最崩溃的一个问题是，旧会话里保存的证据是旧格式，新代码读取时会报错，历史决策报告全部出现解析不了。

后来我做了三件事：

• 把所有配置和 prompt 版本化为独立文件，并用语义化版本号。
• 存储数据时记录 schema_version，每次升级打一个迁移脚本。
• 关键结构都用 JSON Schema 校验，不合法内容直接拒绝加载并提示回退。

整理的结果是，项目从一天一改，变成了每周稳定迭代，但仍能回溯几个月前的会话。版本问题不是功能问题，但它直接决定了系统能不能被信任。

6. 复盘：套壳长成系统后的一些体会

6.1 套壳和系统的边界在哪

经常有人问：你这个东西到底算套壳还是系统？我自己的判断标准是三个：

• 有没有自己的状态。
• 有没有自己的决策逻辑。
• 有没有自己的存储与追溯。

没有状态，就是无脑转发；没有决策逻辑，就是工具分发器；没有存储，就是一次性计算。这三样都齐了，就算披着套壳的皮，它也已经是系统。

“套壳”这个词没必要避讳。很多有价值的东西都是从套壳开始，先解决接口适配，再慢慢长出不可替代的部分。真正重要的不是你叫不叫套壳，而是你有没有在做套壳之上增加别人无法轻易抄走的机制。

我这个项目里最核心的竞争力，并不是 MCP 封装本身，而是围绕决策建立起来的那套证据链、冲突检测、来源多样性评估。它们和具体模型无关，换一个模型提供商，系统照样能跑。

6.2 如何控制需求蔓延

每加一个功能之前，我会过三道问题：

1. 这个功能是不是在研究主链路上，也就是“收集信息 -> 分析 -> 决策”的某个阶段？
2. 它是不是让决策过程更可解释了？
3. 如果拿掉它，用户会不会蒙受明显的损失？

如果两个回答是否，就不加。这么做之后，砍掉了很多花哨但无用的功能，比如花哨的可视化面板、自定义规则引擎、复杂权限中心。这些功能本身不坏，但会让人在无效复杂度里沉迷。

我也开始接受一个原则：系统必须有一些“不给用”的东西。决策引擎在设计上默认不提供“一键生成最终结论”的模式，永远要求输出风险提示和待确认问题。表面上看起来没那么方便，实际上保护了系统的边界，也保护了用户不被幻觉误导。

6.3 这套东西适合谁

我现在最推荐的用法，是把它作为一个研究态 / 决策态的工具，而不是一个通用对话产品。

它适合的场景包括：技术选型、方案评审、情报整理、数据结论交叉验证。它不适合的场景包括：实时客服、需要极低延迟的命令响应、必须保证 100% 精确计算的场景。这些场景不需要决策链，需要的是可靠执行，套壳会更合适。

如果有人想从零复刻，我的建议是先别照抄决策引擎，先从“上下文 + 证据记录”开始，跑通一遍真实任务，再决定要不要上多模型交叉验证。决策逻辑是从实际需求里长出来的，不是预先设计出来的。

最后再分享一点个人的感受。我刚意识到项目“长歪”的那一天，原本有点沮丧，觉得自己的路线不纯粹了。后来想通了，纯不纯粹不重要，系统是否在真实问题上做对了判断才重要。一个套壳 MCP，因为坚持给每个结论找证据、留痕迹、做冲突检验，最后变成了研究决策系统。这条路有点绕，但每一步都踩在需求上，走得不亏。

如果以后再有人问我，叫什么名字不重要，重要的是你有没有能力在模型的自信回答面前，多问一句：“证据呢？”