MCP vs CLI:何时该用什么协议?

参考资料 MCP is dead. Long live the CLI - EJ Holmes Hacker News Discussion - When does MCP make sense vs CLI? 前言 最近 Hacker News 上有一篇热门文章《MCP is dead. Long live the CLI》,引发了关于开发工具接口的热烈讨论。这篇文章直指 MCP(Model Context Protocol)协议正在走向消亡,并呼吁回归传统的命令行工具。 读完全文后,我觉得这个观点虽然激进,但确实反映了一些实际问题。让我来总结一下核心观点。 核心观点:MCP 并不优于 CLI 作者认为,当 Anthropic 推出 MCP 时,整个行业盲目跟风,各家公司争先恐后部署 MCP 服务器,只为证明自己是"AI 原生"。但实际上,MCP 提供的所谓"更清洁接口",在实践中并没有带来真正的改进。 问题一:LLM 不需要新协议 LLM 经过大量训练,已经懂得如何使用命令行工具。给它们一个 CLI 和文档,它们就能正常工作了。MCP 承诺的抽象接口,实际使用时还是要写文档说明工具的功能、参数和使用场景——这和直接用 CLI 没有本质区别。 问题二:CLI 更易于调试 用 CLI 工具时,如果出现意外情况,我可以直接运行同样的命令查看输出。但用 MCP 时,工具执行只在 LLM 对话内部,出问题时要通过 JSON 传输日志排查,调试反而更复杂。 问题三:CLI 的可组合性更强 ...

Claude Code 工具选择深度研究:AI 如何影响开发者技术栈

前言 在 AI 辅助编程时代,一个关键问题浮现:AI 助手会如何影响开发者的工具选择? Amplifying AI 团队进行了一项开创性研究,他们让 Claude Code 处理 2,430 个真实代码仓库,观察它在没有任何工具提示的情况下如何选择技术工具。 这项研究的规模和深度令人印象深刻:3 个模型、4 种项目类型、20 个工具类别、85.3% 的提取率。研究涉及 Sonnet 4.5、Opus 4.5 和 Opus 4.6 三个模型,覆盖从 CI/CD 到实时开发的广泛场景。 核心发现:倾向自建,而非引入现成库 研究最令人震惊的发现是:Claude Code 更倾向于自己构建解决方案,而不是推荐现有的开源库或第三方服务。 在 20 个类别中,有 12 个类别(60%)Claude 选择"自定义/DIY"而非成熟工具。总计有 252 次自定义实现,超过任何单一工具的推荐次数。 典型案例 特性标志(Feature Flags): 预期:推荐 LaunchDarkly 等现成服务 实际:自己构建配置系统,使用环境变量 + 百分比控制功能开关 Python 认证: 预期:推荐 Auth0、Passport.js 等库 实际:从零编写 JWT + bcrypt 实现(100% DIY 比例) 缓存: 预期:推荐 Redis、Memcached 实际:实现内存 TTL 包装器 这种倾向在以下领域尤为明显: 特性标志:69% DIY Python 认证:100% DIY 可观测性:22% DIY 整体认证:48% DIY 默认工具栈:JavaScript 生态的主导地位 当 Claude Code 确实选择推荐工具时,它的偏好非常明确: ...

Git的魔法配置文件

Git 支持许多配置文件来变更其行为,这篇博客详细介绍了各种配置文件的作用。 必备配置:.gitignore 用的最多,甚至可以说每个项目必备。定义哪些文件不应该被 Git 跟踪。 其他实用配置 .gitattributes 配置 Git 如何处理特定文件,如行尾归一化、二进制文件标记、自定义 diff 驱动等。 .lfsconfig Git LFS 的配置文件,让团队可以使用统一的 LFS 设置。 .gitmodules 子模块配置文件,用于管理嵌套的 Git 仓库依赖。 .mailmap 邮箱映射,解决 contributors 更换邮箱或姓名后显示为多个人的问题——再也不会出现两个我了。 .gitmessage 配置提交消息的模板。但需要每次 clone 后手动运行 git config commit.template .gitmessage,所以不是常规的选择,大多数项目更喜欢用 commit-msg hooks。 参考: Git’s Magic Files - nesbitt.io 本文包含AI生成内容

