（图片由kreaAI生成）

AI agent 正在重塑开发者的工作方式，并推动软件架构和通信方式向更高效的自动化方向发展。

以Agent为中心的应用

agent-centric应用正在成为一种新的发展趋势。在这种模式下，由 LLM 等技术驱动的 agent 正在取代人类，成为服务和应用的主要使用者。这种转变需要从根本上重新思考产品的构建方式以及如何定义良好的用户体验。

近年来，agent-centric应用的数量大幅增长，开发者越来越多地使用 LLM 来创造全新的交互体验。现在，开发者不仅要关注为人类构建服务，优化开发者体验（DX），还需要专门为 agent 构建体验。

Agent体验（AX）这一概念正在成为 SaaS 供应商的一个关键考量因素。其核心是让产品更容易被 agent 使用。这与开发者体验类似，但更侧重于 agent 的需求。例如，注册流程可能需要重新设计，因为 agent 无法像人类那样等待长达数天的人工审核流程。

agent-centric应用的核心理念是，从以人为主的操作方式，转变为 agent 执行大部分操作。这意味着，许多目前由人类执行或发起的任务（如构建数据库、发送邮件、与应用交互等）未来将更多地由 agent 完成。

开发agent-centric 应用的方式不是从零开始，而是充分利用现有的 API、SDK 和协议。但在为 agent 设计系统时，仍需考虑一些根本性的差异和限制。agent的内容消费方式与人类不同。例如，LLM 解析纯文本比 HTML 更高效且成本更低。因此，面向 agent 的应用应该优先提供易于解析的数据格式。在电子邮件场景下，虽然人类更喜欢视觉上美观的 HTML 邮件，但对于需要解析并执行操作的 agent 来说，纯文本版本的邮件更加重要。

agent-centric应用通常涉及多个服务的集成，以执行多步工作流。例如，MCP（尽管在信息来源中未完全定义）似乎是一种新兴标准，旨在促进不同 AI 模型和服务之间的通信和交互，使 agent 能够执行复杂任务。例如，一个 agent 可以从某个服务（如 Linear、Notion）获取数据，并使用这些数据在另一个服务中草拟并发送电子邮件。

构建agent-centric 应用需要从用户的起点（如注册和入门）进行彻底的重新思考。需要尽可能减少“阻力”，使 agent 能够快速执行任务。此外，角色访问控制、权限管理和身份验证等方面也需要针对 agent 进行调整。同时，监控 agent 的活动对于调试和理解其行为至关重要。

agent-centric应用代表着软件开发的一次重大演变，在这种模式下，AI agent 成为应用的主要用户，其需求和特性直接影响产品的设计与功能。这一转变将影响从用户体验到底层基础设施和数据格式的各个方面。

Agent体验（AX）

Agent体验（AX）是一个新兴概念，旨在使产品和服务更易于 AI agent 使用和交互。随着 agent-centric 应用的崛起，AI agent 正在成为主要的操作主体，因此 AX 逐渐成为一个重要的关注点。

就像多年来开发者体验（DX）一直是SaaS 供应商的核心关注点一样，如今 AX 也正成为产品和服务设计中的关键考量。供应商开始思考如何让他们的服务更易于 AI agent 访问和使用。

优化AX 需要对既有的行业惯例进行调整。例如，传统的验证码机制用于防止机器人注册，但在 agent 为主导的环境中，拦截 bot（可能是合法的 agent）可能并不合理。同样，一些服务中常见的人工账户审核流程可能需要数天时间，这对于需要即时操作的 agent 来说是不可接受的。

与DX 旨在减少人类开发者的操作阻力类似，AX 也关注如何让 agent 轻松完成任务。

AX和 DX 之间的确切关系仍在探索中。目前尚不清楚 AX 是否只是 DX 的一个针对 agent 的变体，或者是 DX 的一个子集，亦或是一个独立但相关的概念。一种观点认为，AX 可能是对 DX 的补充，例如，为人类开发者提供更好的文档不仅能帮助他们，同时也能让 agent 更容易解析和使用相关服务。

