AI 工程實務 - Kerwin AI Information

如果哪天你打開 Slack，發現新加入的同事叫「ActionNex」，職稱寫著 Oncall Outage Manager（雲端故障值班經理），你大概不會意外——但真正驚訝的，是這位「同事」其實是個 AI Agent。

這不是科幻，也是現在進行式。

這一波 Agent 熱潮，真正有趣的變化不是「模型又變多強」，而是它開始在各個領域變成一個具體的專職角色：

在微軟 Azure，它是負責雲端停機調度的虛擬值班經理（ActionNex）
在科研實驗室，它幫科學代理整理、鍛造會自己長大的技能庫（SkillFoundry）
在程式課教室，它是老師身邊的出題助教（CODE-GEN）

這篇文想聊的不是「又有幾篇新論文」，而是：

Agent 落地時，真正重要的設計點，其實不是「模型多大、多強」，而是：
1. 怎麼設計技能庫
2. 怎麼設計工作流
3. 怎麼設計人類在回圈中的協作

我們會拆三個案例，順便帶到兩個很關鍵的底層技術：Profile-Then-Reason（PTR） 和 Combee，來看 Agent 要怎麼變得更穩、更會學。

一個共通現象：Agent 在團隊裡，開始有「職稱」了

先抓一個大方向：

以前我們講 LLM，多半把它當「加強版 ChatGPT」——一個很聰明的通用助手。

但這幾個系統有個共同點：

它們不是「萬事通」，而是清楚限定職責的角色
它們都有專用的工具與技能庫
它們都有固定的工作流程（workflow）
它們都有穩定運作的記憶系統
而且都強調 human-in-the-loop（人類在回圈中）

換句話說，真正落地的 Agent，比較像是：

「你團隊裡多了幾位非常認真、永遠 oncall、不會累的專職同事。」

接下來就來看這三位「新同事」各自長什麼樣子。

案例一：ActionNex —— 微軟 Azure 的雲端故障「虛擬指揮官」

情境想像一下：

凌晨三點，某區域的 Azure 服務掛了。平常流程：

值班工程師被叫醒
開會、看 dashboard、翻 playbook
瘋狂在 Teams 上 ping 各團隊
邊排查邊對外更新狀態

這種跨團隊、資訊不完整、高壓的情境，過去完全靠人撐著。

微軟在 ActionNex 論文裡做的事情是：

把這整個「停機事件管理」流程，交給一個 專職 Agent 當指揮官。

ActionNex 怎麼工作？

它接收的資訊其實非常雜：

停機事件內容（Ticket、公告）
遙測資料（各種監控指標）
人類在 Teams / Email 裡的對話

第一步，它會做一件很重要的事：

把一堆雜訊壓縮成一串「關鍵事件」（critical events）

有點像是：

從「聊天紀錄 + log + 報表」
自動剪輯成一條事件時間線：「01:32 服務 A 延遲飆升 → 01:37 DB 重啟失敗 → 01:40 客戶大量 Time-out」

接著它會用一套分層記憶系統來推理下一步該做什麼。

三層記憶：讓 Agent 像資深值班工程師一樣「有歷史感」

ActionNex 把記憶分成三種：

KCA 知識庫（Key-Condition-Action）
從歷史 playbook 萃取：
關鍵條件（Condition）：例如「延遲 > 200ms 且錯誤率 > 5%」
對應動作（Action）：例如「先 rollback 上一版」「切到備援區域」
這有點像整個團隊的「作戰 SOP」被結構化塞進 Agent 裡。
情境記憶（Past outage memories）
過去每一次停機的「故事版」：發生什麼、怎麼處理、結果如何。
工作記憶（Working memory）
這次事件當下的進度：已做哪些操作、各團隊目前狀態。

推理代理會把當前的關鍵事件，拿去跟這些記憶對照：

找出「長得很像的歷史事件」
套用對應的 KCA 規則
給出「下一步該做什麼」的建議

最重要的：人機協作，而不是全自動

ActionNex 不是來「接管」值班，而是變成：

為每個角色（不同團隊）
在不同階段（初始 triage、調查、修復、收尾）
給出角色與階段條件化（role- and stage-conditioned） 的建議

而且每一次人類的接受 / 拒絕 / 更改行動，

都會回寫成新的資料，讓系統持續「學會更像這個組織真正的作法」。

簡單講，它就是個永遠在場、會記住每一次事故教訓的「虛擬 oncall 指揮官」。

實測成效：不只是 demo，是真的上線用

這篇論文最關鍵的一段是：

在 8 次真實 Azure 停機案例 中測試
下一步行動建議的：
精確率約 71.4%
召回率約 53–55%

