Remotelab

让AI接手传统行业数字杂活 # 定位 RemoteLab 不是远程终端，也不是只给 AI-native 用户的 IDE；它更像“让普通人把真实机器变成 AI 自动化执行面”的跨端工作台。 现在的第一优先级也很明确：不是先炫多 Agent 编排，而是让用户尽快拿到第一次可信的自动化收益。 # 技术实现思路 控制面采用单一 chat/control plane：手机、桌面、外部渠道都进入同一个入口；状态以 HTTP 读取为准，WebSocket 只做刷新提示，所以断线、刷新、重启都容易恢复。 核心对象是 Session -> Run -> Event：Session 是持久工作线程，Run 是一次执行，底层把不同模型和工具的输出统一规约成事件流，便于回放、审计、重试和跨工具兼容。 执行面是 detached runner：前端负责发起、查看和确认，真正干活的是机器上的本地 Agent CLI；这让它天然支持真机文件处理、脚本运行、浏览器操作和系统级集成。 记忆采用 pointer-first：启动时只给最小上下文，按任务再加载用户记忆、项目背景、技能和领域知识，避免 prompt 越堆越大。 产品面走 session-first：先让用户看到“我要解决的一件事”，而不是 App、Task、User 这些抽象对象；模板、技能、工作流打包更多留在后台逐步沉淀。 外部接入遵循统一消息协议：邮箱、GitHub、IM、语音等都先被规约成“某个线程里来了一个新消息”，所以扩展新渠道时不用重写核心架构。 # Agent进化路径 第一阶段是执行型 Agent：能接任务、调本地工具、保存过程、跨设备回显结果，先把“真能替我做事”做成立。 第二阶段是 intake / PM 型 Agent：不等用户写好 prompt，而是主动澄清目标、补齐输入样例、判断该用脚本、数据处理还是通知流程，先产出 automation brief。 第三阶段是分层智能 Agent：把 基础 Agent / 领域层 / 用户层 / 连接器轴 分开，既提升行业理解，又不把私有数据、共享知识和执行权限混在一起。 第四阶段是编排型 Agent：支持跨 session 上下文新鲜度、分叉、并行子任务和结果汇总，但这些先作为后台能力，而不是一开始就让用户理解 orchestration。 第五阶段是后台常驻 Agent：邮件、GitHub、IM、定时任务等都能持续把更新送进同一工作线程，Agent 从“被动问答”进化成“持续接活、持续交付”的系统。 第六阶段是开放 provider + hosted 化：底层可接不同模型与 runtime，上层继续把模型、机器、权限、隔离复杂度封装掉，最终做到“打开链接就能用”。 # 业务价值说明 对用户，最大价值不是“能聊天”，而是把 Excel 清洗、报表汇总、文件批处理、导出导入、通知同步这类重复数字工作直接交出去，省下真时间。 对非 AI-native 用户，它降低的不是单次推理成本，而是“不会描述问题、不会接工具、不会搭环境”的总门槛；AI 负责把模糊需求收敛成可执行方案。 对高匹配人群，尤其是传统行业里的中层协调者、运营、助理、项目推进者，这种“手机发起 + 真机执行 + 结果回看/审批”的闭环非常贴合真实工作方式。 对产品，session-first + 统一消息协议意味着一个核心架构可以覆盖 chat、邮件、机器人、GitHub、定时任务等多入口，新增场景的边际成本比较低。 对商业化，最自然的路径不是卖“一个模型接口”，而是卖“持续替你完成一类工作”的工作台：可按席位、自动化流程数、连接器能力、行业包、托管服务分层收费。 对长期壁垒，真正沉淀下来的不是某个 prompt，而是用户侧工作上下文、可复用流程模板、连接器集成和交付信任，这会比纯聊天产品更难替代。 [ 队伍介绍 ] - [ 队伍成员介绍 ] 酒嘉年 judy 乾雨