一个 desktop-first、local-first、multi-runtime 的 Agent Workbench。如果要说得更完整一些，它还是一个正在持续扩展长期上下文、远程访问和发布能力的工作系统。 如果换成更贴近 Agent 设计语言的说法，它也可以被理解成：
- 给顶尖模型加上
project harness的工作系统 - 让 Context Engine、Context Connector 和 Host / Client 边界协同工作的产品层
- 让 Agent 不只停留在 code，而是继续进入真实工作现实的执行系统
它不是什么
为了避免误解，先明确三个“不是”：- 不是单一聊天框产品 对话只是入口之一，不是全部产品边界。
- 不是只服务单一 runtime 的包装壳 ContextGo 默认支持多 runtime、多种能力装配方式。
- 不是把手机当成主机的移动优先产品 手机和网页更接近远程使用面，桌面主机才是执行权威。
它真正解决的问题
现实工作不会只存在于一个输入框里。真正影响结果质量的，通常分散在：- 本地文件和项目目录
- 网页、浏览器上下文和研究材料
- 文档、规范、历史结果
- 外部系统、渠道和不同设备
和普通 AI 工具相比，差异在哪里
普通 AI 工具更常见的重心是：- 一个对话框
- 一个模型或一个 Agent
- 一次性问答
- 一次性执行
- 工作台
- project harness
- 长期上下文
- 多 runtime 协同
- 自动化能力
- 远程使用
- 对外发布到真实渠道
当前稳定成立的产品模型
在目前阶段，对外最稳的理解方式是：- 桌面主机负责执行 本地文件、本地工具、长任务和主 runtime 能力主要在这里。
- 网页和手机负责远程接入 它们复用同一套远程产品模型，而不是另起一套独立产品。
- 运行时是执行后端，不是产品本体 用户可以更换 runtime，但不需要重建整套产品模型。
- 发布能力建立在本地闭环之后 先让一个本地工作流稳定，再考虑渠道、audience 和对外服务。
哪类用户最适合
ContextGo 最适合下面两类用户：- 想把本地工作、文档、网页、运行时和结果组织成一个长期系统的人
- 已经在用代码型或通用型 Agent，但希望把它们接入真实工作流，而不是只停留在单次对话的人
当前不应该过度承诺的部分
为了让公开文档口径稳定，下面这些方向可以提到，但不应该包装成“已经完全成熟的主功能”：- 完整的 Space-first 长期信息架构
- 完整多人协作模型
- 所有平台上的完全一致体验
- 所有 runtime 的完全同能力覆盖
下一步
- 想看最稳的上手顺序：看 Quick Start
- 想决定起步模式：看 Choose Your Setup
- 想按真实工作切入：看 Use Cases
- 想理解产品版图：看 Product Map