资源设计指南

MCP 意义上的 Resource 不是原始数据库转储，而是可读的数据上下文—— 经过结构化、过滤，并针对当前需要它的智能体量身定制。 当 Tool 执行操作时，Resource 提供做出合理决策所需的上下文。

带有 kind="resources" 的 Resources 恰好描述了这一点：系统提供哪些 上下文对象、它们如何构建，以及它们具有什么保护级别。

有效的 AI 访问权限（Effective AI Access）

对 AI 的数据访问不能简化为单一问题。正确的模型是叠加的：

User Permission
+ Agent Permission
+ Client Trust Level
+ Resource Sensitivity
+ Purpose
+ Context
+ Confirmation State
= Effective AI Access

这些因素中的任何一个都可能限制访问——即使所有前面的因素 原则上都允许访问。

这太粗糙了。用户权限和 AI 权限是不同的维度。 用户有意识地行动，有上下文，有责任。智能体自动化运行， 没有对敏感性的判断力，在必须明确受限的范围内运行。

示例：薪资数据

高管原则上有权访问薪资数据——这是他的用户权限。 但在此用户上下文中运行的销售助理智能体不应将这些数据纳入其上下文。

原因：智能体有明确定义的目的（联系人管理、跟进、项目工作）。 薪资数据超出了这个目的。智能体权限和目的排除了访问—— 无论用户本人能看到什么。

User Permission:     ✓ （高管可以查看薪资数据）
Agent Permission:    ✗ （销售助理没有 salary:read Scope）
Resource Sensitivity: sensitive
Purpose:             联系人管理 / 项目工作
= Effective AI Access: 拒绝

脱敏与上下文过滤（Redaction & Context Filtering）

MCP-first 系统应该有针对性地为 AI 智能体准备数据，而不是简单地透传。 这意味着：并非内部存在的每个字段都应该进入智能体上下文。

完整内部数据

{
  "name": "Max Müller",
  "email": "[email protected]",
  "phone": "+49...",
  "privateNotes": "...",
  "bankAccount": "...",
  "internalRiskScore": "...",
  "lastEmails": ["..."]
}

此版本包含个人数据、银行数据、私人备注和完整邮件历史。 它适用于内部视图和拥有相应权限的用户—— 而不是一个要提出跟进建议的智能体。

智能体适用版本

{
  "name": "Max Müller",
  "company": "Müller GmbH",
  "role": "Investment Manager",
  "lastInteractionSummary": "Opened exposé but did not reply.",
  "recommendedNextAction": "Follow up by email."
}

智能体只获得其任务所需的内容：姓名、上下文、 最近互动状态和行动建议。银行数据、风险评分和 原始邮件数据已被过滤。这就是设计即脱敏（Redaction by Design）。

脱敏不是事后的安全措施，而是 Resource 设计的一部分： 每个 Resource 都有一个智能体适用的变体，只包含 特定目的所需的字段。

带上下文的 Resources

设计良好的 Resources 不仅提供原始数据，还提供嵌入的上下文： 时间线、摘要、行动建议。这些才是真正让智能体有用的 Resources。

这些 Resources 超越了 contacts.get 或 projects.list。 它们提供经过处理的上下文，使智能体能够推荐合理的下一步操作—— 而无需自行进行原始数据库查询或解析敏感字段。