企业官网建设流程全解析

这个项目最开始其实特别不起眼，说难听点就是个“套壳”：把几个搜索引擎的API、一个网页抓取服务、一个本地文件读写工具，统一包成一个MCP Server丢给大模型用。可三个月之后再回头看，它已经变成了一套带有检索、筛选、交叉验证、置信度评估、最终推荐的研究决策系统。MCP本身只是协议层的东西，按理说它不该“长”出业务逻辑来，但现实是它确实长出来了，而且长得还挺顺理成章。

这篇文章就从头复盘一下，这个“套壳MCP”到底经历了什么，才会一步步变成研究决策系统。我尽量讲得实在一点，把中间层的设计、上下文管理的权衡、评估体系的搭建，还有那些踩过的坑都说清楚。不管你是打算做个简单的MCP工具，还是想让MCP承担更复杂的任务，这里面都有可以参考的东西。

1. 项目是怎么长歪的：从一个套壳MCP说起

1.1 最初的“套壳”长什么样

三个月前的第一版，功能列表用一行字就能写完：大模型没有实时信息，所以我把搜索和网页抓取能力用MCP暴露给它。核心就三个工具：web_search、fetch_page、save_note。大模型收到用户问题后，自己决定要不要调用搜索，拿到搜索结果后自己去抓网页，最后把要点存到本地Notes里。整个过程全部由模型自由发挥，服务器端不掺和任何判断。

当时选MCP而不是直接给每个模型写Function Calling，纯粹是出于一个很自私的理由：我不想在四个不同的模型API里各写一遍工具定义。MCP等于把我这边的工具调用逻辑标准化了，模型那边只要能连MCP Client，就能拿到我这边同一套工具。今天换个模型，配置不用动；明天加个工具，模型那边也感知不到代码变化。说白了，最开始选MCP就是图的省事。

这一版的运行模式可以概括为“模型主导、工具执行”。模型说搜什么就搜什么，抓到什么网页就抓什么网页，存不存Notes也看模型心情。在大多数简单问答场景下，这套东西是够用的。你问“2025年的某个技术大会到底哪天开”，模型调一下搜索，抓两个页面，答案就出来了。

1.2 为什么一开始非要选MCP

这里稍微展开说下MCP是什么，因为它决定了后面所有演化的方向。MCP全称是Model Context Protocol，模型上下文协议，可以理解成给大模型和外部工具之间定的一套标准USB接口。以前每个模型厂商都有自己的插头，你得给ChatGPT配一个转接头，给Claude配一个转接头，给国产模型再配一个转接头；MCP出来之后，大家都用同一个插头，工具方只要做一次适配，所有支持MCP的模型都能用。

这套协议里最核心的几个概念就是工具、资源和提示词。工具是给模型执行的动作，比如搜索、抓网页、读文件；资源是暴露给客户端去读的静态数据，比如文档、表格、目录列表；提示词则是预先写好的模板，负责引导模型按某个套路干活。最初我基本只用工具这一个能力，资源和提示词都是后面被逼着用起来的。很多做MCP的人和我一样，一开始都是只盯着Tools，觉得这就够了，后来才发现资源的用处被严重低估了。

还有一点，MCP Server不挑语言，Python、Node、Go都能写，只要有官方SDK或者按JSON-RPC 2.0自己实现一版就行。我当时图省事用了Python的mcp官方SDK，几行代码就能暴露一个工具。这也为后面快速迭代打下了基础，毕竟改一个工具函数比改一套独立服务要快得多。

1.3 失控的信号：用户开始问“你推荐哪个”

真正的转折点，是第一批真实用户用了一周之后。他们不再满足于“给我几篇资料”，而是开始问“你推荐哪个”“如果只能选一个，你选什么”“结合我们目前的约束条件，直接给结论”。这类问题一出现，原本的套壳架构就撑不住了。

原因很简单：给用户罗列五个候选方案和五个来源，看起来信息充分，实际上是把判断负担全甩给了用户。我真正想要的输出是一个带倾向性的结论：在A和B之间，综合考虑成本、维护难度、团队熟悉度之后，系统建议选哪个，理由是什么，风险在哪里。而要做这种研究型决策，单靠大模型临场发挥是不行的，因为模型每次调用只能看到当前窗口里的内容，它没法像人一样，先收集资料，把资料归档，过几天再回来综合判断。

