Agent 协议、身份与可观测性：从“能连上”到“可委托、可验证、可演进”

研究基线：2026-08-03。本文只使用官方规范、标准、发布记录与 Kimi Code 公开源码作为事实依据；对尚在 Draft / Development 的内容显式标注，不把路线图当成已稳定事实。状态快照：MCP 2026-07-28 是正式 stable release；A2A 最新稳定规范是 1.0.1、wire version 为 1.0；ACP 稳定 wire protocol 是 v1、v2 仍为 Draft；LSP 官网标明最新版本为 3.18；OpenTelemetry GenAI conventions 仍是 Development；Agent-specific identity/authorization 方案尚未收敛为正式 RFC 或 NIST 标准。

0. 先把结论讲清楚

Coding Agent 的协议栈不是一个“大一统 Agent Protocol”，而是六种不同关系的叠加：

1. MCP：Agent host 怎样发现和调用外部工具、资源与提示模板；
2. A2A：一个独立 Agent 系统怎样把长任务委托给另一个 Agent 系统；
3. ACP：IDE / client 怎样驱动一个 coding agent，并呈现 session、进展、tool call、diff 与权限；
4. LSP：编辑器或 Agent 怎样从 language server 获得精确代码语义；
5. Skills / Hooks / Plugins：如何注入程序性知识、确定性生命周期逻辑和可分发扩展包；
6. OpenTelemetry：跨上述边界怎样保留因果关系、成本、失败与评测证据。

它们解决的不是同一个问题。最危险的错误是因为它们都使用 JSON、RPC、session、capability 等词，就假定它们的状态、取消、授权和错误语义可以互换。

真正稳定的系统边界是：

communication ≠ state ownership ≠ authority ≠ trust ≠ correctness

• 协议连通只证明双方能交换合规消息；
• capability declaration 只证明对方声称支持某能力；
• authentication 只证明当前调用者控制某身份凭证；
• authorization 只证明策略允许某个 action；
• effect receipt 才证明某个副作用被提交；
• verifier evidence 才支持“任务完成”的判断。

协议层设计的最高原则因此不是“统一所有接口”，而是：

让每种关系只拥有它必须拥有的状态；让身份、权限、取消、重试和证据在跨边界时保持显式、衰减和可追踪。

1. 总体分层：每种机制到底位于哪一层

1.1 关系与所有权

1.2 Protocol、schema、SDK、product contract 不是一回事

面试中必须区分四层：

Protocol spec       定义 wire 语义与互操作最低要求
Schema              定义消息形状，不自动定义状态机和副作用
SDK                 某版本对规范的实现，可能滞后、超前或带兼容行为
Product contract    产品真正承诺的恢复、权限、验证、隐私与 UX

常见误判：

• “SDK 升级成功”不等于协议迁移完成；隐藏 session state、retry 和 cache 责任可能仍未重画。
• “JSON Schema 验证通过”不等于 tool call 安全；schema 不知道 workspace trust、tenant、资源敏感度与效果。
• “Agent Card 可签名”不等于远端 Agent 值得信任；签名证明 card 完整性和签名者，不证明能力真实性或输出正确性。
• “traceparent 已传播”不等于请求已获授权；trace context 是观测数据，不是 security principal。

2. 核心协议对比矩阵

2.1 选择协议的最小判断树

3. MCP 2026-07-28：从 connection session 转向 request-oriented core

官方 2026-07-28 规范的关键变化见 MCP Key Changes。GitHub 的 2026-07-28 Release明确标记它为 stable release，发布于 2026-07-28；5 月的 2026-07-28-RC 是另一个 pre-release，不能把搜索索引中的 RC 状态套到最终 tag 上。

同时必须区分 spec stability 与 SDK adoption：正式规范已经稳定，不代表每个 SDK、server 和 client 已默认启用。官方 TypeScript SDK v2 当前仍要求显式配置 versionNegotiation 才发送 2026-era wire；默认路径继续说 2025-era protocol。生产迁移必须 feature-detect、双栈验证，不能因 final spec 已发布就假定生态同步完成。

3.1 MCP 解决什么，不解决什么

MCP 标准化三类 capability：

• Tools：有输入 schema、可被调用、可能产生副作用；
• Resources：以 URI 标识、可列出/读取的数据；
• Prompts：server 暴露的 prompt template。

MCP 不负责：

• Agent 如何分解任务、何时调用工具；
• workspace 是否可信；
• 某个 tool 是否应被当前用户批准；
• tool effect 是否与用户目标一致；
• “工具返回成功”是否等于任务完成；
• 多工具结果怎样进入 model context；
• 失败是否该重试、切模型、回滚或求助。

因此 MCP server 不应直接拥有 Agent session。它可以拥有应用业务状态，但状态必须通过普通参数中的显式 handle 暴露。

3.2 对象模型

Host
  └─ MCP client adapter
      ├─ server/discover -> versions + server capabilities + identity
      ├─ tools/list      -> deterministic tools + schemas + ttl/scope
      ├─ tools/call      -> result | input_required | task handle
      ├─ resources/list/read
      ├─ prompts/list/get
      └─ subscriptions/listen -> opted-in list/resource changes

协议对象与产品对象必须有 adapter：

MCP tool schema
  -> validate / normalize
  -> Internal ToolContract
     {name, input, effect, idempotency, timeout, sensitivity, policy, output budget}
  -> Model-facing definition
  -> Executor
  -> Evidence / receipt

直接把 MCP tool schema 原样塞给模型并直接执行，是把协议输入错误地提升成内部 authority。

3.3 2025 → 2026 的结构性变化

这次迁移的本质不是“删几个方法”，而是：

连接只负责传输；request 自描述；业务状态显式；长寿命变化流与单请求响应分离。

3.4 Transport：stdio 与 Streamable HTTP

stdio

stdio 适合 host 启动本地 server 子进程：

• 进程生命周期可由 host 明确拥有；
• stdout 必须只承载协议帧，日志走 stderr；
• 本地凭证通常来自环境或宿主，不套用 HTTP OAuth flow；
• transport drop 的证据是 EOF、exit code、signal 和 stderr tail；
• 新 client 可先发 server/discover，若对方返回 method-not-found，再进入 legacy handshake adapter。

Streamable HTTP

2026 request 的关键属性：

• MCP-Protocol-Version 指明协议日期版本；
• Mcp-Method / Mcp-Name 让 gateway 无需解析 body 即可路由和限流；
• header 与 JSON-RPC body 不一致必须失败，防止 gateway 与 application 对请求语义看法不同；
• response 可以是单一 JSON，也可以是该 request 的 SSE stream；
• server-wide change 走独立 subscriptions/listen；
• 中断一个 2026 Streamable HTTP request 的自然信号是关闭该 request 的响应流，而不是另发一个可能路由到别处的 cancellation POST。

官方 TypeScript SDK 的 2026-07-28 support guide明确区分：2026 Streamable HTTP 用 per-request stream close；stdio 和旧协议仍使用 notifications/cancelled。

3.5 Discovery、version 与 capability negotiation

现代 client 的选择逻辑：

必须区分：

• protocol version：决定 wire 语义；
• client/server implementation version：用于诊断，不能代替 feature detection；
• capability snapshot：本次 request 可用能力；
• tool catalog version/hash：模型看到的工具集合；
• tool schema version：某工具参数和结果契约；
• extension version：独立于 core 演进。

