Agent 控制面 · 开源核心

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

能办事的 AI Agent 接进业务接口——四道闸 + 请求签名 + 高危审批意图,每一步可审计、可叫停。业务只管触发,剩下的交给中枢。

自托管跑通 → 预约演示
Apache 协议 · 可私有部署 · 状态留在你自己的库
业务系统 触发方 网页聊天 widget 企业微信 入站渠道 CONTROL PLANE 百灵中枢 鉴权 路由 · 装配 安全闸 结果原路送回 云端 LLM 可热插拔 远端 Agent 调业务接口
兼容 ·
OpenAI 协议通义千问DeepSeek智谱 GLMKimiMySQL 状态库近零依赖可嵌任意网站企业微信开箱 OpenAI 协议通义千问DeepSeek智谱 GLMKimiMySQL 状态库近零依赖可嵌任意网站企业微信开箱

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

01

不敢让 Agent 碰业务接口

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

02

接入要动老系统

改造 PHP / Java 老系统、绑死某个模型、数据被托管到别人那儿。

03

换模型就丢上下文

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

ARCHITECTURE

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

请求进 → 渠道接入 → 身份与策略 → 调度 → 执行 → 送达 → 结果出。扩展只加适配器,不改内核。

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

三根支柱,立住差异化

01 · 工具治理 · 最强护城河

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

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

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

让 Agent 安全调用业务接口,正是 OWASP 在 agentic 安全方向反复强调、却还没被通用大厂开箱内置的环节。

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

对话和记忆,永远在你自己的库里

对话总账 append-only、是唯一真值;Agent 会话只是可重建缓存。换模型、换大脑都不丢记忆,全程可审计、抗厂商锁定。

换脑不丢记忆 —— 数据和调用,留在你自己的边界内。

03 · 低侵入接入

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

业务与中枢只隔一条冻结的网络契约——不互相 import 代码、不跑在业务进程里。网页一行 script 嵌聊天、后端一个 curl / PHP 触发:这部分粘一段代码即可,老系统逻辑一行不动。

让 Agent 真正查数据、办业务则是个小集成:用零依赖 SDK(ThinkPHP 友好)把你选定的几个动作注册成工具、接一道验签 + 授权闸——四闸、签名、审批意图由中枢托底,"这个人能不能做"回到业务侧裁决。低代码,不是零代码。
<!-- 在任意网页粘一行,即接入聊天 -->
<script
  src="https://你的中枢/widget.js"
  data-entry="pub_xxxxxxxx" async></script>
 
# data-entry 在控制台「聊天入口」生成
# 业务侧一行触发,无需改造老系统
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} 取结果
// 业务后端事件点触发,fire-and-forget
$ch = curl_init('https://你的中枢/run');
curl_setopt_array($ch, [
  CURLOPT_POST => true,
  CURLOPT_HTTPHEADER => [
    'Authorization: Bearer '.$token,
    'Content-Type: application/json',
  ],
  CURLOPT_POSTFIELDS => json_encode([
    'route' => 'order.refund',
    'metadata' => ['operator_uid' => $user->id],
  ]),
]);
curl_exec($ch);
CAPABILITIES

一条路由,配齐一个场景

看完整能力面 →
触发路由
业务一行触发,规则化路由到合适的大脑。
工具插座
把业务接口注册成 Agent 可调的工具,过闸调用。
网页聊天组件
一行 script 嵌入任意网站,开箱即用。
入站渠道
企业微信等渠道接入,统一进中枢。
知识库 RAG
向量检索,按场景注入领域知识,故障自动降级。
对话记忆
滚动摘要记忆,长会话换模型不丢上下文。
页面上下文
把当前页面状态带进对话,答得更准。
对象存储
附件、图片、文件统一托管与引用。
RBAC 控制台
角色权限、密钥掩码、审计可视化。
OPEN-CORE + COMMERCIAL

自己跑,还是交给我们一起跑

开源版 · 自托管

完整能力,自己掌控

完整能力,无功能阉割
核心仓库 Apache 2.0 · 可私有部署
自己部署运维,数据全自持
社区支持 · 路线图公开
看文档 / 自托管
商业版 · 集成交付

私有部署 + 一起把它跑起来

私有部署支持 + SLA
安全合规协助
集成商 / ISV 联合交付
培训与联合交付支持
预约演示 / 商务咨询
SECURITY & COMPLIANCE

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

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

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

三步跑通

起服务 → 建一条路由 → 触发拿结果。Node ≥ 22 + MySQL,技术受众现在就能试。

自托管文档 接口契约
~/bailing-ai
# ① 起服务(生产密钥走环境变量)
$ docker compose up --build
# ② 控制台建一条路由 + 发一把接入方钥匙
本地打开 http://localhost:18900/console/ · 「触发路由」「接入方」
# ③ 触发拿结果
$ 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 等)——私有化落在数据面,而不是逼你本地跑大模型;有不出境要求时再换自托管模型即可。

会改造我的老系统吗?

不改架构。业务与中枢只隔一条冻结的网络契约,不互相 import 代码、不跑在业务进程里。触发与聊天粘一段代码即可、触发方逻辑一行不动;让 Agent 调你的业务接口则需注册几个工具 + 接一道授权闸——是个小集成,但只在老系统旁边加一层,不动你原有逻辑。

我的数据在哪?

在你自己的库里。对话总账落在你独立的状态库、是唯一真值;Agent 会话只是可重建缓存。状态和调用记录始终留在你自己的边界内。

和 Dify / 扣子有什么不同?

它们是搭 AI 应用的平台;百灵是把 Agent 安全接进你既有业务系统的治理控制面。重点不在"搭个应用",而在解耦接入、工具治理与状态主权。

支持哪些模型?

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

怎么保证 Agent 不乱调接口?

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

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

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