MCP 资源与提示resources/prompts实战不只 tools把只读上下文结构化喂给 Agent大多数团队接触 MCP是从tools开始的列目录、跑查询、调 HTTP。很快你会发现另一类痛点——每次都把同一段 README、同一份风格指南、同一张「如何写提交说明」粘进对话框。那不是缺工具是缺结构化只读上下文和可复用提问模板。MCP 把能力拆成三类常见原语具体字段名与 SDK 版本以你使用的规范/SDK 为准tools可调用动作、resources可读取的资源 URI、prompts可填充的提示模板。本文假设你已会在 Cursor 里挂上一个最小 Server见 10-02 实战重点补何时不用再造 tool而是暴露 resource / prompt。适合已经「tools 能跑」、但会话里仍在疯狂粘贴文档的个人与小团队。摘要先分类动作用 tools稳定只读材料用 resources重复话术用 prompts。URI 化把「又要粘贴的那几段」变成可 list/read 的资源。模板化把「设计评审 / 写 PR 描述」做成带参数的 prompts。权限resources 默认只读仍要防路径逃逸prompts 不要偷带密钥。验收list/read/get 调用链可复述Agent 少粘贴、多引用。结论tools 是手resources 是书架prompts 是话术卡。三件事混成「万能 tool」上下文与权限都会变脏。结论卡原语典型用途默认姿态反模式tools查询/写入/外部动作最小权限 确认用 tool 返回整本 WikiresourcesREADME/ADR/规范摘录URI 限定、只读资源根目录指向家目录prompts评审/提交/重构话术参数可审计模板里写死 Token背景与边界MCP 规范与各语言 SDK 仍在演进Cursor 客户端对 resources/prompts 的展示与自动选用行为随版本变化。本文给工程方法与示意结构不绑定某一补丁号的绝对 UI。不覆盖从零手写 Server 的 stdio 基础见既有文也不教绕过沙箱或读取未授权资源。价目与云托管能力以各厂商官方为准本文不编造。若你的客户端暂时对 prompts 支持不完整仍可先把 resources 落地——「少粘贴」这一收益单独成立。prompts 可先以仓库内 Markdown 模板 手动降级待客户端能力齐全再接到 MCP。原理三种东西不要挤进一个 tool为什么「再写一个 get_docs tool」往往是错的用 tool 返回大段静态文档会导致三类问题每次调用都像执行动作语义上吵结果进入工具历史容易在后续轮次回灌权限模型与「读材料」不符审计时分不清「读了书架」还是「动了手」。resource 的语义是这是可寻址的只读材料客户端可以列出、按需读取、引用。prompts 解决什么团队反复使用的开场白「请先列影响面再改」「请按 ADR-3 检查」——若每次手打质量取决于当天心情。prompt 模板把槽位参数化例如module、risk_level让话术可评审、可版本化也方便在 AtomGit 上开 PR 改模板而不是改口头禅。决策口诀有副作用或强实时性 →tool稳定、可缓存、只读 →resource重复任务话术 →prompt既要读又要写 → 拆开不要一个 tool 包办实战步骤步骤 1盘点「总被粘贴」的材料花 20 分钟翻最近会话与 PR 描述列出每次重构都贴的目录约定与错误码表每次 PR 都贴的描述骨架与验收清单每次联调都贴的环境说明必须先脱敏。前两类优先变 resources / prompts含密钥的说明先变成.env.example叙事再谈是否进入资源白名单。步骤 2设计资源命名空间示意 URI形式因实现而异关键是可猜、可限域、可审计docs://project/readme-quickstart docs://project/adr/003-billing-facade docs://project/style-go-errors docs://project/pr-template-short约定只映射仓库内白名单目录如docs/、README.md禁止..逃逸与手写 Server 时的safe_join同一精神大文件提供「摘要资源」「全文资源」避免默认灌入巨册名称稳定改路径要有重定向或变更说明避免旧会话书签失效。步骤 3实现 list/read 与 prompts示意下面用伪代码说明职责而非锁定某一 SDK API 名list_resources: - 返回白名单内资源的 uri、name、mimeType、简短描述 read_resource(uri): - 解析 uri → 安全路径 - 读文件或生成摘录可截断并声明截断 - 返回文本块 list_prompts: - design_review(module, goal) - pr_description(ticket, risk) - refactor_plan(scope, done_definition) get_prompt(name, args): - 校验参数 - 填充模板返回消息列表角色划分按客户端约定design_review模板示意你是设计评审员只读禁止改文件。 模块{{module}} 目标{{goal}} 请输出 1) 假设与未知问题 2) 影响面包/API/数据 3) 风险与回滚点 4) 建议下一步仅允许继续 Ask / 最小改动测试 / 停手升级 不要发明未在仓库出现的依赖。步骤 4在 Cursor 接入并验通mcp.json指向你的 Server本地 stdio 或既有配置密钥用环境变量。重启 / 重载 MCP 后确认资源与提示出现在客户端可发现列表以你的 Cursor 版本 UI 为准。新开对话明确要求 Agent先 read 指定 resource 再回答禁止「我凭训练记忆」。用 prompt 发起一次设计评审检查参数是否进入上下文、是否仍保持只读。对比实验同一任务「粘贴 200 行」vs「读 resource」观察后续轮次是否更干净。步骤 5治理与版本钉扎资源内容来自 Git变更可 diff模板变更走 PR禁止个人静默改生产模板SDK 与 Server 依赖钉版本在团队公约写明新增 resource 必须过白名单目录评审CI 增加冒烟导入 Server 模块并断言资源名集合非空。可复制最小目录与配置提示mcp-knowledge/ server.py # list/read resources prompts templates/ design_review.md pr_description.md refactor_plan.md allowlist.txt # 允许暴露的相对路径 README.md tests/test_safe_uri.pyallowlist.txt示例README.md docs/adr/ docs/style/ docs/pr-templates/Cursor 侧只保留需要时启用的 Server避免与一堆无关 tools 同时常驻。工具定义本身也是前缀税备而不用的 MCP 越多会话越贵。与 Always Rules / Docs 如何分工机制擅长不擅长Always Rules短铁律长文档glob Rules域规范跨任务厚手册Docs / 手动 人点名的文档自动化发现MCP resources可寻址材料、可被工具链统一替代 Git 评审MCP prompts标准化开场替代人的目标判断推荐组合铁律进 Always域约束进 glob厚材料进 resources 或重复话术进 prompts。不要三处各写一份互相打架的「支付规范」。验通清单list_resources可见预期 URI且无白名单外路径read_resource返回可引用文本故意../与绝对路径被拒绝list_prompts/get_prompt参数替换正确、无密钥残留Agent 能引用资源完成问答而不要求你粘贴全文文档写明 SDK 版本与「客户端若不支持 prompts 时的降级用法」冒烟测试在 CI 或本地脚本可一键跑安全与权限resources「只读」不是免责金牌路径逃逸任何 URI→路径必须经安全拼接与根目录约束。敏感文件.env、密钥、生产配置不得进 allowlist示例仓用假数据。prompts 投毒模板被恶意改写会改变 Agent 行为——模板要进 Git 评审。不要用 resource 代替鉴权能读到的材料权限面按最小需要缩小。日志Server 日志勿打印资源全文中的潜在密钥片段。内部演练勿对生产要求 Agent 读取 allowlist 外路径或「读取~/.ssh」期望失败。演练失败则停更、修safe_join、撤回已发布示例。踩坑清单症状可能原因处理资源列表为空未实现 list 或 allowlist 过严先放 README 验通读了但 Agent 仍胡编未要求先读历史记忆干扰新会话明确指令Token 更贵了默认读全文巨册改摘要资源模板无效客户端未接 prompts降级为模板文件安全误报消失白名单过宽收紧并加测试练习作业可交 AtomGit为仓库README与一篇 ADR 各建一个 resource。做一个design_reviewprompt参数含module、goal。写 allowlist 与逃逸测试并在 README 写验通步骤。对比「粘贴」与「读资源」各一次记录会话体感与是否少回灌。90 天演进建议第 1–2 周只上 3–5 个高频 resources不上几十个。第 3–4 周沉淀 2–3 个 prompts纳入代码评审。第 2 个月与 Docs 索引去重消灭双份真相。第 3 个月CI 冒烟 安全演练日常化淘汰无人问津的资源。常见问答Qresources 会不会取代 Rules不会。Rules 是约束与触发resources 是材料。约束短而常在材料长而按需。Q所有文档都要 URI 吗不必。只 URI 化「反复进入对话」的那一小撮。长尾文档继续即可。Q能否用 resource 暴露数据库表结构可以但要用开发环境导出的脱敏快照并明确只读生产连接仍走受控 tool且默认关闭。端到端示例从粘贴到引用假设你每周五都要写 PR 描述过去的做法是把「描述模板」从笔记复制进对话框再让 Agent 根据 diff 填空。改成 resources prompts 之后资源docs://project/pr-template-short存放短模板与必填字段说明提示pr_description接受ticket、risk两个参数人在 Cursor 里先取 prompt再让 Agent 只读相关 diff 与该 resource输出进 PR 正文草稿人改两句后提交。对比指标不必上复杂平台记录「是否还手粘模板」「描述漏项次数」「会话是否更短」。两周后若漏项下降就说明模板真进了工作流而不是又多了一个没人用的 MCP。资源粒度摘要、全文与切片同一份 ADR 可以暴露三个 URI…/adr/003-summary、…/adr/003-full、…/adr/003-rules-extract。默认让 Agent 读摘要需要原文再读全文若只要「可执行约束」读 extract 并与 Rules 对齐。粒度设计能显著降低「一读就灌入八千字」的事故。切片时注意不要静默截断却装作全文。返回文本头部应声明「摘要 / 全文 / 已截断到 N 字」避免模型在残篇上装懂。与手写 tools 的协作方式resources 不淘汰 tools。典型流水线是prompt 约定任务 → resource 提供规范 → tool 执行只读查询或受控写入。例如design_reviewprompt 要求先读docs://…/adr/003再用只读 git diff tool 看变更最后给出选项。写入类 tool 仍要闸门不因「读过规范」就自动放权。若发现某个 tool 的返回值长期是静态文档把它降级为 resource是本周最划算的重构之一。发布到 AtomGit 的示例仓注意点开源教学仓时只放假数据与 allowlistREADME 写明「如何申请自己的密钥并注入环境变量」提供一键冒烟脚本截图打码本机路径。不要把内网 URI 方案原样公开。示例仓的信誉来自读者能安全复现而不是功能清单最长。一周落地排期个人版周一盘点粘贴清单选出三个候选资源。周二实现 allowlist 与 list/read单测逃逸。周三接到 Cursor 做一次「禁止粘贴」的对话实验。周四沉淀一个 prompt 并找同事用同一模板各写一次评审。周五写 README 验通节与降级方案开 PR。若某一天卡住优先保住 resourcesprompts 可降级为仓库内 Markdown。节奏的意义是防止「一次做完美平台」导致两周零收益。小结MCP 进阶不是堆更多会改世界的手而是把书架与话术卡也标准化。resources 让只读上下文可寻址prompts 让高质量提问可复用。先盘点总被粘贴的东西再 URI 化与模板化权限与白名单从头写严。验通标准只有一句调用链能讲清Agent 少粘贴。草稿未发布 · 作者 梧桐秋海 · 活动九月创作之星、工具实践