企业引入 AI Agent 时，真正困难的往往不是模型会不会回答，而是它能否按流程办事、给出可追溯依据、识别越权边界，并在反馈中持续改进。演示里很聪明的 Agent，一旦进入报销、法务、人事或 IT 支持等真实业务，常会暴露流程跑偏、依据不明和错误反复出现的问题。
面壁智能联合相关实验室与 OpenBMB 等团队开源的 StaffDeck，尝试把 Agent 从聊天工具改造成可以创建、发布、运营和治理的“数字员工”。项目官方定位是企业数字员工构建与管理平台，并采用 AGPL-3.0 开源许可。
从“工具”变成有岗位边界的数字员工
StaffDeck 不把 Agent 看成等待一次提问的解题器，而是赋予它岗位、工号、能力范围、访问权限、知识、SOP 和工作记录。管理者不仅能看到它会什么，也能根据真实任务、用户反馈和人工接管记录继续调整能力。
岗位化
明确服务对象、职责、权限与不可处理的边界。
流程化
用状态机和 SOP 约束关键业务步骤。
可运营
记录 Trace、反馈和人工处理，持续优化知识与流程。
第一层：状态机驱动的流程型技能
纯技能调用灵活，但复杂流程容易跳步；纯工作流路径明确，却难以处理临时提问和流程外情况。StaffDeck 把 SOP 封装为流程型技能，并以状态机管理确定性节点，让数字员工既能按章执行，也能在多个流程间切换。
业务人员可以用自然语言描述“先收集什么、满足什么条件、何时调用工具、何时转人工”，平台再生成可视化流程供人工确认。执行中遇到插问时，当前状态可以暂存，回答完后回到中断节点继续。
第二层：结构感知、可溯源的企业知识库
传统 RAG 常把文档切成碎片，模型不容易判断某段内容是强制规则、操作手册还是历史案例。StaffDeck 引入开放知识格式 OKF，并保留文档、章节、页面和摘要等结构，让检索先定位可能的区域，再逐层找到原文。
管理员可以查看每次回答命中了哪份文件、哪一章节以及相关度，从而调试检索策略。这里的关键不是让回答看起来更像专家，而是让依据可以被复核、权限可以被控制、错误可以被定位。
第三层：Trace、反馈与人工接管组成改进闭环
静态发布的 Agent 不会因为一次差评自动变可靠。StaffDeck 记录意图、检索、技能、工具调用和结果，并把用户反馈与任务记录交给管理员分析。遇到制度没有覆盖或高风险操作时，数字员工可以保留上下文并请求人工接管。
报销案例：一句话生成流程，再在对话中执行
原始案例先用一段自然语言描述报销 SOP。这里保留完整 Prompt，便于理解系统如何把业务口径转成流程。
用户申请差旅报销时，先收集报销事由、金额和行程，再核对是否超过差旅补助标准；未超标则继续收集发票信息并提交报销单，超标则转交财务负责人审批。
实际请求同时包含“办理报销”和“查询额度”两个任务：
我上周去上海出差，帮我报一下差旅费，顺便看看这个月的报销额度还剩多少。
数字员工先收集行程与金额，中途遇到“上海餐补标准是多少”的插问时，暂停当前流程并检索知识库；回答后回到原节点，继续填报并调用接口查询额度。制度没有覆盖的情况则转交财务负责人。
部署与企业集成：开源不等于开箱即用
官方仓库提供 macOS、Windows、Linux 安装方式，也支持开发环境部署；应用本身不要求本地 GPU，但需要可用的 OpenAI 兼容模型接口。平台可通过 HTTP API、MCP 与企业系统连接，并支持计划任务。
| 上线前检查 | 为什么重要 |
|---|---|
| 模型与网络 | 回答质量、延迟和可用性依赖所配置的模型服务。 |
| 最小权限 | 外部工具可能产生真实写入、审批和数据变更。 |
| 人工审批 | 高风险操作与制度灰区不能交给模型自行决定。 |
| 隐私与许可 | 需评估数据合规、AGPL-3.0 义务与内部安全规范。 |
我们的观点：数字员工首先是治理系统
StaffDeck 最值得关注的并不是“给 AI 发工号”这个叙事，而是把企业 Agent 需要的流程、知识、权限、观察、反馈和人工接管放进同一套运营框架。底层模型决定能力上限，治理系统决定它能否稳定进入业务。
不过，平台仍处于 Preview 阶段。官方仓库也明确提醒：模型回答可能错误，检索质量依赖源文档与索引，外部工具会产生真实副作用，受监管业务不能缺少授权、隐私保护和人工监督。企业更适合从低风险、可量化、可回滚的流程开始验证，而不是一开始就让数字员工接管关键决策。
