《AI 深度工作流》專為現代知識工作者打造。我們結合「學術的嚴謹度」與「企業的實戰力」，每週為你萃取一套高可靠度的 AI 工作流與防呆 SOP。帶你擺脫無效對話，從「做事的人」真正升級為駕馭 AI 的「系統設計者」。
【AI 深度工作流 #07】當 AI Agent 不再只是幫你做一件事，真正重要的，是怎麼把它設計成一套工作流
主編的話各位朋友， 很抱歉，已經有一段時間沒有發送電子報了。 主要原因是，過去的內容規劃方式運作了一陣子之後，我慢慢發現：不能說這些內容沒有幫助，但對我自己而言，多少有一點像是在做「資訊搬運工」。 所以這段時間，我也一直在思考：這份電子報接下來究竟應該怎麼調整？ 到了今天，總算有了一個比較明朗的方向。我們就姑且把它稱為 【AI 工作流 2.0】 吧。 這接近兩個月的時間，我其實也沒有閒著。 除了持續執行不同的實際任務之外，每次成果交付之後，我也會順手整理過程中的心得，以及那些在任務執行時真正用到、而且值得和大家分享的 Agentic System 設計觀念與細節。 這兩年來，尤其是今年逐漸將 AI 應用聚焦在「學術輔助研究」以及「知識工作者的 AI Agent 應用與管理」這兩個大方向之後，有三個核心問題一直在我心中反覆思考：
坦白說，這三個問題至今還沒有一個「從輪廓到細節都完全定型」的答案。 不過，也正因為這一期電子報延遲了兩個月，反而讓我有機會回頭重新檢視這段時間累積下來的案例。 結果我才發現：其實輪廓與細節並沒有想像中那麼模糊。 更準確地說，是因為 AI 的變化實在太快，我們很難先建立一套固定不動的方法，再照著它一路往下走；更多時候，是必須跟著技術變化與眼前任務，在適當的時機，選擇適當的方法、深度與工具。 什麼意思？ 大家繼續往下看看這兩個月累積下來的案例，以及我在每個案例中試著整理出的實作重點，應該就會比較清楚了。 AI 工作流｜案例設計分享這個段落，我想換一種方式和大家分享過去幾篇文章。 與其單純告訴大家「最近有哪些文章可以看」，我會從實際案例的角度出發，簡單交代：
另外，在「補充資料」這一部分，我們最近也正式釋出了 智慧小編。 智慧小編會試著站在一般知識工作者的需求上，重新解讀值得閱讀的 AI 技術文章與研究資料。因此，接下來補充閱讀的部分，我們會優先分享智慧小編整理過的導讀貼文；每篇導讀裡也都會附上原始資料，有興趣的朋友可以先看導讀，再決定是否深入閱讀原文。 案例一、IRB 審查模擬 Agent Skill這個案例來自一位我正在輔導的學生。 當時她正在準備研究相關的 IRB 審查，實際上還有許多更具體的忙點與需要協助的地方，這裡就不展開了。後來，我們根據她的需求，設計出了一套 IRB 審查模擬 Agent Skill。 這套 Agent Skill 比較特別的地方在於，它不是讓「同一個 AI」從頭做到尾。 整個流程裡，我們分別需要：
因此，整體採用了 Multi-Agent 架構。 而且，為了避免不同角色彼此污染判斷，我們還進一步做了上下文隔離（Context Isolation）。 如果你正在思考 Multi-Agent 該怎麼拆、不同 Agent 之間的資訊到底該不該共享，我相信這個案例會帶來不少啟發。 文章： 相關補充資料：
案例二、流程拆解 × LLM Wiki 的綜合應用這個案例來自我們企業內訓中的一個綜合範例。 我想透過它示範的是：一個比較完整的 Agent 工作流，究竟可以做到什麼程度？ 整套流程包含： 結構化萃取 → 分受眾輸出 → 綜合診斷報告 → LLM Wiki 知識庫歸檔 也就是說，我們不再只是把某一個單點任務丟給 AI，而是開始思考： 一個原本由人類完成的判斷流程，究竟可以如何拆解、分工，再重新組裝成一套 AI 工作流？ 這也是我認為 Agentic System 真正開始產生價值的地方。 文章： 相關補充資料：
案例三、用「失敗測試」挑選 AI 助教產品的底層框架近期我們有一個 AI 助教產品，正準備從概念驗證（PoC）逐步走向正式 MVP。 在概念驗證階段，我們使用 Hermes Agent 作為快速測試框架。 但問題來了： PoC 可以跑，不代表它就適合拿來做正式產品。 那正式產品的底層架構，到底該怎麼選？ 與其列出一大堆框架功能做比較，我們後來採取了另一種方法：先設計一組我們認為正式產品絕對不能失敗的情境，再看看候選框架會不會踩雷。 最後，我們也正是透過這些「失敗測試」，確認了 Hermes Agent 在我們這個產品情境中為什麼不適合繼續往正式產品發展。 如果你也正在選 Agent Framework，我很推薦從這個角度來看架構評估。 文章： 相關補充資料：
案例四、以規格驅動開發，實作微軟研究院的 Claimify 主張提取器這個案例源自一位醫師提出的需求。 我們從他的實際問題出發，逐步發展出一個概念雛形，最後決定以微軟研究院提出的 Claimify 為基礎，實作一套主張（Claim）提取器。 這次實驗，我們選擇使用 Matt Pocock 的 Engineering Skills 來探索需求並進行實作。 整個過程中，讓我印象最深刻的其實不只是最後做出來的功能，而是 Matt Pocock 在 Skills 裡所呈現的一套工程設計思想： 規格很重要，但真正困難的地方，往往不是「把規格寫完整」，而是如何把原本存在於人腦中的模糊需求、隱性知識與判斷標準，一步一步逼出來。 這也成為我這次實驗最大的收穫之一。 細節這裡就不展開了，有興趣的朋友可以直接看文章。 文章： 相關補充資料：
案例五、使用 Agent 幫內容做「對抗性審查」——How？很感謝大家一路看到這裡。 先偷偷告訴大家一件事： 這篇文章裡，我免費公開了一套「模擬一般讀者審查內容」的 Agent Skill。 這個案例最初來自一個很典型的問題： 當我們對自己的專業領域太熟悉之後，反而很容易忘記「一般讀者不知道什麼」。 有些我們認為理所當然的概念、跳躍得非常自然的論證，在讀者眼中可能根本接不起來。 那麼，Agent 能不能反過來扮演「不懂你的那個人」，替我們挑出內容中的理解障礙？ 這就是這個案例想處理的問題。 至於整個故事的原委以及 Skill 怎麼設計，這裡就不劇透太多了，直接打開文章看就對了！ 文章： 相關補充資料：
想實作自己的 Agentic System / AI 工作流程？很高興你一路看到了最後。 如果你現在也正在思考：
我們目前正開放一個 AI 工作流雛形實作服務 的申請： https://forms.gle/VZYbbTW6Bymkk1iSA 你可以先免費和我們聊聊你的想法，我們也會根據你的需求，提供初步的方向建議。 不過要特別提醒一下： 本週末（2026/08/23）就是本期申請的最後截止日。 如果你剛好有一個一直想做、卻還不知道該怎麼落地的 AI 工作流程，記得把握最後的申請時間。 Ted |
AI 深度工作流
《AI 深度工作流》專為現代知識工作者打造。我們結合「學術的嚴謹度」與「企業的實戰力」，每週為你萃取一套高可靠度的 AI 工作流與防呆 SOP。帶你擺脫無效對話，從「做事的人」真正升級為駕馭 AI 的「系統設計者」。
大家這幾天有沒有被 Claude Fable 5 的能耐驚艷到？我這幾天看到 One Useful Thing 分享的一個實驗任務——製作等時線地圖——是真的被嚇到了。 收到指令的 Fable Agent，自己去爬了機場、火車、步行、駕駛各種交通方式的實際數據，然後才依照蒐集到的情報來動手繪製。成果非常精美（本期延伸閱讀的〈What it feels like to work with Mythos〉裡有動態地圖可以親自體驗）。 但讓我真正停下來想的，不是它做得多漂亮，而是另一件事：當 AI 強到可以把一整個任務黑盒子地接走，那我這個人，到底還剩下什麼價值？ 我這陣子越來越確信一個有點違反直覺的答案——這個答案不在任何新技術裡，而在那些我們「早就知道很重要、卻一直不太在意」的老概念上。比方說「以終為始」這種被講到爛的常談：行動之前先想清楚要的是什麼。聽起來像廢話，但你問自己一句——有多少人在把任務丟給 AI 之前，真的做到了？ 又比方說我們過往做工程、做研究時的那種「嚴謹」，到了 AI 全自動的時代，是不是就不需要了？...
嗨，大家好，我是 Ted。 最近我在輔導幾個學員的時候，有個現象讓我印象深刻。 他們不是剛開始學 AI 的人——他們手上都已經有好幾個助理了。有人有寫作助理、有摘要助理、有資料分析助理。每一個單獨用起來都不錯。但有一天其中一個學員問我： 「Ted，我現在每次要用 AI，都要停下來想：這件事應該找哪一個？這個切換的過程，比我自己做還累。」 我聽完笑了，因為這幾乎是每個認真在用 AI 的人，走到某個階段都會遇到的問題。 這讓我意識到：我們花了很多時間在談「如何讓單一 AI 助理更好用」，但幾乎沒有人在談「當你有了一堆助理之後，整個系統該怎麼設計」。 這期電子報，我想圍繞這個問題，從幾個不同角度切入。 主文我挑了 Anthropic 設計主管 Jenny Wen 的工作流訪談——她分享了一個核心概念：不是一個一個助理單點使用，而是讓多個來源、多個流程，自動整合成每週可重複執行的系統。 AI 速報的幾篇，剛好也都在談這件事的不同側面：調度要簡單而不是複雜、組織層級本質上也是一種資訊路由、助理要真的記得你才能真的幫你。 研究者特報，則是我自己最近整理出來的「Router...
嗨，大家好。 上一期我跟大家分享了我們內部決定的管理架構：用 ISO 的骨架收納文件，用 BPM 的血液驅動工作，用 ACM 的精神管理專案。沒想到這個話題讓不少朋友起了共鳴，也有讀者特別寫信來問：「為什麼是 BPM？那句『把價值順利遞交給客戶』，到底是什麼意思？」 今天就用我們最近遇到的一個真實案例來回答這個問題。 最近我們的 AI 論文輔助事業正在規劃第二期（有興趣當朋友可以參考文後研究者特報，有我們計劃的消息），我發現有一篇文章陷入了一個「三不管地帶」——它同時是內容產製（知識中心的職責）、招生行銷工具（總經理室負責），而原始素材卻存在課程設計的資料庫裡。三個邊界，沒有一個地方是它的「正式歸宿」。 這種感覺你一定不陌生：明明事情要做，但就是不知道放哪裡、誰來主責、要不要現在建立一套流程。 後來解開這個結的，是我們之前在流程文件裡寫的一句話：「規模有限、還沒正式切割的責任範圍，先用身兼方式處理。」 這句話的背後，正是 BPM 最核心的哲學：消除浪費，只標準化值得標準化的事。 BPM...