以官方 TypeScript SDK v2 为例，Client.connect() 默认仍走 legacy initialize；只有 versionNegotiation.mode = "auto" 或 pin 2026-07-28 才探测/选择 modern era。这是 implementation default，不改变 2026-07-28 已是 stable specification 的事实。

错误策略：

• 不支持 protocol version：显式 UnsupportedProtocolVersionError；
• 缺少 required capability：在 adapter 层转为 typed compatibility error；
• extension 不认识：若 optional 则降级，若 required 则拒绝；
• 不允许按 serverInfo.version 字符串猜功能；
• 自动 fallback 必须记录 requested → negotiated → degraded features，不能静默丢能力。

3.6 Schema：结构合法不等于语义安全

2026 tool schema 使用完整 JSON Schema 2020-12：

• input root 仍要求 object；
• 支持 oneOf / anyOf / allOf、conditionals、$defs / $ref；
• output schema 可为任意 JSON 类型；
• structuredContent 可为任意 JSON value；
• 不应自动解析外部 $ref；
• host 必须限制 schema depth、composition explosion、validation time 和总字节数。

四层验证不可缺：

1. Wire validation：消息是不是合规 JSON-RPC / MCP；
2. Schema validation：参数形状是否满足 tool schema；
3. Policy validation：主体、资源、effect、路径和 tenant 是否被允许；
4. Postcondition validation：执行结果和副作用是否满足任务不变量。

valid JSON("delete", path="/")
≠ valid product action
≠ authorized effect
≠ verified outcome

3.7 Stateless core 与显式应用状态

协议 stateless 不等于应用 stateless。正确模式：

create_browser() -> { browser_id: "b_123" }
navigate(browser_id="b_123", url=...)
close_browser(browser_id="b_123")

handle contract 至少包含：

• issuer/server identity；
• resource type；
• tenant / subject binding；
• expiry / revocation；
• concurrency semantics；
• transferability：能否交给 subagent 或 remote Agent；
• cleanup semantics；
• observability correlation；
• 是否带 authority，还是仅是 opaque locator。

不要把 handle 当 bearer capability，除非系统明确这样设计。大多数情况下，server 仍应同时验证 caller identity 与 resource authorization。

3.8 MRTR 与 Tasks extension

MRTR 适合一次工具工作流中需要额外输入：server 返回 resultType: "input_required"、inputRequests 与 requestState；client 收集输入后带 inputResponses 重发逻辑请求。

关键所有权：

• requestState 是 server workflow continuation，不是 Agent session；
• host 必须把 elicitation / approval / resource request 映射到自己的 Interaction Service；
• 用户回答不是自动授权；回答内容和 authority decision 必须分开；
• requestState 必须完整性保护、限制大小、绑定 server/version/subject 并可过期；
• 重发时是新 request ID，因此 effect 层必须做 reconciliation。

长任务不是 2026 core 的普通 session，而是官方 io.modelcontextprotocol/tasks extension：server 可返回 task handle，client 使用 tasks/get、tasks/update、tasks/cancel。不要用 MRTR 模拟任意长任务，也不要用 Tasks 取代 A2A：MCP Task 仍是 capability server 的工作句柄；A2A Task 是 Agent 间协作的核心交付对象。

3.9 Streaming、subscription、cancel 与 retry

三种流不要混：

副作用工具的 retry 判定：

safe automatic retry
  = transport failure
  ∧ no committed receipt observed
  ∧ operation idempotent OR server honors idempotency key
  ∧ authority still valid
  ∧ budget permits

否则必须 reconcile：查询资源状态、effect receipt 或 task handle，不能因“没收到响应”推断“没执行”。

3.10 Cache 与 deterministic ordering

tools/list 等结果的 ttlMs 与 cacheScope 解决“多久可认为新鲜”和“能否跨用户共享”，但不等于 HTTP cache 全部语义。Host cache key 至少是：

(server identity, protocol version, subject/tenant, capability set,
 extension set, auth scope, catalog request params)

目录进入 model context 前还应生成：

• canonical schema hash；
• deterministic order；
• enabled/disabled policy projection；
• model-facing name mapping；
• prompt prefix cache key；
• provenance 和 freshness evidence。

catalog 变化时必须让当前 Agent step 看见一致快照。一次模型 request 中不能前半段使用旧 tool definitions、执行时却悄悄路由到新 schema。

3.11 Authorization 与 confused deputy

MCP 2026 HTTP authorization 是 MCP 定义的 authorization profile，组合了 OAuth 2.1 IETF Draft 与 RFC 6750、8414、8707、9207、9728 等正式规范。不能把“实现 MCP authorization profile”表述成“OAuth 2.1 已成为 RFC”。该 profile 要求：

• protected resource metadata；
• authorization server discovery；
• PKCE 等 public-client 防护；
• RFC 8707 resource 指定目标 MCP server；
• access token audience 必须绑定目标 server；
• token 只放 Authorization header，不能放 query；
• issuer credential 分区，authorization server 变化时不能复用旧 client registration；
• runtime scope challenge 和有限次数 step-up。

详见 MCP Authorization。

典型 confused deputy：

控制措施：

• token audience 绑定到精确 resource URI；
• server 不接受、不转发不属于自己的 token；
• 下游调用用 token exchange / downscoped token，不透传用户 bearer token；
• tool policy 不只匹配 tool name，还匹配 effect、resource、tenant 和参数；
• 审批生成 narrow authorization decision，不把自然语言“可以”当长期 grant；
• 高风险 effect 需要 receipt 与 verifier。

3.12 MCP 实现的 deep module

理想 host 只暴露一个深接口：

interface CapabilityConnector {
  discover(signal: AbortSignal): Promise<CapabilitySnapshot>;
  invoke(intent: ToolIntent, signal: AbortSignal): Promise<ToolObservation>;
  reconcile(effectId: string): Promise<EffectState>;
  subscribe(topics: readonly Topic[]): AsyncIterable<CatalogChange>;
  close(): Promise<void>;
}

版本、transport、legacy handshake、OAuth、MRTR、subscription、schema normalization 和 trace propagation 都封在 adapter 内；Agent loop 只看到稳定的 ToolIntent → ToolObservation，避免 MCP 迁移污染执行循环。

4. A2A 1.0.x：跨 Agent 委托的是 Task，不是 prompt

A2A 1.0.0 于 2026-03-12 发布；最新 stable GitHub Release 1.0.1 发布于 2026-05-28，其 release-notes 标题中的规范版本日期是 2026-05-26。当前 wire version 是 1.0，patch 版本不参与协议兼容判断，因此 wire 中写 1.0 而不是 1.0.1。依据：A2A 1.0 Specification、A2A Releases、A2A v1.0.1 Release。

4.1 核心对象与边界

Messages 用于交流，Artifacts 用于交付。把最终结果只塞进 transient status message 会在 stream 断开后丢失关键事实；规范也明确不保证所有 status message 被持久化。

4.2 Task 状态机

真实实现应额外明确：

• 每个状态是否 durable；
• status update 与 artifact chunk 的 sequence/order；
• duplicate send message 的幂等键；
• cancellation accepted 与 effect actually stopped 的差异；
• retention / purge 后 TaskNotFound 的可诊断性；
• Task 终态后 webhook 重试的收敛；
• input/auth required 的 deadline 和 abandon policy。

4.3 Discovery 与 interface selection

Agent Card 可来自：

• /.well-known/agent-card.json；
• curated registry；
• direct configuration。

