Tachyon：把 Java 方法挂成 MCP 服务端的 SDK

Java 侧的又一个 MCP 服务端

MCP（Model Context Protocol）已经从 Anthropic 的一个内部约定变成事实标准之一，客户端侧的工具调用、资源读取和提示模板有了统一的握手方式。协议定义了服务端怎样把能力暴露出去，剩下的问题落在语言生态里。Python 和 TypeScript 起步最早，Java 这边慢半拍，多数团队要么拿官方 SDK 自己拼装，要么等框架厂商补齐。

Tachyon 想填的就是这一段。它的定位很直接：把 Java 方法暴露成 Streamable HTTP 的 MCP 服务端。底层网络用 Netty，这个选择在 Java 圈子里不意外——大量中间件把 Netty 当作 IO 层，长连接、并发和背压都是已经处理过的问题。对需要在生产环境挂载 MCP 服务的团队来说，底层是 Netty 意味着运维、监控和调优的经验可以直接沿用。

规范兼容与两套写法

Tachyon 声称同时兼容当前版本和上一版 MCP 规范。这一点比听起来重要。MCP 在 2025 年把远程传输从 HTTP+SSE 换成了 Streamable HTTP，新旧客户端会并存一段时间，服务端只支持其中一版，就等于替用户做了选择。声称兼容两版，实际是在减少升级期的摩擦。

功能清单列得很全：tools、resources、prompts、completions、extensions，此外还有 tasks 和 skills，标注为 SEP-2640。后两项在 MCP 主线里属于较新的扩展议题，规范文本和实现都还在演进。SDK 把它们写进支持列表是一回事，语义是否稳定、能否直接上生产是另一回事，需要对着项目文档和 SEP 提案逐条核对。

写法上给了两种：DSL 和声明式 Java 注解。注解式的思路对 Java 开发者不陌生，在方法上打标记，注册和参数映射交给框架。DSL 更适合要精细控制参数描述、返回结构和元数据的场景。两套并存的好处是接得进既有代码，代价是文档和维护成本翻倍，早期项目通常只能先把一条路走扎实。

现在还只是 Show HN 阶段

这条项目帖在 Hacker News 上只有 2 分、0 条评论，属于典型的早期曝光。这个数字说明不了代码质量，只能说明它还没进入社区讨论。想判断是否值得引入，比较实际的做法是读 GitHub 上的示例和测试，看它怎么处理错误返回、流式响应中断和并发注册，再决定要不要在自己的服务里试一把。

已经在跑大量 Java 服务的企业，把内部方法开放给 AI 客户端时绕不开一个取舍：让每个服务自己实现协议细节，还是抽出一层 SDK。Tachyon 给的是后一种答案，技术栈押在 Netty 和注解上。这条线上已经有别的玩家，胜负取决于规范跟进速度和与现有 Spring 生态的磨合程度，功能列表的长短反倒次要。