VERSION 04 · PRODUCT EVOLUTION

Nexus+Nexus Bot

2026 Q1

Nexus 是面向企业知识工作者的持续型个人 SuperAgent/AI co-worker,Nexus Bot 是这一 Agent 在飞书 IM 中的个人渠道与触达载体。

用户画像
从单次委托转向与同一个 Agent 跨时间、跨渠道持续协作
设计对象
持续身份、关系与任务状态

一个 Agent,多种工作渠道

aily Agent 已经把核心单位从一次对话提升为一项可规划、可执行、可交付的任务,但主要体验仍发生在独立 Web 产品中。与此同时,持续记忆、Skill、Heartbeat、后台任务和跨渠道触达开始成为新的用户预期。

STRATEGIC PRINCIPLE战略原则

渠道不是产品边界,连续性才是

大模型能力变化与竞品研究

当时的大模型能力变化

基础模型、持续运行环境、Session 编排、Context/Memory、Heartbeat/Cron 与多渠道,共同把 Agent 从一次回答扩展为可持续工作的任务系统。

同期公开模型水位长期记忆和持续运行不能只依赖模型;它们需要 Runtime、Workspace、渠道路由和治理共同承接。
  1. 基础模型Kimi K2.5 Thinking;长程推理、规划、工具调用、代码执行与多模态。

    复杂任务与复合产物成为可能,持续性仍需产品承接。

  2. 运行环境Filesystem、Sandbox、Workspace、Skill。

    为任务保存文件、状态与工具环境。

  3. 任务编排Session、Main Agent、Worker/Super Agent。

    支持多任务、子任务和跨渠道结果回传。

  4. 上下文与记忆Context 组装、Pruning、Compaction、Memory。

    区分任务内上下文与长期记忆,使状态可裁剪、可治理。

  5. 主动性与渠道Heartbeat、Cron、事件触发;Web、IM、群侧边栏、Feed/通知。

    支持后台运行和主动触达,并保持身份、任务与结果连续。

DESIGN IMPLICATION整体设计启发

渠道不是产品边界,连续性才是;长期关系建立在可治理的状态之上;自主性必须连同边界与退出机制被设计;任务复杂度决定交互形态,产物决定价值闭环。

产品定位与目标

POSITIONING核心定位

目标:持续型个人 SuperAgent/AI co-worker,以及它在飞书 IM 中的个人渠道与触达载体。

用户不再只在独立产品中主动发起一项任务,而是与同一个个人 Agent 在 Web、单聊、群和通知中持续协作。群成员和协作者是任务上下文与结果流转中的参与者,不是新的 Agent 拥有者。

  • Nexus 不是一个聊天页面或单一 Bot。

  • Nexus Bot 不是另一个独立 Agent,也不是全部复杂任务的唯一工作台。

  • Web/PC 不是与 IM 割裂的第二套账号或第二个 Agent。

产品架构、界面

PRODUCT SYSTEM

统一身份与任务层把入口、Runtime、主动服务、知识工具和治理连接成同一个持续型 Agent。Nexus 承担 Runtime、Session、Memory、Skills、任务执行、主动服务、产物与治理;Bot 与 Web/PC 是共享身份、任务和结果的不同渠道。

用户与工作入口

Web/PC · 飞书 Bot 单聊 · 群侧边栏 · Feed/通知

统一身份与任务层

Onboarding · Agent Profile · Session · Task · Status · Channel 路由

SuperAgent Runtime

Main Agent · Spawn Worker · Context · Memory · Filesystem · Skills · Sandbox

主动服务层

Heartbeat · Cron · Event Subscription/Injection

知识、工具与产物

飞书上下文 · 企业知识 · MCP/业务系统 · Code/Browser · 文档/报告/表格/Slides

治理与可观测

模型 · 权限 · Bot 生命周期 · 日志/评测 · Dashboard · 审计

设计目标与挑战

DESIGN GOALS

