企业官网建设流程全解析

1. 这期周刊为什么把 MCP 放在第一条

先说结论：2026 年 W37 这一周，如果你只打算花半小时跟进技术动态，那就把时间全砸在 MCP 上。这不是因为它新鲜，而是因为它已经从"一个协议规范"变成了"一整条工具链的公共接口层"。我翻了一圈这周的热搜词，mcp、mcp协议、mcp是什么、mcp怎么被调用的、mcp host和mcp server、mcp服务器、mcp本地文件、codex配置mcp、cursor 好用的mcp、蓝湖mcp、figma mcp、devspace mcp、catia mcp、通达信 股票软件 本地数据 mcp——你会发现一个很明显的信号：MCP 的讨论重心已经从"概念科普"滑向了"具体某个软件怎么接"。

这个滑移非常关键。任何一个协议，只要开始出现"XX 软件怎么接 MCP"这种长尾问题，就说明它跨过了早期采用者的门槛，进入了工程落地阶段。早期大家问的是"这东西能干嘛"，现在问的是"我手上这个工具怎么让它说话"。这两个问题的难度完全不是一个量级。

1.1 从"协议是什么"到"我的工具怎么接"的转折点

我自己的观察是，MCP 这一轮爆发有三个触发条件同时满足了。

第一是宿主端（host）的普及。当主流编辑器、IDE、终端工具都开始内置 MCP 客户端能力，普通开发者不需要自己写客户端就能用，接入成本从"写一个 client"降到"填一段配置"。第二是服务端（server）的模板化。现在写一个 MCP server 基本就是选语言、选 SDK、定义 tools/resources/prompts 三件套，一个下午能跑通。第三是场景被验证了——本地文件读写、数据库查询、设计稿读取、股票数据拉取，这些高频但琐碎的需求，用 MCP 统一封装之后，复用性极高。

所以这周热搜里出现mcp本地文件、通达信 股票软件 本地数据 mcp这种词，一点都不意外。大家发现 MCP 最爽的用法不是接什么云端大服务，而是把本地那些"数据在但不好用"的东西暴露出来。

1.2 热搜词里藏着的三条真实需求线

我把这周和 MCP 相关的词做了个粗略归类，大致是三条线：

这三条线的难度是递增的。概念澄清看一篇就够，工具接入看文档加试错，自建服务才是真正吃功夫的地方。周刊的价值就在于，把这三条线里最容易卡住的点提前标出来。

提示：如果你现在还在"mcp是什么"阶段，别急着去配codex配置mcp，先把 host 和 server 的职责边界搞清楚，否则配置报错你都不知道是哪一端的问题。

1.3 一个容易被忽略的细节：MCP 的调用链到底长什么样

很多人配 MCP 配不明白，根子在于没理清调用链。我用最直白的话讲一遍。

你（用户）在 host 里输入一句话，host 里的大模型决定"我需要调用某个工具"，于是 host 作为 MCP client 向 MCP server 发起请求，server 执行完把结果返回给 host，host 再把结果喂回模型，模型生成最终回答。整条链路里，模型不直接连 server，server 也不认识模型，中间全靠 host 做桥。

这个结构决定了几个实践中的坑：server 挂了，host 会报连接错误而不是模型错误；server 返回的数据格式不对，模型会"看不懂"而不是报错；host 的权限配置决定了 server 能拿到什么上下文。理解了这条链，mcp怎么被调用的这个问题就自解了。

2. Agent 开发这周在吵什么：框架、评估与记忆

Agent 这条线这周的热度一点不比 MCP 低。agent、agent开发、ai agent、agent项目、agent框架、agent架构、agent开发学习路线、agent evals、agent画图、ai agent for beginners、ai agent skill memory mcp、hermes agent、pi agent、pi agent官网——词很多，但真正有信息量的争论集中在三个点上。

2.1 框架选型：别在"哪个框架最好"上浪费时间

我见过太多人在 agent 框架选型上纠结半个月，最后发现纠结的那些差异在实际项目里根本体现不出来。这周热搜里agent框架、agent架构反复出现，说明这个焦虑还在蔓延。

