最新

嗨，HN，我是Luigi。 我们维护一个名为mcp-use的开源TypeScript框架，用于构建MCP服务器和MCP应用程序：<a href="https://github.com/mcp-use/mcp-use" rel="nofollow">https://github.com/mcp-use/mcp-use</a>。MCP现在（终于）是无状态的，因此我们从头开始重写了mcp-use v2，以适应2026年7月28日的MCP规范修订：<a href="https://blog.modelcontextprotocol.io/posts/2026-07-28/" rel="nofollow">https://blog.modelcontextprotocol.io/posts/2026-07-28/</a> 重建带来的好处： - 吞吐量：增加27% → 从8,615提升至10,982中位数操作/秒 - 冷启动：速度提升2.2倍 → 从151.6毫秒降至68.1毫秒 - 全新安装：体积缩小82% → 从404.6 MiB降至74.4 MiB 基准测试及其方法论请见这里：<a href="https://github.com/mcp-use/mcp-use/blob/main/benchmark.md" rel="nofollow">https://github.com/mcp-use/mcp-use/blob/main/benchmark.md</a> 规范中的变化： 1. 不再使用会话。初始化/已初始化的交换和Mcp-Session-Id头部已被移除（SEP-2575，SEP-2567）。每个请求都携带自己的协议版本、客户端身份和能力信息在_meta中。服务器发现现在是可选的服务器/发现RPC，而不是强制的往返请求。 2. 多轮往返请求取代了服务器发起的调用（SEP-2322）。现在服务器返回resultType: "input_required"和requestState，客户端用inputResponses重试原始调用。中途用户确认不再需要保持实时连接。 3. 基于头部的路由（SEP-2243）。Mcp-Method和Mcp-Name现在是必需的HTTP头部，因此网关、速率限制器和WAF可以在不解析JSON主体的情况下进行路由和计量。 4. 可缓存的列表结果（SEP-2549）。 5. 认证加强：DCR仍然有效，但已被弃用，未来将以CIMD取而代之，并将在未来的规范修订中移除。 6. 根、采样和日志记录已被弃用，过渡期为12个月。 7. 传统的HTTP+SSE将有一年的过渡期。 关于mcp-use，我们专注于Claude连接器和ChatGPT插件的MCP应用程序。MCP应用程序使用名为ext-apps的MCP扩展，允许工具返回在聊天中渲染的用户界面。 我们支持的功能： - 视图具有热模块替换（HMR），因此在开发时会热重载。 - 标准的模式验证器用于工具和提示的输入/输出，因此Zod、ArkType、Valibot等都可以使用。或者任何由标准模式支持的验证器库。 - 适用于Auth0、Clerk、WorkOS、Better Auth、Supabase和Keycloak的即插即用OAuth集成。 - 服务器组合（代理和挂载其他MCP服务器）。 - OpenAPI导入并将您的API暴露为MCP服务器。 HTTP层使用Hono，因此可以挂载在现有应用程序中，从而实现边缘部署。 如果您的产品使用Next.js，我们发现很多开发者希望摆脱（基本上无人维护的）mcp-handler。因此，我们为Next.js提供了即插即用的集成：将`next.config.ts`包装在`withMcpUse`中以进行视图编译，然后从一个捕获所有路由的地方导出`export const { GET, POST, DELETE, OPTIONS } = createNextHandler(server)`。 关于开发体验（DX）： - 内置MCP检查器：`mcp-use dev`在`/mcp/inspector`上运行，并支持热重载。我们还提供了一个托管版本：<a href="https://inspector.manufact.com/inspector">https://inspector.manufact.com/inspector</a> - mcp-use CLI具有一个很酷的无头功能，可以调试MCP服务器和来自编码代理的UI部分，包括视觉反馈：`mcp-use client <name> screenshot --tool <tool>`通过Chrome无头渲染视图。代理可以调用工具，读取失败信息，然后截图刚生成的UI，查看其构建的内容。 不幸的是，我们无法避免一些重大变化。好消息是，使用v2构建的90%的MCP服务器与两个版本的MCP规范兼容。客户端会自动协商版本，通过服务器/发现进行探测，并在旧的初始化方法中回退以支持遗留服务器。 我们很想知道运行MCP服务器的人对无状态转变的看法，特别是那些构建了自己会话层的人，现在可以删除它。 详细的博客文章请见：<a href="https://manufact.com/blog/mcp-use-v2">https://manufact.com/blog/mcp-use-v2</a> 如果您想尝试mcp-use v2，它刚刚推出正式版：<a href="https://github.com/mcp-use/mcp-use" rel="nofollow">https://github.com/mcp-use/mcp-use</a>。我们期待听到您的想法以及如何改进它！我们很乐意回答任何问题，并期待您的反馈。

