Agent 跨系统集成与企业平台 ​

协议只统一交互语言，企业集成还必须补齐身份、授权、任务状态、语义适配、故障恢复和治理责任。

定位：这是七篇正式文档中的第 05 篇。
目标：把两个经常被混在一起讨论的主题彻底拆清：
Protocol 解决独立系统之间怎样以稳定契约互操作；Enterprise Agent Platform 解决多个 Agent 产品怎样共享 Runtime、Execution、Identity、Policy、Trace、Eval 等稳定基础能力。

整篇主线：

text

Capability / Agent
→ Discovery
→ Identity
→ Authorization
→ Contract / Version
→ Protocol
→ Gateway / Adapter
→ Execution
→ Artifact / Evidence
→ Trace / Eval

Domain Agent
→ Repeated Problem
→ Stable Contract
→ Shared Capability
→ Platform

**本篇不是 MCP / A2A API 手册，也不是平台功能清单。**真正要回答的是：
什么时候需要协议、协议能解决什么、不能解决什么；企业什么时候值得把重复能力平台化，平台应该统一什么、不应该统一什么，以及如何证明平台有 ROI。

回答原则：协议题优先讲 Boundary（边界）、Contract（契约）、Identity / Authorization（身份 / 授权）、Version（版本）；平台题优先讲 Trigger（触发条件）、Stable Invariant（稳定不变量）、Semantic Control（语义控制权）、ROI（投资回报）。

一、先建立整篇主线 ​

1.1 Protocol 为什么不是 Integration 的全部 ​

一个协议即使把消息格式标准化了，完整集成仍然需要：

Identity
Authorization
Discovery
Version
Retry
Idempotency
Artifact
Trace
Ownership
SLA
Failure Handling

所以：

Protocol 降低的是互操作接口耦合，不会自动消灭完整 Integration Complexity（集成复杂度）。

MCP（Model Context Protocol，模型上下文协议）可以让 Tool / Resource / Prompt 暴露方式标准化；A2A（Agent-to-Agent Protocol，智能体间协议）可以让独立 Agent 发现、交互和管理任务。
但它们都不能替代企业自己的 IAM、Policy、Gateway、Audit、Business Contract。

1.2 MCP 与 A2A 为什么不是竞争关系 ​

可以粗略记：

MCP
→ Agent / App ↔ Tool / Context Provider

A2A
→ Agent ↔ Independent Agent Service

MCP 主要解决：

• Tool Discovery；
• Tool Call；
• Resource；
• Context / Capability Exposure。

A2A 主要解决：

• Agent Discovery；
• Agent Card；
• Remote Task；
• Message / Artifact；
• Long-running Interaction；
• Opaque Agent Interop。

两者可以同时存在。

例如：

Main Agent
→ A2A 调 Remote Specialist Agent
→ Specialist Agent 内部再通过 MCP 调企业 Tool

1.3 Enterprise Agent Platform 为什么不是第一天就该有 ​

最危险的路线：

看到行业架构图
→ 一次建设 Runtime / Sandbox / Memory / Multi-Agent / Gateway / Eval
→ 半年后只有两个业务真正用

更合理：

1～2 个高价值 Domain Agent
→ 真实业务验证

重复 Failure / Risk / Reuse 出现
→ 抽 Stable Contract

多个团队重复建设
→ Shared Capability

共享能力稳定
→ Platform

所以：

Platform 不是从架构图推导出来的，而是从重复问题里抽出来的。

1.4 本篇最重要的两个不变量 ​

不变量一：Protocol ≠ Integration ​

协议负责稳定互操作契约，企业仍然要治理身份、授权、版本、SLA、审计、所有权。

不变量二：Platform owns Guarantees；Domain owns Meaning ​

Platform 应该拥有：

Stable Contract
Runtime Guarantee
Execution Boundary
Identity / Policy
Trace / Eval Infrastructure
Version / Rollback

Domain 应该拥有：

Business Meaning
Domain Context
Domain Tool
Semantic Model
Business Invariant
Verification Criteria

平台一旦开始统一每个业务 Prompt / Metric / Workflow，就会成为业务瓶颈。

1.5 读不懂时先记这张“Protocol → Platform”速记表 ​

一条最关键的链：

发现某个能力
≠
有权使用这个能力
≠
真实动作已经发生

二、Agent Protocol 与 Integration ​

2.1 Q1｜为什么 Protocol 不等于 Integration？一个协议真正解决了什么、没解决什么？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

Protocol 主要解决：

独立系统之间用什么稳定契约说话。

它不能自动解决：

Identity
Authorization
Business Semantics
Version Compatibility
Retry / Idempotency
Ownership
SLA
Audit

所以协议只是 Integration 的一层。

2～3 分钟高分回答 ​

假设两个 Agent 都支持 A2A。

这只说明它们可以：

• Discover；
• Exchange Message；
• Manage Task；
• Exchange Artifact。

但企业真正接入时还要回答：

• 谁可以调用谁？
• 调用代表哪个用户？
• Remote Agent 能访问什么数据？
• Agent Card 是否可信？
• 版本不兼容怎么办？
• Task Timeout / Retry 怎么处理？
• Artifact 谁负责保留？
• Incident 谁 On-call？

所以完整链路是：

Discovery
→ Trust
→ Authentication
→ Authorization
→ Contract
→ Protocol Transport
→ Runtime / Execution
→ Audit / Ownership

高分亮点句 ​

协议降低点对点适配成本，但不会替你承担企业集成责任。

面试官真正想听什么 ​

• 是否把支持协议误认为完成集成；
• 是否理解 IAM / Version / Ownership。

典型追问 ​

1. 标准协议为什么还需要 Gateway？
2. A2A Agent Card 能不能直接信？
3. MCP Server 支持 OAuth 是否就安全？

Red Flags ​

• “统一 MCP 后集成问题就解决了。”
• “A2A 能替代内部 API。”

为什么这样回答 / 本题套路 ​

这是总边界题。先明确协议解决的单一核心问题，再列它不能承担的生产责任。

2.2 Q2｜MCP、A2A、普通 REST API 各解决什么问题？什么时候应该用哪个？ ​

复习优先级：P0｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

我会按“对端是什么”判断：

稳定业务服务
→ REST / gRPC

Agent 需要动态发现 Tool / Context
→ MCP

独立 Agent Service 需要互操作
→ A2A

不要因为协议新，就把所有 API 包成 MCP / A2A。

2～3 分钟高分回答 ​

REST / gRPC

最适合：

• 已知服务； -固定 Contract； -确定性业务调用； -现有企业 IAM / SLA 完整。

MCP

适合：

• Agent Tool Discovery； -模型可见 Capability； -Tool / Resource / Context Provider 的标准暴露。

2026-07-28 MCP 规范已经转向 Stateless Core，并提供 server/discover、header-based routing、cacheable list 等能力，说明它正在往更标准的企业 HTTP 基础设施靠近。[R1]

A2A

适合：

• 对端本身是独立 Agent； -框架 / Vendor 不同； -需要 Agent Discovery、Task、Artifact、Remote Interaction。

A2A 1.0 当前明确目标就是让不同框架 / Vendor 的独立 Agent 在不暴露内部 Memory / Tool 的情况下互操作。[R2]

高分亮点句 ​

协议选择的第一问题不是“哪个更新”，而是系统边界到底是 Service、Tool，还是 Independent Agent。

面试官真正想听什么 ​

• 是否会把协议当时髦包装；
• 是否理解三种边界。

典型追问 ​

1. REST API 包成 MCP 有什么收益？
2. A2A Agent 也能作为 Tool 吗？
3. 一个系统里 MCP / A2A 能共存吗？

Red Flags ​

• “所有 Agent 接口最终都应该 A2A。”
• “MCP 会替代 REST API。”

为什么这样回答 / 本题套路 ​

这是决策树题。按对端对象类型选协议，比按厂商生态选更稳定。

2.3 Q3｜为什么 Discovery ≠ Authorization ≠ Execution？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

三者分别回答：

Discovery
→ 有哪些能力

Authorization
→ 当前主体能不能用

Execution
→ 动作最终有没有发生

这三个状态必须分开。

2～3 分钟高分回答 ​

Agent Registry 里有一个 Tool：

delete_customer

被发现，不代表当前用户可以调用。

Authorization 通过，也不代表已经执行成功。

所以链路应该是：

Registry
→ Visibility Filter
→ Policy / Authorization
→ Approval if needed
→ Execution
→ Evidence
→ Verification

MCP Tool List / A2A Agent Card 解决的是发现层。

真正权限应来自：

• User Identity；
• Agent Identity；
• Resource；
• Environment；
• Risk；
• Delegated Scope。

高分亮点句 ​

能看到、能调用、已经生效，是三件完全不同的事。

面试官真正想听什么 ​

• 是否把 Tool Visibility 当 Authorization；
• 是否理解 Action Proposal / Effect。

典型追问 ​

1. Tool Search 是否应该过滤无权限 Tool？
2. Agent Card 能否携带权限？
3. Approval 放在哪一层？

Red Flags ​

• “不给模型看就算没权限。”
• “Tool Call 返回 200 就算业务完成。”

为什么这样回答 / 本题套路 ​

这是跨篇不变量题。把 Discovery / Authorization / Execution 拆开可以直接连接 01、03、05。

2.4 Q4｜Agent Card、Tool Metadata、Capability Description 为什么都是不可信输入？怎样防止 Capability Poisoning？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Metadata 是 Discovery Input，不是信任证明。

一个 Tool / Agent 可以自称：

“安全、只读、官方。”

系统不能因为描述这么写就授予权限。

2～3 分钟高分回答 ​

风险链：

恶意 MCP Server / A2A Agent
→ 伪造 Description
→ 宣称“官方财务工具”
→ 模型优先选择
→ 请求敏感数据 / 高权限动作

所以至少需要：

Registry Ownership
Publisher Identity
Signature / Integrity
Review Status
Risk Classification
Permission Policy
Runtime Enforcement

这里还要区分：

