企业官网建设流程全解析

如果你在技术社区待过一段时间，大概对“套壳”这个词不陌生。它通常带着点调侃：外面包一层自己的注册逻辑，里面全靠别人的模型能力，没什么技术含量。我最初做的一个内部小工具，就是标准的套壳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%。这不一定是作弊，而是它对自己的生成内容天然更有信息优势。

所以我在评分链路上做了分离设计。每个候选方案先送给一个独立的轻量模型，它只负责做两件事：列出支持证据，列出反对证据，各自标注强度。规则层再按三个维度加权计算最终得分：

单项得分都控制在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——它长成今天这样，不是因为我一开始就想得很清楚，而是因为真实的研究决策需求一直在对技术架构提出新问题。这种“被需求推着生长”的过程，让整个系统每一步都有据可依。