于是，这个套壳MCP开始往“系统”的方向转变，这已经完全超出了套壳的范畴。

2. 拆解“研究决策系统”的成型过程：不是设计出来的，是长出来的

2.1 从单轮调用到多阶段管线

第一件事，是把原来“模型自由发挥”的模式，改造成固定阶段的研究管线。我参考了现实里做调研报告的工作方式：先收集线索，再筛选信源，然后深读关键材料，接着做交叉验证，最后给出结论。对应的，系统也划分成了几个阶段：

• 检索阶段：根据问题拆解出多个搜索词，分别去搜，收集原始链接和摘要。
• 筛选阶段：根据标题、摘要、域名权重，过滤掉明显不相关的链接。
• 深度阅读阶段：对筛选后的关键页面抓取正文，生成摘要。
• 交叉验证阶段：把不同来源的信息放在一起比对，找矛盾点和共识点。
• 决策阶段：综合前面所有材料，按预设的评估维度打分，给出推荐结论。

每个阶段在MCP Server里就是一个或者几个工具，模型按照一套流程依次调用。这一步做完，套壳的性质就变了，它不再是“给模型加个手”，而是“给模型加了一套工作方法”。工具还是那些工具，但组合方式从自由发挥变成了流水线。

有人可能会问：为什么不直接让模型自己规划这五个阶段？答案是：模型会的，但不是每次都会。同样的模型，状态好的时候能规划得很好，状态差的时候上来就抓一堆垃圾页面。把管线固化在服务器端，等于把“靠谱”这件事从模型身上剥离出来，变成系统层面的确定性。这也让我后来深刻理解了一件事：研究决策系统的核心不是模型能力，而是流程约束。

2.2 关键转折点：中间结果落盘与上下文管理

管线化之后，立刻遇到一个致命问题：上下文放不下了。检索阶段返回几十个链接，深度阅读阶段每个页面正文动辄上万字，如果全部塞给模型，窗口早就爆了。MCP官方文档里有一个很关键的设计理念：服务器只提供数据，但如何选择性地把数据暴露给模型，是服务器端要主动控制的事。

解决办法是引入中间结果存储。所有阶段的中间产物都不直接写进对话上下文，而是落盘存储，做成可检索的、独立的资源。第一阶段生成的候选链接存进表格，第二阶段筛选出来的重要页面单独存成Markdown文档，第三阶段的阅读摘要按来源编号保存。模型在每个阶段看到的，只是这个阶段最必要的输入和可操作的下一步动作。

这里我用到了MCP的资源能力。以前我总觉得MCP的Resource是个鸡肋，工具不够用吗？为什么要暴露资源？真实场景里才发现，研究管线的中间结果是天然的资源。它们既不是给模型执行的工具，也不是临时性的对话内容，而是一类可以反复读取、按需调用的结构化数据。比如决策阶段，模型只调用read_dataset读完筛选结果，而不需要从对话历史里翻找早期内容。这样一来，上下文窗口的压力大大下降，模型每阶段的输入都变得精简可控。

落盘方案本身也很简单，没有上数据库，就是本地目录加JSON文件。搜索阶段的结果存成round_1_candidates.json，阅读阶段存成round_2_notes.md。简单可靠，中途崩了也能从文件恢复。到后面如果需要支持多人协作，再考虑迁到独立的存储服务也不迟。

2.3 评估与置信度：让系统敢说“不确定”

第三个关键变化，是引入了置信度和评估维度。这是“研究决策系统”和“高级搜索工具”之间最明显的一道分水岭。普通搜索工具把十条链接排好序给你就完事了，研究决策系统则必须回答一个问题：给出这个结论之前，你对这个结论有多大的把握？依据是什么？证据链是否完整？

我在Server端设计了一个generate_assessment工具，让模型在进入决策阶段之前，先按几个固定维度给出评估：

• 信息覆盖度：关键信源是否都已覆盖，有没有明显缺失的维度。
• 来源一致性：多个来源之间是否达成共识，还是存在显著分歧。
• 时效性：材料是否足够新，有没有过期的可能。
• 可验证性：核心结论能否通过一级信源验证。
• 综合置信度：一个0到100的分数，低于60分时系统要明确告诉用户“这个结论不建议直接用于决策”。

