ContextGo Documentation
ContextGo Docs
Local-First AI Native Workbench
把上下文、工作台、Agent、自动化、发布渠道和多端远程组织成一个可持续工作的系统
ContextGo 不是只给你一个聊天框,也不是只给你一个 Agent。它帮助你把真实工作流接进来,让桌面主机持续执行,让网页和手机端持续接入,并在需要时把一个已经跑顺的 Agent 发布到真实渠道。
Why It Matters
为什么它不像普通 AI 工具
ContextGo 的价值不在“又一个更强的聊天模型”,而在于它把长期工作真正需要的几层能力放到了一起。
No Agent Raising
不用先养 Agent
先从真实任务开始,再逐步添加 runtime、skills、automation 和 publish 能力。
看真实打开方式Context First
先接入工作流,再谈智能
文件、网页、浏览器上下文、项目文档和外部来源先进入系统,Agent 才能围绕真实材料工作。
进入 ContextHost + Remote
桌面主机持续工作,网页和手机持续接入
执行权威留在主机,远程使用面留给 Web 和手机,形成真正可持续的工作系统。
进入 Remote & DevicesProduct Spine
从产品骨架开始理解 ContextGo
如果你把 ContextGo 只理解成一个聊天页,会错过它最重要的结构。更准确的理解方式,是把它看成一个多层工作系统。
Workbench
工作从 Workbench 开始
Conversation、Browser、Artifacts 和未来更多专业工作面,都是 Workbench Host 下的不同工作模式。
打开 WorkbenchContext
长期价值在 Context
Context Connector、Context Engine、Session / Project / Space 共同决定它是否能持续理解你的工作。
打开 ContextCapabilities
Agent、Runtime、Packages、Skills 一起装配能力
ContextGo 把执行后端和能力包分开,让系统更像一个工作平台而不是某个 runtime 的壳。
打开 Agents & CapabilitiesPublish
一个跑顺的 Agent 可以走向真实渠道
渠道、audience、groups、threads 和 publication binding 让 Agent 不只停留在本地。
打开 PublishUse Cases
按真实工作方式进入
如果你不想先理解完整产品结构,最好的方法不是跳过文档,而是从最像你真实工作的场景页开始。
推荐起步顺序
如果你今天就想用起来,不要先试图理解全部能力。按下面的顺序更稳。
- 先读 What Is ContextGo 和 Quick Start,建立主机、远程和上下文的基本心智。
- 然后去 Use Cases,找到最贴近自己工作的打开方式。
- 真正跑顺一条任务后,再回来看 Context、Publish 和 Collaboration 这些更长期的结构。