API、CLI、A2A、MCP、GUI、LUI 摆在一起，很容易被排成一条 AI 时代的进化线。API 和 GUI 像旧世界，LUI、MCP、A2A 像新世界。这个排法省事，却回答不了最重要的问题。一套系统接了大模型、加了聊天框，甚至暴露了 MCP Server，仍然可能只是一套带 AI 功能的传统应用。
我重新核对了 MCP、A2A、Google Cloud 的 Agent 架构和 Microsoft 的生成式 AI 可观测资料。AI 原生目前没有统一认证标准，下面这条分界线是基于这些材料作出的归纳。模型是否进入了核心执行循环，参与理解目标、规划步骤、选择工具、判断结果和决定下一步。
把模型拿走以后，核心流程照常运行，只少了摘要、推荐或文案，这叫 AI 增强更准确。拿走模型以后，用户的目标无法被理解，任务也无法继续拆解和执行，系统才有明显的 AI 原生特征。
接口名称说明不了模型的位置
API 是通用机器接口。模型推理 API、Embedding API 和 Agent API 服务于 AI，但调用它们的应用未必 AI 原生。一个工单系统调用模型生成摘要，原有流转逻辑没有变化，它仍是传统应用。若模型负责理解工单、查询资料、选择处理工具并根据结果调整计划，API 才进入 AI 原生执行循环。
CLI 和 GUI 也没有过时。CLI 可以是确定性命令，也可以让 Agent 读取日志、规划诊断、调用只读工具并等待写操作批准。GUI 可以显示任务计划、证据、工具调用、差异和确认点。AI 原生系统仍需要这两种界面，因为语言适合表达目标，图形和命令适合呈现精确状态。
LUI 更接近 AI 原生的人机入口。用户说出目标，系统负责追问约束并组织行动。不过，规则引擎和传统 NLP 也能做自然语言界面。只有当模型能根据上下文规划多步工作、调用工具、读取反馈并修正方向，LUI 才真正连到 AI 原生内核。
MCP 与 A2A 属于 AI 原生协议
MCP 连接 AI 应用与工具、资源和提示。模型可以发现工具的名称与输入模式，再根据当前任务选择调用。当前 `2026-07-28` 规范将核心请求做成无状态形式，长任务则进入可选扩展。它很适合把现有数据库查询、工单操作、浏览器能力和业务 API 交给 Agent 使用。
A2A 连接独立 Agent。Agent Card 描述能力、端点和安全要求，Task 表示有状态工作，Artifact 承载交付物。A2A v1.0 正式定义 JSON-RPC、gRPC、HTTP+JSON 三种绑定，适合跨团队、跨产品委派长任务，并查询进度、补充输入或取消工作。
这两种协议可以称为 AI 原生接口，因为它们直接服务模型与 Agent 的工作方式。接入协议仍然不等于应用已经 AI 原生。一个 MCP Server 只把旧 API 换个模式暴露出来，上层仍由固定规则调用，系统只是增加了 AI 兼容入口。
旧系统要先让模型安全地参与工作
第一步先画出当前业务动作。查询、修改、审批、支付、发布、删除分别由谁发起，依赖哪些数据，失败怎样恢复。把只有页面点击或脚本拼接才能完成的能力补成稳定 API。AI 原生不会消灭确定性服务，账务、库存、权限和不可逆操作仍要由它们守住。
第二步从只读 Copilot 开始。让模型做搜索、解释、归纳和候选计划，暂时不执行写操作。团队同时建立任务样本和评估指标，检查意图理解、工具选择、参数填写、事实准确性、延迟和成本。生成式 AI 的输出会变化，只跑传统单元测试不够。
第三步把成熟的业务 API 包成工具。工具要有清楚的输入模式、最小权限、超时、幂等和审计。工具数量少时，原生 function calling 已经够用。工具需要被多个 Agent 和客户端发现时，再引入 MCP。协议应当解决复用问题，不能拿来掩盖混乱的业务接口。
这里需要划开概率性决策层与确定性执行层。模型可以判断该查哪份资料、该调用哪个工具、结果是否足以继续。业务服务负责校验账户、权限、金额、库存与事务。模型输出的是候选行动，服务端接收的是结构化参数。参数不合法就明确拒绝，不能让模型用一段解释绕过规则。
第四步才是 Agent 化。模型根据目标拆任务，调用工具，读取结果，再决定继续、改计划或请人介入。每次运行都要有任务标识、状态、轨迹、中间产物和取消能力。只有跨组织或跨产品的独立 Agent 需要互相发现与委派时，A2A 才开始产生价值。一个应用内部的固定模块调用，没有必要包装成 Agent 社交。
Agent 还需要上下文，却不能把所有历史一股脑交给模型。会话状态、用户偏好、企业知识和长期记忆应当分开管理，分别设置来源、权限、保存期限和删除方式。工具返回的数据也要标记来源，避免下一次运行把旧结果当成当前事实。记忆越长，权限泄漏和错误累积的代价越高。
第五步把 LUI、GUI 和 CLI 合起来。LUI 接收开放目标，GUI 展示计划、证据与变更差异，CLI 提供精确执行和自动化入口。高风险动作停在明确的确认点。Google Cloud 的参考架构也把人工监督、有限自治和可观测性放在生产 Agent 的核心位置。
发布流程也要变化。传统接口测试继续验证工具和业务服务，AI 评估则覆盖意图理解、计划质量、工具选择、参数正确性、事实依据与拒绝行为。团队应当保存一组真实任务，模型、提示、工具说明或路由策略变化后重新运行。线上还要看任务完成率、人工接管率、工具失败率、耗时和成本。没有这套评估，模型更新一次就可能让原本可用的流程悄悄变差。
AI Gateway 可以统一模型凭据、路由、配额、成本与审计，Agent Gateway 可以治理 MCP 和 A2A 流量。网关看得见调用，却不能替业务服务完成最终授权。模型选择了转账工具，账户权限、金额限制和事务一致性仍由支付服务决定。
我的判断只建立在公开规范和参考架构上，没有替某套现存系统做过评估。真正的改造优先级可以从三个问题开始。哪些工作必须靠人跨多个系统拼起来，哪些判断需要大量上下文，哪些结果允许先建议后确认。三者交集最大的地方，通常最适合先做 AI 原生改造。
参考资料
