BailingHub 开源版安装完成后，怎样跑通第一条可验证的 Agent 任务？

把一个开源 Agent 项目启动起来，通常并不难。

真正让人停下来的，往往是下一步：

服务已经启动、控制台也能登录，然后呢？怎样证明它真的完成了一次业务任务，而不只是返回了一段看起来合理的文字？

如果答案只是"聊天框能回复"，我们最多证明了模型可以生成文本，还没有证明：

中枢选中了正确的业务场景；
当前 Agent 只看到了被允许的工具；
工具调用真的到达了业务系统；
业务系统验证了请求和操作主体；
结果来自业务系统，而不是模型编造；
任务、工具步骤和失败原因能够被追溯。

BailingHub 是一个面向已有业务系统的开源 Agent 控制面。它的第一条有效验收，不应该是"问一句你好"，而应该是一条可以从输入追到业务结果的完整任务。

本文就完成这一件事：

text 复制代码

启动 BailingHub
-> 确认运行状态
-> 导入或使用演示配置
-> 运行带演示主体的 Smoke
-> 查看 job 与 Trace
-> 理解怎样替换成自己的业务工具

一、什么叫"第一条可验证任务"

一条任务至少要留下四份互相对应的证据：

text 复制代码

1. 用户或系统提出了什么任务
2. 中枢实际选择并调用了什么工具
3. 业务系统返回了什么权威结果
4. 中枢留下了什么 job、Trace 与审计记录

例如：

text 复制代码

查询订单 SO-1001，并创建一条需要人工跟进的售后工单

验证的重点不是 Agent 最终说了多少字，而是能否回答：

它是否调用了订单查询工具；
是否使用查询结果继续创建工单；
工具请求是否带有可信操作主体；
业务侧是否验证了请求签名；
任务最终状态是什么；
如果失败，失败发生在哪一步。

因此本文使用"可验证任务"，而不是"成功对话"。

二、先选择体验路径：在线体验，还是本地完整 Demo

BailingHub 当前提供两条不同的首次体验路径。

1. 在线体验

在线体验适合先认识控制台、导入演示配置并运行系统体检。共享体验环境使用受限的无状态只读演示，不应上传生产凭据、客户数据或真实业务配置。

它的价值是验证产品心智：

调度目标、工具源、路由和接入方分别是什么；
一次任务怎样进入中枢；
Smoke 怎样生成真实 job 和 Trace；
匿名预览与可信业务身份为什么是两条不同路径。

2. 本地完整 Demo

如果要查看查单、创建工单、退款审批和故障 Trace 等更完整的链路，推荐在自己的非生产环境启动 Docker Demo。

它包含：

text 复制代码

BailingHub 中枢
+ MySQL 状态库
+ demo-business 示例业务系统

demo-business 不是一组写死在前端的假结果。它暴露真实的 Agent 工具接口，中枢仍需经过工具发现、主体、签名、限流、审批和审计等运行路径。

两条路径不要混用：在线体验强调受控理解，本地 Demo 用于完整查看业务工具闭环。

三、启动本地 Demo

从源码仓库启动时，先生成管理根密钥：

bash 复制代码

export BAILING_TOKEN="${BAILING_TOKEN:-$(openssl rand -hex 32)}"
docker compose up --build

启动后可以访问：

text 复制代码

中枢健康检查：http://localhost:18900/health
中枢控制台：http://localhost:18900/console/
演示业务系统：http://localhost:19080/
演示工具清单：http://localhost:19080/.well-known/bailing/tools.json

Docker 本地 Demo 的默认控制台账号是：

text 复制代码

admin / bailing-demo-admin

这组固定账号只用于本地演示。正式部署不能照搬 Demo 密码，也不能把空值、短值或公开占位值当作生产 BAILING_TOKEN。

全新 Ubuntu / Debian 服务器也可以使用公开安装脚本：

bash 复制代码

curl -fsSL https://www.bailinghub.com/install.sh | env BAILING_INSTALL_MODE=image sh

安装脚本会生成随机配置并打印实际后台信息。使用脚本之前仍应先阅读脚本内容、确认安装目录、镜像来源、端口和数据库方案；生产环境还要按自己的备份、反向代理、密钥和运维要求完成收口。

四、先检查"服务活着"，但不要停在这里

打开控制台之前，可以先看两类基础状态：

bash 复制代码

curl http://localhost:18900/health
curl http://localhost:18900/health/ready

它们回答的是：

进程是否运行；
数据库与迁移是否就绪；
当前实例是否处于可服务状态。

这很重要，但仍然没有证明业务工具链可用。

text 复制代码

health = 200

不能自动推出：

text 复制代码

工具源可读取
AND 路由允许该工具
AND 操作主体存在
AND 业务签名正确
AND Agent 真正完成调用
AND Trace 可以追溯

