研究

Workspace 作为公司运行时

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

Vecbase Research
#研究#公司操作系统#Agent 治理
Workspace 作为公司运行时的研究视觉图
公司运行时必须把执行、记忆、授权和成本绑定进同一个持久操作边界。

摘要

本文是一篇设计论文,而不是经验实验报告。它的核心论点是:AI-Native 公司软件的正确产品原语,不应是 chat thread,而应是被理解为“公司运行时”的 workspace。这个运行时把 Agent、文件、工具、权限、运行资源、记忆、审计和成本绑定在一个持久边界内。

这个论点首先是架构性的。如果 Agent 被期待承担被委派的工作,而不仅是生成孤立回答,那么围绕 Agent 的系统就必须提供让组织工作变得可理解的基本类别:角色、授权、上下文、产物、责任和预算。聊天线程可以承载对话;仅靠聊天线程无法承载公司。

1. 定义

Workspace。 一个持久的组织边界,内部包含 Agent、session、文件、权限、资源、用量和计费状态。

Agent。 一个软件工作者:它可以接收任务,使用模型,调用工具,访问受限上下文,产生产物,并留下可检查的执行轨迹。

公司运行时。 让一个“类似公司”的单元可以运行所需的最小软件基座:身份、任务委派、执行、记忆、工具访问、治理、审计和成本核算。

AI-Native 公司。 一种组织形态:相当一部分白领执行工作由 Agent 完成,人类仍然是所有者、审查者、客户和法律责任主体。

2. 论点

Workspace 应该被视为 AI-Native 公司的第一类运行时。

原因是结构性的。Agent 执行的工作不只是语言生成,而是一组针对上下文、文件、工具、凭证、外部服务和运行环境的动作。每个动作都有授权、成本和风险。能够一致承载这些属性的最小边界,不是模型,不是对话,也不是单个用户,而是 workspace。

上下文
Agent 可以知道什么
workspace memory、文件、session 和外部数据源必须被公司边界约束。
授权
Agent 可以做什么
工具调用、凭证、存储授权和破坏性动作都需要显式策略。
成本
公司为谁付费
模型 token、compute、storage 和第三方能力调用,都会变成运营成本。

3. 为什么聊天线程不够

聊天线程擅长承载对话连续性。公司工作需要的是运营连续性。二者不是同一件事。

一段对话可以记住说过什么;一家公司必须记住做过什么、由谁做、基于什么授权、影响了哪些资源、花了多少成本、最后产生了什么产物。当 Agent 修改文件、执行命令、调用供应商或者安排定时任务时,真正重要的对象已经不再是消息本身,而是执行轨迹和 workspace 状态的变化。

这产生了五个纯聊天模型无法满足的要求:

  1. 产物持久化。 输出必须落到可以跨 session 存活的文件系统或对象空间。
  2. 授权约束。 Agent 必须被允许访问某些资源,同时被禁止访问另一些资源。
  3. 执行隔离。 命令和脚本需要运行时,而不是用户的个人电脑。
  4. 可审计性。 组织必须能够检查工具调用和关键决策链。
  5. 成本核算。 用量必须归集到真正受益的公司边界。

4. Workspace 语义

当产品原语能够映射为公司语义时,workspace 才真正变得有用。

Agent 作为员工

Agent 有角色、历史、模型偏好、权限和工作面。它不应该只是无状态 prompt preset。

Drive 作为公司记忆

文件和生成产物构成共享记忆层,新 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 建立在这个判断之上:运行一家公司,而不是运行一个聊天框。