把 MCP 理解为“给 AI 插上 USB 接口”其实只说对了一半。最近 Hacker News 上出现了一个有意思的项目标题很简洁“Share context between friends via MCP”。它的重点不是让 AI 多一个工具而是让人与人之间可以直接共享上下文。MCP 在这里变成了一条通道两端分别是两个人AI 只是中间帮忙理解、传递和维持上下文的角色。这个视角切换看似很小但它真正触及的是一个问题在 AI 协作时代我们到底应该把上下文当作什么很多人聊 MCP 时默认它是“工具接入协议”“模型能力扩展协议”讨论集中在 Server、Client、工具调用、资源暴露这些工程细节上。但“朋友之间共享上下文”这个场景把问题从“AI 能访问什么”推到了“人愿意共享什么”。这就不只是接口设计的事而是协作边界、权限粒度、记忆持久化和信任模型的事。顺着这个项目往深处看你会发现 MCP 真正的长期价值可能不是让 AI 学会调用一万个工具而是让上下文本身变成一种可打包、可传递、可共享的资源。1. 先别急着把它当成“朋友的 MCP”这个项目真正在改的是上下文的使用方式MCP 全称是 Model Context Protocol也就是模型上下文协议。简单说它定义了一套标准化方式让 AI 应用能够访问外部数据源、工具和上下文。过去几年里我们看到大量围绕 MCP 的实践蓝湖 MCP 把设计稿接入 AIFigma MCP 让 AI 读取设计文件Playwright MCP 让 AI 操作浏览器SSH MCP 让 AI 连接远程服务器甚至 IDA MCP、MATLAB MCP、支付宝 MCP 这种垂直场景的接入也在快速出现。这些实践有一个共同的叙事AI 是中心工具是外设MCP 是连接它们的总线。但“Share context between friends via MCP”这个项目把叙事倒过来了。如果按这个项目的思路去理解MCP 不一定非要连接“AI 与工具”它也可以连接“人与人的上下文”。比如你和朋友共同研究一个开源项目你希望对方能直接获得你当前的项目背景、你已经梳理过的技术决策、甚至你给 AI 设定的约束条件。传统方式是把文档发给对方让对方再手动导入不同的 AI 应用。而 MCP 的方式是你把自己的上下文封装成一个端点朋友只要在自己的 AI 客户端里接上这个端点就能读取你整理好的那部分上下文。这背后的关键变化是上下文不再局限于单个 AI 会话也不局限在某个模型供应商的服务器上而是变成了一种可以在人与人之间流动的资源。过去我们说“上下文工程”默认上下文是用户和模型之间的窗口拼接现在如果上下文可以通过 MCP 在两个人之间共享那么上下文工程就多了一层语义谁拥有上下文谁控制访问谁来决定它过期。1.1 MCP 的三种能力恰好匹配了“共享上下文”的三种需求MCP 协议定义了三种核心能力资源Resources、工具Tools、提示词Prompts。资源解决的是“AI 可以读什么”。在共享上下文的场景里它对应的是你愿意暴露给朋友的背景资料、技术文档、项目现状、研究笔记。工具解决的是“AI 可以操作什么”。对应到朋友之间可能是对方可以通过你的服务器发起某个动作比如读取某个目录、运行某个查询。提示词解决的是“AI 应该以什么方式处理”。它可以把“进入这段上下文时应该先看什么”“默认尽量使用中文”这类约束固化下来。所以这个项目看起来很轻但它实际上同时利用了 MCP 的三层能力。它没有发明一套新的协议而是把协议里本来就设计好的能力用在了人与人的协作场景上。从这个角度看它不只是一个新项目更像是对现有 MCP 协议的一次场景迁移。1.2 为什么这种迁移是有价值的有一个被反复验证过的规律任何技术如果只解决单机场景价值会受限一旦它能解决多用户协作价值就会大幅放大。MCP 刚兴起时大家关心的是“我的 AI 能不能访问我的数据库”。MCP 成熟一点之后自然会有人问“我的 AI 能不能访问我们团队的数据库”。而“Your AI can access our database as a resource”这个想法一旦把它做成可授权的、可追踪的、可撤销的就变成了新一代协作基础设施的雏形。这个项目正是站在这个边界上。它没有说“我要做一个 SQL 数据库共享工具”也没有说“我要做一个团队知识库接入 AI 的连接器”它说的是“朋友之间共享上下文”。这看起来格局不大但恰恰是很多人日常协作的最小闭环。如果最小闭环能被这个协议标准化那扩展到团队、部门、开源社区只是时间和工程能力的问题。2. 为什么“上下文”才是 AI 协作时代真正值得共享的资源我们得先想清楚一个问题两个人合作时最难的往往不是工具共享而是“背景同步”。假设你和一个朋友一起研究一个 AI Agent 项目。你花了两周时间摸清了框架的调用机制总结了十几个容易踩坑的地方还调整了提示词模板让输出更稳定。现在朋友接手你给他什么一份 README几个聊天记录截图还是你每次重启会话都要重新粘贴的背景说明这些都是传统协作方式里常见的解法但它们都有问题。README 会过时截图没有上下文关联背景说明存在你自己的对话历史里朋友看不到。真正有价值的是你大脑里那个经过实践筛选过的上下文——哪些决策是重要的哪些路径是死路哪些提示词在什么情况下有效。这些东西很难通过文档完全转移因为它在你的对话历史里、你的实验日志里、你的调试记录里。“通过 MCP 分享上下文”这个思路试图把这种无形的东西显性化。你可以把一段上下文打包成一个 MCP 端点这个端点可以提供当前项目的状态摘要、关键约束、推荐做法、以及一批预设提示词。朋友接入之后他的 AI 客户端就能自动读取这些内容相当于把你在两周里积累的判断力快速复制了一份给他的 AI。2.1 上下文不只是“信息块”它包含约束和偏好这里要说明白一点上下文不是简单地等于“堆叠的文字”。在实际的 AI 应用里上下文包含几个层次事实层项目使用了什么框架数据库结构是什么接口怎么定义。约束层不要改核心模块代码风格要统一超时时间不能超过 30 秒。过程层先跑测试再提交遇到 API 错误先查日志不要一上来就问 AI。偏好层代码注释用中文输出尽量结构化默认使用某一种提示词模板。共享上下文的难点在于这四层信息往往混在一起。你直接给对方一份文档他很难判断哪些是硬性约束哪些只是参考信息但通过 MCP 的结构化设计可以把资源、工具、提示词分别暴露让接收方按顺序理解先读资源再调用工具最后按提示词处理。这比微信发文件、发聊天记录截图要系统得多。因为 MCP 的端点在语义上划分了“读”和“用”两个动作——对方可以读取你分享的项目背景也可以在授权范围内调用你暴露的工具。这样一来共享的不是一个静止的文件而是一个仍然在生长的上下文入口。2.2 上下文共享的粒度控制是第一个要跨过去的坎但也要泼一盆冷水。现实协作中朋友这种关系比较微妙你愿意共享一部分上下文但一定不是全部。你可能会愿意分享“项目当前进展”但不愿意分享“你本地的所有环境变量”愿意分享“技术决策记录”但不愿意分享“聊天记录里的吐槽”。所以“共享上下文”这个动作天然需要一个权限层。这个权限层在传统 MCP 里往往没有被突出强调因为大多数 MCP 使用场景是“你想让 AI 读取你的数据库”权限边界是“你”自己设置风险更多是“你有没有授权过度”。但在朋友共享场景里权限边界不再是“一个人在自己的系统里授权”而是“一个人向另一个人开放”信任模型完全不同。从项目角度看一个合格的“朋友间共享上下文”实现必须回答至少四个问题对方是谁身份认证怎么做不能只要知道 URL 就能连。能读什么哪些资源可见哪些资源隐藏。能不能操作工具调用是否开放开放到什么级别。怎么撤销共享关系结束后如何让对方的访问立刻失效。这四个问题如果有一个没解决这个项目就只能停留在“能跑通演示”而不是“能真实使用”。这也是判断一个 MCP 共享类项目成熟度的核心检查清单。3. 从演示到真实使用最麻烦的不是功能而是边界控制我注意到一个普遍现象很多人看到“Show HN”项目会兴奋觉得有新工具可以用。但 Show HN 的价值更多是“验证一个方向”而不是“提供一个生产级产品”。所以聊这个项目重点不该是“它功能完了没有”而是“如果按这个方向做哪些点是深坑”。3.1 第一个深坑上下文是活的不是快照如果你只是把一份 Markdown 文档通过 MCP 暴露给朋友那不算真正的上下文共享那只是文档共享。真正的上下文是有状态的它是两个人对同一件事的持续理解。这意味着共享的端点需要支持增量更新、过期机制、事件通知。举个例子你和朋友共享一个项目上下文。今天项目跑了新测试发现了新问题你更新了上下文。朋友那边什么时候能看到如果他每次都要“重连”才能获取最新状态体验会非常割裂。更合理的做法是MCP 端点像一个 Git 仓库既可以“拉取”最新快照也可以订阅变化。但 MCP 协议本身并不强制要求这种实时性它仍然是一个请求-响应模型。所以工程上要做有心设计比如引入版本号、变更日志、过期标记。3.2 第二个深坑上下文大小和隐私是矛盾体上下文越大AI 处理效果越好但暴露的风险也越高。朋友这个场景里你通常只想分享一小部分上下文比如“这周研究的重点”和“下一步想解决的问题”而不想分享你自己的历史对话、测试脚本、API 密钥。但实际情况是上下文往往很难精准切割。你为了说明一个问题可能需要附带一段日志为了解释一个决定可能需要引用一段代码。如果共享机制不提供细粒度的选择就会出现两种极端要么你只能分享整个上下文目录太危险要么你分享太少朋友看不明白。因此一个好的“共享上下文”项目应该提供一个“选择性导出”机制允许用户在共享前挑出哪些资源对外可见哪些提示词对外暴露。这个机制听起来简单但实现起来需要清晰的路径规划和权限模型。3.3 第三个深坑安全不只是“不泄露”还要“不被利用”在普通的个人 MCP 使用中你把自己的资料库接入 AI风险主要来自误操作比如模型读到了不该读的文件。但在“分享给朋友”的场景里风险变成了对方可能拿到一个更大的攻击面如果共享端点还能调用工具对方可能通过你的 MCP 服务器执行一些你没有预期的操作。这个风险不能靠“我信任我的朋友”来解决。因为攻击不一定来自朋友本人可能来自朋友电脑上的恶意软件也可能来自朋友的 AI 客户端被注入的提示。所以工程上需要额外小心所有工具调用都必须二次授权。共享端点默认只读只有明确开启才允许写操作。敏感字段必须做脱敏处理不能让模型“下意识”通过共享上下文读取。这里要给一个实用建议如果你在搭建类似项目最低限度也要把“分享上下文”和“分享工具操作权”分开。把资源共享做成默认开启把工具调用做成默认关闭。共享上下文可以只读这个设计会让安全性提高一个数量级。3.4 从单次共享到批量使用还要补四件工程化能力如果这个项目要长期使用只解决“能连上”远远不够。按工程经验至少还需要补四块拼图。会话历史一方更新上下文后另一方能否看到变更历史这决定了共享关系是否可回溯。版本控制上下文是演进的最好有版本概念。如果改坏了能从旧版本切回来。监控审计谁能追溯“朋友在什么时间读取了什么资源”没有审计的共享关系是不可维护的。生命周期管理共享关系过期后会怎样是自动断开还是保留只读快照这些都需要明确的策略。这四块拼图任何一个缺失都会在真实协作中形成隐性成本。单次共享可以靠手动操作绕过长期协作根本绕不过去。4. 顺着这个方向想MCP 未来的扩展不止“工具接口”这一条路目前大多数人对 MCP 的认知是“工具接口协议”。但“Share context between friends via MCP”这类项目出现后MCP 的可能性被拉开了一条新线它也可以是一种“上下文交换协议”。这条线如果继续往前走会怎样4.1 从“AI 读取你的环境”到“AI 共享你的判断”过去两年“上下文工程”成为一个热词。做法是把有用的背景、约束、偏好写进提示词让模型理解任务。但上下文工程的痛点一直存在上下文越多构造越麻烦上下文放在提示词里每次传输都消耗 token上下文长期堆积后哪些有效、哪些已经过时很难自动判断。如果把“上下文”做成一个可通过 MCP 共享的资源情况会不一样。你可以把一个领域专家积累的上下文打包成端点让新手团队直接接入。这相当于把“上下文工程”的成果从个人经验里抽离出来变成组织资产。这个价值比单纯“让 AI 多调用一个工具”要大得多因为工具解决的是当下的操作上下文解决的是一段时间内的理解。4.2 从“朋友之间”到“团队之间”边界从信任驱动变成规则驱动“朋友之间共享上下文”的起步形态可以不需要太强的权限体系因为信任是默认的。但一旦这个模式扩展到团队或社区信任模型就必须被规则模型替代。这时候MCP 端点上需要额外的元数据谁创建的、谁更新过、谁在使用、使用频率如何、有效期多久。这也意味着 MCP 协议本身可能在未来需要扩展出更多协作语义。比如资源上可以标记“createdBy”“reviewedBy”“expiresAt”工具调用可以有“quota”“rateLimit”提示词可以加“visibility”。当前 MCP 规范更偏“连接”还没有内建这些“协作治理”概念。所以这类项目如果走得远可能反过来推动 MCP 协议本身的演进。4.3 但不要高估短期变革MCP 生态还处于“能跑但不够稳”的阶段虽然有这么多可能性我还是想提醒一句MCP 生态现在还处在早期。常见问题包括不同客户端对 MCP 的支持程度不一致。很多 MCP Server 是社区维护稳定性和文档质量参差不齐。MCP 的调试工具、日志机制、权限管理还没有统一标准。部分客户端对动态资源、流式更新的支持还不够好。所以“朋友之间共享上下文”这个方向更像是一个先导实验。它在告诉你MCP 的叙事可以不局限于“模型 工具”而是可以演进成“人 人 模型 上下文”的协作协议。但这个演进需要生态持续的工程投入不是某一个 Show HN 项目能独立完成的。5. 如果你想复现或自己做一个类似的共享机制从哪里开始说了这么多最终还是要落到“怎么做”上。如果你看完这个项目也想去试试类似的做法这里有一个比较现实的路径。5.1 第一步设计最小可用的“上下文包”首先要明确你想和对方共享的是什么建议从“一个目录 一个提示词模板 一个只读资源”开始。比如一个目录/shared-context/project-brief.md一个提示词BUILD_NOTE_zh.md里面写清楚 AI 在读取这个共享上下文时应该优先关注哪些点。一个只读工具list_files让朋友查看共享目录中有哪些文件。先不要做数据库接入、SSH 共享、复杂权限体系。最小可用闭环是朋友能在自己的 AI 客户端里看到你共享的目录和说明并能让 AI 围绕这些内容给出有效回答。5.2 第二步选一个你熟悉的 MCP Server 框架如果你会 TypeScript可以选择官方的 TypeScript SDK如果会 Python则用 Python SDK。关键不是选哪个语言而是要跑通三条链路资源路径能不能被远程客户端访问。提示词模板能不能被加载。工具列表能不能被列出并调用。在这个阶段不要先急着部署到公网。先在本地跑通用 MCP Inspector 或类似的调试工具验证路径。5.3 第三步把“认证”和“授权”从第一天就放进去这是最容易踩的坑。很多新手做 MCP Server习惯把权限问题留到后面结果一暴露出去就出事。更稳妥的做法是在第一天就至少加一个最简单的 Token 认证。用 HTTP header 传 API TokenServer 端校验通过后才返回资源。别追求 OAuth 或 SSO用 Token 先挡住“无意暴露”的风险。权限可以分三层公开资源不需要登录即可读取适合不敏感的信息。朋友资源需要 Token适合协作内容。私有资源默认不暴露必须显式授权。把资源都按这个规则过一遍再开始写业务逻辑。5.4 第四步加上变更记录和过期策略共享上下文不是一次性操作要设计成可持续更新。建议在目录里维护一个CHANGELOG.md每次更新都记录。同时在SERVER.md里说明上下文的更新频次和有效期限。如果上下文在 30 天内没有更新可以视为过期在资源里明确标注“最后更新日期”。这能避免朋友误以为旧上下文仍然是最新状态。5.5 常见故障排查路径如果你把类似思路放到自己的环境里遇到问题可以按这个顺序排查先看客户端能否发现 Server检查 URL、端口、健康检查端点。再看认证是否通过检查 Token 是否过期、header 是否正确。再看资源路径确认资源路径在本地能被读取远程访问时的路径映射是否正确。再看权限配置如果你能看到资源但 AI 看不到大概率是 Server 端权限过滤问题。最后看提示词模板如果 AI 的回答风格不对检查模板是否真的被加载而不是被缓存了旧版本。这个顺序基本能覆盖 80% 的“能连上但用不好”问题。这个方向值得关注但不值得急着下结论说到底“Share context between friends via MCP”这个项目最有价值的地方不是它做出了什么复杂的系统而是用很小的切口展示了一种新的可能上下文可以不只属于单个会话不只是存在于某个模型供应商的服务器上它可以被整理、被分享、被持续更新成为人与人协作的中介。当然它现在还只是一个方向而不是一个成熟答案。安全模型、协作语义、协议扩展、客户端兼容这些工程问题都不会自动消失。但反过来说如果这些问题真的被逐步解决那我们讨论 AI 协作时关注点就会从“AI 能用哪些工具”转向“AI 能共享哪些上下文”。到那个时候MCP 的真正意义才会完全显影——它不是给 AI 提供更多外设而是让理解和判断可以像接口一样连接起来。如果你手头正好有一个需要长期协作的项目不妨试试这个思路把最重要的背景整理成一段可持续更新的上下文让你的朋友通过 MCP 接入而不是每次从头说起。这个过程也许粗糙但它会让你提前感受到当上下文可以共享时协作的起点会低得多。 MCP不只是工具接口：如何让上下文在人与人之间共享
把 MCP 理解为“给 AI 插上 USB 接口”其实只说对了一半。最近 Hacker News 上出现了一个有意思的项目标题很简洁“Share context between friends via MCP”。它的重点不是让 AI 多一个工具而是让人与人之间可以直接共享上下文。MCP 在这里变成了一条通道两端分别是两个人AI 只是中间帮忙理解、传递和维持上下文的角色。这个视角切换看似很小但它真正触及的是一个问题在 AI 协作时代我们到底应该把上下文当作什么很多人聊 MCP 时默认它是“工具接入协议”“模型能力扩展协议”讨论集中在 Server、Client、工具调用、资源暴露这些工程细节上。但“朋友之间共享上下文”这个场景把问题从“AI 能访问什么”推到了“人愿意共享什么”。这就不只是接口设计的事而是协作边界、权限粒度、记忆持久化和信任模型的事。顺着这个项目往深处看你会发现 MCP 真正的长期价值可能不是让 AI 学会调用一万个工具而是让上下文本身变成一种可打包、可传递、可共享的资源。1. 先别急着把它当成“朋友的 MCP”这个项目真正在改的是上下文的使用方式MCP 全称是 Model Context Protocol也就是模型上下文协议。简单说它定义了一套标准化方式让 AI 应用能够访问外部数据源、工具和上下文。过去几年里我们看到大量围绕 MCP 的实践蓝湖 MCP 把设计稿接入 AIFigma MCP 让 AI 读取设计文件Playwright MCP 让 AI 操作浏览器SSH MCP 让 AI 连接远程服务器甚至 IDA MCP、MATLAB MCP、支付宝 MCP 这种垂直场景的接入也在快速出现。这些实践有一个共同的叙事AI 是中心工具是外设MCP 是连接它们的总线。但“Share context between friends via MCP”这个项目把叙事倒过来了。如果按这个项目的思路去理解MCP 不一定非要连接“AI 与工具”它也可以连接“人与人的上下文”。比如你和朋友共同研究一个开源项目你希望对方能直接获得你当前的项目背景、你已经梳理过的技术决策、甚至你给 AI 设定的约束条件。传统方式是把文档发给对方让对方再手动导入不同的 AI 应用。而 MCP 的方式是你把自己的上下文封装成一个端点朋友只要在自己的 AI 客户端里接上这个端点就能读取你整理好的那部分上下文。这背后的关键变化是上下文不再局限于单个 AI 会话也不局限在某个模型供应商的服务器上而是变成了一种可以在人与人之间流动的资源。过去我们说“上下文工程”默认上下文是用户和模型之间的窗口拼接现在如果上下文可以通过 MCP 在两个人之间共享那么上下文工程就多了一层语义谁拥有上下文谁控制访问谁来决定它过期。1.1 MCP 的三种能力恰好匹配了“共享上下文”的三种需求MCP 协议定义了三种核心能力资源Resources、工具Tools、提示词Prompts。资源解决的是“AI 可以读什么”。在共享上下文的场景里它对应的是你愿意暴露给朋友的背景资料、技术文档、项目现状、研究笔记。工具解决的是“AI 可以操作什么”。对应到朋友之间可能是对方可以通过你的服务器发起某个动作比如读取某个目录、运行某个查询。提示词解决的是“AI 应该以什么方式处理”。它可以把“进入这段上下文时应该先看什么”“默认尽量使用中文”这类约束固化下来。所以这个项目看起来很轻但它实际上同时利用了 MCP 的三层能力。它没有发明一套新的协议而是把协议里本来就设计好的能力用在了人与人的协作场景上。从这个角度看它不只是一个新项目更像是对现有 MCP 协议的一次场景迁移。1.2 为什么这种迁移是有价值的有一个被反复验证过的规律任何技术如果只解决单机场景价值会受限一旦它能解决多用户协作价值就会大幅放大。MCP 刚兴起时大家关心的是“我的 AI 能不能访问我的数据库”。MCP 成熟一点之后自然会有人问“我的 AI 能不能访问我们团队的数据库”。而“Your AI can access our database as a resource”这个想法一旦把它做成可授权的、可追踪的、可撤销的就变成了新一代协作基础设施的雏形。这个项目正是站在这个边界上。它没有说“我要做一个 SQL 数据库共享工具”也没有说“我要做一个团队知识库接入 AI 的连接器”它说的是“朋友之间共享上下文”。这看起来格局不大但恰恰是很多人日常协作的最小闭环。如果最小闭环能被这个协议标准化那扩展到团队、部门、开源社区只是时间和工程能力的问题。2. 为什么“上下文”才是 AI 协作时代真正值得共享的资源我们得先想清楚一个问题两个人合作时最难的往往不是工具共享而是“背景同步”。假设你和一个朋友一起研究一个 AI Agent 项目。你花了两周时间摸清了框架的调用机制总结了十几个容易踩坑的地方还调整了提示词模板让输出更稳定。现在朋友接手你给他什么一份 README几个聊天记录截图还是你每次重启会话都要重新粘贴的背景说明这些都是传统协作方式里常见的解法但它们都有问题。README 会过时截图没有上下文关联背景说明存在你自己的对话历史里朋友看不到。真正有价值的是你大脑里那个经过实践筛选过的上下文——哪些决策是重要的哪些路径是死路哪些提示词在什么情况下有效。这些东西很难通过文档完全转移因为它在你的对话历史里、你的实验日志里、你的调试记录里。“通过 MCP 分享上下文”这个思路试图把这种无形的东西显性化。你可以把一段上下文打包成一个 MCP 端点这个端点可以提供当前项目的状态摘要、关键约束、推荐做法、以及一批预设提示词。朋友接入之后他的 AI 客户端就能自动读取这些内容相当于把你在两周里积累的判断力快速复制了一份给他的 AI。2.1 上下文不只是“信息块”它包含约束和偏好这里要说明白一点上下文不是简单地等于“堆叠的文字”。在实际的 AI 应用里上下文包含几个层次事实层项目使用了什么框架数据库结构是什么接口怎么定义。约束层不要改核心模块代码风格要统一超时时间不能超过 30 秒。过程层先跑测试再提交遇到 API 错误先查日志不要一上来就问 AI。偏好层代码注释用中文输出尽量结构化默认使用某一种提示词模板。共享上下文的难点在于这四层信息往往混在一起。你直接给对方一份文档他很难判断哪些是硬性约束哪些只是参考信息但通过 MCP 的结构化设计可以把资源、工具、提示词分别暴露让接收方按顺序理解先读资源再调用工具最后按提示词处理。这比微信发文件、发聊天记录截图要系统得多。因为 MCP 的端点在语义上划分了“读”和“用”两个动作——对方可以读取你分享的项目背景也可以在授权范围内调用你暴露的工具。这样一来共享的不是一个静止的文件而是一个仍然在生长的上下文入口。2.2 上下文共享的粒度控制是第一个要跨过去的坎但也要泼一盆冷水。现实协作中朋友这种关系比较微妙你愿意共享一部分上下文但一定不是全部。你可能会愿意分享“项目当前进展”但不愿意分享“你本地的所有环境变量”愿意分享“技术决策记录”但不愿意分享“聊天记录里的吐槽”。所以“共享上下文”这个动作天然需要一个权限层。这个权限层在传统 MCP 里往往没有被突出强调因为大多数 MCP 使用场景是“你想让 AI 读取你的数据库”权限边界是“你”自己设置风险更多是“你有没有授权过度”。但在朋友共享场景里权限边界不再是“一个人在自己的系统里授权”而是“一个人向另一个人开放”信任模型完全不同。从项目角度看一个合格的“朋友间共享上下文”实现必须回答至少四个问题对方是谁身份认证怎么做不能只要知道 URL 就能连。能读什么哪些资源可见哪些资源隐藏。能不能操作工具调用是否开放开放到什么级别。怎么撤销共享关系结束后如何让对方的访问立刻失效。这四个问题如果有一个没解决这个项目就只能停留在“能跑通演示”而不是“能真实使用”。这也是判断一个 MCP 共享类项目成熟度的核心检查清单。3. 从演示到真实使用最麻烦的不是功能而是边界控制我注意到一个普遍现象很多人看到“Show HN”项目会兴奋觉得有新工具可以用。但 Show HN 的价值更多是“验证一个方向”而不是“提供一个生产级产品”。所以聊这个项目重点不该是“它功能完了没有”而是“如果按这个方向做哪些点是深坑”。3.1 第一个深坑上下文是活的不是快照如果你只是把一份 Markdown 文档通过 MCP 暴露给朋友那不算真正的上下文共享那只是文档共享。真正的上下文是有状态的它是两个人对同一件事的持续理解。这意味着共享的端点需要支持增量更新、过期机制、事件通知。举个例子你和朋友共享一个项目上下文。今天项目跑了新测试发现了新问题你更新了上下文。朋友那边什么时候能看到如果他每次都要“重连”才能获取最新状态体验会非常割裂。更合理的做法是MCP 端点像一个 Git 仓库既可以“拉取”最新快照也可以订阅变化。但 MCP 协议本身并不强制要求这种实时性它仍然是一个请求-响应模型。所以工程上要做有心设计比如引入版本号、变更日志、过期标记。3.2 第二个深坑上下文大小和隐私是矛盾体上下文越大AI 处理效果越好但暴露的风险也越高。朋友这个场景里你通常只想分享一小部分上下文比如“这周研究的重点”和“下一步想解决的问题”而不想分享你自己的历史对话、测试脚本、API 密钥。但实际情况是上下文往往很难精准切割。你为了说明一个问题可能需要附带一段日志为了解释一个决定可能需要引用一段代码。如果共享机制不提供细粒度的选择就会出现两种极端要么你只能分享整个上下文目录太危险要么你分享太少朋友看不明白。因此一个好的“共享上下文”项目应该提供一个“选择性导出”机制允许用户在共享前挑出哪些资源对外可见哪些提示词对外暴露。这个机制听起来简单但实现起来需要清晰的路径规划和权限模型。3.3 第三个深坑安全不只是“不泄露”还要“不被利用”在普通的个人 MCP 使用中你把自己的资料库接入 AI风险主要来自误操作比如模型读到了不该读的文件。但在“分享给朋友”的场景里风险变成了对方可能拿到一个更大的攻击面如果共享端点还能调用工具对方可能通过你的 MCP 服务器执行一些你没有预期的操作。这个风险不能靠“我信任我的朋友”来解决。因为攻击不一定来自朋友本人可能来自朋友电脑上的恶意软件也可能来自朋友的 AI 客户端被注入的提示。所以工程上需要额外小心所有工具调用都必须二次授权。共享端点默认只读只有明确开启才允许写操作。敏感字段必须做脱敏处理不能让模型“下意识”通过共享上下文读取。这里要给一个实用建议如果你在搭建类似项目最低限度也要把“分享上下文”和“分享工具操作权”分开。把资源共享做成默认开启把工具调用做成默认关闭。共享上下文可以只读这个设计会让安全性提高一个数量级。3.4 从单次共享到批量使用还要补四件工程化能力如果这个项目要长期使用只解决“能连上”远远不够。按工程经验至少还需要补四块拼图。会话历史一方更新上下文后另一方能否看到变更历史这决定了共享关系是否可回溯。版本控制上下文是演进的最好有版本概念。如果改坏了能从旧版本切回来。监控审计谁能追溯“朋友在什么时间读取了什么资源”没有审计的共享关系是不可维护的。生命周期管理共享关系过期后会怎样是自动断开还是保留只读快照这些都需要明确的策略。这四块拼图任何一个缺失都会在真实协作中形成隐性成本。单次共享可以靠手动操作绕过长期协作根本绕不过去。4. 顺着这个方向想MCP 未来的扩展不止“工具接口”这一条路目前大多数人对 MCP 的认知是“工具接口协议”。但“Share context between friends via MCP”这类项目出现后MCP 的可能性被拉开了一条新线它也可以是一种“上下文交换协议”。这条线如果继续往前走会怎样4.1 从“AI 读取你的环境”到“AI 共享你的判断”过去两年“上下文工程”成为一个热词。做法是把有用的背景、约束、偏好写进提示词让模型理解任务。但上下文工程的痛点一直存在上下文越多构造越麻烦上下文放在提示词里每次传输都消耗 token上下文长期堆积后哪些有效、哪些已经过时很难自动判断。如果把“上下文”做成一个可通过 MCP 共享的资源情况会不一样。你可以把一个领域专家积累的上下文打包成端点让新手团队直接接入。这相当于把“上下文工程”的成果从个人经验里抽离出来变成组织资产。这个价值比单纯“让 AI 多调用一个工具”要大得多因为工具解决的是当下的操作上下文解决的是一段时间内的理解。4.2 从“朋友之间”到“团队之间”边界从信任驱动变成规则驱动“朋友之间共享上下文”的起步形态可以不需要太强的权限体系因为信任是默认的。但一旦这个模式扩展到团队或社区信任模型就必须被规则模型替代。这时候MCP 端点上需要额外的元数据谁创建的、谁更新过、谁在使用、使用频率如何、有效期多久。这也意味着 MCP 协议本身可能在未来需要扩展出更多协作语义。比如资源上可以标记“createdBy”“reviewedBy”“expiresAt”工具调用可以有“quota”“rateLimit”提示词可以加“visibility”。当前 MCP 规范更偏“连接”还没有内建这些“协作治理”概念。所以这类项目如果走得远可能反过来推动 MCP 协议本身的演进。4.3 但不要高估短期变革MCP 生态还处于“能跑但不够稳”的阶段虽然有这么多可能性我还是想提醒一句MCP 生态现在还处在早期。常见问题包括不同客户端对 MCP 的支持程度不一致。很多 MCP Server 是社区维护稳定性和文档质量参差不齐。MCP 的调试工具、日志机制、权限管理还没有统一标准。部分客户端对动态资源、流式更新的支持还不够好。所以“朋友之间共享上下文”这个方向更像是一个先导实验。它在告诉你MCP 的叙事可以不局限于“模型 工具”而是可以演进成“人 人 模型 上下文”的协作协议。但这个演进需要生态持续的工程投入不是某一个 Show HN 项目能独立完成的。5. 如果你想复现或自己做一个类似的共享机制从哪里开始说了这么多最终还是要落到“怎么做”上。如果你看完这个项目也想去试试类似的做法这里有一个比较现实的路径。5.1 第一步设计最小可用的“上下文包”首先要明确你想和对方共享的是什么建议从“一个目录 一个提示词模板 一个只读资源”开始。比如一个目录/shared-context/project-brief.md一个提示词BUILD_NOTE_zh.md里面写清楚 AI 在读取这个共享上下文时应该优先关注哪些点。一个只读工具list_files让朋友查看共享目录中有哪些文件。先不要做数据库接入、SSH 共享、复杂权限体系。最小可用闭环是朋友能在自己的 AI 客户端里看到你共享的目录和说明并能让 AI 围绕这些内容给出有效回答。5.2 第二步选一个你熟悉的 MCP Server 框架如果你会 TypeScript可以选择官方的 TypeScript SDK如果会 Python则用 Python SDK。关键不是选哪个语言而是要跑通三条链路资源路径能不能被远程客户端访问。提示词模板能不能被加载。工具列表能不能被列出并调用。在这个阶段不要先急着部署到公网。先在本地跑通用 MCP Inspector 或类似的调试工具验证路径。5.3 第三步把“认证”和“授权”从第一天就放进去这是最容易踩的坑。很多新手做 MCP Server习惯把权限问题留到后面结果一暴露出去就出事。更稳妥的做法是在第一天就至少加一个最简单的 Token 认证。用 HTTP header 传 API TokenServer 端校验通过后才返回资源。别追求 OAuth 或 SSO用 Token 先挡住“无意暴露”的风险。权限可以分三层公开资源不需要登录即可读取适合不敏感的信息。朋友资源需要 Token适合协作内容。私有资源默认不暴露必须显式授权。把资源都按这个规则过一遍再开始写业务逻辑。5.4 第四步加上变更记录和过期策略共享上下文不是一次性操作要设计成可持续更新。建议在目录里维护一个CHANGELOG.md每次更新都记录。同时在SERVER.md里说明上下文的更新频次和有效期限。如果上下文在 30 天内没有更新可以视为过期在资源里明确标注“最后更新日期”。这能避免朋友误以为旧上下文仍然是最新状态。5.5 常见故障排查路径如果你把类似思路放到自己的环境里遇到问题可以按这个顺序排查先看客户端能否发现 Server检查 URL、端口、健康检查端点。再看认证是否通过检查 Token 是否过期、header 是否正确。再看资源路径确认资源路径在本地能被读取远程访问时的路径映射是否正确。再看权限配置如果你能看到资源但 AI 看不到大概率是 Server 端权限过滤问题。最后看提示词模板如果 AI 的回答风格不对检查模板是否真的被加载而不是被缓存了旧版本。这个顺序基本能覆盖 80% 的“能连上但用不好”问题。这个方向值得关注但不值得急着下结论说到底“Share context between friends via MCP”这个项目最有价值的地方不是它做出了什么复杂的系统而是用很小的切口展示了一种新的可能上下文可以不只属于单个会话不只是存在于某个模型供应商的服务器上它可以被整理、被分享、被持续更新成为人与人协作的中介。当然它现在还只是一个方向而不是一个成熟答案。安全模型、协作语义、协议扩展、客户端兼容这些工程问题都不会自动消失。但反过来说如果这些问题真的被逐步解决那我们讨论 AI 协作时关注点就会从“AI 能用哪些工具”转向“AI 能共享哪些上下文”。到那个时候MCP 的真正意义才会完全显影——它不是给 AI 提供更多外设而是让理解和判断可以像接口一样连接起来。如果你手头正好有一个需要长期协作的项目不妨试试这个思路把最重要的背景整理成一段可持续更新的上下文让你的朋友通过 MCP 接入而不是每次从头说起。这个过程也许粗糙但它会让你提前感受到当上下文可以共享时协作的起点会低得多。