SmythOS Studio 自托管指南：Docker、成本与部署边界

如果可视化智能体编辑器和运行环境都能留在自己控制的基础设施上，它的价值就不只是“少写几行代码”。这正是 SmythOS Studio 值得关注的地方：在画布上连接语言模型、API 和逻辑，边搭建边检查流程，再通过 SmythOS Runtime Environment，即 SRE，运行智能体。仓库介绍了聊天机器人和 API 的部署方式，而不只是一个流程图编辑器。查看 Studio 仓库及其软件包结构。

关键是区分 免费软件、本地应用和可投入生产的服务。Studio 提供了前者，也提供了实现本地运行的路径，但生产服务仍然需要明确的运维方案。

资料核查日期：2026 年 10 月 1 日。下文的仓库细节以提交 3e1ea87e6718fdfdb24365b2184fbd1daa9f94f8 为依据。本文是文档与源代码分析，不是实际部署性能测试。建议配置和验收用例尚未在运行中的 Studio 实例上执行。

SmythOS Studio 真的免费且开源吗？

本次检查的 Studio 仓库采用 MIT 许可证。 许可证允许使用、修改和分发，包括商业使用，前提是保留所要求的版权和许可声明。它不提供担保。这是对软件许可证的说明，并不代表所有模型、依赖、集成或 SmythOS 托管服务都使用相同条款。核对实际的 MIT 许可证。

自托管部署的费用应分成四部分：模型推理、基础设施、外部工具和运维工作。免费编辑器不会让付费模型调用变成免费。本地模型只是把推理成本转移到自有硬件及其维护上，并没有消除成本。

我们建议用这个预算公式：每月运维成本 = 计算与存储 + 模型调用 + 付费 API + 运维投入。实施费用另行计算。更完整的衡量方法见现有的 AI 智能体单次操作成本指南，不要把仓库的价格当成整个工作流的成本。

可视化画布能构建哪些工作流？

组件文档涵盖 API 调用、JSON 转换、语言模型步骤、循环和并行分支。因此，Studio 适合拿来评估边界清楚的流程，例如分类收到的请求、读取内部服务中的信息，再起草回复。这些是已经有文档说明的构建模块，不代表任何具体业务流程都无需配置即可投入使用。查看有文档支持的工作流组件。

超出预设模块后也有扩展路径。Code 组件支持用 JavaScript 进行转换、校验和轻量逻辑处理。其文档接口用 _output 返回结果，用 _error 表达结构化错误。开发者可以把确定性规则写进代码，而不是要求模型猜测如何执行。核对 Code 组件的输入输出约定。

我们的判断是：画布的价值不在于省掉工程工作，而在于让了解业务的人看清预期的执行顺序。API 超时、结果缺失或操作未获授权时怎么办，仍然必须有人明确设计。

如何通过 Docker 安装 SmythOS Studio？

评估时使用 Docker 安装路径，不要混入另一套本地开发环境说明。本次检查的仓库指南要求 Docker Compose v2、至少 8 GB 内存和 10 GB 可用磁盘空间。这是该指南的安装要求，不是智能体负载或本地模型的容量评估。阅读仓库中的 Docker 安装指南。

首先克隆仓库并创建环境配置文件：

git clone https://github.com/SmythOS/smythos-studio.git
cd smythos-studio
git checkout --detach 3e1ea87e6718fdfdb24365b2184fbd1daa9f94f8
cp .env.compose.example .env
chmod 600 .env

这里的 checkout 固定的是配置源代码版本，不是应用镜像。Compose 文件仍然引用一个可变镜像标签，下文会说明它的影响。

启动前先编辑 .env。替换数据库、Redis 和会话的示例密钥，并配置所选模型提供商的凭证。每个密钥应使用独立的高强度随机值，例如分别运行 openssl rand -hex 32 生成。不要把该文件提交到版本控制，也不要放进共享日志。原始模板包含示例凭证、LOG_LEVEL="debug"、HTTP 应用地址和 ENABLE_TLS=false。检查完整的 Compose 环境模板。

如果只在自己的笔记本上评估，我们建议修改现有 .env 中的对应值，而不是额外创建一个部署配置层。Dashboard 变量未出现在原始模板中，需要手动补充：

