朋友之间共享上下文这可能是目前 MCP 生态里一个非常轻巧但又不失想象力的玩法。这次我们来看一个发布在 Show HN 上的项目Share context between friends via MCP。它没有做复杂的知识库、没有搞高深的多智能体编排核心就一件事——让多个朋友、多台电脑、多个 MCP 客户端能共享同一份 AI 会话上下文。如果你平时在 Claude Desktop、Dify、Cherry Studio 或者 Cursor 这类 MCP 客户端里折腾提示词和会话记忆这个项目值得花十分钟研究一下。先说它的核心特点基于 MCPModel Context Protocol实现、采用 Server/Client 架构、多个好友可接入同一个共享上下文服务、可以通过 JSON-RPC 方式读写上下文片段、部署形态很轻本地起一个服务即可。相比传统把上下文写在记忆文件里手动复制的做法这个项目把上下文变成了一个可订阅、可同步的服务端资源这在多人协作、小团队共享提示词、或者个人多设备之间同步会话状态时非常实用。这篇文章我会按 CSDN 技术博客的习惯拆开讲清楚这个项目适合谁、怎么理解它的共享上下文机制、本地部署需要准备什么、如何接入不同 MCP 客户端、怎么测试读写效果、以及有哪些值得注意的坑。通篇不搞云里雾里的概念直接说能不能用、怎么用。1. MCP 共享上下文项目核心能力速览在动手之前先给一个可快速判断的规格表。因为项目本身在持续迭代且不是重量级平台这里的参数更多是基于项目定位和常见 MCP 实现方式的推断具体以官方仓库最新 README 为准。能力项说明项目类型MCP Server提供共享上下文读写能力核心功能多客户端共享、读取、写入、订阅上下文片段通讯协议MCPModel Context Protocol基于 JSON-RPC 2.0部署形态本地服务进程可暴露给局域网内好友推荐运行环境一台常开的电脑、NAS、或云服务器均可客户端兼容性Claude Desktop、Dify、Cherry Studio、Cursor 等支持自定义 MCP 的客户端是否支持 API是MCP 工具调用本质上就是接口调用是否支持批量任务取决于上下文服务设计通常可按标识批量读写是否支持多人是这是项目核心定位显存需求无纯 CPU 服务磁盘需求很小主要是代码和上下文存储文件上手难度低适合有基础 Node.js 或 Python 经验的开发者从项目标题可以看出这个项目的亮点不是上下文管理而是通过 MCP 在朋友之间共享。换句话说它把 MCP 当成了人与人之间交换 AI 上下文的通道。你分享的不只是一个文件而是一个随时可以变更、订阅、同步的上下文服务。2. 这个项目解决什么问题朋友间上下文共享很多人在实际使用 AI 助手时都会遇到一个尴尬情况自己攒了一套很好用的系统提示词或者一整段调试了很久的 few-shot 示例想发给朋友一起用结果只能通过聊天窗口复制粘贴粘过去后还要手动改格式。如果是两个人维护同一个提示词版本那就更痛苦改来改去最后根本分不清哪个是新的。这个项目把上下文抽象成了 MCP 服务端的一个资源。你可以往服务端写入一段上下文比如我常用的前端代码审查规则给一个标识然后朋友通过 MCP 客户端就能实时读取。你在服务端更新这段上下文朋友那边再调用时拿到的就是最新版。这种模式对于小型开发团队共享代码评审规范朋友之间共用一套提示词模板个人在办公室和家里的电脑之间同步 AI 助手状态教学场景中老师给学生分发统一的提问上下文都有很直接的价值。需要注意边界。共享上下文不等于共享一切。任何涉及密钥、密码、个人隐私、未授权数据的内容都不应该放进共享上下文。MCP 本身只是协议通道不会帮你做鉴权和审计权限控制基本靠部署方自己实现。所以这个项目更适合熟人小圈子 可控网络环境的场景而不是直接丢到公网上使用。如果要在公网部署必须加反向代理、TLS 和身份认证否则相当于把上下文数据裸奔在互联网上。3. MCP 共享上下文部署环境准备部署这个项目本身不需要 GPU也不需要单独的显卡环境核心是有一台能运行 Node.js 或 Python 的机器。下面是通用的环境检查清单适合大多数 MCP Server 项目。3.1 操作系统Windows、macOS、Linux 都可以。考虑到朋友之间共享这个场景更稳妥的做法是部署在一台能长期开机的设备上比如家里的 NAS一台云服务器或者一台放在办公室的迷你主机如果你只是想本地本机测试那笔记本上直接跑也行。3.2 运行时环境具体运行时取决于项目实现。如果仓库是 Node.js 写的就装 Node.js 16 或更高版本如果是 Python 写的就需要 Python 3.9 以上并配合 uv 或 pip 管理依赖。建议先确认仓库根目录下的package.json或pyproject.toml再决定安装哪个运行时。# 如果项目是基于 Node.js node -v npm -v # 如果项目是基于 Python python --version3.3 MCP 客户端要体验共享上下文的完整流程至少准备一个支持自定义 MCP Server 的客户端。常见选择Claude Desktop在claude_desktop_config.json中配置 MCPDify在设置里添加自定义 MCP 服务Cherry Studio支持本地 MCP server 添加Cursor可通过 MCP 配置接入其他支持 MCP 的 IDE 或客户端3.4 网络与端口本地测试可以直接用127.0.0.1。要和朋友共享则需要这台机器在局域网内可访问或者通过内网穿透、云服务器公网地址访问。端口建议选择一个不容易冲突的高位端口比如 8000 到 9999 之间的常用端口。启动前先检查端口是否被占用。# Linux/macOS 下查看端口占用 lsof -i :8000 # Windows PowerShell 下查看端口占用 netstat -ano | findstr :80003.5 存储空间如果只是共享文本型上下文磁盘需求非常小几十 MB 的存储空间和代码量就够了。但如果未来要共享大段文档、图片或音视频上下文需要考虑存储目录的容量规划。4. 安装部署与启动方式由于项目形态是一个标准的 MCP Server部署方式通常遵循克隆代码 - 安装依赖 - 配置环境变量 - 启动服务 - 在客户端添加 MCP 配置这条链路。下面以通用的 Node.js 版本为例演示具体命令需要按实际仓库调整。4.1 克隆项目git clone 项目仓库地址 cd 项目目录4.2 安装依赖npm install如果项目使用了pnpm或yarn对应改为pnpm install # 或 yarn install4.3 配置环境变量多数 MCP Server 支持通过环境变量或配置文件指定监听地址、端口和存储目录。一个通用的配置示例# 监听本机所有网卡方便局域网内好友访问 export HOST0.0.0.0 export PORT8900 # 上下文存储目录 export CONTEXT_DIR./data如果是 Windows PowerShell则这样设置$env:HOST0.0.0.0 $env:PORT8900 $env:CONTEXT_DIR./data4.4 启动服务npm start启动后控制台通常会出现类似MCP server listening on http://0.0.0.0:8900的日志。表示服务已经在运行下一步就是接入 MCP 客户端。4.5 在 MCP 客户端中添加服务以 Claude Desktop 为例配置文件位置一般在macOS~/Library/Application Support/Claude/claude_desktop_config.jsonWindows%APPDATA%\Claude\claude_desktop_config.json配置文件里增加一个mcpServers条目{ mcpServers: { friend-context: { command: npx, args: [ 项目目录/dist/index.js, --port, 8900 ], env: { HOST: 127.0.0.1, PORT: 8900 } } } }在 Dify 这类平台型工具中通常是填一个 MCP endpoint 地址。如果项目支持 HTTP/SSE 传输那么地址可能是http://127.0.0.1:8900 # 或 http://127.0.0.1:8900/sse具体路径要看项目实现。5. 功能测试与效果验证服务启动、客户端配置完成后不要急着写入大量内容。建议先按下面的流程做最小功能验证。5.1 测试 MCP 客户端能否发现服务在客户端里查看 MCP 工具列表如果配置成功应该能看到这个 Server 提供的工具。常见的工具命名可能包括context_list列出所有共享上下文标识context_get读取指定标识的上下文内容context_set写入或更新上下文内容context_delete删除指定上下文context_subscribe订阅上下文变更如果项目支持如果在客户端里看不到任何工具优先检查服务进程是否存活日志里有没有报错启动时的工作目录是否正确配置里路径是否写错5.2 写入一段共享上下文在客户端中调用context_set输入一个标识和内容。例如{ key: frontend-review-rules, content: 请按照 Vite React TypeScript 项目的代码规范审查以下代码重点关注类型定义、组件拆分布局、样式方案一致性。不要输出与代码审查无关的建议。 }预期结果是返回写入成功并且该标识出现在context_list结果中。5.3 从另一个客户端读取上下文让朋友在另一台电脑上用同一个 MCP endpoint 调用context_get传入相同的 key{ key: frontend-review-rules }如果返回和你写入时一致的内容说明共享链路是通的。这一步是整个项目最核心的验证点因为它证明了上下文不是本地文件而是服务端共享资源。5.4 测试覆盖更新再次调用context_set写入相同 key 但不同的内容随后重新context_get确认返回的是最新内容。这个测试可以验证上下文版本是否会被正确覆盖更新避免出现新旧内容混用的场景。5.5 测试非法输入和权限尝试读取一个不存在的 key观察返回的错误信息是否友好尝试写入超大内容观察是否有大小限制和报错。很多 MCP Server 在初期不会对输入做严格限制但作为使用者你应该在测试阶段摸清楚边界。6. 接口调用与多客户端协作MCP 协议本身就是一种接口规范所以这个项目天然具备接口能力。它的底层通讯是 JSON-RPC 2.0常用的方法包括initialize、tools/list和tools/call。如果你不想在图形客户端里点来点去可以直接用 curl 或 Python 脚本调用。下面给一个通用的 JSON-RPC 调用示例。注意不同项目的 MCP transport 可能有差异有的是标准 stdio有的是 SSE 或 streamable HTTP你需要根据实际项目调整 endpoint。# 初始化 MCP 会话 curl -X POST http://127.0.0.1:8900 \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, id: 1, method: initialize, params: { protocolVersion: 2024-11-05, capabilities: {}, clientInfo: { name: curl-test, version: 0.1.0 } } }调用工具curl -X POST http://127.0.0.1:8900 \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, id: 2, method: tools/call, params: { name: context_get, arguments: { key: frontend-review-rules } } }用 Python 调用也类似import requests url http://127.0.0.1:8900 payload { jsonrpc: 2.0, id: 1, method: tools/call, params: { name: context_set, arguments: { key: daily-standup-template, content: 今天是 {date}请生成一段 3 人小团队的每日站会摘要模板包含已完成事项、今日计划、风险阻塞。 } } } response requests.post(url, jsonpayload, timeout10) print(response.json())当你通过脚本方式调用成功后就可以把共享上下文服务接到自己的自动化工作流中。比如写一个定时脚本每天自动更新某个 key 的上下文内容让群里所有朋友的 AI 助手都能拿到最新的模板。如果是多人同时写入同一个 key需要注意并发冲突。比较简单的设计是最后写入覆盖但更稳妥的做法是给每个需要协调的上下文加一个单独的唯一 key或者把写入日志记录到本地方便回溯。7. 资源占用与性能观察这类轻量级 MCP Server 的资源占用非常低但依然可以从几个角度观察运行状态。7.1 内存和 CPUNode.js 或 Python 写的轻量服务长期运行的内存占用通常在几十 MB 到两三百 MB 之间。如果出现内存持续上涨优先怀疑是否是上下文存储文件被反复加载进内存或者存在未关闭的连接。观察方式# Linux/macOS top -p $(pgrep -f node.*index.js) # 或 ps aux | grep node.*index.js7.2 网络连接如果有很多朋友同时接入可以观察连接数和服务端日志。MCP 是长连接场景连接数会随着客户端数量线性增加。如果接入方太多可以在服务端做连接数限制。# 查看监听端口的连接状态 lsof -i :89007.3 并发读写性能对于纯文本上下文的读写并发能力通常不是瓶颈。但如果存入了一整份很长的文档每次读取都要把完整内容返回给所有客户端网络开销会明显增加。建议不要让单个 key 的上下文体积过大。之前有朋友在 MCP 使用中遇到过上下文过大已进行多次自动总结但上下文大小仍超出限制的问题这种提示在共享上下文项目里同样可能出现避免办法是把超长内容拆分成多个 key按业务场景分开读取。7.4 降低负载的思路只保留必要的 key定期清理过期上下文使用 gzip 压缩响应体在服务端做简单的限流避免单客户端频繁打爆服务对写入内容做大小限制超大文本直接拒绝8. 常见问题与排查方法问题现象可能原因排查方式解决方案客户端配置后看不到 MCP 工具服务未成功启动、路径配置错误、command 参数不对查看服务端控制台日志用npx直接启动验证确认command和args路径正确重启客户端局域网内好友无法访问服务只监听了127.0.0.1或防火墙拦截端口检查启动日志中的监听地址用curl http://本机局域网IP:端口测试将HOST改为0.0.0.0开放防火墙端口读取到的上下文是旧版本多客户端本地缓存了服务列表未重新拉取检查最近一次context_set的返回状态重新调用context_get或让客户端重新连接写入中文内容出现乱码客户端字符编码不一致检查返回 JSON 值的字符编码统一使用 UTF-8避免在 Windows 终端用 GBK 写文件上下文过大导致请求超时单个 key 中存入了过长内容检查存储目录中文件大小拆分 key控制单条上下文长度Dify 添加本地 MCP 服务失败endpoint 类型不匹配SSE / streamable HTTP查看 Dify 日志和 server 端请求日志根据项目支持的 transport 类型填对应 endpoint端口被占用之前启动的服务没有退出使用netstat或lsof查看占用进程结束旧进程或换一个端口启动多人同时写入数据丢失并发覆盖且无锁机制查看服务端是否有冲突日志给不同写入方分配独立 key 前缀或自行实现锁9. 最佳实践与合规使用建议9.1 上下文命名规范建议给共享上下文的 key 加前缀比如friend-a/review-rules、group/dev/commit-rules。这样即使你们是好几个人共用同一个服务端也不会出现互相覆盖的问题。好的命名规范是这个项目能否长期用下去的关键。9.2 私密信息隔离共享上下文的本质是别人也能读。所以绝对不要往里面写数据库连接串、API Token、密码、身份证号、未公开的商业信息。假如真的需要共享这类数据也要通过独立的安全通道并在上下文里填写引用占位符而不是明文。9.3 控制公开范围MCP Server 如果部署在公网必须加一层认证和 TLS 加密。不要图省事直接暴露 MCP 端口。一个比较稳妥的组合是只监听127.0.0.1通过 Nginx/Caddy 反向代理对外暴露反向代理层加 Basic Auth 或其他身份认证开启 HTTPS9.4 定期备份与清理上下文内容虽然体积不大但很多朋友会把精心编写的提示词放在里面。建议把存储目录纳入备份体系定期复制到本地移动硬盘或对象存储。同时清理那些已经不再使用的 key避免服务端列表越来越乱。9.5 合规使用提醒MCP 共享上下文是一种技术手段方便了协作但也可能被用来传播不适宜内容。使用时应确保共享内容合法合规不涉及侵权材料、不传播垃圾信息、不用于任何违反平台规则的行为。如果上下文里包含他人的作品、提示词、图标、代码片段请先确认有授权再共享。10. 总结与下一步Show HN: Share context between friends via MCP这个项目最值得尝试的点是把 MCP 从AI 与工具之间的通道延伸成人与人之间共享 AI 上下文的通道。它不需要 GPU、不需要复杂的数据管线一台小机器、一个 MCP 客户端就能让几个朋友维护同一套上下文模板。从工程角度看它更像一个思路示范而不是一个巨大的平台项目。建议你上手后先做三件事第一用context_set写入一个常用提示词第二换一个客户端或设备去context_get读取第三多人同时写入不同 key验证命名隔离是否有效。最容易踩的坑基本集中在端口监听地址不对、客户端缓存、上下文过大导致超时这几个方面。后续可以继续扩展的方向也不少给共享上下文加版本历史、增加基于 MCP 的订阅通知、做一个简单的 Web 管理面板、把存储从 JSON 文件换成 SQLite 或 Redis这些改造都不会太难。对于想深入理解 MCP 协议的开发者来说这个项目也是一个很适合拿来拆解的轻量样本。