Workspace 作为公司运行时
一篇关于 AI-Native 公司的设计论文:为什么 workspace,而不是聊天线程,应该成为 Agent 工作的操作边界。

摘要
本文是一篇设计论文,而不是经验实验报告。它的核心论点是:AI-Native 公司软件的正确产品原语,不应是 chat thread,而应是被理解为“公司运行时”的 workspace。这个运行时把 Agent、文件、工具、权限、运行资源、记忆、审计和成本绑定在一个持久边界内。
这个论点首先是架构性的。如果 Agent 被期待承担被委派的工作,而不仅是生成孤立回答,那么围绕 Agent 的系统就必须提供让组织工作变得可理解的基本类别:角色、授权、上下文、产物、责任和预算。聊天线程可以承载对话;仅靠聊天线程无法承载公司。
1. 定义
Workspace。 一个持久的组织边界,内部包含 Agent、session、文件、权限、资源、用量和计费状态。
Agent。 一个软件工作者:它可以接收任务,使用模型,调用工具,访问受限上下文,产生产物,并留下可检查的执行轨迹。
公司运行时。 让一个“类似公司”的单元可以运行所需的最小软件基座:身份、任务委派、执行、记忆、工具访问、治理、审计和成本核算。
AI-Native 公司。 一种组织形态:相当一部分白领执行工作由 Agent 完成,人类仍然是所有者、审查者、客户和法律责任主体。
2. 论点
Workspace 应该被视为 AI-Native 公司的第一类运行时。
原因是结构性的。Agent 执行的工作不只是语言生成,而是一组针对上下文、文件、工具、凭证、外部服务和运行环境的动作。每个动作都有授权、成本和风险。能够一致承载这些属性的最小边界,不是模型,不是对话,也不是单个用户,而是 workspace。
3. 为什么聊天线程不够
聊天线程擅长承载对话连续性。公司工作需要的是运营连续性。二者不是同一件事。
一段对话可以记住说过什么;一家公司必须记住做过什么、由谁做、基于什么授权、影响了哪些资源、花了多少成本、最后产生了什么产物。当 Agent 修改文件、执行命令、调用供应商或者安排定时任务时,真正重要的对象已经不再是消息本身,而是执行轨迹和 workspace 状态的变化。
这产生了五个纯聊天模型无法满足的要求:
- 产物持久化。 输出必须落到可以跨 session 存活的文件系统或对象空间。
- 授权约束。 Agent 必须被允许访问某些资源,同时被禁止访问另一些资源。
- 执行隔离。 命令和脚本需要运行时,而不是用户的个人电脑。
- 可审计性。 组织必须能够检查工具调用和关键决策链。
- 成本核算。 用量必须归集到真正受益的公司边界。
4. Workspace 语义
当产品原语能够映射为公司语义时,workspace 才真正变得有用。
Agent 有角色、历史、模型偏好、权限和工作面。它不应该只是无状态 prompt preset。
文件和生成产物构成共享记忆层,新 Agent 和人类成员都可以复用。
搜索、代码执行、连接器、定时任务和外部服务不是普通按钮,而是在策略下分配的能力。
模型用量、compute、storage 和能力调用构成运行 workspace 的成本。
5. 先治理,再自治
安全的顺序应该是:先治理,再自治。
很多 Agent 系统试图通过让模型更强来增加自治程度。这是必要的,但不充分。没有边界的自治会制造歧义:Agent 可以访问什么、可以修改什么、什么时候需要人审查、谁为动作付费、出错后组织如何恢复?
因此,workspace 运行时在扩大自治之前,应该先暴露四类治理机制:
- 对文件、工具、凭证和外部服务的权限边界。
- 对工具调用、生成产物和状态变化的可见轨迹。
- 对高风险、高成本或不可逆工作的人工审查点。
- 对成本的运行时硬限制,让余额、预付款和 spend limit 成为真实约束,而不是仪表盘建议。
6. 设计推论
如果 workspace 是运行时,产品设计就应遵循以下原则。
6.1 状态属于 workspace
重要状态不应该只存在于模型上下文窗口里。文件、产物、决策、定时任务、凭证和资源授权都需要持久的 workspace 存储。模型上下文是执行辅助;workspace memory 才是系统记录。
6.2 Agent 应按角色专门化
单个万能助手很方便,但作为组织抽象并不强。公司受益于角色分离,因为授权、上下文、评估和成本都可以被约束。研究、代码、支持、运营、财务和写作 Agent 即使共享 workspace,也应该可以分别治理。
6.3 工具执行必须可见
隐藏工具执行短期会让产品更顺滑,长期会削弱信任。如果用户无法检查一个产物如何生成,workspace 就无法成为严肃的操作面。
6.4 成本必须是运行时信号
在 AI-Native 公司里,用量不是装饰性指标,而是被委派工作的运营成本。余额、预付承诺、月度 spend limit 和 suspension 行为必须在运行时被硬性执行。
6.5 破坏性动作需要时间和审计
资源删除、workspace purge 等破坏性操作不应该是计费失败或不活跃后的即时反应。运行时需要宽限期、通知、审计记录、dry-run 模式和显式运营控制。
7. 论点的局限
这个论点有三个重要局限。
第一,当前模型能力并不均匀。运行时可以让 Agent 工作更可治理,但不能让所有任务天然可靠。产品必须假设失败、歧义和审查始终存在。
第二,法律责任仍然属于人。即使 Agent 承担更多执行工作,人类仍然是合同、合规、客户承诺和财务决策的责任主体。
第三,公司工作是社会技术系统。更好的软件可以降低协调成本,但不会消除判断、品味、信任和战略。
8. 评估议程
这个论点不应只用“聊天质量”来评估,而应使用运营结果来评估。值得研究的问题包括:
- 多少重复工作可以从手动 prompt 转移到 schedule 或 Skill?
- 什么权限模型能够在配置负担最低的情况下带来最高信任?
- 什么粒度的执行轨迹最有助于用户审查,而不会造成信息过载?
- workspace memory 应该如何决定保留、总结或遗忘什么?
- 当模型、compute 和 storage 都作为 workspace 成本核算时,哪些任务在经济上变得可行?
9. 结论
AI-Native 公司首先不是模型问题,而是操作系统问题。
模型提供智能。workspace 提供边界、记忆、授权、执行、审计和成本。没有这个运行时,Agent 只能是用户旁边的助手;有了这个运行时,Agent 才可能成为公司内部的工作者。
Vecbase 建立在这个判断之上:运行一家公司,而不是运行一个聊天框。
