ModelBest 开源 StaffDeck，押注数字员工能够超越聊天机器人

ModelBest 已将 StaffDeck 开源。这是一款企业 AI 数字员工平台，旨在让 AI 在聊天会话结束后仍能继续工作。7 月 15 日发布的 StaffDeck 将知识、标准操作程序和决策规则转化为可管理的 AI 员工。这一定位使 StaffDeck 与企业聊天机器人形成直接竞争，后者能够回答问题，却很少负责持续运行的业务流程。

这种区别非常重要，因为企业已经能够使用性能强大的语言模型。它们面临的更棘手问题，是如何将分散的文档和员工经验转化为可靠的运营流程。StaffDeck 声称可通过持久化角色、程序化技能、受控权限、定时任务和可追溯执行记录来填补这一空白。

在企业测试 Microsoft、Salesforce、ServiceNow 以及越来越多开源项目推出的 AI agents 之际，StaffDeck 应运而生。这些系统承诺超越文本生成，在各种业务应用中完成工作。ModelBest 及其合作者提出了一个更聚焦的观点：实用的企业 agents 应该更像受到治理的员工，而不是临时聊天窗口。

这一观点比该项目早期的受欢迎程度更为重要。截至 7 月 17 日，也就是公告发布两天后，开源代码仓库在评测时拥有 46 个星标和 9 个复刻。StaffDeck 仍处于早期测试阶段，其核心主张尚未获得独立的企业级验证。

不过，这些代码依然为一个日益普遍的理念提供了具体的检验机会。如果组织能够将自身的知识、工作流、权限和反馈封装成可复用的数字角色，那么 AI 的采用方式就会从个人辅助转向组织基础设施。

ModelBest 的 StaffDeck 企业 AI 平台将工作流转化为角色

StaffDeck 将 AI agent 视为一份员工档案，其中包含职责、能力、权限和工作历史。

该平台由 ModelBest、NEU-ModelBest 数据智能联合实验室、清华大学自然语言处理实验室、OpenBMB 和 AI9Stars 联合开发。OpenBMB 将自己描述为一个由清华大学研究人员和 ModelBest 支持的开放社区。

该团队以 GNU Affero General Public License version 3 发布了 StaffDeck。该许可证允许组织检查、修改和部署该软件。当修改后的版本作为网络服务提供时，它也要求共享源代码。

StaffDeck 的界面以数字员工而非通用聊天机器人为核心。管理员可以创建职位、定义其职责边界、分配员工 ID、配置访问权限，并关联可复用的能力。这些能力可以包括知识集合、通用技能、工具和程序化工作流。

企业可以创建一个研究分析师，让其收集材料、遵循经批准的审核流程、生成报告并保存工作记录。另一个数字员工则可以监控传入的请求、查阅政策文档、调用内部服务，并将例外情况上报给人工处理。

这种结构试图解决通用 AI 助手反复出现的一个问题。员工可以与模型进行多次有价值的对话，但由此产生的知识往往仍被困在聊天记录中。其他团队成员难以轻松查看该助手积累的操作规则，也无法安全地复用这些规则。

相比之下，StaffDeck 将角色本身变成一个可管理的组织对象。该公司表示，数字员工可以将个人专业知识保存为可复用且可追溯的资产。它们还可以积累记忆，并通过对话日志、用户反馈和任务结果不断改进。

这是一个雄心勃勃的主张。捕捉程序比捕捉程序背后的判断更容易。经验丰富的员工经常运用未被记录的背景信息、非正式关系和从未出现在 SOP 中的例外规则。

StaffDeck 并不能消除这个问题。它为团队提供了一套表示和修订这些知识的结构。这种表示能否保持准确，取决于负责构建、测试和治理每个数字员工的人员。

该平台还包含一个用于共享能力的市场式系统。普通用户可以复制或绑定已获授权的资源，而不会更改原始模板。这种分离机制旨在防止某位用户的编辑操作在无形中改变整个组织正在使用的能力。

部署选项包括 Web 应用程序，以及适用于 macOS、Windows 和 Linux 的桌面软件包。该应用程序本身不需要本地图形处理器。它连接到兼容 OpenAI 的模型端点，由部署该应用程序的组织决定底层模型和计算方式。

因此，首个版本提供的不只是一个概念演示。它包含 Python 后端、React 和 TypeScript 界面、任务工作进程、存储组件、安装脚本和应用程序打包功能。它还会公开 agent 运行后的执行详情，供管理员检查。