Signature
→ 证明内容来自谁、有没有被篡改

Trust
→ 企业是否信任这个 Publisher

Authorization
→ 当前用户 / Agent 是否有权调用

高分亮点句 ​

Capability Metadata 可以参与 Routing，但不能参与自我授权。

面试官真正想听什么 ​

• 是否理解供应链 / Metadata Poisoning；
• 是否混淆 Signature / Trust / Auth。

典型追问 ​

1. 第三方 MCP Server 怎么审核？
2. Agent Card Registry 谁维护？
3. Tool Description 能否由 LLM 自动生成？

Red Flags ​

• “签名了就可信。”
• “官方 Agent Card 里写了权限范围就够了。”

为什么这样回答 / 本题套路 ​

这是安全边界题。高分点是拆 Signature / Trust / Authorization 三层。

2.5 Q5｜MCP 2026-07-28 变成 Stateless Core，对企业架构意味着什么？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Stateless Core 最大的企业意义是：

协议层不再要求会话粘性和共享 Session State，普通 HTTP Load Balancer / Gateway 更容易横向扩展。

但应用层的 Session / Task State 仍然需要自己管理。

2～3 分钟高分回答 ​

2026-07-28 MCP 取消旧的 initialize / initialized 协议级 Session，改成每个 Request 自带：

• Protocol Version；
• Client Info；
• Capability Metadata。

还新增 server/discover。

这意味着 Remote MCP Server 更容易：

Any Request
→ Any Instance

无需：

• Sticky Session；
• Shared MCP Session Store。

但不要误解成：

“Agent 不需要状态了。”

Agent Run、Approval、Tool Job、Business Session 仍然属于应用层 Runtime。

AWS AgentCore Gateway 当前已经支持 MCP 2026-07-28，并显式说明这一版是 Stateless Protocol Revision。[R3]

高分亮点句 ​

协议 Stateless 不等于业务 Stateless；它只是把状态责任从协议传输层移回应用层。

面试官真正想听什么 ​

• 是否理解 Protocol State / Business State 区别；
• 是否能从规范变化推架构影响。

典型追问 ​

1. Stateless 后长任务怎么办？
2. server/discover 和 tools/list 什么关系？
3. 老版本 MCP 怎么兼容？

Red Flags ​

• “MCP 现在无状态，所以不用 Session / Runtime。”

为什么这样回答 / 本题套路 ​

这是动态事实 + 架构推理题。先讲规范变化，再说复杂度被转移到哪里。

2.6 Q6｜Protocol Version、Capability Version、Schema Version 为什么必须分开管理？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

三者变化速度和影响范围不同：

Protocol Version
→ 怎么通信

Capability Version
→ 这个 Tool / Agent 做什么

Schema Version
→ 输入输出长什么样

绑成一个 Version 会让兼容和灰度非常痛苦。

2～3 分钟高分回答 ​

例如 MCP Server 升级 Protocol：

2025-11-25
→ 2026-07-28

不代表某个 Tool：

create_report v3

也变了。

Tool v3 自己又可能保持同名 Capability，但 Input Schema 从：

region: string

变成：

regions: string[]

所以 Version Contract 应该分层：

transport / protocol version
capability version
schema version
semantic version

最危险的是 Schema Compatible 但 Semantic Incompatible：

字段还叫 status，但含义从“当前状态”变成“最后完成状态”。

高分亮点句 ​

Schema Compatibility 不等于 Semantic Compatibility。

面试官真正想听什么 ​

• 是否有企业版本治理；
• 是否只检查 JSON Schema。

典型追问 ​

1. Capability Deprecation 怎么做？
2. 多版本 Tool 同时存在怎么发现？
3. Agent Card 怎么声明版本？

Red Flags ​

• “JSON Schema 不报错就兼容。”
• “协议升级时所有 Tool 一起升级。”

为什么这样回答 / 本题套路 ​

这是 Versioning 题。用“三层版本”避免把通信、能力和数据结构混成一个发布单元。

2.7 Q7｜Remote Agent / Tool 是长任务时，为什么 Task Lifetime 不能绑定 HTTP Connection Lifetime？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

因为一个 Remote Agent Task 可能持续：

分钟
小时
人工等待
异步外部 Job

网络连接不应该承担业务任务生命周期。

2～3 分钟高分回答 ​

错误设计：

POST /agent
→ HTTP 连接挂 30 分钟

会遇到：

• LB Timeout；
• Client Disconnect；
• Deploy；
• Network Flap；
• Retry ambiguity。

更合理：

Create Task
→ task_id
→ accepted / working / waiting
→ poll / stream / webhook / signal
→ artifact
→ final state

A2A 当前规范就是围绕独立 Agent Task / Artifact / Message 交互设计；Microsoft Agent Framework 的 A2A Provider 也支持 Streaming 和 Background Responses。[R2][R4]

高分亮点句 ​

长任务的生命周期应该绑定 Task Identity，而不是绑定 Socket。

面试官真正想听什么 ​

• 是否有异步任务设计；
• 是否理解网络连接和业务生命周期分离。

典型追问 ​

1. Retry Create Task 会不会重复？
2. Client 断线后怎么恢复？
3. Task Retention 怎么定？

Red Flags ​

• “HTTP 超时调成一小时。”
• “断线就重新发一次任务。”

为什么这样回答 / 本题套路 ​

这是 Runtime / Protocol 交叉题。关键是引入 Task Identity 和 Durable State，而不是调大 Timeout。

2.8 Q8｜Gateway（网关）在 Agent Integration（智能体集成）中到底提供什么价值？为什么“统一 Gateway”也可能过度设计？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Gateway 最有价值的能力通常是：

Auth
Policy
Routing
Protocol Translation
Quota
Audit
Observability

但如果只有少数稳定内部服务，直接 API 可能更简单。

2～3 分钟高分回答 ​

Gateway 适合解决跨团队重复问题：

• Inbound Authentication；
• Outbound Credential；
• Tool Registry；
• Rate Limit；
• Policy；
• Protocol Adapter；
• Trace；
• Version Routing。

AWS AgentCore Gateway 当前就是把 OpenAPI / Lambda 等 Target 转成 MCP-compatible Tool，并区分 Inbound / Outbound Authorization。[R3][R5]

但过早统一 Gateway 会新增：

• Latency；
• Central Bottleneck；
• Ownership；
• Migration；
• Provider Lock-in；
• Semantic Translation Complexity。

所以 Trigger 应该是：

多 Agent
多 Backend
多 Auth Model
多团队重复接入
治理要求明显

Agent Gateway 和传统 API Gateway 的差异 ​

传统 API Gateway 主要面对固定 API Traffic；Agent Gateway 还经常需要处理：

Model-visible Discovery
Tool / Agent Metadata
Dynamic Capability Routing
Delegated Identity
Long-running Task
Artifact
Tool-level Risk / Approval
Agent-native Trace

所以它不是“给 API Gateway 加个 MCP Parser”，但应尽量复用成熟 IAM、Rate Limit、Routing、TLS、Audit，而不是重造传统基础设施。

高分亮点句 ​

Gateway 应该在“集成治理问题开始重复”时出现，而不是因为架构图上需要一个中间层。

面试官真正想听什么 ​

• 是否会过度平台化；
• 是否理解 Gateway Control Plane。

典型追问 ​

1. Gateway 是否应该做 Tool Search？
2. Gateway 失败会不会全局故障？
3. Protocol Translation 怎么保证语义不丢？

Red Flags ​

• “所有调用必须统一过 Gateway。”
• “Gateway 只是反向代理。”

为什么这样回答 / 本题套路 ​

这是平台化 Trigger 题。先说它解决的重复问题，再讲什么时候不值得。

2.9 Q9｜Protocol Translation 为什么不是简单 JSON Mapping？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

真正 Translation 要映射的是语义：

Task State
Error
Retry
Artifact
Streaming
Cancellation
Identity

字段能对应，不代表行为等价。

2～3 分钟高分回答 ​

例如 A 协议里：

status = working / completed / failed

B 协议可能还有：

waiting_approval
cancel_requested
partial

如果简单把未知状态映射成：

working

上层系统就丢失了业务语义。

同样：

• A 是 At-least-once；
• B 假设 Client Retry；
• A 有 Task ID；
• B 只有 Request ID。

字段翻译后仍可能产生 Duplicate Side Effect。

所以 Adapter 必须定义：

Semantic Mapping
Unsupported Capability
Lossy Translation
Fallback
Compatibility Test

尤其像 Cancellation（取消）：

Protocol A supports cancel
Protocol B does not

Adapter 不能假装 cancel success。应该显式表达 unsupported / best-effort / local-detach-only，并告诉上层真实副作用可能仍继续。

高分亮点句 ​

协议适配最危险的不是字段映射失败，而是字段看起来成功、语义已经悄悄丢失。

面试官真正想听什么 ​

• 是否理解 Adapter 的语义责任；
• 是否考虑 Lossy Mapping。

典型追问 ​

1. Unsupported Feature 怎么暴露？
2. Streaming 转 Polling 怎么办？
3. Error Code 怎么统一？

Red Flags ​

• “做一个 JSON Transformer 就可以兼容协议。”

为什么这样回答 / 本题套路 ​

这是 Integration 事故题。重点是 Silent Semantic Loss，而不是 Syntax Error。

2.10 Q10｜如何给 Tool / Agent Registry（工具 / 智能体注册中心）做企业级治理？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Registry 不能只是名称列表。

至少要表达：

Owner
Version
Trust
Risk
Permission
Endpoint
Health
SLA
Deprecation

并支持 Discovery、Policy、Audit。

2～3 分钟高分回答 ​

一个 Capability Entry 可以包含：

capability_id
name
description
type
owner
publisher
protocol
endpoint
version
schema
risk_level
auth_method
data_classification
region
status
deprecation
health

然后分两层：

Registry
→ 企业有哪些能力

Model-visible Candidate Set
→ 当前任务模型能看到哪些

这两个不能等同。

Registry 可能有 5000 个 Tool，模型这一轮只应该看到几十个候选。

