介绍 Vecbase
为什么 Vecbase 从 workspace 出发：关于 Agent、文件、运行时和公司操作系统方向的一篇产品札记。
Vecbase 从一个很现实的产品约束开始：真正的工作不会在模型回复结束时结束。
工作需要文件。工作需要工具。工作需要权限。工作需要一个可以执行的地方。工作需要可复查的过程。工作还有成本。当 Agent 被期待做的不只是回答问题，这些东西就不再是附属功能，而是产品本身。
Workspace 是基本单位
大多数 AI 产品从 chat thread 开始。Vecbase 从 workspace 开始。
这个选择会改变整个系统的形状。聊天线程是一段对话；workspace 可以承载团队、文件系统、工具集合、权限、运行时资源和运营成本。如果长期目标是让 Agent 参与公司工作，那么 workspace 必须成为持久边界。
Agent 需要工作场所
员工不只是说话。员工会打开文档、使用工具、修改文件、请求审查、保存产物，并在预算和权限模型内工作。
AI Agent 也需要对应的结构。不是因为我们要把它拟人化，而是因为被委派的工作天然有运营要求。
Agent 需要访问正确的 workspace 历史、文件和指令，同时不能跨边界泄露。
Agent 需要搜索、读取、写入、调用服务、执行命令，并在可见的地方创建产物。
Agent 需要一个隔离环境来执行代码和使用凭证，而不是把用户本机变成工作台。
workspace 需要权限、用量核算、计费状态和审查界面，让工作可以被信任。
今天的 Vecbase 是什么
今天的 Vecbase Cloud 提供的是核心操作面：
- 以 workspace 作为组织边界。
- Agent 拥有角色、session、模型选择和设置。
- Chat 中保留可见的工具执行过程。
- Drive 承载输入、生成文件、预览和下载。
- 沙盒运行时承载 Agent 的真实执行。
- 订阅、credits、充值和用量在 workspace 级别可见。
- 主站提供 pricing、features、product updates、blog 和 research。
这是基础，不是终局。
Vecbase 不想成为什么
Vecbase 不想做一个只靠输入框体验竞争的通用聊天 Agent。它不是 IM。它不试图成为模型供应商。它也不是传统云控制台，不要求用户手动拼装基础设施原语。
它的方向更窄，也更大：当 Agent 逐渐可靠到可以承担更多执行层工作时，让 workspace 能够承载公司的运行。
接下来
下一阶段是可重复性。一个任务如果能稳定执行一次，就应该沉淀成 Skill。一个任务如果反复出现，就应该进入 schedule。一个工具授权应该有边界。一个文件产物应该成为 workspace memory 的一部分。一个高风险动作应该能够被审查。
产品体验应该从“和软件聊天”，逐步变成“运营一个拥有 AI 团队的小公司”。
这就是 Vecbase 的方向。