StaffDeck 面临的第一个挑战，是证明这种员工隐喻能够改善运营。为 agent 命名、分配角色并记录其工作，并不会自动产生可靠的判断。真正的价值必须来自这一隐喻背后的机制。

为什么企业聊天机器人才是真正的对手

StaffDeck 的主要对手并非另一个开源项目，而是以临时对话为中心的企业 AI 模式。

大多数企业采用 AI 都从聊天界面开始。员工要求 AI 提供摘要、草稿、答案或分析。模型作出响应，然后由用户决定下一步该怎么做。

这种模式可以提高个人生产力，但责任仍然落在操作聊天工具的人身上。系统很少负责某个流程、维持持久的角色，或在员工离开后继续处理任务队列。

StaffDeck 试图以持久化数字员工取代这种交互模式。数字员工可以获得明确的能力、执行定时任务、保留与工作相关的记忆，并与外部服务交互。人类可以检查它们的操作、中断运行，或在必要时接管任务。

这种差异给企业助手供应商带来了压力。聊天机器人可以给出精美的答案，却仍可能无法完成底层流程。数字员工则必须应对工具错误、信息缺失、审批要求、政策变化和指令冲突。

从回答问题转向执行操作，也改变了成功的衡量方式。聊天机器人通常根据响应质量和用户满意度进行评判。运营型 agent 还必须根据完成率、异常率、审核时间、可逆性以及错误操作造成的后果接受评估。

StaffDeck 会公开意图检测、检索、技能、工具、审核和最终响应的流式记录。这些记录旨在展示结果是如何产生的，而不只是模型说了什么。

这种可见性解决了企业的一项基本顾虑。当 agent 犯错时，管理员需要判断原因究竟是文档错误、检索失败、程序有缺陷、模型不合适，还是工具调用不安全。

传统聊天记录只能提供部分证据。它通常隐藏了影响输出结果的中间检索和执行决策。StaffDeck 面向追踪的设计试图让这些决策变得可观察。

该平台还允许通过定时任务和持久化工作进程持续开展工作。数字员工这一名称正是在这里获得了实际意义。如果 agent 只在有人打开对话时才运行，那么无论品牌如何包装，它仍然只是一个助手。

持续运行也会带来额外的运营负担。工作进程必须保持可用，时区必须正确配置，凭据必须始终有效，失败的任务也需要恢复路径。如果无人发现第一次失败，定时运行的 agent 可能会反复重现同一个错误。

StaffDeck 的代码仓库承认了这些局限性。它警告称，模型响应可能不正确或不一致，执行记录也无法保证正确性。它还建议用户对高风险操作采用最小权限凭据和人工审批。

这些警告揭示了真正的竞争边界。StaffDeck 并不是在承诺更好的对话个性，而是在提出一个运营层，用于将模型行为转化为受控的组织工作。

对于考虑进行这种转型的团队而言，可靠的组织上下文至关重要。可搜索的团队知识库可以帮助整合 agent 所需的源材料。随后，StaffDeck 会在这些知识之上加入程序、工具、权限和执行机制。

聊天机器人模式依然颇具吸引力，因为它限制了自主性。用户发起每次交互，并在采取行动前审核每个答案。StaffDeck 则要求企业接受更高程度的自动化，以换取连续性和可复用性。

这种交换将决定该平台的发展前景。只有当运营收益超过测试、监督、安全和维护成本时，企业才会采用数字员工。

通过 SOP、检索和工具使用理解 StaffDeck

StaffDeck 的核心机制将结构化程序、文档感知检索和受控的外部操作结合起来。

该平台的程序化技能使用状态机，将工作流表示为定义明确的状态和允许的状态转换。系统无需让模型即兴设计整个流程，而是可以要求它按照结构化序列逐步推进。

采购工作流可以从请求分类开始，随后进入政策检索、检查审批门槛、收集缺失信息，最后转交请求。遇到例外情况时，可以触发一个单独的分支，而不是任由模型自行编造下一步操作。

StaffDeck 表示，用户可以根据自然语言描述生成这些结构化 SOP。随后，他们可以通过可视化方式编辑工作流、在不同分支间保留上下文、管理版本，并逐步调整各个分支。

这种方法针对的是不受约束的 agents 的一个已知弱点。语言模型可以生成看似合理的计划，但随着任务变长，其计划可能逐渐偏离目标。状态机可以减少可用路径，并让当前阶段更易于检查。

