Agent 正在改变接口的设计对象
过去多年，软件系统的设计围绕 API 展开：暴露 REST 端点、定义 gRPC 契约、实现业务服务、建立集成模式，再由应用消费这些能力。API 优先支撑了分布式系统、微服务、平台工程和生态集成。但在 Dev.to 一篇讨论软件架构演进的文章中，作者提出了一个新的问题：现有应用是否已经准备好被 AI Agent 消费，还是每新增一个 AI 用例，都要再写一套定制集成？
变化来自 Agent 的角色。AI 不再只是被集成到应用里的一个功能。随着 Agent 出现，应用需要理解上下文、发现能力、与外部系统交互并执行业务任务。传统 API 仍然有效，但当消费者从“预定义集成需求的应用”变成“需要自主理解能力的 Agent”时，仅有接口并不足够。
文章的核心判断是：架构不需要放弃 API 优先，而应向其扩展，逐步走向 AI 原生优先。真正要补的，不是另一套业务系统，而是让 AI 能够理解、发现并安全调用既有业务能力的接口层。
双接口架构：同一业务能力，两种消费方式
作者提出了“双接口架构”的思路。每一项业务能力都应围绕领域职责设计，并同时服务两类消费者：传统应用继续使用 REST、gRPC 或消息接口；AI Agent 则通过标准化方式发现和调用能力。两种接口复用同一套底层业务能力，而不是重新实现业务逻辑。
在这一结构中，MCP Server 被定位为集成适配器。它建立在现有应用能力之上，负责向 AI 应用暴露工具、资源和提示模板，但不承担业务规则。原有 REST 与 gRPC 接口继续服务既有调用方，业务服务继续负责领域规则、授权和事务一致性。
文章提到，Model Context Protocol（MCP）为 AI 应用与外部工具、数据源交互提供了标准化方式。其服务端包含三类构建模块：
- Tools：允许 AI 应用调用操作。
- Resources：向 AI 应用提供可获取的上下文信息。
- Prompts：为特定任务或工作流提供可复用的提示模板。
MCP 并不替代 REST 或 gRPC，而是为 AI 应用增加一种新的交互协议。
不要把每个 REST 端点都变成 MCP 工具
文章特别提醒，不建议把每一个 REST 端点或 gRPC 方法都直接包装成 MCP 工具。低层 CRUD 接口即使暴露出来，也不等于 Agent 能理解业务。更好的做法是按业务能力组织接口，让 MCP 工具表达业务意图、所需输入、预期输出和适用约束。
文中给出的例子是：用户向 AI 助手提出“查找我最近的订单，并为已损坏的商品发起替换”。这类请求不会对应单一接口，而需要多个能力协同。Agent 通过 MCP 发现并调用所需工具，MCP Server 验证请求并调用对应业务服务；业务服务继续执行领域规则、授权和事务一致性。
这里的关键边界是：Agent 不直接访问数据库，也不实现业务规则。它做的是编排既有业务能力。文章强调，AI 应该编排业务能力，而不应成为业务规则或事务完整性的拥有者。
AI 原生优先需要补齐描述、发现与动态编排
如果只把 MCP 端点暴露出去，仍然只是开始。文章提出了几个设计原则。首先，围绕业务能力而非技术操作设计接口。能力应有明确契约和清晰职责，底层实现可以继续使用领域服务、REST API、gRPC 或内部应用服务。
其次，契约需要比传统 API 更丰富。普通 API 契约通常描述请求和响应结构，但 Agent 还需要知道能力的用途、输入要求、限制条件等信息。以 initiate_refund 为例，Agent 需要理解这个能力何时适用、需要哪些输入、有哪些约束。描述、schema、业务文档、领域上下文和操作约束会变得更重要。工具描述不充分，会影响 Agent 的决策质量。
第三，工作流组织方式也会变化。传统工作流通常是预定义的操作序列，而 Agent 带来了根据上下文动态选择和组合能力的可能。例如客户支持类工作流，可能不再完全依赖固定流程，而是由 Agent 根据当前状态调用不同能力。
这篇讨论的价值在于，它没有把 AI 原生架构理解为推倒重来，而是把问题落回工程现实：企业已有大量 API 和业务服务，真正需要补的是面向 Agent 的能力发现层、语义描述层和工具调用规范。当 Agent 成为新的调用方，接口设计的目标不再只是让程序能调通，而是让模型能理解业务边界，并在受控范围内执行任务。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/rang-ye-wu-xi-tong-neng-bei-agent-diao-yong-ruan-jian-jia
