聊天机器人
文本生成。会幻觉, 更可怕的是, 它会替你编出事实, 替你做出承诺, 仅仅是因为这在对话听起来很顺。 没有运行时状态, 既不知道用户是谁, 也不知道跑到了哪一步。没有业务状态。
beta · 现已上线
Hyperbolic.双曲线
为多步业务流打造的
对话操作系统
把你产品里的多步业务流程变成对话, 同样的 API, 同样的业务逻辑, 更高的完成率。
对话能搞定的, 用对话。搞不定的, 用界面。同一段会话, 状态不丢。
一次订票, 从头到尾 —— 运行时驱动你的 API, 对话问对的问题, 界面接手对话搞不定的事。一段会话, 一笔订单走完。
Agent
查询中
订明天晚上的两张剧院票
正在查明天的演出场次
输入消息
查询中 —— 调用你的 API。
Agent
等待中
明天有 7:30 和 9:45 两场，你要哪一场？
输入消息
询问中 —— 停下，等你回复。
Agent
对话继续
已下单 —— H 14 & H 15，7:30 场。确认信刚刚发到你的邮箱。
还有别的吗？
输入消息
对话继续 —— 任务结束, 对话继续。
Agent
展示界面
要 7:30 那场
好的 —— 在右边的座位图上选位 →
输入消息
选座 · 7:30 场
可选
已售
你的
打开界面 —— 展示你的界面, 不仅仅是对话而是富文本界面。
常见业务流程
为这些多步骤业务流程而生:
- 预订
- 下单
- 开户
- 实名认证
- 退款
- 保险理赔
- + 更多
今天, 每一段稍微复杂一点的业务流程对于用户来说都是一次页面迷宫。进入表单, 填三个字段, 点下一步, 撞上一个校验错误, 返回, 修改, 再点下一步, 反复。每一次跳转都可能导致用户流失, 这些用户流失本不应该出现。
到了对话应用里, 情况反过来了。AI引导, 用户跟着走。按顺序问对的问题, 在对的时机调用你的 API, 出错的时候提示什么错误了, 如何修改。用户费力摸索, 变成了只需要轻松跟随; 用户费劲找路, 变成了系统带路, 没有页面跳转压力, 一次就完成任务。同样的业务, 同样的结果, 用户不会再迷失在页面中。
同样的 API。同样的业务逻辑。更少的错误, 更少的用户流失, 更高的完成率。
真正的差别
为什么是对话操作系统 —— 而不是又一个聊天机器人。
不是聊天机器人, 不是工作流编辑器, 也不是 Agent 框架。
作为一个操作系统, 我们维护对话和任务的运行时状态, 确保一切按照预期执行。
工作流编辑器
有节点, 有变量映射, 有重试, 但节点之间的状态依然装在LLM的上下文窗口里。一旦LLM幻觉, 整个流程都需要废弃。相当于把LLM 当数据库用, 但是它会忘事。
Agent 框架
由 LLM 决定下一步调什么。但是如何让LLM理解下一步应该做什么, 以及如何让LLM严格遵循你的业务规则依然是大问题, 还有那尖端模型带来的无法控制的成本。
构建、打包和发布
一个链接, 客户打开就用。
无账号, 无安装, 用户那一侧不需要做任何集成。一个 URL 把你的客户直接送进一个托管的对话应用 —— 它已经知道该怎么一步步把业务跑完。
怎么搭起来的
-
任务
把你的 API 串成一段流程。决定什么时候问用户, 什么时候交给侧面板。
-
Agent
选定一个 Agent 能跑哪些任务, 加上 guardrails, 起个名字。
-
一个链接
你的 Agent 上线。把 URL 发出去, 你的客户在这个链接里走完整段业务。
Hyperbolic
走进控制台
在控制台里面定义和调试任务, 搭建智能体, 提交, 发布和回滚, 全流程可视化, 让你放心调整你的Agent。
我的任务
我的 Agent
API Keys