这一层设计最反直觉的地方在于：它不是在追求“结论更聪明”，反而是在逼系统承认自己不知道。可实际跑下来，效果很好。因为用户需要的并不是一个永远自信的AI，而是一个能说“这个答案我只能有六成把握，因为一手信源太少，主要依据来自二手博客”的系统。置信度机制一旦建立，整个系统的可信度反而大幅上升。

3. 核心实现细节：三个层到底怎么搭

3.1 工具层：每个工具只做一件事

整个系统里，最容易写坏的就是工具层。很多人做MCP Server时，喜欢把工具做得又大又全，一个函数里又是搜索又是解析又是存储。这样短期省事，但后期灾难。搜索失败时你分不清是哪个环节出了问题；模型调用时也容易因为参数太长而报错。

我这边反着来，每个工具只负责一件极小的事情。拿检索链举例，拆成了四个独立的工具：

• search_engine_query：只执行一次搜索，返回标题+链接+摘要，不做任何过滤。
• chunk_filter_candidates：传入一批候选链接，按规则过滤，返回保留/剔除的原因。
• page_fetch_markdown：抓取单个页面，只输出正文转Markdown的结果。
• extract_key_points：基于页面正文，输出固定格式的要点列表。

这种颗粒度的好处有三个。第一，可调试。哪个环节返回了垃圾数据，一眼定位。第二，可复用。page_fetch_markdown不光给研究管线用，任何时候模型需要读网页都可以直接调。第三，可测试。每个环节都是纯函数式的输入输出，我可以在不连接大模型的情况下，单独跑一遍全链路测试。

工具定义时，描述要写得极其具体。MCP工具的描述不是给用户看的，是给模型看的。同一个search_engine_query，如果描述写成“搜索互联网”，模型调用时可能不知道什么时候用；如果写成“当用户需要最新信息、实时数据或外部网页内容时调用，每次搜索返回最多10条结果”，模型就很容易判断适用条件。这个细节，我个人认为是整个MCP工程里性价比最高的一项优化。

3.2 决策层：把“研究”变成可计算流程

决策层是这套系统最核心的部分，它负责把开放式的研究过程，变成可计算、可复现的判断流程。我的实现思路是：不是在对话里让模型“想一想然后回答”，而是让模型按固定的节奏产出一份结构化的决策报告。

具体来说，决策阶段有一个专用的提示词模板，里面规定了报告的结构：背景重述、候选方案列表、评估维度、各维度打分、矛盾点罗列、最终建议、置信度说明。这几个模块必须按顺序产出，缺失哪个模块，Server端会直接报错，要求补齐。

评估维度这块，我允许用户动态传入，而不是写死在系统里。技术选型场景默认用“成本、上手难度、社区活跃度、扩展性、风险”；采购决策场景则可能换成“报价、交付周期、售后响应、合规、可替代性”。维度变化时，不需要改代码，只需要在问题里带上维度列表，系统就会把它作为决策框架使用。

可计算性还体现在中间产物上。候选方案会统一转成标准格式，包括名称、来源、关键论据、正反方观点。这样做是方便后续交叉验证，也方便打分。打个比方，这就像把一堆散乱的投资建议整理成同一张Excel表格，每个方案一行，维度是列，打分明明白白，不存在模糊地带。

3.3 接口层：让大模型按节奏调用

有了工具层和决策层，还差最后一步：让大模型愿意按节奏调用。这层看似简单，实际上决定了管线能不能顺利跑完。MCP Client在模型那边会暴露工具列表，如果模型乱序调用、跳过关键环节，管线就形同虚设。

我用了两个手段来控制节奏。第一，在不同的阶段，只暴露当前阶段相关的工具。检索阶段时，Server端只向客户端暴露搜索相关工具；进入评估阶段时，才暴露评估相关工具。MCP本身支持动态更新工具列表，我就在管线推进时主动刷新。模型看不到的工具，自然就不会误调用。这个做法的好处是，模型的注意力被强制集中在本阶段任务上，不容易跑偏。

第二，利用提示词模板块。MCP支持在Server端注册提示词模板，客户端可以通过prompts/list拉取。我把每个阶段的引导语都封装成模板，阶段切换时，要求模型必须重新加载对应提示词再继续。比如筛选阶段加载的提示词里会强调“宁缺毋滥，不要为了凑数保留低质量信源”，交叉验证阶段则强调“必须指出来源间的矛盾，不能只选取与预设结论一致的内容”。模板化管理，让我可以随时调整整个系统的工作风格，而不需要去改模型的系统提示词。

