硅基铁匠丙午年 · 独立刊物
← 返回全部文章
技术与 AI约 8 分钟

员工经验总散在文档里？StaffDeck 把 SOP 跑起来

StaffDeck 把岗位画像、知识、SOP、工具、记忆和执行记录放进同一个数字员工工作台。它适合隔离环境里的 PoC，距离企业生产部署仍有不少工程要补。

公司里最难复制的往往是老员工脑子里的经验：客户怎么分级，退款走哪几步，异常找谁确认，哪些操作必须留痕。写进文档后，文档又容易躺进知识库，遇到具体任务还得靠人翻、靠人判断。

OpenBMB 刚开源的 StaffDeck，试图把这些材料装进一个可运行的数字员工工作台。它把岗位画像、知识文档、 SOP 、 HTTP/MCP 工具、长期记忆、定时任务和执行 Trace 放到同一套系统里。

截至 2026 年 7 月 20 日，最新发布是 v0.1.1-beta.3。版本号已经说明它还在早期阶段，更适合做 PoC 、流程原型和源码评估。

数字员工到底装了什么

StaffDeck 里的数字员工有几类可管理资产：

  • 岗位画像：负责什么、有哪些权限、用什么语气；
  • 知识：导入 TXT 、 Markdown 、 HTML 、 PDF 和 DOCX，回答时检索相关片段；
  • SOP 技能：把业务步骤写成状态机，按当前状态继续推进；
  • 工具：调用 HTTP API 、 MCP 服务或本地命令；
  • 记忆与 Trace：保存会话状态、长期信息和每次执行过程；
  • 定时任务与人工接管：让任务按计划运行，必要时交回给人。

一条退款流程可以拆成：识别订单、核对规则、查询状态、提交退款、记录结果。知识库负责解释规则，SOP 限制步骤，工具连接订单系统，Trace 留下每次判断和调用记录。这样的组合比单独放一个聊天框更接近业务流程。

数字员工广场界面示意，图片来自 StaffDeck 仓库内置素材。

数字员工画像配置界面示意，图片来自 StaffDeck 仓库内置素材。

本地跑起来需要什么

源码模式要求 Python 3.11+、 Node.js 20+、 npm，以及一个兼容 OpenAI Chat Completions 的模型服务。

macOS 、 Linux 或 WSL 可以这样安装：

git clone https://github.com/OpenBMB/StaffDeck.git
cd StaffDeck

python3 -m venv backend/.venv
backend/.venv/bin/python -m pip install -e "backend[dev]"
npm --prefix frontend-enterprise ci
cp backend/.env.example backend/.env

接着编辑 backend/.env，至少替换这些配置：

APP_SECRET="换成足够长的随机字符串"
DEMO_MODEL_BASE_URL="https://你的模型接口/v1"
DEMO_MODEL_NAME="你的模型名"
DEMO_MODEL_API_KEY="你的API-Key"

随机密钥可以这样生成：

python3 -c "import secrets; print(secrets.token_urlsafe(48))"

启动和检查：

scripts/dev_up.sh --detach
curl http://127.0.0.1:5173/api/health
scripts/dev_status.sh

停止服务：

scripts/dev_down.sh

页面默认在 http://127.0.0.1:5173。如果端口被占用，启动器会在 5173～5199 之间选择空闲端口，实际地址以 scripts/dev_status.sh 为准。

登录界面预览，图片来自 StaffDeck 仓库内置素材。

Release 构建流程覆盖 Windows x64 、 macOS Intel/Apple Silicon，以及 Linux x86_64 的 DEB 和 AppImage 。当前标签仍带有 Beta；下载安装前应核对版本和系统架构，并留意安装包是否具备有效的平台签名。仓库暂未提供可独立下载的 SHA-256 校验文件。

第一个 PoC 不要选高风险流程

适合起步的场景是“读取资料后生成草稿”，例如：

  1. 导入售后政策和常见问题；
  2. 建一个售后助手，只给它知识检索能力；
  3. 用几组历史问题测试引用是否准确；
  4. 再接只读订单查询接口；
  5. 最后才考虑退款提交、消息发送或定时执行。