我的建议很直接：先看你的宿主语言和部署环境，再看框架的抽象层级。如果你的团队是 TypeScript 栈，那就优先选 TS 生态的框架，别为了"某个框架 star 多"去跨语言。跨语言的代价在 agent 项目里会被放大，因为 agent 项目天然要频繁调试、频繁改 prompt、频繁看中间状态，语言不顺手会拖垮迭代速度。

至于抽象层级，高抽象的框架上手快但黑盒多，出问题难定位；低抽象的框架代码量大但每一步都看得见。我的经验是，第一个 agent 项目用低抽象的，把链路走通一遍；第二个项目再考虑用高抽象的提效。反过来做，你会在第一个项目里被黑盒坑到怀疑人生。

2.2 Agent Evals：这周最值得认真对待的话题

agent evals出现在热搜里，我挺欣慰的。因为过去大半年，agent 圈子的通病就是"能跑 demo，没法证明它稳定"。Evals 就是来解决这个的。

Agent 的评估和传统软件测试完全不是一回事。传统测试是确定性的：输入 A 必然输出 B，断言相等就行。Agent 的输出是概率性的，同一个输入可能给出三种不同但都合理的回答。所以 agent evals 的核心不是"对不对"，而是"在可接受范围内稳不稳"。

我实际用下来，比较靠谱的做法是三层评估：

• 结果层：最终任务是否完成。比如"帮我把这份数据整理成表格"，就看表格有没有生成、字段对不对。
• 过程层：中间步骤是否合理。有没有绕远路、有没有调用不该调用的工具、有没有陷入循环。
• 成本层：token 消耗、调用次数、耗时。一个能完成任务但烧掉十倍 token 的 agent，在生产环境里是不可接受的。

这三层里，过程层最难做，也最有价值。我的做法是把 agent 的每一步 trace 都存下来，人工抽检几十条，找出高频的"无效步骤"模式，然后针对性优化 prompt 或工具描述。

注意：别一上来就追求全自动 evals。先用人工抽检建立 baseline，等你知道"好的 agent 行为长什么样"之后，再把这套判断标准固化成自动评估。

2.3 Skill 与 Agent 的区别：一个被问烂但确实重要的问题

skill和agent的区别、harness和agent区别这两个词这周都在榜上。我用一个类比说清楚。

Agent 是一个"会自己决定做什么的人"，Skill 是这个人"会的一项具体技能"。Agent 负责规划、决策、调度；Skill 负责执行某个明确的任务。Harness 则是"这个人工作的环境"——包括他能用哪些工具、能看到哪些信息、有什么约束。

为什么这个区分重要？因为它决定了你的架构怎么切。如果你把太多决策逻辑塞进 skill，skill 就变成了小 agent，复用性崩了；如果你把太多执行细节塞进 agent 的 prompt，agent 就变成了硬编码脚本，灵活性没了。清晰的边界是：决策归 agent，执行归 skill，约束归 harness。

这周还有个词ai agent skill memory mcp挺有意思，它把 skill、memory、mcp 三个概念串在一起了。我的理解是：skill 是能力，memory 是上下文，mcp 是能力的外部供给通道。三者配合，agent 才能既知道自己会什么，又记得之前发生过什么，还能随时接入新能力。

3. TypeScript 生态的这波"版本阵痛"

TypeScript 这周的热搜词密度很高：typescript、typescript面试、typescript教程、typescript ai、typescript 从入门到项目实践、typescript 命名空间 declare global、typescript = [{}]、vue 类型工具与现有 typescript 7 不兼容、选项"baseurl"已弃用，并将停止在 typescript 7.0 中运行、github typescript vue springboot。这里面有学习需求，但更值得注意的是两个"不兼容"信号。

3.1 TypeScript 7.0 的弃用警告不是小事

选项"baseurl"已弃用，并将停止在 typescript 7.0 中运行这条，我建议所有还在用baseUrl做路径映射的项目立刻重视。baseUrl这个选项在历史上被大量项目用来简化 import 路径，但它的语义一直有点模糊，和paths配合时行为不够直观。

TypeScript 团队决定在 7.0 移除它，意味着你现在写的baseUrl: "./src"这类配置，未来会直接报错。迁移方向是用paths显式声明映射，或者干脆用 package.json 的imports字段。我实测下来，纯paths方案虽然配置啰嗦一点，但行为可预测性强很多，尤其是 monorepo 场景。