先定义要达成什么

  1. 建立持续协作关系的统一心智

    身份、Session、Task、记忆与 Artifact 都属于同一段关系。

  2. 定义 Channel 分工并保证连续性

    Web、单聊、群侧边栏、Feed 与通知共享身份、任务和产物。

  3. 让任务复杂度决定交互与控制

    简单请求按消息完成,复杂与并发任务按 Task 管理。

DESIGN CONSTRAINTS

再看什么阻碍目标

  1. 保持跨渠道状态连续

    单聊、群侧边栏和 Web 需要明确沿用、分叉或新建 Session 的边界。

  2. 按复杂度分配 IM 与 PC

    轻量发起和回传留在 IM,复杂上下文、计划、文件和产物进入 PC。

  3. 让主动服务有价值但不打扰

    主动行为必须可解释、可关闭、可纠错。

设计判断

  • 以持续关系组织产品

    Bot 只是 Channel,前台从工作目标和结果出发。

  • 以 Task 统一多渠道执行

    简单任务留在 IM,复杂与并发任务进入 Web/PC,但共享 Session、Task 与结果。

  • 以 Artifact 完成工作闭环

    对话表达意图,Task 承载过程,Artifact 承载可编辑结果。

  • 把主动性做成可治理服务

    主动行为同时设计来源、权限、状态、去向、频率和退出。

设计策略与动作

STRATEGYKEY TRADE-OFFDESIGN ACTIONS
  1. 以持续关系组织产品

    KEY TRADE-OFF · 关键取舍

    Nexus 是跨 Web 与飞书持续存在的个人 Agent,Bot 只是 Channel;技术概念按需展开。

    DESIGN ACTIONS · 核心动作

    把身份建立、必要授权、能力预期和首次成功任务合并进 Onboarding;用 Agent Profile 统一身份、记忆、Skills、权限、任务与产物。

  2. 以 Task 统一多渠道执行

    KEY TRADE-OFF · 关键取舍

    简单任务留在 IM,复杂与并发任务进入 Web/PC;群上下文只作为单次任务的有边界输入。

    DESIGN ACTIONS · 核心动作

    Main Agent 同步完成轻任务,Worker/Super Agent 异步执行复杂任务;提供状态、进度、取消/恢复和原 Channel 回传。

  3. 以 Artifact 完成工作闭环

    KEY TRADE-OFF · 关键取舍

    对话表达意图、澄清和反馈,Task 承载过程,Artifact 承载可继续编辑的结果。

    DESIGN ACTIONS · 核心动作

    用任务卡和状态面板汇报关键进展;把结果落入文档、表格、Slides 等协作对象;消息、Task 与 Artifact 相互引用。

  4. 把主动性做成可治理的服务

    KEY TRADE-OFF · 关键取舍

    主动行为必须有明确来源、权限边界和退出机制。

    DESIGN ACTIONS · 核心动作

    Heartbeat/Cron/Event 遵循“触发→判断→执行→交付→反馈”;呈现来源、使用数据、状态和去向,提供调频、关闭、撤销和纠错。

Nexus+Nexus Bot 的关键界面与交互结果

0104

Agent Profile/Onboarding

同一 Agent 的身份、能力与关系入口。

IM 发起 → Web 深入

原 Channel 发起、复杂任务跳转和结果回传。

Task/Status/Artifact

长任务状态、取消/恢复与结果交付。

多渠道产物与工作入口

跨入口发现能力,并在同一工作关系中继续处理产物。

阶段结果

智能伙伴于 3 月 19 日正式发布;截至 4 月 7 日,DAU 为 58,431,累计激活 11.5 万,工作日次日留存约 65%。季度复盘口径另记录 NPS > 50、周留存接近 80%,Skill Hub 日安装量 4,000—6,000。

复盘

  • Nexus 与 Nexus Bot 的边界被澄清:Bot 是快速路径,也是结构性妥协;复杂任务依旧需要 Web 承载。
  • Agent 执行、主动服务、飞书 Channel、Profile/治理四条工作流并行推进,需要提前定义跨线依赖和联调节点。