Demo 之後：Agents 正式採購單前，買家還要釐清什麼

摘要（TL;DR）。 一場好的 Agents demo 展示的是大門：一次登入、對的角色看到對的卡、 管理員仍握着控制。這還不是可買的正式產品包。開採購單前，先釘實範圍、 接駁、包裝、證據與數據在哪裏——否則 demo 只是共同回憶，不是交付物。

Demo 實際證明了什麼

OrchAI Agents 是 OrchAI 交付工具的單一大門。同事一次登入，看到按角色過濾的卡片網格， 點進獲准使用的工具。管理員在同一介面管理使用者與角色、登錄應用與 agent 類型，並做實例 生命週期操作。正規表面是 agents.orchai.app（修復前勿稱可示範）。

Showcase 回答的是這類問題：

• 人們能否不用記五個網址、五組密碼就找到工具？
• 能否按卡授權？
• 控制平面感覺是否管治得住？

這些都真實。它們也是體驗證明——還不是完整的工作說明書。

Demo 翌週，買家常感到的落差

機構買家（學院 IT、診所規模、受規管團隊）往往在精彩 demo 後，心裏仍有同一張安靜清單：

1. 第一期包含哪些能力？ Demo 可能展示三個模組。正式版通常要把每一個寫成核心功能—— 它必須完成的一件事——而不是一串開心路徑的拼貼。
2. 必須接駁什麼？ 檔案在 Drive／OneDrive／SharePoint／本機上載；身分在你的目錄；輸出要有落點。 接駁是工程。很少「因為簡報好看就自動包進去」。
3. 哪些是重用、哪些是新建？ 誠實的供應商會說堆疊裏已有什麼、還要建什麼。這決定時程與風險。
4. 如何證明在我們的工作上可用？ Demo 腳本不是驗收測試。受規管買家需要證據關卡——用真實文件、 角色與失敗模式做短評測——才談上線。
5. 處理跑在哪裏？ 地端設備、自有雲、混合或氣隙。對機密文件而言，「demo 為了方便托管在某處」 不是正式答案。

這些沒寫清楚之前，採購單都嫌早——即使全場都很喜歡那一場。

開單前的冷靜清單

可當買賣雙方的共同議程：

釐清項	夠清楚的答案聽起來像…
範圍	「能力 A 只做這一件事；B、C 屬第二期。」
接駁	「輸入來自 X／Y；身分經 Z；輸出到 W。」
包裝	「Agents 是這次 OrchAI 部署的大門（搭配 Library／作為 Portal 一部分）——不是神秘的第五個 SKU。」
證據	「驗收＝這些任務、這些角色、這條品質線；弱結果也公開，不藏。」
數據駐留	「處理留在這裏；密鑰進保管庫；沒有驚喜的第三方呼叫。」
商務	「採購單覆蓋這個包裝與這些假設——其餘走變更控制。」

注意清單沒有什麼：更大的模型「B」、更長的功能矩陣，或保證 demo 環境等於正式拓撲。

這與我們做的事有什麼關係

在 AiHPC，我們把 showcase 當成對話起點，不是合約。OrchAI Agents 作為 OrchAI 部署看得見的大門出貨—— 需要引用知識時配 Library、需要品質關卡時配 Eval、需要整座受管大樓時配 Portal。從 demo 到採購單的誠實路徑是 先釐清，再按書面包裝去建。

若你已過了 wow 簡報、準備把那份包裝寫下來，與我們聯絡 或 試用演示，並帶上上面的清單。

常見問題

Demo 成功就代表可以買了嗎？ 代表你們對體驗有共同圖像。正式交付仍需要範圍、接駁、托管、驗收與商務條件。

OrchAI Agents 一句話是什麼？ 啟動器＋控制平面：一次登入、按角色的卡片、管理員登錄與權限——OrchAI 部署的大門。

正式採購單前應釐清什麼？ 對每個能力：一件核心工作、接駁、重用 vs 新建、如何量度成功、數據在何處處理——然後包裝那一套。