数量继续扩大后的 Federation ​

当规模从几十个 Server / 数百 Capability 继续扩到跨组织、跨 Region 时，Registry 会进一步需要：

Namespace / Domain Registry
Federated Discovery
Semantic Search / Ranking
Identity Federation
Policy Federation
Compatibility / Conformance
Local Ownership

不应把全公司所有实时权限和 Metadata 强行集中成一个全球单体 Registry。

高分亮点句 ​

Capability Registry 是企业资产目录，Model-visible Tools 只是它在当前任务下的一个受控投影。

面试官真正想听什么 ​

• 是否理解 Registry ≠ Prompt Tool List；
• 是否有 Owner / Risk / Version 思维。

典型追问 ​

1. Registry 多 Region 怎么做？
2. Tool Health 会不会影响 Routing？
3. Description 变化需要 Review 吗？

Red Flags ​

• “把 Tool Schema 存数据库就是 Registry。”

为什么这样回答 / 本题套路 ​

这是 Control Plane 题。重点从“存元数据”升级到治理和模型可见投影。

2.11 Q11｜MCP、A2A、AG-UI、ACP 为什么分别解决不同边界？怎样避免“一个协议打天下”？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

我会按交互边界区分：

MCP
→ Agent / App ↔ Tool / Context

A2A
→ Agent ↔ Independent Agent

AG-UI
→ Agent Backend ↔ Frontend / UI State

ACP
→ Coding Agent ↔ Editor / IDE

它们解决的是不同互操作问题，不应该互相替代。

2～3 分钟高分回答 ​

MCP

核心是让模型 / Agent 发现和调用 Tool、Resource、Context Provider。

A2A

核心是让独立 Agent Service 在不暴露内部 Tool / Memory 的前提下互操作，管理 Task / Message / Artifact。

AG-UI

核心是 Agent 与前端实时交互。

当前官方文档使用 typed event，并通过：

STATE_SNAPSHOT
STATE_DELTA
MESSAGES_SNAPSHOT

同步前端状态；Activity / Tool / Run 也都有独立 Event。[R8]

ACP（Agent Client Protocol，智能体客户端协议）

更偏 Coding Agent 与 IDE / Editor 的互操作，让一个 Agent 实现可以接入多个编辑器。Zed 当前已经把 ACP 用在 Zed、JetBrains、VS Code 等编辑器与多种 Coding Agent 的连接上。[R9]

因此选协议前先问：

谁和谁在通信？需要共享的是 Tool、Task、UI State，还是 IDE Interaction？

高分亮点句 ​

协议不是按“新旧”分类，而是按系统边界分类。

面试官真正想听什么 ​

• 是否知道 Agent 生态协议不是一个维度；
• 是否会“所有协议都 MCP 化”。

典型追问 ​

1. AG-UI 能不能替代 A2A？
2. ACP 和 A2A 有什么重叠？
3. 一个 Coding Agent 同时支持 ACP + MCP 合理吗？
4. 前端是否应该直接连 MCP？

Red Flags ​

• “MCP 最终会统一所有 Agent 协议。”
• “A2A 和 AG-UI 只是不同厂商版本。”

为什么这样回答 / 本题套路 ​

这是协议全景题。最稳定的方法是先找通信边界，再映射协议，不按产品 Feature 表背诵。

2.12 Q12｜API、Protocol、SDK、Framework、Gateway 分别是什么？为什么在 Agent 架构评审里必须先分清这五层？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

我会先按职责拆：

API
→ 一个系统暴露什么能力

Protocol
→ 独立实现之间按什么稳定规则互操作

SDK
→ 开发者如何更方便地调用协议 / API

Framework
→ 应用内部怎样组织 Agent 逻辑

Gateway
→ 多个能力 / 系统怎样统一接入、治理、路由

它们不是同一层，也不应该因为“都能调用 Tool”就混成一个概念。

2～3 分钟高分回答 ​

最容易出错的是把产品能力和架构责任混在一起。

比如：

“我们用了某 Agent Framework，所以已经支持 MCP。”

这最多说明 Framework 提供了一个 MCP Client / Server Adapter，并不代表企业 Tool 已经完成 Registry、Identity / Authorization、Version、SLA、Audit 治理。

同样，Gateway 也不是 Protocol。Gateway 可以同时代理 REST、MCP、A2A；Protocol 只是其中一种互操作契约。

所以做架构 Review 时我会先问：

这是应用内编程抽象？
还是跨进程 API？
还是跨 Vendor Protocol？
还是企业治理入口？

高分亮点句 ​

很多 Agent 架构争论不是方案冲突，而是大家在用同一个词讨论不同层。

面试官真正想听什么 ​

• 是否能做概念分层；
• 是否把 Framework / Protocol / Gateway 混用；
• 是否能识别产品封装背后的架构责任。

典型追问 ​

1. SDK 能不能隐藏 Protocol？
2. Framework Lock-in 和 Protocol Lock-in 有什么区别？
3. Gateway 是不是一定要单独部署？

Red Flags ​

• “MCP 是一个 Agent Framework。”
• “用了 SDK 就完成企业 Integration。”

为什么这样回答 / 本题套路 ​

这是 Protocol 模块的根定义题。先把层次分开，后面的 Gateway、Registry、Compatibility 才能讨论清楚。

2.13 Q13｜Capability Registry 已经撤权，但 Discovery Cache 仍把 Tool 暴露给 Agent，为什么 Discovery Cache 不能成为 Authorization Source？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

因为：

Discovery Cache
→ 优化“能发现什么”

Authorization
→ 决定“现在能不能执行”

缓存可以陈旧，权限不能以陈旧缓存为最终事实。

2～3 分钟高分回答 ​

典型事故：

Tool T
→ Registry / IAM 已撤权
→ Client 仍缓存旧 tools/list
→ 模型继续看到 T
→ 发起调用

正确系统应该允许：

Tool 仍被模型看到，但执行层最终 Authorization 拒绝。

更好的体验是同时做：

Cache TTL / Invalidation
+
Query-time Authorization

但是绝不能：

visible_in_cache = authorized

MCP 2026-07-28 支持 cacheable list results 后，这个边界更加重要：缓存优化 Discovery，实时权限仍必须在执行路径重新成立。

高分亮点句 ​

Visibility 可以最终一致，Authorization 必须在执行时重新成立。

面试官真正想听什么 ​

• 是否理解 Cache Staleness；
• 是否会把 Tool List 当 ACL；
• 是否有 TOCTOU（检查与使用时序差）意识。

典型追问 ​

1. 权限撤销后多久必须不可见？
2. Model 已经计划调用被撤权 Tool 怎么办？
3. Authorization Cache 能不能做？

Red Flags ​

• “tools/list 里没有就算无权限；有就算有权限。”

为什么这样回答 / 本题套路 ​

这是一个隐藏 Failure Window：Discovery 和 Authorization 时间点不同，普通 Demo 很容易把两者偷懒合并。

2.14 Q14｜Remote Agent Timeout 后直接 Retry 导致重复 Deploy，Operation / Task Semantics 应该怎么设计？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

Remote Agent Timeout 代表：

客户端不知道远端 Task 当前结果。

它不等于远端失败。

因此需要稳定 task_id / operation_id、Idempotency、Status Query 和 Reconciliation，再决定是否 Retry。

2～3 分钟高分回答 ​

错误链：

Client → Remote Deploy Agent
Remote 已触发 Deploy
→ Response 丢失
Client Timeout
→ 再创建一个 Deploy Task
→ 重复发布

更合理：

create task with request identity
→ receive / recover task_id
→ timeout
→ query remote status
→ reconcile
→ continue / retry safely

如果创建本身 Response 丢失，还需要 client request id、server-side dedup 和 correlation key。

A2A 当前把 Task 作为核心动作单元，包含稳定 Task ID、Status、Artifact / History；MCP 新版 Tasks Extension 也沿显式 Task Handle 方向演进。

高分亮点句 ​

Remote Agent 的 Retry 首先是 Task Identity 问题，其次才是网络重试问题。

面试官真正想听什么 ​

• 是否理解 Unknown Outcome；
• 是否能把 Durable Runtime 的副作用语义迁移到远端 Agent。

典型追问 ​

1. Create Task 自身如何幂等？
2. Remote Agent 不支持 Status Query 怎么办？
3. Task Retention 太短怎么办？

Red Flags ​

• “HTTP 5xx / Timeout 就自动 Retry。”

为什么这样回答 / 本题套路 ​

这是 Protocol 和 Durable Runtime 的交叉题。真正高分点是把“网络失败”还原成“业务任务状态未知”。

2.15 Q15｜SSE / WebSocket / Agent Stream 中途断线，怎样通过 Event ID、Snapshot、Delta、Resume / Re-sync 保证状态可重建？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

Streaming 不能把连接本身当状态。

我会让事件拥有单调 ID，并把 Client State 建模成：

Snapshot
+
Ordered Delta

断线后根据 last_event_id Resume；无法增量恢复时重新取 Snapshot。

2～3 分钟高分回答 ​

一个稳定事件至少有：

run_id
event_id
event_type
version
payload
timestamp

Client 记录 last_applied_event_id。

重连时：

resume after N

如果 Server 仍保留 History，返回 N 之后的 Delta；如果 History 已压缩或 Retention 过期，就：

re-sync snapshot
→ continue deltas

还要处理：

• Duplicate Event → Idempotent Apply；
• Out-of-order → Sequence Check；
• Missing Gap → Re-sync；
• Snapshot / Delta 版本不一致 → Reject / Retry。

高分亮点句 ​

可靠 Streaming 的核心不是连接不断，而是连接断了以后状态还能重建。

面试官真正想听什么 ​

• 是否有前后端状态恢复能力；
• 是否把 SSE 当一次性日志流。

典型追问 ​

1. Event History 保存多久？
2. 多 Tab 同时连接怎么办？
3. Approval 事件重复应用怎么办？

Red Flags ​

• “断线后重新建立 SSE，从新消息开始看。”

为什么这样回答 / 本题套路 ​

