给现有业务系统接 AI 助手，入口怎么选？网页聊天、自动化任务与本地 Agent 对比

三种入口分别适合什么场景？

如果你只想用 30 秒做第一次判断，可以先记住下面四句话：

人已经登录业务后台，并且任务依赖当前页面和当前账号：优先选网页聊天。
任务由订单事件、定时器或固定流程触发：优先选 API / 自动化任务。
任务需要读取本机文件、调用操作系统能力，或进行跨系统的动态多步规划：优先选本地 Agent。
**三种入口不是三选一。**同一套业务系统可以让客服从网页发起，让定时任务从 API 发起，也让管理者在本地 Agent 中处理复杂任务。

真正需要统一的，是业务动作、可信身份、允许范围、审批和审计；不是强迫所有人都从同一个界面进入。

一、先分清三个维度：入口、连接协议和治理层

很多选型讨论之所以越聊越乱，是因为把三个不同问题混在了一起。

1. 入口：任务从哪里开始？

入口解决的是用户体验和触发方式：

网页聊天：由当前正在使用后台的人发起；
自动化任务：由业务事件、定时器或工作流发起；
本地 Agent：由电脑上的智能体客户端发起。

2. 连接协议：它们怎样调用能力？

HTTP API、OpenAPI、SDK 和 Model Context Protocol（MCP）解决的是"怎样连接"。

MCP 不是网页聊天之外的"第四种入口"。本地 Agent 可以通过 MCP 发现和调用能力，自动化平台也可以通过 HTTP API 发起任务；同一个入口甚至可以组合多种协议。

Dify、n8n 也不天然等于某一种入口。它们既可以承接表单和人工触发，也可以接收业务事件、运行定时流程。选型时应先问"谁触发任务"，再决定使用哪个平台和协议。

3. 治理层：这次操作凭什么允许执行？

治理层回答的是另一组问题：

当前代表哪个业务用户？
这个入口可以看到哪些业务动作？
写操作是否需要审批？
最终执行结果怎样追溯？

以 BailingHub 为例，网页聊天、Client API 和本地 Agent 可以进入同一套能力治理与审计体系，但身份和会话语义由各入口分别建立：网页使用业务后端签发的短票据；Client API 使用 Client Token 认证接入方，只在需要代表具体用户时由已鉴权业务层派生主体；本地 Agent 使用浏览器授权建立可撤销的 Agent Session。三者不能互换凭据或直接共享会话。入口、协议和治理是可以组合的三层，不应画成互相替代的三个产品框。

二、用同一个业务动作，比较三种入口

假设我们要完成一件很常见的事：

查询订单状态，判断用户反馈的问题，并在符合条件时创建一条售后工单。

同一件事放在三种入口里，体验会完全不同。

网页聊天：客服正在订单后台处理问题

客服已经登录商城后台，当前页面就是订单详情。他在右下角聊天窗口中输入：

看看订单 SO-1001 为什么还没发货，如果需要跟进就创建一条售后工单。

此时网页入口的优势是离业务现场最近：当前用户、当前门店和当前页面都容易建立对应关系，执行结果也可以直接返回原后台。

但页面的 path、title 或自定义 context 只能作为帮助模型理解的线索，不能作为可信身份、订单归属或工具放行依据；这些页面信息可能被前端修改。可信身份仍应来自业务后端签发的短票据，订单归属和最终权限仍由业务系统校验。

自动化任务：订单超时事件自动触发

业务系统检测到订单超过约定时间仍未发货，通过服务端调用提交一个任务。它不需要等待模型在同一次 HTTP 请求里完成全部工作，而是先获得任务编号，再轮询或接收签名回调。

这种方式适合规则明确、量较大、需要重试和幂等的流程。发起方不是正在聊天的人，而是持有受限 Client Token 的受信任服务端或自动化平台；业务事件本身不是身份凭证。

本地 Agent：运营结合本机材料做多步处理

运营人员电脑上有一份客户投诉材料，需要先读取本地文件，再查询订单、比对内部说明，最后决定是否创建工单。

这时本地 Agent 更合适，因为编排发生在用户电脑上的智能体中，本机文件和本地工具可以参与推理；BailingHub 仍负责把可调用的业务能力按授权范围交给它，并记录实际发生的业务调用。

这三个流程调用的可以是同一组订单与工单 API，但任务发起者、上下文来源和身份建立方式并不相同。

三、八个维度的入口选型表

