问HN：谁在生产环境中使用MCP？

# 问HN：谁在生产环境中使用MCP？ 来源：https://news.ycombinator.com/item?id=49548600 https://news.ycombinator.com/vote?id=49548600&how=up&goto=item%3Fid%3D49548600问HN：谁在生产环境中使用MCP？ (https://news.ycombinator.com/item?id=49548600)22积分由sukit (https://news.ycombinator.com/user?id=sukit)3小时前发布 (https://news.ycombinator.com/item?id=49548600)\|隐藏 (https://news.ycombinator.com/hide?id=49548600&goto=item%3Fid%3D49548600)\|存档 (https://hn.algolia.com/?query=Ask%20HN%3A%20Who%20is%20using%20MCP%20in%20production%3F&type=story&dateRange=all&sort=byDate&storyText=false&prefix&page=0)\|收藏 (https://news.ycombinator.com/fave?id=49548600&auth=b2a484ebda5dc7f7f83c9ba36ae363efe2fb9610)\|34条评论 (https://news.ycombinator.com/item?id=49548600)自从MCP首次推出以来，我就一直在关注它。早期它获得了大量关注，但我还没怎么见过有人在生产环境中使用它。可能是我错过了相关信息。 如果你在生产环境中使用MCP，你用它做什么？与普通的API、直接工具集成或仅仅是CLI相比，你发现了哪些优势？ 帮助 (https://news.ycombinator.com/formatdoc) https://news.ycombinator.com/vote?id=49559951&how=up&goto=item%3Fid%3D49548600 我的背景是实时视觉特效创建，但我在我的（原生）自定义工具中大量使用MCP，作为一种驱动应用内UI更新的方式，当然还包括双向状态查询，以及用于闭环验证的帧缓冲区捕获。 我觉得CLI可能也能实现，但那样我最终也会实现类似的东西。话虽如此，我遇到过常见的坑：工具太多会导致上下文窗口迅速增长，而且某些智能体有时会跳过部分工具列表而不查询全部，从而导致行为错误。 如果你有余裕，我建议你查看一下源代码，看看它被使用的深度：https://github.com/sxp-studio/subjective-zero （视频展示MCP实际应用，有点长，可以跳过：https://www.youtube.com/watch?v=DcI1tsPJ8eM） 我遇到过的另一个挺酷的MCP用法其实来自……法国政府！他们将其用于开放数据倡议：https://github.com/datagouv/datagouv-mcp https://news.ycombinator.com/vote?id=49559767&how=up&goto=item%3Fid%3D49548600 总的来说，MCP的优势在于可以细粒度地控制智能体允许使用的工具。但不幸的是，周围存在大量糟糕透顶的MCP服务器，它们比直接API访问甚至CLI集成还要差。 我不会宣传我使用的任何商业MCP，但举一个设计精良、有用的MCP服务器的例子，我可以提一下NixOS MCP。它有用是因为它将所有的Nix资源整合到一个端点，比网页搜索更高效，并且能更好地控制数据源。 https://github.com/utensils/mcp-nixos 另一个例子是这个文件系统MCP，在我看来，它优于直接的CLI访问。当然这也取决于你的整体沙箱策略，但如果你只使用通用的Docker镜像，仍然有许多潜在危险的二进制文件可用，而这样的MCP可以限制模型的能力。 https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem 当然，还有许多服务提供商提供他们自己的MCP，背后有自己的LLM/智能体，例如大多数网络搜索引擎。在这种情况下，你很可能已经在使用MCP而没有意识到。 https://news.ycombinator.com/vote?id=49559387&how=up&goto=item%3Fid%3D9548600 我把Claude代码连接到了Jira和Figma。这更多是对Jira的批评，但能在终端里用自然语言与它交互是极大的解脱。遗憾的是，它在某些方面仍然有限制。如果可用，它比直接通过API接口要稍微容易一点，所以算是锦上添花。 https://news.ycombinator.com/vote?id=49559759&how=up&goto=item%3Fid%3D49548600 我也这么做过。我发现这真的很低效，因为如果我处理大量文本，就必须将所有内容通过模型传递给MCP调用。一旦你对内容满意，使用临时文件并通过CLI工具进行管道处理要好得多。例如，开发用户故事并创建Jira问题。 https://news.ycombinator.com/vote?id=49559514&how=up&goto=item%3Fid%3D49548600 > “它比直接通过API接口要稍微容易一点” 以什么标准衡量？我预计一个轻量级的API客户端（具有可读代码）通常会优于一个你无法管理/编辑的工具接口。 https://news.ycombinator.com/vote?id=49559500&how=up&goto=item%3Fid%3D49548600 我最近为英国每个地方议会/地方规划机构创建了一个规划申请抓取工具，很大程度上是在Claude的帮助下完成的。正如你无疑可以想象的那样，这是那种机制远不如其外围工作重要的任务类型。 对我来说，让此类事情顺利运行，常常归结为尽可能快地找出那些我不知道自己不知道的东西。我与Claude合作，作为其中的一部分，创建了一个基础的调试前端——用于我自己的数据检查、寻找模式——当时，主要是出于一时兴起，我要求Claude在其基础上创建一个MCP接口：最近的运行状态、哪些看起来正常、哪些不正常、各个数据点的覆盖差距在哪里。 我将最小可行产品（MVP）添加到Claude中，并定期检查以询问进展如何。 然后——我会询问一些细微差别，*为什么*某些事情看起来不太对劲。或者昨晚那些议会总体发生了什么？接着——毫无征兆地，没有被提示或要求——Claude会在查看代码的同时查询MCP。当我舒适地坐在椅子上调试时，获得了即时的、生产级别的洞见。 我当时想“噢。” 以及“这确实相当不错”，因为关键细节在于，我认为，如果MCP设计良好且运行良好，并且与你当时每天的工作相关，它*就是*你工具箱的*又一个*补充。 这让我思考如何为我的朝九晚五的用户做同样的事情。 https://news.ycombinator.com/vote?id=49559151&how=up&goto=item%3Fid%3D49548600 我为自己学习构建了一个小型MCP服务工具；它检索学习材料和课程内容，使我能够通过与ChatGPT的语音交互对话进行学习。它记录我的学习数据，然后我可以检索并分析这些数据以评估我的整体进度。 https://news.ycombinator.com/vote?id=49559823&how=up&goto=item%3Fid%3D49548600 在cadenya.com构建智能体运行时环境，而MCP服务器一直是创建适配器最困难的部分。对于一个两年前的规范来说，变体实在太多了。 https://news.ycombinator.com/vote?id=49548909&how=up&goto=item%3Fid%3D49548600 我们正在使用它，一个最近上线的新工具。它使得与应用资源的通信更加容易。并且它是智能体与远程资源对话的标准化方式，让它们更容易理解有哪些可用资源以及如何使用。 阅读更多关于mcp工具/资源/提示的信息。 https://news.ycombinator.com/vote?id=49559267&how=up&goto=item%3Fid%3D9548600 我不明白为什么要让机器人更容易做事。把API指向它们，它们就能搞定。你能更详细地解释一下哪里更容易了吗？ https://news.ycombinator.com/vote?id=49559343&how=up&goto=item%3Fid%3D49548600 MCP显然减少了概率性故障——也就是所有这些机器人的常见致命缺陷（幻觉、错过API文档中的内容等）。 知道这些结果后，这让我觉得MCP更有趣了。 这确实强调了我们已经知道的关于LLM回复/结果特定弱点的结论。 https://news.ycombinator.com/vote?id=49559366&how=up&goto=item%3Fid%3D49548600 我认为那是6个月前的问题，但在xhigh上的GPT 5.6 Sol没有这类问题了。我认为这不会持续。事情发展很快。 https://news.ycombinator.com/vote?id=49559663&how=up&goto=item%3Fid%3D49548600 人们每次模型发布时都这么说，而且每次都错了。我敢跟你打赌，这次和过去十几次一样，不会有什么不同。 https://news.ycombinator.com/vote?id=49559716&how=up&goto=item%3Fid%3D49548600 我每天燃烧5亿个token“写代码”，已经连续83天了。其中一个我正在构建的项目通过API将Netbox、Stripe、QuickBooks、Mercury和Deel集成在一起。我写了一行代码，也没读过一份API文档。它完全按照我的要求去做，并为我提供了一个关于我每年数百万美元ARR业务每个方面的360度视图。 你呢？ https://news.ycombinator.com/vote?id=49559489&how=up&goto=item%3Fid%3D49548600 我愿意相信！ 不过，企业仍然为了合规而运行很多无用的东西。 https://news.ycombinator.com/vote?id%3D49560014&how=up&goto=item%3Fid%3D49548600 大部分我都理解了，但公平地说，是的，有点啰嗦哈哈。 这不清楚，但如果你有预感会怎样，我很感兴趣（对任何人说）。 https://news.ycombinator.com/vote?id=49549217&how=up&goto=item%3Fid%3D49548600 我用一个来制作一个AI工具，让人们可以直接报告错误/功能请求。 它会搜索以确保不是重复项，撰写工单，然后提交。 因为这是一个生产工具，我们想要尽可能便宜的工具，同时又不能太不准确。如果你使用API等，最终你还是会在上面构建一个类似于MCP的适配器，以便它可以用自然语言交流，而不是处理JSON之类的东西。 Linear的MCP也非常简洁和设计精良，可能是他们相对于比如Jira的核心优势之一。我不知道API长什么样，因为MCP运行得很好。 https://news.ycombinator.com/vote?id=49559788&how=up&goto=item%3Fid%3D49548600 他们可能指的是MCP服务器暴露的工具API设计精良。这肯定有很大区别。 https://news.ycombinator.com/vote?id=49556093&how=up&goto=item%3Fid%3D49548600 这就是我们在我们产品中使用的——一个使用Linear MCP创建任务的错误报告工具。运行得很好。 https://news.ycombinator.com/vote?id=49559287&how=up&goto=item%3Fid%3D49548600 Caudena去年在其企业功能中发布了一些MCP内容，并在今年将其提供给消费市场，地址是https://mcp.caudexcatena.com/。 我们收到了企业客户和消费领域客户的非常好的反馈，他们真的很喜欢它。 https://news.ycombinator.com/vote?id=49559346&how=up&goto=item%3Fid%3D49548600 MCP仍然是我使用Cursor与企业系统（如Glean、Jira和Port）交互的主要方式。除此之外，所有东西，尤其是GitHub，都转移到了CLI（根据需要添加技能）。 https://news.ycombinator.com/vote?id=49557800&how=up&goto=item%3Fid%3D49548600 我发现CLI或直接调用API要便宜和快速得多。目前我唯一使用的MCP是Jira MCP，只是因为我之前设置过它，而且它已经在那里很长时间了。 https://news.ycombinator.com/vote?id=49559392&how=up&goto=item%3Fid%3D49548600 是的！我认为这不过是另一个正在慢慢消亡的潮流。我希望我的公司没有花整个团队六个月的时间来创建一个永远不会真正大规模使用的MCP服务器。 https://news.ycombinator.com/vote?id=49559960&how=up&goto=item%3Fid%3D49548600 我*个人*没有在生产环境中使用MCP，但是，我的团队在用。我的团队也为其他团队生产MCP服务器，这让我有点抓狂。我想知道是否有人能理解我的经历。 感觉MCP背负着大量的包袱。它具有先发优势——出现在前沿领域看起来大不相同的时期。模型可预测性差得多，经常搞砸工具调用——并且无法快速找到一个好方法来直接与API交互。 现在情况大不相同了——看到我团队的新项目仍然将MCP视为在模型面前呈现数据的合理首选方案，我感到沮丧。每个人都使用Claude代码（CLI、桌面端；我也对这么多人使用CC而不是替代品感到沮丧——那是另一个抱怨），因此，每个人都有一个可以愉快地利用shell +技能来精确完成任务的运行环境。那么——为什么？为什么我看到我的团队成员都在使用同一个有缺陷的Atlassian MCP服务器——而我们无法控制其工具接口？为什么不直接让智能体指向API规范？如果答案是启动太慢，必须读取API规范才能知道该做什么——那么，让它指向你的.claude/.codex/.whatever目录——找到智能体使用来自MCP服务器工具的地方，并创建技能或某种轻量级客户端接口。 我承认，是的，我观察到一个设计精良的MCP服务器可以提供比让智能体用一个定义模糊的任务去调用API更好的性能。然而——‘设计精良’并不容易实现。你必须运行许多轮基准测试和评估，观察运行轨迹，并在多次迭代中改进工具接口。你也无法预测用户——因此你需要监控使用情况，并随时间推移进行改进。这是一个艰巨的工作。 此外——没人对这东西进行基准测试。他们把MCP扔给问题，一旦智能体能够完成任务就收工了。真让人沮丧。 我曾尝试发声并建议，也许与改进API接口的用户体验（或智能体体验）相比，MCP可能不值得付出那么多努力，或者不如投入周期去改进数据存储和展示。但我觉得每次提到MCP时，我都在一致地提出这个问题，让自己开始感觉像个混蛋。 我意识到这已经深入到了抱怨的领域。不过，互联网上的匿名发帖对灵魂有好处。总之——普遍感觉其他人对放下自尊、开展研究并改进我们的认知和做事方式，并不像我那么感兴趣。这又回到了CC——我是团队中唯一不使用CC作为日常主力的人。再次——我感觉自己像个混蛋，但是天哪，我就像个破唱片一样建议别人尝试不同的模型和运行环境。我不断听到关于输出冗长或变化无常的半抱怨，而几乎没人愿意尝试一下OpenAI的模型。 我受不了听一群人自怜自艾地说模型输出读起来很累——而这些抱怨只针对Anthropic模型，甚至没人读过提示指南，里面明确说明了如何减少输出的冗长/密集/华丽程度。 看在上帝的份上。别再试图让其他提供商的模型在CC中工作了。这并非不可能；但它本质上是一个对黑客不友好的平台。我向你保证，CC CLI不是唯一一个你会感到舒服的编码智能体CLI工具。实际上——我愿意加倍押注，一旦你看到那个橙色围墙花园外的草地是什么样，你就会讨厌CC CLI。呸！ — 编辑：还有！为什么这些产品（https://artificialanalysis.ai/articles/search-api）如此受追捧？用这些有什么问题：https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool 和 https://developers.openai.com/api/docs/guides/tools-web-search?api-mode=responses（或者，OpenAI的alpha/search端点）