这是 Full-stack 与 Protocol 的交叉题。重点从 Transport 提升到 State Reconstruction。

2.16 Q16｜远端 Artifact URL 为什么可能成为 SSRF / Exfiltration 入口？怎样安全接收 Agent Artifact？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

Remote Agent 返回一个 URL，不代表平台应该直接 Fetch。

它可能指向内网、Cloud Metadata、恶意重定向或超大文件，因此 Artifact Fetch 本身也是高风险 Network Capability。

2～3 分钟高分回答 ​

典型攻击：

artifact.url
= http://169.254.169.254/...

或者：

attacker URL
→ redirect
→ internal service

安全链应该有：

URL validation
→ scheme / host policy
→ DNS / redirect check
→ size / timeout limit
→ content-type validation
→ malware scan
→ managed artifact store
→ provenance

高敏感场景更倾向传受控 Artifact Handle / Blob，而不是允许任意 URL。

高分亮点句 ​

Artifact 是交付物，但 Artifact Pointer 本身也可能是一条执行路径。

面试官真正想听什么 ​

• 是否理解 SSRF / Exfiltration；
• 是否考虑远端 Agent 不可信；
• 是否有 Artifact Gateway 思维。

典型追问 ​

1. Signed URL 就一定安全吗？
2. 大文件怎么传？
3. 跨 Region Artifact 怎么处理？

Red Flags ​

• “远端返回 URL，平台直接下载即可。”

为什么这样回答 / 本题套路 ​

这是安全惊喜题：普通人把 Artifact 当数据，高级回答会继续看到“取 Artifact”本身也是受控执行。

2.17 Protocol / Integration 阶段性总结 ​

如果只记六句话：

1. Protocol ≠ Integration。
2. MCP 更偏 Agent ↔ Tool / Context；A2A 更偏 Agent ↔ Independent Agent。
3. Discovery ≠ Authorization ≠ Execution。
4. Signature ≠ Trust ≠ Authorization。
5. Task Lifetime ≠ Transport Connection Lifetime。
6. Schema Compatibility ≠ Semantic Compatibility。

三、Enterprise Agent Platform 企业级智能体平台 ​

3.1 Q17｜什么情况下企业应该建设 Shared Agent Platform？什么情况下反而不应该？ ​

复习优先级：P2｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

我只在：

重复问题
+
稳定抽象
+
多个团队复用
+
治理收益明确

时建议平台化。

如果只有 1～2 个 Agent、架构还快速变化，过早平台化反而会冻结错误抽象。

2～3 分钟高分回答 ​

合理 Trigger：

Reuse

多个 Agent 都重复建设：

Run
Trace
Tool Contract
Identity
Sandbox
Eval

Risk

副作用、权限、多租户安全开始重复出现。

Scale

大量 Run、Tool、Agent、Team。

Governance

版本、成本、审计、发布开始失控。

Migration Urgency

越晚统一 Contract，迁移代价越高。

反过来，如果：

• 团队少； -场景变化快； -业务价值还没证明； -共享需求不稳定；

先把 Domain Agent 做成功更重要。

再往上一层：平台化其实是在赌“抽象已经稳定” ​

平台最危险的失败不是做不出来，而是：

把还在变化的 Domain Pattern
→ 过早冻结成 Shared Contract
→ 所有业务开始迁移
→ 两个月后发现抽象错了
→ 全公司一起承担迁移成本

所以我会同时看两个信号：

重复度是否足够高？
抽象稳定性是否足够高？

只有“重复很多”还不够。重复出现的如果仍然是快速变化的探索性做法，也不应该马上平台化。

怎么验证平台化决定是对的 ​

至少看：

接入新 Agent 的 lead time
重复基础代码
跨 Agent incident rate
platform-induced latency / outage
migration effort
business escape-hatch usage

如果平台接入后只是“代码统一了”，但上线更慢、平台故障半径更大，说明平台化并没有真正创造净收益。

高分亮点句 ​

平台不是最终目标，它只是重复问题足够稳定以后的一种组织方式。

面试官真正想听什么 ​

• 是否有平台化克制；
• 是否理解 Trigger。

典型追问 ​

1. 第一个该统一什么？
2. 哪些能力最不应该过早统一？
3. 怎么判断抽象稳定？

Red Flags ​

• “企业最终一定需要统一大平台。”
• “先搭平台再找业务。”

为什么这样回答 / 本题套路 ​

这是平台总判断题。先给“不一定要平台”，再讲 Trigger，才能体现架构判断。

3.2 Q18｜Enterprise Agent Platform（企业智能体平台）应该统一什么，不应该统一什么？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

统一稳定不变量：

Run / Trace Contract
Tool / Capability Contract
Identity / Policy Hook
Runtime
Execution Boundary
Artifact
Eval Infrastructure
Version / Cost

不要统一高变化业务语义：

Prompt
Metric Definition
Domain Workflow
Business Verification

2～3 分钟高分回答 ​

Platform 应该拥有 Guarantee：

• Run 可追踪；
• Runtime 可恢复；
• Execution 有隔离；
• Policy 可执行；
• Trace 可关联；
• Version 可回滚；
• Eval 可比较。

Domain 应该拥有 Meaning：

• 用户目标；
• Domain Context；
• Domain Tool；
• Semantic Model；
• Business Invariant；
• Verification Criteria。

例如 Data Agent 的 Metric Definition 不能被 Agent Platform Team 统一维护。

研发 Agent 的 Repo-specific Build / Test 规则也不应该硬编码进 Shared Core。

高分亮点句 ​

Platform owns Guarantees；Domain owns Meaning。

面试官真正想听什么 ​

• 是否有平台 / 业务分工；
• 是否会把平台做成超级业务层。

典型追问 ​

1. Verification Framework 谁拥有？
2. Tool Contract 谁定义？
3. Domain Skill 属于哪层？

Red Flags ​

• “所有 Agent 使用统一 Prompt / Workflow。”
• “平台团队维护所有业务 Tool。”

为什么这样回答 / 本题套路 ​

这是组织边界题。用 Guarantee vs Meaning 是最稳定的抽象。

3.3 Q19｜为什么 Shared Harness Core 应该很薄？哪些能力更适合作为可替换 Standard Capability？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

Core 越厚，越容易把变化快的 Agent Pattern 固化。

我会让 Core 只保留：

Run / Turn
Capability Contract
Context Interface
Policy Hook
Verification Hook
Trace Event
Budget / Cancellation

2～3 分钟高分回答 ​

这些语义跨 Data / Coding / Ops Agent 都相对稳定。

而：

Planning
Compaction
Skill
Subagent
Approval
Memory

更适合作为 Replaceable Standard Capability（可替换标准能力）。

为什么？

因为这些能力：

• 模型变化会影响最佳实现； -不同 Domain 需求差异大； -行业仍在快速演进。

如果塞进 Core：

每次能力升级都变成平台大版本。

一个判断 Core / Capability 的简单方法 ​

我会连续问四个问题：

1. 这个语义跨 Domain 是否稳定？
2. Model 能力升级后它会不会明显变化？
3. 不同业务是否需要完全不同策略？
4. 一旦放进 Core，未来替换成本是否很高？

例如 Run ID / Trace Event / Cancellation Hook 很稳定，适合 Core。

但 Planning / Memory Ranking / Subagent Strategy 会随着 Model、任务类型和产品形态持续变化，更适合 Replaceable Capability。

Core 过厚的真实后果 ​

一个业务想升级 Planning
→ 需要平台发版

一个团队想换 Memory Backend
→ 影响所有 Agent

一个新模型支持不同 Tool Pattern
→ Core 需要全局重构

最终 Platform Team 会成为所有 Domain 的变更瓶颈。

高分亮点句 ​

Shared Core 应该稳定地承载不变量，而不是提前固化今天最流行的 Agent Pattern。

面试官真正想听什么 ​

• 是否有 Core / Extension 边界；
• 是否会把 Framework Feature 全塞平台。

典型追问 ​

1. Approval 是 Core 还是 Capability？
2. Context Engine 属于 Core 吗？
3. 怎么定义插件 Contract？

Red Flags ​

• “平台 Core 自带所有能力才完整。”

为什么这样回答 / 本题套路 ​

这是平台架构边界题。高分点是“可替换默认值”而不是“大一统核心”。

3.4 Q20｜Agent Platform 的 Control Plane 与 Runtime / Execution Plane 为什么要分开？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Control Plane 管：

配置、策略、版本、发现、发布。

Runtime / Execution Plane 管：

单次 Run 真正如何执行。

两者生命周期不同，不应该绑死。

2～3 分钟高分回答 ​

Control Plane

Agent Definition
Prompt / Skill Version
Tool Registry
Model Routing
Policy
Quota
Deployment
Experiment

Runtime Plane

Run
Checkpoint
Wait / Signal
Scheduling
Trace

Execution Plane

Sandbox
Workspace
Browser
Shell
SQL
Artifact

为什么分？

因为：

配置变化频率
≠
运行任务生命周期

一个 Waiting Run 可能跨越两次平台发布。

如果 Control / Runtime 耦合，就会导致：

• 旧 Run 无法恢复；
• Agent Config 漂移；
• Rollback 困难。

高分亮点句 ​

平台配置的生命周期和单次执行生命周期必须解耦。

面试官真正想听什么 ​

• 是否有 Control Plane / Data Plane 思维；
• 是否理解版本绑定。

典型追问 ​

1. Policy 实时变更是否影响 Running Run？
2. Tool Registry 更新如何灰度？
3. Model Routing 属于哪层？

Red Flags ​

• “一个 Agent Service 同时维护配置和所有运行状态。”

为什么这样回答 / 本题套路 ​

这是平台控制面题。关键是生命周期差异。

3.5 Q21｜Identity / Permission / Approval 为什么应该成为共享平台能力？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

因为多个 Agent 都会重复遇到：

谁代表谁
谁能做什么
在哪个环境能做
什么风险需要审批

而且这是高风险、不适合每个业务自己随意实现的稳定语义。

