信息收集

向用户请求结构化信息

信息收集（Elicitation）允许 Agent 通过客户端向用户请求结构化信息。它基于已锁定的 MCP 2026-07-28 候选发布版信息收集规范，支持两种模式：

表单模式：使用受限的 JSON Schema 收集非敏感数据。
URL 模式：为敏感或外部托管的工作流（如 OAuth）打开带外交互。

用户交互要求

客户端必须清晰标识请求信息的 Agent，尊重用户隐私，并提供明确的拒绝和取消控制。对于表单模式，客户端必须允许用户在发送前查看和修改响应。对于 URL 模式，客户端必须显示目标主机并在导航前获得同意。客户端应当展示请求的 message，以便用户理解请求的内容和原因。

检查支持

客户端在初始化期间通过 capabilities.elicitation 宣告信息收集支持。

{
  "capabilities": {
    "elicitation": {
      "form": {},
      "url": {}
    }
  }
}

能力对象具有以下语义：

省略或为 null 的顶层 elicitation 字段表示不支持信息收集。
仅当 form 明确存在且非 null 时才存在表单支持。仅当 url 明确存在且非 null 时才存在 URL 支持。
省略或为 null 的模式字段表示该模式未被宣告。
存在的能力对象可以宣告零个、一个或两个模式。{} 和 {"form":null,"url":null} 宣告无支持的模式。

这与 MCP 2026-07-28 候选发布版有意识地区分开来，后者中空的信息收集能力保留原始仅表单的含义。ACP 要求每种支持的模式明确声明。

Agent 不得请求客户端未宣告的模式。Agent 应当在所需模式不可用时提供优雅的降级方案。

创建信息收集

Agent 直接通过 ACP 连接发送 elicitation/create 请求。这适配了 MCP 2026-07-28 数据模型。ACP 还要求明确指定 mode；它不应用 MCP 的省略模式默认为表单。

作用域通过扁平化字段表示：

sessionId 用于会话作用域的请求。还可以包含 toolCallId 以关联该会话中的工具调用。
requestId 用于会话外的请求作用域交互。

Agent 必须将每个信息收集及相关状态绑定到接收的客户端连接，存在认证时还绑定到已验证的用户身份。单独的 sessionId 或未经验证的客户端身份是不够的。

表单模式

{
  "jsonrpc": "2.0",
  "id": 43,
  "method": "elicitation/create",
  "params": {
    "sessionId": "sess_abc123",
    "mode": "form",
    "message": "我应该如何对待这次重构？",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "strategy": {
          "type": "string",
          "enum": ["保守", "平衡", "激进"]
        }
      },
      "required": ["strategy"]
    }
  }
}

表单 schema 是扁平对象，其属性使用支持的原始类型和枚举 schema。客户端应当在响应前验证提交的值，Agent 应当再次验证它们。

支持 schema 默认值的客户端应当使用声明的默认值预填充表单字段。

表单模式不得用于请求授予访问权限或授权交易的秘密或凭据，如密码、API 密钥、访问或刷新令牌、私钥、恢复码或支付凭据。普通个人资料信息（如姓名、电子邮件地址或用户名）不会一概禁止。Agent 必须对敏感交互使用 URL 模式。如果客户端不支持 URL 模式，Agent 不得降级使用表单模式；必须使用其他安全流程或使操作失败。

URL 模式

{
  "jsonrpc": "2.0",
  "id": 44,
  "method": "elicitation/create",
  "params": {
    "requestId": 12,
    "mode": "url",
    "elicitationId": "github-oauth-001",
    "url": "https://agent.example.com/connect?elicitationId=github-oauth-001",
    "message": "请授权访问你的代码仓库。"
  }
}

accept 响应表示用户同意打开 URL，不表示外部交互已完成。

URL 模式不能替代授权客户端访问 Agent 的流程。Agent 不得将通过 URL 模式获取的凭据或令牌通过 ACP 发回或放入客户端或模型上下文。

响应

客户端以三种操作之一响应：

accept：用户提交或同意交互。
decline：用户明确拒绝。
cancel：用户取消交互但未做出选择。

content 字段在 accept 上可选；接收方将省略和 null 视为等同。它仅对 accept 有意义；接收方忽略 decline 和 cancel 中的它。对于接受的表单信息收集，content 应当符合所请求的 schema。对于接受的 URL 信息收集，客户端通常省略 content，因为交互发生在带外。

Agent 不得假设信息收集会成功。它们必须妥善处理 decline、cancel 和失败，安全地降级、重试或使原始操作失败。

URL 完成

与 MCP 2026-07-28 不同，ACP 保留 elicitationId 和完成通知用于其直接请求流。Agent 必须在该 Agent-客户端连接上的未完成 URL 信息收集中保持每个 elicitationId 唯一，客户端必须将其视为不透明。Agent 可以在外部交互完成后发送 elicitation/complete。它必须仅向接收原始请求的同一客户端发送该通知，并包含原始的 elicitationId。客户端必须忽略未知或已完成的 ID。

使用客户端未宣告的模式产生的请求会产生 JSON-RPC -32602（无效参数）错误。

URL 安全

实现 URL 模式的 Agent 和客户端必须遵循以下要求。这些要求将 MCP 的安全 URL 处理规则适配到 ACP。

Agent 不得将凭据、个人数据或预认证访问放入 URL，并应当在开发环境外使用 HTTPS。
Agent 不应当在任何表单模式请求的字段中包含可点击的 URL。
客户端不得在未获得用户明确同意的情况下预获取 URL 或打开它。它们必须在征求同意前显示完整 URL。
客户端必须在安全上下文中打开 URL，防止客户端或 Agent 的语言模型检查页面或用户输入。
客户端应当高亮域名并对可疑或歧义 URL（包括 Punycode 域名）发出警告。
客户端不应当在任何信息收集字段中将 URL 渲染为可点击，除非是 URL 模式请求的 url 字段，且受上述限制约束。
Agent 必须验证启动信息收集的认证用户就是完成外部交互的同一用户。

查看 schema 参考获取完整的请求和响应类型。