EXPOSE_TRAEFIK_PORT=127.0.0.1:6060
EXPOSE_HTTPS_TRAEFIK_PORT=127.0.0.1:6062
EXPOSE_TRAEFIK_DASHBOARD_PORT=127.0.0.1:8089
LOG_LEVEL=info

这些值使用了已检查的 Compose 端口映射中的主机地址位置。如果没有指定主机地址，Docker 通常会在所有主机网络接口上发布端口。因此，在浏览器里通过 localhost 打开应用，并不等于网络中的其他机器无法访问它。请使用当前版本的 Docker，并确认实际绑定结果。Docker 文档还指出，28.0.0 之前的版本对 localhost 端口发布存在已知限制。核对 Docker 的端口发布行为。

检查环境配置后，再启动整套服务：

docker compose config --quiet && docker compose up -d
docker compose ps
docker compose logs --tail=100 smythos

等服务健康状态正常后，打开 http://localhost:6060。这些仅供本地使用的设置应与后续公网部署分开管理。不要为了方便演示，就把评估实例直接暴露到互联网。

Docker 实际启动了哪些服务？

本次检查的 Compose 文件定义了五个服务。它是一套小型应用系统，不是只有浏览器界面的单一应用。拓扑、挂载数据和镜像标签都可以在源码中查看。检查五个服务及其默认配置。

git-sync 是理解“没有中间平台”这句话时不能忽略的细节。它的默认仓库是 SmythOS/sre-models-pub，未覆盖配置时同步间隔为 600s。它同步的是仓库内容，并不是本地模型推理服务。部署中有这个服务，不代表模型就能离线运行。查看同步与挂载配置。

该版本的应用镜像是 smythos/smythos-studio:alpha。固定 Git 提交并不会固定这个镜像。 为了让试点可复现，应记录实际运行的镜像摘要以及智能体导出文件。升级前，使用相同输入和可恢复的状态副本验证新版本。

为什么 localhost:6060 或智能体地址可能无法访问？

先确认采用了哪条安装路径。 网站的自托管指南使用 http://localhost 和 APP_BASE_URL，而本次固定版本的 Compose 模板使用带有 6060 端口的 APP_URL。不要直接拼接不同指南中的变量，应先对照所选版本的源码。比较网站指南与仓库安装说明。

然后检查三个与端口相关的值。 EXPOSE_TRAEFIK_PORT 控制主机端口映射；APP_URL 表示浏览器访问的应用地址；模板中的 AGENT_DOMAIN_PORT 则单独设为 6060。只改公开端口，生成的 URL 可能仍然指向旧地址。

编辑器可用，不代表运行时路由也可用。 模板把 dev.agent.oss.smyth.ai 用作运行时及开发智能体域名，把 prod.agent.oss.smyth.ai 用作生产智能体域名。请在需要使用这些地址的机器上核对 DNS 解析、实际目标和 Traefik 的 Host 路由。域名由厂商提供，并不能证明运行时也由厂商托管。检查具体的域名与 URL 变量。

遇到 502 或服务不健康时，应先查基础设施，再改工作流。 从 docker compose ps 和有限范围的日志开始。应用健康检查同时覆盖两个内部 HTTP 服务器。数据库凭证、挂载目录权限和运行时启动都是独立故障点，修改画布上的节点无法解决这些问题。

公开部署前需要修改和验证什么？

以下是我们建议的部署验收清单，不代表默认发行配置已经通过这些检查。

移除不安全的管理面板访问路径

固定版本的 Compose 文件启用了 --api.insecure=true，默认把管理面板发布到主机的 8089 端口。它还定义了一个 api@internal 路由。因此，仅关闭 insecure 标志并不等于完成面板暴露检查。应移除不需要的端口和路由，或用身份认证及网络限制保护确实需要的管理入口。Traefik 明确提醒不要在生产环境使用不安全的管理面板模式。阅读 Traefik 的管理面板警告。

区分主机名与 URL，并验证 TLS

仓库生产指南的示例在 APP_DOMAIN 和 RUNTIME_DOMAIN 中加入了 https://，但 Compose 会把这些值插入 Traefik 的 Host(...) 规则。根据源码，我们建议域名字段只填主机名，URL 字段才填完整地址：