迁移的时候有个坑：baseUrl一旦移除，所有依赖它做"裸模块名解析"的 import 都会失效。你得先把这些 import 找出来，逐个改成相对路径或显式映射。我一般用tsc --noEmit配合编辑器的"查找所有引用"来扫，比盲目改要快。

3.2 Vue 类型工具与 TS 7 的兼容问题

vue 类型工具与现有 typescript 7 不兼容这条，本质上是生态滞后于语言版本的老问题。Vue 的类型工具链（比如某些宏的类型推导、defineProps的复杂类型处理）依赖 TypeScript 的内部 API，而 TS 7 对这些 API 做了调整，导致类型工具暂时跟不上。

遇到这种情况，我的处理原则是：生产项目不要追 TS 的最新大版本，等生态跟上再升。语言版本升级带来的收益，通常远小于生态不兼容带来的调试成本。你可以开一个分支试升级，把报错收集起来，等主要依赖都发兼容版本了再合并。

至于typescript 命名空间 declare global这个热搜，我猜是有人在写全局类型声明时踩坑了。declare global只能在模块文件里用，而且必须配合export {}让它变成模块，否则会报错。这个细节文档里有，但很容易被忽略。

3.3 面试向的 TS 知识：别只背概念

typescript面试这个词每周都在，说明需求稳定。但我发现很多人准备 TS 面试的方式是背"什么是泛型""什么是联合类型"，这在 2026 年已经不够了。

现在面试官更爱问的是：你怎么用类型系统表达业务约束？比如"这个函数的参数必须是某个联合类型的一个，且返回值类型随参数变化"——这就是条件类型加泛型的实战。再比如"怎么保证一个对象的所有 key 都来自另一个对象的 value"——这是keyof和映射类型的组合。

我的建议是，准备面试时少背定义，多写几个"用类型把非法状态排除掉"的例子。这类例子能同时展示你对类型系统的理解和工程判断，比背概念有说服力得多。

4. WebGPU 与 WebAssembly：浏览器里的高性能计算

这周热搜里WebAssembly、WebGPU、splat.js、纯 javascript + webgpu 的 3d 高斯泼溅处理方案这几个词连在一起，指向一个很明确的方向：浏览器端的高性能图形与计算正在从"能跑"走向"好用"。

4.1 3D 高斯泼溅为什么突然火了

高斯泼溅（Gaussian Splatting）是一种三维场景表示方法，简单说就是用一堆带颜色和透明度的"椭球"来重建场景，渲染速度快、效果真实。它火起来的原因是：相比传统网格建模，它从照片重建场景的门槛低很多，而且渲染性能好。

splat.js这个库的定位就是"纯 JavaScript + WebGPU 的 3D 高斯泼溅处理方案"。注意"纯 JavaScript"和"WebGPU"这两个限定词。纯 JS 意味着不需要编译工具链，前端开发者直接就能用；WebGPU 意味着渲染性能比 WebGL 有质的提升，尤其是大量泼溅点的并行处理。

我实际试过类似的方案，最大的感受是：WebGPU 的 compute shader 才是高斯泼溅在浏览器里跑得动的关键。泼溅点的排序、投影、混合，这些计算量巨大的步骤，用 compute shader 并行处理，比在 CPU 上快一个数量级。如果你的方案还在用 WebGL 硬扛，性能瓶颈会非常明显。

4.2 WebAssembly 在 2026 年的真实定位

WebAssembly这个词这周出现，我猜和 agent 工具链、或者浏览器端计算有关。WebAssembly 的定位这几年其实越来越清晰了：它不是用来"替代 JavaScript"的，而是用来"把重计算搬到浏览器"的。

典型场景是：图像处理、音视频编解码、物理模拟、加密运算。这些场景的共同点是计算密集、逻辑稳定、对性能敏感。用 Rust 或 C++ 写好，编译成 wasm，在浏览器里跑，性能接近原生。

但 wasm 也有它的代价：和 JS 的互操作有开销，调试体验不如 JS，包体积会变大。所以我的判断标准是：只有当这段计算确实是瓶颈，且逻辑足够稳定不会频繁改，才值得上 wasm。为了"技术先进"而把简单逻辑塞进 wasm，是典型的过度工程。

