为什么我们要做 ContextGo

我们为什么没有从“聊天框”开始

过去两年，AI 产品最容易成立的演示方式，是先给用户一个聊天框。

这种方式有两个优点。第一，它上手门槛低。第二，它很容易展示模型“已经很聪明了”。但一旦进入真实工作，问题就立刻出现了。

真实工作不是几轮问答。真实工作有项目目录，有文档和历史决策，有浏览器上下文，有本地文件，有第三方系统，有运行时环境，有消息渠道，还有一堆需要被长期记住、反复调用、持续治理的事实。

如果这些东西没有被接成一个系统，再强的模型也很容易退化成表面上的聪明。它可能在单轮里表现不错，但做不了太久，也进不去真正的工作流。

所以我们没有把 ContextGo 定义成“另一个 AI 聊天工具”。我们更想解决的，是 如何让 Agent 真正进入工作，而不是停留在演示。

我们想解决的到底是什么问题

我们观察到的核心问题，其实不是模型能力本身，而是工作系统层面的断裂。

1. Agent 很强，但缺少稳定的 harness

模型已经能推理、能写代码、能调用工具，但只要任务变长，常见问题还是会出现：

• 目标逐渐漂移
• 关键约束被遗忘
• 中间状态越来越脏
• 输出和真实项目逐步脱节

这说明问题不只在模型，而在于缺少一层稳定的 harness，让 Agent 可以在真实项目里持续被约束、披露和治理。

这里的 harness，不是一个抽象口号。

它通常必须落在一套真实对象上：

• project
• AGENTS.md
• docs/
• skills
• hooks / commands / schedules

模型负责推理，runtime 负责执行，而 harness 负责把这项工作持续绑定在真实项目边界里。这也是为什么我们会反复强调，Agent 的问题不能只从模型能力理解。

2. 上下文很多，但没有被真正组织起来

文件、文档、历史对话、偏好、成功模式、失败模式，本来都应该成为长期工作的一部分。但在很多产品里，它们要么散落在外部系统里，要么只在一次 prompt 里被临时拼接。

这会导致一个非常直接的问题：用户每次都要重新解释背景，Agent 每次都像重新开机。

所以我们说的 Context Engine，也不应该被理解成“又一个记忆数据库”。

它更像一层上下文稳定器：

• 它会从工作过程里提炼高价值信号
• 它会把长期有效的东西整理成 memory、profile 和 context pack
• 它会处理上下文的熵增，减少脏材料、过时约束和重复线索带来的污染

这也是为什么我们会引入 context space 这样的概念。不是所有长期信号都应该直接绑定到一个物理 project。很多真正有价值的偏好、模式和判断框架，天然会跨 project 存在。

对我们来说，一个好的 Space 更接近 document-native、vault-style 的长期上下文空间，而不是一块藏在后台、用户永远看不见的黑盒记忆。

3. AI 和现有软件栈仍然是割裂的

大多数人真正的工作，发生在浏览器、文档、IM、本地文件、项目目录和各种业务系统里。

如果 Agent 只能停留在自己的对话界面里，它就无法真正接入你的工作，也无法把结果可靠地回流到你的工作流中。

这也是我们为什么强调 Context Connector 不是“多接几个插件”。

它真正解决的是两件事：

1. 把你原来就在用的工作现实接进来。
2. 再把 Agent 的结果送回原来的工作现实。

如果只有第一步没有第二步，用户最终还是会回到复制粘贴和手动搬运。那就不是一个成立的工作系统。

4. 多端和远程访问常常只有“表面可用”

很多产品会宣传多端，但没有讲清楚真正执行发生在哪里。结果就是用户以为手机和网页是完整宿主，实际却仍然依赖桌面环境，最后口径和行为对不上。

我们不想继续制造这种模糊心智。

ContextGo 的产品定义是什么

我们现在对外最想保持一致的一句话是：

ContextGo 是一个以桌面主机为执行权威的 AI Native Workbench。

这里至少包含四层意思：

1. 它不是只负责回答问题的聊天界面，而是一个长期工作台。
2. 它的核心不是模型包装，而是 harness、上下文和连接能力。
3. 它默认承认真实工作依赖主机、文件、工具、运行时和项目结构。
4. 它会把远程访问、连接器、发布渠道和自动化能力放进同一套产品模型里。

