MCP（Model Context Protocol）正迅速成为企业智能体架构的默认答案——访问数据用MCP，调用API用MCP，智能体之间通信也用MCP。但MCP只标准化了一个边界：AI应用与能力之间的连接。它不决定哪个数据源是权威的，不保留业务事务，不处理审批流程，也不验证智能体是否正确执行。一个企业级的智能体平台必须处理至少七个独立的边界，代理到工具只是其中之一。
过去18个月内，四个主流厂商推出了四个开放协议，针对不同问题：
• MCP（Anthropic，2024年11月开源）— 基于JSON-RPC，定义AI客户端如何发现和调用工具。已被Claude、Cursor、VS Code及数十个智能体框架采用。适合多个AI客户端共享同一能力接口。
• A2A（Google，2025年4月发布，2026年1月v1.0）— 标准化相互独立运行的智能体之间的工作委托。现由Linux基金会治理。适合“去调查这个供应商并生成报告”这类跨组织协作。
• AG-UI（CopilotKit，2025年开源）— 标准化智能体后端与前端的流式连接。适合实时状态、交互式UI、超出聊天范围的人机协同。
• AgentCore（AWS，2025年）— 为智能体提供托管基础设施，涵盖身份、能力网关和运行时。适用于AWS环境中的凭据管理、工作负载身份和网关路由。
全都开源，但各自解决不同问题，单独任何一个都不足以构成生产级企业平台。
七个边界：
边界 | 技术 | 解决的问题
智能体 → 工具 | MCP、function calling | 发现并调用有界能力
智能体 → 业务服务 | REST、gRPC、GraphQL | 利用现有保证进行确定性领域操作
智能体 → 智能体 | A2A | 将目标委托给独立运行的智能体
智能体 → 用户 | AG-UI、A2UI、MCP Apps | 流式状态、渲染交互体验
服务 → 服务 | API、事件、队列 | 可靠的系统集成（已解决）
智能体 → 持久化流程 | 工作流引擎 | 持久性、重试、审批、补偿
身份 → 资源 | OAuth、OIDC、IAM | 建立并强制授权
将这些边界放在一起，组成六个平面：体验层（聊天/IDE/门户）、智能体运行时（模型/状态/规划）、能力层（注册表/网关/MCP）、企业上下文（数据产品/搜索/记忆）、执行层（工作流/队列/沙箱/审批）、记录系统（ERP/CRM/数据库）。横切关注点包括身份、授权、策略、密钥、审计、可观测性、评估、成本和生命周期。
随着模型能力提升，硬编码的路由将减少，模型会动态组装执行路径。但这不会消除对身份、授权、事务、持久状态、审计和评估的需求——更强的智能体能尝试更多操作，控制层反而更重要。趋势是：更少的自定义编排，更强的能力和信任基础设施。
下周一可以做的事：映射你平台中的七个边界；找出哪些地方在用MCP替代工作流引擎；识别模型中本应由确定性系统做决策的环节；端到端构建一个可追踪的例子，从体验层到记录系统走通，发现信任假设的缺口。模型越强，受治理的企业层就越厚，这正是平台投入的方向。
@DevToolboxHub