让不同的软件系统相互对话是开发人员面临的一个典型挑战。多年来，我们一直使用具有明确规则的应用程序接口来实现这一目标。但现在，大型语言模型（LLM）正在改变游戏规则，为系统在理解语言而不仅仅是严格格式的基础上进行交互提供了一种新方法。这开辟了令人兴奋的可能性，但也带来了一系列需要解决的新问题--再次证明开发人员的工作永远不会真正完成！
让我们来探讨一下这对开发人员意味着什么。
我们过去是如何连接系统的？传统的应用程序接口
想想我们通常是如何连接系统的。我们使用
- REST API：API 通常使用 JSON，也可能使用 OpenAPI（Swagger）规范，API 明确说明了进出系统的数据，包括数据类型（如字符串或数字）。
- RPC（远程过程调用）：gRPC 等工具可让系统通过协议缓冲区等方式相互调用函数，以准确定义函数的需求和返回。
- SOAP/WSDL：这是一种较老的方法，但也依赖于对服务的详细描述（WSDL）。
- 消息队列（如 Kafka、RabbitMQ）：这些系统通常按照约定的特定格式来回发送消息。
关键在于这些方法依赖于明确的规则和格式。机器会检查数据是否符合预定义的结构（模式或类型定义）。开发人员阅读文档，了解应用程序接口的作用，然后编写代码，按照需要的顺序调用它们，处理它们返回的数据。自计算机问世以来，开发人员就一直在这样做。
新兴范例：MCP、代理框架和提示增强型应用程序接口
从严格定义的传统应用程序接口（API）到流畅的、语言驱动的 LLM 交互，并不总是每个系统组件都直接跃升为纯粹的、无约束的自然语言。相反，我们看到强大的中间范式和框架正在崛起，它们旨在弥合这一差距，使现有系统和新服务成为 "可消费的 LLM"。
这些新兴方法的核心是提示增强应用程序接口（prompt-augmented APIs）的概念。我们并不要求 LLM 从头开始直觉功能，也不要求开发人员编写复杂的适配器代码，而是用丰富的自然语言描述来 "装饰 "或 "包装 "我们的 API（无论它们是古老的 REST 服务还是新的 gRPC 端点）。这些描述就像专门为 LLM 编写的用户手册，解释了 API 的用途、如何调用它、它需要哪些参数（以何种格式）以及它返回什么。
例如，"模型上下文协议"（MCP）提供了一种更有条理的方式，可将各种功能暴露给基于 LLM 的控制平面。系统可以声明其服务及其支持的操作，以及元数据和自然语言描述。然后，LLM 可以查询这些已声明功能的 "菜单"，并根据用户请求或更高层次的目标来协调对这些底层服务的调用，了解它们的功能以及如何通过已声明的提示式界面来使用它们。
这与快速发展的代理框架世界密切相关。这些框架通常为构建一个主要的、由 LLM 驱动的控制代理提供脚手架。这个中心代理充当协调者或 "大脑"，能够进行推理、规划和任务分配。当这个控制代理被赋予访问一套 "工具 "或子代理的权限时，它才会发挥真正的威力。
这些分代理的情况可能大不相同：
- 有些可能是其他基于 LLM 的专业代理，专为复杂数据分析或创意内容生成等特定任务而设计。
- 还有一些可能是更简单的软件模块，或者更重要的是现有传统应用程序接口的封装器。在这种情况下，开发人员会创建一个轻量级的封装程序，例如内部订单管理 API。这个封装器不仅暴露了技术端点，还包括精心制作的提示，用自然语言描述 API 的功能："本工具允许您获取订单状态。它要求输入'order_id'，并将返回当前状态、预计交付日期和订单中的项目"。
这些范例的共同点显而易见：无论是全新的微服务还是通过封装器暴露的传统系统，应用程序接口都不再仅仅是一份技术合同。它增加了一层描述性提示。这使得消费 LLM（通常是控制代理）能够动态地发现、理解和使用大量的工具和功能。LLM 不需要了解每种工具的复杂实现细节；它只需要理解基于提示的使用说明即可。这种转变从根本上改变了我们思考系统集成的方式，并更加强调这些描述性提示的清晰度、精确度和全面性，我们将进一步探讨这一点。
未来......与众不同
从严格的、基于格式的应用程序接口（API），甚至是这些新兴的提示增强接口，到真正广泛的基于语言的 LLM 交互，这是一个巨大的转变。作为一名开发人员，我已经习惯于明确定义可能的输入、输出和错误信息。与 LLM 一起工作将带来我们从未拥有过的大量功能。但它也将重新定义你与其他系统的交互方式。作为开发人员，了解如何制作精确而全面的提示来描述能力变得越来越重要，尤其是在我们构建可能需要多个人工智能代理协作的系统时。
注释