企业这两年买了不少 AI 工具：聊天助手、写作插件、客服机器人、内部知识问答。真正沉淀下来的能力却不多。提示词还在个人电脑里，业务流程散落在文档角落，智能体上线后缺少反馈和修订，业务骨干仍然被同一类咨询占满工时。问题往往不是模型不够聪明，而是系统没有把「干活」设计成可管理的岗位能力。
先拆清：聊天窗口为什么当不了岗位
聊天机器人回答一次问题就结束。岗位要连续承接工作：收集信息、判断规则、调用系统、写回状态、遇到例外再升级。差旅报销是典型例子——用户可能先说「帮我报差旅」，中途又问「这个月额度还剩多少」，随后再补一张发票。如果系统把每次对话都当成新会话，流程会断，上下文会丢，事后也无法复盘是规则错了还是接口错了。
行业里已有把智能体按「数字员工」来建的做法：给它岗位、工号、能力边界和工作记录，再配上可修订的 SOP、知识库、工具和执行轨迹。开源方向上，OpenBMB 等机构发布的 StaffDeck 就把 Agent 写成可运营的资源组合，而不是一段提示词。对企业自研或定制来说，值得借的不是产品名词，而是这套对象模型。
业务逻辑：系统里至少要有七类对象
做数字员工系统，先把业务对象写进规格，再谈模型选型。
- 岗位档案：姓名或角色名、工号、职责、在线状态、服务对象。没有档案，权限和考核无处挂靠。
- 能力边界：能读哪些单据、能写哪些字段、不能承诺什么。边界要能被管理员改，而不是写死在提示词里。
- SOP / 流程型技能：把复杂流程拆成节点，支持条件分支、工具调用、知识检索和转人工。
- 知识本体：主题、规则、来源、操作手册分开存，回答必须能指回来源，检索要能调试。
- 工具接入：HTTP 接口或 MCP，用来查额度、创建单据、改状态，而不是只生成一段话。
- 定时任务：日报汇总、超时催办、库存巡检这类周期活，不能等用户先开口。
- Trace 与反馈：记录路由、步骤、工具、知识和回复；点赞差评和人工接管进入下一轮修订。
一次真实请求常常包含多个任务。数字员工要能先进入报销 SOP，收齐字段并做规则判断，再切换到额度查询 SOP 调接口。用户中途插问政策，应保存当前节点，答完再回到原流程。超出规则的问题，把上下文交给创建者或值班人，禁止无依据强答。
设计逻辑：角色、状态机、知识分层
角色怎么切
至少分四类人：创建者（把经验固化成员工）、管理员（管权限、发布、配额）、使用人（向数字员工派活）、值班人（接例外）。创建者不应默认拥有改库存、改价格的权限；使用人不应看到完整提示词和密钥。开放接口也要分层：账号级密钥能管资源配置，员工级密钥只能创建会话和读自己的轨迹。
SOP 用状态机，不要只用对话记忆
自然语言可以生成初稿，执行必须走状态机：当前节点、已收集槽位、可调用工具、失败重试、人工节点。任务被打断后要能序列化上下文，回到原节点继续。多个 SOP 允许实时切换，但切换要留「从哪来、带了什么已确认信息」，避免用户重复填表。版本和分支要可回滚，现场改一句提示词就上线，后续一定无法追责。
知识不要做成大杂烩检索
按文档、章节、页面、摘要建可导航索引，先判断信息可能在哪一类，再定位原文。知识分桶：制度口径、产品说明、售后话术、例外案例分开，定向检索比全域关键词更稳。每条回答绑定来源、规则和业务主题，测试环境要能看到「为什么命中这一段」。检索调试比再换一个更大的模型更常解决问题。
开发落地：接口、隔离、观测、验收
运行时建议统一入口，避免每个技能各走一套链路导致状态漂移。能力发现、隔离执行、工件完整性、配额核算要在运行时完成，而不是靠约定。技能发布到内部市场前，做权限扫描：认证头、环境变量、连接凭证不得出现在普通读取接口里。
- 执行通道：同步流式适合对话；异步 Run + 事件流适合断线续传和任务队列，两者共用同一套内核。
- 渠道身份：微信、企业微信、飞书、钉钉可以做入口，但员工身份、会话和 Trace 必须统一，禁止各渠道各建一套记忆。
- 安全：模型配置只引用已有配置编号，不回传供应商密钥；工具结果进 Trace 时做脱敏。
- 人工兜底：超时、低置信、越权、用户主动转人工，四条都要能把上下文完整交接。
验收不要只测「能聊天」。给一组可重复脚本：正常闭环、中途插问、额度不足、接口超时、越权写入、无来源拒答。每条脚本核对：节点是否恢复、单据是否写对、Trace 是否完整、例外是否落到人。抽检通过率、超时处理率、无依据回答次数，比满意度星级更适合作为上线门禁。
上线顺序：先一段重复劳动
不要一上来做全能助手。选销售跟进纪要、审批催办、制度问答或费用预审里每天重复半小时以上的一段，把输入、输出、权限、例外写成四句话，再配 SOP 和两三个只读或受限写入接口。主数据脏、审批节点不清时，先补对象和状态，再叠智能执行——脏数据被自动化之后，只会更快传遍全公司。
怎样算设计做对了：原来靠群催、靠表填的那一段不再是主路径；纪要、催办、汇总能对照单据抽检；说不清的情况有升级对象；敏感操作有人审、日志能查。衡量开发是否合格，看同一条 SOP 被打断后能否恢复、回答能否指回来源、边界案例能否进入下一轮修订。这三项过了，再扩岗位，比先铺很多聊天入口更稳。
数字员工系统的技术难度，不在对话生成，而在把岗位、流程、知识、工具和轨迹做成可版本化的软件对象。提示词可以一周改十次，对象模型一旦散了，后面每个技能都会各写一套。先把这七类对象和状态机跑通，模型升级才换得起；否则每次换模型，都是一次新的项目，而不是一次配置变更。