代价则是维护。业务流程会发生变化，结构化工作流也可能过时。一个高度一致地遵循过时规则的 agent，可能比一个向人类寻求指导的助手造成更大的损害。

因此，版本管理与初始生成同样重要。组织需要知道每项操作受哪个流程版本管控。它们还需要明确负责人，以便在法规、产品、系统或内部政策发生变化时更新程序。

StaffDeck 的第二项机制是文档结构感知检索。检索是指在模型生成答案或作出决策之前选择相关源材料的过程。许多系统会将文档分割成多个块，并根据语义相似度进行搜索。

StaffDeck 描述了一种更易于导航的层级结构，涵盖文档、章节、页面、摘要及其他层级。数字员工可以先估计信息最可能出现的位置，然后逐步定位到相关原文。

这种设计旨在保留简单分块可能抹去的结构。一个段落可能会因其所属章节、文档类型或与上下文中例外条款的关系而具有不同含义。层级导航可以为决策提供更多上下文。

该平台支持独立的知识库、定向检索、来源引用和检索调试。调试尤为重要，因为一个看似合理的答案可能来自错误的文档或过时的政策。

检索质量仍然取决于来源集合。StaffDeck 的维护者明确将文档质量、解析、索引、权限和模型能力列为依赖因素。可追溯性可以揭示薄弱的来源，但无法将该来源转化为准确的政策。

第三种机制是通过 HTTP 应用程序编程接口和 MCP 标准执行工具。MCP 提供了一种将 AI 应用程序与外部工具和数据源连接起来的通用方法。

这种支持让数字员工不只能检索信息。它可以调用获批服务、创建记录、检查系统或执行其他已定义的操作。计划任务可以主动启动工作，无需等待新的聊天消息。

StaffDeck 将这些操作与检索和推理事件记录在同一执行流程中。用户可以继续处理排队的请求、取消运行、将控制权转交给人员，或回答系统暂时搁置的问题。

该平台的路线图表明了当前版本尚未完善之处。计划中的工作包括数字员工之间的群组对话、智能体之间的任务分工、更多企业连接器，以及针对高风险操作制定更详细的审批政策。

这些项目并非无关紧要。多智能体协调决定了专业化数字员工能否协作，同时避免重复工作或将错误传递到下游。审批政策决定了当工具能够修改真实系统时，自主性是否仍能得到约束。

StaffDeck 目前提供了企业智能体控制闭环所需的各个组成部分。知识提供上下文，SOP 约束流程，工具执行操作，记录保存证据。人类反馈和长期记忆旨在改进未来的工作。

这一设计逻辑连贯，但项目团队之外尚未验证各个闭环的质量。企业需要开展基于场景的评估，测试完整工作流，而不是孤立的模型响应。

开源提高了可检查性，但无法彻底解决治理问题

开放代码使 StaffDeck 更易于审计和调整，但企业仍需对每项部署决策和运营风险承担责任。

StaffDeck 的 AGPL 许可证允许技术团队访问其角色、权限、检索、记忆和执行系统背后的实现。他们可以审查凭据的存储方式、检查数据流，并根据内部要求修改组件。

对于无法通过封闭服务传输敏感运营数据的组织，这种透明度可能非常有价值。StaffDeck 支持自行管理部署，并允许管理员选择兼容 OpenAI 的模型端点。

开源还减少了对单一模型提供商的依赖。如果另一个兼容模型更符合公司的安全、语言、延迟或部署要求，公司可以更换应用程序背后的端点。

然而，源代码可用并不等同于已完成安全审查。该代码仓库目前没有公布任何安全公告或正式安全认证。该版本被标记为 beta，维护者也列出了若干尚未解决的运营风险。

快速入门文档还将初始管理员凭据设置为广为人知的默认值。文档要求用户在登录后更改密码。对于本地演示而言，这可以接受，但生产部署需要更严格的初始化控制。

管理员必须管理密钥、网络暴露范围、访问权限范围、用户身份、日志、模型端点、数据库保护和备份流程。他们还必须确定每个数字员工可以调用哪些工具，以及可以在什么条件下调用。

该项目建议采用最小权限访问，即每个智能体只获得其角色所需的权限。当智能体能够调用 API 或执行会对真实系统产生影响的生成式运行程序时，这一原则至关重要。

研究型员工可能只需要对获批文档拥有读取权限。销售运营员工可能需要创建记录草稿的权限，但不能最终确定合同。财务员工不应仅凭模型判断执行交易。

人工审批可以降低风险，但审批设计不能只是添加一个确认按钮。审核者需要获得足够的上下文，以理解拟议操作、来源证据、预期后果和可用的恢复步骤。

