A2B 控制面 · ACC 开放契约

让 Agent 安全地
接进你的业务系统

我们用 A2B 表达 Agent-to-Business:让 Agent 安全接入已有业务系统。百灵中枢基于 ACC 能力声明 + 四层治理 + 请求签名 + 高风险审批意图,让每一步可审计、可叫停。

在线体验 自托管跑通
curl -fsSL https://www.bailinghub.com/install.sh | sh 体验 Demo 文档
业务系统 触发方 网页聊天 widget 消息渠道 入站渠道 CONTROL PLANE 百灵中枢 鉴权 路由 · 装配 安全闸 结果原路送回 云端 LLM 可热插拔 远端 Agent 调业务接口
兼容 ·
OpenAI 协议通义千问DeepSeek智谱 GLMKimiMySQL 状态库近零依赖可嵌任意网站渠道可插拔 OpenAI 协议通义千问DeepSeek智谱 GLMKimiMySQL 状态库近零依赖可嵌任意网站渠道可插拔

想让 Agent 真正办业务,难的从来不是调模型

01

不敢让 Agent 碰业务接口

一调就怕越权、误删、资损;没有闸门和审计,出了事谁都说不清。

02

接入要动老系统

改造存量系统、绑死某个模型、数据被托管到别人那儿。

03

换模型就丢上下文

会话和记忆散在各家大模型里,换一个全重来,没法审计。

ARCHITECTURE

一层控制面,把「业务」和「Agent 大脑」干净地隔开

从请求进入、渠道接入、身份与策略、调度、执行到结果送达,每一层职责清晰。新增模型、渠道和执行方式优先通过适配器扩展,保持核心职责稳定。

01
渠道接入
网页 · 消息 · 触发
02
身份策略
鉴权 · RBAC · 策略
03
调度
规则路由 · 装配上下文
04
执行
工具插座 · 四道闸
05
送达
回传 · 总账落库
WHY DIFFERENT

三根支柱,立住差异化

01 · 工具治理 · 核心治理能力

让 Agent 能办事,
但每一步都过闸、可审计、可叫停

白名单 / 风险分级 / 限流 / 逐次审计 四道闸 + 请求签名(把"谁、为哪个任务"钉进签名)+ 高风险暂停并转人工裁决。

"Agent 够得到什么"由中枢管,"这个人此刻能不能做"永远由业务裁决。

OWASP 将权限过大、过度自治和缺少高影响操作审批列为 Agentic 应用的重要风险。百灵中枢把最小权限、业务身份、风险策略、人工审批与逐次审计落实到每一次工具调用。

深入工具治理
Agent 发起调用 · order.refund
闸 1白名单校验
闸 2风险分级
闸 3限流
闸 4逐次审计 + 请求签名
高风险暂停待审 · 通过后执行
🗄️
对话总账
你自己的 DB · append-only · 唯一真值
热插拔
🧠
Agent 会话
可重建缓存 · 换脑不丢
02 · 状态主权

持久化状态,由你自己的数据库持有

中枢把对话总账、记忆、任务、审计与 trace 持久化到你自己的状态库;Agent 会话只是可重建缓存。调用云端模型时,输入传输与供应商留存边界仍由你选择和评估。

换模型不必重建中枢状态,持久化数据边界由你的部署与模型选择共同决定。

03 · 低侵入接入

触发与聊天粘一段代码,
让 Agent 办事是个小集成

业务与中枢通过稳定的 HTTP 契约协作,不互相 import 代码,也不跑在同一业务进程里。网页聊天入口可用 script 嵌入,后端通过 HTTP 触发;原有业务架构和权限体系继续保留。

让 Agent 真正查数据、办业务则是个小集成:用 SDK 或 OpenAPI x-agent-capability 按 ACC 声明你选定的几个动作,再接一道验签 + 授权闸。四闸、签名、审批意图由中枢托底,"这个人能不能做"回到业务侧裁决。低代码,不是零代码。
<!-- 在任意网页粘一行,即接入聊天 -->
<script
  src="https://你的中枢/widget.js"
  data-entry="pub_xxxxxxxx" async></script>
 
# data-entry 在控制台「聊天入口」生成
# 业务侧通过标准 HTTP 触发,保留原有业务架构
curl -X POST https://你的中枢/run
  -H "Authorization: Bearer $BL_TOKEN"
  -H "Content-Type: application/json"
  -d '{
    "route": "order.refund",
    "input": "为订单 SO-20260623-018 退款",
    "metadata": { "operator_uid": "1042" }
  }'
 
返回 { "job_id": "a3f…" } # 再 GET /jobs/{job_id} 取结果
// 业务系统发布 OpenAPI,用 ACC 声明允许 Agent 调用的能力
"/orders/{id}": {
  "get": {
    "operationId": "order.get",
    "summary": "查询订单",
    "x-agent-capability": {
      "version": 1,
      "enabled": true,
      "scope": "order.read",
      "risk": { "level": "low" },
      "subject": { "required": true }
    }
  }
}
 
