这篇文章不是讲方法论而是想复盘一下一个原本只是给内部业务包一层MCP接口的套壳项目怎么在三个月里一步步变成了一个带研究、分析、决策辅助能力的完整系统。中间没有大的架构预谋每一步都是被真实需求推着走回头一看这玩意儿已经不是当初那个壳了。如果你正在做MCP服务开发、AI工具集成或者在一个老系统上接AI能力这篇文章里记录的演化路径、模块拆分、踩坑细节应该能帮你少走不少弯路。不废话直接开始。1. 先别笑为什么套壳MCP会是一个真实需求1.1 这里的套壳指的是什么MCPModel Context Protocol模型上下文协议是一个把AI模型和外部工具、数据源连接起来的开放协议。它定义了一套标准的工具调用、资源访问和上下文传递方式让AI应用可以像一个统一插线板一样插上不同的MCP工具就能干不同的事。而套壳MCP在实操中通常指在一个已经存在的业务系统或者一堆散装脚本之上包一层标准的MCP服务接口让AI助手能够调用它。说得直白点就是把老系统的能力翻译成AI能听懂的话然后开一个门让AI进来干活。这个需求听着不性感但现实中极其普遍。因为大部分团队的老系统改造起来成本高、风险大更不可能推倒重来。MCP恰好提供了一个低侵入的切入点你不需要改老系统的内部逻辑只需要在外面加一个适配层把老系统的输入输出转换成MCP能识别的工具调用格式就完事了。我们当时的情况也差不多。某团队内部的业务系统已经跑了很多年数据都在里面但查询入口非常老旧团队成员想临时看个指标都得找特定的人帮忙跑数据。我们就琢磨着能不能包一层MCP让AI助手直接对接这些数据查询能力。1.2 最初的需求清单其实很朴素项目刚启动的时候需求就三个自然语言查数据团队成员用对话的方式查询项目进度、资源占用、关键指标等常规数据。报告汇总把散落在多个文档里的日报、周报信息抓取出来按模板生成汇总报告。阈值提醒监控几个核心指标超过设定阈值时自动推送提醒。这三个需求拆开来看每一个都很轻。自然语言查数据本质是一个MCP工具加上查询解析报告汇总就是文档读取工具加模板渲染阈值提醒最多加一个定时任务扫描工具。我们一开始也确实是这么设计的三个工具一个统一入口一个MCP服务完事。按当时的时间估算这个壳子大概一周就能搭完。事实也差不多骨架确实一周搞定了但噩梦从第二周开始。1.3 用户预期的第一次膨胀壳子跑起来之后团队里的人新鲜了两周。每天用自然语言问数据、让AI汇总报告确实比原来翻系统快多了。但很快问题就变了。原话我记得很清楚数据查出来了但是能不能帮我分析一下为什么这个指标降了这几份报告汇总好了能顺便告诉我目前哪个方向风险最大吗一开始我们的态度是不行这是个查询工具不做分析。但问的人多了我们自己也意识到如果拒绝这个需求用户就只能自己把数据拷出去再丢给大模型问一遍然后再把结论拿回来。这个流程极其断裂用户体验很差。那时候做了一个极其重要的决定不是把分析能力硬塞进现有的MCP工具链而是在工具调用之上加一层任务编排能力让系统可以按顺序调用多个MCP工具中间穿插数据处理和推理步骤。这个决定的后果直接决定了后面系统会走向哪里。2. 三个演化岔路口决定它不再是壳2.1 第一次演化从工具封装到任务编排MCP协议本身解决的是AI怎么调用单个工具它不解决AI怎么按正确顺序调用一堆工具、中间失败了怎么处理。当你只有一个查询工具的时候不需要编排。但当分析需求出现后整个流程就变了。以为什么指标降了这个问题为例。要回答它至少需要三个步骤先把相关指标的历史数据拉出来再把同期其他指标的数据做对比最后结合业务变化记录做归因分析。三个步骤涉及的工具是一样的但顺序、依赖关系、数据传递方式都需要一个调度层来管理。当时我们调研过一些工作流引擎但都太重型了。考虑到这个系统本身是从壳起步的我们选了一个轻量方案自己实现一个简单的有向无环图DAG调度器。每个任务节点可以是MCP工具调用、数据处理函数、或者模型推理步骤。节点之间通过一份统一的上下文协议传递数据。这个调度器在代码上其实不难难的是设计节点输入输出的格式规范。我们定了三条规则每个节点的输出必须是结构化JSON不能是自由文本节点之间通过显式的字段引用传递依赖不允许隐式共享内存任意节点失败时如果要降级必须走预设的fallback路径而不是让模型临场发挥。这三条规则后来成了整个系统稳定的基石。等系统长成完整的决策框架之后回头看这次演化的意义不只是能跑多步流程了而是让系统第一次具备了研究的基本形态先收集数据再分析数据最后输出判断。2.2 第二次演化从单次问答到证据链闭环第一次演化让系统能做多步操作但它仍然是一个黑箱用户问了一个问题系统转了半天吐出一个结论。至于这个结论是根据哪些数据得出来的、经过了怎样的推理过程用户完全不知道。在业务场景里这是不可接受的。因为就算AI的分析结论有道理团队也不敢直接采信一个没有出处的判断。毕竟是拿来做管理决策参考的错了要背锅。于是我们做了第二个关键决定引入证据链机制。具体方案是系统每次执行研究任务时会自动记录三样东西——原始数据快照、中间节点输出、最终结论。这三样东西通过一个traceID关联每次用户提问都会自动生成一个独立的研究档案。用户不仅能看到结论还能一层层点开看到某条结论是由哪几个数据点支持、经过哪个推理节点得出的。听起来容易做起来有不少细节。最核心的困难是模型在推理过程中产生的中间结果是不稳定的同一个问题不同时间问中间步骤可能有差异。如果我们只记录最终调用的工具和数据证据链就只是个日志对用户没有实际意义。我们的解法是给调度器增加步骤级标注功能。每当DAG中的一个节点执行完调度器会强制把节点输入和输出摘要写入证据链同时在模型做推理前调度器会把之前的关键数据摘要注入到模型提示词里。这样就能保证一件事不管模型怎么发挥它的最终判断一定是基于证据链里已经记录的数据而不是它自己脑补出来的内容。这次演化让系统从回答者变成了研究者——它不是给你一个答案而是给你一份可以审查的研究报告。很多内部用户开始信任这个系统就是从证据链功能上线之后开始的。2.3 第三次演化从被动应答到主动监控前面两步演化之后系统已经能处理相当复杂的研究型问题了。但它仍然是一个你问它答的工具。如果没有人提问系统就静默待命什么也不做。转机出现在一次具体的事故上。有一天一个关键指标突然异常下降但因为没人主动去查系统毫无反应。直到晚上复盘会议才发现问题。这次事故后产品负责人提了一个要求系统应该主动盯指标而不是等着被问。这次的改动比前两次都要出圈因为系统不再只是一个MCP服务了它还需要在后台持续运行、感知外部变化。我们做了一套事件驱动机制定时任务按照预设频率扫描关键指标生成指标快照快照与历史基线对比偏差超过阈值则触发分析流程分析流程自动复用已有的DAG调度器生成归因报告报告生成后通过消息服务主动推送给相关人。这个机制上线后系统才真正成为决策系统的一个完整雏形它能主动发现问题、分析问题、输出建议、送达相关人员。整个链路不再是人发起、AI响应的单向关系而是人机协同的双向互动。3. 研究决策系统的关键模块拆解到这一步系统已经从套壳MCP长成了一套完整的决策辅助框架。下面把系统的关键模块做一个拆解每个模块我们踩过的坑、最后定型的设计方案都一并讲清楚。3.1 统一数据访问层MCP工具背后的数据底座很多人以为MCP工具就是直接查数据库其实不是。如果每个MCP工具都直连各自的库、各自的表那调度层就没法统一管理了。我们花了很大力气做的是所有MCP工具背后必须通过一层统一数据访问层不许直接连底层数据。这个数据访问层分了三层结构原始层底层业务系统的数据表结构、字段命名都很随意直接暴露给模型是不可控的。汇总层对原始数据做清洗、去重、格式化处理后形成的宽表按业务主题组织。指标层进一步把宽表加工成指标比如日活转化率渠道成本占比库存周转天数。这一层是MCP工具直接读取的对象。MCP工具只读指标层有几个好处数据口径统一权限控制简单模型不会接触到底层脏数据。指标层的索引和缓存是我们踩过最多坑的地方。一开始没有做缓存每次用户提问都去汇总层现算一个指标动辄几千万行数据查询动辄几秒到几十秒。后来加了二级缓存结果缓存同一个问题短时间内的重复查询直接走缓存和预聚合缓存提前算好常用指标查询时只做时间维度裁剪。缓存上线后系统平均响应时间从8秒降到1.5秒左右体验完全是两个量级。还有一个细节容易被忽略MCP工具的输入参数设计很重要。我们要求工具的参数表结构必须是时间范围 业务维度 指标ID的形式这是为了后续任务编排时不同工具之间可以方便地共享参数。如果每个工具的参数格式各搞各的调度器做参数传递的时候会痛苦到怀疑人生。3.2 决策规则引擎别把全部判断都交给模型在搭建过程中我们最坚持的一个原则是别把一切都押在模型推理上。对于确定性强的判断应该用规则引擎来处理只有开放性问题才交给大模型。举个例子某指标本周环比下降超过10%这个判断你完全不需要大模型。写一个简单的阈值判断准确率100%响应时间1毫秒。如果非要把这个判断也丢给模型不仅慢还有可能因为模型输出的不确定性导致误判。我们的决策规则引擎归为两类统计规则基于数学公式的确定性判断。比如环比变化率、同比变化率、三日移动平均线突破、方差异常检测。这类规则全部用代码实现不走模型。语义规则基于业务知识的经验性判断。比如当获客成本上升且留存率下降同时出现时判定为增长结构恶化。这类规则也需要用结构化规则表达语言配置而不是让模型自由发挥。只有一种情况我们会主动调用大模型当规则引擎无法穷举候选原因需要基于文本信息做开放性推理的时候。比如请根据过去两周的运营日志和竞品动态给出转化率波动的综合解读。这种混合决策架构有一个非常直观的好处系统的决策过程是可解释的。用户问为什么系统认为这个渠道效率低下我们可以立刻给出答案因为该渠道的获客成本指标连续七天超过阈值且同期的用户留存率下降超过了5%。每一个判断都有据可查用户自然愿意信任系统。如果你把全部判断都交给模型那你就得接受一个现实系统做出的每一个判断都可能出现模型幻觉而你几乎没有成本低的手段去验证。3.3 上下文压缩与记忆管理研究决策系统一个最容易被低估的难点是上下文管理。系统在执行复杂任务时往往会在多个节点之间传递大量数据。如果每个节点都把全量数据返回给模型模型的上下文窗口很快就会被打爆。我们采取的是两级压缩策略第一级是结构化摘要。每个工具执行完毕返回数据时数据访问层会自动生成一个摘要对象包含涉及的时间范围、数据总量、最大值、最小值、均值、主要趋势变化点。摘要对象体积很小几百字节以内模型只需要读摘要就能把握全局。第二级是关键字段截断。有些业务场景下模型确实需要看到原始明细数据比如找出某个异常值所在的维度。这种情况下我们会让工具可以按需加载明细但只加载当前推理步骤真正需要的字段并且限制返回行数一般是前50行或者按相关性排序后的TOP N。记忆管理方面我们最初做得很朴素就是直接把多轮对话拼进提示词结果长任务跑到一半上下文就乱了。后来参考了比较成熟的记忆管理方案把系统记忆拆成了两层短时记忆当前研究任务内产生的数据摘要、中间结论、引用来源。任务结束后清空。长期记忆跨任务保存的稳定信息比如用户的业务偏好、常用的指标口径、反复出现的数据异常记录。长期记忆经过摘要化之后只保留最有价值的部分。这里有一个非常容易踩的坑如果你只做摘要不做剔除长期记忆会快速膨胀。我们的做法是给长期记忆内的每一条记录加一个使用频率字段超过一定时间没有被调用过的记录会自动归档降级。相当于给记忆做了个LRU缓存。3.4 审计与回放机制研究决策系统跟纯工具型的系统不同它输出的内容是决策支持信息。既然涉及到决策就必须能审计、能回放。我们给系统中的每一个研究任务分配一个全局唯一的traceID。这个traceID贯穿整个链路包括入参、调度器执行过程、每个节点的输入输出摘要、模型推理日志、最终结论、以及主动推送记录。回放机制做得比较彻底在系统的后台管理页面可以按traceID查询某个历史任务看到完整的执行链路。每一步用了哪个工具、查了哪些数据、中间推理的过程文本是什么、最后结论是怎么生成的全部可查。这项能力上线之后产生了一个意外的副产品它变成了我们排查系统问题的第一利器。以前发现系统给了一个错误结论只能靠复现问题来定位现在直接在后台看证据链是数据错了、工具挂了还是模型胡扯了一眼就能定位。还有一个细节审计日志的记录时间最好用系统统一时钟不要依赖各服务器的本地时间。我们有段时间大量使用容器部署各实例的时钟偏移导致日志时间线错乱排查问题的时候极其痛苦。后来统一接了一个时间同步服务这个问题才算根治。4. 实操过程中遇到的坑和解决方案4.1 工具描述写得太模糊模型开始瞎猜MCP工具的描述信息直接决定了模型能不能正确选择和使用工具。刚开始写描述时我们偷懒了每个工具就一两句话比如查询业务指标完了。后果是灾难性的模型经常不知道选哪个工具也不知道该传什么参数。比如系统里有两个工具查询渠道指标和查询整体指标模型分不清渠道和整体的区别经常传错维度值返回空数据时它也察觉不到。后来我们花了整整一个下午把每一个工具的描述按照一个固定模板全部重写这个工具是干什么的适合什么场景不适用什么场景什么时候应该用另一个工具替代完整参数列表每个参数的类型、取值范围、默认值一个具体的调用示例包括输入和输出返回数据的结构说明以及可能出现的空值情况。重写后模型选工具的准确率明显提升而且有个意外收获因为描述写清楚了什么时候不该用模型在条件不足时会主动说明原因而不是硬着头皮调用一个不合适的工具。这一点对研究决策系统的严谨性非常重要——有时候答不上来比胡答要好得多。4.2 MCP调用超时与重试策略MCP工具调用外部API的时候网络抖动、服务繁忙、数据量大都可能导致超时。最开始我们没管这个结果模型经常一调用工具就收到一个timeout错误然后它就认为这个工具不可用转而去编造一个听上去合理的答案或者直接放弃。这个问题的隐蔽性在于模型并不会明显表现出因为超时所以我放弃了它通常会假装完成了任务然后给一个模糊的回答很多用户就被糊弄过去了。我们的解法是分级设置超时策略快速工具如简单的指标查询3秒超时重试1次中速工具如带汇总计算的数据查询10秒超时重试2次慢速工具如跨多系统数据对比30秒超时不重试直接降级为人工处理。这里有一个细节值得写出来重试不是简单的同一个请求发两遍而是要在重试前做一个幂等性判断。如果这个工具调用产生了副作用比如写入数据重试就会导致重复执行。我们在设计MCP工具接口时强制要求写操作工具必须支持幂等标识符查询类工具天然幂等这个问题就提前规避了。还有一个容易忽视的地方工具超时后调度器给模型的错误信息必须明确。不能只写调用超时而要写清楚工具查询了多长时间、包含哪些参数、下一步建议是降级还是等一会再试。这样才能让模型在失败时做出合理的应对而不是慌不择路地编答案。4.3 长任务与流式输出的配合问题研究决策系统有些任务执行时间很长动辄几十秒。问题在于模型发出工具调用请求后通常会在几秒内等待结果。如果工具迟迟不返回模型端的逻辑就会出现真空期表现得像卡住了。这里我们试验过两种方案。第一种是让MCP工具尽快返回一个任务已接收的确认结果然后让系统内部异步执行真正的流程。第二种是采用任务ID加进度回调的方式模型拿到任务ID之后可以轮询或订阅进度。最终我们选了第二种因为它更自然。流程是这样模型调度器发出请求系统立即返回一个researchTaskId系统后台开始执行DAG流程每个节点完成时更新进度状态模型每隔一段时间调用一个查询任务进度的工具获取最新的任务进度和前序节点的结果摘要整个过程结束后模型再调用一个获取最终结果的工具拉取完整的结论和证据链。这套方案上线后长任务不再显得卡死模型可以在任务执行期间给用户输出阶段性的反馈比如我已经完成了数据采集正在分析三个候选归因预计还需要10秒。这个细节对用户体验的影响极大因为用户能感知到系统正在工作而不是干等。4.4 权限与数据脱敏的复杂度研究决策系统一旦联动到真实业务数据权限问题就会立刻浮出水面。不同角色能看的数据范围不一样如果不做隔离后果非常严重。我们最终把MCP工具分成了三层权限控制调用权限谁可以调用这个工具。比如普通成员只能调用查询类工具管理者才有权限调用导出和写入类工具。参数权限同一个工具不同人能看到的数据范围不同。比如区域经理只能传自己区域的维度值传其他区域会直接报错。结果脱敏部分工具返回的数据要经过脱敏处理屏蔽掉手机号、身份证号、内部备注等敏感字段。脱敏放在数据访问层做不在MCP层做这样不管什么入口触达数据脱敏逻辑都能生效。这里有一个很关键的教训权限判断一定要做在服务端而不是依赖模型去判断该不该调用某个工具。因为模型非常容易被绕过你告诉它某某人没有权限它可能会想方设法换一种方式去问比如换个措辞重新描述工具参数。另外权限策略要定期review。我们在上线初期给一个查询工具设置的权限范围偏宽结果有人在对话中查到了其他部门的数据虽然没有出事但这一事件瞬间让团队对权限重视程度上了几个台阶。5. 现在这个系统能做什么能力边界与落地效果5.1 一个完整的研究决策链路示例用我们最核心的一个业务场景来演示一下现在的系统能力上限。假设业务负责人问过去一个季度我们的转化效率在哪个环节下降最明显系统收到这个问题后整个执行链是这样跑的第一步意图识别和方案生成。模型分析出这个问题需要做分段效率分析于是生成一个包含四个节点的DAG拉取线索阶段的数据、拉取销售跟进阶段的数据、拉取成交阶段的数据、拉取各阶段转化率变化。第二步调度器执行DAG。四个节点分别调用MCP工具查询指标层数据每个节点返回时调度器自动生成结构化摘要写入证据链。第三步异常筛选与归因候选。规则引擎先做统计判断计算各阶段转化率的环比变化率锁定了销售跟进阶段转化率从上一季度的23%下降到17%这个显著变化。然后模型基于运营日志和团队会议记录等文本数据生成三个候选归因跟进时效下降、线索质量下滑、话术调整后转化率波动。第四步结论生成与证据链整理。模型综合量化证据和文本证据输出结论主要下降集中在销售跟进阶段初步指向线索响应时效从2小时延长到6小时后转化率同步下滑建议优先排查响应时效。同时系统自动附上了响应时效与转化率的时间序列对照数据作为证据。整条链路运行下来大约是25秒用户获得的不只是一个结论还有完整的证据路径。可以直接把这份报告转发到复盘会不需要再手动整理。5.2 能力边界系统不能做什么尽管系统做到了上述程度我们还是清醒地知道它的能力边界在哪里。第一个边界是深度归因。系统可以给出候选归因并排序但它无法像资深分析师那样基于多年经验、行业认知和对业务细微变化的感知做出深度的因果判断。比如某个渠道新增了一批高价词导致转化率虚降这种洞察需要人对业务上下文非常熟悉系统目前只能提供可能性提示最终定性还是需要人来判断。第二个边界是数据质量。系统再聪明也是建立在数据质量之上的。如果原始数据存在大量缺失、错误或口径不一致系统产出的结论就会出现偏差。我们在实际使用中遇到过几次这样的情况指标层的数据清洗逻辑升级后导致历史口径不一致系统给出的同比结论明显失真。后来我们在证据链里加入了数据质量标记当系统检测到某指标的可信度低于阈值时会在结论中主动提示该结论基于不完整数据仅供参考。第三个边界是突发未知事件。系统擅长在已知的维度里做分析但对于完全无法预知的事件比如突发的市场变化、意外的人事变动它只会把这些作为异常文本记录下来很难自行建立因果关系。这种时候系统的价值更多是及时暴露异常而不是解释异常。明确边界有一个非常重要的好处使用者的信任度会更高。如果你试图让系统包打天下用户会在某一次失败后立刻失去信心。如果系统清晰地标出哪些事情它能做好、哪些不能用户就会在能力范围内放心地使用它。6. 关于长成的反思架构演化的启示6.1 为什么一个壳会长成系统因为数据闭环跑通了回到标题的问题一个套壳MCP为什么长成了研究决策系统如果用一句话回答因为套壳之后数据闭环跑通了。闭环的起点是用户需求。套壳最初只是让AI能调用数据但用户接着就会说帮我分析于是你要加编排要分析就得有依据于是你要加证据链分析完了用户还会说盯紧点别等我问了才告诉我于是你要加主动监控。每一步都是为了把这个闭环的某个缺口补上补着补着它就长成了系统。这个过程不是规划出来的而是被使用逼出来的。所以如果你发现自己手头有个项目正在经历类似的演化我的建议是**不要抗拒演化但也不要无脑膨胀。**每一步都要想清楚这次增加的能力是否补上了闭环的某个缺口如果答案是肯定的就放心去做如果只是为了显得强大那多半是不必要的。6.2 演化过程中最该坚持的三件事回顾整段路程有三件事我们从头到尾都没有妥协过现在看是极其正确的坚持。第一件是可回放。所有研究任务都必须有traceID所有结论都必须有证据链。这件事在最早期做成本很低但如果等系统复杂之后再补几乎不可能补上。你可以没有精美的界面但你不能没有追溯能力。第二件是可降级。系统里的每一个关键路径都必须有降级方案。MCP工具挂了怎么办数据访问层返回超时怎么办大模型调用失败怎么办我们为每一项都准备了降级路径确保系统在故障时不是直接崩掉而是以更低的能力水平继续服务。运行半年多来降级路径被触发过很多次每一次都避免了严重的线上问题。第三件是可解释。系统的每一步决策逻辑都应该是人能够理解的。我们尽量避免把所有逻辑都塞给模型做而是用规则引擎处理确定性问题用模型处理开放性问题。这样的系统也许不如全用模型驱动看起来炫酷但它的行为是可以被理解的是可以被修正的。对一个实际用于业务决策的系统来说这比任何花哨功能都重要。6.3 什么时候应该主动踩刹车系统演化不是单行道不是所有功能都是越多越好。我们中间也走过一段弯路有一阵子我们觉得既然系统有分析能力不如把方案推荐、项目规划、甚至人员绩效评估也塞进去。后来在一次模拟测试中发现系统在绩效评估上给出的建议是极度片面的——它只看到了量化指标完全忽略了很多无法量化但同样重要的因素。好在我们在上线之前踩了刹车把这类过于主观的决策功能全部砍掉了。从那以后我们定了一个规矩**任何新增能力必须回答清楚系统在这个任务中扮演什么角色、人类保留什么决策权这两个问题才允许进入开发。**如果角色的边界模糊或者人类决策权无法清晰保留那这个能力再酷也不上。这不是保守而是对系统负责。因为研究决策系统的最终价值不是替代人类做决策而是把人类做决策所需的信息、证据、推理过程整理到最清晰的状态。这种定位越早想清楚越好。做完这套系统之后我有一个比较深的体会很多大系统不是一开始设计出来的而是在持续服务真实需求的过程中一层一层长出来的。你不需要一开始就想清楚最终形态但你需要在一开始就把那些将来会增加成本的基础能力比如可审计、可回放、可降级想好。这些能力在系统只有三个工具时做只要一下午在系统有几十个工具时再做可能就是好几周甚至几个月的工作量了。我们算是运气好在还来得及的时候做了对的选择。如果你正在做类似的东西以上这些路径和教训应该能给你一个参考。