APP_DOMAIN=studio.example.com
APP_URL=https://studio.example.com
RUNTIME_DOMAIN=runtime.example.com
RUNTIME_URL=https://runtime.example.com

这只是命名示例，并非完整生产配置。还需要根据实际环境设置其余智能体域名、DNS、入口端口、重定向和 TLS。编辑器、运行时与已发布智能体的路由应分别测试。对照上面的配置检查 Host 规则。

默认解析器使用 HTTP 验证方式，并不会自动为任意智能体子域名提供通配符证书。Traefik 文档要求通过 DNS-01 获取通配符证书。可以配置这条路径，也可以使用分别得到证书覆盖的主机名，但都必须检查实际返回的证书。核对 Traefik 的 ACME 与通配符证书要求。

记录哪些数据会离开本机

本地托管说明的是部分系统在哪里运行，不是所有数据都会在哪里处理。云端 LLM、API 连接器或远程代码执行组件仍然可能接收工作流数据。

例如，SmythOS 的 NodeJS (Serverless) 文档描述的是 AWS Lambda 执行路径。不要把它与轻量 Code 组件混为一谈，也不要假设整个产品文档中的所有功能都能在 Community 中本地执行。应核对具体组件、产品版本和配置的后端。阅读文档说明的 Lambda 执行方式。

.smyth 绑定挂载也不只有同步的模型目录：Compose 注释中还列出了 Vault 配置和运行时存储。应备份实际使用的数据位置，控制备份访问权限，并测试恢复过程。只有数据库备份，并不足以证明完整智能体部署可以恢复。检查应用的挂载位置。

一个合适的首个工作流：起草客服回复，但不发送

我们建议的试点范围刻意保持很小：接收一条合成客服请求，校验字段，读取获准使用的参考数据，起草回复，再交给人工审核。第一轮不要授予发送消息、退款或修改账户的权限。

让每一步都对应画布中可见的流程环节。必填字段使用确定性校验，数据访问使用获得许可的 API 步骤，回复草稿使用模型步骤，并明确处理证据缺失的情况。这是我们提出的设计，不是经过实测的 Studio 内置模板。

验收问题不应只是“所有模块都变绿了吗”，而应是回复是否得到检索信息的支持，以及信息缺失时系统能否安全停止。测试应包含未授权记录、提供商超时、格式错误的数据，以及检索内容中要求智能体绕过规则的嵌入指令。即使以后增加写入操作，授权也不能交由模型自行决定。

架构选择可参考现有的 AI 智能体设计模式指南。本文的重点是评估 Studio 作为可视化开发和自托管环境的适用性，而不是替代完整的智能体设计过程。

不运行可视化编辑器，也能执行 Studio 智能体吗？

官方文档给出了导出路径。 SmythOS 描述了从 Studio 导出 .smyth 文件，再通过 SRE CLI 运行的方法。安装并配置兼容的 CLI 后，文档中的命令是：

sre run ./my-agent.smyth

这提供了一个实际检验工作流能否离开开发环境的方法。阅读 Studio 到 CLI 的工作流程。

不要把导出文件当作完整备份，也不要认为它会自动成为可迁移的部署包。应逐项梳理智能体依赖的凭证、模型配置、存储、自定义代码和连接器。在干净环境中执行导出文件，对比其输出和失败行为是否与编辑器版本一致。拥有源码减少了一类依赖，但不会消除迁移工作。

编辑器、运行时和外围可靠性控制之间的区别，可参考 Agent Harness 工程指南。

哪些团队值得评估 SmythOS Studio？

我们的判断是：如果你需要业务人员能看懂、开发者能扩展，而且团队可以在选定基础设施上维护的可视化工作流，Studio 值得进入候选名单。先选择一个有价值的具体流程，并制定清晰的验收标准，不要一开始就承诺自动化整个部门。

如果没有人负责更新、恢复和故障处理，托管服务可能更实用。如果工作流大部分已经是自定义代码，或团队主要需要库级集成，代码优先的实现方式可能更合适。这是运营方式的选择，并不是某种界面在所有场景都更优秀。

Wavect 的 AI 工程服务涵盖工作流实施与生产环境加固。Twinsoft AI 案例展示的是相关实施经验，并非 SmythOS Studio 参考部署。可以使用 上线前 QA 检查清单定义所需证据，或 与 Wavect 讨论自托管智能体试点。