最近 MCP 这个词在开发圈里出现频率越来越高从 Dify 本地接入 MCP Server到 WorkBuddy 通过 MCP 直接访问数据库再到 Figma MCP、支付宝 MCP 这类面向业务场景的实践几乎每一个环节都有人讨论“怎么把真实业务上下文交给 AI”。但大部分教程讲的是“如何接入一个 MCP 工具”很少有人认真讲一个问题MCP 真正改变的是什么我的判断是MCP 不只是“AI 访问外部工具”的接口标准它更是一个上下文协作协议。所有围绕它的热点本质上都是在解决同一个痛点——如何让 AI 理解真实世界的信息并让这些信息在不同人、不同 Agent 之间流转。本文从一个很有意思的 Hacker News 项目标题切入Show HN: Share context between friends via MCP。这个标题虽然很短但信息量不小。读完这篇文章你可以理解 MCP 的核心概念与适用场景并亲手实现一个“在朋友或协作者之间共享上下文”的最小 MCP Server包含完整代码、客户端配置和排错思路。1. 为什么 MCP 突然成了开发圈的公共话题先看一个现象。各大技术社区关于 MCP 的搜索词已经从最早的“MCP 是什么”“MCP Server”扩展到了非常具体的实践场景Dify 添加本地 MCP 服务Win 系统上怎么创建 MCPCodex MCP、Playwright MCPSSH MCP、Trae 集成 MCP支付宝 MCP 的使用上下文过大已进行多次自动总结但上下文大小仍超出限制。请检查 MCP 服务器或 Skill这些搜索词说明什么说明开发者已经不满足于“理解概念”而是开始把 MCP 用在真实工作流中。大家真正关心的不是协议本身多优雅而是三件事如何让 AI 助手拿到我项目里的真实数据如何让 AI 助手操作外部系统而不是只停留在聊天框如何把多个 AI 工具、多个协作者的上下文统一起来避免“各说各话”。第三点恰恰是“通过 MCP 共享上下文”这个方向的核心价值。过去我们做上下文共享手段基本是拉群、发文档、贴聊天记录信息是碎片化的、不可检索的而且很难让 AI 增量消费。MCP 提供了一条结构化路径把上下文暴露成服务端资源让多个客户端按需读取。所以这篇文章不打算再写一份“MCP 入门指南”而是直接进入一个具体场景你和朋友共同维护一个开源项目两个人都在用 AI 助手如何用 MCP 把项目状态、讨论结论、待办事项同步起来。如果你正在做 AI 应用开发、Agent 工具链落地或者只是好奇“MCP 到底能解决什么实际问题”这篇文章应该能给你一个可以直接跑通的最小方案。2. MCP 协议的核心概念从工具调用到上下文共享MCP 的全称是 Model Context Protocol由 Anthropic 在 2024 年开源。它的目标很直接统一 AI 模型与外部数据、工具之间的交互方式。理解 MCP 的关键是分清四个角色角色作用你可以把它理解成Host宿主运行 AI 模型和交互界面的应用聊天窗口、IDE 插件Client客户端与 Server 建立连接发起请求接线员Server服务端提供工具、资源、提示词工具箱 / 数据仓库数据源被 Server 封装的外部系统数据库、文件、网页、API过去一个 AI 应用想要读取本地文件需要写死一段代码想要查数据库又要单独写一套 SQL 封装。每个模型、每个 Agent 框架都要重复造轮子。MCP 的贡献是把这个过程标准化了Server 暴露统一接口Client 统一调用传输层可以是 stdio 本地进程也可以是 SSE / HTTP 远程服务。MCP Server 主要提供三类能力Tool工具由模型决定何时调用适合“执行动作”例如写入文件、发请求、执行命令。Resource资源数据由客户端按需读取适合“提供上下文”例如读取文档、项目配置、共享笔记。Prompt提示词模板客户端可以主动调用的模板帮助用户快速发起特定任务。很多人第一次接触 MCP 时最容易犯的误解是把所有东西都设计成 Tool。但如果你只是想让 AI“看到”某份上下文内容把它设计成 Resource 会更自然因为模型不需要主动调用它客户端可以在对话开始时主动注入。这也是“共享上下文”项目里最重要的设计决策上下文是作为工具被调用还是作为资源被读取答案会影响整个架构。3. 共享上下文到底在解决什么真实痛点一个人使用 AI 助手通常遇到的典型问题是什么是上下文断裂。比如你上午跟 AI 讨论了一个功能设计下午继续聊时AI 已经不记得上午的结论。你只好把聊天记录复制粘贴一遍甚至贴完还会被提示“上下文过长已经自动总结多次但仍然超出限制”。两个人使用 AI 助手问题会加倍。你和朋友都针对同一个项目聊天、写代码但彼此不知道对方和 AI 说了什么。于是常见场景变成了这样你花了一下午让 AI 整理出一份部署方案朋友晚上又问了一遍 AI得到完全不同的答案你发现一个线上问题在群里发了三条消息朋友下次启动 AI 时完全不知道两个人各自维护一份项目文档最后根本不知道哪份是最新的。传统的解决办法是共享一个 Git 仓库或一份在线文档。但文档是给“人”看的AI 不能自动消费即使能粘贴给 AI也缺少结构化入口不好检索、不好追加。用 MCP 做共享上下文本质上是把“上下文”变成一种可编程资源。它可以被多个客户端读取可以按主题追加可以被 AI 作为事实依据。相比聊天记录和文档它有两个优势上下文不是静态快照而是持续更新的服务端资源读取和写入都通过统一协议任何人用任何支持 MCP 的客户端都能访问。从这个角度看“Share context between friends via MCP”虽然听起来像玩具项目但它触及的其实是 AI 协作中最现实的问题如何让 AI 的理解保持一致。4. 方案设计一个最小可用的共享上下文架构要实现“通过 MCP 在朋友之间共享上下文”不需要一开始就上数据库、上云 Sync。最简单、最可控、也最容易审计的方案是共享文件 MCP 读写。整体架构分三层共享存储层一个 Markdown 文件放在两台机器都能访问的位置。最简单的方案是放进 Git 仓库或者用网盘同步目录。这个文件就是“共享上下文”的事实来源。MCP Server 层一个本地 Python 服务把文件封装成两个能力。append_context 用于追加内容context 资源用于读取全部内容。客户端接入层两个朋友各自的 AI 客户端通过 MCP 配置连接到同一个 Server。为什么选文件而不是数据库因为共享上下文场景的特点是写入不频繁、可读性强、需要人工审查。Markdown 文件天然适合这个场景可以直接用 Git 看 diff可以用编辑器快速修改出问题了一键回滚。数据库方案适合更大规模的团队但需要额外维护权限、连接、并发控制不适合作为第一版。这里的核心设计思路是MCP Server 不负责解决所有问题只负责把“上下文文件”的读写能力暴露出来。同步问题交给 Git权限问题尽量简化格式问题用 Markdown 的二级标题作为主题分区。5. 环境准备与项目初始化这一节开始实操。环境要求如下操作系统Windows / macOS / Linux 均可本文命令基于 Linux/macOS 习惯Windows 下注意路径分隔符区别Python 3.10 及以上版本pip 或 uv本文使用 pip一个支持 MCP 的客户端常用的有 Claude Desktop、Dify、Cline、Cherry Studio 等。首先创建项目目录并安装依赖。mkdir shared-context-mcp cd shared-context-mcp python -m venv .venv source .venv/bin/activate pip install mcp如果你使用 Windows激活虚拟环境的命令是.venv\Scripts\activatemcp是官方 Python SDK安装完以后FastMCP 模块可以直接导入。FastMCP 是 SDK 提供的简化封装好处是不用手动处理协议消息只需写装饰器函数。项目目录结构如下shared-context-mcp/ ├── server.py ├── .venv/ └── README.md这里我还建议在 README 中约定共享上下文的写作规范后面会讲到具体规范。安装完成后可以先确认版本python -c import mcp; print(mcp.__version__)这一步能尽早发现 Python 环境问题。如果提示找不到模块说明依赖没有安装到当前虚拟环境。6. 核心代码实现一个支持读写上下文的 MCP Server下面创建一个最简但功能完整的 MCP Server。代码放在server.py。# server.py import os from pathlib import Path from mcp.server.fastmcp import FastMCP SHARED_DIR Path.home() / .shared-context CONTEXT_FILE SHARED_DIR / context.md mcp FastMCP(shared-context-server) def _ensure_file(): SHARED_DIR.mkdir(parentsTrue, exist_okTrue) if not CONTEXT_FILE.exists(): CONTEXT_FILE.write_text(# Shared Context\n, encodingutf-8) def _read_all() - str: _ensure_file() return CONTEXT_FILE.read_text(encodingutf-8) mcp.tool() def append_context(section: str, content: str) - str: 向共享上下文的指定主题追加一段内容返回当前总行数。 Args: section: 主题名称例如 部署讨论 或 Bug排查 content: 要保存的内容 _ensure_file() text _read_all() if not text.endswith(\n): text \n text f\n## {section}\n{content}\n CONTEXT_FILE.write_text(text, encodingutf-8) return fok, total lines: {len(text.splitlines())} mcp.resource(shared-context://all) def get_context_all() - str: 读取完整共享上下文供客户端在对话开始时加载。 return _read_all() mcp.tool() def search_context(keyword: str) - str: 在共享上下文中按关键字搜索返回匹配的段落。 Args: keyword: 搜索关键词 text _read_all() lines text.splitlines() result [] current_section None for line in lines: if line.startswith(## ): current_section line elif keyword in line: result.append(f{current_section or 未分区}: {line}) if not result: return no match return \n.join(result) if __name__ __main__: mcp.run()这段代码做了三件事append_context是一个 ToolAI 可以在需要的时候主动调用把讨论结论、待办事项追加到共享文件。Tool 适合“写入”这种动作型操作。get_context_all是一个 Resource客户端可以在发起对话时自动加载全部上下文。这样就解决了“AI 看不到之前的讨论”的问题。search_context是一个检索 Tool避免上下文文件过大时全部塞进对话导致上下文膨胀。关于存储目录我选择放在用户主目录下的.shared-context文件夹。这样两个朋友各自跑一个 Server只要该目录通过 Git 或网盘同步读写的就是同一份数据。如果你的场景是两个人同时写一个文件建议用 Git 同步每次写入后提交拉取时解决冲突。MCP 本身不负责同步它只负责读写。启动 Serverpython server.py默认使用 stdio 传输这是 MCP 最常见的本地通信方式。启动后没有任何输出因为它是在等待客户端通过标准输入输出发送协议消息。7. 客户端接入Dify、Claude Desktop 与通用 MCP 配置写好了 Server下一步就是让 AI 客户端连上它。不同客户端的配置方式略有区别但核心都是一个 JSON 结构告诉客户端用什么命令启动这个 Server。先看通用配置。大多数 MCP 客户端支持下面的 schema{ mcpServers: { shared-context-server: { command: python, args: [/absolute/path/to/server.py] } } }关键点command必须是虚拟环境中的 Python 完整路径否则客户端可能找不到依赖。如果你使用的是.venv建议写成{ mcpServers: { shared-context-server: { command: /absolute/path/to/.venv/bin/python, args: [/absolute/path/to/server.py] } } }Windows 下对应路径可能是{ command: C:\\path\\to\\.venv\\Scripts\\python.exe, args: [C:\\path\\to\\server.py] }7.1 Claude DesktopClaude Desktop 的配置文件位于macOS~/Library/Application Support/Claude/claude_desktop_config.jsonWindows%APPDATA%\Claude\claude_desktop_config.json在配置文件中加入上述mcpServers即可。配置完成后需要完全退出 Claude Desktop 再重启MCP Server 才会被拉起。7.2 Dify 添加本地 MCP 服务Dify 的 MCP 配置入口在“工具”页面中。选择添加 MCP 工具时类型选择“stdio”命令和参数分别填入 Python 路径和脚本路径。需要注意Dify 运行在 Docker 中时无法直接访问宿主机进程。如果你在 Dify 里接入本地 MCP要确认 Dify 进程和 Python 服务在同一运行时环境。更稳妥的办法是先docker exec进入 Dify 容器确认可执行 Python 之后再配置。7.3 MCP Inspector 调试工具开发阶段最推荐使用的是 MCP Inspector它提供了一个可视化界面可以直接测试 Server 的 Tool 和 Resource。npx modelcontextprotocol/inspector python server.py运行后会打开一个 Web 页面可以查看 Server 提供的工具列表、手动调用工具也可以读取 Resource。这一步是验证 Server 是否正常的关键手段。8. 运行验证与效果测试启动 Server 后建议按下面的顺序做验证。第一步用 Inspector 确认服务已连接。打开 Inspector 页面可以看到shared-context-server点开 Tools能看到append_context和search_contextResources 里能看到shared-context://all。第二步手动调用append_context填入参数{ section: 部署讨论, content: 我们决定使用 Docker Compose 部署端口映射改为 8080:8080。 }如果返回ok, total lines: 3说明写入成功。第三步检查本地文件cat ~/.shared-context/context.md预期输出# Shared Context ## 部署讨论 我们决定使用 Docker Compose 部署端口映射改为 8080:8080。第四步在同一台机器或已经同步文件的朋友机器上启动客户端让 AI 读一下shared-context://all资源然后提问“我们当时的部署方案是什么” 如果 AI 能准确说出 Docker Compose 和端口映射说明上下文共享已经生效。这个流程验证的不只是代码而是整个链路MCP Server 的读写能力、客户端的配置、共享文件的同步能力。如果失败通常不是 MCP 协议问题而是路径、环境或文件同步出了问题。9. 常见问题与排查思路实操过程中比较容易出问题的地方集中在环境、路径、协议连接和上下文大小四个方面。问题现象可能原因排查方式解决方案客户端提示 MCP Server 启动失败command 路径错误或虚拟环境未激活直接在终端运行配置中的 command 确认可启动使用虚拟环境中 Python 的绝对路径模块找不到mcppip 安装到了全局环境客户端用的是另一个 Python在客户端配置中指定.venv/bin/python重新安装依赖确认pip list中存在 mcp调用 append_context 后文件无变化文件路径是用户主目录两个用户读取的目录不同打印SHARED_DIR实际路径统一使用一个约定路径或通过环境变量注入上下文文件过大AI 一直提示超出限制Resource 直接把全部内容注入对话查看 MCP Server 返回的字节数改用 search_context 按需检索或服务端做摘要截断两台机器数据不同步文件系统没有同步机制检查文件修改时间引入 Git 或网盘同步写入后自动提交中文乱码编码不一致检查文件编码格式统一使用encodingutf-8读写特别说明一下“上下文过大”的问题。搜索词里频繁出现“已进行多次自动总结但上下文大小仍超出限制”这种情况在共享上下文场景中很容易发生所有朋友都往同一个文件里写内容文件越来越大客户端每次对话都加载全部内容最终超出模型上下文窗口限制。解决思路不是限制朋友写入而是改变读取方式。共享文件适合作为“历史档案”但每次对话时不应该全量注入。更好的做法是只注入最近更新的摘要或让 AI 先调用search_context检索再回答。这也是我在 Server 中增加搜索工具的原因。10. 从“共享文件”到“共享 Agent 上下文”的工程建议这个最小方案跑通之后你可能会想把它用到实际项目中。此时有几个建议非常值得留意。第一权限边界。共享上下文等于把朋友的一部分工作状态开放给了 AI。写文件前想清楚什么内容可以共享什么内容需要脱敏。如果上下文包含密钥、内网地址、客户信息建议在写入前做一层过滤。第二审计意识。文件方案的最大优势是可审计。每次追加内容后通过 Git diff 就能看到谁在什么时候写入了什么。多人在同一台服务器上操作时可以加上写入者字段例如在 section 中标注作者。第三上下文结构规范。建议维护一个固定的 Markdown 规范比如## [日期] [主题] by [作者] 内容这样检索、合并、清理都方便。没有规范的共享上下文很快就会变成无法阅读的流水账。第四谨慎对待“AI 自动写入”。让 AI 自动写入共享上下文等于让 AI 修改团队知识库。一方面要设计好 Tool 描述避免模型滥用另一方面可以增加mcp.tool()内部的写入限制例如只在包含特定关键词时才允许写入。第五不要绕过安全机制。如果未来要把 MCP Server 暴露到公网必须加上认证和传输加密。最简单的方式是放在内网或使用支持鉴权的远程 MCP 运行环境不要直接让一个无鉴权的 HTTP MCP Server 暴露在公网。11. 总结与下一步方向回到最初的问题MCP 为什么值得关注因为它是目前少有的、能让 AI 上下文从“单机内存”走向“协作资源”的开放协议。本文通过“朋友之间共享上下文”这个场景完成了一个最小闭环用 Python 编写 MCP Server通过文件存储共享内容通过客户端配置接入 AI用检索工具控制上下文长度。下一步你可以继续做几个方向的升级一是给共享上下文增加加密存储避免敏感信息明文落盘二是引入数据库存储支持多人并发的行级更新和冲突解决三是把 MCP Server 部署为远程服务让不同网络环境的朋友也能访问四是结合 Webhook让文件每次更新时自动通知所有客户端刷新资源。如果你正在做 Agent 工具链或者团队协作型 AI 应用“通过 MCP 共享上下文”是一个值得具体落地的切入点。建议先把这个最小方案跑通再逐步加入权限、加密和同步机制。这样既不会陷入繁琐的架构设计又能让 AI 协作迈出关键一步。
最近 MCP 这个词在开发圈里出现频率越来越高从 Dify 本地接入 MCP Server到 WorkBuddy 通过 MCP 直接访问数据库再到 Figma MCP、支付宝 MCP 这类面向业务场景的实践几乎每一个环节都有人讨论“怎么把真实业务上下文交给 AI”。但大部分教程讲的是“如何接入一个 MCP 工具”很少有人认真讲一个问题MCP 真正改变的是什么我的判断是MCP 不只是“AI 访问外部工具”的接口标准它更是一个上下文协作协议。所有围绕它的热点本质上都是在解决同一个痛点——如何让 AI 理解真实世界的信息并让这些信息在不同人、不同 Agent 之间流转。本文从一个很有意思的 Hacker News 项目标题切入Show HN: Share context between friends via MCP。这个标题虽然很短但信息量不小。读完这篇文章你可以理解 MCP 的核心概念与适用场景并亲手实现一个“在朋友或协作者之间共享上下文”的最小 MCP Server包含完整代码、客户端配置和排错思路。1. 为什么 MCP 突然成了开发圈的公共话题先看一个现象。各大技术社区关于 MCP 的搜索词已经从最早的“MCP 是什么”“MCP Server”扩展到了非常具体的实践场景Dify 添加本地 MCP 服务Win 系统上怎么创建 MCPCodex MCP、Playwright MCPSSH MCP、Trae 集成 MCP支付宝 MCP 的使用上下文过大已进行多次自动总结但上下文大小仍超出限制。请检查 MCP 服务器或 Skill这些搜索词说明什么说明开发者已经不满足于“理解概念”而是开始把 MCP 用在真实工作流中。大家真正关心的不是协议本身多优雅而是三件事如何让 AI 助手拿到我项目里的真实数据如何让 AI 助手操作外部系统而不是只停留在聊天框如何把多个 AI 工具、多个协作者的上下文统一起来避免“各说各话”。第三点恰恰是“通过 MCP 共享上下文”这个方向的核心价值。过去我们做上下文共享手段基本是拉群、发文档、贴聊天记录信息是碎片化的、不可检索的而且很难让 AI 增量消费。MCP 提供了一条结构化路径把上下文暴露成服务端资源让多个客户端按需读取。所以这篇文章不打算再写一份“MCP 入门指南”而是直接进入一个具体场景你和朋友共同维护一个开源项目两个人都在用 AI 助手如何用 MCP 把项目状态、讨论结论、待办事项同步起来。如果你正在做 AI 应用开发、Agent 工具链落地或者只是好奇“MCP 到底能解决什么实际问题”这篇文章应该能给你一个可以直接跑通的最小方案。2. MCP 协议的核心概念从工具调用到上下文共享MCP 的全称是 Model Context Protocol由 Anthropic 在 2024 年开源。它的目标很直接统一 AI 模型与外部数据、工具之间的交互方式。理解 MCP 的关键是分清四个角色角色作用你可以把它理解成Host宿主运行 AI 模型和交互界面的应用聊天窗口、IDE 插件Client客户端与 Server 建立连接发起请求接线员Server服务端提供工具、资源、提示词工具箱 / 数据仓库数据源被 Server 封装的外部系统数据库、文件、网页、API过去一个 AI 应用想要读取本地文件需要写死一段代码想要查数据库又要单独写一套 SQL 封装。每个模型、每个 Agent 框架都要重复造轮子。MCP 的贡献是把这个过程标准化了Server 暴露统一接口Client 统一调用传输层可以是 stdio 本地进程也可以是 SSE / HTTP 远程服务。MCP Server 主要提供三类能力Tool工具由模型决定何时调用适合“执行动作”例如写入文件、发请求、执行命令。Resource资源数据由客户端按需读取适合“提供上下文”例如读取文档、项目配置、共享笔记。Prompt提示词模板客户端可以主动调用的模板帮助用户快速发起特定任务。很多人第一次接触 MCP 时最容易犯的误解是把所有东西都设计成 Tool。但如果你只是想让 AI“看到”某份上下文内容把它设计成 Resource 会更自然因为模型不需要主动调用它客户端可以在对话开始时主动注入。这也是“共享上下文”项目里最重要的设计决策上下文是作为工具被调用还是作为资源被读取答案会影响整个架构。3. 共享上下文到底在解决什么真实痛点一个人使用 AI 助手通常遇到的典型问题是什么是上下文断裂。比如你上午跟 AI 讨论了一个功能设计下午继续聊时AI 已经不记得上午的结论。你只好把聊天记录复制粘贴一遍甚至贴完还会被提示“上下文过长已经自动总结多次但仍然超出限制”。两个人使用 AI 助手问题会加倍。你和朋友都针对同一个项目聊天、写代码但彼此不知道对方和 AI 说了什么。于是常见场景变成了这样你花了一下午让 AI 整理出一份部署方案朋友晚上又问了一遍 AI得到完全不同的答案你发现一个线上问题在群里发了三条消息朋友下次启动 AI 时完全不知道两个人各自维护一份项目文档最后根本不知道哪份是最新的。传统的解决办法是共享一个 Git 仓库或一份在线文档。但文档是给“人”看的AI 不能自动消费即使能粘贴给 AI也缺少结构化入口不好检索、不好追加。用 MCP 做共享上下文本质上是把“上下文”变成一种可编程资源。它可以被多个客户端读取可以按主题追加可以被 AI 作为事实依据。相比聊天记录和文档它有两个优势上下文不是静态快照而是持续更新的服务端资源读取和写入都通过统一协议任何人用任何支持 MCP 的客户端都能访问。从这个角度看“Share context between friends via MCP”虽然听起来像玩具项目但它触及的其实是 AI 协作中最现实的问题如何让 AI 的理解保持一致。4. 方案设计一个最小可用的共享上下文架构要实现“通过 MCP 在朋友之间共享上下文”不需要一开始就上数据库、上云 Sync。最简单、最可控、也最容易审计的方案是共享文件 MCP 读写。整体架构分三层共享存储层一个 Markdown 文件放在两台机器都能访问的位置。最简单的方案是放进 Git 仓库或者用网盘同步目录。这个文件就是“共享上下文”的事实来源。MCP Server 层一个本地 Python 服务把文件封装成两个能力。append_context 用于追加内容context 资源用于读取全部内容。客户端接入层两个朋友各自的 AI 客户端通过 MCP 配置连接到同一个 Server。为什么选文件而不是数据库因为共享上下文场景的特点是写入不频繁、可读性强、需要人工审查。Markdown 文件天然适合这个场景可以直接用 Git 看 diff可以用编辑器快速修改出问题了一键回滚。数据库方案适合更大规模的团队但需要额外维护权限、连接、并发控制不适合作为第一版。这里的核心设计思路是MCP Server 不负责解决所有问题只负责把“上下文文件”的读写能力暴露出来。同步问题交给 Git权限问题尽量简化格式问题用 Markdown 的二级标题作为主题分区。5. 环境准备与项目初始化这一节开始实操。环境要求如下操作系统Windows / macOS / Linux 均可本文命令基于 Linux/macOS 习惯Windows 下注意路径分隔符区别Python 3.10 及以上版本pip 或 uv本文使用 pip一个支持 MCP 的客户端常用的有 Claude Desktop、Dify、Cline、Cherry Studio 等。首先创建项目目录并安装依赖。mkdir shared-context-mcp cd shared-context-mcp python -m venv .venv source .venv/bin/activate pip install mcp如果你使用 Windows激活虚拟环境的命令是.venv\Scripts\activatemcp是官方 Python SDK安装完以后FastMCP 模块可以直接导入。FastMCP 是 SDK 提供的简化封装好处是不用手动处理协议消息只需写装饰器函数。项目目录结构如下shared-context-mcp/ ├── server.py ├── .venv/ └── README.md这里我还建议在 README 中约定共享上下文的写作规范后面会讲到具体规范。安装完成后可以先确认版本python -c import mcp; print(mcp.__version__)这一步能尽早发现 Python 环境问题。如果提示找不到模块说明依赖没有安装到当前虚拟环境。6. 核心代码实现一个支持读写上下文的 MCP Server下面创建一个最简但功能完整的 MCP Server。代码放在server.py。# server.py import os from pathlib import Path from mcp.server.fastmcp import FastMCP SHARED_DIR Path.home() / .shared-context CONTEXT_FILE SHARED_DIR / context.md mcp FastMCP(shared-context-server) def _ensure_file(): SHARED_DIR.mkdir(parentsTrue, exist_okTrue) if not CONTEXT_FILE.exists(): CONTEXT_FILE.write_text(# Shared Context\n, encodingutf-8) def _read_all() - str: _ensure_file() return CONTEXT_FILE.read_text(encodingutf-8) mcp.tool() def append_context(section: str, content: str) - str: 向共享上下文的指定主题追加一段内容返回当前总行数。 Args: section: 主题名称例如 部署讨论 或 Bug排查 content: 要保存的内容 _ensure_file() text _read_all() if not text.endswith(\n): text \n text f\n## {section}\n{content}\n CONTEXT_FILE.write_text(text, encodingutf-8) return fok, total lines: {len(text.splitlines())} mcp.resource(shared-context://all) def get_context_all() - str: 读取完整共享上下文供客户端在对话开始时加载。 return _read_all() mcp.tool() def search_context(keyword: str) - str: 在共享上下文中按关键字搜索返回匹配的段落。 Args: keyword: 搜索关键词 text _read_all() lines text.splitlines() result [] current_section None for line in lines: if line.startswith(## ): current_section line elif keyword in line: result.append(f{current_section or 未分区}: {line}) if not result: return no match return \n.join(result) if __name__ __main__: mcp.run()这段代码做了三件事append_context是一个 ToolAI 可以在需要的时候主动调用把讨论结论、待办事项追加到共享文件。Tool 适合“写入”这种动作型操作。get_context_all是一个 Resource客户端可以在发起对话时自动加载全部上下文。这样就解决了“AI 看不到之前的讨论”的问题。search_context是一个检索 Tool避免上下文文件过大时全部塞进对话导致上下文膨胀。关于存储目录我选择放在用户主目录下的.shared-context文件夹。这样两个朋友各自跑一个 Server只要该目录通过 Git 或网盘同步读写的就是同一份数据。如果你的场景是两个人同时写一个文件建议用 Git 同步每次写入后提交拉取时解决冲突。MCP 本身不负责同步它只负责读写。启动 Serverpython server.py默认使用 stdio 传输这是 MCP 最常见的本地通信方式。启动后没有任何输出因为它是在等待客户端通过标准输入输出发送协议消息。7. 客户端接入Dify、Claude Desktop 与通用 MCP 配置写好了 Server下一步就是让 AI 客户端连上它。不同客户端的配置方式略有区别但核心都是一个 JSON 结构告诉客户端用什么命令启动这个 Server。先看通用配置。大多数 MCP 客户端支持下面的 schema{ mcpServers: { shared-context-server: { command: python, args: [/absolute/path/to/server.py] } } }关键点command必须是虚拟环境中的 Python 完整路径否则客户端可能找不到依赖。如果你使用的是.venv建议写成{ mcpServers: { shared-context-server: { command: /absolute/path/to/.venv/bin/python, args: [/absolute/path/to/server.py] } } }Windows 下对应路径可能是{ command: C:\\path\\to\\.venv\\Scripts\\python.exe, args: [C:\\path\\to\\server.py] }7.1 Claude DesktopClaude Desktop 的配置文件位于macOS~/Library/Application Support/Claude/claude_desktop_config.jsonWindows%APPDATA%\Claude\claude_desktop_config.json在配置文件中加入上述mcpServers即可。配置完成后需要完全退出 Claude Desktop 再重启MCP Server 才会被拉起。7.2 Dify 添加本地 MCP 服务Dify 的 MCP 配置入口在“工具”页面中。选择添加 MCP 工具时类型选择“stdio”命令和参数分别填入 Python 路径和脚本路径。需要注意Dify 运行在 Docker 中时无法直接访问宿主机进程。如果你在 Dify 里接入本地 MCP要确认 Dify 进程和 Python 服务在同一运行时环境。更稳妥的办法是先docker exec进入 Dify 容器确认可执行 Python 之后再配置。7.3 MCP Inspector 调试工具开发阶段最推荐使用的是 MCP Inspector它提供了一个可视化界面可以直接测试 Server 的 Tool 和 Resource。npx modelcontextprotocol/inspector python server.py运行后会打开一个 Web 页面可以查看 Server 提供的工具列表、手动调用工具也可以读取 Resource。这一步是验证 Server 是否正常的关键手段。8. 运行验证与效果测试启动 Server 后建议按下面的顺序做验证。第一步用 Inspector 确认服务已连接。打开 Inspector 页面可以看到shared-context-server点开 Tools能看到append_context和search_contextResources 里能看到shared-context://all。第二步手动调用append_context填入参数{ section: 部署讨论, content: 我们决定使用 Docker Compose 部署端口映射改为 8080:8080。 }如果返回ok, total lines: 3说明写入成功。第三步检查本地文件cat ~/.shared-context/context.md预期输出# Shared Context ## 部署讨论 我们决定使用 Docker Compose 部署端口映射改为 8080:8080。第四步在同一台机器或已经同步文件的朋友机器上启动客户端让 AI 读一下shared-context://all资源然后提问“我们当时的部署方案是什么” 如果 AI 能准确说出 Docker Compose 和端口映射说明上下文共享已经生效。这个流程验证的不只是代码而是整个链路MCP Server 的读写能力、客户端的配置、共享文件的同步能力。如果失败通常不是 MCP 协议问题而是路径、环境或文件同步出了问题。9. 常见问题与排查思路实操过程中比较容易出问题的地方集中在环境、路径、协议连接和上下文大小四个方面。问题现象可能原因排查方式解决方案客户端提示 MCP Server 启动失败command 路径错误或虚拟环境未激活直接在终端运行配置中的 command 确认可启动使用虚拟环境中 Python 的绝对路径模块找不到mcppip 安装到了全局环境客户端用的是另一个 Python在客户端配置中指定.venv/bin/python重新安装依赖确认pip list中存在 mcp调用 append_context 后文件无变化文件路径是用户主目录两个用户读取的目录不同打印SHARED_DIR实际路径统一使用一个约定路径或通过环境变量注入上下文文件过大AI 一直提示超出限制Resource 直接把全部内容注入对话查看 MCP Server 返回的字节数改用 search_context 按需检索或服务端做摘要截断两台机器数据不同步文件系统没有同步机制检查文件修改时间引入 Git 或网盘同步写入后自动提交中文乱码编码不一致检查文件编码格式统一使用encodingutf-8读写特别说明一下“上下文过大”的问题。搜索词里频繁出现“已进行多次自动总结但上下文大小仍超出限制”这种情况在共享上下文场景中很容易发生所有朋友都往同一个文件里写内容文件越来越大客户端每次对话都加载全部内容最终超出模型上下文窗口限制。解决思路不是限制朋友写入而是改变读取方式。共享文件适合作为“历史档案”但每次对话时不应该全量注入。更好的做法是只注入最近更新的摘要或让 AI 先调用search_context检索再回答。这也是我在 Server 中增加搜索工具的原因。10. 从“共享文件”到“共享 Agent 上下文”的工程建议这个最小方案跑通之后你可能会想把它用到实际项目中。此时有几个建议非常值得留意。第一权限边界。共享上下文等于把朋友的一部分工作状态开放给了 AI。写文件前想清楚什么内容可以共享什么内容需要脱敏。如果上下文包含密钥、内网地址、客户信息建议在写入前做一层过滤。第二审计意识。文件方案的最大优势是可审计。每次追加内容后通过 Git diff 就能看到谁在什么时候写入了什么。多人在同一台服务器上操作时可以加上写入者字段例如在 section 中标注作者。第三上下文结构规范。建议维护一个固定的 Markdown 规范比如## [日期] [主题] by [作者] 内容这样检索、合并、清理都方便。没有规范的共享上下文很快就会变成无法阅读的流水账。第四谨慎对待“AI 自动写入”。让 AI 自动写入共享上下文等于让 AI 修改团队知识库。一方面要设计好 Tool 描述避免模型滥用另一方面可以增加mcp.tool()内部的写入限制例如只在包含特定关键词时才允许写入。第五不要绕过安全机制。如果未来要把 MCP Server 暴露到公网必须加上认证和传输加密。最简单的方式是放在内网或使用支持鉴权的远程 MCP 运行环境不要直接让一个无鉴权的 HTTP MCP Server 暴露在公网。11. 总结与下一步方向回到最初的问题MCP 为什么值得关注因为它是目前少有的、能让 AI 上下文从“单机内存”走向“协作资源”的开放协议。本文通过“朋友之间共享上下文”这个场景完成了一个最小闭环用 Python 编写 MCP Server通过文件存储共享内容通过客户端配置接入 AI用检索工具控制上下文长度。下一步你可以继续做几个方向的升级一是给共享上下文增加加密存储避免敏感信息明文落盘二是引入数据库存储支持多人并发的行级更新和冲突解决三是把 MCP Server 部署为远程服务让不同网络环境的朋友也能访问四是结合 Webhook让文件每次更新时自动通知所有客户端刷新资源。如果你正在做 Agent 工具链或者团队协作型 AI 应用“通过 MCP 共享上下文”是一个值得具体落地的切入点。建议先把这个最小方案跑通再逐步加入权限、加密和同步机制。这样既不会陷入繁琐的架构设计又能让 AI 协作迈出关键一步。
