这次我们来看一个很有意思的 Hacker News 项目Share context between friends via MCP。项目名字已经说明了一切——借助 MCP 协议把 AI 上下文从一个模型会话里解放出来在朋友之间共享。说白了就是让我的 Claude、你的 ChatGPT、他用的 Dify 工作流都能通过同一个上下文服务读写同一段背景信息而不是每次都从零开始解释。MCP 这个词在最近的技术圈讨论里密集出现已经不是新鲜概念了。Figma MCP、蓝湖 MCP、Playwright MCP、Dify 本地 MCP 服务、Codex MCP几乎所有主流工具链都在往这个协议上靠。它解决的问题很统一模型怎么按需、安全地访问外部数据和工具。而“朋友之间共享上下文”这个项目等于把 MCP 的应用场景从“人机连接”扩展到了“人人通过 AI 连接”。这篇文章会围绕这个项目拆开讲几件事MCP 上下文共享的核心设计思路、本地部署与启动流程、如何在 Claude Desktop / Dify 这类客户端里接入、怎么验证共享是否生效、以及最关键的安全和权限边界。如果你正打算自己实现一个 MCP server或者想把团队协作上下文接到 AI 工作流里这篇可以直接收藏。1. 核心能力速览在展开部署细节之前先把这类“上下文共享 MCP Server”的能力边界和门槛列出来。以下内容综合项目标题、MCP 协议特性和通用工程实践整理具体参数以你实际拿到的仓库 README 为准。能力项说明项目类型基于 MCP 协议的上下文共享服务客户端-服务端架构核心思路将共享上下文建模为 MCP Resource / Tool支持跨用户读写协议依赖MCPModel Context Protocol底层 JSON-RPC 2.0运行环境Node.jsTypeScript SDK或 PythonPython SDK均可无 GPU 需求部署方式本地 stdio 进程或远程 Streamable HTTP / SSE 端点客户端兼容Claude Desktop、Dify、Cline、Codex、自研 Agent 等支持 MCP 的客户端是否支持 API是MCP Endpoint 本身就是接口可扩展出 HTTP 封装是否支持批量任务取决于实现上下文写入/读取天然适合批处理建议用脚本批量调用显存占用无 GPU 推理需求服务进程内存占用通常在几十到几百 MB 量级敏感度涉及隐私和授权必须做权限控制不能默认公开可写这条链路里MCP server 只是一个“中间仓库”它负责保存上下文、按朋友 ID 或空间 ID 组织内容、提供读写和查询工具。真正消耗算力的模型调用发生在客户端一侧因此这个项目几乎没有硬件门槛。2. 适用场景与使用边界2.1 适合谁这类项目最适合三类人第一MCP 初学者。想理解 MCP 的 Resource、Tool、Prompt 三种原语到底怎么落地与其看一堆官方文档不如跑一个最小上下文共享服务对着代码改一改理解会快得多。第二小团队和熟人协作场景。朋友之间一起做项目、写代码、整理资料时通常需要在多个对话窗口里复述同一段背景。共享上下文服务可以把“项目背景”“代码规范”“常用术语表”集中存起来任何一个人在任何客户端里都能直接读到。第三正在做 Agent 工作流的开发者。如果自研的 Agent 需要跨会话、跨用户共享记忆这个项目提供了一个不错的参考实现MCP 作为统一入口后端存什么、怎么控制权限可以完全自定义。2.2 不适合什么场景不要把这个项目当成公网数据库用。MCP 协议默认强调客户端与 server 之间的信任关系MCP Server 本身不是身份认证系统。如果你不做额外的鉴权层就把共享端点暴露到公网等于允许任何人读写你的上下文内容。也不要把它当成高并发 KV 存储。它更适合低频、上下文相关的读写场景高频毫秒级查询建议用正经数据库。2.3 版权、隐私与合规边界这是必须强调的一点。共享上下文意味着把一段信息复制给其他用户因此需要遵守几个底线不共享任何账号密码、API Key、Token 等机密信息。涉及人脸照片、声音样本、个人真实身份信息时必须获得当事人明确授权。共享代码或文档时确认版权和许可证允许再分发。在公网部署前要评估内容被爬取或泄露的风险。从热词趋势看MCP 正在被大量业务系统接入这也意味着上下文里可能包含企业敏感数据。上下文共享服务默认应关闭公开注册限定为受信任成员。3. 环境准备与前置条件下面给出一套通用的本地部署环境清单。没有硬性版本号要求的情况下我按常规工程实践给保守建议实际以项目 README 为准。3.1 基础环境组件建议操作系统Windows 10/11、macOS、主流 Linux 发行版均可Python3.9 及以上推荐 3.10/3.11Node.js可选18 及以上如果用 TS SDK 实现 server包管理工具pip / uv / npm / pnpmGit用于拉取项目源码客户端Claude Desktop、Dify 社区版或任意支持 MCP 的 Agent 框架3.2 需要理解的关键概念在动手前先对应着理解 MCP 的三个原语Prompts预置的提示词模板让用户通过自然语言触发固定操作。Resources暴露上下文数据通常是只读的文件、数据库记录、URL 等。Tools可执行的操作比如“写入上下文”“搜索上下文”“订阅好友上下文”。这个项目从名字推断重点会落在 Resources 和 Tools 上把“某个朋友的上下文”暴露成 Resource用 Tool 完成写入和查询。3.3 网络与端口本地测试时stdio 传输方式不需要监听端口。如果采用远程 HTTP 传输需要预留一个端口供 MCP 客户端访问。常见做法是绑定127.0.0.1或内网 IP再用反向代理加 HTTPS。端口冲突是高频问题。如果你本机 8000、8080、3000 已被占用可以更换自定义端口并确保客户端配置里的 URL 同步更新。4. 安装部署与启动方式由于“Share context between friends via MCP”目前只是 Show HN 展示项目没有公开完整 README 细节时我们不能凭空给一键安装脚本。下面我用 MCP 官方 SDK 写一个最小实现让你理解这类项目的核心结构同时给出通用的启动方式。4.1 用 MCP Python SDK 实现最小上下文共享服务创建项目目录后先安装依赖mkdir friend-context-mcp cd friend-context-mcp python -m venv .venv # Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate pip install mcp[cli] httpx然后创建一个server.py核心逻辑是按 friend_id 读写上下文内容并通过 MCP 以 Resource 和 Tool 两种方式暴露。import json from typing import Any from mcp.server.fastmcp import FastMCP mcp FastMCP(friend-context) # 这里仅做内存存储演示实际建议用 SQLite / Redis / 文件持久化 STORAGE: dict[str, list[str]] {} def read_context(friend_id: str) - str: records STORAGE.get(friend_id, []) return \n.join(records) if records else mcp.resource(context://{friend_id}) def get_context_resource(friend_id: str) - str: return read_context(friend_id) mcp.tool() def append_context(friend_id: str, content: str) - str: 按 friend_id 追加一条共享上下文。 if not content.strip(): return error: content is empty STORAGE.setdefault(friend_id, []).append(content.strip()) return fok, {friend_id} now has {len(STORAGE[friend_id])} records mcp.tool() def search_context(friend_id: str, keyword: str) - str: 搜索某个好友上下文里的关键词。 records STORAGE.get(friend_id, []) matches [r for r in records if keyword in r] if not matches: return no match return \n---\n.join(matches) mcp.tool() def list_friends() - list[str]: 返回当前有上下文记录的好友 ID 列表。 return list(STORAGE.keys()) if __name__ __main__: mcp.run()这个示例能把项目核心逻辑跑通好友上下文以friend_id为维度隔离A 朋友写入的内容不会出现在 B 朋友的空间里除非你主动设计成“群组共享”。4.2 在 MCP 客户端里配置本项目最常见的接入方式是把 server 配置到 Claude Desktop 或 Dify 中。配置文件通常是claude_desktop_config.json或项目下的mcp.json结构如下{ mcpServers: { friend-context: { command: python, args: [server.py], cwd: D:/projects/friend-context-mcp } } }如果你在远程服务器上以 HTTP 方式启动则配置改为{ mcpServers: { friend-context: { url: https://your-server.example.com/mcp, headers: { Authorization: Bearer your-token } } } }4.3 远程部署与守护进程远程部署时不要让 Python 进程裸奔。推荐用systemdLinux或pm2Node/supervisord做进程守护。一个简单的 systemd 服务模板如下实际情况按路径替换[Unit] Descriptionfriend-context-mcp Afternetwork.target [Service] Userwww-data WorkingDirectory/opt/friend-context-mcp ExecStart/opt/friend-context-mcp/.venv/bin/python server.py Restartalways RestartSec3 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.target启动后建议先用journalctl -u friend-context-mcp -f观察日志确认服务是否正常监听。4.4 独立 Web UI 或管理后台Show HN 项目往往只侧重 MCP 端点并不一定会提供完整管理后台。如果你的目标是长期使用可以自己补一个轻量后台用 FastAPI 封装append_context/search_context并增加简单的 token 鉴权方便非技术朋友通过网页读写上下文。5. 功能测试与效果验证项目跑起来后最怕的是“服务启动了但客户端工具不出现”。我建议按下面五个步骤验证每一步都有明确的成功标准。5.1 验证 MCP Server 能正常启动直接运行python server.py日志里出现 MCP 服务启动信息没有异常堆栈说明基础进程没问题。如果启动时报依赖缺失回到第 4 节确认mcp包是否安装到当前虚拟环境。5.2 用 MCP Inspector 验证工具和资源MCP 官方提供了mcp-inspector这是调试 MCP server 最直接的工具。启动命令mcp inspector python server.py在浏览器打开 Inspector 页面后检查三点Resources 列表里有没有context://{friend_id}。Tools 列表里有没有append_context、search_context、list_friends。手动调用append_context传入friend_idalice和一段测试文本返回是否正常。成功标准工具列表存在且手动调用返回ok。5.3 在 Claude Desktop 中验证共享效果配置好claude_desktop_config.json后重启 Claude Desktop。在对话框中直接请求“调用 friend-context 工具给 alice 写入一条内容我们正在开发一个 MCP 共享工具。”如果配置成功Claude 会主动调用工具并返回结果。然后新开一个会话再请求“读取 alice 的上下文。” 如果能看到刚才写入的内容说明跨会话共享已经生效。5.4 在 Dify 中验证本地 MCP 服务Dify 的新版本支持在 Agent 或工作流中配置 MCP 服务。操作路径一般是工具设置 - MCP 服务 - 添加本地 MCP 服务。这里需要根据 Dify 版本的界面差异填写 server 配置。成功标准在 Dify Agent 的提示词里要求调用search_context模型能正确把参数映射到工具并返回结果。5.5 验证上下文隔离与权限这是最关键的一步。写入friend_idalice的内容再尝试读取friend_idbob确认返回为空。如果项目里没有显式权限控制这一步会暴露隔离问题后续必须补上。# 手动模拟隔离验证 from server import STORAGE, append_context, read_context append_context(alice, 这是我的私密上下文) print(read_context(bob)) # 预期输出为空判断成功的标准不同 friend_id 之间完全隔离没有任何串号。6. 接口 API 与批量任务MCP 协议本身已经是一种标准接口。它通过 JSON-RPC 2.0 通信客户端可以调用tools/call来执行工具。如果你不想依赖图形客户端完全可以用脚本直接调用。6.1 通过 MCP Client 调用共享上下文下面是用 Python 调用 MCP 工具的最小示例。这里以 stdio 方式连接本地 serverimport asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def append_context(session: ClientSession, friend_id: str, content: str) - str: result await session.call_tool( append_context, arguments{ friend_id: friend_id, content: content, }, ) return str(result) async def main(): params StdioServerParameters( commandpython, args[server.py], cwdD:/projects/friend-context-mcp, ) async with stdio_client(params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() print(await append_context(session, alice, batch record 1)) print(await append_context(session, alice, batch record 2)) print(await session.call_tool(list_friends, {})) if __name__ __main__: asyncio.run(main())实际项目如果使用 MCP TS SDK调用方式类似只是包名和方法名不同。重点是MCP 工具调用天然支持编程方式可以非常方便地接入自己的脚本。6.2 HTTP 接口封装不是所有下游系统都喜欢直接走 MCP。如果团队内部有现成的 HTTP 调用体系可以再包一层 FastAPI。下面是一个通用模板from fastapi import FastAPI, Header, HTTPException app FastAPI() def check_token(authorization: str | None): # 实际场景中换成自己的 token 校验逻辑 if authorization ! Bearer test-token: raise HTTPException(status_code401, detailunauthorized) app.post(/api/context/{friend_id}) async def write_context(friend_id: str, payload: dict, authorization: str | None Header(defaultNone)): check_token(authorization) content payload.get(content, ) return {status: ok, friend_id: friend_id, content: content}这段代码只是演示接口分层思路并没有绑定具体存储实现。真正要上生产时应在 HTTP 层再做一层速率限制和请求日志。6.3 批量任务设计批量写入或批量读取是这个项目很适合的场景。合理设计是用消息队列或一个简单的 Python 脚本循环读取friends.json逐个调用append_context。{ tasks: [ { friend_id: alice, content: 上下文内容 1 }, { friend_id: bob, content: 上下文内容 2 } ] }批量任务建议加三个能力幂等标识每条内容带一个record_id重复执行不会产生重复记录。失败重试单条失败先记录日志不要中断整个批次。限速控制 QPS避免把 MCP server 打挂。7. 资源占用与性能观察这个项目没有 GPU 推理资源占用重点看三件事进程内存、磁盘写入、连接数。7.1 如何观察资源占用本地启动后用系统命令查看进程状态# Linux / macOS top -p $(pgrep -f server.py) # Windows PowerShell Get-Process python | Select-Object Id, WorkingSet64, CPU, StartTimeMCP 客户端每开一个会话就会建立一个连接。如果连接的会话不关闭进程会持续保持活跃进而可能造成资源累积。排查这类问题可以用 lsof 或者 netstat。# 查看监听端口替换成你的实际端口 netstat -ano | findstr :80007.2 上下文过大的处理热词里出现了“上下文过大已进行多次自动总结但上下文大小仍超出限制”这类问题这在共享上下文场景里非常真实。当某个好友的上下文累积到几千条甚至几万条时读取全部内容会让模型直接超限。缓解策略有三个滚动窗口只返回最近 N 条记录。自动摘要每次追加内容时对旧记录做一次摘要压缩把摘要作为新记录存进去。分级存储热门上下文放内存冷数据放 SQLite 或文件存储。7.3 降低存储与传输开销如果共享的上下文包含长文链接或整篇文档建议不要把全文塞进上下文。更合理的方式是只存引用 ID 和摘要原文放到对象存储或数据库里模型需要时再通过另一个 MCP Tool 拉取全文。这样既能减少上下文体积也能降低每次读取的响应时间。8. 常见问题与排查方法下面这张表覆盖了从部署到使用最常见的故障点。问题现象可能原因排查方式解决方案启动后没有输出进程立即退出依赖未安装或语法错误在终端前台运行python server.py看报错安装项目依赖检查 Python 版本客户端配置后工具列表为空MCP server 启动失败或进程路径错误查看客户端日志确认command和args可执行用绝对路径确保cwd正确调用 append_context 报超时服务卡死或连接数过多检查服务端日志和内存占用增加进程守护必要时重启服务不同好友之间上下文串号没有做 friend_id 隔离或存储 key 拼错检查存储读写逻辑每个操作都显式传入 friend_id远程连接失败端口未开放、无 HTTPS、token 错误用 curl 测试端点连通性配置反向代理开启鉴权头上下文过大导致客户端报错返回内容超模型窗口查看返回文本长度使用滚动窗口或摘要压缩Dify 添加本地 MCP 服务后不生效Dify 版本不支持或配置格式不对查看 Dify 日志确认 MCP 配置项名称升级 Dify 版本按官方格式重试批量任务中途卡住某条数据格式导致异常给脚本加单条日志捕获异常并跳过/重试排查时有一个通用原则先确认 MCP server 本身能通过 Inspector 调用再去排查客户端配置问题。Inspector 是最小验证闭环能减少很多误判。9. 最佳实践与使用建议9.1 目录与数据管理建议把数据文件、日志、配置分离不要全部堆在项目根目录friend-context-mcp/ server.py requirements.txt data/ contexts.db logs/ server.log config/ mcp.json这样的好处是备份数据时只需要备份data目录清理日志时不会影响程序文件配置变更时可以单独 diff。9.2 权限模型建议最小可用权限模型分为三级公开上下文适合团队共享的项目背景任何人可读。好友上下文仅好友之间可读写。私密上下文只有本人可读写。从这个项目的名字来看核心定位是第二级。实际实现时不要在业务代码里硬编码权限建议用一张权限表记录user_id、friend_id、permission三列。9.3 内容过滤与合规无论上下文是文本、URL 还是文件引用写入前都应做一道内容检查是否包含明显的密钥特征sk-、api_key、password等。是否包含非授权的人脸、声音、个人隐私信息。是否包含版权受限的完整文档。一道简单的词法过滤可能不够建议在共享前人工审核高风险内容尤其是涉及企业业务数据时。9.4 保留一套最小可运行配置改成乱七八糟前先留一个稳定版本。比如在 Git 里为最初的server.py打个 tag保证任何时候都能回退到“能启动、能调用”的状态。第一次尝试新功能时用独立分支测试不要直接改主干。10. 总结与下一步这个项目最值得尝试的点不是功能多复杂而是它把 MCP 的协作场景做得很轻一个朋友 ID 就是一块上下文空间读写分离天然能接进现有 MCP 客户端。如果你想验证自己是否真的理解了 MCP按这篇文章的步骤把最小 server 跑通再用 Claude Desktop 或 Dify 完成一次“写入 - 新会话读取”基本就算入门了。最容易踩的坑是权限和上下文体积。很多新手跑通本地 demo 后就把服务端口暴露到局域网甚至公网结果上下文被随意写入然后又被“上下文过大”绊住。我的建议是第一版先只允许本机和内网访问等确认逻辑稳定后再考虑远程部署存储上从一开始就用 SQLite 或文件持久化不要用纯内存存储否则服务一重启所有共享上下文就丢了。下一步可以往三个方向扩展。第一是接入更多 MCP 客户端比如 Cline、Codex、自研 Agent验证跨客户端共享是否一致第二是增加群组共享能力把“一个好友一个空间”升级为“一个项目一个空间”第三是参考生态里已经出现的 Figma MCP、设计协作工具 MCP把共享上下文从纯文本扩展为结构化数据比如标签、文件引用、关键实体关系。这样一套做下来这个 Show HN 项目就不再只是 demo而是一个能真正支撑小团队 AI 协作的轻量基础设施。