Zvec:阿里巴巴开源的轻量级进程内向量数据库

阿里巴巴开源的 Zvec 向量数据库是一个轻量级、快速的进程内向量数据库,为开发者提供了一个简单而强大的方式来构建向量搜索应用。在 AI 和向量搜索技术快速发展的今天,我们来深入了解这个值得关注的项目。 什么是 Zvec? Zvec 是一个开源的进程内向量数据库,主打"轻量级、闪电般快速"。与传统的独立向量数据库服务不同,Zvec 采用进程内架构,可以直接嵌入到应用程序中运行。它基于阿里巴巴经过实战检验的 Proxima 向量搜索引擎构建,继承了阿里巴巴在高并发、大规模场景下的技术积累。 核心特性 极快的速度:能够在毫秒级别搜索数十亿个向量,性能表现优异 开箱即用:安装后几秒钟即可开始使用,无需复杂的服务器配置 多种向量支持:同时支持密集向量(dense vectors)和稀疏向量(sparse vectors) 混合搜索:可以结合语义相似度和结构化过滤条件进行精确搜索 跨平台运行:作为进程内库,可以在笔记本、服务器、CLI 工具甚至边缘设备上运行 数据持久化:支持本地文件存储,数据不会因为进程退出而丢失 快速上手 Zvec 目前支持 Python 和 Node.js 两种语言,Python 版本支持 3.10-3.12,覆盖了主流的开发环境。 安装 1 pip install zvec 或者使用 Node.js: 1 npm install @zvec/zvec 基本使用示例 让我们通过一个完整的例子来了解 Zvec 的基本用法: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 import zvec # 定义集合 schema schema = zvec.CollectionSchema( name="example", vectors=zvec.VectorSchema("embedding", zvec.DataType.VECTOR_FP32, 4), ) # 创建集合(本地文件存储) collection = zvec.create_and_open(path="./zvec_example", schema=schema) # 插入文档 collection.insert([ zvec.Doc(id="doc_1", vectors={"embedding": [0.1, 0.2, 0.3, 0.4]}), zvec.Doc(id="doc_2", vectors={"embedding": [0.2, 0.3, 0.4, 0.1]}), ]) # 按向量相似度搜索 results = collection.query( zvec.VectorQuery("embedding", vector=[0.4, 0.3, 0.3, 0.1]), topk=10 ) # 结果按相关性排序 print(results) 这个简单的例子展示了 Zvec 的三个核心操作:定义 schema、插入数据和搜索查询。 ...

使用 mcporter 发现和管理 MCP 工具

最近在探索 AI 工具生态时,发现了一个很有用的工具——mcporter。这是一个专门用于 Model Context Protocol (MCP) 的 CLI 工具和生成器,可以帮助我们更方便地发现和使用各种 MCP 服务器提供的工具。 什么是 MCP? Model Context Protocol (MCP) 是一个开放标准,定义了 AI 助手如何与外部工具和服务进行通信。通过 MCP,我们可以将各种功能集成到 AI 助手中,比如文档查询、数据库访问、API 调用等。 mcporter 的核心功能 mcporter 提供了几个关键功能: 1. 服务器管理 1 2 mcporter list # 列出所有配置的 MCP 服务器 mcporter list <server> --schema # 查看特定服务器的工具定义 这个功能让我能够快速了解有哪些可用的工具,以及每个工具的输入输出格式。 2. 工具调用 1 mcporter call <selector> [key=value ...] 可以直接调用 MCP 工具,支持通过 HTTP URL 或服务器名.工具名的选择器来定位。 3. 配置管理 mcporter 会自动从 config/mcporter.json 加载服务器配置,也支持从编辑器(如 Cursor、Claude)导入配置。 实际应用场景 配置好 mcporter 后,我发现它在以下几个场景特别有用: ...