货代公司的官网，经常会遇到这样一类访客。
他还没有加销售企业微信，也没有进客户群，只是在网站上看产品、看服务，然后突然产生一个问题：
你们能不能做美国线？
这个系统适合报关公司吗？
怎么申请试用？
你们支持哪些业务类型？
如果官网上只有一个电话号码或者“联系我们”按钮，这个访客接下来可能有两个选择：
主动加销售。
或者：
直接关掉网页。
立刻智能体的网页组件，解决的就是中间这一段。
在自己的官网右下角放一个悬浮客服按钮。
访客有问题时点开，
直接和企业自己的 AI 智能体对话。
它更像官网里的第一名“售前客服”
网页组件最适合的，不是已经合作多年的老客户。
而是：
还没有进入企业私域的访客。
例如一个潜在客户通过搜索引擎进入货代官网。
他可能正在看：
- 海运服务
- 空运服务
- 报关服务
- 软件功能
- 产品价格
- 试用说明
这时候，他脑子里可能只有一个很简单的问题：
你们这个能不能做？
如果为了得到答案，还需要先：
找联系电话 → 加微信 → 等销售通过 → 再重新描述一遍问题
这个转化链条其实很长。
网页组件的作用，就是把第一轮沟通留在官网里完成。
访客不需要登录。
也不需要先成为微信好友。
点开右下角的客服入口，就可以直接提问。
访客问的，还是企业自己的智能体
网页组件本身不是另外一套独立客服系统。
它只是立刻智能体的一种接入渠道。
也就是说，企业在立刻智能体里已经维护好的：
知识库、智能体设定以及绑定技能，
都可以继续成为官网客服回答问题时的能力来源。
例如知识库里已经维护：
如何申请试用？
支持哪些业务类型？
软件如何收费？
系统在哪里下载？
访客在官网问到这些内容时，AI 就可以根据企业自己的资料回答。
如果当前智能体还绑定了相应技能，也可以在上线前使用真实问题进行验证。
所以企业不需要为了官网客服再重新维护另一套知识。
核心仍然是：
同一个智能体，通过不同渠道提供服务。
接入方式，比自己开发一套聊天窗口简单得多
网页组件的目标，就是让企业能够比较轻量地把 AI 客服放进自己的网站。
创建好网页组件以后，将对应嵌入代码放到网站页面中。
网站上就可以出现悬浮客服入口。
例如可以把它配置成：
官网售前客服
访客点击以后，即可展开聊天窗口。
这种方式更适合：
我要快速在官网放一个 AI 客服入口。
而不是为了一个聊天窗口，再单独开发：
前端页面、会话接口、鉴权、聊天记录以及人工接待逻辑。
一个很重要的安全细节：嵌入代码里没有 API Key
企业在把第三方能力嵌入网站时，经常会担心一个问题：
网页源代码里会不会暴露接口密钥？
立刻智能体网页组件的嵌入代码：
不包含 API Key。
网页组件使用的是组件自己的：
widget_token
进行鉴权。
所以它并不是把开放 API 的密钥直接写进浏览器端代码。
这点尤其重要。
因为网页代码最终需要发送给访客浏览器。
如果把真正的 API Key 暴露在前端，本身就是非常不合理的做法。
网页组件因此采用的是自己独立的组件鉴权方式。
网页组件，也不是偷偷调用 /api/v1/chat
这一点同样容易混淆。
立刻智能体还提供开放 API。
开发者可以通过：
/api/v1/chat
把智能体能力集成进自己的业务系统。
但：
网页组件不是通过这套开放 API 工作的。
它有自己独立的接入链路。
因此系统设置里的：
“AI 会话”开关
以及：
v1 API 白名单
并不会直接影响网站上的组件访客。
简单理解：
网页组件是一条渠道。
开放 API 是另一条渠道。
不要因为两者最后都能和智能体对话，就把它们当成同一套接口。
只给组件用的 Key，不一定要进开放 API 白名单
有些配置场景里，某个 Key 可能只是配合网页组件完成：
统计
或者：
转人工
等相关用途。
如果这个 Key 并不用于调用开放 API，
就没有必要因为网页组件而把它加入 /api/v1/chat 的开放 API 白名单。
这个区别看起来比较技术化，
但对于实际部署很重要。
否则企业很容易为了“让组件能用”，把不需要开放的接口权限一起放开。
正确的理解应该是：
组件按组件的规则配置。
开放 API 按开放 API 的权限控制。
两边不要混着处理。
基础版没有网页组件
网页组件并不是所有套餐都提供。
当前规则是：
基础版：不提供网页组件
专业版：最多 2 个
旗舰版：最多 10 个
为什么需要多个网页组件？
因为一家企业可能不止一个网站入口。
例如可能有：
公司官网
产品官网
某个专题落地页
甚至不同站点希望配置不同的智能体、不同的欢迎方式或者不同的人工接待策略。
专业版最多可以建立 2 个。
旗舰版最多可以建立 10 个。
具体套餐能力仍以立刻智能体控制台和帮助中心为准。
新建完以后，别忘了打开“功能开关”
创建网页组件时，可以先填写一个便于自己识别的名称。
例如：
官网售前客服
或者：
国际物流官网客服
但创建完成，并不意味着网站上立刻开始提供服务。
还需要在对应组件配置中打开：
功能开关。
只有功能处于启用状态时，
网站上的组件才会正常显示和工作。
这一点很适合在上线前作为检查项。
因为有时候代码已经部署，页面上却看不到客服入口，
原因未必是网站代码错了，
也可能只是组件本身没有启用。
要不要显示“人工客服”按钮，可以自己决定
AI 不一定需要承担所有问题。
特别是售前阶段，很多客户聊到最后会进入：
报价
商务谈判
定制需求
复杂方案咨询
这些事情最终还是可能需要销售或者客服人员参与。
因此网页组件可以配置：
是否显示人工客服按钮。
如果企业希望：
AI 先处理第一轮常见问题，
需要时用户再主动找人工，
就可以打开人工入口。
如果当前企业还没有安排人工坐席，
也可以暂时关闭人工按钮。
所以组件并不是强制要求：
AI + 人工必须同时出现。
企业可以根据自己的客服流程决定。
还可以在 AI “答不上来”时自动转人工
比让访客自己点“人工客服”更进一步的方式，是：
根据 AI 的回答自动判断是否应该转接。
例如企业可以设置一类拦截短语：
无法回答
暂时没有找到相关信息
建议咨询人工客服
当 AI 的回答中出现这些指定短语时，
组件可以触发自动转人工。
这样就形成一个比较自然的流程：
AI 能回答 → AI 继续处理
AI 无法可靠回答 → 转人工
而不是要求访客自己发现：
“这个机器人已经答不上来了，我是不是应该再找个人？”
拦截短语也可以自己配置
不同企业设计智能体提示词的方式不一样。
有人可能要求 AI 在没有知识时回答：
暂无相关资料。
有人可能写成：
当前知识库无法确认。
也有人统一要求：
建议转人工确认。
因此自动转人工的拦截短语可以自定义。
企业可以让它和自己的系统提示词配合。
例如你已经在智能体里规定：
知识库没有可靠答案时，必须回复“建议联系人工客服确认”。
那么就可以把相应文字配置为转人工触发条件。
这样 AI 在无法确认时：
不是继续猜，
而是把会话交给真人。
不配置拦截短语，也可以使用默认规则
如果企业暂时不想自己设计这一套短语，
也可以留空。
留空时使用系统默认的拦截短语逻辑。
对于刚开始上线 AI 客服的企业来说，
可以先使用默认配置，
等实际积累一段时间的访客对话以后，再根据真实问法调整。
例如观察：
客户最常在哪些问题上需要人工？
AI 什么情况下容易回答不完整？
哪一种转接提示对客户最自然？
有了真实对话，再优化会比上线第一天就设计一套非常复杂的规则更实际。
转人工之后，人工在哪里接？
当网页组件开启人工客服能力以后，
需要人工处理的访客会话，可以进入：
访客协助
相关流程。
坐席可以在控制台接入对应会话。
这时候整个过程就从：
AI 自动服务
切换为：
真人继续沟通。
对访客来说，他不需要重新跳到另一个网站，也不需要把前面的问题全部再说一遍。
官网聊天窗口仍然是同一个入口。
这也是网页组件相比单纯放一个“添加微信”二维码更适合承接即时咨询的地方。
还可以打开“追问气泡”
很多访客进入网站以后，并不会主动点击客服。
他可能只是：
浏览页面，
停留十几秒，
然后离开。
网页组件可以配置：
追问气泡。
也就是通过一个更加主动的提示，引导访客开始对话。
不过这里有一个前提：
除了网页组件自己的相关设置之外，
还需要在系统设置中打开：
全局追问。
两边配合后，追问能力才能真正生效。
所以如果已经打开组件配置，却发现网站没有出现预期的追问提示，
也需要检查系统级开关。
对货代官网来说，追问内容最好别太“客服腔”
例如访客正在查看货代软件介绍页。
如果突然弹出一句：
尊敬的客户您好，请问有什么可以帮助您的吗？
其实很容易被忽略。
更适合真实业务场景的方式可能是：
想了解系统是否适合你的业务？可以直接问我。
或者：
海运、空运、报关系统怎么选？可以直接问。
甚至：
想申请试用？直接告诉我你的业务类型。
核心是让访客快速知道：
这个按钮能解决什么问题。
而不是只告诉他：
“这里有一个客服”。
当然，具体话术仍然应根据企业自己的实际业务配置。
上线前，最好别只测试“你好”
网页组件部署完成以后，一个很常见的问题是：
技术人员点开窗口，
输入：
你好
机器人回复：
您好，请问有什么可以帮助您？
然后就宣布：
测试通过。
但这只能证明：
聊天窗口能打开。
并不能证明真正的售前场景可以工作。
更合理的测试方式应该使用客户真实会问的问题。
例如：
你们支持海运出口吗？
报关公司可以用吗？
怎么申请试用？
软件多少钱？
系统能不能管海外代理费用？
这些问题能够验证：
知识库有没有相关内容
智能体有没有正确理解问题
回答是否符合企业口径
没有答案时会不会乱编
这才是真正的上线测试。
如果智能体绑定了技能，也要顺手测试一次
如果作为官网客服的智能体已经绑定了一些实时查询技能，
上线前最好也验证对应能力。
例如：
今天美元兑人民币汇率是多少？
或者：
不锈钢保温杯的 HS 编码是什么？
这样可以确认：
从网页组件进入的访客，
智能体是否能够正常完成技能调用和结果回复。
所以测试不能只覆盖知识库。
应该根据这个智能体实际绑定的能力来验证。
桌面端能用，不代表手机端就一定没问题
货代官网现在的访问来源，不可能全部来自电脑。
很多客户会直接通过：
微信链接、
搜索结果、
同事转发，
在手机浏览器里打开网站。
因此网页组件上线前至少应该分别检查：
电脑端
和：
手机端。
重点看几个地方：
客服悬浮按钮会不会挡住网站原有内容？
展开以后高度是否正常？
输入框能不能用？
返回、关闭是否自然？
文字会不会太小？
人工客服入口是否正常？
如果网站本身还有其他悬浮按钮，例如：
电话
微信
返回顶部
更要检查几个按钮之间有没有互相覆盖。
网页组件和企微机器人，解决的不是同一个入口问题
前面几篇文章一直在讲企业微信外部群。
那么可能有人会问：
已经有企微机器人了，为什么还需要网页组件？
因为两者面对的人群不一样。
企微机器人更适合：
已经进入企业微信沟通体系的客户。
例如客户已经在外部群里。
他要查订单、要文件、问业务规则，
直接在群里 @ 机器人最自然。
而网页组件面对的更多是：
还没有进群的人。
他可能甚至还不知道你们销售是谁。
所以可以简单理解成：
官网访客 → 网页组件
已经进企微群的客户 → 企微机器人
两个入口可以使用同一套智能体能力，
但服务的是客户旅程中的不同阶段。
典型的官网售前场景，可以是这样的
假设一个货代老板通过搜索进入立刻云官网。
他看了一会儿以后问：
你们这个系统支持空运出口吗？
网页右下角的 AI 客服根据知识库回答。
他继续问：
能不能申请试用？
AI 根据企业已有说明告诉他申请方式。
接着客户问：
我们公司业务比较特殊，还要和海外代理对账，这种能不能做？
如果知识库中已有明确答案，AI 可以继续回复。
如果无法确认，
系统根据配置识别到对应拦截短语，
自动转给人工。
于是整个过程变成：
访客先问 AI
↓
标准问题自动回答
↓
复杂问题交给人工
销售不用从每一句：
“你们是什么系统？”
开始重复解释。
更值得人工参与的部分，
留到客户真正产生明确需求以后再处理。
网页组件最大的价值，不是“网站多了一个聊天框”
如果只看表面，
网页组件不过是在官网右下角增加了一个按钮。
但真正有价值的，是这个按钮后面连接的东西。
它连接的是：
企业自己的知识库
企业自己的智能体
已经配置好的技能
以及：
需要时可以接入的人工客服。
这样官网不再只是：
展示信息。
而开始能够：
回答问题。
过去访客看完官网以后，还需要自己决定下一步去哪里找人。
现在则可以在产生问题的那个瞬间，
直接开始沟通。
不同渠道，不必重复建设一套 AI
如果企业以后同时有：
官网、
微信公众号、
企业微信、
自己的业务系统，
最麻烦的方式，是每个渠道都单独做一套机器人。
每个机器人都有自己的知识，
自己的回答规则，
自己的维护方式。
这样最终一定会出现：
官网回答 A，
企微回答 B，
公众号又回答 C。
立刻智能体更希望解决的是：
智能能力统一维护，渠道按需要接入。
知识库仍然是一套。
智能体仍然是一套。
只是客户从不同入口进来。
官网访客通过网页组件。
企业微信客户通过企微机器人。
自己的系统如果需要深度集成，则可以使用开放 API。
网页组件和开放 API，应该怎么选？
如果你的需求只是：
在官网右下角快速放一个 AI 客服窗口，
优先使用网页组件。
因为组件本身已经处理了前端交互和渠道逻辑。
而如果你的需求是：
把智能体深度集成到自己的产品页面、业务系统或者自定义流程里，
那更适合使用：
开放 API。
两种方式解决的是不同层级的问题。
可以简单记成：
要现成客服窗口 → 网页组件
要自己设计交互和业务流程 → 开放 API
最后
很多货代企业做官网时，重点往往都在：
页面设计得好不好看，
产品介绍够不够完整，
案例有没有放齐。
但一个潜在客户真正进入网站以后，最关键的时刻往往只有几秒钟：
他突然有了一个问题。
如果这个问题可以马上得到回答，
对话就可能继续。
如果必须先找联系方式、加好友、等人工，
有些访客可能就离开了。
所以网页组件看起来只是一个很小的入口。
它解决的却是官网里非常现实的一段链路：
客户产生问题的那一刻，先把对话接住。
能由知识库解决的，让 AI 回答。
AI 无法确认的，再转给人工。
已经进入企微群的客户，则继续在他们熟悉的群里查单、答疑。
不同渠道各自做最适合自己的事情，
背后仍然使用同一套企业智能能力。
这可能才是一个官网 AI 客服真正应该有的样子。