3.4 实操参数：上下文预算与评分公式

说完层，再给一版实际跑通的参数，供参考。这些参数不是拍脑袋定的，都是压力测试之后调出来的。

• 最大候选链接触发数：25条。超过会强制截断，因为太多了后面的深度阅读根本看不过来，太少了又容易漏掉关键信息。
• 深度阅读页面上限：8个。一次决策最多深读8个页面，按权重排序取前8，其余只保留摘要。
• 单页正文上限：12000字符。超长页面截断，只保留前12000字符，基本能覆盖正文主体，又不会撑爆Token预算。
• 置信度阈值：65分。低于65分时，系统必须在回复开头声明低置信度，并给出需要补充的信息清单。

评分公式也分享一个简化版。某项维度的分数，不是模型直接拍出来的，而是结合证据强度计算：

维度得分 = 基础判断分 * 0.4 + 信源强度分 * 0.3 + 一致性分 * 0.2 + 时效性分 * 0.1

配合这套公式，模型就不是在凭空打分，而是在做加权计算。基础判断分来自模型对材料的理解，信源强度分看是不是一手资料、域名权重是否够高，一致性分看多个来源的结论是否趋同，时效性分看发布时间距今多久。总分落在0到100之间，再由分数决定最终建议的置信区间。

这套参数用在大多数调研场景下都够用。如果你要处理更复杂的金融研报、医学临床信息，那阈值和权重都得改，我这里只是给出一个平衡性比较好的起点。

4. 从配置到跑通：一个完整的决策流程实录

4.1 环境与MCP Server配置要点

整个系统跑起来之后，最常被人问起的是两个问题：MCP Server到底怎么配，以及哪一步最耽误时间。

配置方面，因为MCP现在已经成了事实上的标准，几个主流的客户端都支持直接在配置文件里声明MCP Server。我本地用的是一个通用的配置结构，路径和参数按自己项目改即可：

{ "mcpServers": { "research-server": { "command": "uvx", "args": ["research-mcp-server"], "env": { "SEARCH_API_KEY": "your-key", "OUTPUT_DIR": "./research_output", "MAX_CANDIDATES": "25" } } } }

这里有几个容易踩坑的点。第一，环境变量里的密钥千万不要硬编码进仓库，用环境变量注入。第二，command字段建议用uvx或者npx这种包运行器，省去手动管理虚拟环境的麻烦。第三，OUTPUT_DIR一定要指定，不然中间落盘文件会写到当前目录，目录一乱后面排查问题就头疼。

另一个很实用的排查技巧：先用MCP Inspector这类工具把Server单独跑起来，直接在调试界面里测试工具调用，确认搜索、抓取、评分等工具全部返回正常，再接大模型客户端。大部分人遇到“Codex找不到MCP”或者“模型一直报工具不存在”的问题，十有八九是Server根本没起来，或者环境变量没注入成功。先用调试工具验证一遍，能排除掉一大半问题。

4.2 一个真实案例：技术选型研究

跑一个实际案例来看这个系统怎么工作。假设问题是：“我们团队想做本地优先的文档库，需要支持全文搜索和Markdown编辑，想在A、B、C三个开源项目里选一个，综合维护活跃度、协议风险、二次开发成本给出建议。”

检索阶段，系统会拆出两组搜索词，一组是“项目A markdown 全文搜索 自托管”，另一组是“项目A license 协议 风险”。之所以要拆，是因为一次搜索往往只能覆盖一个维度，维度混在一起，结果质量会明显下降。第一阶段最终返回约25条候选链接。

筛选阶段，系统会根据摘要和域名去重、剔除明显过时的内容，保留大概12条。深度阅读阶段抓取8个页面，包括官方文档、GitHub仓库主页、两个社区评测帖。交叉验证阶段发现了一个关键矛盾：项目C在Reddit上的社区活跃度很高，但实际GitHub提交频率很低。系统在矛盾的标记里明确写了一句：“社区讨论热度与代码维护活跃度不一致，建议以代码仓库真实数据为准。”