Card 中 supportedInterfaces 按偏好排序，声明 URL、protocol binding 与 protocol version。Client 选择第一个自己支持的 interface。这里更像“声明 + 选择”，不是连接中动态协商；选择前要完成：

1. 来源信任和 HTTPS endpoint 校验；
2. card signature / issuer policy；
3. auth scheme 是否能满足；
4. media type、stream/push、extension 能力是否满足任务；
5. tenant / data residency / cost / policy 检查。

签名只证明“这张 Card 是某 key 对这份 canonical JSON 的签名”，不证明 endpoint 当前运行同一实现，也不证明 skill 成功率。

4.4 Version 与 binding

A2A 1.0 将 application protocol 与 JSON-RPC、gRPC、HTTP+JSON bindings 分开。不同 binding 必须保持功能、错误和 auth 语义一致。

Wire version 使用 Major.Minor：

• Client 每 request 发送 A2A-Version: 1.0；
• Server 必须按请求版本处理；不支持则返回 VersionNotSupportedError；
• patch release 如 1.0.1 不改变协议兼容；
• 需要最新 feature 的 client 不应静默 fallback，避免能力无声消失；
• 一个 server 可在相同或不同 URL 暴露多个 version/binding。

Adapter 的测试重点不是“序列化相同”，而是跨 binding 的 semantic equivalence：取消、认证错误、artifact ordering、stream 终态、pagination 和 retry 必须一致。

4.5 Streaming、push 与 disconnected execution

三种消费模式：

• blocking send：等到终态或 input/auth required；
• non-blocking send：立即返回 Task，client 后续 poll/subscribe/push；
• streaming send：先 Task 或 Message，随后 status/artifact events，终态关闭。

Push webhook 不是“可靠 exactly-once channel”：

• server 至少尝试交付，通常 exponential backoff；
• receiver 必须去重、验证签名/凭证、限制 body 和处理乱序；
• webhook URL 必须防 SSRF、DNS rebinding、私网探测；
• 每个配置使用 single-purpose token；
• delivery receipt 不等于 client 已持久化或验证 artifact。

4.6 Cancel 与 effect

Cancel Task 表达“请求远端取消 Task”，不自动保证所有下游 effect 被回滚。需要区分：

cancel requested
→ remote accepted
→ new work stopped
→ in-flight tool interrupted
→ committed effects reconciled
→ compensation completed

协议终态 CANCELED 最多说明 remote Agent 的 task state；调用方仍需检查 artifacts、effect receipts 和外部资源状态。

4.7 A2A 的 trust gap

A2A 解决 communication interoperability，不解决 trust composition：

Agent Card says "can fix repository"
≠ has permission to repository
≠ will not exfiltrate code
≠ can satisfy acceptance tests
≠ artifact is safe to merge

远程委托必须附带：

• narrow task goal 与 acceptance criteria；
• task-scoped, audience-bound, expiring authority；
• data classification 和 allowed egress；
• artifact schema、provenance 和 integrity；
• cost/time/step budget；
• independent verifier；
• revocation/cancel/reconcile contract。

4.8 In-task authorization 的正确理解

TASK_STATE_AUTH_REQUIRED 只表示 Task 缺少额外授权。它本身不授权任何 action；规范不定义 credential 的 scope、表示、有效期和撤销。

正确流程：

规范建议 credential 尽量通过安全的 out-of-band channel 直接交给发起请求的 Agent，避免凭证在多 Agent 链中逐跳暴露。

5. ACP：IDE 与 coding agent 的 UX/runtime 边界

截至 2026-08-03，ACP 稳定 wire protocol 是 v1。官方 2026-07-21 release 同时发布了 Rust crate v1.6.0、v1 schema artifact v1.20.0，以及标为 pre-release 的 v2 schema v2.0.0-alpha.2；crate/schema artifact 版本都不能用来推断 wire compatibility。ACP v2 于 2026-07-20 发布首个 Draft，官方明确要求同时保留 v1、用 version negotiation 与 feature flags 隔离，不应默认投产。依据：ACP repository versioning、ACP releases、ACP v2 Draft announcement。

5.1 ACP 的核心所有权

ACP 是 point-to-point client ↔ agent protocol：

• Client 拥有 editor UI、用户输入、permission presentation，以及可选择暴露的 filesystem/terminal；
• Agent 拥有 session runtime、模型 context、tool orchestration 和 session persistence；
• ACP 传递 presentation-ready updates，但不是 Agent 的 durable journal；
• 一个 connection 可承载多个 concurrent sessions；
• v1 不解决多个 clients 同时观察/修改一个 session 的一致性。

5.2 v1 生命周期

v1 baseline 与 optional 能力：

