为什么还要做另一个 Agent 工作台
打开任何一个模型厂商的网页，你都能得到一个能聊天的框。问题从来不在那个框。
真正的工作是这样发生的：你先读几个文件，再跑一次测试，看到报错去改代码，改完再跑一次，最后把日志贴给模型让它解释。每一步都能用 AI 加速，但上下文在搬运过程中不断丢失——你复制粘贴的内容，和模型真正需要看到的内容，从来不是一回事。
缺的不是对话，是“能执行的那一半”
一个只输出文本的助手，把执行留给了你：你要在自己的机器上跑命令、控制版本、清理临时文件、记住上次试到哪一步。于是“AI 帮我写代码”变成了“我帮 AI 执行代码”。
工作台要补的就是这一半：
- 会话是有状态的。消息、工具调用、中间产物都在同一个上下文里，不需要你反复复述。
- 工具有真实副作用。读写文件、跑命令、起服务、截图，都在一个隔离环境里发生。
- 失败可以重试。报错进入上下文，模型看到的是真实的退出码和 stderr，而不是你口述的“它好像报错了”。
为什么是“沙盒”，而不是“在你的机器上跑”
最省事的做法是直接把命令丢到本机跑。我们没这么做，原因有三个，按重要性排序：
- 安全：模型生成的命令不该拥有你的主目录权限。
- 可复现：同一份镜像、同一套依赖，换台机器结果一致。
- 可丢弃：任务失败时最正确的动作是扔掉环境重来，而不是在里面修半天。
沙盒按需启动，任务结束即回收；会话和沙盒绑定，文件跟着会话保留期走。这和“给你一台长期在线的开发机”是两种产品。
为什么保留“无沙盒”路径
不是所有任务都值得启动一个容器。查文档、改一段文案、解释报错——这些纯对话任务如果也要等 30 秒环境就绪，产品就没法用。
所以运行时允许两种模式并存：会话可以绑定沙盒，也可以不绑。什么时候升级到沙盒，应该由任务决定，而不是由产品流程决定。
我们刻意没做的事
没有可视化工作流编辑器。 把 Agent 编排画成 DAG 很漂亮，但绝大多数真实任务的分支是在运行中才出现的：测试挂了要回去改，改完可能又挂。用固定图描述这种来回，最后一定会变成“图上画了 12 个节点，实际每次只走 3 个”。
没有把技能做成插件市场。 技能首先是文件：一段说明、几个脚本、可选的资源。它跟着仓库走、能 diff、能 review。集市很好，但它解决的是分发问题，不是执行问题。
没有隐藏工具调用。 每一步都能看到输入输出、耗时、退出码。信任来自可核查，不来自“AI 已经帮你搞定了”这句话。
那它现在是什么
一个自托管的多 Agent 运行时：会话、Agent 配置、技能、MCP 服务器、沙盒、交换空间都在同一套后端里，前端只是它的一个视图。你可以用公共池的免费额度把流程跑通，也可以带上自己的 Key，把成本和模型选择都握在手里。
下一步是把“多租户”这件事做扎实——隔离、配额、审计——因为一个只在单用户环境下好用的工作台，最终只能当 demo。