在 X 上花十分鐘，你就會看到有人在爭論自己做的東西到底算「AI agent」還是「agentic AI」。這場爭論根本問錯了方向。標籤從來都不是難點。真正的難點在於：你公司實際的運作方式存在於人們的腦袋裡，而不是存在於你的系統整合之中。
真正能解鎖價值的是一個應用場景：一項可重複執行的工作，讓 agent 從觸發到可審閱的結果全程負責，並且跨越你已經在使用的工具。以下 20 個場景正是我們發布的工作流程自動化範例，每一個都在今天以真實的連接器、真實的排程和真實的交付物運行。每個條目都包含啟動它的提示詞，讓你在讀完之前就能複製一個來執行。
以下每個工作流程都是一個即時範例頁面：觸發條件、連接的工具，以及產出的交付物。瀏覽全部二十個。
什麼是好的 AI agent 應用場景
並非每項任務都值得交給 agent 處理。能夠持續運作的場景都有四個共同要素，如果你能回答這四個問題，你就有了一個應用場景。
- 觸發條件，而非提醒。 工作由排程（每個工作日早上 8:45）或事件（會議摘要送達、行事曆事件移動）啟動，而不是等到有人想起來才詢問。
- 已持有脈絡的資料來源。 Agent 從答案所在的系統讀取資料——Sentry、HubSpot、Gmail、Xero——而不是要求你貼上資料。
- 明確的輸出物。 一個已建立的 issue、一份評分後的交易摘要、一份差異說明、一個已部署的頁面。某個人可以核查的東西，而不是更多的聊天文字。
- 一個審核點。 你決定哪些步驟自動完成，哪些步驟等待你確認。「起草，絕不發送」是一個有效的——而且通常是正確的——指令。
在實務上，這是唯一值得區分 agent 與 agentic AI 的標準。一個只執行某個步驟；另一個負責整項工作。以下所有範例都屬於後者。
工程與事件應變的 AI agent
工程團隊最早在日常工作中使用 agent，因為輸入資料——錯誤、日誌、pull request——本身就已結構化。
1. Sentry 錯誤轉 GitHub issue。 早上 8:45，agent 從 Sentry 和 Axiom 提取未解決的錯誤，將兩個來源中相同的根本原因合併，套用你設定的發生次數門檻，並建立附有堆疊追蹤和證據的 GitHub issue 並指派負責人。值班工程師打開筆電看到的是一份排序好的清單，而不是一堵警報牆。每天節省約 25 分鐘。
@Zero 每個工作日早上 8:45，從 Sentry 和 Axiom 提取過去 24 小時的未解決錯誤。跨來源去重。對於發生次數達 5 次以上的錯誤，建立附有完整堆疊追蹤的 GitHub issue，並指派給相關的程式碼負責人。
查看範例報告：Sentry 錯誤轉 GitHub issue。
8:45 的分類執行結果，團隊收到的樣子：來自兩個來源的 17 個原始訊號合併為 13 個根本原因，六個已建立並指派，五個低於門檻而保留。查看完整報告。
2. 每日工程簡報。 四個分頁變成一則訊息。Agent 在站立會議前從 GitHub、Linear、Sentry 和 Plausible 提取資料，將每個數字與其 7 天滾動平均值比較，並標記偏離規律的項目。沒有人需要記得上週二的流量。每天節省約 20 分鐘。
@Zero 每個工作日早上 8:30，從 Plausible、Sentry、GitHub 和 Linear 提取即時資料，標記與 7 天滾動平均值相比的異常，並將格式化的 4 節每日簡報發布到 #engineering。
查看範例報告：每日工程簡報。
3. Slack 錯誤回報轉 GitHub 修復。 在發現問題的討論串中用白話文描述錯誤。Agent 撰寫結構化的 issue、加上標籤並指派負責人，當問題根源在單一元件時，還會開一個附有修復程式碼和回歸測試的 pull request 供審閱。回報不再消失在討論串裡。
@Zero 建立 issue：在排程對話框中按下 ESC 鍵，即使有未儲存的編輯也會立即關閉。應先詢問確認。指派給 Lancy。標籤為 bug、platform。優先級中等。
查看範例報告：Slack 錯誤回報轉 GitHub 修復。
銷售與 GTM 的 AI agent
速度決定早期銷售的成敗，而決定勝負的那幾分鐘，正是通話結束後——也正是後續跟進最容易脫節的時刻。
4. ICP 研究轉外發草稿。 Agent 依照你的 ICP 在 Apollo 搜尋，根據你自己的訊號對每位潛在客戶評分，將符合資格的人寫入管道試算表，並起草個人化的多觸點 Gmail 序列，一旦有人回覆就立即停止。每批次節省約 45 分鐘。
@Zero 在 Apollo 搜尋種子輪到 A 輪開發工具新創公司的創辦人和工程主管，依照我們的 6 個 ICP 訊號對每位潛在客戶評分（0-18 分），並篩選 10 分以上的人。將符合資格的潛在客戶加入我們的 Google Sheets 管道，然後為每位潛在客戶起草 3 觸點的 Gmail 序列。一旦有人回覆，立即停止序列。
查看範例報告：ICP 研究轉外發草稿。
5. 銷售通話轉後續跟進草稿。 當摘要送達時，agent 將其與 HubSpot 交易配對，用 MEDDIC 評估健康度，引用逐字稿中每個風險的相關段落，記錄雙方承諾事項及截止日期，撰寫 CRM 備註，並準備附有你承諾文件的後續跟進電子郵件草稿。僅起草；由你決定是否發送。每次會議節省約 40 分鐘。
@Zero 當 Gmail 收到會議摘要電子郵件時，將其與 HubSpot 交易配對，用 MEDDIC 評估交易健康度，引用逐字稿標記風險，記錄雙方承諾事項及截止日期，將結構化備註寫入 HubSpot，並在 Gmail 中準備附有我們承諾文件的後續跟進草稿。絕不發送任何內容；我先審閱。
查看範例報告：銷售通話轉後續跟進草稿。
根據逐字稿撰寫的交易摘要：MEDDIC 分數及與上次會議的變化、每個風險附有時間戳記的引用，以及雙方承諾事項的記錄。查看完整摘要。
6. Calendly 預約轉 tl;dv 後續跟進。 潛在客戶在 Calendly 填寫的三個資格問題通常會消失在行事曆邀請裡。在這個流程中，它們會變成通話前簡報；一旦 tl;dv 逐字稿就緒，同一個流程就會評估交易、撰寫 HubSpot 備註，並起草後續跟進郵件。階段變更等待業務代表確認。每次會議節省約 55 分鐘。
@Zero 當 Calendly 預約了一場銷售會議時，根據預約回答和 HubSpot 歷史記錄準備通話前簡報。當對應的 tl;dv 逐字稿就緒時，評估交易，用附有時間戳記的引用標記風險，撰寫 HubSpot 備註，並建立 Gmail 後續跟進草稿。未經我的批准，絕不發送電子郵件或變更交易階段。
查看範例報告：Calendly 預約轉 tl;dv 後續跟進。
7. KOL 研究轉合作夥伴草稿。 給 agent 一個帳號名稱。它閱讀該創作者最近 30 篇貼文，找出他們真正關心的事，並儲存一封 150 字以內、引用近期具體內容的 Gmail 草稿。冷外發郵件不再像範本。每位創作者節省約 20 分鐘。
@Zero 閱讀 @swyx 最近 30 篇 X 貼文，了解他們的風格和興趣。撰寫一封關於合作夥伴關係的個人化冷外發電子郵件，150 字以內。引用他們最近發布的具體內容。儲存為 Gmail 草稿。
查看範例報告：KOL 研究轉合作夥伴草稿。
行銷、SEO 與內容製作的 AI agent
行銷工作建立在週期性研究和重複性製作上。Agent 擅長資料蒐集和第二稿，而這正是時間的消耗所在。
8. 關鍵字缺口轉多語言草稿。 Agent 從 Ahrefs 提取即時搜尋量和難度，將缺口分群，並給你一份排序好的候選清單。選定一個後，同一個流程就會撰寫文章、生成封面圖片，並將每個語言版本作為草稿發布到你的 CMS。每個主題節省約 4 小時。
@Zero 研究 AI agent 權限與存取控制相關的關鍵字。從 Ahrefs 提取搜尋量和難度，將其分組為主題群，並傳送排名前五的給我。一旦我選定一個，撰寫文章、生成封面圖片，並以草稿形式將英文、簡體中文和日文版本發布到 Strapi。
查看範例報告：關鍵字缺口轉多語言草稿。
9. 已合併 PR 轉上線文案。 本週合併了三十幾個 pull request，而有人必須判斷哪些是客戶會注意到的。Agent 讀取合併清單，保留面向使用者的變更，將其分組為主題，並在你批准後一次性將更新日誌發布到部落格、Resend 名單和 X。每週節省約 90 分鐘。
@Zero 每週五早上 9 點，讀取過去 7 天合併的 pull request。保留面向使用者的部分，將其分組為主題，並撰寫更新日誌文章。在 #marketing 預覽，然後發布到部落格，透過 Resend 發送給「subscribers」受眾，並在 X 上發布討論串。
查看範例報告：已合併 PR 轉上線文案。
10. 每週付費廣告優化。 週一的報告在你登入之前就已自動生成：每個廣告活動的週對週花費、轉換和 CPA 比較、燒掉預算卻零轉換的搜尋詞、因預算不足而損失曝光份額的廣告活動，以及下一步具體建議及其預期價值。每週節省約 3 小時。
@Zero 每週一早上 9 點，根據 Google Ads 撰寫上週的付費廣告報告。將每個廣告活動與前一週在花費、轉換和 CPA 上進行比較。列出花費超過 $20 但零轉換的搜尋詞，標記因預算不足而損失曝光份額的廣告活動，並以下週建議的變更及各項預期價值作為結尾。
查看範例報告：每週付費廣告優化。
週一的廣告報告，四項建議變更已起草，尚未套用任何內容。查看完整報告。
11. 品牌簡報轉登陸頁面。 描述品牌和頁面。Agent 撰寫每個區塊、取得授權攝影圖片、將網站提交到 GitHub，並部署到 Vercel。文案、設計、前端、部署——四個交接環節合而為一。每個頁面節省約 3 小時。
@Zero 為一個名為 AURELLE 的精品珠寶品牌建立登陸頁面。安靜奢華的調性，客製化訂製服務。包含主視覺、系列作品、客製化流程、品牌故事、FAQ 和預約行動呼籲。推送到新的 GitHub 儲存庫並部署到 Vercel。
查看範例報告：品牌簡報轉登陸頁面。
12. 螢幕錄影轉說明影片。 交出你已錄製的原始操作示範。Agent 觀看影片、撰寫腳本、生成一位主持人在前段說明概念、為操作示範配音，並將整個內容剪輯成 60 秒的說明影片。每支影片節省約 6 小時。
@Zero 這是我在 Google Drive「Dashboard Launch」資料夾中的螢幕錄影。觀看它，撰寫腳本，生成一位 HeyGen 主持人說明關鍵概念，並用 ElevenLabs 配音為操作示範配音。剪輯成 60 秒的說明影片。
查看範例報告：螢幕錄影轉說明影片。
客戶洞察與報告的 AI agent
你在定位和成長審查中需要的證據早已存在。只是分散在四個工具和三個團隊之間。
13. 客戶通話轉動態訊息文件。 每週，agent 讀取 Intercom 對話和通話筆記，提取逐字的工作需求、痛點、異議和有效的說法，區分一次性評論和反覆出現的訊號，並按區段提出對共享訊息文件的更新建議。它不會修改 CRM 欄位或發布文案。每週節省約 2 小時。
@Zero 審閱本週的 Intercom 客戶對話和 Granola 通話筆記。提取逐字的工作需求、痛點、異議和有效的說法。按 HubSpot 區段分組重複出現的訊號，並提出對 Drive 中訊息文件的更新建議。不要修改 CRM 欄位或發布文案。
查看範例報告：客戶通話轉動態訊息文件。
14. 網站分析轉每週成長報告。 兩個分析工具，一份報告。Agent 調和 Plausible 和 PostHog 的資料，只報告流量、註冊和漏斗步驟中的重大變化，在歸咎於市場之前先確認追蹤是否出現問題，並在 Notion 中撰寫報告，不主張無法佐證的因果關係。每週節省約 90 分鐘。
@Zero 每週一，在 Plausible 和 PostHog 中比較上一個完整週與前一週。只報告重大的流量、註冊和漏斗變化。交叉核查追蹤健康狀況，使用 Notion 發布記錄作為背景，並起草簡潔的報告。不要在沒有證據的情況下主張因果關係。
查看範例報告：網站分析轉每週成長報告。
兩個分析工具調和為一份報告——包括一個被標記為追蹤缺口而非轉換下降的頁面。查看完整報告。
財務與專業服務的 AI agent
週期性報告是一個完美的應用場景：相同的提取、相同的格式、每個週期。判斷的關鍵在於哪些事情是 agent 絕對不能自行捏造的。
15. Xero 實際數字轉預算差異說明。 帳本已結算，但說明仍存在於信用卡備註、發票和財務團隊的記憶中。Agent 將 Xero 實際數字和 Brex 花費與核准預算進行比較，將重大變動追溯回來源證據，區分時間性差異和結構性變化，並對任何無法佐證的項目起草一個私下問題給負責人。未知的就保持未知。每月節省約 3 小時。
@Zero 將七月的 Xero 實際數字和 Brex 花費與 Google Sheets 中的核准預算進行比較。僅使用交易和 Drive 中的證據說明重大差異。對於任何無法解釋的項目，起草一個私下問題給預算負責人。不要編輯 Xero 或發送訊息。
查看範例報告：Xero 實際數字轉預算差異說明。
月末說明，附有證據，以及一個無法解釋的差異留作問題給預算負責人。查看完整報告。
16. 行事曆活動轉計費時數摘要。 服務團隊先完成工作，之後才記錄時間，而此時會議已有通用名稱，短暫的後續跟進也被遺忘了。Agent 從行事曆活動、筆記和專案記錄重建這一週，在 Xero 中核查重複項目，並為每個建議的條目提供信心等級和來源追蹤。它絕不提交工時表或開立發票。每週節省約 90 分鐘。
@Zero 每週五，從我的 Google Calendar 和 Granola 筆記重建可能的計費時間。將其與 Airtable 中的活躍專案配對，並在 Xero 中核查重複項目。顯示每個缺失條目的證據和信心等級。絕不提交工時表或建立發票。
查看範例報告：行事曆活動轉計費時數摘要。
營運與個人效率的 AI agent
最後一組是安靜的那種：從未出現在路線圖上，卻仍然吃掉每天第一個小時的工作。
17. 每日收件匣分類。 早上 7 點，183 封郵件在等待，其中四封今天需要做決定。Agent 閱讀完整的討論串，將需要決定的放在最前面，然後是你欠回覆的，再來是有用的背景資訊，並按來源分組例行通知，不刪除任何內容。一份簡報，發送到你的 DM。每天早上節省約 25 分鐘。
@Zero 每個工作日早上 7 點，審閱過去 24 小時的 Gmail。將今天需要做決定的郵件放在最前面，然後是我欠回覆的討論串，再來是有用的背景資訊。按來源分組例行通知，不刪除任何內容。發送一份早間簡報到我的 Slack DM。
查看範例報告：每日收件匣分類。
183 封郵件，7 點前已讀完：四個決定排在最前面，暴露的 API 金鑰排在最頂端，164 封例行通知已折疊但未刪除。查看完整簡報。
18. 員工入職計畫。 每位新進員工都要花同樣的 45 分鐘協調。Agent 撰寫入職文件、預約第一週的介紹會議、發布歡迎訊息，並私訊新同事他們的議程，讓第一天不再依賴有人注意到一則 Slack 訊息。每位新進員工節省約 45 分鐘。
@Zero 為 4 月 14 日加入擔任產品設計師的 Sarah Chen 辦理入職。建立 Google Docs 入職計畫，在 Google Calendar 上安排第一週的介紹會議，安排 30 天後的追蹤會議，在 #general 發布歡迎訊息，並私訊 Sarah 她的第一週議程。
查看範例報告：員工入職計畫。
19. 行事曆變更轉可用時段。 一個會議移動了，但你的預約頁面還顯示昨天的可用時段。Agent 只重新計算受影響的時間窗口，並只編輯它自己建立的佔位保留時段。它絕不移動、刪除或重新解讀真實的會議或私人時段。每次變更節省約 15 分鐘。
@Zero 當 Google Calendar 事件被建立、更新或取消時，重新計算受影響的 Calendly 可用時間窗口。只更新此工作流程建立的佔位保留時段。絕不移動或刪除真實的會議、預約或非本工作流程建立的私人事件。
查看範例報告：行事曆變更轉可用時段。
20. X 書籤轉筆記與任務。 你在快速瀏覽時儲存了高價值的貼文，卻很少回頭閱讀它們連結的內容。Agent 做這個二次閱讀：開啟來源、在 Notion 中建立有來源的筆記、與你已知的內容去重，並只在研究支持活躍專案的具體行動時才提出 Linear 任務建議。每週節省約 60 分鐘。
@Zero 每週五，審閱我新的 X 書籤並開啟其連結的來源。與 Notion 去重，建立有來源的筆記，並只在某個項目支持活躍專案的具體行動時才提出 Linear 任務建議。絕不在 X 上發布或互動；未經批准不要建立任務。
查看範例報告：X 書籤轉筆記與任務。
AI agent 與自動化工具的比較：Zero、Zapier、n8n 和 Dify
如果你在評估 AI agent 的應用場景，你可能也在考慮 Zapier、n8n 或 Dify。它們有重疊之處，但從問題的兩端切入。Zapier、n8n 和 Dify 是建構工具：你事先設計工作流程，並自行維護。Zero 是一個 agent：你用白話文描述結果，它在每次執行時自行規劃步驟。
| 維度 | Zero | Zapier | n8n | Dify |
|---|---|---|---|---|
| 定位 | 跨工具的 AI 工作夥伴 | 觸發-動作式應用程式自動化 | 開源工作流程自動化 | LLM 應用程式與 agent 建構工具 |
| 設定方式 | 用自然語言描述工作 | 從預定義步驟建立 Zap | 在視覺化畫布上連接節點 | 在控制台中編排應用程式 |
| 非結構化輸入 | 讀取逐字稿、堆疊追蹤、討論串 | 需要可映射的欄位 | 透過你設定的 AI 節點 | 是，在你建構的應用程式內 |
| 開放式推理 | 針對目標規劃每次執行 | 固定步驟加上 AI 動作 | 固定圖形加上 AI 節點 | 是，在你的應用程式流程內 |
| 運行位置 | 雲端，按排程或事件觸發，回報到 Slack 或網頁應用程式 | 網頁儀表板 | 自架或雲端畫布 | 網頁控制台或嵌入式應用程式 |
| 存取控制 | 每個應用程式和每個動作，讀取或寫入，可設定時效 | 每個已連接的帳號 | 每個你自架的憑證 | 每個應用程式設定 |
| 模型選擇 | 隨新前沿模型發布即可切換 | 供應商內建的 AI 步驟 | 你連接的任何模型 | 你設定的任何模型 |
| 定價模式 | 點數加上自帶金鑰，非按座位計費 | 按任務和方案計費 | 免費開源，付費雲端 | 免費開源，付費雲端 |
各自的最佳使用時機：
- Zapier：當你需要兩個應用程式之間可靠的「當 X 發生，執行 Y」，且永遠不希望它自行發揮時。
- n8n：當工程師想要一個自架的、有分支的管道，並能控制每個節點時——這通常是團隊超出按任務計費後的標準答案。
- Dify：當你在建構面向客戶的 AI 應用程式或聊天機器人，並需要 RAG 和提示詞編排時。
- Zero：當工作每次形態都不同，且輸入是非結構化的時候。上述每個範例都是這類工作：一份逐字稿、一個堆疊追蹤、一週的廣告花費、183 封電子郵件。
它們並非互斥。一個 Zap 或 n8n 節點可以將判斷步驟交給 Zero，而 Zero 也可以在已有確定性管道的地方觸發它。真正的問題不是哪個工具最好，而是這項工作是一個你應該建構的固定管道，還是一個你應該交出去的開放式任務。
如何在不購買 20 個授權的情況下執行 20 個應用場景
請注意，上述每個範例都是同一個 agent 跨不同工具工作，而不是 20 個獨立的產品。由此衍生出四件事。
它在你不在時也能運行。 這些工作流程在雲端按排程或事件觸發運行，因此在你關上筆電後仍持續運作，可同時執行多個工作，並回報到你的團隊已在使用的地方。
存取權限按動作授予。 每個連接器的範圍限定於工作流程實際使用的內容，讀取或寫入，每個應用程式各自設定——對你的錯誤資料的讀取權限絕不意味著對你的儲存庫的寫入權限。授權可以設定時效為一小時或一天，敏感步驟保留在你的審核之後。
工作流程是團隊資產。 一個人建構，整個組織都可以執行，每位成員可以在上面附加自己的觸發條件、排程和憑證。沒有人需要重建一個已經存在的工作流程。
不鎖定於單一模型供應商。 你可以在新的前沿模型發布時切換，無需重建工作流程，如果你願意也可以自帶金鑰。
從這份清單中選出你的團隊每週重複執行的那一個工作流程，先把那一個交出去。在設定排程之前，先審閱一次執行結果。
常見問題
AI agent 和 agentic AI 有什麼區別？ 幾乎沒有應該改變你決策的差異。「Agentic AI」描述更廣泛的能力——能夠規劃和行動的軟體——而「AI agent」描述執行某項工作的特定實例。重要的是它是否能從觸發到可審閱的結果全程負責一個真實的應用場景，而不是它戴著哪個標籤。
Agentic AI 應用場景的主要類型有哪些？ 上述 20 個場景分為六類，這是審視你自己一週工作的有用方式：工程與事件應變、銷售與 GTM、行銷與內容製作、客戶洞察與報告、財務與專業服務，以及營運與個人效率。每種類型都有相同的結構——觸發條件、資料來源、輸出物、審核點——差異只在於哪些工具持有脈絡。
小型團隊最佳的 AI agent 應用場景是什麼？ 從工作重複、跨工具、且以可驗證的結果結束的地方開始：收件匣分類、錯誤分類、每週報告和通話後跟進。它們在第一週就能帶來回報，而且幾乎不需要設定。
這與基於規則的自動化有何不同？ 基於規則的自動化遵循固定條件，當輸入不符合時就會停滯。Agent 讀取非結構化的輸入——逐字稿、堆疊追蹤、討論串——跨工具比較，並在你設定的權限範圍內產出報告、草稿、issue 或決策摘要。
AI agent 會取代員工嗎？ 有用的框架是範疇，而不是人數。Agent 負責重複性的、跨工具的工作——分類、初稿、週期性報告——讓人們將時間花在判斷、關係和需要人類的決策上。在上述幾個範例中，agent 被明確告知只起草，絕不發送。
如何讓人類保持在迴圈中？ 在指令中說明，就像財務、銷售和行事曆範例所做的那樣：僅起草，絕不發送，絕不編輯帳本，絕不觸碰真實的會議。然後只連接工作流程需要的工具，將每個工具的範圍限定為讀取或寫入，並在排程下一次執行之前審閱第一次的執行結果。
Agent 需要哪些工具才能發揮作用？ 存取你的工作已經發生的系統。Zero 連接 200 多個工具，工作流程能夠讀取和寫入的工具越多——你的收件匣、你的儲存庫、你的 CRM、你的分析工具、你的帳本——它就能端到端負責更多的工作。這種跨工具的觸及範圍，正是 agent 與聊天機器人的區別所在。