美国国家标准与技术研究院的 AI 风险框架强调持续治理、衡量和风险管理。这些责任适用于整个已部署系统，而不只是其中的语言模型。

StaffDeck 的执行记录通过保留中间事件为这一方向提供了支持。然而，组织仍然需要制定保留政策、访问控制、事件审查流程，以及检测重复失败模式的方法。

长期记忆带来了另一个治理问题。数字员工可以通过保留反馈和工作历史得到改进，但错误记忆也可能持续存在。StaffDeck 需要提供明确的控制机制，用于审查、编辑、删除学习到的信息并标明其来源。

隐私规则让这个问题变得更加复杂。对话日志可能包含个人数据、机密战略、客户信息或受监管记录。组织必须确定智能体可以保留哪些内容，以及这些材料可以保留多长时间。

知识沉淀也可能引发雇佣关系方面的问题。StaffDeck 将数字员工视为一种把个人专业知识转化为组织资产的方式。员工和雇主可能会对哪些知识属于组织以及应如何复用这些知识产生分歧。

在受雇期间记录的流程不同于个人更广泛的专业判断。采用数字员工系统的公司需要制定透明的政策，涵盖同意、署名、监控、评估和可接受使用范围。

当多个智能体交换任务时，安全隐患会进一步增加。不受信任的文档可能包含操纵智能体的指令，这种风险通常称为提示词注入。遭到篡改的工具结果也可能以看似合理的方式影响后续操作。

由开放全球应用安全项目维护的智能体安全指南重点介绍了过度自主、工具滥用、数据暴露和输入操纵等风险。StaffDeck 的审批控制需要在工作流层面应对这些威胁。

开源为独立检查提供了机会，但不能保证每个组织都能正确部署该平台。规模较小的团队可能难以维护持续运行的智能体所需的监控和安全基础设施。

因此，最重要的质疑并不是 StaffDeck 能否生成数字员工，而是企业能否治理数百个不断变化的员工、技能、知识集合、工具权限和流程版本。

一次成功的演示或许可以展示一个智能体完成一项工作流。一个成功的平台则必须确保众多智能体长期保持正确、最新、获得授权且可理解。

StaffDeck 对企业智能体市场意味着什么

StaffDeck 将企业智能体领域的争论重点从模型智能转向组织能力的所有权与维护。

大型供应商已经提供了用于构建智能体的系统，让智能体能够访问公司数据和应用程序。它们的优势包括现有企业客户关系、身份集成、支持团队，以及连接广泛使用的商业软件的连接器。

StaffDeck 从开源角度切入市场。组织可以检查其代码、控制部署、选择兼容模型，并围绕本地流程调整平台。这种灵活性可能会吸引研究机构和拥有专门基础设施的公司。

该平台尚无法匹敌成熟企业软件供应商的分发能力或集成目录。其路线图仍包括增加更多连接器和经过审核的市场资源。这些差距可能会减缓采用速度，因为企业工作流很少只存在于单一应用程序中。

StaffDeck 的定位仍然值得关注。许多智能体产品围绕任务、对话或应用程序集成来组织自动化。StaffDeck 则围绕具有持久身份和持续演进能力的员工来组织自动化。

这种模式可以让治理更易于沟通。管理者已经熟悉职位、职责、权限、工作记录、培训和升级处理。将智能体控制映射到这些概念上，可以为企业提供一套熟悉的管理词汇。

这种比喻也可能造成误导。软件不具备人类的责任承担能力、判断力或社会理解力。将智能体称为员工，可能会促使管理者把责任交给一个实际上无法承担责任的系统。

更稳妥的理解是，数字员工是一种受到治理的软件角色。它将模型、知识来源、流程、工具、权限、记忆和监督整合为一个可复用的运营单元。

按照这一定义，StaffDeck 与其说是 AI 助手，不如说同样是一种内部应用平台。每个角色都需要设计、测试、部署、监控和维护。组织需要负责管理一整套基于智能体的应用程序。

这为企业技术团队带来了新的工作负担。他们必须决定谁可以创建数字员工、谁负责审批、谁拥有其来源知识，以及谁负责处理故障。他们还需要建立淘汰过时角色的流程。

StaffDeck 的市场概念可以加速复用，但也会带来供应链方面的隐患。一个共享技能或工作流可能会影响许多员工。变更需要版本控制、审核要求、依赖关系跟踪和回滚流程。