所以健康检查是第一层，不是最终验收。

五、演示配置只创建"道路"，不会伪造"车辆已经开过"

BailingHub 的上手向导可以导入一套演示数据集。它会创建或登记：

调度目标；
工具源；
路由；
接入方；
必要的演示配置关系。

导入不会伪造：

job；
工具调用；
审批记录；
成本记录；
Trace；
审计事件。

这个边界非常重要。

如果导入配置后，任务列表里立刻出现一堆"成功记录"，读者就无法判断这些记录来自真实执行，还是安装包预置的数据。

正确流程是：

text 复制代码

导入配置
-> 明确点击运行 Smoke
-> 由真实调用生成 job 和 Trace

本地完整 Demo 使用 full-local profile；共享在线体验使用 stateless-readonly profile。后者只声明只读订单查询和故障观测能力，不保存业务请求状态，也不会自动创建公开聊天入口。

六、为什么第一条任务应该从"演示主体 Smoke"开始

演示订单工具要求可信操作主体。如果直接打开一个匿名聊天入口，它不会自动继承中枢管理员身份，相关工具也不会交给 Agent。

上手向导里的"运行演示主体 Smoke"解决的是另一个问题：

在受控演示环境中，由服务端携带固定演示主体，验证任务、工具和 Trace 链路是否成立。

在控制台中：

text 复制代码

进入「上手向导」
-> 确认演示配置已导入
-> 点击「运行演示主体 Smoke」

命令行环境也可以运行：

bash 复制代码

docker compose exec bailinghub npm run smoke

Smoke 会按当前配置检查多个层面，例如：

health 与 ready；
控制台与版本 API；
数据结构和配置诊断；
路由预演；
在存在演示路由与接入凭据时创建 /run 任务；
等待任务进入终态；
按 request_id 查询 Trace 与脱敏排障包。

结果会分别标记：

text 复制代码

pass：检查已经执行并通过
skip：当前没有提供完成该检查所需的配置
fail：检查已经执行但未通过

不要把 skip 当成 pass。如果 /run + trace 因缺少路由或接入凭据被跳过，我们只能证明基础服务正常，不能声称端到端业务工具链已经完成。

七、这条 Smoke 实际经过了什么

本地完整 Demo 中，一条"查询订单并创建售后工单"的任务大致经过：

text 复制代码

任务输入
-> demo_support 路由
-> demo-agent 调度目标
-> 路由工具来源与 scope 白名单
-> list_demo_orders
-> create_demo_ticket
-> demo-business 验证签名与 On-Behalf-Of 主体
-> 工具结果返回中枢
-> job 进入终态
-> Trace 与审计记录落库

其中有几个容易被忽略的点。

1. 工具不是全量暴露

业务系统在 OpenAPI 中声明能力，中枢还会按路由的来源与 allow 白名单计算当前可见工具。

text 复制代码

业务系统声明
∩ 路由允许范围
∩ 当前主体和治理条件
= 当前 Agent 实际候选工具

2. 操作主体不是模型填写的

演示路由使用 operator_uid 作为主体字段。Smoke 的演示主体由服务端受控注入，不要求模型生成 user_id。

3. 业务系统仍然验证请求

demo-business 会验证工具调用签名与 X-Bailing-On-Behalf-Of。中枢允许某项工具进入候选集合，不等于业务系统必须执行它。

4. 结果不是只留在聊天文本里

工具调用、工具结果、终态与排障信息进入 job、Trace 和审计面。这样才能区分"模型说成功"和"业务系统真的返回成功"。

八、不接真实大模型，为什么仍然有验证价值

本地 Demo 默认使用确定性的 demo-agent，而不是要求使用者先配置真实模型 Key。

这是有意设计：

首次体验不会卡在模型兼容性、网络额度或余额；
同一输入可以稳定走到预期工具；
工具白名单、主体、签名、限流、审批和审计路径仍是真实的；
出现故障时，可以先排除模型随机性。

它证明的是控制面和业务工具链，而不是某个模型的推理质量。

正式接入时，可以把路由目标换成 llm 并配置 OpenAI 兼容模型端点；如果需要本地 Agent，也可以注册 executor 类调度目标，通过出站长轮询领取任务。

九、在哪里查看任务与 Trace

Smoke 成功后，不要只看最后一句回复。

进入控制台的任务与 Trace 页面，至少核对：

证据	要回答的问题
request / job 标识	这是不是刚才那一条任务
route	实际使用了哪个业务场景
target	由哪个调度目标处理
tool call	Agent 实际选择了什么工具和参数
tool result	业务系统返回了什么结果
terminal status	任务最终是完成、拒绝还是失败
audit / debug bundle	失败发生在哪一层，公开信息是否已脱敏

如果是本地完整 Demo，还可以打开 demo-business 页面核对业务侧的订单、工单和审批意图。

