很多企业准备给现有商城、SaaS、CRM、ERP 或内部管理系统增加 AI 助手时，第一轮讨论通常会出现一串名词：
- 做一个知识库，用 RAG；
- 把现有接口整理成 OpenAPI；
- 再接一个 MCP Server；
- 复杂任务交给工作流；
- 如果要修改后台，再加一层 Agent 控制面。
于是问题很快变成：这些技术到底应该选哪一个？
其实，这个问题从一开始就问错了。
RAG、OpenAPI、MCP、工作流和 Agent 控制面并不是五个互相替代的产品。它们位于不同层，分别解决“知道什么”“接口是什么”“怎样连接”“步骤怎样组织”以及“这次业务操作凭什么可以执行”。
一个真正能操作业务后台的 AI 助手，往往不是从中挑一个，而是按任务需要组合其中几层。
先给答案：不要按名词选，要按任务后果选
如果只想做第一次判断，可以先记住下面五句话：
- 回答制度、产品说明和操作手册，用 RAG。
- 让程序准确理解已有 HTTP 接口，用 OpenAPI。
- 让 Agent 发现并调用外部工具，用 MCP 或其他连接器。
- 步骤稳定、分支明确、必须按顺序运行，用工作流。
- 一旦 Agent 要代表真实用户修改业务数据，就要补上可信身份、能力范围、幂等和审计，并明确哪些操作可以直接执行、哪些需要确认或审批。这部分可以由业务系统、网关、工作流平台和 Agent 控制面共同承担，但不能只写在提示词里。
最关键的判断不是“哪个技术更先进”，而是：
这次任务只是生成答案，还是会对真实业务产生后果？
一、用一个场景，看懂五层分别做什么
假设一家已经运行多年的商城希望增加 AI 助手。运营人员输入：
找出库存低于 10 件、最近 30 天仍有销量的商品，创建补货申请草稿，并通知采购负责人。
这句话里至少包含四件事：
- 理解“低库存”和补货规则；
- 查询实时库存与销量；
- 创建一张补货申请草稿；
- 发送通知。
如果把它拆成技术层次，大致是：
用户目标
↓
Agent：理解目标，决定下一步
├─ RAG：查找补货制度、商品规则和操作说明
├─ MCP / 连接器：发现并调用库存、销量、补货、通知工具
├─ 工作流：在步骤固定时约束查询、判断、创建和通知顺序
↓
Agent 控制面：重验身份、裁剪能力、应用风险与审批闸门、记录调用与审计，并协调幂等和未知终态对账
↓
SDK / 业务适配器：调用业务 API
↓
现有商城：按原有租户、角色、数据归属和业务规则最终执行或拒绝
业务能力旁注：OpenAPI 描述接口结构；ACC 等治理元数据描述 Agent 触达时需要遵守的边界。
这里每一层都重要，但它们解决的不是同一个问题。
二、RAG：解决“AI 应该参考什么”，不直接解决“能不能改后台”
RAG，也就是检索增强生成，适合把企业文档、产品说明、知识库和历史资料检索出来，作为模型回答时的参考。这一技术路径最早在 RAG 原始论文中被系统化描述。
它很适合处理这些问题：
- 公司的补货规则是什么？
- 退款需要满足哪些条件？
- 某个后台功能应该怎样使用？
- 这份合同里约定了什么？
但 RAG 本身并不等于实时业务查询，更不等于业务写入。
即使知识库里放了一份“商品接口文档”，模型能够解释接口怎么调用，也不代表它已经获得当前库存，更不代表它有权创建补货申请草稿。把数据库定时导出的内容放进向量库，也可能产生时效性、权限隔离和删除同步问题。
所以，RAG 最适合回答：
这件事应该怎样理解？有哪些规则可以参考？
它不能单独回答：
当前这个用户能不能在这家门店修改这条数据？
三、OpenAPI：解决“接口长什么样”，不自动决定“这次调用能不能成功”
OpenAPI Specification 用结构化方式描述 HTTP API：路径、方法、参数、请求体、响应以及安全方案等。对已有商城、CRM、ERP 来说，它通常是把现有业务接口整理成 Agent 可理解能力的好起点。
例如，OpenAPI 可以明确告诉工具调用方：
POST /purchase-orders
需要哪些字段
每个字段是什么类型
成功和失败会返回什么
这解决了“接口怎样正确调用”的问题。
但一份 OpenAPI 文档不会自动知道：
- 当前行动者属于哪个租户；
- 他能不能操作这家门店；
- 将这份补货申请草稿正式提交时是否超过审批阈值；
- 同一次请求重放会不会创建第二张单；
- 接口超时后到底有没有成功。
OpenAPI 可以描述认证方式，也可以通过扩展字段承载更多元数据，但真正的业务权限和状态判断仍要由运行时及业务系统执行。
因此，OpenAPI 回答的是：
这个 HTTP 能力是什么，应该怎样调用？
四、MCP：解决“Agent 怎样发现和调用工具”，但不等于拿到了整个后台权限
MCP 的 Server 能力包括提示、资源和工具，并通过统一协议提供给 Agent 宿主。对于开发者，它最大的价值是减少不同 Agent 客户端与不同工具之间的重复适配。
比如同一个库存查询能力，可以通过 MCP 交给桌面 Agent，也可以由其他支持 MCP 的客户端使用。Agent 不必为每个工具重新理解一种完全不同的私有调用格式。
但这里需要避免一个常见误解：
MCP 不是“没有安全”的协议，也不是一接入就会绕过权限。
MCP 官方架构本身包含宿主侧的连接权限、安全策略、用户同意和能力协商。问题在于，Agent 宿主允许连接某个 MCP Server，或者用户同意调用某个工具，并不自动等于商城已经允许这个用户修改某个租户下的商品。
这是两层不同的授权：
- Agent 平台判断“这个连接和工具是否可以被当前客户端使用”；
- 业务系统判断“这个真实业务用户此刻是否可以操作这条业务数据”。
所以，MCP 更准确地回答：
Agent 与工具之间怎样建立可发现、可调用的连接？
五、工作流：解决“确定步骤怎样稳定重复”，不必让 Agent 每次重新规划
如果任务步骤已经很明确，例如：
每天 9 点查询低库存商品
→ 按固定公式计算建议数量
→ 生成补货申请草稿
→ 超过金额阈值时进入审批
→ 审批后通知采购
那么工作流通常比让 Agent 每次从头规划更合适。
工作流的优势是顺序清楚、条件明确、运行稳定，也更容易配置超时、重试、补偿和人工节点。n8n、Dify 工作流或企业已有流程引擎，都可以承担这类编排。
但工作流不必和 Agent 二选一：
- Agent 可以理解模糊目标，再选择并启动一条工作流；
- 工作流可以在某个节点调用模型做分类、总结或参数提取；
- 高风险步骤仍然可以交给原业务审批流；
- 跨入口共享的身份、工具范围和审计，也可以放到统一控制层。
工作流回答的是：
已经确定的步骤，怎样按规则稳定运行？
六、Agent 控制面：解决“当多个 Agent 真正办业务时，怎样守住共同边界”
如果只有一个内部脚本调用一条只读接口，团队未必需要独立的 Agent 控制面。
但当业务系统开始同时接入网页聊天、本地 Agent、MCP 客户端、Dify、n8n 或消息渠道，并且工具从查询扩展到创建、修改、发起审批和通知时，很多问题会重复出现：
- 不同入口分别代表谁？
- 哪个入口可以看到哪些工具？
- 只读和写操作怎样区分？
- 高风险调用在哪里暂停？
- 审批通过后怎样保证参数没有被 Agent 改掉？
- 同一个请求怎样避免重复执行？
- 工具可能成功但网络断开时，为什么不能盲目重试？
- 对话、工具调用、审批和业务结果怎样串成同一条轨迹？
所谓 Agent 控制面，就是把这些跨模型、跨入口、跨工具都会遇到的运行治理能力集中起来。
它不是必须单独采购的固定产品形态。团队可以把这层能力实现到 API 网关、Agent 平台、工作流引擎或自建服务中；当入口和业务系统越来越多时，也可以使用独立控制面统一管理。
BailingHub 的位置就在这一层：BailingHub Core 提供网页聊天、Client API 和 Agent Client Runtime 等接入面；独立 MCP 或宿主适配器可以在不进入 Core 制品的前提下，把兼容客户端接入这些受治理能力。业务操作不依赖绕过业务 API 直连数据库，最终权限仍由业务系统判断。
七、一张表看懂：你的需求应该从哪一层开始
| 真实需求 | 优先能力 | 还需要补什么 |
|---|---|---|
| 回答制度、产品和操作手册 | RAG | 文档权限、时效和引用来源 |
| 查询实时订单、库存、客户数据 | 业务 API（可由 OpenAPI 描述，经 SDK、连接器或 MCP 暴露） | 可信身份、数据范围、业务最终授权 |
| 让桌面 Agent 使用多种外部工具 | MCP / 连接器 | 宿主授权、业务身份和工具治理 |
| 每天固定生成报表或补货申请草稿 | 工作流 | 稳定请求标识、失败分支、审计 |
| 用户用自然语言完成不固定的多步任务 | Agent + 工具 | 能力按需发现、调用预算和结果核验 |
| 修改员工、创建工单、下架商品 | Agent + 业务 API | 写工具白名单、可信主体、幂等和审计 |
| 退款、删除、改权限、批量外发 | Agent / 工作流 + 治理层 | 参数快照、审批、执行前重验、未知终态对账 |
| 多个 Agent 和自动化平台共用一套业务能力 | Agent 控制面 | 统一身份、策略、能力目录和执行总账 |
这张表的重点不是让所有项目都增加更多组件，而是避免让某一层承担它并不擅长的职责。
八、四种常见组合，分别适合什么阶段？
组合一：RAG + 对话界面
适合企业知识问答、帮助中心和内部制度查询。
此时 AI 的主要产物是答案，不直接改变业务状态。重点应该放在知识质量、权限过滤、引用和时效性，而不是急着接几百个工具。
组合二：Agent + 只读业务 API（OpenAPI 可用于描述，MCP / 连接器可用于接入）
适合查询订单、客户、库存和经营数据。
这是从“会回答”走向“能查后台”的第一步。即使全部是只读，也要验证真实身份、租户隔离、数据范围和业务系统最终授权。
组合三：Agent + MCP / 连接器 + 控制面 + 业务 API / 系统
适合创建工单、修改普通资料、生成业务草稿等可核验、可恢复的写操作。
Agent 负责理解和规划，MCP 或连接器负责调用适配，控制面负责限制可见能力、绑定主体和记录轨迹，业务系统按原权限最终执行。
组合四：工作流 + Agent + 控制面
适合稳定流程中夹杂少量智能判断的任务。
例如，工作流固定负责取数、条件判断、审批和通知，Agent 只在“理解客户问题”“归类异常原因”“生成处理建议”等节点发挥作用。这样既保留确定性，也不浪费模型的理解能力。
九、最容易踩的五个坑
坑一：把 API 文档放进知识库，就以为 AI 能查实时数据
知识库能让模型理解接口说明，但真实订单和库存仍要通过受控接口读取。
坑二：把整份 OpenAPI 全部转换成工具
后台里的通用 CRUD、批量删除、权限管理和内部运维接口，并不都适合直接交给 Agent。应先按真实业务动作重新筛选和命名。
坑三：把 MCP 连接授权当成业务最终授权
连接成功只说明 Agent 获得了一条调用路径。订单归属、门店范围和用户角色仍需由业务系统实时判断。
坑四：把审批规则写进提示词
“金额超过 1000 元请先询问用户”可以帮助模型，但不是可靠的强制规则。真正的暂停、参数冻结和审批消费必须在模型无法绕过的执行路径上发生。
坑五：为了接 AI，重新复制一套业务权限
Agent 不应该成为独立于原后台的超级管理员。更合理的方式是让它携带可信业务主体调用原有业务接口，并由原系统继续校验租户、角色、数据范围和当前状态。
十、已有系统第一步怎么做？先跑通“一读一写”
如果你的团队现在正准备立项，不要第一天就讨论“要接多少模型”“要开放多少 MCP 工具”。
先选择一个最小闭环：
一套现有业务系统
+ 一个真实测试身份
+ 一条高频只读动作
+ 一条低风险、可回滚写操作
+ 一条可以对上的执行轨迹
例如：
- 读取一条测试订单；
- 为这条订单创建一条内部跟进工单。
然后逐项验证：
- Agent 能找到正确工具，而不是看到整个后台；
- 身份来自真实登录或授权，不来自模型填写；
- 有权限账号能读，无权限账号由业务系统拒绝；
- 写操作只产生一次业务后果；
- 请求超时后可以查事实，而不是直接重试；
- 最后能从会话追到工具调用和业务结果。
跑通以后，再决定下一步需要增加 RAG、MCP 生态、工作流编排，还是独立的 Agent 控制面。
这个顺序比先堆完整技术栈更省时间，也更容易发现真正的系统边界。
结语：连接不是终点，业务后果才是分界线
RAG 让 Agent 能参考知识，OpenAPI 让接口可以被准确描述，MCP 让工具更容易被发现和调用，工作流让确定步骤稳定运行，Agent 控制面则帮助多个入口在真实业务操作中共享身份、能力和审计边界。
它们不是竞品关系，而是一套可以按任务后果逐层组合的技术栈。
如果 AI 只需要回答“怎么做”，RAG 可能已经足够。
如果 AI 还要查询“现在是什么状态”，就需要实时业务接口和可信身份。
如果 AI 最终要替人创建、修改、发起审批或执行经过审批的操作，那么真正需要设计的就不只是工具调用，而是：
谁在行动、允许做什么、为什么这次可以做、产生了什么后果，以及事后怎样追溯。
这也是现有业务系统从“接入一个模型”走向“让 Agent 真正办事”时，最值得先想清楚的一层。
下一步：用一条真实动作验证，而不是继续比较名词
如果你已经有商城、SaaS、CRM、ERP 或内部后台，可以先准备一条脱敏业务动作：
- 接口用途；
- 最小请求与响应；
- 谁可以调用；
- 是否产生副作用；
- 是否需要审批；
- 重复请求应该怎样处理。
然后可以：
- 查看 BailingHub 开源仓库；
- 运行仓库内置的 Docker Demo，复现订单查询、退款审批和 Trace；
- 按 真实 API 接入评估 提交一条不含密钥、私有域名和客户数据的脱敏 operation；
- 了解实现中立的 ACC（Agent Capability Contract），判断一项业务能力应该怎样声明作用范围、主体、风险和执行约束。
