企業這兩年買了不少 AI 工具：聊天助手、寫作外掛、客服機器人、內部知識問答。真正沉澱下來的能力卻不多。提示詞還在個人電腦裡，業務流程散落在文檔角落，智能體上線後缺少反饋和修訂，業務骨幹仍然被同一類諮詢佔滿工時。問題往往不是模型不夠聰明，而是系統沒有把「干活」設計成可管理的崗位能力。
先拆清：聊天窗口為什麼當不了崗位
聊天機器人回答一次問題就結束。崗位要連續承接工作：收集資訊、判斷規則、調用系統、寫回狀態、遇到例外再升級。差旅報銷是典型例子——用戶可能先說「幫我報差旅」，中途又問「這個月額度還剩多少」，隨後再補一張發票。如果系統把每次對話都當成新會話，流程會斷，上下文會丟，事後也無法復盤是規則錯了還是介面錯了。
行業裡已有把智能體按「數字員工」來建的做法：給它崗位、工號、能力邊界和工作記錄，再配上可修訂的 SOP、知識庫、工具和執行軌跡。開源方向上，OpenBMB 等機構發布的 StaffDeck 就把 Agent 寫成可營運的資源組合，而不是一段提示詞。對企業自研或客製來說，值得借的不是產品名詞，而是這套對象模型。
業務邏輯：系統裡至少要有七類對象
做數字員工系統，先把業務對象寫進規格，再談模型選型。
- 崗位檔案：姓名或角色名、工號、職責、線上狀態、服務對象。沒有檔案，權限和考核無處掛靠。
- 能力邊界：能讀哪些單據、能寫哪些字段、不能承諾什麼。邊界要能被管理員改，而不是寫死在提示詞裡。
- SOP / 流程型技能：把複雜流程拆成節點，支持條件分支、工具調用、知識檢索和轉人工。
- 知識本體：主題、規則、來源、操作手冊分開存，回答必須能指回來源，檢索要能調試。
- 工具接入：HTTP 接口或 MCP，用來查額度、創建單據、改狀態，而不是只生成一段話。
- 定時任務：日報匯總、超時催辦、庫存巡檢這類週期活，不能等用戶先開口。
- Trace 與反饋：記錄路由、步驟、工具、知識和回覆；點讚差評和人工接管進入下一轮修訂。
一次真實請求常常包含多個任務。數字員工要能先進入報銷 SOP，收齊字段並做規則判斷，再切換到額度查詢 SOP 調接口。用戶中途插問政策，應保存當前節點，答完再回到原流程。超出規則的問題，把上下文交給創建者或值班人，禁止無依據強答。
設計邏輯：角色、狀態機、知識分層
角色怎麼切
至少分四類人：創建者（把經驗固化成員工）、管理員（管權限、發布、配額）、使用人（向數字員工派活）、值班人（接例外）。創建者不應默認擁有改庫存、改價格的權限；使用人不應看到完整提示詞和密鑰。開放介面也要分層：帳號級密鑰能管資源配置，員工級密鑰只能創建會話和讀自己的軌跡。
SOP 用狀態機，不要只用對話記憶
自然語言可以生成初稿，執行必須走狀態機：當前節點、已收集槽位、可調用工具、失敗重試、人工節點。任務被打斷後要能序列化上下文，回到原節點繼續。多個 SOP 允許實時切換，但切換要留「從哪來、帶了什麼已確認資訊」，避免用戶重複填表。版本和分支要可回滾，現場改一句提示詞就上線，後續一定無法追責。
知識不要做成大雜烩檢索
按文檔、章節、頁面、摘要建可導航索引，先判斷資訊可能在哪一類，再定位原文。知識分桶：制度口徑、產品說明、售後話術、例外案例分開，定向檢索比全域關鍵詞更穩。每條回答綁定來源、規則和業務主題，測試環境要能看到「為什麼命中這一段」。檢索調試比再換一個更大的模型更常解決問題。
開發落地：介面、隔離、觀測、驗收
運行時建議統一入口，避免每個技能各走一套鏈路導致狀態漂移。能力發現、隔離執行、工件完整性、配額核算要在運行時完成，而不是靠約定。技能發布到內部市場前，做權限掃描：認證頭、環境變量、連接憑證不得出現在普通讀取介面裡。
- 執行通道：同步流式適合對話；異步 Run + 事件流適合斷線續傳和任務隊列，兩者共用同一套內核。
- 渠道身份：微信、企業微信、飛書、釘釘可以做入口，但員工身份、會話和 Trace 必須統一，禁止各渠道各建一套記憶。
- 安全：模型配置只引用已有配置編號，不回傳供應商密鑰；工具結果進 Trace 時做脫敏。
- 人工兜底：超時、低置信、越權、用戶主動轉人工，四條都要能把上下文完整交接。
驗收不要只測「能聊天」。給一組可重複腳本：正常閉環、中途插問、額度不足、介面超時、越權寫入、無來源拒答。每條腳本核對：節點是否恢復、單據是否寫對、Trace 是否完整、例外是否落到人。抽檢通過率、超時處理率、無依據回答次數，比滿意度星級更適合作為上線門禁。
上線順序：先一段重複勞動
不要一上來做全能助手。選銷售跟進紀要、審批催辦、制度問答或費用預審裡每天重複半小時以上的一段，把輸入、輸出、權限、例外寫成四句話，再配 SOP 和兩三個只讀或受限寫入介面。主數據髒、審批節點不清時，先補對象和狀態，再疊智能執行——髒數據被自動化之後，只會更快傳遍全公司。
怎樣算設計做對了：原來靠群催、靠表填的那一段不再是主路徑；紀要、催辦、匯總能對照單據抽檢；說不清的情況有升級對象；敏感操作有人審、日誌能查。衡量開發是否合格，看同一條 SOP 被打斷後能否恢復、回答能否指回來源、邊界案例能否進入下一轮修訂。這三項過了，再擴崗位，比先鋪很多聊天入口更穩。
數字員工系統的技術難度，不在對話生成，而在把崗位、流程、知識、工具和軌跡做成可版本化的軟體對象。提示詞可以一周改十次，對象模型一旦散了，後面每個技能都會各寫一套。先把這七類對象和狀態機跑通，模型升級才換得起；否則每次換模型，都是一次新的專案，而不是一次配置變更。