2～3 分钟高分回答 ​

我会至少区分：

User Identity
Agent Identity
Execution Identity

权限判断：

user
× agent
× capability
× resource
× environment
× risk

不是：

“用户有权限，所以 Agent 全部有权限。”

AWS AgentCore Identity 当前把 Agent Identity 建模成 Workload Identity，并明确区分 Agent / Tool 访问 AWS 和第三方服务时的 Credential Management；Gateway 也区分 Inbound 与 Outbound Authorization。[R5][R6]

Approval 只应该处理高风险边界，不应该替代权限和 Sandbox。

高分亮点句 ​

Agent 平台的身份问题不是“谁登录了”，而是“谁代表谁，在什么范围内替谁行动”。

面试官真正想听什么 ​

• 是否理解 Agent Identity；
• 是否会每个业务自建审批。

典型追问 ​

1. Delegation 怎么传身份？
2. Service Account 能不能共用？
3. Approval 和 Authorization 区别？

Red Flags ​

• “所有 Agent 用统一平台 Service Account。”
• “高风险动作都弹确认即可。”

为什么这样回答 / 本题套路 ​

这是共享治理能力题。Identity / Policy 是最值得早统一的 Contract 之一。

3.6 Q22｜为什么 Observability（可观测性）/ Eval（评测）必须绑定版本？Agent Platform 至少要记录哪些 Version Dimension（版本维度）？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Agent 系统变量太多，不绑定版本就无法归因。

至少记录：

agent
model
prompt
skill
tool
context policy
runtime
execution image
topology

2～3 分钟高分回答 ​

用户说：

“昨天很好，今天变差了。”

可能是：

• Model Provider；
• Prompt；
• Tool Schema；
• Knowledge Index；
• Skill；
• Multi-Agent Topology；
• Sandbox Image；
• Runtime；
• Policy。

所以一次 Agent Release（智能体发布）不应该只绑定一个 agent_version，而要把本次运行真正依赖的版本形成 Version Manifest（版本清单），并绑定到 Run：

run_id
agent_version
model_version
prompt_version
skill_version
tool_version
knowledge / memory policy version
context_policy_version
runtime_version
execution_image_version
topology_version

这样才能：

Regression
→ Diff
→ Attribution
→ Rollback

高分亮点句 ​

没有 Version-aware Trace，就没有真正的 Agent Regression Engineering。

面试官真正想听什么 ​

• 是否能做生产回归归因；
• 是否只看最终答案。

典型追问 ​

1. Provider 偷偷更新 Model 怎么办？
2. Prompt / Skill 灰度怎么打版本？
3. Tool Backend 逻辑变了但 Schema 不变怎么办？

Red Flags ​

• “只记录 model name 和 prompt text。”

为什么这样回答 / 本题套路 ​

这是 Observability / Release 交叉题。核心是多变量归因。

3.7 Q23｜Build vs Buy / OSS / Managed 应该怎么判断？什么叫 Semantic Control？ ​

复习优先级：P2｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

我不会按“核心能力一定自研”判断。

真正要问：

这层语义是否是企业必须长期掌控的？

即使 Runtime / Sandbox / Gateway 用 Managed 服务，也应该保留自己的：

Contract
Policy
Trace
Eval
Data
Version Mapping

2～3 分钟高分回答 ​

例如买 Managed Sandbox。

企业可以不自己维护 VM / Container Fleet，但仍应该控制：

• Environment Contract；
• Network Policy；
• Identity；
• Artifact Contract；
• Trace；
• Provider Abstraction。

这叫 Semantic Control（语义控制权）。

Buy / Managed 更适合：

• 差异化价值低； -运维复杂； -成熟 Provider 有明显优势。

Build 更适合：

• 核心业务语义； -强合规 / Data Residency； -Provider Lock-in 风险高； -企业需要统一跨 Provider Contract。

高分亮点句 ​

企业不需要拥有所有基础设施代码，但必须拥有关键语义和迁移权。

面试官真正想听什么 ​

• 是否会理性 Build / Buy；
• 是否理解 Provider Lock-in。

典型追问 ​

1. Sandbox Provider 怎么替换？
2. Agent Framework 该不该统一？
3. Managed Runtime 值不值得？

Red Flags ​

• “核心系统必须全部自研。”
• “Managed 服务什么都不用管。”

为什么这样回答 / 本题套路 ​

这是架构决策题。用 Semantic Control 替代“自研情结”。

3.8 Q24｜Agent Platform 的能力优先级应该怎么排？为什么不是 Feature 越高级越先做？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

我会优先统一：

越晚统一，迁移成本越高；风险越大；复用越稳定的 Contract。

而不是优先做最酷的 Feature。

2～3 分钟高分回答 ​

一个概念模型：

Priority
≈
Reuse Frequency
× Failure / Risk Cost
× Standardization Stability
× Migration Urgency
-
Coordination Cost
-
Platform Complexity

P0

• Run / Agent Version；
• Trace Correlation；
• Tool Contract；
• Identity / Policy Hook；
• Artifact Contract；
• Usage / Cost。

P1

• Durable Runtime；
• Sandbox / Workspace；
• Context Governance；
• Eval Infrastructure；
• Approval；
• Skill Registry。

P2

• Global Scheduler；
• Organization Memory；
• Dynamic Capability Router；
• Multi-Agent Platform；
• Protocol Federation。

P2 不是更高级，只是通常更晚才有正 ROI。

高分亮点句 ​

平台优先级看迁移不可逆性和稳定复用，不看技术新颖度。

面试官真正想听什么 ​

• 是否会 Roadmap；
• 是否能做投资取舍。

典型追问 ​

1. 为什么 Trace 是 P0？
2. Multi-Agent 为什么 P2？
3. Skill Registry 什么时候提前？

Red Flags ​

• “先把所有 Capability 都搭齐。”
• “行业最火的能力优先。”

为什么这样回答 / 本题套路 ​

这是 Roadmap / Investment 题。P8 要体现资源配置能力，而不是只会画架构。

3.9 Q25｜平台团队和 Domain Team 怎么分工，避免平台成为业务瓶颈？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

Platform Team 承诺 Guarantee；Domain Team 拥有 Meaning。

不要让平台团队写每个业务 Prompt，也不要让业务团队重复造 Runtime / Identity / Trace。

2～3 分钟高分回答 ​

Platform：

Run / Trace Contract
Runtime
Execution Fabric
Identity / Policy
Capability Registry
Eval Infrastructure
Version / Rollback

Domain：

Domain Instruction
Domain Tool
Semantic Model
Business Invariant
Verification Criteria
Domain Skill

共同：

• Incident； -上线治理； -成本； -安全 Review。

一个 RACI（职责分工）可以是：

Platform
→ A/R for infrastructure guarantees

Domain
→ R for business semantics and verification

高分亮点句 ​

平台团队不应该成为全公司的 Prompt 工程团队，业务团队也不应该成为分布式系统基础设施团队。

面试官真正想听什么 ​

• 是否有组织设计能力；
• 是否理解平台和 Domain 的 ownership。

典型追问 ​

1. Tool Contract 谁负责？
2. Incident 谁 On-call？
3. Verification framework 和 rule 谁拥有？

Red Flags ​

• “平台统一维护所有 Agent。”
• “业务自己搞全部底座更灵活。”

为什么这样回答 / 本题套路 ​

这是组织架构题。好的技术平台设计一定要能映射到 Ownership。

3.10 Q26｜Enterprise Agent Platform 的 ROI 怎么证明？为什么接入 Agent 数量不是好指标？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

平台成功不是：

“接了多少 Agent。”

而应该看它是否：

降低交付成本
降低生产事故
提升复用
缩短 Debug / Recovery
提高治理覆盖

2～3 分钟高分回答 ​

我会从四类看。

Developer Efficiency

• 新 Agent 从 0 到 Production 的时间；
• 重复底座代码减少；
• Shared Capability Reuse。

Production

• Verified Success；
• Incident Rate；
• Recovery Rate；
• Time to Debug；
• Change Failure Rate。

Cost

• Cost / Successful Run；
• Infra / Run；
• Shared Capability Saving。

Governance

• Unauthorized Attempt；
• Trace Coverage；
• Version Coverage；
• Audit Completeness。

最重要的是建立平台前后对照：

Before Platform
vs
After Platform

否则“用了平台”不能证明创造价值。

高分亮点句 ​

平台 ROI 应该体现“重复复杂度被消除了多少”，而不是“平台接入规模有多大”。

面试官真正想听什么 ​

• 是否有平台 ROI；
• 是否会用 Vanity Metric。

典型追问 ​

1. 怎么算复用收益？
2. 平台增加的 Coordination Cost 怎么算？
3. 什么时候应该下线平台能力？

Red Flags ​

• “平台接入了 100 个 Agent，所以成功。”
• “能力数量越多 ROI 越高。”

为什么这样回答 / 本题套路 ​

这是 Leadership / Platform Ownership 题。最终要能证明平台投资值得。

3.11 Q27｜从 2 个 Agent 到 100 个 Agent，平台架构会发生哪些质变？ ​

复习优先级：P2｜题型：S4 Architecture Evolution

30 秒核心回答 ​

规模从 2 到 100，最先变复杂的不是模型，而是：

Registry
Identity
Policy
Version
Cost
Quota
Observability
Ownership

很多原本隐式约束会被迫平台化。

2～3 分钟高分回答 ​

2 个 Agent：

• 手工 Tool List； -简单 Service Account； -人工看日志； -团队内约定。

100 个 Agent：

Capability

Registry
Discovery
Deprecation
Version

Identity

Agent Identity
Delegation
Tenant Isolation

Runtime

Quota
Priority
Backpressure

Observability

Trace correlation
version attribution
cost attribution

Governance

release
audit
ownership
policy

这就是：

Scale 会把隐式约束逼成显式平台能力。

高分亮点句 ​

Agent 数量增长的真正后果，不是模型调用变多，而是治理对象数量爆炸。

面试官真正想听什么 ​