換句話說：

它給的「可用建議」不少，而且品質不差
又因為有值班工程師在回圈裡，不會傻傻地完全照做

對營運團隊來說，這不是「AI 會不會取代我」的題目，而是：

「我多了一個懂歷史、熟 SOP、24 小時在線的值班副手。」

案例二：SkillFoundry —— 幫科研 Agent 打造會自己長大的技能庫

第二個案例走進研究室。

現在很多實驗室都在做「科學代理」：

幫忙寫分析程式
跑生物資訊 pipeline
讀 paper、查資料

但現實問題是——科研世界的「知識」非常碎：

GitHub repo 裡的腳本
API 文件
Lab wiki、Notebook
Database 查詢
方法論寫在論文裡

對 Agent 來說，這些都像一堆散落各地的「技能零件」，

會寫 Python ≠ 會跑你實驗室那套 pipeline。

SkillFoundry 做的事情，就是：

把這些 heterogeneous 資源，鍛造成「可以直接拿來用的技能包」，而且會自我演進。

什麼是「技能包」？

在 SkillFoundry 裡，每個 skill 不是一句 prompt，而是一個完整的「模組」：

包含：

任務範圍（這技能用來幹嘛）
輸入／輸出格式
執行步驟（step-by-step 程序）
環境假設（需要哪些環境 / 資料）
來源（來自哪個 repo / 文件 / 論文）
測試（怎樣算成功）

很像你在寫一個「可重用的工具」，不是臨時寫一段 code 貼上就算。

SkillFoundry 的核心流程：

可以想像成四步：

建立領域知識樹（Domain Knowledge Tree）
把目標領域（例如基因組學）拆成一棵樹：
節點可能是：資料前處理 → 比對 → 變異檢測 → 下游分析
從高價值分支挖資源
從 repo / API / 文件 / 論文中抓出相關程式與描述
用 LLM 幫忙抽取出「這個操作到底在做什麼」
轉成技能包 + 測試
把操作流程寫成結構化 skill
自動或半自動生成測試案例
閉環驗證 + 自我演進
讓代理實際用這些 skill 去解 benchmark / 真實任務
觀察：
- 哪些技能常用？
- 哪些技能常出錯？
依狀況進行：擴展／修復／合併／刪減

這個「挖 → 寫成 skill → 用 → 回饋 → 精煉」的迴圈，就是它的「自我演進」。

結果：不是在堆技能，而是真的變強

幾個有意思的數字：

SkillFoundry 產生的技能庫，跟現有的 SkillHub / SkillSMP 比，
70% 以上的技能是新的（不是抄舊東西）
把這些技能接上現有 coding agent：
在多個科學基準上表現有明顯提升
對像基因組學這種比較硬的任務，提升特別明顯

更關鍵的是：

你可以針對某個具體任務，按需設計一批技能，而不是丟給模型自己猜要怎麼做。

從產品角度來看，這個訊號非常清楚：

真正厲害的科學 Agent，不只是「模型懂很多生物學」
而是它有一套針對領域打造的技能庫 + 驗證機制

如果你在做 B2B / 垂直領域產品，這其實就是：

「先把你的 domain SOP 結構化成一個會自己長大的技能庫。」

案例三：CODE-GEN —— 程式課老師的 AI 出題助教

第三個案例走進教室。

程式課老師大概都懂這個痛點：

要為不同程度的學生出足夠多、夠有品質的題目
題目要對齊課程目標（不是隨便考）
還要兼顧：清晰度、合理難度、沒有語病、程式碼要能跑…

CODE-GEN 做的是：

用一個 Human-in-the-loop 的 RAG Agent 系統，當老師的「出題助教」。

兩個 Agent：出題者 + 驗題者

整個系統拆成兩個角色：

Generator（出題代理）
讀課程內容、學習目標（透過 RAG 把相關教材餵給模型）
產生多選題：題幹、選項、正解、解析
Validator（驗證代理）
獨立地、用另一套流程檢查題目
檢查七個教學維度，例如：
- 題目是否清晰
- 程式碼是否可執行、沒有 bug
- 概念是否對齊課程目標
- 正確答案是否合理

兩個 Agent 都配了一些專用工具：

用來實際跑程式碼
驗證輸出
做精確計算

所以這不是「LLM 靠感覺出題」，而是：

LLM + 工具 + 另一個 LLM 當審稿編輯。

人類在回圈：老師還是最後的權威

CODE-GEN 強調的是 Human-in-the-loop：

研究找了 6 位領域專家（程式教師）
對 288 題 AI 生成題目做評估
得到 2016 組人機共同評分數據