判断维度	网页聊天	API / 自动化任务	本地 Agent
主要发起者	已登录后台的业务人员	业务事件、定时器、工作流	使用本机智能体的人
关键上下文	当前页面、当前订单、当前登录态	事件载荷、流程变量、业务记录	本机文件、桌面工具、跨系统信息
身份 / 凭据来源	业务后端基于现有登录态签发短票据	Client Token 认证接入方；需要时由已鉴权业务层派生业务主体	浏览器授权后建立可撤销 Agent Session
编排主要发生在哪里	中枢会话与路由	上游系统 / Dify / n8n 与中枢任务	本地智能体负责规划，中枢负责能力治理
交互节奏	面向人的对话与流式反馈	适合异步提交、轮询或回调	面向人的多轮规划与工具调用
是否需要本机资源	通常不需要	通常不需要	需要时优势明显
最小接入改动	嵌入脚本 + 业务后端签票	服务端接入稳定 Client API	安装客户端插件 + 公共连接配置 + 浏览器授权
第一条验收动作	当前用户查询一条测试订单	一个测试事件触发一条无副作用任务	读取一份脱敏本地材料并查询测试数据

这张表里最容易被忽略的是"可信身份来源"。同样一句"查询订单"，从网页、自动化平台和本地 Agent 发起时，不能因为文本相同就默认代表同一个用户。

四、什么场景优先选择网页聊天？

最适合

客服、运营、销售等人员本来就在后台工作；
问题和当前页面、当前订单或当前客户强相关；
希望降低培训成本，不要求用户另外安装客户端；
需要把结果直接呈现在现有系统中。

不应该优先选

没有人值守、必须由事件自动触发；
任务依赖本机文件或操作系统能力；
需要跨多个系统进行较长时间的动态编排。

最少需要接入什么

网页端可以嵌入聊天脚本，但可信业务身份不能由浏览器随便填写。业务后端应根据现有登录态签发短时票据，再交给组件使用；接入方的 Client Token 不能进入前端。

还要注意，visitor_id 只适合维持匿名访客的会话连续性，Origin 白名单主要防止聊天组件被其他网站盗嵌，两者都不能代替业务身份鉴权。

怎样算第一条路径跑通

用一个真实的测试账号登录后台，让它查询一条该账号本来就有权看到的测试记录。换成另一个无权限账号后，应由业务系统最终拒绝，而不是只看聊天窗口能否返回一句话。

五、什么场景优先选择 API / 自动化任务？

最适合

新订单、退款申请、工单超时等业务事件；
每天、每小时运行的固定任务；
Dify、n8n 或自有工作流已经承担流程编排；
希望把提交和结果获取解耦，并支持幂等重试。

不应该优先选

用户需要围绕当前页面连续追问；
每次任务都高度依赖个人电脑上的临时材料；
流程尚未收敛，连第一条业务动作是什么都没有定义。

最少需要接入什么

BailingHub 的稳定 Client API 公共面只需要三个端点：

text 复制代码

GET  /health
POST /run
GET  /jobs/{job_id}

提交任务时核心输入是：

json 复制代码

{
  "request_id": "after-sales-1001",
  "route": "after_sales_assistant",
  "input": "查询测试订单 SO-1001，并判断是否需要创建售后工单"
}

POST /run 是异步提交，返回 202；同一次业务请求重试时应复用 request_id，避免重复执行。Client Token 只放在服务端或自动化平台的安全凭据区，它标识接入方，不会自动变成某个终端用户。若任务需要代表具体用户，主体仍应由已经完成鉴权的业务层派生。

怎样算第一条路径跑通

先用一条无副作用或可回滚的测试路由，验证：提交成功、获得同一个任务、能够读到终态、重复提交不会重复执行。之后再增加真实写操作。

六、什么场景优先选择本地 Agent？

最适合

需要读取电脑上的文档、表格、代码或其他本地材料；
需要调用本机工具，再结合业务 API 完成多步任务；
用户希望在独立智能体客户端里管理多个业务连接；
任务步骤不固定，需要智能体根据中间结果动态规划。

不应该优先选

只是想把现有网页聊天原样套一层桌面壳；
所有用户都在同一个后台页面完成简单问答；
业务侧还没有任何可调用能力，却希望客户端直接"接管任意网页"。

本地 Agent 的价值在于本地编排和本机能力。如果它只是把一句话转发给中枢，再等待中枢完成全部思考，那么普通聊天客户端通常已经足够。

最少需要接入什么

开发者分发的是不含秘密的连接信息，例如：

text 复制代码

hubUrl
clientAppId
workspace
connectionName

用户添加连接后，通过系统浏览器进入业务系统自己的授权页面，确认当前登录身份，再建立可撤销的 Agent Session。中枢侧还要启用对应的 Agent Runtime 和允许路由；仅仅安装一个 MCP 插件，并不会凭空获得业务权限。

怎样算第一条路径跑通

让用户明确选择一个测试身份，读取一份脱敏本地材料，再调用一条只读业务能力；在中枢后台应能对上会话、能力调用和结果。之后再验证一条低风险、可回滚的写操作。

七、三种入口可以共存，但不能混用凭据和会话

