把 AI 助手的上下文通过 MCP 分享给朋友这个玩法看起来很小众但它踩中了 MCPModel Context Protocol模型上下文协议最实用的一层价值让模型能按需访问别人维护的数据。Show HN 上的这个项目思路并不复杂——你本地跑一个 MCP Server提供分享、读取、检索上下文的工具朋友在自己的 AI 客户端里接入同一个服务就能拿到你共享的对话摘要、资料片段和项目笔记。我花了一些时间把这类“朋友共享上下文”的方案完整跑了一遍包括单机验证、跨客户端配置、多人共享、权限设计和上下文过大这类典型问题。下面按实际落地顺序拆开讲。适合谁看如果你已经在用 Claude、Dify、Cursor、Codex 这类支持 MCP 的客户端想把自己维护的知识和上下文分享给朋友或小团队这篇文章可以直接照着操作。1. 先搞明白这个项目到底在“分享”什么1.1 MCP 不是工具是一套连接协议MCP 全称 Model Context Protocol解决的是模型与外部数据、工具之间的连接问题。你可以把它理解成 AI 世界的标准化插头客户端负责对话和任务编排服务端负责暴露资源、工具和提示模板两者通过协议交换信息。这个“分享上下文”项目没有重新发明协议它只是自己做了一个 MCP Server专门用来管理人与人之间的上下文共享。被共享的内容可以是一段对话摘要、一份项目笔记、几张资料卡片、一条代码评审结论或者一组书摘链接。朋友那边不需要看你的聊天记录原文只需要通过客户端调用你暴露的工具就能拿到整理后的上下文。这是它和“直接把聊天记录发过去”最本质的区别共享的是结构化上下文不是原始聊天流。1.2 要分享的上下文有哪些常见形态实际使用时值得分享的上下文通常不是随手复制粘贴的大段文字而是经过筛选和整理的信息。形态例子适合共享吗对话摘要本次讨论的结论、待办、分歧点非常合适项目笔记环境搭建记录、踩坑记录非常合适资料链接文章、论文、视频的要点合适代码片段可复用的函数、配置片段合适完整聊天记录几万字的原始对话不建议原因很简单MCP 工具更适合返回小型、可检索、可复用的信息。朋友读取一条“会议结论”比读三万字的聊天记录效率高得多。1.3 相比直接发文档MCP 方案的差异在哪直接发消息或云文档也能分享信息但有几个问题不可检索消息被刷上去之后很难再被 AI 客户端当作“工具”按需读取。不同步你更新了结论朋友手里的旧版本不会自动变化。难合并多人各自维护文档最后要靠人工整理。通过 MCP Server 共享好处是上下文变成了可调用的服务。朋友在对话里让 AI 调用你的共享工具读取到的永远是最新内容而且可以按 context_id 精确取用。缺点也很明显需要自己维护服务端权限和存储都要自己设计不是开箱即用的网盘。2. 环境准备跑通前先把“服务端-客户端-配置”三件事对齐2.1 服务端需要什么条件这个项目的服务端本质上就是一个 MCP Server。以常见做法来说你可以用 Python 或 Node.js 写也可以直接用官方 SDK 快速搭一个框架。最低运行条件并不高Python 3.9 以上或 Node.js 16 以上。安装对应语言的 MCP SDK。本地存储用 SQLite 或 JSON 文件起步先不引入数据库。如果只是自己机器上的两个客户端共享用 stdio 模式即可如果要让朋友通过网络访问需要把服务部署到有公网地址的机器上并开放对应端口。这里我建议先用本地 stdio 模式验证不要一上来就部署远程服务。stdio 模式下客户端直接拉起本地进程调试日志都在终端里出现问题一眼能看到。2.2 客户端怎么接入目前主流支持 MCP 的客户端接入方式大致分三类。客户端配置方式说明Claude Desktopclaude_desktop_config.json在客户端配置目录里维护mcpServersDify工具 / Agent 设置里添加 MCP支持本地进程和 HTTP/SSE 端点Cursor / Trae 等编辑器项目级.mcp文件跟随项目团队内可共用Codex / 命令行工具CLI 配置或环境变量适合脚本化和自动化场景mcpServers里最核心的就是三件事服务名、启动方式、参数。本地进程用command加args远程服务用url或transport指定协议。很多“连不上”的问题都是本地和远程模式没对齐造成的。2.3 本地服务还是远程服务这个选择决定了你后面的配置方式和工作量。如果是“我开两个客户端互相共享上下文”本地 stdio 就够配置最简单。如果是“我和三个朋友共享上下文”服务端必须能通过网络访问否则朋友的客户端无法连接到你的机器。远程部署要额外考虑三件事端口是否对外开放、是否被防火墙拦截。服务是否用 HTTPS 暴露明文 HTTP 在长期使用时会有安全风险。服务进程是否足够稳定会不会因为一段时间的空闲被系统回收。注意远程共享不等于把服务直接裸奔到公网。接入阶段建议先用测试数据验证确认没问题后再加入真实上下文。3. 从零搭一个朋友共享上下文的 MCP Server3.1 最小可运行骨架以 Python 的 MCP SDK 为例一个最简的服务端可以只有几十行。from mcp.server.fastmcp import FastMCP mcp FastMCP(friend-context-server) store {} mcp.tool() def share_context(context_id: str, content: str, owner: str) - str: 写入一条上下文返回写入结果 store[context_id] {content: content, owner: owner} return fok:{context_id} mcp.tool() def get_context(context_id: str) - str: 读取一条上下文 item store.get(context_id) return item[content] if item else not found if __name__ __main__: mcp.run()这段代码的核心不是功能完整而是把“工具”这个概念跑通。mcp.tool()声明了两个工具客户端配置好后就能直接调用。先用内存字典存储验证链路没问题再换成 SQLite 或正式数据库。3.2 在客户端里注册这个服务假设你用 Claude Desktop配置文件里加上这一段{ mcpServers: { friend-context: { command: python, args: [/path/to/friend_context_server.py], env: {} } } }如果你是编辑器用户项目根目录下的.mcp文件写法类似{ mcpServers: { friend-context: { command: python, args: [server.py] } } }.mcp文件的含义就是“跟随项目的 MCP 配置”团队拉取代码后可以直接使用同一个服务配置。注意command要能直接在系统环境里找到如果你用的是虚拟环境里的 Python建议写绝对路径否则经常会出现“服务起不来但看不出原因”的问题。3.3 单条上下文跑通验证配置完成后建议按下面的顺序验证不要跳过先在终端手动启动服务确认进程不退出、没有 import 报错。在客户端中重新加载 MCP 服务确认工具列表里出现了share_context和get_context。让 AI 助手调用share_context写入一条测试内容。再让 AI 调用get_context读取刚才写入的内容。对比写入和读取的结果是否一致。成功的标准很简单工具能被列出、调用不报错、两次读取内容一致、服务端日志没有 ERROR。不要一上来就同时让多个客户端调用也不要开大并发。先把一条链路跑稳再谈批量。4. 从单机到朋友共享存储、权限和上下文大小4.1 上下文数据放哪里本地演示用 JSON 文件或内存都可以但一旦涉及多个朋友就必须考虑数据持久化和并发写。我的建议是最少用 SQLite表结构可以非常简单。一张contexts表大概包含这些字段context_id上下文唯一标识。owner创建者。friend_ids允许读取的朋友列表。type类型比如 note、summary、link。content正文内容。created_at/updated_at创建和更新时间。表结构越简单越好。共享场景最怕的不是字段不够而是字段设计过度最后没人维护。先把“谁能读、谁能写、写什么”三个问题用表字段表达清楚后续再扩展。4.2 权限怎么设计朋友共享不等于全公开。最简单可控的权限模型是“每条上下文指定可见范围”写入时创建者声明哪些 friend ID 可以读取。读取时服务端先校验请求者身份再决定是否返回内容。修改时建议只允许创建者本人修改。在 MCP 工具层实现时可以给每个工具增加一个caller参数代表当前调用者的身份。这样虽然简陋但对学习和小团队场景已经够用。真正要注意的是不要把整个聊天记录直接塞进共享上下文。共享摘要、共享结论、共享可执行的信息比共享原始数据安全得多。4.3 上下文过大是共享场景最常踩的坑很多人在使用 MCP 时会遇到“上下文过大已进行多次自动总结但仍超出限制”的提示。这个问题在共享场景里尤其容易出现原因通常有两个第一单条 context 内容过大。你把一整个项目的历史对话全部写入一条上下文AI 客户端读取时直接撑爆窗口。第二读取时一次拉取太多条目。调用list_contexts时没有分页一次性返回几千条。对应的解决办法也很直接写入前先做摘要或分段每段控制在模型上下文窗口可承受的范围内。读取工具增加limit和offset参数强制分页。工具返回体里的非必要字段尽量去掉比如不返回updated_at的完整时间戳除非确有必要。注意服务端返回的数据量会直接占用客户端的上下文窗口。共享工具在返回前要做一次“裁剪”而不是无脑返回完整字段。4.4 多朋友、多分组怎么扩展如果只是两三个朋友用friend_ids字段就够了。人再多一些建议引入分组概念groups表保存分组信息。contexts里的可见范围可以指向某个 group而不是逐个朋友 ID。后续还可以加订阅或通知机制朋友读取后标记已读或者上下文更新时通知相关人。另外很多人会把 Agent Skill 和 MCP 混在一起。简单区分MCP 着重提供“工具和资源访问”解决的是模型能不能调到外部数据的问题Skill 更像预置的提示词和流程模板解决的是“同样一类任务怎么稳定执行”的问题。共享上下文项目里两者可以配合MCP 负责读写数据Skill 负责让 AI 按固定格式生成摘要和待办。5. 实战中容易踩的坑和排查顺序5.1 服务起不来先看环境和路径最常见的是command not found或者ModuleNotFoundError。这时候不要先去怀疑协议先按顺序查当前终端能不能直接执行配置里的command。args里的脚本路径是否绝对路径、是否存在。Python/Node 版本是否满足 SDK 要求。依赖包是否安装是否装进了被客户端使用的那个环境。很多时候问题出在客户端进程的环境变量和你的终端环境不一样。虚拟环境里的 Python在桌面客户端里不一定找得到。5.2 工具调用报错先对齐传输模式“服务端能跑但客户端提示 tool not found”这类问题大概率是传输模式不一致。本地文件配置的是 stdio服务端却以 HTTP 方式启动或者客户端配了url服务端还在监听 stdio。排查思路是先把一端固定本地调试统一用 stdio。远程调试统一用 HTTP/SSE并且确认服务端真的监听在对应端口。每次只改一个环节改完立刻看服务端日志。5.3 上下文不同步先看写入是否成功如果你写入一条上下文但朋友读取时看不到先不要怀疑协议先看数据层服务端写入后数据库或文件里真的保存了吗朋友访问的服务实例和你写入的实例是不是同一个有没有可能存在多个服务进程各自指向不同的数据文件多实例指向不同存储是共享场景非常隐蔽的坑。服务端看似正常实际读写的是两个数据库。解决方法是把存储路径写绝对路径并在启动时打印当前使用的存储文件。5.4 固定排查链路遇到任何问题我一般按这个顺序走能省掉大量无效尝试先看现象是启动失败、调用报错、返回空还是速度过慢。再看服务端日志有没有异常堆栈、连接记录、错误码。再看客户端配置路径、端口、协议、环境变量是否和服务端一致。再看数据层写入是否成功、读取条件是否正确。最后再看参数边界是不是单条内容过大、并发过高、分页缺失。这套链路适合绝大多数 MCP 共享场景。不要一上来就改代码或换协议大多数问题出在配置和路径上。6. 方案的边界、适用场景和后续空间6.1 适合什么不适合什么适合的场景是三五人的学习小组共享资料摘要和讨论结论。开源项目协作者之间共享环境配置和踩坑记录。个人在多台机器、多个客户端之间同步自己整理好的上下文。想让 AI 客户端能按需读取朋友维护的笔记而不需要每次都人工复制。不适合的场景也要提前说清楚不适合当网盘用尤其是大文件和二进制文件。不适合高安全要求的场景权限模型做得很粗无法满足企业级审计。不适合强实时协同多个朋友同时对同一条上下文编辑需要额外做冲突处理。不适合完全替代团队知识库MCP Server 只是访问层管理界面仍然缺失。6.2 稳定性建议如果项目要长期用而不是只跑一个演示建议把这几件事提前做加日志每次工具调用都记录调用者、调用时间、返回状态。定义输出命名和分类规则context_id 不要乱起统一前缀比如note/、summary/、link/。做失败重试写入失败要有明确的错误信息读取失败要有兜底返回。定期备份SQLite 文件很小每天备份一次成本很低但能救命。6.3 还可以扩展什么这个项目最大的想象空间不在协议本身而在“上下文如何被生产、整理和消费”。后面的版本完全可以从这几个方向扩展自动摘要接入一个摘要服务把长对话自动转成结构化上下文再共享。定时同步定时从某个数据源拉取内容更新到共享上下文里。Webhook 通知上下文更新时通知相关朋友。连接更多生态比如把浏览器操作能力、数据库访问能力也做成 MCP 工具让共享上下文不只是静态笔记而是可执行操作的入口。我在实际跑完后最大的感受是MCP 让“上下文”不再是一个只能在浏览器里翻看的聊天记录而是变成了可编程、可检索、可共享的资产。这个方向比“多一个玩具项目”更有价值也值得花时间继续打磨。如果你也想自己搭一个建议从小处开始先本机跑通一条上下文再让朋友加入最后再谈分组、权限和自动化。别一上来就规划一个分布式架构先把“和朋友共享一条笔记”这件事做顺后面一切都好说。