如果 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。
开源的意义在于验证：把产品、工程和生态的协作方式放到更大的开发者网络里去检验。