標籤: AI Agent

  • Hippo 記憶:讓本機 AI Agent 真正記住你

    📌 本文重點

    • Hippo 讓 AI Agent 具備結構化長期記憶
    • 不只用向量搜索,而是多維度記憶召回
    • 可直接接入 LangChain / LangGraph 現有架構

    如果你受夠了每次開新對話 AI 就失憶,Hippo 是一個專門幫 AI Agent 建長期記憶結構 的開源工具,讓模型可以跨對話記住你、記住專案、記住世界觀。

    專案連結:https://github.com/kitfunso/hippo-memory


    核心功能:它跟「塞進向量資料庫」有什麼不一樣?

    1. 生物啟發的記憶結構:不是只靠 embedding 搜索

    一般「加記憶」做法:

    • 把所有對話 / 文件轉成向量,丟進向量資料庫
    • 查詢時用 embedding 相似度召回

    這樣會遇到:

    • 記憶越多越慢
    • 容易抓到語意相似但情境不對的內容
    • 很難做「時間感」與「重要程度」的區分

    Hippo 的做法更像大腦海馬迴:

    • 把記憶拆成多種型態(事件、事實、偏好、任務等)
    • 每種記憶有自己的欄位:時間戳、重要性、來源、關聯 id
    • 召回時不只看相似度,還會考慮:
    • 時間距離(最近 / 很久以前但被多次提及)
    • 重要性(例如「明天要開會」權重更高)
    • 記憶種類(對話中問的是偏好,就優先找偏好類)

    💡 關鍵: Hippo 透過「記憶類型 + 時間 + 重要性」多維度過濾與排序,比單靠 embedding 更接近人類大腦的記憶方式。

    你可以採取的行動

    • 在設計 Agent 時,把「要記住什麼」先分類(例:使用者設定、長期專案狀態、一次性任務)
    • 對應到 Hippo 的不同記憶類型,而不是全部塞進單一向量庫

    2. 高效寫入 / 召回:不是每一句話都存

    Hippo 會讓 LLM 幫忙「過濾」哪些內容要進長期記憶:

    • 每輪對話結束時,呼叫一次 LLM:
    • 請它輸出:要存什麼?是什麼類型?重要性幾分?
    • 只有被標註為「值得記住」的內容才寫入記憶庫

    召回時則是:

    • 先根據 當前任務類型 過濾可疑記憶(例如問「專案」時,優先專案類)
    • 再用 embedding + 時間 + 重要性加權排序

    效果:

    • 記憶庫不會無限膨脹
    • 查詢時間穩定,對話變長也不會暴漲

    💡 關鍵: 透過 LLM 篩選與加權排序,Hippo 在長期對話下仍能維持穩定的查詢速度與記憶品質。

    你可以採取的行動

    • 在對話 loop 中加入一個 summarize_and_store_memory() 步驟
    • 規劃一份提示詞,教 LLM:什麼東西需要記住(例如使用者偏好、長期任務)

    3. 可以直接當「記憶模組」接到 LangChain / LangGraph

    Hippo 把核心封裝成一個獨立記憶層:

    • 暴露簡單的 API:add_memory(), retrieve_memories(), summarize_dialogue()
    • 你可以把它包成一個自訂的 LangChain Memory 類或 LangGraph node

    這代表你不必改整個 Agent 架構,只要:

    • 把原本「向量記憶」的那一層換成 Hippo
    • Prompt 裡多餵一段:{relevant_memories}

    你可以採取的行動

    • 先用 Hippo 做一個獨立小腳本,確定記憶寫入 / 召回正常
    • 再把它接進現有的 LangChain / LangGraph 專案

    適合誰用?三種具體場景

    1. 客服 / 助理型 Agent:跨對話記住使用者

    問題:

    • 今天跟你聊過喜好,明天又得重講一次

    用 Hippo 可以:

    • 把「使用者個人偏好」「公司規則」「歷史問題」分成不同記憶類型
    • 在每次新對話開始前,先用使用者 id 去 retrieve_memories()

    具體做法:

    • 每個 user 綁一個 user_memory_store
    • 首輪對話後,寫入:
    • 常用產品 / 方案
    • 語氣偏好(喜歡簡短回答、或喜歡詳細教學)
    • 下次對話開頭,在系統 prompt 裡加:
    • 你已知這個使用者的偏好:...

    2. 工具型 Agent:追蹤專案長期狀態

    像是:

    • 本機程式碼助手
    • 專案管理 / 自動化腳本編排 Agent

    用 Hippo 可以把:

    • 已完成的任務
    • 未完成的 TODO
    • 決策理由(為什麼選 A 而不是 B)

    長期存起來,讓 Agent 未來做決策時可以「回頭想」,而不是只看當前 prompt。

    具體做法:

    • 每次工具成功執行後,寫入:操作內容、輸入、輸出、錯誤紀錄
    • 下次 Agent 在決定要不要呼叫同個工具時,先查過去的失敗 / 成功案例

    💡 關鍵: 對工具型 Agent 來說,持續累積「決策與結果」記憶,可以大幅降低重複犯錯與無效操作。

    3. 遊戲 / 模擬:角色人格與世界觀持久化

    如果你在做:

    • 文字冒險遊戲中的 NPC
    • 模擬城市 / 社會裡的多 Agent 系統

    Hippo 可以:

    • 把 NPC 的「人生事件」「人際關係」「信念」拆成不同記憶
    • 讓同一個角色在不同局遊戲中保有成長、偏好

    具體做法:

    • 每次玩家與 NPC 互動後,將關鍵事件寫入該 NPC 的記憶庫
    • 下次載入遊戲時,先載入角色記憶,再生成回應

    怎麼開始:本機跑一個有長期記憶的 Agent

    下面示範:在本機用一個輕量開源 LLM + Hippo 跑出一個最小可用的長期記憶 Agent。

    1. 安裝依賴(Python)

    假設你有 Python 3.10+,先開一個虛擬環境:

    python -m venv venv
    source venv/bin/activate  # Windows 用 venv\Scripts\activate
    
    pip install hippo-memory
    pip install transformers accelerate sentence-transformers
    

    如果你想用 Ollama / 本機模型,也可以只要 HTTP API,把 llm_call() 改成呼叫本地端服務即可。

    2. 建一個最小記憶介面

    概念流程:

    1. 使用者說話
    2. Agent 回應(用 LLM)
    3. 用 LLM 檢查這輪對話有沒有值得記住的東西
    4. 需要記住的就丟給 Hippo
    5. 下一輪對話前,從 Hippo 取出相關記憶加進 prompt

    簡化版範例(偽代碼結構):

    from hippo_memory import HippoMemory
    
    memory = HippoMemory()
    
    def llm_call(prompt: str) -> str:
        # TODO: 換成你實際使用的本機 LLM(Ollama / vLLM / transformers)
        ...
    
    
    def summarize_for_memory(dialogue: str) -> list[dict]:
        """讓 LLM 決定要存哪些記憶,回傳 list[{"type":..., "content":..., "importance":...}]"""
        prompt = f"""
    你是記憶管理員。以下是剛剛的一段對話:
    {dialogue}
    
    請列出值得長期記住的事情(使用者偏好、長期目標、重要事件)。
    用 JSON 陣列輸出,每個元素包含 type, content, importance(1-5)。
    如果沒有,回傳 []。
    """
        import json
        res = llm_call(prompt)
        return json.loads(res)
    
    
    def add_dialogue_to_memory(history: list[tuple[str, str]]):
        # history = [(user_msg, assistant_msg), ...]
        text = "\n".join([f"User: {u}\nAssistant: {a}" for u, a in history[-3:]])
        items = summarize_for_memory(text)
        for item in items:
            memory.add_memory(
                mem_type=item["type"],
                content=item["content"],
                importance=item.get("importance", 3),
            )
    
    
    def chat_loop():
        history = []
        while True:
            user = input("你:")
            if user.strip().lower() in {"exit", "quit"}:
                break
    
            # 1) 先查記憶
            relevant = memory.retrieve_memories(query=user, top_k=5)
            memory_text = "\n".join([f"- {m.content}" for m in relevant])
    
            # 2) 組 prompt
            prompt = f"""你是一個會記住使用者的助理。
    以下是你對這位使用者的已知記憶:
    {memory_text or '(目前沒有特別記憶)'}
    
    現在的對話:
    使用者:{user}
    請根據記憶與對話回應。
    """
            assistant = llm_call(prompt)
            print("Agent:", assistant)
    
            history.append((user, assistant))
            add_dialogue_to_memory(history)
    
    
    if __name__ == "__main__":
        chat_loop()
    

    你可以採取的行動

    • 把上面程式框架複製到自己的專案
    • llm_call() 替換成你現用的 LLM(如 Ollama 的 /api/chat
    • 用幾輪「自我介紹 → 問之前說過什麼」來測試記憶效果

    3. 接到 LangChain / LangGraph 的 memory 模組

    如果你已經在用這些框架,可以這樣思考:

    • LangChain:
    • 寫一個 HippoMemoryWrapper,實作 load_memory_variables + save_context
    • 內部直接呼叫 HippoMemory.add_memory() / retrieve_memories()
    • LangGraph:
    • 把 Hippo 抽成一個 node:「更新記憶」與「擷取記憶」
    • 在主對話 graph 中,讓每輪都經過這兩個 node

    這樣你不用推翻原有設計,只是把記憶 backend 換成更聰明的 Hippo。


    小結:什麼時候值得上 Hippo?

    你可以用一個簡單判斷:

    • 只做「單次任務、一次對話就結束」的 Agent → 一般向量資料庫就夠
    • 需要「跨天、跨專案、角色長期成長」的 Agent → 值得導入 Hippo 記憶

    先從一個很小的場景開始:例如讓你的本機助理 記住你的個人偏好。當你發現它真的記得你說過的事,再把同樣的記憶結構,複製到客服、專案管理或遊戲 NPC 上。

    專案原始碼與設計細節: https://github.com/kitfunso/hippo-memory

    🚀 你現在可以做的事

    • 打開專案頁面,閱讀 Hippo 的 README 與範例程式碼:https://github.com/kitfunso/hippo-memory
    • 在本機建立一個小腳本,實作文中 llm_call() 並跑起示範的記憶型 Agent
    • 將 Hippo 接入你現有的 LangChain / LangGraph 專案,先讓一個特定 user 或 NPC 擁有長期記憶
  • Deep Researcher Agent:幫你 7×24 小時跑深度學習實驗

    📌 本文重點

    • 讓 Agent 自動從開題到調參跑完整實驗流程
    • 透過雙層記憶與精簡工具控制 token 與成本
    • 實測可連跑 30+ 天、500+ 次實驗且指標提升 52%

    Deep Researcher Agent 不是寫論文工具,而是幫你自動設計、啟動、監控、調整深度學習實驗的「實驗室助理」,讓你晚上開好一個任務,隔天早上直接看總結與下一步建議。

    原文與程式碼: arXiv: Deep Researcher Agent


    核心功能:把「開題到調參」變成自動流程

    1. 零成本監控:只讀日誌與進程,不再瘋狂 call API

    多數「AI 助手監控訓練」的做法是:每隔幾分鐘就丟當前 log / loss 給 LLM 解讀,API 費用跟著訓練時間線性上升。Deep Researcher Agent 直接反其道而行:

    做法

    • 不在訓練中途問 LLM
    • 只用本機腳本:
    • 檢查訓練進程(還活著嗎?GPU 滿不滿?)
    • 讀 log 檔 / checkpoint 資訊
    • 訓練跑完後,才把「摘要後的訓練結果」送給 LLM 分析

    結果

    • 一個專案可以連續跑 30+ 天、500+ 次實驗,LLM 每日成本約 0.08 美元
    • 你可以安心開長實驗,不用擔心「監控本身」把錢燒光

    💡 關鍵: 把 LLM 使用集中在「訓練後一次分析」,可以在連跑 500+ 次實驗的情況下,將每日成本壓到約 0.08 美元。

    你可以立刻做的事

    • 檢查你現有的訓練流程,是否一定要「在線可視化」?
    • 如果只是每天看一次結果,Deep Researcher Agent 的這種「訓練中不問 LLM,訓練後一次分析」就非常適合。
    • 思考:你現在哪些監控行為其實可以改成「訓練後解析 log」,先在自己腳本裡做一次簡單實驗。

    2. 雙層記憶 + 精簡工具:防止 context 爆炸、token 費用受控

    讓一個 Agent 連續工作幾天,最常見的問題就是:

    • 每次對話都把所有歷史實驗貼進去
    • context 越來越長,token 費用越來越高,最後不是超長就是被截斷

    Deep Researcher Agent 用兩個設計解決:

    雙層固定大小記憶(Two-Tier Memory)

    • 短期記憶(Working Memory)
    • 只放當前 1~數個實驗的細節(超參、log 摘要、錯誤訊息)
    • 控制在約 5K 字元級別,方便每次對話完整送進 LLM
    • 長期記憶(Research Memory)
    • 只存「實驗結論」與「調參心得」,像是研究筆記
    • 例如:
      • 「batch size > 64 容易 OOM」
      • 「加入 label smoothing,val F1 提升約 3%」
    • 每次對話只抽取跟當前主題最相關的幾條結論給 LLM

    效果

    • 跑到第 300 次實驗時,Agent 不會忘記前面學到的規則
    • 同時每次 LLM 呼叫的 context 仍保持在可控長度

    💡 關鍵: 透過短期與長期記憶拆分,即使到第 300 次實驗仍能保留前面經驗,同時維持每次對話在可控 token 範圍。

    精簡工具集(Master-Worker 工具設計)

    Deep Researcher Agent 不是給 Agent 一大堆雜亂工具,而是用「主代理 + 工人工具」的拆分方式:

    • 主代理(Research Agent):負責思考研究方向與高層決策
    • 工具極少:像是「列出已完成實驗」「建立新實驗配置」「讀取實驗結果」
    • 工作腳本(Workers):真正執行訓練的 Python / shell 指令
    • 不需要 LLM 介入,只在啟動時決定指令與參數

    你可以立刻做的事

    • 列出你現在所有給 LLM 能呼叫的「工具」或指令,分成:
    • 必須由 LLM 決策的(例如:如何改超參)
    • 完全可以由固定腳本處理的(例如:啟動訓練、sync log)
    • 把第二類先抽出去,用單純腳本運行,減少 LLM 每次對話要「理解的東西」。

    3. 實際成效:30+ 天、500+ 次實驗,指標提升 52%

    論文中給了一個具體部署紀錄:

    • 同時跑 4 個研究專案
    • 連續運作超過 30 天
    • 累積超過 500 次實驗迭代
    • 其中一個專案的核心指標(文中稱 meta-metric)提升 52%
    • 每天 LLM 成本約 0.08 美元

    💡 關鍵: 在連續 30+ 天、500+ 次迭代中,單一專案 meta-metric 能提升 52%,顯示自動實驗迭代對指標有明顯放大效果。

    背後做的事包括:

    1. 自己提出假設(例如:換 optimizer / lr schedule)
    2. 自動改訓練腳本或 config
    3. 啟動新一輪訓練
    4. 訓練結束後讀取 log,分析哪裡變好或變壞
    5. 寫成研究筆記,決定下一輪調整

    你可以立刻做的事

    • 選一個你目前「還在摸索怎麼調參」的專案(例如:分類模型 F1 卡在 0.7)
    • 想像:如果可以一週內自動跑 100 次變體,你會想讓 Agent 幫你嘗試哪些方向?
    • 先寫下三個:例如 optimizer、資料增強、模型寬度/深度
    • 等下在「怎麼開始」段落,我會示範怎麼把這些需求塞進 Agent。

    適合誰用?三種典型場景

    1. 個人研究者:晚上丟任務,早上看實驗日誌

    情境:你在做論文或 side project,每天能盯 terminal 的時間有限,但有 GPU 資源。

    你可以這樣用:

    • 晚上:
    • 給 Deep Researcher Agent 一個初始實驗設定(Model A + Dataset X)
    • 勾勒你允許它調整的範圍(例如 lr、batch size、增強策略)
    • 隔天早上:
    • 看 Agent 整理的:
      • 已跑過的實驗表格
      • 每一類調整的效果摘要
      • 下一步建議(例如「接下來專注調整 learning rate decay」)

    2. Startup ML 團隊:小團隊也能跑「持續自動調參」

    情境:公司只有 1–3 個 ML 工程師,但有幾台 GPU,要在短期內打磨一個核心模型(推薦、排序、廣告 CTR 等)。

    你可以這樣用:

    • 把既有的 PyTorch / Hugging Face 訓練腳本接入 Deep Researcher Agent
    • 讓 Agent 針對特定線上指標(例如 AUC / NDCG)做持續探索
    • 團隊成員每天只需要花 30 分鐘看報告與決定是否採用 Agent 建議的設定

    3. 公司內部模型調參:封裝成本、控管風險

    情境:你是公司內部「那個會調參的人」,大家都找你幫忙加一點準確度,但手工改 config 太耗時間。

    你可以這樣用:

    • 把公司的標準訓練 pipeline(包含資料路徑、監控、部署步驟)封裝成一個「Agent 可叫的 Worker」
    • 為每個專案設一個 sandbox:
    • 限制 Agent 只能用某些 GPU、只能改某些超參
    • 其他同事只要:
    • 把資料與 baseline config 準備好
    • 按一次「啟動自動調參」,等報告

    怎麼開始:最小可用 Workflow

    以下以「你已有一個 PyTorch / Hugging Face 訓練腳本」為前提,示範最快上手方式。實作細節可對照論文附檔與 GitHub(論文頁面會附上連結)。

    步驟 0:準備環境與專案

    1. 準備一台能跑你模型的機器(本機或遠端,都可以):
    2. Python 3.10+、CUDA、PyTorch / Transformers 已能正常訓練
    3. 選一個專案當作試驗田:
    4. 例如 train.py 接受 --lr --batch_size --model_name 等參數

    步驟 1:Clone 專案、安裝依賴

    # 以假想 repo 名稱為例,實際請依論文提供的 GitHub
    git clone https://github.com/xxx/deep-researcher-agent.git
    cd deep-researcher-agent
    
    pip install -r requirements.txt
    

    接著,設定你的 LLM 金鑰(例如 OpenAI / Claude):

    export OPENAI_API_KEY=你的_API_KEY
    # 或依 repo 說明設定其他模型供應商
    

    步驟 2:接上你現有的訓練腳本

    假設你原本的訓練指令是:

    python train.py \
      --model_name bert-base-chinese \
      --lr 2e-5 \
      --batch_size 32 \
      --output_dir runs/exp1
    

    你需要做兩件事:

    1. 定義一個 Worker 指令模板(讓 Agent 能替換超參):
    2. 在 Deep Researcher Agent 的設定檔(例如 config/experiments.yaml)中新增:

    yaml
    experiments:
    - name: text_classification_bert
    command_template: >-
    python /path/to/your/train.py
    --model_name {model_name}
    --lr {lr}
    --batch_size {batch_size}
    --output_dir {output_dir}
    search_space:
    model_name: ["bert-base-chinese", "hfl/chinese-roberta-wwm-ext"]
    lr: [1e-5, 2e-5, 3e-5]
    batch_size: [16, 32]

    1. 指定 log / metric 的位置與格式
    2. 讓 Agent 知道到哪裡讀結果,例如:

    yaml
    log_config:
    metric_file: "{output_dir}/metrics.json"
    target_metric: "f1"

    並確保你的 train.py 在訓練結束會輸出一個 metrics.json,內容類似:

    json
    {"f1": 0.73, "accuracy": 0.88}

    步驟 3:啟動一個最小實驗

    完成以上設定後,你可以啟動一個最小自動實驗循環,例如:

    python run_agent.py \
      --experiment text_classification_bert \
      --max_iterations 5
    

    這會做的事通常包括:

    1. Agent 讀取目前專案目標與 search space
    2. 設計第 1 個實驗配置,產生實際指令
    3. 啟動訓練進程,等待完成
    4. 讀取 metrics.json,寫入研究記憶
    5. 依照結果調整下一輪超參,直到跑完 max_iterations

    跑完後,你可以查看:

    • logs/ 目錄:每次實驗的設定、結果、分析
    • 研究摘要檔:看到 Agent 寫的「這幾次實驗學到了什麼」

    步驟 4:把它變成你的「夜間實驗助手」

    當你確認一輪流程跑得穩:

    1. max_iterations 調大,例如 50 或 100
    2. 使用排程或 tmux / screen,在下班前啟動一次 Agent
    3. 第二天早上:
    4. 開啟 Agent 產生的 summary(通常是 markdown / text)
    5. 根據它給的建議,決定:
      • 是否擴大 search space
      • 是否更換模型架構

    小結:先讓它代替你跑 5 次實驗就好

    Deep Researcher Agent 真正帶來的改變不是「多一個會寫程式的 ChatGPT」,而是:

    • 你不再需要手動複製貼上超參、啟動訓練、整理 log
    • 你可以把「實驗設計+結果分析」外包給一個成本極低、24 小時上班的助手

    建議你的第一步:

    1. 選一個已有訓練腳本的小專案
    2. 按上文接入 Deep Researcher Agent,只跑 5 次迭代
    3. 看看它整理出來的實驗表與建議,感受一下:「如果把這件事放大到 500 次實驗,對你現在的工作會有什麼幫助?」

    接著,你就可以考慮把公司或實驗室真正重要的專案,一個一個遷移進這套自動化實驗流程裡。

    🚀 你現在可以做的事

    • 檢查現有訓練腳本,先挑一個小專案依照文中的 experiments.yaml 範例接入 Deep Researcher Agent。
    • 實際跑一次 --max_iterations 5 的自動實驗循環,觀察 log、metrics 與 Agent 產出的研究摘要。
    • 根據初次結果,逐步擴大 search space 與 iterations,評估是否將公司或實驗室的核心專案遷移到這套流程。
  • AI Agent 正在變成各行各業的「專職角色」:從雲端故障指揮官到教育出題機的三個實戰案例

    如果哪天你打開 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 服務掛了。平常流程:

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

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

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

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

    ActionNex 怎麼工作?

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

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

    第一步,它會做一件很重要的事:

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

    有點像是:

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

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

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

    ActionNex 把記憶分成三種:

    1. KCA 知識庫(Key-Condition-Action)
      從歷史 playbook 萃取:
    2. 關鍵條件(Condition):例如「延遲 > 200ms 且錯誤率 > 5%」
    3. 對應動作(Action):例如「先 rollback 上一版」「切到備援區域」
      這有點像整個團隊的「作戰 SOP」被結構化塞進 Agent 裡。
    4. 情境記憶(Past outage memories)
      過去每一次停機的「故事版」:發生什麼、怎麼處理、結果如何。
    5. 工作記憶(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 的核心流程:

    可以想像成四步:

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

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

    結果:不是在堆技能,而是真的變強

    幾個有意思的數字:

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

    更關鍵的是:

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

    從產品角度來看,這個訊號非常清楚:

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

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

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


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

    第三個案例走進教室。

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

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

    CODE-GEN 做的是:

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

    兩個 Agent:出題者 + 驗題者

    整個系統拆成兩個角色:

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

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

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

    所以這不是「LLM 靠感覺出題」,而是:

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

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

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

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

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

    • 成功率在 79.9% – 98.6% 之間

    但研究也坦白說:

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

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

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

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

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

    底層技術:要讓 Agent 穩、快、會學,靠什麼?

    看完三個落地案例,你會發現一個 pattern:

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

    這種情境下,兩個瓶頸很常見:

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

    這時候,兩篇研究上場:Profile-Then-Reason(PTR)Combee

    Profile-Then-Reason(PTR):先寫流程,再執行

    一般常見的 Agent 模式(像 ReAct)是:

    想一步,call 一次工具;看結果,再想下一步。

    問題是:

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

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

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

    大致流程:

    1. Profile(定義流程)
    2. LLM 看任務與可用工具
    3. 一口氣設計出一個 explicit workflow(像寫一個簡化版 pipeline)
    4. Execution(執行)
    5. 由 deterministic 或 guarded operator 來跑這個 workflow
    6. 這一步不再狂 call LLM,而是照規劃一步步執行
    7. Verification(驗證)
    8. 有一個 verifier 來檢查整個 trace 合不合理
    9. Repair / Re-Reason(修正)(只有必要才做)
    10. 若 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 執行軌跡。

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

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

    實驗上,在 AppWorld、Terminal-Bench、Formula、FiNER 等任務上:

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

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

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


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

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

    1. 記憶系統(Memory)
    2. ActionNex:KCA + 過往事故 + 當前工作記憶
    3. SkillFoundry:領域知識樹 + 已驗證技能歷史
    4. CODE-GEN:課程內容、過往題目與評分結果
    5. 技能庫(Tools / Skills)
    6. ActionNex:操作手冊轉成 KCA;各種維運工具
    7. SkillFoundry:每個帶測試的 skill module
    8. CODE-GEN:程式執行、驗證工具 + RAG 工具
    9. 工作流程(Workflow / Orchestration)
    10. 有明確的階段:感知 → 推理 → 行動 → 回饋
    11. PTR 類的技術則用來把這工作流更結構化、穩定化
    12. 驗證與自我修正(Verification & Self-Improvement)
    13. ActionNex:人類值班人員的使用/拒絕行為
    14. SkillFoundry:用 benchmark 與測試來修技能
    15. CODE-GEN:Validator Agent + 老師評分
    16. Combee 類技術:把這些軌跡學成更好的 prompt
    17. Human-in-the-loop(人類在回圈中)
    18. 不只是「可選的審核」,而是:
      • 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,可以試著先畫一張圖:

    1. 中間寫上那個你想要的「AI 職稱」
    2. 左邊列出它需要什麼技能(對應到工具 / API / SOP)
    3. 右邊畫出它每天的工作流程(哪裡要人類確認)
    4. 下方想想:它今天做錯了,你要怎麼讓它明天變得更好?

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


    延伸閱讀

    • ActionNex: A Virtual Outage Manager for Cloud
      https://arxiv.org/abs/2604.03512
    • SkillFoundry: Building Self-Evolving Agent Skill Libraries from Heterogeneous Scientific Resources
      https://arxiv.org/abs/2604.03964
    • CODE-GEN: A Human-in-the-Loop RAG-Based Agentic AI System for Multiple-Choice Question Generation
      https://arxiv.org/abs/2604.03926
    • Profile-Then-Reason (PTR): Bounded Semantic Complexity for Tool-Augmented Language Agents
      https://arxiv.org/abs/2604.04131
    • Combee: Scaling Prompt Learning for Self-Improving Language Model Agents
      https://arxiv.org/abs/2604.04247