在可被人類直接檢查的維度（清晰度、程式碼有效性、概念對齊、答案合理性）上：

成功率在 79.9% – 98.6% 之間

但研究也坦白說：

有一些「比較微妙」的教學品質問題
例如題目的「教育價值」「是否真的能引導學生思考」
還是需要人類專業來判斷

我覺得這是很健康的設計哲學：

AI 幫你「大量產出高水準草稿」，
老師主導「最後把關與精修」。

對任何內容產品團隊也一樣：

不要期待 Agent「全自動產出完美內容」
要把它當成高效率內容工廠 + 嚴謹的 QA 流程

底層技術：要讓 Agent 穩、快、會學，靠什麼？

看完三個落地案例，你會發現一個 pattern：

都是多步驟流程
都要跟工具互動
都要反覆執行很多次

這種情境下，兩個瓶頸很常見：

Agent 推理流程太長 → 延遲爆炸、錯誤累積
想讓 Agent 自我提升 → 學得太慢或學壞

這時候，兩篇研究上場：Profile-Then-Reason（PTR） 和 Combee。

Profile-Then-Reason（PTR）：先寫流程，再執行

一般常見的 Agent 模式（像 ReAct）是：

想一步，call 一次工具；看結果，再想下一步。

問題是：

工具多 → LLM 每一小步都要重新推理
跑久了延遲很高，而且很容易一錯再錯、錯誤累積

PTR 論文提出一種不一樣的做法：

Profile-Then-Reason：先用模型「把整個工作流程寫出來」，再用比較穩的運算子去執行這個流程。

大致流程：

Profile（定義流程）：
LLM 看任務與可用工具
一口氣設計出一個 explicit workflow（像寫一個簡化版 pipeline）
Execution（執行）：
由 deterministic 或 guarded operator 來跑這個 workflow
這一步不再狂 call LLM，而是照規劃一步步執行
Verification（驗證）：
有一個 verifier 來檢查整個 trace 合不合理
Repair / Re-Reason（修正）（只有必要才做）
若 verifier 發現流程不可靠，才再叫 LLM 來調整流程

核心 idea 是：

「盡量把『思考成本』集中在一兩次，再用穩定的程式化執行接手。」

實驗結果：

在 6 個 benchmark、4 個不同模型上測試
PTR 的精確匹配率普遍優於 ReAct
模型呼叫次數也被嚴格限制在 2–3 次 左右

尤其在：

以檢索為主（RAG-heavy）
任務拆解很多階段

這種情境，PTR 特別吃香。

對產品設計來說，這個訊息很直接：

真正複雜的工作流，不要用「一直問模型下一步要幹嘛」來跑，而是讓模型先設計流程，再讓系統執行。

Combee：讓一大群 Agent 的經驗變成可用的「系統提示升級」

第二個問題是：

「我們收了一堆 Agent 執行軌跡，怎麼讓它們真的變成 Agent 變強的養分？」

過去像 ACE、GEPA 這類 prompt learning 方法，可以從歷史任務中學出更好的 system prompt，但多半：

針對單一 Agent 或小量並行
當你想一次學很多 trace，就會：
要嘛變超慢
要嘛品質崩掉

Combee 的出發點是：

我們需要一個可以「高並行學 prompt」的框架，才配得上現在一堆大規模 Agent 執行軌跡。

它的做法可以簡化理解為三個關鍵機制：

平行掃描（Parallel scan）
把大量軌跡拆開，在多個 worker 上同時做提示學習
增強隨機重排（Enhanced random reshuffling）
避免某些偏差樣本一直堆疊導致 prompt 學壞
動態批次控制（Dynamic batch size）
根據學習狀況調整 batch，兼顧穩定與速度

實驗上，在 AppWorld、Terminal-Bench、Formula、FiNER 等任務上：

相比之前方法，學習速度最高快 17 倍
準確度大致持平或更好
成本維持相近

這帶來一件很實際的想像：

未來你的產品如果有 10,000 個 Agent 在跑任務，它們的「軌跡」真的可以變成一種集體學習機制，而不是只拿來算 dashboard。

三個案例的一致設計：記憶、技能、驗證、人類在回圈

把 ActionNex、SkillFoundry、CODE-GEN 放在一起，你會看到一張很像的架構圖：