生成 中枢编译成 ToolDefinition,并统一过白名单 / 风险 / 限流 / 审计
CAPABILITIES

一条路由,配齐一个场景

查看完整能力面
触发路由
业务通过标准 HTTP 触发,按场景路由到模型或执行器。
工具插座
把业务接口注册成 Agent 可调的工具,过闸调用。
网页聊天组件
用 script 低侵入嵌入现有网站,并按需接入登录票据和页面上下文。
入站渠道
消息平台、网页入口和业务触发统一进中枢。
知识库 RAG
向量检索,按场景注入领域知识,故障自动降级。
对话记忆
滚动摘要记忆,长会话换模型不丢上下文。
页面上下文
把当前页面状态带进对话,答得更准。
任务追溯
一个 job_id 查全链路,调度、工具、审批、送达都能回放。
RBAC 控制台
角色权限、密钥掩码、审计可视化。
OPEN SOURCE + OPTIONAL PLATFORM

多数场景,开源版已经足够

一个组织内接入多个业务系统,直接使用完整开源版即可;只有多个独立客户或组织共享一套平台并需要隔离管理时,才需要额外的平台层。

开源版 · 完整自托管

完整开源中枢,自己掌控

完整路由、工具、知识、审批、审计与控制台能力
多路由、多接入方、多工具源
核心仓库 Apache 2.0 · 可私有部署
自己部署运维,中枢持久化状态自行持有
看文档 / 自托管
多租户平台 · 按需选择

多个独立租户共享平台时再用

基于同一开源核心,增加租户级隔离
租户生命周期、额度与平台后台
适合 SaaS 厂商与多客户运营
部署、SLA 与联合交付均可选
判断是否需要
SECURITY & COMPLIANCE

状态留在域内,
每一步可追溯

私有化的正确落点是控制面 / 数据面私有:状态与总账在你的库里;模型按需调云端或国产 API,敏感场景也可换自托管模型让数据不出境。

状态进你自己独立的库,与业务库隔离
输入即不可信:prompt 注入防护
分层鉴权 + 密钥掩码 + reveal 审计
kill switch 一键停
控制面私有部署,模型可调云端 / 国产 API
逐次审计,追溯到"谁、为哪个任务"
QUICKSTART

先看后台,再跑闭环

在线体验用于最快理解后台心智和多租户治理形态;Docker Demo 用于在自己的机器上跑完整技术闭环。两条路径互补,不需要一开始就搭环境;公开体验环境不要填写生产密钥或接入真实生产数据。

在线体验 Docker Demo 自托管文档
~/bailinghub
# 01 起服务(生产密钥走环境变量)
$ docker compose up --build
# 02 控制台建一条路由 + 发一把接入方钥匙
打开 本地控制台 http://localhost:18900/console/ · 「触发路由」「接入方」
# 03 触发拿结果
$ curl -s $HUB/run -H "Authorization: Bearer $TOKEN" \
    -d '{"route":"support","input":"你好"}'
返回 { "job_id": "a3f1…" }
$ curl -s $HUB/jobs/a3f1… -H "Authorization: Bearer $TOKEN"
完成 { "status": "done", "result": { … } }
FAQ

常见问题

要不要本地部署大模型?

不强制。把控制面私有部署,模型按需调云端或国产开源 API(通义 / DeepSeek / 智谱 / Kimi 等)。私有化落在数据面,而不是逼你本地跑大模型;有不出境要求时再换自托管模型即可。

会改造我的老系统吗?

不需要重构原有架构。业务与中枢通过稳定的 HTTP 契约协作,不互相 import 代码、不跑在同一业务进程里;让 Agent 调用业务动作时,需要声明选定工具并接入验签与原有权限判断。这是边界清晰的小规模集成,不是零改造承诺。

我的数据在哪?

中枢的对话总账、记忆、任务、审计与 trace 持久化到你自己的状态库。调用云端模型或外部工具时,对应输入会按配置发送到所选服务;有不出域要求时,应使用自托管模型、内网工具和自己的媒体存储。

和 Dify / 扣子有什么不同?

Dify、扣子等平台主要帮助搭建 AI 应用、工作流和智能体;百灵中枢聚焦 Agent 与既有业务系统之间的治理控制面。它们可以配合使用,并不是互斥替代关系。

支持哪些模型?

兼容 OpenAI 协议的模型,以及通义千问、DeepSeek、智谱 GLM、Kimi 等国产模型。按场景 / 成本 / 可用性做规则化路由,支持一键切换与降级。

怎么保证 Agent 不乱调接口?

调业务接口要过四道闸(白名单 / 风险分级 / 限流 / 逐次审计)+ 请求签名,高风险暂停并转人工裁决。"Agent 够得到什么"由中枢管,"这个人能不能做"由业务裁决。

把 Agent 接进业务,从一条路由开始

自托管跑通 阅读文档
或先读文档 / 看方案