AX 的核心原则是将 agent 视为“一级公民”。这需要从根本上重新评估产品的设计和运营方式，以适应 agent 作为主要用户的环境。

要优化 AX，需要重新审视产品的各个层面，例如：

· 注册和入门流程（onboarding），确保agent 能快速上手。

· 用户真正理解产品价值的瞬间，需要适配 agent 的需求。

· 基于角色的访问控制（RBAC）和权限管理，确保agent 能够在安全前提下执行任务。

· 活动日志监控，便于理解和调试agent 的行为。

在之前的agent-centric 应用讨论中，提到了这种新兴趋势如何推动针对 agent 的体验优化。AX 直接回应了这一需求，专注于 AI agent 与软件和服务交互时的特殊需求和限制。尽管 AX 目前尚无统一的定义，但越来越多的开发者和服务提供商正在关注如何让他们的产品更加“Agent 友好”。

MCP的采用

MCP（Machine Communication Protocol，机器通信协议）在AI agent 与服务的交互中正成为一个重要且不断演进的话题。

MCP被认为是 agent 开发者正在探索的一种新兴标准。尽管目前尚未完全普及，但它正在 AI 开发社区中获得越来越多的关注和认可。

MCP是否能被更广泛的 AI 模型采用，是其能否大规模普及的决定性因素。如果像OpenAI 这样的主要 AI 模型提供商决定采用 MCP，它可能会成为 AI agent 之间通信和交互的事实标准（de facto protocol），从而提升各 agent 之间的互操作性，推动形成更统一的 AI 生态系统。

API 供应商们正在考虑支持 MCP，以便让其他 agent 轻松集成到他们的服务中。例如，MCP 可以使 agent 通过标准化协议执行发送邮件、管理联系人列表、分析邮件数据等操作。

目前已有一些初步的尝试来构建MCP 生态，包括建立 MCP 服务器的“应用商店”或“市场”（类似于 API 市场）。这一趋势表明 MCP 可能会沿着 API 经济的发展路径，形成一个集中式的发现和使用平台。

由于技术挑战（如Server-Sent Events，SSE 的实现），大多数现有的 MCP 实现仍然是“本地优先”（local-first）的。这意味着 MCP 客户端通常在本地执行命令，然后再与第三方 API 交互。

目前MCP 主要应用于特定环境（如 Cursor 和 Cloud Desktop），如果能扩展到更广泛的消费者应用层，可能会带来革命性的变化。

MCP 的核心价值在于简化不同 AI 模型和服务之间的集成，使其能够实现更复杂的自动化工作流。例如，Stripe 团队在构建 MCP 服务器时，选择先专注于解决常见的应用场景，而不是一开始就支持整个 API 生态。这种务实的策略有助于 MCP 先在关键用例中落地，然后逐步推广。

在讨论中，某些关键数据系统（如Linear 的任务管理、Gmail 的邮件存储、Notion/Apple Notes 的笔记数据）被认为是 MCP 生态中的核心部分。这些系统本身存储着大量重要信息，因此 agent 可以利用这些数据，通过 MCP 执行各种任务。

尽管MCP 被视为 AI agent 之间通信的一个有前景的标准，但其广泛采用仍然依赖于主流 AI 模型厂商的支持以及更成熟的生态系统建设。要推动其发展，还需要解决当前的技术限制，并拓展 MCP 的适用场景，特别是在本地环境之外的应用。此外，API 供应商通过专注于实际用例（而非全面 API 兼容性）来推动 MCP 采用，也可能成为其普及的关键因素。

来源|A16z

总结|Notebooklm

翻译|ChatGPT

排版|Heisenberg

更多相关内容请阅读⬇️

1. AI + MCP > AI + API

2. 构建有效的AI Agents

更多「Heisěnberg」精彩内容，欢迎点击「阅读原文」

MCP 协议与 Agent 体验（AX）：软件开发的新范式