这也是为什么我们在 README 里会反复强调几件事：project、AGENTS.md、docs/、skills/、hooks、commands、schedules，以及 Context Engine、Context Connector、Host / Client 这些对象。

这些不是附属 feature。它们共同构成了 Agent 真正能工作的边界。

如果要把这件事说得更直白一点，我们相信：

Code Agent 不止 code。给它稳定的 harness、上下文和连接器，它就可以进入更完整的工作现实。

为什么我们坚持 desktop-first 和 local-first

这不是怀旧，也不是为了显得“更工程化”。

而是因为今天真正高价值的工作，依然高度依赖本地环境：

• 项目代码在本地目录
• 浏览器状态在本机
• 文件和工具链在主机
• 很多权限和执行环境绑定在当前设备
• 长任务、受控操作和复杂 runtime 调用，仍然更适合由主机统一承担

所以 ContextGo 默认采用 Host Runtime + Client Shell 模型。

桌面主机负责真正执行，浏览器和移动端负责远程访问、继续、监督和控制。这样说虽然不花哨，但它是诚实的，也更能支撑长期产品演进。

我们宁可把边界讲清楚，也不想靠混淆心智换一时的“到处都能跑”叙事。

为什么 ContextGo 不只是给开发者

ContextGo 确实从很多开发者关心的问题出发，比如 code agent、project harness、上下文治理和运行时控制。

但我们真正想做的，并不是一个只给工程师用的 IDE 插件替代品。

我们更在意的是另一件事：普通用户真正关心的是，Agent 能不能替他长期做事。

这意味着产品必须同时满足两端：

• 对开发者和团队来说，它要有明确的架构边界、项目模型和可治理能力。
• 对普通用户来说，它要尽量把这些复杂度收敛成一个可使用的工作系统，而不是一堆底层概念。

如果最后只有懂 prompt、懂 runtime、懂目录结构的人才能把 Agent 用起来，那这件事就没有真正成立。

这也是为什么我们会非常在意产品层的表达方式。

很多复杂工作并不适合永远只用消息流来承接。未来一些更复杂的 Agent 协作，应该逐步有更结构化的人机协同 UI，例如可以被插件化渲染的卡片、步骤面板和任务状态面。

我们不把它当成今天已经完全成熟的主功能，但它代表一个很重要的方向：UI 也应该开始为 Agent 参与工作而设计，而不是只为消息展示而设计。

我们的使命和愿景

如果要把这件事说得更直接一点，我们的使命不是“做一个更会聊天的 AI 产品”，而是：

让顶尖模型、Agent、上下文、连接器和真实软件世界之间，不再彼此割裂。

我们希望未来的软件不只是为人类点击界面设计，也要开始为 Agent 可理解、可执行、可治理而设计。

我们也希望未来的 Agent 不只是一次性的问答角色，而是能在你的项目、工作台和长期任务里持续承担责任。

这背后对应的是三个长期方向：

• Agent 不应该只是聊天
• 上下文不应该只是历史记录
• 软件不应该只对人类界面友好，也应该对 Agent 友好

如果这三件事真的成立，ContextGo 才有意义。

ContextGo 接下来要继续证明什么

对我们来说，愿景不是靠一句口号成立的，而是要持续在产品行为里被证明。

接下来最重要的，不是去堆很多“看起来更 AI”的表层功能，而是继续证明几件事：

• Agent 可以在真实项目中长期稳定工作
• 高价值上下文能够被持续沉淀和治理
• 连接器能把外部工作流真正接进来，也把结果真正送回去
• 远程访问、多端使用和发布渠道能共享同一套产品模型
• 产品界面能从单一消息流，逐步演进到更适合人机协同的工作界面

只有这些事逐渐成立，ContextGo 才不是一套概念，而是一套真正能被长期使用的工作系统。

这篇文章之后应该读什么

如果你想继续理解 ContextGo 的产品边界，建议按这个顺序往下读：

1. 《为什么 ContextGo 先做上下文，再谈 Agent》 先理解为什么我们把上下文层放在产品中心。
2. 《桌面主机，移动端客户端，这个产品模型要说清楚》 再理解远程访问为什么必须建立在清晰的 Host / Client 模型上。
3. 《发布运维应该统一收口到 contextgo-releases》 最后理解为什么版本、下载和更新的事实来源，必须和产品信任绑在一起。

这些文章放在一起，才更接近我们真正想做的 ContextGo。