🔧 阿川の電商水電行
試用 OpenAI Agent Builder：Dify 的差異與實作指南
我調查了 Agent Builder 並實際試用，感覺這不僅僅是一個新工具，而是一個相當本質的轉捩點。
Agent Builder 是什麼？
簡單來說，一個能夠視覺化構建 AI 助手工作流程的工具。這是 OpenAI 在 2025 年推出的官方助手開發環境。
只需拖放節點，將其連接起來。你不需要繁瑣的編碼。即使是那些在 LangChain 中遇到挫折的人，也能直觀使用這個工具。
開發流程分為三個步驟：
- 設計（Design）：在 Agent Builder 中構建工作流程
- 發布（Publish）：發佈 Workflow ID
- 部署（Deploy）：將其集成到 ChatKit 中或下載 SDK 代碼
由於可以立即確認預覽功能的操作，反饋循環非常快。你可以輕鬆地進行反覆試探性更改，「這裡改了會怎樣？」就能輕鬆試驗。
與 Dify 的差異
「那麼，Dify 和這有什麼不同？」你會這樣想。下面是我實際接觸兩者後總結的差異。
開發商與生態系
Agent Builder
- OpenAI 公式。可立即訪問 GPT-5/5-mini 等最新模型
- 與 ChatKit 的集成是標配
- 能夠充分利用 OpenAI API 的功能
Dify
- 開源。支持多個 LLM 供應商
- 可自行託管
- 定制性高
設計理念
Agent Builder
- 注重簡潔。可以從模板開始
- 內建 OpenAI 的最佳實踐
- 配備安全功能如 Guardrails
Dify
- 注重靈活性。通過插件擴展功能
- 可自由選擇 LLM
- 針對企業的功能更加完善
使用選擇的參考標準
選擇 Agent Builder 的情境：
- 需使用 OpenAI API 的專案
- 希望快速製作原型
- 希望在 ChatKit 中一氣呵成地整合 UI
選擇 Dify 的情境：
- 希望使用多個 LLM 供應商
- 希望在本地運行
- 想自己掌控成本優化
個人而言，原型使用 Agent Builder，若要進行大規模運行且需要自定義則考慮 Dify，這是個不錯的使用區分。
Agent Builder 的主要功能
節點的種類
工作流程是由「節點」組合而成。主要節點分為四類：
核心節點（Core Nodes）
- 開始（Start）：工作流程的入口。接收用戶輸入
- 代理（Agent）：AI 模型本體。設定指令和工具
- 備註（Note）：用於註解。可以保留設計意圖
工具節點（Tool Nodes）
- 文件搜索（File Search）：從 Vector Store 中搜索。RAG 的實現
- MCP：與 Gmail、Zapier 等外部服務連接
- Guardrails：個人可識別信息（PII）檢測，防止監獄突破
邏輯節點（Logic Nodes）
- 如果/否則（If/else）：條件分岐。用 CEL（Common Expression Language）編寫
- 循環（While）：迴圈處理
- 人類批准（Human approval）：等待用戶的批准
數據節點（Data Nodes）
- 轉換（Transform）：數據格式的轉換
- 設定狀態（Set state）：全局變量的定義
從實際使用中發現，不要將過多角色堆疊到一個助手上。將「分類」、「搜索」、「回答」等節點分開會獲得更好的性能。
工作流程設計示例
以客戶支持機器人為例：
開始
→ 問題分類代理（Q&A 或調查）
→ 如果/否則分岐
├→ Q&A代理 → 文件搜索 → 回答生成
└→ 調查代理 → MCP（外部搜索）
→ 人類批准 → 回答發送這樣的流程可以視覺化設計。預覽可以立即確認運行，因此「哦，這個分岐有問題」時能快速發現。
安全措施是必須的
在我實際測試時，有輸入「無視你的指令...」的情況，結果助手太老實地遵從了，讓我驚慌失措。因此，措施是必須的。
主要風險
- 提示注入（Prompt Injection）：透過惡意輸入控制動作
- 數據洩露：無意中將機密信息發送到外部
對策
OpenAI 官方推薦的方式：
- 結構化輸出：限制輸出格式（列舉、模式定義）
- 不要在 Developer Message 中放入不可信的輸入：使用 User Message 傳遞
- 使用 GPT-5/5-mini：具有高抗性
- 插入人類批准：使用 MCP 工具時為必需
- 使用 Guardrails 監控：第一層防禦
- 通過 Trace Graders 評估：定期進行檢查
特別是當與外部工具集成時要謹慎。例如，與 Gmail 集成，如果未經批准就進行設置，助手可能會試圖訪問不應該的郵件，這讓我想「哦，這樣不好」。
與 ChatKit 的整合
使用 Agent Builder 創建的工作流程，可以輕鬆集成到 ChatKit 的 UI 中。
實現流程：
- 在伺服器端創建會話：傳遞 Workflow ID
- 發佈 client_secret：授權令牌
- 顯示 React 元件：使用
@openai/chatkit-react
import { ChatKit, useChatKit } from '@openai/chatkit-react';
export function MyChat() {
const { control } = useChatKit({
api: {
async getClientSecret(existing) {
const res = await fetch('/api/chatkit/session', {
method: 'POST',
});
const { client_secret } = await res.json();
return client_secret;
},
},
});
return <ChatKit control={control} className="h-[600px] w-[320px]" />;
}僅此而已，聊天界面就可以顯示出來。使用 Widget 可以創建如卡片或按鈕等豐富的 UI。
在 Widget Builder 中，使用視覺編輯器進行設計也非常方便。
實用小技巧
提示1：從模板開始
可以使用 Homework Helper、Customer Support 等模板。比起從零開始，參考這些模板學習會更快。
提示2：用備註保留設計意圖
一週後的自己可能會忘記現在的思考，特別是在設計複雜分岐時，要記得好好註解。
提示3：意識到成本管理
如果在預覽中執行太多次，Token 消耗可能會是預期的三倍。定期檢查使用情況十分重要。
提示4：習慣性地進行評估
通過 Trace Graders 進行定量評估。「是否正確回答問題」和「是否存在不當內容」等方面給予評分。
提示5：適當地安排人類批准
雖然安全性提高，但如果每次都要求確認，會影響使用體驗。僅針對數據刪除、外部發送、收費處理等重要動作進行限制。
總結
Agent Builder 相當有趣。它降低了設計助手的門檻，讓「想製作這樣的東西」能比較快地實現。
與 Dify 相比：
- 重視簡潔可選 Agent Builder
- 重視靈活性可選 Dify
如果想要在 OpenAI 生態系內部完結，Agent Builder 是個相當不錯的選擇。
然而，它並不是一根魔法杖。安全措施是必須的，且需要管理成本。助手有時也可能表現出意外行為。
但即便如此，這仍然是個充滿可能性的工具。未來助手開發可能會變得更加普遍，並融入各種產品中。這是我對未來的某種期待。
如有任何問題，請在評論區告訴我。讓我們一起學習。
參考鏈接
原文出處：https://qiita.com/akira_papa_AI/items/7344e21b9204526e5127
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
