从业务需求配置 Agent 中枢
BailingHub 解决的是 Agent 进入现有业务系统后的完整运行链路，不只是一个聊天框。业务系统通过稳定契约暴露必要动作，中枢负责能力触达与执行治理，业务系统继续拥有租户隔离、权限、状态机和最终业务授权。
先回答六个问题
Section titled “先回答六个问题”- 入口在哪里？ 是业务后端事件、网页聊天、本地 Agent，还是自动化平台？
- 谁在操作？ 哪个登录用户、租户或门店需要成为可信业务主体？
- 允许做什么？ 先选一条可验证动作，不要把全部后台 API 一次暴露。
- 哪些情况要审批？ 区分只读、申请/草稿和产生直接副作用的操作。
- 最终由谁授权？ 答案必须是现有业务系统，而不是模型提示词或中枢管理员登录态。
- 如何追溯？ 明确
request_id、job_id、工具调用、批准者和最终业务结果。
后台对象与业务决定
Section titled “后台对象与业务决定”| 对象 | 它回答的问题 | 交给开发者的结果 |
|---|---|---|
| 触发路由 | 这是哪个场景，使用哪些规则、知识和能力？ | 稳定 route、输入与 metadata 约定 |
| 接入方 | 哪个系统可以触发哪些路由？ | 服务端 Token、路由白名单和限速 |
| 调度目标 | 由内置 LLM、外部执行器还是其他运行时处理？ | 目标名称和运行边界 |
| 工具源 | 哪些业务 API 可以被 Agent 看见和调用？ | OpenAPI/ACC spec、签名与授权约定 |
| Agent Client | 哪个本地客户端应用与 workspace 可被授权？ | clientAppId、统一授权入口和允许路由 |
| 知识库 | 哪些资料需要按路由检索？ | kb_id、数据同步与删除规则 |
| 聊天入口 | 哪个页面可嵌入哪条路由？ | entry_key、Origin 白名单和身份票据 |
| 任务与审计 | 发生了什么，失败在哪一层？ | job_id、trace 和脱敏诊断材料 |
推荐的第一条动作
Section titled “推荐的第一条动作”先选“风险低、结果明确、可在业务系统核对”的动作，例如：
- 查询一张订单并返回当前履约状态；
- 查找库存低于阈值的商品；
- 创建一张工单或草稿，不直接提交不可逆后果；
- 修改开发测试账号的一项普通资料。
不要以“让 Agent 管理整个后台”作为第一期需求。第一条动作跑通以后，再按同样边界增加能力。
一份可执行的交接清单
Section titled “一份可执行的交接清单”场景：订单查询与售后工单入口：业务后台内嵌聊天 / 本地 Agent中枢路由：order-support可信主体：metadata.principal.id + tenant工具源：order-tools允许 scope：order.read / ticket.create写操作：只允许创建工单，不直接退款审批：真实退款必须由业务审批流决定验签：业务工具接口验证 BailingHub HMAC最终授权：按原业务权限表判断主体能否访问订单排障：保留 request_id、job_id 与 trace