合理的组合不是维护三套完全不同的业务 API，而是：

text 复制代码

网页聊天 ─┐
自动化任务 ├─> 统一的能力与治理层 ─> 现有业务 API
本地 Agent ─┘

三种入口可以复用：

同一批明确开放的业务动作；
相同的能力参数与结果结构；
一致的风险、审批和审计口径；
经过入口适配的路由、知识和工具范围配置。

但下面这些秘密和会话不应被跨端分发或混用：

下发到网页或本地 Agent 的 Client Token；
浏览器 Cookie；
Agent Session；
会话上下文；
未经重新确认的业务主体。

推荐按入口和职责拆分接入方，以获得更小的 route 白名单和更清楚的审计边界。如果受信任服务端确实复用同一个接入方，Client Token 也只能留在服务端，不能复制到网页组件或本地客户端，并且不同入口的路由与审计仍应可区分。

"统一治理"不等于"把同一把钥匙分发给所有入口"。真正的统一，是每次调用都能说明它从哪里发起、代表谁、被允许做什么，以及最后由哪个业务系统完成授权。

八、四个问题，选出你的第一条入口

如果团队还在争论，可以按下面四问做决策：

问题 1：任务是谁发起的？

人正在后台操作：先看网页聊天；
业务事件或定时器：先看 API / 自动化任务；
人在独立智能体中发起：继续看本地 Agent。

问题 2：任务最重要的上下文在哪里？

当前页面和当前登录态：网页聊天；
结构化事件和流程变量：自动化任务；
本机文件、桌面工具和跨系统材料：本地 Agent。

问题 3：可信业务身份从哪里来？

现有后台会话：由业务后端签发短票据；
服务端事件：由已鉴权业务层派生主体；
本地客户端：通过浏览器授权建立 Agent Session。

如果这一问回答不出来，先不要开放写操作。

问题 4：第一条验收动作是什么？

不要从"让 AI 管理整个商城"开始。把目标缩小成：

text 复制代码

一套系统
+ 一个真实测试用户
+ 一条明确业务动作
+ 一个首选入口

例如：

让开发调试门店的客服，从网页聊天查询一条测试订单。

或：

让订单超时事件通过 API 创建一条测试跟进任务。

或：

让本地 Agent 读取一份脱敏投诉材料，并查询对应测试订单。

只要第一条链路的身份、结果和审计能够对上，再扩展第二个入口会容易很多。

九、几个常见问题

后台 AI 助手应该嵌入现有系统，还是做独立客户端？

如果主要使用者一直在业务后台，任务依赖当前页面，优先嵌入；如果任务依赖本机文件、桌面工具或跨系统动态规划，独立客户端更合适。不要因为"桌面端看起来更像 Agent"就默认选择更重的方案。

MCP 是入口、连接协议还是治理层？

MCP 更接近连接与能力交换协议，不是业务入口，也不会自动完成终端用户身份、业务审批和最终授权。网页、自动化任务和本地 Agent 都仍需要自己的身份与治理链路。

三种入口能否共用同一套业务 API？

可以，而且通常应该复用业务系统已有的、经过明确开放的 API 或薄适配层。不同入口必须分别建立可信身份；接入凭据推荐按入口和职责拆分，并始终只保存在受信任服务端或系统安全存储中。业务系统仍保留最终权限判断。

没有业务 API，能不能直接让 AI 操作后台？

BailingHub 不模拟任意网页点击，也不会读取业务数据库或凭空创造业务能力。没有可调用接口时，应先为一条明确动作补充 API 或薄适配层，再选择入口。

第一条接入路径应该怎样验收？

不仅要看"AI 回答成功"，还要核对：发起身份是否正确、只暴露了预期动作、业务系统是否完成最终授权、重复请求是否安全，以及中枢能否查到对应执行记录。

结语：先选入口，再选平台和协议

给现有商城、SaaS、CRM 或 ERP 接入 AI 助手时，入口选择决定了用户体验、上下文和身份从哪里来；平台与协议则决定它怎样连接和编排。

最稳妥的起点不是一次性规划一个"万能 AI 员工"，而是先回答：

谁在什么地方，代表哪个真实业务身份，完成哪一条动作？

如果人就在后台，从网页聊天开始；如果任务由事件触发，从 API / 自动化任务开始；如果必须使用本机资源和动态规划，从本地 Agent 开始。三者成熟后可以共存，但每一条路径都必须独立建立可信身份和可追溯执行链路。

你可以先运行 BailingHub 公开 Docker Demo，再按第三方对接指南选择网页、Client API 或本地 Agent 路径。如果已经有业务 API，也可以只整理"一套系统 + 一条动作 + 一份脱敏接口说明"，通过 Integration Evaluation开始第一条接入评估。

项目地址：https://github.com/bailinghub/bailinghub