• 是否能解释平台为什么“长出来”；
• 是否理解规模质变。

典型追问 ​

1. 哪一层最先平台化？
2. 1000 Agent 怎么做 Registry？
3. Quota 按 Agent 还是 Tenant？

Red Flags ​

• “多 Agent 就多部署几个服务。”

为什么这样回答 / 本题套路 ​

这是 Architecture Evolution 题。重点讲“什么约束从隐式变显式”。

3.12 Q28｜如果从零设计 Enterprise Agent Platform（企业智能体平台），你会怎么分层？ ​

复习优先级：P2｜题型：S1 System Design

30 秒核心回答 ​

我会分成：

Domain Layer
Agent / Harness Layer
Context / Capability Layer
Runtime Layer
Execution Layer
Integration Layer
Assurance / Governance Layer

但重点不是画几层，而是每层 Contract 和 Ownership 清晰。

2～3 分钟高分回答 ​

一个参考结构：

[Domain Agent]
  ├─ Prompt / Skill / Domain Tool / Verifier
  ↓
[Harness]
  ├─ Loop / Planning / Tool / Policy Hook
  ↓
[Context + Capability]
  ├─ Context Policy / Tool Registry / Knowledge / Memory
  ↓
[Runtime]
  ├─ Run / Checkpoint / Wait / Signal / Retry / Version
  ↓
[Execution]
  ├─ Sandbox / Workspace / Browser / Shell / Artifact
  ↓
[Integration]
  ├─ API / MCP / A2A / Gateway / Enterprise Systems

横向：
[Identity / Policy / Trace / Eval / Cost / Release]

这里横向 Assurance 不属于某一个单点层。

例如：

• Identity 贯穿 Capability / Execution；
• Trace 贯穿 Harness / Runtime / Tool；
• Eval 绑定所有 Version。

高分亮点句 ​

Reference Architecture 的价值不是组件齐全，而是把责任边界、依赖和演进 Trigger 说清楚。

面试官真正想听什么 ​

• 是否能系统设计平台；
• 是否把所有能力塞一个 Runtime；
• 是否理解横向治理。

典型追问 ​

1. 哪层可以 Managed？
2. Context Platform 和 Knowledge Platform 怎么分？
3. Protocol 放哪层？
4. Multi-Agent 属于哪层？

Red Flags ​

• 只画一堆框，没有 Contract / Ownership；
• 按产品名分层。

为什么这样回答 / 本题套路 ​

这是 System Design 总题。先给稳定系统责任，再允许实现替换。

3.13 Q29｜为什么 Agent Platform 成熟度不能用“有没有 Memory / Multi-Agent / Computer Use”衡量？怎样做多维成熟度诊断？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

成熟度不是 Feature 数量，而是：

当前业务最关键的风险边界是否已经可靠。

不同 Domain 可以在不同维度处于不同成熟度。

2～3 分钟高分回答 ​

例如：

Ops Agent

可能非常成熟地拥有：

Identity
Approval
Audit
Runtime

但完全不需要 Memory。

Research Agent

可能：

Context / Source Eval

很强，但 Durable Runtime 很薄。

Coding Agent

可能：

Sandbox / Workspace / Runtime

很成熟，但仍然保持 Single Agent。

所以我会按维度诊断：

Harness
Context
Runtime
Execution
Identity / Security
Memory / Skill
Multi-Agent
Integration
Observability / Eval
Cost / Governance

每个维度分别看：

Basic
→ Productionized
→ Shared / Platformized

而不是强迫所有 Agent 走同一阶段模型。

高分亮点句 ​

成熟度不是用了多少高级 Feature，而是关键风险是否被正确治理。

面试官真正想听什么 ​

• 是否有架构成熟度判断；
• 是否会把 Feature Adoption 当 KPI；
• 是否理解不同 Domain 压力不同。

典型追问 ​

1. 哪些能力必须先成熟？
2. Multi-Agent 为什么不是高级阶段？
3. 怎么做平台成熟度 Review？

Red Flags ​

• “有 Multi-Agent / Memory 才算高级 Agent。”
• “所有团队按统一成熟度路线升级。”

为什么这样回答 / 本题套路 ​

这是架构诊断题。P8 候选人应该能判断什么时候不要升级，而不只是给出终局架构。

3.14 Q30｜为什么 Run 应该成为 Enterprise Agent Platform 的中心对象？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

企业真正要治理的不是一个 Agent 配置，而是：

一次任务到底用了什么版本、做了哪些动作、产生什么证据、花了多少资源、最后是否成功。

这些天然围绕 Run 聚合。

2～3 分钟高分回答 ​

Agent Definition 是配置对象，Run 才是生产对象。

它关联：

Session
Agent Version
Model / Prompt / Skill
Context Snapshot
Tool / Operation
Child Run
Artifact
Approval
Trace
Cost
Outcome

没有稳定 run_id：

• Trace 难关联；
• Eval 难回放；
• Cost 难归因；
• Child Agent 难挂父链；
• Incident 难恢复完整因果。

所以 Run Contract 是最值得尽早统一的 P0 Contract 之一。

为什么不是 Session、AgentDefinition 或 Trace 做中心对象 ​

Session
→ 可能包含多个任务，只能表达交互历史

AgentDefinition
→ 是配置，不代表一次真实执行

Trace
→ 是观察视角，不应该承担业务生命周期

只有 Run 同时具备：

stable identity
start / end
input / outcome
version manifest
cost
artifact
operation
child runs

因此它最适合作为平台里“执行事实”的根对象。

Run Contract 设计得差会怎样 ​

如果不同 Agent 对 Run 的含义不同：

• 一个把一轮对话算 Run； -一个把整个项目算 Run； -一个子 Agent 没有 Child Run；

那么跨 Agent Cost、Trace、Eval、Recovery 都无法统一。

所以平台早期应该先把 Run Granularity（运行粒度）定义清楚，而不是先做漂亮 Dashboard。

高分亮点句 ​

AgentDefinition 描述“系统能怎么工作”，Run 记录“这次到底发生了什么”。

面试官真正想听什么 ​

• 是否有平台中心对象模型；
• 是否把 Session / Agent / Run 混在一起。

典型追问 ​

1. Session 和 Run 什么关系？
2. 一个 Run 可以跨多个 Agent 吗？
3. Run 结束后保留多久？

Red Flags ​

• “平台核心对象是 Agent 配置表。”
• “Trace ID 就等于 Run ID。”

为什么这样回答 / 本题套路 ​

这是平台对象模型题。Run 是把 Runtime、Trace、Cost、Eval、Artifact 串成整体的关键主键。

3.15 Q31｜Model Gateway 为什么不只是多模型 API Proxy？模型路由应该考虑哪些约束？ ​

复习优先级：P2｜题型：S6 Engineering Implementation

30 秒核心回答 ​

真正的 Model Gateway 不只做 Provider URL 切换，还要基于：

Task / Risk / Context / Cost / Residency / Capability

做路由，并统一 Quota、Audit、Fallback 和 Version。

2～3 分钟高分回答 ​

路由维度至少包括：

task_type
reasoning_need
context_length
tool_use_capability
multimodal
latency_slo
cost_budget
data_residency
safety / policy
provider_health

比如简单分类走快模型，复杂 Coding 走强 Reasoning Model；受监管数据限定 Region / Provider。

但不是第一天就建 Gateway。真正 Trigger 通常是多 Provider、统一 Quota、Fallback、A/B、审计 / Residency 等问题开始跨团队重复。

高分亮点句 ​

Model Gateway 真正统一的是“模型选择与治理语义”，不是把所有 API 改成同一个 URL。

面试官真正想听什么 ​

• 是否理解模型平台；
• 是否会按约束路由；
• 是否有过度平台化克制。

典型追问 ​

1. Router 用规则还是模型？
2. Provider Silent Update 怎么治理？
3. Fallback 会不会改变行为？

Red Flags ​

• “Model Gateway 就是 Nginx + API Key。”

为什么这样回答 / 本题套路 ​

这是平台能力边界题。先讲路由约束，再讲何时值得平台化。

3.16 Q32｜Capability、Knowledge、Memory / Skill 都有 Control Plane，为什么不能合成一个 Mega Control Plane？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

它们可以共享 Identity、Version、Audit、Policy Framework，但不能统一生命周期和业务语义。

Capability → 能做什么
Knowledge → 什么是权威事实
Memory → 过去什么值得复用
Skill → 遇到某类任务怎么做

2～3 分钟高分回答 ​

Mega Control Plane 很诱人：

“反正都有 Registry / Metadata / Search / Version，一套系统解决。”

但它们的治理目标不同。

Capability 关心 Side Effect / Authorization / SLA；Knowledge 关心 Authority / Freshness / Lineage；Memory 关心 Scope / Correction / Forgetting；Skill 关心 Trigger / Eval / Release / Supply Chain。

更合理：

Shared Governance Primitives
+
Separate Semantic Control Planes

共享基础能力，不共享一个万能对象模型。

高分亮点句 ​

可复用的是治理 Primitive，不是把不同语义强行统一成一个对象。

面试官真正想听什么 ​

• 是否会 Mega Platform；
• 是否能区分共享基础设施和统一语义。

典型追问 ​

1. Registry 能否共用？
2. Search 能否共用？
3. Policy Engine 能否统一？

Red Flags ​

• “统一一张 metadata 表，type 字段区分就够了。”

为什么这样回答 / 本题套路 ​

这是架构克制题。高级平台设计难点往往是“哪些地方坚决不要统一”。

3.17 Q33｜Quota、Rate Limit、Admission Control、Fair Scheduling 有什么区别？为什么企业 Agent 平台四个都可能需要？ ​

复习优先级：P1｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

四者分别解决：

Quota → 一个主体总共能用多少
Rate Limit → 单位时间能发多少
Admission Control → 当前容量下这次任务能不能进入
Fair Scheduling → 多个主体竞争资源时谁先执行

2～3 分钟高分回答 ​

