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是什么、什么是mcp、mcp协议、mcp host和mcp server刚听说想搞明白边界工具接入蓝湖mcp、figma mcp、codex配置mcp、cursor 好用的mcp、devspace mcp手上有工具想接上自建服务mcp服务器、mcp本地文件、springboot mcp、springboot mcp jdk想自己写 server 暴露内部能力这三条线的难度是递增的。概念澄清看一篇就够工具接入看文档加试错自建服务才是真正吃功夫的地方。周刊的价值就在于把这三条线里最容易卡住的点提前标出来。提示如果你现在还在mcp是什么阶段别急着去配codex配置mcp先把 host 和 server 的职责边界搞清楚否则配置报错你都不知道是哪一端的问题。1.3 一个容易被忽略的细节MCP 的调用链到底长什么样很多人配 MCP 配不明白根子在于没理清调用链。我用最直白的话讲一遍。你用户在 host 里输入一句话host 里的大模型决定我需要调用某个工具于是 host 作为 MCP client 向 MCP server 发起请求server 执行完把结果返回给 hosthost 再把结果喂回模型模型生成最终回答。整条链路里模型不直接连 serverserver 也不认识模型中间全靠 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 则是这个人工作的环境——包括他能用哪些工具、能看到哪些信息、有什么约束。为什么这个区分重要因为它决定了你的架构怎么切。如果你把太多决策逻辑塞进 skillskill 就变成了小 agent复用性崩了如果你把太多执行细节塞进 agent 的 promptagent 就变成了硬编码脚本灵活性没了。清晰的边界是决策归 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 安全工具与 MCPcodex 联动 burpcodex联动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那样你会在调试上耗掉所有耐心。