这形成了三角证据：

text 复制代码

BailingHub 工具调用结果
+ 业务系统记录
+ BailingHub job / Trace
= 可核对的任务闭环

十、从演示工具换成自己的业务 API

Smoke 通过后，下一步不是继续堆演示数据，而是选择自己系统中的一个真实、可控动作。

推荐顺序是：

text 复制代码

一个系统
-> 一个业务对象
-> 一个高频只读动作
-> 再增加一个可核验的低风险写操作

例如：

查询一张订单；
查询一个客户；
查询库存；
创建一条内部工单；
更新一个可恢复的内部状态。

接入大致分为五步。

第一步：业务系统发布 Agent 工具清单

业务端用 OpenAPI 与 x-agent-capability 声明：

operation；
scope；
risk；
是否要求可信主体；
只读、幂等、超时等执行语义。

PHP 系统可以使用 BailingHub PHP SDK；其他语言可以按公开契约生成工具清单并实现签名验证。

第二步：业务端实现验签与最终授权

业务接口不能只验证"请求来自 BailingHub"，还必须验证：

text 复制代码

当前 On-Behalf-Of 主体是谁
AND 他在业务系统中是否仍有效
AND 他是否有权操作当前对象
AND 当前对象状态是否允许这次动作

第三步：在中枢注册工具源

配置：

base_url；
工具清单来源；
调用签名密钥；
清单访问策略；
刷新和负向探测。

第四步：让路由只允许需要的 scope

不要把一个业务系统的全部工具一次性交给所有路由。每个来源配置 allow，并用 subject_field 指明操作主体来自哪一个可信元数据字段。

第五步：重复同一套验收

text 复制代码

工具清单读取
-> 正确签名探针
-> 错误签名负向探针
-> 主体存在与缺失测试
-> 真实任务
-> 业务记录
-> job / Trace

只有这一套证据闭环之后，才能说第一项业务能力已经接入。

十一、为什么匿名预览不能替代 Smoke

控制台里的"匿名预览"用于验证：

聊天组件能否打开；
公开问答是否正常；
不要求主体的工具是否可用；
外观、页面上下文和基础会话体验。

它不会继承中枢管理员登录状态，也没有独立的业务登录入口。

所有声明 subject.required:true 的工具------包括只读查询------在没有可信业务票据时都会保持隐藏。

所以：

text 复制代码

演示主体 Smoke ≠ 匿名预览

前者是受控的身份化端到端验证；后者是无业务身份的组件预览。把两者混在一起，会让使用者误以为"登录中枢控制台"就自动获得了商城或 CRM 的业务身份。

这条边界将在下一篇单独展开。

十二、第一条任务的最小验收清单

部署完成后，可以按下面这组问题收口：

这份清单比"页面能打开"更接近真实可用。

十三、这次验证证明了什么，没有证明什么

它可以证明：

当前 BailingHub 实例的基础服务和控制台可用；
演示配置可以建立目标、路由、接入方和工具源关系；
一次受控任务可以生成真实 job 与 Trace；
工具调用可以经过主体、签名和治理路径到达演示业务系统；
使用者知道怎样把演示能力替换为自己的业务 API。

它不能证明：

已经完成生产部署；
所有模型、业务系统和工具都兼容；
所有高风险动作都适合自动执行；
Demo、下载、注册或一次 Smoke 等于外部采用；
中枢可以替代业务系统最终权限与业务规则。

结语：安装成功只是起点，第一条 Trace 才是可验证的开始

一个 Agent 控制面真正开始产生价值，不是在控制台第一次打开时，也不是在聊天框第一次回复时。

更可靠的起点是：

text 复制代码

任务有明确输入
工具有受控范围
主体来自可信上下文
业务系统返回权威结果
中枢留下可追溯证据

BailingHub 的 Demo 与 Smoke，目的不是制造一组好看的成功记录，而是让第一次使用者能在不接真实生产系统的前提下，看清这条链路怎样工作、每一层负责什么，以及下一步怎样替换成自己的业务能力。

当你能从一条任务追到一次真实工具调用，再从工具结果追到业务记录和 Trace，才算真正跨过了"项目已经启动"和"系统可以被验证"之间的那条线。

延伸阅读与体验

BailingHub GitHub：https://github.com/bailinghub/bailinghub
在线体验：https://trial.bailinghub.com/register/
快速开始：https://github.com/bailinghub/bailinghub/blob/main/docs/QUICKSTART.md
Docker Demo：https://github.com/bailinghub/bailinghub/blob/main/docs/DEMO.md
BailingHub v0.3.4：https://github.com/bailinghub/bailinghub/releases/tag/v0.3.4
CRMEB 真实业务操作示例：《给 CRMEB 后台接入一个能办事的 AI 助手：BailingHub 独立 Adapter 实测》