先验证它能否找到正确资料、按 SOP 走完步骤、留下可读 Trace 。涉及转账、退款、删除、外发消息时，保留人工确认。

先做隔离，再接业务

需要重点隔离的是通用技能 Runner 。源码模式下，模型生成的 Python Runner 会作为子进程执行；在非 Windows 、非打包的开发环境中也可执行 Bash 。代码设置了运行超时，并会在结束时终止残留进程，但没有看到容器、 seccomp 或系统调用级沙箱。 Runner 继承应用进程环境，可以读取其权限范围内的文件并发起网络请求。

试用环境至少要做这些隔离：

  • 使用独立测试机、虚拟机或容器，不挂载生产目录；
  • 给模型网关、 HTTP 工具和 MCP 服务使用低权限测试账号；
  • 不要在运行 StaffDeck 的进程环境中放生产凭据；PoC 只使用低权限、短期、可撤销的测试凭据；
  • 保持 127.0.0.1 监听，不把 5173 端口直接暴露公网；
  • 禁止自动执行付款、退款、删除和群发等高风险动作。

模型如果接在云端，系统提示词、历史对话、知识检索结果、工具输出和部分 Trace 都可能发送给模型提供商。本地部署 StaffDeck 只代表应用和 SQLite 在本机运行，数据是否外发仍取决于模型与工具配置。

默认配置必须先改

首次启动会创建 admin/admin，示例中的 APP_SECRET 也是公开固定值。两项都要换。主分支当前还缺少登录限流，Token 默认有效 14 天，也没有完整的主动吊销机制，不适合直接架到公网。

模型 API Key 会用 Fernet 加密后写入 SQLite，密钥由 APP_SECRET 派生。如果丢失或更换 APP_SECRET，已有 Key 可能无法解密。 HTTP 工具的 headers/auth 以及 MCP 的 headers/env 目前以 JSON 直接写入 SQLite，管理接口也会原样返回；即使 HTTP 工具支持 ${secret.NAME} 环境变量占位，也不应把生产密钥放进同一个 StaffDeck 进程。

目前还不能当成成熟企业平台

StaffDeck 的对象模型已经覆盖知识、流程、工具、记忆和追踪，但生产工程还没跟上产品范围：

  • 默认使用 SQLite，没有 PostgreSQL 、多副本和高并发部署说明；
  • 仓库没有 Dockerfile 、 Compose 、 Helm 或完整 TLS 方案；
  • 高风险工具的细粒度审批仍在路线图中；
  • 当前仓库没有内置的微信或企业微信连接器；
  • 知识解析没有 OCR，扫描 PDF 和旧版 .doc 不适用；
  • 当前代码关闭了 Swagger/OpenAPI 页面，README 里的 /docs 地址不能直接使用；
  • 没有 SSO 、 LDAP 、 SAML 等企业身份集成，也没有公开的合规认证或性能基准。

许可证文件还有缺口：README 标注项目采用 AGPL-3.0，但仓库根目录没有 README 所链接的 LICENSE，也没有 COPYING 正文。计划复制、修改、分发或通过网络提供服务前，应向项目方确认实际适用的许可文本，并完成合规评估。 AGPL-3.0 本身不禁止商业使用，但会对分发和网络服务提出相应的源代码提供义务。

谁适合现在试

技术团队、 AI 应用团队和流程负责人可以拿 StaffDeck 做隔离 PoC，重点观察三件事：SOP 能否稳定推进，工具调用是否可控，Trace 能否让人看懂失败原因。

如果需求包括公网访问、多租户隔离、企业身份接入、细粒度审批或大规模并发，现阶段先不要上线。更稳妥的用法是在隔离环境里选一条只读、可回放的流程，记录检索命中率、 SOP 完成率、工具失败率和人工接管次数，再决定是否继续投入。

来源：https://github.com/OpenBMB/StaffDeck