Tenant A 每天最多 1000 Runs 是 Quota；每秒最多 20 个 Model Call 是 Rate Limit；Sandbox 满了后新 Run 先排队是 Admission Control；A 有 1000 个任务、B 只有 10 个时，不能让 A 永远吃满 Worker，这是 Fair Scheduling。

Agent 还有递归 Fan-out：

Parent
→ N Child
→ Child 再 Fan-out

只做 Rate Limit 仍然可能把队列和 Waiting State 打爆。

高分亮点句 ​

Rate Limit 控流量，Admission 控容量，Quota 控份额，Fairness 控竞争。

面试官真正想听什么 ​

• 是否懂大规模资源治理；
• 是否只会 429。

典型追问 ​

1. Quota 按 User / Tenant / Agent 哪层？
2. 高优任务如何插队？
3. Cost Budget 和 Quota 什么关系？

Red Flags ​

• “统一做 Rate Limit 就够了。”

为什么这样回答 / 本题套路 ​

这是 Scale 题。四个概念表面相近，真正差异在治理目标。

3.18 Q34｜为什么 Trace、Eval、Cost 最好共享一套 Agent-native Telemetry？怎样从 Production Trace 形成 Release Gate？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

因为三者都需要回答：

同一次 Run 发生了什么、用了什么版本、最终结果怎样、花了多少资源。

如果各自一套数据模型，最后很难做可靠归因。

2～3 分钟高分回答 ​

统一事件至少关联：

run_id
span_id
parent_run_id
agent / model / prompt / skill / tool version
operation
artifact
latency
tokens / infra cost
outcome
error taxonomy

然后：

Production Trace
→ Failure Mining
→ Cluster / Label
→ Eval Case
→ Regression Suite
→ Release Gate
→ Canary
→ Production Trace

比如线上反复出现 Tool Selection Wrong，就把真实 Trace 变成 Tool Routing Regression Set。后续 Tool Search / Prompt / Model 变更都要过这组 Case。

高分亮点句 ​

Observability 解释过去，Evaluation 约束未来；它们应该通过同一批真实 Run 连成闭环。

面试官真正想听什么 ​

• 是否能把 Trace 与 Eval 连起来；
• 是否有 Continuous Release Gate；
• 是否能做 Cost Attribution。

典型追问 ​

1. Trace 数据太敏感怎么办？
2. Production Failure 如何自动聚类？
3. LLM Judge 结果也进入 Telemetry 吗？

Red Flags ​

• “Trace 给运维，Eval 给算法，两套系统各自建设。”

为什么这样回答 / 本题套路 ​

这是 Assurance 体系题。真正高分不只是“要 Trace 和 Eval”，而是解释两者怎样互相喂数据。

3.19 Q35｜中央 Gateway / Policy Service 挂了导致全公司 Agent 不可用，架构错在哪里？怎样避免 Governance 变成单点故障？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

集中治理不等于所有请求都必须同步依赖一个中央服务。

关键是区分：

Control Plane → 配置 / 发布 / 治理
Data Plane → 执行时快速、本地、可降级地 enforce

2～3 分钟高分回答 ​

如果每个 Tool Call 都同步依赖：

Central Policy Service
+
Central Gateway

中央系统一挂，全公司 Agent 全挂。

更稳：

Policy centrally authored
→ versioned distribution
→ local / regional enforcement

配合：

• Last-known-good Policy； -明确 Fail-open / Fail-closed； -多 Region； -Health-aware Routing； -数据面尽量减少中央状态依赖。

还要明确 Fail-open / Fail-closed 的业务语义 ​

不是所有 Policy Service 不可用时都做同样处理。

生产写 / 权限变更
→ Fail-closed

只读低风险查询
→ 可考虑 last-known-good policy

审计 / telemetry 暂时异常
→ 可能允许执行但打降级标记

这个决定必须提前写成 Policy，不应该在事故发生时临时拍脑袋。

怎么证明治理层没有成为新的可靠性短板 ​

关注：

policy decision availability
gateway added P95 latency
stale-policy rate
fail-open / fail-closed count
blast radius by region / tenant

平台治理本身也需要 SLO 和故障演练。

高分亮点句 ​

治理应该集中定义，不一定集中执行。

面试官真正想听什么 ​

• 是否有 Control / Data Plane 思维；
• 是否考虑平台 Blast Radius；
• 是否会把 Governance 变成 SPOF。

典型追问 ​

1. 哪些 Policy 必须 Fail-closed？
2. Cache Policy 过期怎么办？
3. Gateway Federation 怎么做？

Red Flags ​

• “统一治理，所以所有请求必须经过一个中央服务。”

为什么这样回答 / 本题套路 ​

这是平台反脆弱题。普通答案只讲集中治理，高级答案会继续问“集中以后故障半径有多大”。

3.20 Q36｜公司已有 30 个 Agent、5 个 Framework、200 个 Tool，怎样做 Brownfield Migration，而不是全部推倒重来？ ​

复习优先级：P2｜题型：S4 Architecture Evolution

30 秒核心回答 ​

我不会先统一 Framework。

先统一最值得统一、迁移收益最大的 Contract：

Run / Trace
Capability Metadata
Identity / Policy Hook
Artifact
Version / Cost

再通过 Adapter 渐进接入。

2～3 分钟高分回答 ​

第一步 Inventory：

Agent
Framework
Tool
Identity
Runtime
Execution
Trace
Owner
Risk

第二步定义 Target Contract：

• Run ID；
• Trace Event；
• Tool Contract；
• Identity；
• Artifact；
• Version Manifest。

第三步：

Existing Agent
→ Adapter
→ Shared Platform

而不是要求所有团队重写到同一个 SDK。

迁移优先高风险 / 高复用 / 高事故团队，同时保留 Escape Hatch，避免平台迁移阻塞业务。

迁移顺序也要有明确决策逻辑 ​

我不会按团队排队，而会优先：

Risk × Reuse × Incident Frequency × Migration Feasibility

比如：

• 高权限 Agent； -重复 Tool 最多的团队； -Trace 缺失导致 Debug 最痛的系统；

更值得先迁。

迁移成功的标准不是“全部接入” ​

我会允许一段较长时间：

old path
+
adapter path
+
native platform path

并记录：

migration coverage
adapter error rate
platform bypass rate
time-to-onboard
incident delta

当 Adapter 长期成为主要路径且没有迁移收益时，也要反思 Target Contract 是否真的合理，而不是把“业务不愿迁”归咎于业务团队。

高分亮点句 ​

Brownfield Platform 的第一目标不是统一代码，而是统一可治理语义。

面试官真正想听什么 ​

• 是否有遗留系统迁移能力；
• 是否会大爆炸重构；
• 是否理解 Contract-first Migration。

典型追问 ​

1. 旧 Agent 没 Run ID 怎么办？
2. Framework 差异很大怎么接？
3. 迁移 ROI 怎么证明？

Red Flags ​

• “先统一到一个 Framework，再接平台。”

为什么这样回答 / 本题套路 ​

这是 P8 很重要的落地题。企业几乎永远是 Brownfield，不是 Greenfield 架构图。

3.21 Q37｜Agent Platform 和 Agent Framework 有什么区别？为什么“统一 Framework”通常不是平台化的正确起点？ ​

复习优先级：P2｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

Framework 主要是：

开发一个 Agent 的编程抽象。

Platform 主要是：

让多个 Agent 在共享的运行、执行、安全、观测、评测和治理基础上持续生产。

所以企业可以允许多个 Framework，同时统一 Platform Contract。

2～3 分钟高分回答 ​

Framework 通常提供：

Agent class
Tool abstraction
Context / Memory helper
Workflow / Orchestration API

Platform 负责的更像：

Run
Identity / Policy
Runtime
Execution
Capability Registry
Artifact
Trace / Eval
Cost
Release

为什么不应该先统一 Framework？

因为 Framework 演进快，而且不同 Domain 可能适合不同编程模型。

企业真正不希望重复的是：

• 每个团队各自做身份； -各自做 Trace； -各自做 Sandbox； -各自做 Runtime； -各自定义 Tool Contract。

所以更稳：

Multiple Frameworks
→ Adapters
→ Shared Platform Contracts

高分亮点句 ​

Framework 统一代码写法，Platform 统一生产保证；企业更应该优先统一后者。

面试官真正想听什么 ​

• 是否把平台等同 Framework；
• 是否有技术生态演进判断；
• 是否能容纳多 Framework。

典型追问 ​

1. Framework 太多不会增加维护成本吗？
2. 什么 Contract 最先统一？
3. Platform SDK 会不会又变成 Framework？

Red Flags ​

• “平台化第一步是规定所有团队使用同一个 Agent Framework。”

为什么这样回答 / 本题套路 ​

这是平台根定义题。高级平台的稳定性来自 Contract，而不是押注某一个快速变化的开发框架。

3.22 Q38｜Control Plane、Runtime / Execution Plane、Assurance Plane 分别负责什么？为什么 Assurance 不应该只是旁路日志？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

我会分成：

Control Plane
→ 配置 / 版本 / Policy / Registry / Release

Runtime / Execution Plane
→ Run 真正如何调度、恢复和执行

Assurance Plane
→ Trace / Eval / Security / Cost / Audit / Release Gate

Assurance 必须参与发布和运行决策，而不是只做观察。

2～3 分钟高分回答 ​

Control Plane

回答：

系统应该怎样运行？

包括 Agent Definition、Tool Registry、Policy、Version、Experiment。

Runtime / Execution Plane

回答：

这次 Run 实际怎样活着、怎样改变现实？

包括 Checkpoint、Scheduling、Sandbox、Tool、Artifact。

Assurance Plane

回答：

这套系统值不值得信任和继续发布？

包括：

Trace
Evaluation
Security Signal
Cost
Audit
Release Gate
Incident Feedback

如果 Assurance 只是 Dashboard：

Eval 发现回归，但 Release 仍然照常发布。

那它不是真正的生产保障面。

所以成熟平台会把：

Eval / Security / Cost Threshold
→ Release Gate / Runtime Policy

反馈回 Control / Runtime。

高分亮点句 ​

