SAP CAP 拥抱AI：MCP与Agent插件实战解析

当CAP遇见AI：从协议到智能体的进化

在SAP Devtoberfest的分享中，来自SAP开发者频道的Simon和Stefan展示了CAP（Cloud Application Programming Model）在AI时代的最新插件生态。这场直播的核心信息很明确：CAP正通过MCP适配器和Agent插件，让企业级应用以极低的代码量接入大模型与智能体能力。据SAP开发者YouTube频道「CAP in the Age of AI」系列的分析，这些插件并非实验室玩具，而是已进入可用阶段的工程实践。

插件化架构：保持内核干净

CAP团队延续了插件优先的设计哲学。MCP适配器、Agent插件、AI Core服务封装都以独立npm包形式存在于CAPJS命名空间下，开发者按需安装即可。这种「内核干净、能力外挂」的策略，使得不需要AI能力的应用完全不受影响，而需要时只需添加一个注解。正如直播中提到的，连SQLite适配器本身也是插件——这印证了CAP插件体系的成熟度。

两大核心插件：MCP适配器与Agent插件

MCP适配器：四字符暴露业务数据

MCP（Model Context Protocol）适配器的用法极为简洁：在CDS服务上添加@mcp注解，即可将现有服务通过MCP协议暴露给外部智能体。直播演示中，团队使用MCP Inspector连接本地CAP应用，发现服务只暴露了三个通用工具：describe、query、call。这是刻意为之的设计——避免用大量工具定义撑爆大模型的上下文窗口。

值得一提的是，工具描述直接来源于CDS模型中的文档注释（doc comments）。这带来一个反直觉的建议：开发者应该在CDS模型里认真写文档注释，因为这些注释会成为大模型理解业务语义的关键上下文。普通注释则不会被注入，以免泄露内部技术细节。

据Simon和Stefan介绍，社区反馈还促成了一个细节改进：MCP规范要求使用JSON-RPC（仅POST请求），因此GET请求会被拒绝，但页面会给出明确提示而非静默失败。

MCP（Model Context Protocol）是由 Anthropic 于 2024 年底提出并开源的协议标准，旨在统一大语言模型与外部数据源、工具之间的交互方式。它采用客户端-服务器架构：MCP 服务器暴露资源（resources）、工具（tools）和提示模板（prompts），MCP 客户端（如 Claude Desktop、IDE 插件或 Agent 运行时）则按协议调用这些能力。协议底层基于 JSON-RPC 2.0，当前规范主要使用 POST 请求进行通信。MCP 的核心价值在于解耦——模型无需为每个数据源编写专用集成代码，只需实现一次协议即可接入任意兼容的 MCP 服务器。这也是 CAP 选择 MCP 作为对外暴露业务数据标准的原因：一次适配，即可被多种智能体客户端消费。

Agent插件：把智能体装进应用内部

与MCP适配器将AI置于应用外部不同，Agent插件把智能体直接嵌入CAP应用。同样只需一个@agent注解，应用就获得了一个可通过自然语言对话的智能体接口。直播中演示了开发者体验的亮点：插件会检测本地已有的LLM凭证（如Anthropic配置）并自动完成模型配置，索引页甚至内置了一个聊天预览界面。

更关键的是架构复用：Agent插件依赖MCP插件，智能体看到的工具与MCP Inspector中完全一致。团队没有重复造轮子，而是让两个插件共享同一套工具层。此外，开发者可以在服务旁放置agent.md文件来自定义智能体行为——比如设定语气、添加技能说明。直播中DJ分享了一个有趣的测试：他把agent.md写成「粗鲁、没耐心的书店店员」，结果智能体真的变得非常无礼。

CQL：为大模型优化的查询语言

直播中一个值得关注的技术决策是查询语言的切换。早期MCP适配器使用CQN（CAP查询表示法），但需要向模型解释CQN语法，导致上下文膨胀且调用频繁失败。团队后来改用CQL——一种接近SQL的文本查询语言——效果显著提升，并已移除切换回CQN的选项。

在演示中，本地智能体（使用opencode）查询「有多少家公司」时直接生成CQL语句，CAP后端日志清晰可见。DJ在直播中半开玩笑地说，如果要推荐一门值得学习的语言，CQL会是首选，因为它既有SQL的通用性，又更简洁、更易被大模型理解。

CQN（Core Query Notation）是 CAP 内部用于表达查询的抽象语法树式表示法，通常以 JSON 对象形式存在，便于程序化构造和跨数据库方言转换。它功能强大但语法冗长，对人类和 LLM 都不够直观——模型需要理解嵌套的 JSON 结构以及 CAP 特有的操作符命名，容易产生格式错误。CQL（CAP Query Language）则是 CAP 提供的文本化查询语言，语法高度接近 SQL 的 SELECT 语句，支持 where、order by、join、聚合等常用能力，同时保留了 CAP 对关联路径（如 book.author.name）的简写支持。由于大模型在预训练中见过大量 SQL，CQL 的类 SQL 形态显著降低了生成门槛，这也是切换后调用成功率提升的根本原因。

n8n插件：工作流触发的声明式集成

最后一个展示的插件是CAP与n8n的集成。通过注解或自定义逻辑，CAP应用可以在实体创建等事件发生时触发n8n的Webhook，从而调用n8n生态中数千种集成能力。插件同样遵循CAP的可测试性原则：在开发模式下，工作流触发会被替换为日志输出，无需真实n8n实例即可完成本地开发。异步触发通过事务性Outbox模式保证一致性，这是经典架构模式在AI工作流场景下的延续。

事务性 Outbox 模式是一种保证消息最终一致性的经典架构模式：业务操作与待发送消息在同一数据库事务中写入 Outbox 表，随后由独立的后台处理器轮询或订阅该表，将消息可靠地投递到外部系统（此处即 n8n Webhook）。这样即使外部系统暂时不可用或投递失败，消息也不会丢失，且不会因外部调用失败而回滚业务事务。在 AI 工作流场景下，这一模式尤为重要——n8n 工作流可能耗时较长或依赖第三方服务，同步调用会拖垮主事务，而 Outbox 将触发解耦为异步、可重试的可靠投递。

多源信息交叉与分歧点

本次分享的信息主要来自单一来源（Devtoberfest直播），但其中若干说法可与CAP官方文档和「CAP in the Age of AI」系列往期内容相互印证：MCP适配器的三工具设计、Agent插件对MCP工具的复用、CQL作为默认查询语言，均在文档中有对应记录。需要说明的是，直播中关于AI Core服务类型（application service）的讨论出现过短暂的不确定，主持人现场确认后统一了口径，读者以官方文档为准即可。

对开发者的启示

这套插件生态传递出的信号是：企业应用接入AI不必推倒重来。CAP把AI能力封装为符合既有开发习惯的服务和注解，开发者用声明式的方式表达意图，底层连接、协议转换、凭证管理由框架处理。对于已经在使用CAP的团队，MCP适配器和Agent插件的迁移成本极低；对于观望中的团队，这或许是一个重新评估CAP技术栈的理由。