很多团队已经有商城、CRM、ERP、工单系统或 SaaS 管理后台，也已经试过用大模型写文案、回答知识库问题。
下一步自然会问：
能不能让 AI 不只回答问题，还能直接查询后台、创建记录或提交业务操作？
这时最容易走向两个极端。
一种是把整个后台接口都交给模型，希望它自己理解；另一种是先规划一套庞大的“企业 Agent 平台”，几个月后仍然没有跑通一个真实业务动作。
更适合存量系统的起点，是先完成一条很窄的纵向链路：
一个真实用户
-> 一个已有业务系统
-> 一个明确业务对象
-> 一个只读动作
-> 一个低风险写动作
-> 一条可以还原的执行记录
例如：
商城 + 订单 + 查询订单 + 创建售后工单
CRM + 客户 + 查询客户 + 新建跟进记录
ERP + 商品 + 查询库存 + 提交补货申请
工单系统 + 工单 + 查询进度 + 补充处理备注
这就是“一读一写”。它不是最终架构，却是判断一套 AI 助手能否真正进入业务系统的最小切片。
一、第一步不是训练模型，而是选择业务动作
给现有后台增加 AI 助手，通常不需要先训练一个新模型。
模型已经能理解“帮我查一下订单”和“为这笔订单创建售后工单”。真正缺少的是业务侧把这些自然语言意图映射到受约束的系统能力，并继续保留原来的身份、权限和业务规则。
所以开始前先写清四件事：
| 问题 | 示例答案 |
|---|---|
| AI 服务谁 | 已登录的客服人员 |
| 操作什么对象 | 当前租户中的订单 |
| 第一项只读能力 | 按订单号查询订单 |
| 第一项写能力 | 为订单创建售后工单 |
如果这四项还说不清楚，就不应该先把几十个后台接口一次性暴露出来。
一个合格的首个动作应满足什么
优先选择：
- 业务人员每天都会重复执行；
- 输入和结果容易人工核对；
- 失败时能明确告诉用户发生了什么；
- 不需要跨越多个系统完成复杂事务；
- 第一项写操作可以被追踪、撤回或进入后续人工流程。
不建议一开始就选择：
- 自动退款；
- 批量修改库存；
- 删除客户数据；
- 冻结员工账号；
- 直接执行生产运维命令。
这些动作当然可以成为后续能力，但它们会同时引入审批、参数绑定、幂等、风险策略和恢复执行等问题，不适合作为团队第一次验证“AI 能不能操作后台”的入口。
二、不要把数据库和管理员账号直接交给模型
AI 助手进入业务系统，不等于模型直接连接数据库，也不等于在提示词里放一个管理员 Token。
更合理的调用链是：
已登录用户
-> 聊天或业务操作入口
-> Agent 选择被允许的工具
-> 控制面绑定可信身份与当前场景
-> 调用已有业务 API
-> 业务系统做最终权限和状态校验
-> 返回结构化结果
-> Agent 组织成人能理解的回答
这里至少有三层不能混在一起：
| 层次 | 负责什么 | 不能代替什么 |
|---|---|---|
| 模型与 Agent | 理解意图、选择候选工具、组织参数 | 不能自己声明“我是管理员” |
| Agent 控制面 | 限制可见能力、绑定可信上下文、执行治理和记录 Trace | 不能替业务系统判断订单最终能不能操作 |
| 业务系统 | 校验租户、用户权限、对象状态和业务规则 | 不能因为请求来自 AI 就跳过原有校验 |
换句话说，AI 可以提出“查询订单 ORDER-20260807-001”，但当前用户属于哪个租户、能否查看这笔订单，必须来自登录态和业务系统，而不是来自模型生成的参数。
三、先把已有 API 收缩成两个 Agent 能力
假设商城已有以下接口：
GET /api/orders/{order_id}
POST /api/after-sales/tickets
并不需要为了 AI 重写一套业务系统。团队可以继续复用原 API，但要为 Agent 明确描述哪些操作允许进入工具目录、需要什么参数、属于什么风险。
例如，查询订单可以声明为只读能力：
paths:
/api/orders/{
order_id}:
get:
operationId: order_get
summary: 查询当前用户有权查看的订单
x-agent-capability:
version: 1
enabled: true
scope: order.read
risk:
level: low
subject:
required: true
execution:
readonly: true
idempotent: true
创建售后工单可以作为首个写能力：
paths:
/api/after-sales/tickets:
post:
operationId: after_sales_ticket_create
summary: 为当前用户有权处理的订单创建售后工单
x-agent-capability:
version: 1
enabled: true
scope: after_sales.ticket.create
risk:
level: medium
subject:
required: true
execution:
readonly: false
idempotent: true
这些声明不是最终权限。
它们表达的是：这项能力可以被 Agent 发现，运行时应该按什么方式对待它。真正执行时，商城仍然要检查：
- 当前用户是否属于正确租户；
- 订单是否存在且对当前用户可见；
- 订单状态是否允许创建售后；
- 相同请求是否已经创建过工单；
- 请求字段是否满足业务校验。
Agent Capability Contract（ACC，Agent 能力契约）可以给这些 Agent-facing 治理语义提供公共表达，但它不会接管商城的最终业务授权。
四、为什么一定要同时做“一读”和“一写”
只做查询，可以验证模型是否会选择工具、身份能否传到业务系统、结果能否正确返回。
但它还不能证明系统具备真正的业务行动能力。
只做写操作又很危险，因为缺少查询上下文时，模型可能根据用户一句不完整的话直接构造操作参数。
一读一写组合在一起，形成了更完整的业务闭环：
用户：帮我看看 ORDER-20260807-001 为什么还没发货
AI：调用 order_get
业务系统：返回已付款、待发货、已超过承诺时间
AI：说明当前状态，并询问是否创建催发货工单
用户：创建吧
AI：调用 after_sales_ticket_create
业务系统：校验用户、订单、状态和幂等键
业务系统：返回工单 TICKET-8921
AI：明确告知工单编号和当前处理状态
这条链路已经包含企业 Agent 最基本的几个问题：
- AI 能发现什么；
- 它代表谁操作；
- 查询结果是否来自真实系统；
- 写操作是否得到用户明确意图；
- 业务系统是否最终接受；
- 重复请求会不会创建两张工单；
- 发生后能否查到请求、执行和结果。
把这条链跑通，比先展示几十个“理论上可调用”的工具更有价值。
五、BailingHub 在这条链路中负责什么
BailingHub（百灵中枢） 是一个开源、自托管的 Agent-to-Business（A2B）控制面。它面向的不是再做一个孤立聊天机器人，而是帮助 Agent 通过受治理的运行链路进入已有业务系统。
在“一读一写”的接入中，可以把工作拆成五步：
- 业务侧发布工具源：从已有 OpenAPI 中只开放
order_get和after_sales_ticket_create； - 中枢配置路由：为当前助手选择模型、工具源和允许使用的能力；
- 业务入口传入可信身份：由已有登录系统提供用户和租户上下文，不让模型生成身份；
- 业务系统保留最终校验：订单权限、状态和写入规则继续由原系统决定；
- 通过任务和 Trace 验证结果：不仅看聊天框说了什么，还看实际调用了哪个工具、使用了什么可信上下文、业务端返回了什么。
BailingHub 不要求企业把商城、CRM 或 ERP 搬进中枢，也不会替业务系统保存最终权限真相。它连接并治理的是“Agent 选择动作”到“业务系统接受或拒绝动作”之间的过程。
这也是开源项目在这里最适合出现的位置：不是用一句“接入 AI”盖住所有复杂度，而是把每个边界做成可以配置、运行和验证的工程链路。
六、首轮接入应该怎样验收
不要只用“聊天窗口成功回复了一段话”作为验收标准。
至少检查下面十项：
- [ ] 未登录用户不能调用业务工具；
- [ ] A 租户用户不能查询 B 租户订单；
- [ ] 模型输出的用户 ID 不会覆盖可信登录身份；
- [ ] 不存在的订单会返回明确失败，而不是由模型补全；
- [ ] 查询接口不会改变业务数据；
- [ ] 创建工单前能让用户看懂即将执行的动作；
- [ ] 相同幂等键重复提交不会生成两张工单；
- [ ] 业务状态变化后，写操作会被业务系统重新判断；
- [ ] 成功结果包含真实工单编号，而不是一段模糊的“已处理”；
- [ ] 控制面和业务系统都能还原这次调用的关键证据。
如果其中任何一项只能回答“应该没问题”，说明这条链路还没有真正完成。
七、最常见的五种错误起点
1. 一次性开放整个后台 OpenAPI
模型看到的工具越多，不一定越聪明，反而更容易选错能力、混淆参数，也扩大了需要治理和审查的范围。
2. 把提示词当权限系统
“你只能查询当前租户订单”是一条模型指导，不是可靠的租户隔离。最终限制必须由可信身份和业务系统代码执行。
3. 只看最终回答，不看真实调用
AI 说“工单已创建”不等于数据库中真的存在工单。验收必须核对真实业务对象、任务状态和 Trace。
4. 写操作没有幂等键
网络超时、页面重试或任务恢复都可能重复提交。没有幂等语义，第一个低风险写操作也可能制造重复数据。
5. 为了 AI 绕开原系统权限
如果原来必须登录、校验租户和检查订单状态，接入 Agent 后仍然必须做。控制面增加了一层治理，不等于业务系统可以少一层授权。
结语：先完成一条窄而真实的链路
已有商城或 CRM，不需要先推倒重做，也不需要一开始就组建一支“AI 员工团队”。
先选择：
一个系统 + 一个对象 + 一个只读动作 + 一个低风险写动作
让真实用户从现有入口发出请求，让 AI 调用已有 API，让业务系统继续做最终判断，再用实际结果和 Trace 证明整条链成立。
当“一读一写”稳定以后，再逐步增加审批、复杂编排和更高后果能力，团队会清楚每增加一步究竟多承担了什么责任。
如果你已经有一套业务后台，最适合先跑通的“一读一写”组合是什么？
- 商城：查订单 + 建售后工单；
- CRM：查客户 + 写跟进记录；
- ERP：查库存 + 提交补货申请；
- 还是另一组更高频的动作？