Observability 只有在能改变发布和运行决策时，才真正进入 Assurance，而不只是“可视化”。

面试官真正想听什么 ​

• 是否理解平台三平面；
• 是否把观测评测当旁路；
• 是否能形成闭环治理。

典型追问 ​

1. Eval 属于 Control Plane 还是 Assurance Plane？
2. Runtime Policy 如何消费 Assurance Signal？
3. Cost Budget 能不能阻止 Run？

Red Flags ​

• “Trace / Eval 是离线分析，不影响在线系统。”

为什么这样回答 / 本题套路 ​

这是平台总装题。重点不是画三层，而是说明 Assurance 怎样反向约束 Release / Runtime。

3.23 Enterprise Platform 阶段性总结 ​

只记六句话：

1. 平台不是目标，是重复问题稳定以后的一种组织方式。
2. Platform owns Guarantees；Domain owns Meaning。
3. Shared Core 应该薄，变化快的能力做成 Replaceable Capability。
4. Identity / Run / Trace / Tool Contract 等稳定语义越晚统一，迁移越贵。
5. Build vs Buy 的关键是 Semantic Control，而不是自研比例。
6. 平台 ROI 看重复复杂度、事故、交付效率和治理，不看 Agent 数量。

四、把 Protocol 与 Platform 真正连起来 ​

4.1 Protocol 什么时候会上升成平台问题 ​

最开始：

Agent A
→ 直接调用 3 个 Tool

不需要 Registry / Gateway。

后来：

20 个 Agent
×
200 个 Tool
×
多个 Team / Vendor

就开始需要：

Capability Registry
Identity
Policy
Version
Gateway
Trace
Cost

这时 Protocol 才从“SDK 接入”上升成 Integration Platform。

4.2 平台不应该绑死一个协议 ​

企业应该统一：

Capability Contract
Identity
Policy
Trace
Artifact
Version

Protocol Adapter 可以是：

REST
MCP
A2A
Internal RPC

这样未来协议变化时，企业核心治理语义不被带着重写。

4.3 一个完整企业调用链 ​

User
→ Main Agent

Capability Discovery
→ Registry

选择 Remote Specialist
→ A2A

Specialist 内部发现 Tool
→ MCP

Gateway
→ Auth / Policy / Quota

Execution
→ Enterprise API / DB

Artifact / Evidence
→ Remote Agent

A2A Result
→ Main Agent

Trace / Eval / Cost
→ Shared Platform

这条链最重要的不是协议名字，而是：

Identity、Authorization、Version、Evidence、Ownership 是否端到端连续。

五、P7+～P8 面试里怎样讲好这一篇 ​

5.1 Protocol 题不要背规范 ​

低质量：

“MCP 有 Tools、Resources、Prompts……”

高质量：

“我先看边界。如果对端是普通业务服务，REST 更自然；如果 Agent 需要动态发现 Tool，MCP 有价值；如果对端是独立 Agent Service，需要任务 / Artifact 语义，A2A 更合适。”

5.2 Platform 题不要堆 Feature ​

低质量：

Runtime
Memory
Sandbox
Multi-Agent
Gateway
Eval

高质量：

现在哪些问题重复发生？
↓
什么 Contract 已稳定？
↓
统一后收益是什么？
↓
复杂度被转移到哪里？
↓
怎么证明平台值得？

5.3 最值得准备的三个真实故事 ​

故事 A：Integration 演进 ​

点对点 API
→ Tool / Agent 增长
→ Registry / Gateway / Protocol

故事 B：平台抽象 ​

多个 Agent 重复 Runtime / Trace / Identity
→ 哪些抽成 Shared Core
→ 哪些留在 Domain

故事 C：平台 ROI ​

接平台前
→ 重复代码 / Incident / 上线周期

接平台后
→ 用指标证明改善

六、本篇 2～3 分钟总复述 ​

如果面试官问：

“你怎么看 MCP、A2A 和 Enterprise Agent Platform？”

可以这样回答：

“我会先把 Protocol 和 Integration 分开。MCP 主要解决 Agent 或应用怎样标准化发现和调用 Tool / Context；A2A 更适合独立 Agent Service 之间发现、任务和 Artifact 交互。但协议只负责稳定互操作契约，身份、授权、版本、Retry、SLA、Owner 和 Audit 仍然是企业 Integration 的责任。

当 Agent / Tool / Team 数量增长以后，这些重复问题会自然把 Registry、Gateway、Identity、Policy、Trace、Version 上移成平台能力。平台也不应该第一天就设计出来，而应该从高价值 Domain Agent 的重复问题里抽稳定 Contract。

我对企业平台最核心的判断是 Platform owns Guarantees，Domain owns Meaning。平台负责 Run、Runtime、Execution Boundary、Identity、Trace、Eval 等稳定保证；Domain 继续拥有业务语义、Tool、Metric、Verification。Build vs Buy 也不是看是否核心，而是企业是否保留 Semantic Control——Contract、Policy、Trace、Eval 和迁移能力。

所以最终目标不是支持最多协议或最多 Agent，而是让多个 Domain Agent 在共享的安全、运行、执行和治理基础上，以可控成本持续交付可验证结果。”

七、业界实现证据与边界 ​

• [R1] MCP 2026-07-28 Specification：MCP 当前规范升级为 Stateless Core，取消旧式协议 Session / Handshake，引入 server/discover、header-based routing、cacheable list results、authorization hardening 与 extension framework。
  https://blog.modelcontextprotocol.io/posts/2026-07-28/

• [R2] A2A Protocol 1.0 Specification：当前最新发布版本为 1.0.0，目标是让独立、潜在不透明的 Agent 系统跨框架 / Vendor 发现能力、管理协作任务并交换信息 / Artifact。
  https://a2a-protocol.org/dev/specification/

• [R3] Amazon Bedrock AgentCore Gateway：当前支持 MCP 2026-07-28 / 2025-11-25 等版本，并使用 MCP 作为 Tool Discovery / Invocation 入口。
  https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using.html

• [R4] Microsoft Agent Framework — A2A Agent Service：支持 Agent Card Discovery、Streaming、Background Responses，并可把 Remote A2A Agent 包装为统一 Agent / Tool 接口。
  https://learn.microsoft.com/en-us/agent-framework/agents/providers/agent-to-agent

• [R5] Amazon Bedrock AgentCore Identity：把 Agent Identity 建模成 Workload Identity，并管理 Agent / Tool 访问 AWS 与第三方服务时的 Credential。
  https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html

• [R6] Amazon Bedrock AgentCore Gateway Authorization：明确区分 Inbound Authorization 与 Gateway Target 的 Outbound Authorization。
  https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using-auth.html

• [R7] OpenAI Agents SDK — MCP / Tools：支持 Hosted MCP、Streamable HTTP、stdio MCP，并明确提醒只连接可信 MCP Server、使用最小权限 Credential，对敏感操作要求 Approval。
  https://openai.github.io/openai-agents-python/mcp/
  https://openai.github.io/openai-agents-python/tools/

• [R8] AG-UI — Events / State Management：使用 typed event 连接 Agent Backend 与 Frontend，并通过 Snapshot / Delta 模式同步 State、Messages、Activity 与 Run Lifecycle。
  https://docs.ag-ui.com/concepts/events
  https://docs.ag-ui.com/concepts/state

• [R9] Agent Client Protocol / Zed ACP：面向 Coding Agent 与 Editor / IDE 的互操作；当前 Zed 生态已经通过 ACP Registry 连接多种 Agent 与多个编辑器。
  https://agentclientprotocol.com/get-started/introduction
  https://zed.dev/acp
  https://zed.dev/blog/acp-registry

业界产品会变化，真正应掌握的稳定机制是：

text

Boundary
Discovery
Identity
Authorization
Contract
Version
Task Lifetime
Gateway
Ownership
Stable Platform Invariant
Semantic Control
ROI

八、本篇最终记忆锚点 ​

如果只记 16 句话：

1. Protocol ≠ Integration。
2. MCP 更偏 Agent ↔ Tool / Context；A2A 更偏 Agent ↔ Independent Agent。
3. Discovery ≠ Authorization ≠ Execution。
4. Signature ≠ Trust ≠ Authorization。
5. Task Lifetime ≠ Transport Connection Lifetime。
6. Schema Compatibility ≠ Semantic Compatibility。
7. Gateway 应该在集成治理问题开始重复时出现。
8. Capability Registry ≠ Model-visible Tools。
9. 平台不是目标，是重复问题稳定后的组织方式。
10. Platform owns Guarantees；Domain owns Meaning。
11. Shared Core 应该薄，能力默认可替换。
12. Build vs Buy 的关键是 Semantic Control。
13. Scale 会把隐式约束逼成显式平台能力。
14. 平台 ROI 看复杂度消除、生产质量和治理，不看 Agent 数量。
15. 协议按系统边界选择：Tool、Agent、UI、IDE 不是一个问题。
16. 平台成熟度看关键风险边界，不看 Feature 数量。

九、本篇最容易拉开候选人差距的专家判断 ​

1. **Protocol ≠ Integration。**协议降低接口耦合，但 IAM、Version、Retry、SLA、Ownership 仍然存在。
2. **Discovery 可以缓存，Authorization 必须在执行时重新成立。**这是 Capability Cache 最危险的隐藏 Failure Window。
3. Remote Agent Timeout 首先是 Task Identity / Unknown Outcome 问题，不是 HTTP Retry 问题。
4. Protocol Translation 最大风险不是 JSON 映射失败，而是语义悄悄丢失。
5. Gateway 可以集中治理定义，但不应该把全公司的 Data Plane 变成单点故障。
6. **Platform owns Guarantees；Domain owns Meaning。**这比“平台做什么功能”更稳定。
7. Build vs Buy 要保留 Semantic Control：Contract、Policy、Trace、Eval 和迁移权。
8. 企业几乎永远是 Brownfield；优秀平台先统一可治理语义，不先统一 Framework。
9. Platform ROI 看复杂度消除和 Verified Outcome，不看接入 Agent 数。