• baseline：initialize、session/new、session/prompt、session/cancel、session/update、permission；
• optional：session/load、session/resume、session list/delete/close、config options、auth logout；
• client reverse-RPC：fs/read_text_file、fs/write_text_file、terminal/*、elicitation；
• stable transport 以 newline-delimited JSON-RPC over stdio 为主，stdout 不能出现 banner/log；
• _meta 承载 extension 与 traceparent / tracestate / baggage；自定义 method 以 _ 开头。

5.3 Session load、resume 与 replay

不要把三个操作混成“恢复”：

ACP replay 是 UI 同步机制，不应直接用 transcript 重建 Agent 内部 state。内部恢复应基于 journal/checkpoint；ACP adapter 把恢复后的 domain state 投影为 updates。

5.4 Tool call 与 permission

ACP tool call update 的主要作用是让 client 展示：

• intent/title/kind；
• status 与进展；
• locations、diff、terminal output；
• permission options；
• success/failure/cancelled 结果。

Permission 的边界：

• Client 是用户交互 gate，不一定是最终 policy engine；
• Agent 发出的 permission request 不能决定它自己是否有权；
• approval 必须绑定具体 subject、session、tool/effect、resource、arguments hash、expiry；
• UI 允许“本次/本 session/永久”时，持久 grant 的 scope 必须显式；
• permission response 不应把 secret 注入 model transcript；
• client fs/terminal capability 是“可调用”而非“默认授权”。

5.5 两种 cancellation

ACP v1 现有两个不同机制：

• session/cancel：语义化取消当前 session/prompt work；是 notification，需由 agent 收敛到 stop reason；
• $/cancel_request：2026-06 已进入稳定 v1 文档的通用 JSON-RPC request cancellation，按 request ID 请求取消任意 outstanding request；但它明确是 optional / best effort，接收方可因运行时限制忽略 $/ notification。支持方可返回 partial result 或 -32800。

取消 prompt 时，Agent 还要取消它向 Client 发出的 pending reverse-RPC，例如 terminal/permission；仅停止 model stream 会留下悬空 UI 和进程。

5.6 ACP v2 Draft 为什么出现

v1 默认心智是 user prompt 启动一个 turn，prompt response 结束 turn。长时间后台工作、steering、queue 和多观察者使该模型变窄。v2 Draft 的核心变化：

• session updates 可在 prompt request 生命周期之外发生；
• prompt response 更像“消息已接收”，不再拥有全部 work lifecycle；
• Agent 可显式表示 idle / ready for input；
• message、tool call、terminal output 使用 stable ID + patch semantics；
• diff 表达 add/delete/modify/move/copy/binary；
• permission 有自己的 title/description/subject，不再硬绑 tool call；
• enum-like value 允许 _ 前缀扩展，改善 forward compatibility。

这反映一个更深趋势：

Coding Agent 的 client protocol 正从 turn-oriented UI stream，演进为 session-oriented replicated presentation state。

但 v2 仍是 Draft。正确演进方式是双栈 adapter、feature gate、golden transcript/replay tests，而不是让 v2 patch model 侵入内部 journal。

5.7 ACP 典型失败

6. LSP 3.18：代码语义基础设施，不是 Agent 协议

官方当前页面标明最新 LSP 版本为 3.18：Language Server Protocol、3.18 Specification。该仓库没有单独的 GitHub Release artifact；版本判断应以微软的规范首页与 3.18 页面为准，而不是把“无 release tag”误判成 3.18 未发布。

6.1 LSP 提供什么

• symbols、definition、references、implementation；
• diagnostics、code action、completion、hover；
• rename、format、workspace edit；
• semantic tokens、inlay hints、call hierarchy；
• document/workspace synchronization；
• work-done progress 与 partial results。

这些是比全文 grep 更精确的结构证据，但它们仍可能 stale、incomplete 或受 build config 影响。

6.2 状态与 capability model

initialize(root/workspace, clientCapabilities)
  -> serverCapabilities
initialized
  -> didOpen(version=1)
  -> didChange(version=2)
  -> definition/references/diagnostic...
  -> workspace/applyEdit(version-aware)
shutdown -> exit

LSP 没有类似 MCP 2026 每 request 的 protocol-version metadata。互操作依赖规范版本与 granular capabilities；server 还可 dynamic register/unregister 某些能力。

Coding Agent 应记录：

• language server implementation/version；
• workspace/config/build target；
• document URI 与 version；
• request method、latency、result count；
• stale/timeout/restart；
• Agent 最终是否采纳该证据。

6.3 LSP 与 Agent retrieval 的组合

不应向模型暴露整个 LSP surface。Host 可形成深工具：

find_symbol_evidence(query, scope, budget)
  -> lexical + LSP + AST/graph
  -> ranked locations + confidence + source version

这样把 server-specific capability、重启、partial result 和 document sync 封装在 retrieval module 内。

6.4 Cancel、progress 与 edit 安全

• $/cancelRequest 是 best effort；server 可能已完成并返回结果，client 必须容忍 race；
• $/progress 与 work-done token 只表达进展，不是 durable task；
• partial result 需要去重与终态判定；
• WorkspaceEdit、rename、code action 可能修改文件，必须经过 Agent 自己的 effect/policy 层；
• 对未保存 editor buffer，client 的 document version 是 authority；磁盘内容可能不是用户看到的内容；
• apply edit 必须检查 version，冲突时重新读取/重新规划，不能盲覆盖。

6.5 LSP 典型失败

• server 尚未完成 indexing，返回空结果被误判为“不存在”；
• compile flags / monorepo target 不对，diagnostic 为假；
• symlink / generated code / virtual document URI 映射错误；
• didChange 丢包，client/server document version 分叉；
• rename edit 跨越 workspace trust 边界；
• Agent 把 diagnostic 当 verifier，而 diagnostic 只覆盖静态规则；
• server restart 后 dynamic registrations 与 cache 未失效。

7. Skills、Hooks、Plugins：扩展生态不是协议的附属名词

7.1 三者本体

7.2 Skill 设计

Skill catalog 至少需要：

• stable name + description + trigger guidance；
• scope：builtin / org / user / project / session；
• precedence 与 collision policy；
• version / content hash / provenance；
• required tools / environment / permissions；
• argument schema；
• model-invocable 与 user-only 标志；
• nesting/recursion budget；
• test cases 和 stale/invalidation policy。

Skill 是“模型可读取的程序性知识”，不是 deterministic workflow engine。即使 Skill 写着“必须运行测试”，模型仍可能遗漏；强制 postcondition 应由 loop/verifier/hook 实现。

7.3 Hook 设计

Hook 必须定义：

(event, phase, matcher, input schema, timeout,
 ordering/concurrency, output schema, fail policy, audit policy)

不同用途的 fail policy：

• telemetry/notification hook：通常 fail-open；
• formatting/advisory hook：可 fail-open，但错误应可见；
• security/admission hook：若它是唯一 gate 必须 fail-closed；更理想是权限系统本身拥有 gate，hook 仅 defense-in-depth；
• post-effect audit hook：失败不能假装 action 未发生，必须记录 unknown/audit-incomplete。

并行 hooks 还需定义 decision aggregation：deny overrides allow、timeout 如何处理、输出怎样合并、相同 command 是否去重。

7.4 Plugin 设计

Plugin manifest 是 capability request，不是 capability grant：

manifest declares
  skills + hooks + MCP servers + prompt + agents + commands
        ↓
installer verifies provenance / integrity / compatibility
        ↓
host computes effective capability set
        ↓
user/org policy grants a subset
        ↓
session receives immutable snapshot

必须治理：

• source provenance、签名、hash、publisher trust；
• transitive dependencies 与 MCP server binary；
• install scope 与 runtime scope；
• update channel、pinning、rollback、revocation；
• enable/disable 后何时对 live session 生效；
• prompt budget 和 collision；
• secret access、network egress、filesystem scope；
• plugin 贡献的 hook 是否可阻断、是否 fail-open；
• unload 时怎样清理 child processes、subscriptions、credentials。

7.5 Scope 与 precedence

一个可解释的 precedence 公式：

effective extension
  = trusted(scope)
  ∩ compatible(protocol/runtime)
  ∩ enabled(user/org)
  ∩ allowed(policy)
  ∩ available(environment)

“更靠近 repo 的配置优先”只适用于已经信任 repo。未信任 workspace 中的 Skill、Hook、MCP command 或 Plugin manifest 不能因 scope 更具体就自动获得执行权。

7.6 Extension 观测字段

每次 Skill/Hook/Plugin 生效至少记录：

• id、version、content hash、publisher/source；
• resolution scope 与 shadowed candidates；
• trust decision / policy branch；
• loaded/invoked/blocked/failed/timeout；
• context bytes / prompt tokens；
• tools/capabilities contributed；
• update availability 与 session snapshot version；
• hook duration、exit code、decision；
• 不记录 secret、完整源码或未脱敏 prompt。

8. Identity、Delegation 与 Authority：协议栈真正缺失的控制面

NIST/NCCoE 于 2026-02-05 发布的文件是 Initial Public Draft concept paper，公开评论已于 2026-04-02 截止，项目状态为 Reviewing Comments。它把 identification、authentication、authorization、delegation、auditing、non-repudiation 与 data provenance 列为 Agent 身份体系的核心问题，但不是已完成的 Agent identity 标准。依据：NIST CSRC publication status、NCCoE project status。

截至本研究日，也没有一个 Agent-specific identity / delegation profile 已成为正式 IETF RFC。AAP、AIP、DAAP、AI-Agent Auth 等仍是多个相互竞争的 individual Internet-Drafts；IETF Datatracker 明确提示 individual I-D 可由任何人提交、不代表 IETF 背书、没有正式标准地位。它们可以用于跟踪设计方向，不能被写成“行业已采用的 Agent 身份标准”。生产基线仍应组合正式 OAuth/JWT、Token Exchange、resource indicators、PoP、workload identity 与组织 policy。代表性状态证据：AAP Datatracker。

8.1 一次 Agent action 至少有六种身份

只传 user_id 会丢失 actor；只传 agent_id 会丢失 authority origin；只传 API key 会把 authentication、authorization 和 delegation 全压扁成 bearer possession。

8.2 Authority tuple

下面的 authority tuple 是本文用于架构推理的 内部设计模型，不是 IETF/NIST 注册 token schema。把 authority 表达为：

Authority = {
  subject,          // rights owner
  actor,            // current agent/workload
  audience,         // intended service
  resource,         // concrete resource/tenant/path
  operations,       // allowed actions/effects
  constraints,      // amount, branch, network, data class, time
  issued_at, expiry, revocation,
  delegation_chain,
  intent_or_approval_ref,
  proof_binding
}

授权判定不是 scope.contains("write")，而是：

allow(action)
  = authenticated(actor)
  ∧ audience_matches(target)
  ∧ resource_matches(action.resource)
  ∧ operation_allowed(action.effect)
  ∧ constraints_hold(current_state)
  ∧ delegation_valid_and_monotonic
  ∧ approval/intention binding valid
  ∧ not_expired_or_revoked

8.3 Delegation 与 impersonation

RFC 8693 OAuth Token Exchange区分：

• impersonation：A 在某权限上下文中被视为 B；接收方可能看不到 A；
• delegation：A 保留自己的 actor identity，同时代表 B 行动。

Agent 系统应优先保留 delegation 语义：subject=user、actor=agent。RFC 8693 的 subject_token、actor_token 与 JWT act 可表达当前 actor 和 delegation history；但 RFC 明确不规定具体部署 trust model，仍需组织 profile。

Delegation 必须单调衰减：

authority(child)
  ⊆ authority(parent)
  ∩ task requirements
  ∩ child trust policy

任何一跳都不能通过“新建 Agent”获得更多 scope、更长 expiry、更广 audience 或更弱约束。

8.4 Proof-of-possession

Bearer token 的问题是“拿到的人就能用”。RFC 9449 DPoP把 OAuth token 绑定到 client key；每次请求提交包含 method、URI、时间、唯一 ID、access-token hash 等的签名 proof，可降低 token 泄漏后的重放。

DPoP 能证明：

• 当前 presenter 控制绑定的 private key；
• proof 绑定特定 HTTP request；
• access token 与 key 相匹配。

DPoP 不能证明：

• 模型的 action 符合用户意图；
• Agent 没被 prompt injection 劫持；
• tool output 正确；
• 当前 runtime binary 没被替换；
• effect 应被执行。

因此 PoP 是 token-theft control，不是 Agent alignment 或 policy verifier。Workload identity 还可用 mTLS/SPIFFE 等机制；关键是 private key 不进入 model context，签名在独立 credential broker 中完成。

8.5 Least privilege 的四个维度

仅按 tool name 许可不够：同一个 bash 可读目录也可上传密钥；同一个 github tool 可读 issue 也可 merge PR。Policy 必须消费 normalized ToolIntent 的 effect summary 和 resource set。

8.6 Confused deputy 防线

1. 每个 token 绑定明确 audience/resource；RFC 8707解释了 resource indicator 与 audience restriction；
2. 下游调用执行 token exchange/downscope，不透传上游 bearer token；
3. subject、actor、client/workload 分开记录；
4. capability server 只接受为自己签发的 token；
5. credential broker 不向模型暴露 token bytes；
6. external content 不能提升 authority；
7. approval 绑定 intent hash / effect / resource；
8. remote Agent 与 MCP server 都被视为独立 trust domain；
9. trace baggage 不承载或证明 authority；
10. effect receipt 绑定 actor、task、idempotency key 和外部资源版本。

8.7 Identity 与 protocol metadata 的关系

9. OpenTelemetry GenAI：把跨协议执行变成因果证据

截至 2026-08-03，GenAI conventions 已从 core semantic-conventions 仓库迁入独立官方仓库；其主干引用 2026-07-03 发布的 core semantic conventions 1.43.0，但独立仓库仍没有 GitHub release，也没有可用的稳定 schema URL，GenAI agent spans、general spans、metrics、events 文档均标记为 Development。Core dependency 1.43.0 的稳定性不能传递成 GenAI conventions 的稳定性。因此生产系统应 pin 自己实际发出的 convention snapshot/commit，而不是假定字段已经永久稳定。依据：OpenTelemetry GenAI repository、GenAI agent spans status、GenAI releases、pinned core version、core v1.43.0 release。

9.1 五种证据对象不要混

不要从 sampled trace 恢复 session，也不要把完整 journal 上传当 telemetry。

9.2 Trace propagation

W3C Trace Context 定义：

• traceparent：trace ID、parent span ID、flags；
• tracestate：vendor-specific tracing state；
• baggage：另一个标准，用于传播键值上下文，不属于 traceparent。

MCP 2026 与 ACP _meta 都保留 traceparent、tracestate、baggage 名称，可让调用链贯通。依据：W3C Trace Context、OpenTelemetry Propagators。

安全要求：

• 把入站 trace context 当不可信数据，严格解析长度/格式；
• trace ID 不是 auth token；
• baggage 可能跨越第三方服务，不放 secret、源码、prompt、email 或 credential；
• 跨 tenant/trust boundary 可继续 trace，也可新建 trace 并用 Span Link 关联；
• 禁止让外部调用者通过 sampling flags 制造无限高成本；
• baggage 白名单、大小限制、hop policy 和脱敏必须独立配置。

9.3 推荐 span tree

原则：

• 一个 user turn / agent invocation 通常是 invoke_agent internal span；
• 调远程 managed Agent 是 invoke_agent client span；
• 直接 inference 用 provider client span；
• execute_tool 表示框架实际执行工具，不要为“模型建议了 tool call”提前创建成功执行 span；
• MCP/A2A/HTTP/RPC 下游 span 保留 parent context；
• detached background task 可新 trace，并用 Span Link 连接 submit span；
• evaluation 往往发生在执行之后，用 eval event + target trace/span ID 关联，不强塞成原 trace 的实时 child。

9.4 当前 GenAI conventions 关键对象

Spans

• inference / embeddings；
• invoke_agent client 与 internal；
• execute_tool internal；
• invoke_workflow；
• retrieval；
• memory create/search/update/upsert/delete；
• plan；
• create_agent；
• fetch response。

Metrics

• token usage；
• operation duration；
• time to first chunk / time per output chunk；
• workflow / agent invocation duration；
• per-agent inference call count、tool call count；
• execute tool duration。

Events

• inference operation details；
• gen_ai.evaluation.result，包括 evaluator metric name、score value/label、explanation；
• client operation exception。

所有这些当前仍需 version pin 和 migration discipline。

9.5 Span attributes：低基数与内容分离

推荐默认属性：

gen_ai.operation.name
gen_ai.provider.name
gen_ai.request.model / gen_ai.response.model
gen_ai.agent.id / name / version
gen_ai.tool.name / type / call.id
gen_ai.usage.input_tokens / output_tokens
gen_ai.usage.cache_read.input_tokens
gen_ai.usage.cache_creation.input_tokens
gen_ai.usage.reasoning.output_tokens
error.type
server.address / server.port (remote client spans)

产品 domain attributes：

app.session.id           // trace attr，可高基数，不做 metric label
app.agent.instance.id
app.turn.id / step.id
app.workspace.trust
app.tool.effect_class
app.permission.decision
app.harness.version
app.tool_catalog.hash
app.verifier.version
app.outcome

内容属性如 tool arguments/result、input/output messages、tool definitions 可能包含源码、PII、secret 且体积高，默认关闭。需要 debug bundle 时应在本地、显式授权、脱敏、加密、短 retention，与 cloud telemetry 分开。

9.6 Agent、tool、eval spans 的精确语义

invoke_agent

边界应覆盖一次 Agent invocation 的真实工作，而不是只包 model call。记录：agent id/version、conversation/session correlation、error/outcome、duration。Internal 用于 in-process runtime，Client 用于远程 Agent service。

execute_tool

只在实际 executor 运行 tool 时创建；建议 span name execute_tool {tool.name}。记录 tool name、call ID、type、status、duration；arguments/results opt-in。对于并行 tools，它们是同一 agent span 的 sibling spans，而不是相互 parent-child。

Evaluation

Eval 必须记录：

• evaluator name/version/prompt/model；
• target artifact/trace/span/task；
• metric definition与 scale；
• score value/label/explanation；
• deterministic / human / LLM judge 类型；
• retry/aggregation；
• 是否影响 rollout gate。

一个 0.8 分若没有量表、evaluator version 与 target，几乎不可比较。

9.7 Async task 的 trace 模型

长任务跨队列、断线和数小时执行时，不要制造一个无限长、依赖单 parent context 的脆弱 trace。推荐：

Trace A: task.submit
  span A1 -> emits task_id + trace link context

Trace B: task.execute attempt 1
  linked to A1

Trace C: task.resume attempt 2
  linked to A1 and failed B root

Trace D: task.verify
  linked to final artifact + task_id

Task/journal 保证 durable correlation，Trace/Links 保证观测因果；二者各司其职。

9.8 Sampling

• head sampling：成本低，但可能丢掉最终失败；
• tail sampling：可保留 error、high latency、permission denied、rollback、verifier fail；
• exemplar：把 SLO metric 的异常点连回 trace；
• per-tenant quota：防止单任务生成数万 spans；
• span compression：高频 token/chunk 不要逐个 span；用 events/metrics；
• full fidelity local trace：调试时短期启用，与生产默认分离。

建议强制保留：安全拒绝、疑似越权、destructive effect、effect unknown、verifier disagreement、resume/reconcile failure；普通成功任务按比例采样。

9.9 Trace 质量自检

一个 trace 能否回答：

1. 用户目标和 Agent/harness 版本是什么？
2. 第一次错误决定发生在哪个 step？
3. 模型看到了哪个 tool catalog/context snapshot？
4. 哪个 identity/authority 导致 action 被允许或拒绝？
5. tool intent、effect 与 receipt 如何关联？
6. retry 是同一 effect 的重试还是新 effect？
7. cancel 到底停止了哪一层？
8. remote Agent / MCP / LSP 的失败边界是什么？
9. artifact 由哪个 verifier、哪个版本验收？
10. 为什么系统最终声称 complete/failed/unknown？

若回答不了，trace 只是性能瀑布图，不是 Agent debugging substrate。

10. 跨协议完整时序：一次 IDE 中的远程委托与工具调用

这条链上至少存在四种状态：ACP session、A2A Task、MCP explicit handle/task、内部 Agent journal。不能只用一个 session_id 试图统一。

10.1 ID correlation 建议

ID 之间应建立映射表或 structured attributes，不应拼接成一个超长复合字符串。

11. Compatibility、failure 与 security 总矩阵

11.1 Compatibility matrix

11.2 Failure matrix

11.3 Security matrix

12. 迁移与演进：怎样升级而不把版本条件扩散到整个系统

12.1 稳定内部 contract

所有 wire 差异收敛到 adapter：

禁止在 Agent loop 中散布：

if (mcpVersion === "2026-07-28") ...
if (acpV2) ...

loop 只消费稳定对象，版本差异在 adapter conformance tests 中解决。

12.2 MCP 2026 迁移清单

1. inventory server/SDK/transport/era；
2. 为 connector 添加 modern discover 与 legacy fallback；
3. 把 initialize/session/client capability cache 改为 request envelope；
4. 清点所有隐藏 session state，变成显式 handle 或 server store + explicit key；
5. 替换 ping：stdio 监视 process/pipe，HTTP 依赖真实 request/health/discover；
6. 实现 subscriptions/listen 与 full re-list on reconnect；
7. catalog cache 加 ttlMs、cacheScope、hash、deterministic order；
8. MRTR 接入统一 Interaction Service；
9. response stream 丢失后执行 effect reconciliation；
10. Roots/Sampling/Logging 进入 deprecation path；
11. OAuth credential 按 issuer/resource 分区，验证 iss；
12. 增加 trace context propagation 与 privacy policy；
13. 跑双栈 conformance、failure injection、side-effect replay tests；
14. telemetry 记录 legacy share 与 fallback reason，达到阈值后再移除旧栈。

12.3 ACP v2 演进清单

• 不把 v2 Draft 默认开启；
• v1/v2 使用同一个内部 journal，分别投影；
• stable message/tool IDs 从 domain event 生成，不从 UI 临时序号生成；
• patch reducer 做 property-based tests：omit/null/replace/append；
• prompt acknowledgement、work active、idle、session closed 分开建模；
• diff schema 支持 text/binary/move/copy，保留 artifact hash；
• permissions 从 tool UI 对象中解耦为 authority request；
• client capability 不支持某 v2 surface 时明确降级；
• transcript replay、断线恢复、乱序/duplicate updates 做 golden tests。

12.4 OTel convention 演进

• pin 当前 semantic convention snapshot/commit；
• instrumentation library 输出 schema/convention version；
• dashboard 不直接依赖 Development 字段而无 translation；
• rename 时短期 dual-read，避免永久 dual-write；
• content capture policy 与 schema upgrade 分离；
• custom domain attributes 使用自有 namespace；
• upstream stable 后删除已经被标准字段取代的别名。

12.5 “兼容”不应变成永久复杂性

Compatibility adapter 要有删除条件：

legacy usage < threshold
∧ no critical partner remains
∧ migration telemetry reliable
∧ rollback window expired
∧ removal release communicated

否则“双栈”会变成永远存在的状态空间倍增。

13. Kimi Code 公开实现映射

审视基线：Kimi Code 公开仓库 commit 29c9e2a，提交时间 2026-08-03。以下是公开代码证据，不推断内部未公开系统。

13.1 MCP

公开实现显示：

• 支持 stdio、Streamable HTTP 和 legacy SSE；
• MCP connection manager 以 Session 为生命周期边界，并行连接、隔离单 server 失败；
• 有 per-server/global startup 与 tool-call timeout；
• 支持静态 header、环境变量 bearer token 与 OAuth；
• tool catalog 进入统一 tool manager，命名为 mcp__<server>__<tool>；
• permission 规则可按 server/tool wildcard；
• project-level stdio MCP 会执行本地 command，文档明确要求信任 repo；
• 当前 agent-core / agent-core-v2 依赖 @modelcontextprotocol/sdk ^1.29.0，client helper 仍调用 ping 做 liveness。

证据：MCP docs、v2 MCP connection manager、MCP client shared、agent-core-v2 package。

判断：这是 MCP 2026 发布后数天的正常生态迁移窗口，不宜称为产品 bug。但它给面试提供了高质量架构题：

将 2026 stateless era 封进 connector adapter，内部 ToolContract、Session tool lifecycle 和 permission pipeline 是否需要改？哪些只是 wire migration，哪些责任必须重新拥有？

建议答案：

• wire version/discover/ping/subscription 封在 MCP adapter；
• catalog freshness、显式 handle、effect reconciliation 是 host 必须新增/重审的责任；
• 不应让 MCP-Protocol-Version 进入 Agent loop；
• current permission matcher 不含 MCP arguments，长期应在统一 ToolIntent effect policy 层补足参数/资源粒度，而非把参数 regex 塞进协议 adapter。

13.2 ACP

Kimi 提供 kimi acp，通过 stdio JSON-RPC 接入 IDE；公开文档列出：

• initialize/auth/new/load/resume/prompt/cancel/list；
• session updates、tool approval、client file read/write；
• MCP server config 从 ACP session 转成 Kimi MCP config；
• terminal reverse-RPC 尚未连接，shell 仍在本地执行；
• adapter 依赖 @agentclientprotocol/sdk ^0.23.0；
• Kimi 文档明确区分 stable 与 unstable surface。

证据：Kimi ACP reference、ACP adapter、ACP package。

面试判断：ACP 是 presentation adapter，不应成为 Kimi Agent state source。session/load 应从 Kimi journal/domain state 恢复，再投影 ACP updates；ACP v2 Draft 到来时保持这一边界，升级成本才可控。

13.3 Skills、Hooks、Plugins

Kimi 的公开 contract 很适合讨论 extension governance：

• Skills scope precedence 为 Project > User > Extra > Built-in；支持手动/模型调用、argument expansion 和最多 3 层嵌套；
• Hooks 接收 JSON stdin，blockable events 只有部分生命周期；当前设计对 error/timeout fail-open，因此文档明确不能作为唯一安全边界；
• Plugins 可贡献 skills、agents、session-start skill、system prompt、MCP servers、hooks、commands；有 official/curated/third-party trust tier，第三方安装默认取消；
• Plugin 当前 user scope，变更在 reload/new session 后稳定生效；prompt contribution 有单项与总量 budget；
• Plugin MCP、Hook 和 system prompt 把 supply-chain、authority 与 context pollution 聚到一个包，安装批准必须是 capability-aware，而不是只问“信任这个插件吗”。

证据：Skills、Hooks、Plugins。

13.4 Telemetry 与 trace

Kimi 公开架构已有：

• session/agent/turn/step/tool-call 等稳定关联字段；
• provider trace ID；
• typed telemetry events 与 privacy filter；
• wire journal、transcript、telemetry 分离；
• tool/compaction/subagent/permission 等 domain events。

证据：Telemetry events、privacy filter、wire service。

公开快照不足以证明已完整采用当前 OTel GenAI Development conventions。更合理的演进是：保留 Kimi domain events 作为产品语义，在 exporter/instrumentation 层映射标准 invoke_agent、execute_tool、inference、evaluation spans；不要为了“标准化”删除对 failure attribution 必要的 Kimi-specific 字段。

13.5 Kimi 协议栈建议图

14. 设计决策框架：新协议或新版本该不该接

14.1 八问

1. 它标准化的是哪两个角色之间的哪种关系？
2. 它拥有哪些 durable state，谁是事实源？
3. transport 断开时，work 是取消、继续还是 unknown？
4. capability 是声明、协商、证明还是授权？
5. retry 会不会重复 effect？receipt/idempotency 在哪层？
6. identity、subject、actor、audience、delegation 怎样表达？
7. trace context 怎样跨边界，敏感内容怎样治理？
8. 版本差异能否封进 adapter，删除旧栈的条件是什么？

14.2 Adoption scorecard

14.3 红线

• 把 self-declared capabilities 当授权；
• 把 transport session 当业务 session；
• 用用户 bearer token贯穿多 Agent / 多工具链；
• 对非幂等 tool 在 unknown outcome 后自动重试；
• 把 trace baggage 当 security context；
• 未信任 repo 自动运行 project hook/MCP/plugin；
• 将 Development telemetry schema 当永久 API；
• 让协议版本判断散布在 Agent loop；
• 只记录最终 error，不记录第一次错误决定和 decision branch。

15. 二十组面试深追问与专家回答框架

1. MCP 2026 为什么删除 protocol session，不会让 stateful tools 变难吗？

答题骨架： 区分 transport/session/application state。旧 session 把 capability snapshot、routing、liveness 和业务状态绑在 connection 上，导致 sticky routing 与隐藏状态。2026 用每 request metadata、discover、显式 handle、subscription stream 解耦。Stateful tool 仍可存在，但 handle 必须显式，便于模型组合、转交和审计。

继续追问： handle 泄漏怎么办？

深入： handle 绑定 issuer、subject/tenant、expiry、resource type；多数情况下 handle 不是 bearer authority，server 仍验证 caller token。

2. Streamable HTTP 断在 tool 已执行但 response 未收到，是否重试？

答题骨架： 这是 unknown outcome，不是普通 transient error。先凭 effect ID / idempotency key / receipt / resource version reconcile；只有 operation 幂等或 server 保证相同 key 去重时才自动重试。新 request ID 不代表新 effect。

继续追问： 没有 reconciliation API？

深入： 将非幂等 tool 标记 non-replayable，要求人工确认或设计 read-after-write verifier；长期补 effect receipt contract。

3. server/discover 与 tools/list 有什么不同？

答题骨架： discover 是协议版本、server identity 和高层 capability discovery；tools/list 是具体 catalog/schema。前者决定能否及怎样说话，后者决定有哪些工具。二者 cache key、TTL 和失效条件不同。

继续追问： serverInfo version 能不能做 feature gate？

深入： 不能；只作诊断。feature truth 来自 negotiated protocol/capabilities/extensions。

4. MCP stateless 后怎样做 liveness？

答题骨架： liveness 从 protocol ping 回归 transport/operation：stdio 监视 child exit、EOF、stderr；HTTP 看 connection/request/health；catalog freshness靠 TTL/subscription。不要用“连接还在”推断 server state 或 tool 可用。

5. MRTR、MCP Tasks、A2A Task 分别何时用？

答题骨架： MRTR 是单 request 需要额外 input 的 continuation；MCP Tasks 是 capability server 内长任务 handle；A2A Task 是独立 Agent 系统间的协作交付对象。按 ownership 选择，不按“都很长”混用。

6. A2A Agent Card 签名后是不是就能自动调用？

答题骨架： 签名证明 card 完整性和 signing identity，不证明 capability quality、runtime attestation、授权或 artifact correctness。还要 endpoint trust、policy、task-scoped authority、data handling、cost budget、verifier。

7. 为什么 A2A 要把 Message 与 Artifact 分开？

答题骨架： Message 是交流和状态，可能 transient；Artifact 是 durable typed deliverable。把输出放 status message 会在断流/replay时丢关键事实，也无法独立 version/hash/verify。

8. A2A AUTH_REQUIRED 能否直接当“用户已批准”？

答题骨架： 不能，它只表示缺授权。协议不定义获得的 credential scope/validity/revocation。需要独立 authority service，把 grant 绑定 actor、task、audience、resource、effect、expiry。

9. 怎样跨多 Agent 安全委托用户权限？

答题骨架： subject 与 actor 分离；每跳 token exchange/downscope；authority 单调衰减；audience/resource 绑定；短 expiry；PoP；保留 delegation chain；credential out-of-band 直达最终 actor；不把 token bytes放进 prompt/message。

10. Delegation 与 impersonation 有何工程差异？

答题骨架： impersonation 在权限上下文中把 A 当 B，审计容易丢 actor；delegation 保留 A 代表 B，适合 Agent。用 sub + act/actor chain 表达，但 RFC 8693 不替你定义 trust policy。

11. DPoP 是否解决 Agent 被 prompt injection 后滥用权限？

答题骨架： 不解决。DPoP 防 stolen token replay，证明 presenter 持有 key；被劫持的合法 Agent 仍持 key。还要 context provenance、policy gate、effect-scoped authority、approval 和 verifier。

12. ACP 为什么不是另一个 MCP？

答题骨架： ACP 标准化 IDE/client 与 coding agent 的 session、prompt、updates、permission 和 presentation；MCP 标准化 host 与 capability server。ACP 可把 MCP configs交给 Agent，但不能替代 MCP tool protocol。

13. ACP session/load 为什么不能直接从 transcript 重建 Agent？

答题骨架： transcript 是用户投影，缺少 hidden state、tool receipts、compaction、policy decisions。内部 journal/checkpoint 才负责恢复；load 只是把恢复后的 domain state投影给 client。

14. ACP v2 Draft 最重要的结构变化是什么？

答题骨架： work lifecycle 不再等于 prompt turn；session updates 可独立发生，prompt response 变 acknowledgement，增加 idle 和 stable-ID patch state。这为 background/steering/multi-observer铺路。因为是 Draft，要双栈和 feature gate。

15. LSP 能否作为 Coding Agent 的 verifier？

答题骨架： 只能作为一类静态语义证据。它会受 indexing、build config、document version影响，不能证明 runtime behavior。最终 verifier 应按 test/build/type/domain oracle层级组合。

16. Skill、Hook、Plugin 中哪个能承担安全边界？

答题骨架： Skill 是概率性知识，不能；Hook 只有明确 fail-closed 且不可绕过时才可参与，但更理想由 permission/policy deep module拥有；Plugin 是分发包，本身扩大 supply-chain surface，不是安全边界。

17. 为什么 trace context 不能承载 authority？

答题骨架： traceparent/baggage 为观测传播设计，可由外部输入、会跨服务、通常不签名；它们不具备 issuer/audience/scope/revocation。Authority 用验证过的 token/policy，trace 只关联 decision evidence。

18. Agent span 应包 model call 还是整个 turn？

答题骨架： invoke_agent 包一次 Agent invocation/turn 的真实工作，内部包含多个 inference/retrieval/tool spans。只包 model call 会丢 loop、tool 和 verifier责任；单个模型请求另建 inference span。

19. Async A2A Task 为什么推荐 Trace Links 而不是一个超长 parent-child trace？

答题骨架： 长任务跨队列、断线和 attempts，单 active parent脆弱且不利采样。Task ID/journal负责 durable correlation；每次 submit/execute/resume/verify独立 trace，用 Links表达因果。

20. 如果让你给 Kimi Code 升级 MCP 2026，你先改哪里？

答题骨架： 先不动 Agent loop。建立 era-aware connector adapter：discover/legacy fallback、per-request envelope、subscription、transport-specific cancel；随后重审显式 handle、catalog cache 与 effect reconciliation。用双栈 conformance/failure injection和 telemetry观察 legacy share，再移除旧路径。

继续追问： Kimi 当前 permission matcher 不看 MCP args怎么办？

深入： 不在 MCP adapter里加散乱 regex；把 MCP call normalize成统一 ToolIntent，policy按 resource/effect/argument summary判定，UI显示同一份 intent，receipt也绑定 intent hash。

16. 掌握度自检

如果以下任何问题只能回答名词，还不算“讲透”：

• 能否画出 MCP 2026 request、subscription、Tasks 三种生命周期？
• 能否解释断流时 unknown outcome 与 retry 的差异？
• 能否写出 catalog cache key 和失效条件？
• 能否解释 A2A Message/Task/Artifact/Context 各自所有权？
• 能否说明 Agent Card signature 不证明什么？
• 能否区分 ACP connection、session、prompt request 与 background work？
• 能否说明 ACP wire protocol version 与 Rust crate、JSON Schema artifact、各语言 SDK package version 的区别？
• 能否解释 LSP document version 与 Agent file tool 冲突？
• 能否给 Skill/Hook/Plugin 各自选择正确 fail/trust policy？
• 能否列出一次 action 的 subject、actor、audience、resource 和 delegation chain？
• 能否解释 PoP、audience restriction、downscope各防什么？
• 能否设计 Agent/tool/eval span tree，并说清异步 task为何用 Links？
• 能否在不记录 prompt/源码/secret的前提下完成失败归因？
• 能否把 MCP/A2A/ACP 版本差异封在 adapter而不污染 loop？
• 能否把协议成功、effect成功、artifact验证和任务完成分成四个状态？

17. 一手资料索引与状态标注

MCP

• MCP 2026-07-28 Stable Release — final tag；GitHub 明确标为 stable release。
• MCP 2026-07-28 Key Changes — 当前正式日期规范变化。
• MCP Architecture — host/client/server 基本关系。
• MCP Discovery — server/discover。
• MCP Authorization — OAuth profile、resource/audience、issuer、scope。
• TypeScript SDK: Supporting 2026-07-28 — 新旧 era adapter 与 transport-specific cancel。

A2A

• A2A 1.0 Specification — data model、operations、bindings、auth/security。
• A2A Releases — 1.0.1 为 latest stable；GitHub 发布日 2026-05-28。
• A2A Proto — canonical schema objects。

ACP 与 LSP

• Agent Client Protocol — 稳定 wire v1；crate/schema artifact version 与 wire version 分离。
• ACP Releases — Rust crate v1.6.0、v1 schema v1.20.0；v2 schema alpha.2 是 pre-release。
• ACP v1 Overview — 生命周期与方法。
• ACP v1 Extensibility — _meta 与 trace context propagation keys。
• ACP v2 Draft — 2026-07-20 Draft，非稳定默认。
• Language Server Protocol 3.18 — 当前 LSP 规范。

Identity 与 observability

• NIST CSRC Agent Identity Concept — Initial Public Draft concept；不是完成标准。
• NCCoE Agent Identity Project — 截至研究日为 Reviewing Comments。
• IETF AAP Datatracker — individual Internet-Draft；页面明确无 IETF 背书和正式标准地位。
• RFC 8693 OAuth Token Exchange — subject/actor、delegation/impersonation。
• RFC 8707 Resource Indicators — audience/resource restriction。
• RFC 9449 DPoP — sender-constrained token / proof-of-possession。
• W3C Trace Context — traceparent / tracestate。
• OpenTelemetry Trace API — spans、links、status。
• OpenTelemetry GenAI Semantic Conventions — 当前独立仓库；Development、无稳定 schema URL。
• OpenTelemetry GenAI Releases — 截至研究日没有 release artifact。

Kimi Code

• Kimi Code repository — 公开 runtime 主源。
• Kimi MCP docs
• Kimi ACP reference
• Kimi Skills
• Kimi Hooks
• Kimi Plugins

18. 最后一页：面试时的统一回答模板

遇到任何协议题，按下面八步回答：

1. Relationship：标准化哪两个角色之间的关系；
2. Objects：核心对象与状态机；
3. Ownership：谁拥有 durable state；
4. Transport：连接、stream、cancel、retry 的语义；
5. Compatibility：version、capability、schema、fallback；
6. Authority：subject、actor、audience、resource、delegation；
7. Evidence：trace、receipt、artifact、verifier；
8. Tradeoff：它明确不解决什么，以及怎样封进 adapter。

一句收束：

我不会因为协议能交换消息就把状态、权限和信任交给它。我会先确定对象和所有权，再让版本、transport 与 schema 收敛在 adapter；让 authority 逐跳衰减、effect 可对账、trace 可贯通，最后用独立 verifier 决定任务是否完成。