该平台计划推出经过审核的市场资源，这表明其开发者意识到了这一要求。审核流程的质量将比可用模板的绝对数量更加重要。

模型独立性是另一个关键问题。StaffDeck 可以连接兼容 OpenAI 的端点，让组织选择不同的托管或自行管理的模型。这种选择有助于团队在控制力和能力之间取得平衡。

兼容性并不能保证行为一致。不同模型可能会以不同方式解释流程、调用工具或应对模糊证据。使用一个模型测试通过的工作流，可能会在更换端点后失效。

企业在更换模型或核心提示词之前，需要进行回归评估。这些测试应重放具有代表性的工作流，并比较决策、工具调用、引用、升级处理和最终结果。

这一要求进一步凸显了 StaffDeck 对追踪记录的重视。如果没有完整记录，团队将无法确定模型、流程或知识更新后行为发生变化的原因。

该项目也体现了 ModelBest 更广泛的开源战略。OpenBMB 此前已发布语言模型和开发者框架，并获得 ModelBest 和清华大学研究人员的支持。StaffDeck 将这一战略推进到了应用栈的更高层。

合作方没有再发布一个基础模型，而是着力解决组织如何将模型投入实际运营的问题。这一转变反映了市场上更广泛的共识：仅仅能够访问模型，并不能实现可靠的业务自动化。

最终胜出的企业智能体平台，未必拥有最令人惊艳的独立模型。它可能是最善于在数千项日常操作中管理上下文、流程、权限、评估和纠错的平台。

StaffDeck 现在必须证明自己能够成为这样的管理层。代码开源使开发者能够审视这一主张、构建集成、报告故障，并检验“数字员工”这一抽象能否经受住真实运营复杂性的考验。

三个信号将表明 StaffDeck 能否走出测试阶段

StaffDeck 接下来面临的考验是采用质量，而非发布所获得的关注度。

第一个信号是来自真实企业部署的证据。当前文档介绍了创建角色、附加能力、运行会话、审查追踪记录和安排持续工作等工作流，但并未公布经过独立审查的任务完成率或错误率。

有价值的部署证据应明确说明工作流、基准流程、自主程度、人工审查负担以及所遇到的故障类型。与详细的运营结果相比，一份参与企业名单所能提供的洞察更为有限。

如果组织在生产环境中持续运行 StaffDeck，并发布可复现的结果，那么“数字员工”的论据将更有说服力。如果采用仍局限于演示和内部实验，那么“员工”这一定位就会显得为时过早。

第二个信号是细粒度审批策略的落地。StaffDeck 的路线图明确列出了针对高风险工具操作的更强控制机制。这项功能将决定管理员能否在不暴露整个系统的情况下授予有效的自主权。

关键细节包括条件式审批、特定操作权限、审批者身份、时限、证据呈现和回滚支持。通用的审批步骤无法覆盖企业运营中存在的各种风险。

强大的审批控制将进一步证明 StaffDeck 关于开放式智能体仍可受到治理的主张。若该功能延迟交付或控制机制过于浅显，则会削弱其竞争敏感工作流的能力。

第三个信号是形成一个由连接器和经过审核的能力组成的有效生态系统。当数字员工能够跨越工作实际发生的各种应用执行操作时，它们才会真正有用。与此同时，每项集成也会增加安全和维护负担。

StaffDeck 需要能够保留身份、权限、审计记录和错误处理机制的连接器。它还需要为共享 SOP、技能和工具建立审核流程，确保复用不会传播不安全的行为。

一个持续增长且得到积极维护的目录，将表明 StaffDeck 能够成为组织基础设施。一组未经审核的模板只会增加实验机会，却无法解决企业信任问题。

在接受任何一种极端叙事之前，开发者、企业买家和知识工作者都应关注这些信号。StaffDeck 既不是可以全面取代员工的成熟产品，也不仅仅是另一个聊天界面。

它是一项开源尝试，旨在将组织工作表示为持久且可检查的 AI 角色。该代码仓库使这一尝试足够具体，可以接受检验，而其测试阶段的状态仍留下了许多尚未解答的重要问题。

评估 ModelBest StaffDeck 企业 AI 数字员工平台的团队，应从一个范围明确的流程开始。在连接真实工具之前，他们应定义权限、成功标准、升级规则和恢复步骤。

决定性的问题不在于 StaffDeck 能否生成令人信服的输出，而在于数字员工能否完成重复性工作，同时保持信息更新、可审计、可纠正，并向人类负责人承担责任。