Sim AI 工作区
在同一工作区构建、部署并监控 AI 智能体与自动化流程。
证据显示 CI 默认使用只读内容权限，并仅在发布任务中增加包写入或 OIDC 权限；数据排放测试路由还执行变更权限检查、凭据解密、超时控制和审计记录。配置状态命令声明不会输出凭据，安装程序生成密钥，依赖安装使用冻结锁文件并忽略脚本，多数外部 Actions 固定到提交。扣分在于材料没有系统说明代理运行时每个集成所需权限、数据会发送到哪些第三方、工作流执行前的逐项用户确认机制或完整秘密生命周期。外部部署有测试、迁移、不可变标签和防陈旧发布门禁，重置会归档环境文件，但回滚仍依赖推送回退提交，且重置会清除托管数据。来源标为 Sim 团队和 Sim Studio, Inc.，但给定注册信息说明发布者身份未经验证，因此只能视为有仓库内署名而非独立确认。
README、脚本清单、CI 和测试围绕 Bun、Docker、工作流、实时服务及多环境部署形成基本一致的产品叙述；依赖和运行时版本较明确，并提供 GitHub 与 Blacksmith 的 CI 切换路径。扣分在于所给材料只是仓库切片，未展示锁文件、全部复用工作流或生产故障恢复实现，无法充分证明所有依赖路径的可用性。失败消息处理较强：安装状态、doctor、健康检查、缺失密钥检查、404/不支持目的地、超时以及数据排放测试错误均有明确反馈和日志。
材料清楚覆盖云托管、自托管、贡献开发、Docker Compose、Helm、Ollama、vLLM、可视化、对话式和代码式构建等受众与场景，并提供按能力重新配置和运行方式自动检测，因此受众覆盖和环境适配充分。扣分在于能力边界主要是功能列表和少量不支持错误，未系统说明哪些模型、集成或动作不可用；也没有提供足够的代理触发定义、歧义处理、误触发防护或自然语言触发精度证据。
README 的快速开始、能力、自托管、密钥、环境变量、技术栈、贡献和许可结构清楚，安装与管理命令详细，并注明 PATH、端口、内存、Docker 和部分部署限制。Apache-2.0 元数据与完整 LICENSE 一致，可得满分。扣分在于 FAQ 和端到端示例有限，已知限制分散，根包版本固定为 0.0.0；CI 虽能识别语义版本发布提交，但未提供变更日志或清晰的用户升级兼容策略。维护入口包括贡献指南、文档、Slack 和 Sim 团队署名，但发布者身份未获独立验证。
产品提供可视化工作流、代码和对话构建、数据存储、知识库、集成、部署、日志、计划任务和监控，输出可直接成为可运行代理或工作流；统一工作区相对单一代理脚本具有明确的边际价值。扣分在于成本收益主要由功能陈述支持，未提供资源基准、托管定价、集成成本或规模化运维数据；自托管还需要 Bun、Docker，并在嵌入式安装提示中注明约 12GB 以上内存。
部分陈述可由脚本、路由、CI 门禁和实时测试相互支持，例如自托管命令、审计、发布顺序和协作通信。扣分在于“1,000+ integrations”“every major LLM”和用户规模等宣传性陈述没有在给定文件中得到清单、统计方法或独立来源支持；材料也未明确区分实测事实、设计意图和营销概括。测试文件能佐证有限组件行为，但不能交叉证明整个代理平台的广泛能力。
- 发布者身份未经 FollowAgents 企业注册表验证；仓库内的公司和团队署名不等于独立身份确认。
- 连接外部 LLM、Slack、Notion、HubSpot、Salesforce、数据库、数据排放目标或远程执行服务前，应逐项核查权限范围、数据保留、跨境传输和供应商条款。
- bun run sim reset 会归档环境文件但清除托管数据；执行前应另行备份数据库、文件和知识库，并确认恢复流程。
- CI 会使用 AWS、Docker Hub、GHCR 和 Trigger.dev 凭据并产生部署或发布效果；应保护环境审批、OIDC 角色范围和分支规则。
- “1,000+ integrations”“every major LLM”及用户规模没有被给定静态文件充分证明，不应作为采购或风险判断的唯一依据。
- 本评估未执行安装、测试或依赖漏洞扫描；固定版本和提交引用只能降低供应链漂移，不能证明依赖无漏洞。
这个 Agent 能做什么，适合哪些场景？
Sim 是一个面向团队的 AI 智能体与工作流平台，可通过聊天、可视化流程编辑器或代码完成构建。它能连接主流大模型以及 Slack、Notion、HubSpot、Salesforce、数据库等 1,000 多种集成，并让流程使用文件、知识库和结构化表格数据。运行结果通过日志、计划任务和工作流活动进行监控；技术栈还列出了 Trigger.dev 后台任务、Socket.io 实时通信、E2B 远程代码执行和 isolated-vm 隔离执行。产品既提供 sim.ai 托管服务，也支持本地开发、Docker Compose 和 Kubernetes Helm 自托管。该仓库采用 Next.js、Bun、PostgreSQL、Drizzle、Better Auth、ReactFlow 和 Turborepo，适合希望将智能体设计、数据和运维集中管理的团队。
用户可以在聊天界面、ReactFlow 驱动的可视化编辑器或代码中创建智能体和工作流。流程可读取上传文件、同步知识库及内置 Tables 中的结构化数据，并调用主要大模型以及 Slack、Notion、HubSpot、Salesforce、数据库等外部服务。Sim 负责运行工作流，并展示运行记录、日志、计划任务及工作流活动；其技术栈列有 Trigger.dev、Socket.io、E2B 和 isolated-vm。自托管安装由 bun run setup 向导配置数据库、生成密钥、写入 .env、连接 Chat API key 并启动所选部署方式。之后可用 bun run sim start、bun run sim status、bun run sim logs 和 bun run sim doctor 管理或诊断实例。
- 运营团队需要把 Slack、Notion、HubSpot、Salesforce 和数据库操作编排成可监控的自动化流程。
- 产品团队希望通过对话或可视化编辑器快速搭建智能体，同时允许工程师用代码补充复杂逻辑。
- 知识管理团队需要让智能体检索文件、同步文档、知识库和结构化表格数据。
- 受数据部署要求约束的组织希望通过 Docker Compose 或 Kubernetes Helm 在自己的环境运行平台。
- 工程团队需要集中查看智能体运行日志、计划任务、健康状态和工作流活动。
- 希望使用本地模型的团队需要把自托管工作区连接到 Ollama 或 vLLM。
这个 Agent 有哪些优点和局限？
- 聊天、可视化流程编辑器和代码三种构建方式位于同一个工作区，可覆盖不同技术水平的协作者。
- 明确支持 1,000 多种集成、主要大模型以及文件、知识库和内置结构化表格。
- 同时覆盖构建与运维，提供运行记录、日志、计划任务、工作流活动及健康诊断命令。
- 部署选择完整，包括托管服务、本地开发、Docker Compose 和 Kubernetes Helm，并支持 Ollama 与 vLLM 本地模型。
- Apache-2.0 许可允许团队检查、修改和自行部署代码。
- 自托管明确依赖 Bun 和 Docker，并包含 PostgreSQL、认证、后台任务、缓存等多个需要维护的组件。
- 聊天功能依赖 Sim 管理的 Chat API key；即使自托管，也需要登录 sim.ai 获取或管理该密钥。
- 外部集成和云端模型通常需要网络连接及相应服务凭据，完全离线能力没有得到证明。
- Kubernetes 仅说明通过 Helm 部署到本地集群，来源没有提供生产级规模、可用性或性能数据。
- README 列出 E2B 远程执行和 isolated-vm 隔离执行，但没有给出安全边界、权限模型或沙箱限制的详细证据。
如何安装或部署这个 Agent？
前置条件是 Bun 和 Docker。执行：
git clone https://github.com/simstudioai/sim.git && cd sim
bun install
bun run setup交互式向导会配置 PostgreSQL 数据库、生成密钥、写入 .env、连接 Sim Chat API key，并让你选择本地开发、Docker Compose 或 Kubernetes Helm。Chat API key 需要在向导打开浏览器后登录获取并自动保存。完成后访问 http://localhost:3000。可运行 bun run setup status 检查有效配置，但该命令不会打印凭据值。
如何使用这个 Agent？
打开 http://localhost:3000，通过聊天、可视化流程编辑器或代码构建工作流；添加所需的大模型、集成、文件、知识库或 Tables 数据源，然后运行并查看日志、计划任务和活动。常用管理命令包括：
bun run sim start
bun run sim stop
bun run sim restart
bun run sim status
bun run sim logs
bun run sim doctor可用 bun run setup llm 重新配置模型，用 bun run setup integration slack 配置 Slack；邮件、存储、沙箱、后台任务、缓存和知识功能也有对应的 bun run setup 子命令。
这个 Agent 与同类方案有什么区别？
托管版 sim.ai 适合希望直接使用平台而不维护基础设施的团队；自托管版则提供本地开发、Docker Compose 和 Kubernetes Helm 三种路径，但需要自行维护 Bun、Docker、PostgreSQL、密钥和相关服务。模型方面既可连接主要云端大模型，也支持 Ollama 与 vLLM 本地模型；来源未提供两者在功能、性能或成本上的量化对比。
常见问题
可以完全自托管吗？
自托管需要哪些基础设施？
.env。不同可选能力还可能涉及存储、缓存、后台任务、沙箱和知识服务。如何排查实例无法运行的问题？
bun run setup status 检查配置，再用 bun run sim status 查看服务健康状态、bun run sim logs 跟踪日志、bun run sim doctor 诊断配置问题。