記憶系統（Memory）
ActionNex：KCA + 過往事故 + 當前工作記憶
SkillFoundry：領域知識樹 + 已驗證技能歷史
CODE-GEN：課程內容、過往題目與評分結果
技能庫（Tools / Skills）
ActionNex：操作手冊轉成 KCA；各種維運工具
SkillFoundry：每個帶測試的 skill module
CODE-GEN：程式執行、驗證工具 + RAG 工具
工作流程（Workflow / Orchestration）
有明確的階段：感知 → 推理 → 行動 → 回饋
PTR 類的技術則用來把這工作流更結構化、穩定化
驗證與自我修正（Verification & Self-Improvement）
ActionNex：人類值班人員的使用／拒絕行為
SkillFoundry：用 benchmark 與測試來修技能
CODE-GEN：Validator Agent + 老師評分
Combee 類技術：把這些軌跡學成更好的 prompt
Human-in-the-loop（人類在回圈中）
不只是「可選的審核」，而是：
- ActionNex：值班工程師 + 跨團隊溝通
- SkillFoundry：領域專家指導知識樹、審關鍵技能
- CODE-GEN：老師最後裁決題目品質

這裡面有一個很重要的觀點：

真正落地的 Agent 系統，設計重心往往不在「選哪個模型」，而在：

你怎麼整理你組織的知識（記憶）

你怎麼把流程拆成可重用的技能

你怎麼安排工作流與驗證點

你怎麼讓人類有自然的介面可以介入、修正、教它

如果你想在自家產品導入 Agent，應該先思考什麼？

把研究拉回產品實務，我會建議你先從這三個問題開始，而不是先問「要不要上 GPT-4.1 還是別的？」

1. 你想讓 Agent 當什麼「專職角色」？

不要一開始就說：「我要一個 AI 助手。」

改問：

在你的業務裡，有沒有：
雜事多、流程固定
但又需要一定專業判斷的角色？

例如：

客服團隊裡的「初步 triage 專員」
SRE 團隊裡的「值班副手」（像 ActionNex）
研究團隊裡的「腳本整理小幫手」（像 SkillFoundry）
教育團隊裡的「出題助教」（像 CODE-GEN）

給它一個清楚的職稱和職責範圍，

你比較有機會設計出真的能上線用的 Agent，而不是玩具 demo。

2. 你的「技能庫」要怎麼長出來？

機器不懂你公司到底怎麼做事。

你需要回答：

你們現在的 SOP 放在哪？（文件、Notion、Wiki、內部工具？）
哪些操作可以拆成「技能」？
每個技能：輸入是什麼、輸出是什麼、怎樣算成功？
有沒有測試機制可以驗證技能沒壞？

可以借鏡 SkillFoundry 的心法：

先畫一棵「業務知識樹」
選幾個高價值分支去做 POC
用半自動方式把 SOP 轉成技能，儘量帶上測試與環境假設

3. 你要怎麼把人類放進回圈？

這點在三個案例裡都被反覆強調：

沒有人類在回圈的 Agent，很難安全地上產線

你可以設計：

哪些階段一定要人類確認？
例如：
- 發布外部公告前
- 修改關鍵設定前
- 上線前最後一版題目
人類的操作會不會被記錄、回饋？
接受 / 拒絕 / 修改 Agent 建議
能不能作為未來 prompt / 技能優化的資料

這裡就呼應 Combee 的價值：

如果你能把大量的「人類如何修正 Agent」軌跡存下來，未來可以用高並行的 prompt learning 框架，把整體系統悄悄調得越來越好。

結語：先設計角色與流程，再談模型

ActionNex、SkillFoundry、CODE-GEN、PTR、Combee 這幾篇研究，對我來說共同在傳遞一件事：

Agent 不再只是「一個更聰明的大模型」，而是「被放進組織裡，負責特定工作的專職角色」。

而當它變成「同事」之後，你最需要思考的其實是那些很「工程」也很「管理」的問題：

你要給它什麼職稱和職責？
它的技能從哪裡來，怎麼維護？
它的工作流長什麼樣？
它怎麼跟人類同事協作、被教會？

模型當然重要，但更像是：

一個很會學習、很會表達、很會寫 code 的「大腦」，
真正決定它能不能上線成為團隊一員的，是你給它的 記憶、技能、流程與人際關係（human-in-the-loop）設計。

如果你正準備在產品裡導入 Agent，可以試著先畫一張圖：

中間寫上那個你想要的「AI 職稱」
左邊列出它需要什麼技能（對應到工具 / API / SOP）
右邊畫出它每天的工作流程（哪裡要人類確認）
下方想想：它今天做錯了，你要怎麼讓它明天變得更好？

當這張圖足夠清楚，選用哪個模型，反而是一個比較好解的工程問題了。

標籤: AI 工程實務

AI Agent 正在變成各行各業的「專職角色」：從雲端故障指揮官到教育出題機的三個實戰案例