4.3 WebGPU 的兼容性现状与降级策略

WebGPU 虽然性能好，但兼容性仍然是绕不开的问题。不同浏览器、不同平台的支持程度有差异，尤其是移动端和老设备。

我的做法是准备两套渲染路径：优先走 WebGPU，检测不支持时降级到 WebGL。降级不是简单的"换个 API"，而是要在架构上把渲染逻辑抽象出来，让上层业务代码不感知底层用的是哪个。这层抽象会增加前期工作量，但能避免"上线后发现一半用户打不开"的灾难。

提示：WebGPU 的 device lost 处理一定要写。GPU 资源被系统回收是常态，不处理的话用户会遇到"页面突然白屏"。

5. 那些看起来零散但值得一说的热搜

热搜词里还有一些单点，单独拎出来说说，因为它们各自代表了一类真实需求。

5.1 设计工具与 MCP 的结合：蓝湖、Figma

蓝湖mcp、蓝湖mcp使用、figma mcp、figma mcp token在哪获取、figma mcp怎么运用在trae这几个词，指向的是"设计稿到代码"这条链路。

设计工具接 MCP 的价值在于：让 agent 能直接读取设计稿的结构化信息（图层、样式、间距、组件），而不是靠人肉截图描述。这能大幅减少"设计稿和实现不一致"的返工。

figma mcp token在哪获取这个问题说明接入的第一步就卡住了——token 的获取路径。一般来说，这类 token 在账号的设置或开发者选项里生成，具体位置各平台不同，但逻辑都是"生成一个访问凭证，填到 MCP 配置里"。我的建议是，token 权限给最小必要范围，别图省事给全权限。

5.2 传统软件的 MCP 化：通达信、CATIA

通达信 股票软件 本地数据 mcp和catia mcp这两个词特别有意思，因为它们代表的是"传统桌面软件 + MCP"这个组合。

通达信是股票软件，本地有大量行情数据；CATIA 是工业设计软件，本地有大量模型数据。这些软件的共同点是：数据在本地、格式私有、没有现成的 API。MCP 在这里的价值就是做一个"适配层"，把这些私有数据暴露成 agent 能理解的结构。

这类项目的难点不在 MCP 本身，而在数据解析。你得先搞清楚这些软件的数据存在哪、什么格式、怎么读。MCP 只是最后那层"包装"。我见过有人一上来就写 MCP server，结果发现数据根本读不出来，白忙一场。先解决数据可读，再解决协议对接，这个顺序不能反。

5.3 安全工具与 MCP：codex 联动 burp

codex联动burp mcp这个词指向的是安全测试场景。把安全测试工具通过 MCP 暴露给 agent，让 agent 能自动发起测试、分析结果。

这个方向很有潜力，但我要提醒一句：安全类工具的自动化一定要有边界和审计。Agent 自动发起的测试请求，必须记录、必须可控、必须有明确的授权范围。否则很容易从"测试"变成"事故"。这不是技术问题，是工程纪律问题。

6. 这周我自己的实践记录

最后分享两个我这周实际动手的小实验，都是围绕 MCP 的。

第一个是本地文件 MCP server。我用它把几个常用目录暴露出来，让 agent 能直接读项目文档、日志、配置文件。实测下来最大的收益不是"省了复制粘贴"，而是 agent 能主动去查它需要的信息，而不是等我喂。这个转变很微妙但很重要——agent 从"被动接收"变成了"主动获取"。

第二个是给一个内部工具写 MCP 封装。这个工具原本只有命令行接口，我把它包成 MCP server 之后，agent 就能调用了。踩的坑是：命令行工具的输出是给人看的，格式不规整，agent 解析起来很吃力。后来我在 server 里加了一层结构化转换，把输出转成 JSON 再返回，效果立刻好了。MCP server 不只是转发，还要做适配，这个认知是我这周最大的收获。

如果你也在做类似的事，我的建议是：先把一个最小的 server 跑通，哪怕只暴露一个 tool，然后再逐步加。别一上来就设计一个大而全的 server，那样你会在调试上耗掉所有耐心。