决策阶段，系统按“维护活跃度、协议风险、开发成本”三个维度分别打分。项目A在协议风险上得分最高，因为它是宽松许可证；项目B功能最全，但最近三个月提交频率下降明显；项目C社区呼声最高，但一手证据偏弱。综合加权后，系统给出的建议是项目A，置信度78分，并附带一句提醒：“如果团队未来强烈依赖导出功能，建议再关注项目B的路线图，该项存在隐性风险。”

这就是整套系统该有的产出：有结论，有理由，有矛盾点标记，有置信度。最重要的是，这些不是模型一次性生成的，而是经过五个阶段，每一阶段都有据可查，复现成本极低。

4.3 踩坑实录与排查技巧

从套壳到决策系统，一路踩坑踩出几个很有代表性的问题，整理成表格供参考。

这里我想多说一句，排查技巧里最值钱的其实不是你掌握了多少调试命令，而是你给每个中间环节留下了足够的可观测性。我把每个阶段的关键决策都追加到一条日志里，包括筛选时剔除某个链接的具体原因、打分时各维度的输入值。出了问题，打开日志就能还原当时模型的每一步判断。没有这一步，系统一旦跑偏，排查成本会非常高昂。

5. 复盘：什么项目适合长成这样，什么不适合

5.1 五个判断标准

经历这次演化之后，我对“要不要把MCP做成研究决策系统”这件事有了一个比较清醒的判断。并不是所有套壳MCP都该长成决策系统，甚至可以说，大部分MCP项目就应该停在套壳阶段。下面这五个标准，至少满足三条，再考虑往决策系统方向演进：

• 用户的输出物是一种“结论”，而不只是“信息”。如果用户拿到搜索结果就够了，那搜索套壳就到头了。
• 问题具备多源交叉验证的必要。单一信源能给答案的问题，不值得上五阶段管线。
• 答案一旦错误，代价是可感知的。技术选型错了、采购选错了、方案推荐错了，后续成本很高，才有必要引入评估与置信度机制。
• 输入信息是动态的、时效性强的。如果答案是静态知识，大模型自己就是专家，不需要研究过程。
• 你有意愿维护一套中间状态的管理机制。很多人忽略了这条，决策系统需要管状态，管失败，管恢复，不维护的话，流程很快就会腐化。

反过来，如果只是给企业内部数据库写个查询接口，或者包装一下内部API，老老实实做个套壳就很好。用决策系统的复杂度换一个简单查询场景，纯属杀鸡用牛刀。

5.2 成本账：Token、延迟、复杂度

继续劝退一波。研究决策系统的成本，比大多数人预想的要高。

Token消耗上，一次完整研究流程平均烧掉2万到4万Token，其中大头在深度阅读阶段。相比套壳MCP动辄几百Token的调用，这完全不是一个量级。延迟上，全流程跑完通常在40到90秒之间，因为要连续执行搜索、抓取、多轮生成。用户如果只想快速找个答案，这个延迟是没法接受的。

维护复杂度上，从单文件套壳变成多阶段系统，代码量至少翻三倍，测试量更是翻五倍不止。我保留了完整的回归测试集，因为改一处评估逻辑，很可能影响后续所有决策案例的输出格式。没有自动化验证，这套系统根本不敢频繁迭代。

所以，上这个系统之前，先算清楚这笔账。如果结论错了代价小，或者用户就是想在几秒内拿到参考资料，那决策系统反而是伤害体验的。

5.3 一点个人体会

写到这里，想用我在实际维护过程中最深的一条心得收尾。MCP协议本身确实很轻，轻到给任何人解释十分钟就能上手写工具。但它真正的威力，恰恰是轻之外的那一层：当工具、资源、提示词、上下文管理这些标准能力组合在一起，你就有了一个可以把“做事方法”固化下来的沙盒。我的项目从套壳演进成研究决策系统，本质上不是协议在推着我走，而是用户的需求一次次提出了新的问题，MCP只是很争气地接住了这些问题。

如果你也在做一个看似简单的MCP套壳，我的建议是：不急着按研究决策系统来设计，先把最简单的那一版跑通，然后用真实用户的问题去蹂躏它。当套壳连续三次回答不了“那你推荐哪一个”的时候，你就知道下一步该往哪长了。那时候，MCP的协议基础已经帮你把路铺好了，你只需要顺着走下去。