https://blog.gby.ai/tags/claude/ Recent content in Claude on GbyAI Hugo -- gohugo.io zh Content under license [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/) Thu, 05 Dec 2024 00:00:00 +0000 https://blog.gby.ai/mcp-sqlite-example-and-fix-problem/ Thu, 05 Dec 2024 00:00:00 +0000 https://blog.gby.ai/mcp-sqlite-example-and-fix-problem/ Anthropic 前两天发布了 MCP，很多人觉得和 FC、Plugins 是一个路数并不看好，持观望态度。我自己是参照官网整体走了一遍流程，说一下自己的看法，以及遇到的小坑。（小声蛐蛐官网居然不写这些小点） 个人看法 不管成不成，先用你自己的 Claude 客户端，做一个提升你效率的工具体验一下才有资格去评论。即使不成，收益总是你自己的嘛 可以在官网看十几个 case，并且 GitHub 开源的 MCP 应用已经不少了 https://github.com/modelcontextprotocol/servers 如果 MCP 成了，就像是 VS Code 的 LSP 协议，借着开源的春风，那么这个玩意有可能会做出个人 PC 的超级入口。当然这就得看 mac 和 win 同不同意了，毕竟人家也想做嘛。但是你不动， anthropic 替你先发。😁 MCP 和 Plugins 很像，但是 Plugins 你需要去上传数据等到第三方平台，MCP 虽然也有泄漏的风险但是相对少一些，而且数据在本地，也省的我 ChatGPT 也传一份，coze 也传一份... 好多 agent 平台啊 MCP 和 FC 对比 目的都是为了让大模型调用外挂能力，扩展更多的上下文，实现更多的能力，满足用户需求 接入方式一个是在模型方写调用描述，一个在 MCP client 写描述，都是哪里用在哪里写，都是服务发现的那一套。不过 MCP 更规范扩展性更强，有更多的指导意义，但是其实从 agent 开始流行之后 GitHub 就有很多去中心化的协议了，只不过不是大厂发布核心影响力不够。 难点都是模型的意图识别，用户 query 找到最匹配的能力（外挂），路由啊路由，难得都是在海量的质量参差不齐的应用里面找到最合适的一个。 实现上孰优孰劣真不好说，但是个人使用方面觉得 MCP 更方便 实操原理 MCP Server 实现步骤： 首先，通过详细描述 prompts、resources 和 tools，明确定义服务的具体能力； 接着，使用 server. https://blog.gby.ai/long-context/ Thu, 07 Mar 2024 00:00:00 +0000 https://blog.gby.ai/long-context/ 最近发布的 claude 3 支持 200 k 的上下文，简单回顾了一下到 2024 年 3 月 7 号为止超过 100 k 上下文窗口的大模型。 模型名 最大上下文 大海捞针通过率 Claude 3 系列 100-200 K >99% Claude 2.1 200 K >50% GPT 4 128 K >95% Yi-34B 200 K 无 Baichuan 2 200 K >90% ChatGLM 4 192 K >99% kimi chat 192 K >99% XVERSE-Long 256 K 无 InternLM 200 K 无 Gemini 100 K 无 长上下文带来的益处 模型性能的提升 大型语言模型的上下文窗口扩大到200K tokens，意味着模型可以在单个输入中处理更长的文本。这对于理解长篇文章、书籍、编写更长的内容或进行深入的话题分析具有显著优势。模型能够捕捉到更长文本中的细微联系和结构，从而提高了语言理解和生成的质量。 应用场景的扩展