这场分享围绕一个核心问题展开:如果 Agent 不只是聊天窗口,而是能贯穿桌面端、Web 应用、云端服务、插件生态和多 Agent 协作的个人助理,产品和工程系统应该如何搭建?
我的答案来自 LobsterAI 的实践。它最早从有道教育场景里的 AI 能力长出来,服务过词典笔、答疑笔、听力宝等智能硬件,也落地过小 P 老师、视频答疑等产品能力。教育场景要求输出稳定、反馈清晰、边界可控,这些约束后来成为通用 Agent 产品化时最重要的底层经验。
从垂类场景到通用 Agent
教育类 Agent 的输入通常很具体:题目、图片、语音、文本,以及用户希望获得的解释。通用个人助理的输入更开放,可能是文档、网页、邮件、数据表、PPT、视频素材,也可能是一串很模糊的目标。
因此 LobsterAI 的关键不是把能力堆在界面上,而是把工作流拆成可理解的任务链路:输入如何进入系统,Agent 如何规划,工具如何被调用,执行结果如何确认,最终产物如何交付给用户。
OpenClaw 与工程化迁移
早期版本使用 Claude Agent SDK 快速验证,但长期维护会遇到模型协议、运行环境和生态接入的限制。迁移到 OpenClaw 后,LobsterAI 可以复用更成熟的工具生态、MCP Bridge、多 Agent 能力和插件体系。
工程上,关键设计是把 OpenClaw 作为独立 Gateway 进程运行,桌面端和业务系统通过 WebSocket RPC 通信。这样做可以隔离引擎崩溃风险,也让引擎升级、能力灰度和业务功能迭代拥有更清晰的边界。
产品边界
一个可用的 Agent 产品需要同时处理能力展示和安全约束。LobsterAI 在提示词约束、危险操作确认、HTTP 阻断、超时控制、UI 简化和任务状态反馈上做了大量工程化处理,让用户看到的是一个能做事的助理,而不是复杂框架的裸露接口。
未来方向
Agent 的形态正在从 Chatbot 演进到更接近操作系统的执行层。LobsterAI 关注的是让个人、团队和开发者都能把前沿模型能力接入真实工作流:数据分析、文档处理、PPT 生成、视频处理、邮件任务、插件开发和 Vibe Coding。
开源不是展示技术本身,而是把产品、工程和生态的协作方式放到更大的开发者网络中验证。