大家好，我们是来自ProvenMetal的Will和Johnny（<a href="https://provenmetal.com">https://provenmetal.com</a>）。您只需将设计文件或规格发送给我们，我们便能在几天内为您提供组装好的电路板。 在2000年，美国生产了全球30%的印刷电路板（PCB），而现在这一比例仅为4%。中国制造商已完全主导了这一领域，占全球生产的55%。 如今，对国内PCB供应链的需求比以往任何时候都要高，但在过去20年中，相关基础设施却在不断消退。现在剩下的大多是一些小型家庭经营的制造商（CM），他们自2000年代初以来，依然以相对劳动密集的方式运营。 当您通过CM下订单时，通常需要几天才能收到报价并完成设计制造审核，接着您还得自己采购所有组件（这通常是最难的部分）和裸板，然后再等待几天到几周的时间进行组装和测试。 我们最初是在一个车库里用专业级设备（NeoDen YY1、Glenbrook X射线、焊膏模板和手动返工站）组装电路板。我们认为，通过掌控制造过程，我们可以将所有前端自动化转向内部。但问题是……在车库里用专业级设备制造电路板需要耗费大量时间。突然间，我们90%的时间都花在了组装电路板上，而不是业务的扩展。我们完全受限于产能，尽管有一些华丽的软件自动化，但在低产量下并不是瓶颈。 然后我们从繁琐的细节中抽身，退后一步，意识到我们试图解决的瓶颈是错误的。 这些制造商擅长生产，但在前端（报价、DFM审核和零件采购）方面表现不佳。当您审视整个过程时，会发现组装并不是瓶颈。因此，我们停止了试图解决在这个阶段无法解决的问题。 我们测量了瓶颈，并确定了我们目前最有能力解决的瓶颈。 当客户需要国内制造的电路板时，这并不是一个简单的过程。我们通过前端自动化使这一过程变得简单。 客户将设计文件提供给我们，我们会自动采购组件，并协调裸板制造和组装厂以获取报价、设计审核和制造，形成一个紧密的循环。 我们如何解决零件采购问题——没有零件就无法组装电路板。 当用户向我们下订单时，我们的系统会自动从美国和海外分销商那里采购他们的物料清单（BOM）。 然而，在与客户的设计过程中，我们的插件与KiCAD和Altium互动，将BOM发送到我们的订购平台，这使我们能够在布局最终确定之前自动采购组件。 KiCAD插件：（<a href="https://github.com/proven-metal/provenmetal-kicad" rel="nofollow">https://github.com/proven-metal/provenmetal-kicad</a>） Altium插件：（<a href="https://github.com/proven-metal/provenmetal-altium" rel="nofollow">https://github.com/proven-metal/provenmetal-altium</a>） 这使我们能够提前订购长交货期的零件，如果零件缺货，还能建议替代品，从而解决流程中的最大瓶颈。 我们在旧金山的总部存储零件，然后将电路板进行配件和通过我们的网络进行分发。我们还为长交货期的物品提供长期存储服务。 我们如何解决无尽的邮件往来——每个制造商都希望以不同的格式获取相同的信息。通常需要几天的邮件往来才能达成共识。 我们为每个制造商建立了一个档案，并根据他们的要求发送订单。这听起来可能微不足道，但它消除了大多数订单上多天的往返，这在快速交付的生产中占据了相当大的时间份额。 如何解决设计审核——每个制造商都有各自的能力表，因此我们有一个启发式工具，Fable 5用来检查电路板的DFM问题。 我们正在构建一个端到端的PCB制造流程，但这是否足以解决供应链问题？绝对不够。 产能才是问题，任何智能软件都无法解决这一点。我们今天正在从系统中提取实际的冗余，这种冗余是有限的，在某个产量下，唯一的选择就是增加物理产能。我们认为这就是未来的发展方向。 我们如何盈利——我们根据订单复杂性对订单价值收取简单的利润，并提供完全透明的报价细目。 我们在不到一周的时间内接到了第一笔付费订单，在六周内完成了大约70,000美元的11个订单。 我们非常希望听到您的意见。我们正在处理一个到处都是问题的领域，关于我们应该解决哪些问题以及如何解决这些问题，我们不断受到各种方向的牵引。您有什么可以教我们的呢？