1. 开源雷达周刊 2026-W37 核心看点拆解这一周的开源圈信息密度相当高几个关键词几乎在同一时间窗口内集中爆发MCP、Agent、TypeScript、WebAssembly、WebGPU。单独拎出来任何一个都不算新话题但它们在这一周的交汇点非常值得聊——MCP 正在从“协议规范”走向“工程落地”Agent 从“能跑就行”走向“可评估、可观测”而 TypeScript 和 WebGPU 则在底层悄悄改变前端与图形应用的构建方式。我做开源项目跟踪有个习惯不看 star 数的绝对值看的是“这周有没有人真的拿它做出了东西”。这周符合这个标准的项目不少尤其是围绕 MCP 的周边工具链已经从早期的“玩具级 demo”进化到了能进生产环境的程度。这篇周刊我会按领域拆开讲每个方向都尽量给出可复现的路径和我自己踩过的坑而不是简单罗列链接。适合谁看如果你在做 Agent 相关开发、在评估 MCP 的落地可行性、或者单纯想跟上 TypeScript 生态和 WebGPU 图形方案的最新进展这篇内容应该能帮你省下不少自己翻仓库的时间。我会尽量把“为什么选它”和“怎么用起来”讲清楚而不是只告诉你“这个东西很火”。2. MCP 生态从协议规范到工程化落地2.1 MCP 到底是什么为什么这周讨论度突然拉高MCP 全称 Model Context Protocol直译是“模型上下文协议”。用生活化的类比它就像是给 AI 模型和外部工具之间定了一套“USB 接口标准”。以前你想让模型读本地文件、查数据库、调某个 API每个工具都要单独写适配层模型换个供应商就得重写一遍。MCP 做的事情是把这层适配标准化——工具方按 MCP 规范暴露能力模型方按 MCP 规范调用两边解耦。这周讨论度拉高的直接原因是几个主流开发工具开始原生支持 MCP 配置。比如 Codex 配置 MCP 的流程被大量讨论Figma MCP 的 token 获取方式成了热搜蓝湖 MCP 的使用也在中文社区传开。这说明 MCP 已经跨过了“协议设计”阶段进入了“工具接入”阶段。我自己的判断是MCP 的价值不在于协议本身有多优雅而在于它把“工具接入”这件事的边际成本压到了极低。以前接一个新工具要半天现在改几行配置就行。这个成本差异会直接改变 Agent 的设计思路——你会更愿意给 Agent 挂更多工具因为挂载成本低了。2.2 MCP Host 与 MCP Server 的分工以及常见误解很多人第一次接触 MCP 会搞混 Host 和 Server 的角色。简单说MCP Host发起请求的一方通常是 AI 应用或 IDE它决定“我要调用什么能力”。MCP Server提供能力的一方比如一个本地文件系统 Server、一个数据库 Server、一个第三方 API Server。注意MCP Server 不一定跑在远程。很多场景下它就是本地起的一个进程通过标准输入输出和 Host 通信。这也是为什么“MCP 本地文件”会成为热搜——大家想知道怎么让模型安全地读本地文件。我踩过的一个坑早期以为 MCP Server 必须部署成 HTTP 服务结果发现本地 stdio 模式才是大多数场景的首选。stdio 模式的好处是没有网络暴露面安全性天然更高坏处是 Host 和 Server 必须同机。选哪种模式取决于你的部署形态不是越“服务化”越好。2.3 几个值得关注的 MCP 落地场景这周热词里出现了几个很有意思的具体场景我挑三个展开说。第一个是 Figma MCP。设计师在 Figma 里画完稿通过 MCP 把设计稿的结构化信息直接喂给 AI让 AI 生成对应的组件代码。这个链路的价值在于省掉了“人工读设计稿”这一步。Figma MCP token 的获取方式之所以成为热搜是因为 token 是访问权限的凭证拿不到 token 整个链路就跑不通。一般流程是在 Figma 账号设置里生成个人访问令牌然后配置到 MCP Server 的环境变量里。第二个是通达信本地数据 MCP。这个场景很典型股票软件的本地数据格式是私有的直接让 AI 读不现实但通过一个 MCP Server 做中间层把本地数据转成模型能理解的结构就能实现“用自然语言查本地行情数据”。这类场景的通用模式是私有格式 → MCP Server 转换 → 模型消费。第三个是 Codex 联动 Burp MCP。这个组合的思路是让 AI 辅助分析网络请求。Burp 作为代理工具捕获流量MCP Server 把流量数据结构化后暴露给模型模型做分析和标注。这类场景对安全边界要求很高我的建议是只在隔离环境里跑不要在生产网络里直接挂。2.4 MCP 怎么被调用一次完整链路的拆解很多人问“MCP 怎么被调用的”我用一个具体流程说明Host 启动时读取配置文件发现注册了若干个 MCP Server。Host 按配置启动对应的 Server 进程stdio 模式或连接远程端点。Host 向 Server 发送“列出可用工具”的请求Server 返回工具清单和参数 schema。模型在对话中决定调用某个工具Host 把调用请求转发给对应 Server。Server 执行实际操作把结果返回给 HostHost 再喂回模型。这个链路里最关键的是第 3 步——工具清单和参数 schema。它决定了模型“知道有哪些工具可用”以及“怎么正确传参”。如果 schema 写得含糊模型就会传错参数这是实际开发中最常见的故障点。实操心得给 MCP 工具写描述时宁可啰嗦也不要省略。把每个参数的类型、取值范围、是否必填都写清楚模型传参的准确率会明显提升。我试过把描述从一句话扩成三句话调用成功率从六成提到了九成以上。3. Agent 开发从能跑到可评估的跨越3.1 Agent 框架选型的几个现实考量这周热词里 Agent 相关的内容占了很大比重agent 开发、agent 框架、agent 架构、agent evals、agent 学习路线、ai agent for beginners。说明这个领域正在从“早期尝鲜”走向“系统学习”。选 Agent 框架时我一般看四个维度维度关键问题常见取舍抽象层级框架帮你做了多少决策高层省事但难定制低层灵活但工作量大工具生态现成工具多不多生态好上手快但可能被绑定可观测性能不能看清每步在干什么调试成本直接取决于这个评估支持有没有内置 eval 能力决定你能不能持续迭代这周“agent evals”成为热词很说明问题——大家已经不满足于“Agent 能跑”开始关心“Agent 跑得好不好、怎么量化”。这是领域成熟的标志。3.2 Skill 和 Agent 的区别以及 Harness 和 Agent 的区别这两个问题这周都被反复问到我分别说清楚。Skill 和 Agent 的区别Skill 是“一项能力”Agent 是“一个会自主决策的执行者”。类比一下Skill 像是工具箱里的一把锤子Agent 像是拿着工具箱干活的工人。工人会判断“现在该用锤子还是螺丝刀”锤子本身不会判断。所以 Skill 通常是被 Agent 调用的而不是反过来。Harness 和 Agent 的区别Harness 是“测试/运行框架”Agent 是“被测试/被运行的对象”。Harness 负责给 Agent 提供输入、捕获输出、记录中间状态、跑评估指标。你可以理解为 Harness 是跑道和计时器Agent 是跑步的人。做 Agent 评估时Harness 的设计质量直接决定了你能不能发现 Agent 的真实问题。注意很多人把 Harness 和 Agent 框架混为一谈其实职责完全不同。Agent 框架关心“怎么构建 Agent”Harness 关心“怎么衡量 Agent”。两者可以独立选型。3.3 Agent 学习路线的务实建议“agent 开发学习路线”和“ai agent for beginners”是这周的高频搜索。我给一条我自己验证过的路径先跑通一个最小 Agent不要一上来就上框架先用最朴素的方式比如直接调模型 API 手写工具调用循环跑通一个能查天气的 Agent。这一步的目的是理解 Agent 的本质循环观察 → 决策 → 行动 → 再观察。引入一个框架选一个主流框架把上面的最小 Agent 用框架重写一遍。对比一下框架帮你省了什么、又限制了什么。加上工具给 Agent 挂 3 到 5 个工具体会工具描述对调用准确率的影响。加上评估设计几个测试用例跑一遍看 Agent 的成功率。这一步会暴露大量问题。加上可观测性接入日志和追踪看清每一步的输入输出。这个路径的好处是每一步都有明确的产出不会陷入“学了很多概念但做不出东西”的困境。3.4 Agent 执行报错的常见原因“agent execution terminated due to error”这周被搜了很多次说明这是普遍痛点。我整理了几类常见原因工具调用参数不匹配模型传的参数和工具 schema 对不上。排查方法是把 schema 和实际传参打出来对比。上下文超限Agent 循环几轮后上下文爆了。解决办法是做上下文压缩或摘要。死循环Agent 反复调用同一个工具。需要在 Harness 里加最大轮次限制。外部依赖失败工具背后的 API 挂了或超时。需要加重试和降级逻辑。这几类问题里死循环是最隐蔽的因为日志看起来“一切正常”只是永远不结束。我的做法是在 Harness 里硬性限制最大工具调用次数超过就中断并记录。4. TypeScript 生态版本迁移与类型工具的阵痛4.1 TypeScript 7 带来的兼容性变化这周“vue 类型工具与现有 typescript 7 不兼容”和“选项 baseurl 已弃用并将停止在 typescript 7.0 中运行”两条热搜指向同一个问题TypeScript 7 的破坏性变更开始显现。baseUrl被弃用这件事影响面很广因为大量老项目用它来做模块路径解析。弃用后的替代方案是paths配合moduleResolution的新配置方式。迁移时要注意先确认当前tsconfig.json里有没有用baseUrl。如果有检查所有依赖它的路径别名。逐步替换成新的解析配置不要一次性全改。实操心得大版本迁移时我习惯先在一个独立分支上跑tsc --noEmit把所有类型错误列出来按错误类型分组再决定迁移顺序。一次性改完再跑测试出问题很难定位。4.2 TypeScript 命名空间与 declare global 的正确用法“typescript 命名空间 declare global”这个搜索说明很多人在处理全局类型声明时遇到了困惑。declare global用在模块文件里用来给全局作用域补充类型。典型场景是给window挂自定义属性或者扩展第三方库的类型。一个容易犯的错误是在非模块文件里用declare global这时候它不生效因为文件本身就在全局作用域里。判断方法很简单文件里有没有import或export有就是模块文件。4.3 TypeScript 面试与实战的差距“typescript 面试”和“typescript 从入门到项目实践”同时成为热词反映了一个现实面试考的和项目用的往往不是一回事。面试爱考类型体操条件类型、映射类型、模板字面量类型项目里更常用的是基础类型、泛型约束、工具类型。我的建议是两条腿走路类型体操要会因为它能帮你理解类型系统的边界但项目里不要炫技能用简单类型解决的就别上复杂类型。可维护性比“类型写得漂亮”重要得多。5. WebGPU 与 WebAssembly图形与性能的新底座5.1 splat.js纯 JavaScript WebGPU 的 3D 高斯泼溅方案这周“splat.js”和“纯 javascript webgpu 的 3d 高斯泼溅处理方案”一起出现指向一个具体项目用 WebGPU 在浏览器里做 3D 高斯泼溅渲染。高斯泼溅是一种 3D 场景表示方法和传统网格模型不同它用大量带位置、颜色、透明度的“泼溅点”来表示场景。优点是渲染质量高、能表现复杂材质缺点是数据量大、对 GPU 要求高。WebGPU 的出现让浏览器端做这件事变得可行因为 WebGPU 提供了更接近原生的 GPU 访问能力。splat.js 的价值在于它用纯 JavaScript 实现不依赖编译工具链降低了使用门槛。实际使用时要注意浏览器必须支持 WebGPU目前主流浏览器的新版本基本都支持。泼溅点数量直接影响性能需要做 LOD细节层次处理。数据加载是瓶颈大场景建议做分块加载。5.2 WebAssembly 在 Agent 工具链里的角色WebAssembly 这周和 Agent 一起出现不是偶然。Agent 工具链里有很多“需要高性能但又要跨平台”的场景比如本地数据处理、格式转换、加密解密。这些场景用 WebAssembly 实现既能保证性能又能被多种语言的 Host 调用。一个典型模式是把核心算法编译成 WebAssembly 模块MCP Server 加载这个模块来执行实际操作。这样算法逻辑和协议层解耦算法可以独立优化和测试。5.3 WebGPU 与 WebAssembly 的组合潜力这两个技术组合起来能覆盖“高性能计算 高性能渲染”的完整链路。WebAssembly 负责计算密集的部分WebGPU 负责渲染密集的部分两者通过共享内存或缓冲区交互。这个组合在浏览器端的 3D 应用、科学可视化、实时数据处理等场景都有想象空间。我个人的观察是这个组合目前还处于“能做出 demo 但离产品化有距离”的阶段。主要瓶颈不在技术本身而在工具链和调试体验。WebGPU 的调试工具还不够成熟WebAssembly 的调试体验也比原生代码差一截。但方向是明确的值得提前布局。6. 这周踩过的坑与实操记录6.1 MCP 配置里最容易出错的三个地方这周我在配置几个 MCP Server 时反复遇到三类问题记录下来供参考。第一类是路径问题。stdio 模式下Host 启动 Server 进程时的工作目录可能和你预期的不一样。如果 Server 里用了相对路径读文件很容易读不到。解决办法是在 Server 里统一用绝对路径或者在配置里显式指定工作目录。第二类是环境变量传递。很多 MCP Server 依赖环境变量拿凭证比如 Figma token。如果 Host 启动 Server 时没有正确传递环境变量Server 会启动失败或调用失败。排查方法是先在命令行手动跑一遍 Server确认环境变量没问题再放到 Host 配置里。第三类是超时设置。有些 MCP 工具执行时间较长比如处理大文件默认超时可能不够。需要在 Host 配置里调整超时参数否则会看到“调用超时”但不知道是工具慢还是真的挂了。6.2 Agent 评估的实操框架做 Agent 评估时我用的是一个很朴素的框架准备一组测试用例每个用例包含输入和期望输出。跑 Agent记录实际输出和中间步骤。对比期望和实际标记通过/失败。对失败的用例做归因分析。这个框架的关键是第 4 步。失败原因通常分几类模型能力不足、工具描述不清、上下文组织不当、外部依赖问题。不同原因对应不同的修复方向。如果不做归因只是笼统地“调 prompt”效率会很低。实操心得评估用例不要一次写太多先写 10 个覆盖核心场景的跑通评估流程后再扩充。我见过太多人一上来写 100 个用例结果评估框架本身有问题白跑一遍。6.3 TypeScript 迁移的渐进式策略面对 TypeScript 7 的破坏性变更我的策略是渐进式迁移不追求一次性到位。具体做法是先在tsconfig.json里开启新配置的兼容模式如果提供的话让老代码继续能编译然后按模块逐步迁移每迁移一个模块就跑一次测试最后全部迁移完再关掉兼容模式。这样风险可控出问题也能快速定位到是哪个模块的改动导致的。这个策略的代价是迁移周期拉长但换来的是稳定性。对于有大量历史代码的项目我认为这个取舍是值得的。6.4 WebGPU 项目的性能调优记录这周我在一个 WebGPU 渲染项目上做性能调优记录几个有效的手段。减少 draw call。WebGPU 的 draw call 开销比想象中大能合并的渲染批次尽量合并。我试过把 100 个独立 draw call 合并成 5 个帧率提升明显。合理使用缓冲区。WebGPU 的缓冲区创建和更新有成本频繁创建小缓冲区不如复用一个大的。我习惯预分配一块较大的缓冲区按需切分使用。异步加载资源。大纹理和几何数据不要阻塞首帧渲染用异步加载 占位符的方式先渲染能渲染的加载完再替换。这些手段都不新鲜但在 WebGPU 语境下具体怎么实现和 WebGL 时代有不少差异需要重新摸索。7. 下周值得盯的几个方向MCP 的工具生态还在快速扩张我预计接下来会有更多垂直领域的 MCP Server 出现尤其是和本地数据、专业软件结合的方向。Agent 评估这块目前还没有特别成熟的通用方案谁先做出好用的评估工具谁就能占住位置。TypeScript 7 的迁移阵痛会持续一段时间相关的迁移工具和指南值得关注。WebGPU 方面splat.js 这类项目会推动浏览器端 3D 应用的门槛进一步降低。我个人最关注的还是 MCP 和 Agent 的结合点——当工具接入成本足够低、评估手段足够成熟时Agent 的能力边界会发生质变。这个变化不会一夜之间发生但方向已经很清楚。这周看到的这些项目都是朝着这个方向在走。