Conduit

Hi Product Hunt 👋

我是 Tyler，Conduit 的创建者

我不断往 AI 工具里加 MCP 服务器，加得越多，智能体就越慢越不可靠。原因让我意外：每次请求，每个 MCP 服务器都会把整个工具列表塞进模型上下文。以我的配置，还没打一个字，工具定义就已经占了约 24,000 token 的上下文，而模型在调用之间会丢弃所有这些，所以下次请求你还得再掏一次钱。

Conduit 解决了这个问题。它是一个本地优先的网关，位于你的 AI 工具和 MCP 服务器之间。每个客户端只需连接它一次，它不会暴露所有工具，而是暴露三个元工具供智能体按需搜索。完整目录仍然可用，只不过不再每次请求都塞进上下文。

我在真实配置上做了基准测试：每次请求的工具开销降低了 97%，总 token 数减少了约 90%，且任务成功率不变。完整方法和数据都在 repo 里。

无论你用什么方式工作，这都有帮助。用云模型，token 就是你的账单。用本地模型，工具定义会吃掉你的上下文窗口。不管怎样，你都不再为智能体从未调用的工具付费。

我重点关注了几个方面：

• API key 留在你的操作系统钥匙串里，绝不会出现在配置文件中

• 不会回传任何数据，完全本地优先

• 目前支持 17 个客户端，覆盖 Windows、macOS 和 Linux

• 免费且开源

欢迎给我反馈，尤其是你希望接下来支持哪些 MCP 服务器或客户端。感谢你的关注 🙏

~90% 的 MCP token 削减是个大话，也是个真正的痛点。这是来自修剪工具 schema/结果，还是实际响应压缩？

关于 90% token 减少的说法，我想更深入地了解。这是来自在客户端侧、在到达模型之前就去掉上下文，还是你做了更聪明的事情，比如缓存工具描述，只在 schema 未更改时发送差异？这两种架构很不同，失败模式也大相径庭。另外好奇 Conduit 如何处理 MCP 服务器 schema 在会话中变化的情况，因为传给模型的缓存描述如果过时，可能会导致微妙的工具调用错误，很难调试。

这恰恰是那种很容易被忽视的智能体基础设施痛点，直到它变成账单或延迟问题。工具列表膨胀这个细节很有用，因为它点出了具体的失败模式，而不仅仅是“token 太多”。好奇：你觉得团队会想要每个服务器/每个工具的使用可见性吗？还是这个网关应该配置好后就保持透明？

嘿，恭喜！

你能详细说明一下解决方案的基准测试吗——你是怎么衡量成功率的，用了哪些基准？

在开始任务之前工具列表就膨胀得这么严重，真高兴有人在网关层解决这个问题，而不是在每个智能体内部处理。它能处理在运行时改变工具列表的服务器吗？还是按会话缓存目录？祝贺发布。