Kerwin AI Information

Blog

  • 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

  • AI 代理衝進預測市場：PolySwarm、TimeSeek，模型真的贏得過金融市場嗎？

    如果有一群 24 小時不睡覺的「AI 小操盤手」，幫你盯著預測市場、算機率、調倉、抓套利機會 —— 你會把錢交給它們嗎？

    現在不再是理論題，而是真的有人把這件事做出來了。

    這篇文想聊兩個很有意思、而且是實際拿真金白銀去試的研究：

    • PolySwarm：一個在去中心化預測市場上做交易、還會玩「延遲套利」的多代理 LLM 系統。
    • TimeSeek：一個用 Kalshi 真實市場，系統性量測十個前沿模型「預測能力隨時間衰退」的基準。

    最後，我會談談殘酷一點的問題：

    就算 AI 代理會寫 code、會查網路、會算機率，它們真的能穩定打敗市場、賺到超額報酬（alpha）嗎？

    還是，只是換了一種更炫炮的方式，去繳學費？

    一、PolySwarm：50 個 LLM 小操盤手組成的「AI 交易部門」

    PolySwarm 這篇論文的副標題，如果翻成白話，大概是：

    「我們用 50 個不同人格的 LLM，真的在去中心化預測市場上交易，還順便做延遲套利。」

    論文在 arXiv 上可以看到：PolySwarm: A Multi-Agent Large Language Model Framework for Prediction Market Trading and Latency Arbitrage

    1.1 先搞清楚：他們在玩什麼市場？

    PolySwarm主要鎖定的是像 Polymarket 這類去中心化預測市場。

    例如：

    • 「某候選人今年選舉勝出？」是 / 不是（Yes/No）
    • 「某支股票年底前會不會跌破某價位？」
    • 「某項政策會不會在某日期前通過？」

    每個市場其實就是一個二元期權：

    • 市場價格 0.64，可以解讀為「市場認為事件發生的機率是 64%」。
    • 如果你買「Yes」，最後事件發生，你拿到 1；不發生，你拿 0。

    PolySwarm 要做的，就是：

    1. 評估每個事件「發生的機率」。
    2. 看現在市場價格划不划算（有沒有錯價）。
    3. 按照風險控管規則下單，賺取預期正報酬。

    聽起來跟一般量化交易很像，但差別是：

    所有決策都是由一群 LLM 代理討論出來的。

    1.2 50 個 LLM 代理：不像量化團隊，更像一個 AI 版 Reddit 投票版

    PolySwarm 一次丟出 50 個不同 persona 的 LLM 代理，讓他們同時對同一個市場做預測。

    這些代理的差異可能包括：

    • 不同提示語（prompt）設計
    • 不同角色設定（保守派、激進派、數據派、新聞派…）
    • 不同工具使用方式（有的偏重歷史數據，有的偏重新聞、社交媒體）

    每個代理會輸出：

    • 對事件發生機率的估計（例如 0.73）
    • 自己的「信心程度」

    有點像你開了一個 Telegram 群組，裡面有 50 個超認真的 AI 網友，每人都會附帶：「我覺得有 73% 會發生，我蠻有把握，信心 8/10。」

    1.3 他們怎麼把 50 人意見聚合？Bayesian + 市場共識

    重點來了：多代理系統的精髓不是問一堆人，而是「怎麼聚合」這些意見。

    PolySwarm 用的是一種 信心加權的貝葉斯聚合，大致流程：

    1. 先把市場當作一個「先驗機率」
    2. 如果市場價格是 0.64，系統就先假設：目前「公共資訊」說機率 64%。
    3. 再把 50 個代理的估計視為「額外證據」
    4. 每個代理的概率 + 信心，進入貝葉斯框架，調整原本的 0.64。
    5. 信心高的代理，權重比較大
    6. 有點像一群人投票，但可信度高的人票比較重。

    最終得到一個 聚合後機率，例如：0.71。

    這個 0.71 會拿來和市場價格（0.64）比較：

    • 如果我們覺得機率 71%，但市場只賣 0.64，那就是一個「期望正值」的機會。

    1.4 用 Kelly 公式控制下注大小：AI 也要控風險

    大部分散戶在市場上死得很慘，有一大半原因不是方向錯，而是倉位管理爛。

    PolySwarm 很加分的一點是，他們沒有只「猜對方向」，還把風險控管公式搬進來，用的是：

    • 四分之一 Kelly（Quarter-Kelly）策略

    Kelly 公式是老牌賭徒＋量化交易都用過的一套東西，用來決定：

    在一個有正期望值的賭局裡，你應該壓資金的多少比例，才能在長期最大化資本成長，又不容易破產。

    簡化一下直覺：

    • 如果你認為「發生機率 70%，賠率也不錯」
    • Kelly 會給你一個建議比例，比如 20% 資金
    • PolySwarm 還再打 1/4，只下 5%，保守很多

    這類保守的 Kelly 變體，在實際交易界是有共識的：

    • 純 Kelly 太兇，很容易在短期波動下被打爆。
    • 四分之一 Kelly 是在「成長」跟「不破產」之間折衷。

    1.5 延遲套利：抓「市場 lag」賺無風險（或低風險）利潤

    PolySwarm 研究中最有趣的部分之一，是它們做的 Latency Arbitrage（延遲套利）：

    利用不同市場更新速度不一樣，去剪那幾秒鐘到幾十秒鐘的價差。

    具體是這樣玩的：

    1. 假設某事件，在一個中心化交易所（CEX） 有交易，例如某種衍生品或相關標的。
    2. CEX 的流動性比較好、參與者多，價格更新較快。
    3. 同一個事件，在 Polymarket 上的價格，可能更新比較慢。
    4. PolySwarm 用一個 對數常態模型，從 CEX 的價格推回「隱含機率」。
    5. 如果發現：
    6. CEX 隱含機率已經跳到 80%，
    7. 但 Polymarket 還停在 65%，
    8. 而這個差距超過手續費、滑點等成本，
    9. 就在那個短窗內直接下單套利。

    這種作法在傳統金融世界也有：

    • 高頻交易會盯著不同交易所的同一標的，利用更新延遲賺 tiny spreads。
    • 差別只是現在「判斷是否值得套利」的邏輯，是 AI 代理做的。

    1.6 用資訊論檢查「錯價」：KL、JS 散度登場

    PolySwarm 還加了一個有點 geek 的模組：市場資訊分析引擎，用的是：

    • KL 散度（Kullback–Leibler Divergence）
    • JS 散度（Jensen–Shannon Divergence）

    用在兩種情境：

    1. 跨市場效率低落
    2. 比如兩個高度相關的市場，理論上機率應該接近，結果價格差很大。
    3. 否定對市場（negation pairs）錯價
    4. 例如：「某候選人會不會當選？」Yes 市場價格是 0.7，No 市場應該要在 0.3 附近（扣掉費用）
    5. 如果兩者加起來 ≠ 1，就有明顯錯價。

    資訊論指標本質上就是在量一件事：

    「這兩個機率分布到底差多少？差到不合理嗎？」

    一旦判斷「差很多又不合理」，系統就會啟動交易策略，去吃這個錯價。

    1.7 實驗結果：多代理聚合 > 單一模型

    論文裡用 Brier 分數、對數損失、校準分析做評估，得到的核心結論：

    • 單一模型做預測的表現，的確不穩定。
    • 多代理 + Bayesian 聚合後的群體共識，整體上更穩、更準。

    換句話說，他們做出了一個「AI 版的 crowd wisdom」，而且在真實市場中跑得動。這件事本身就非常重要，因為：

    這不只是 LLM 回答問題，而是直接把模型的輸出，接上了金融市場的錢包。

    二、TimeSeek：模型的預測能力，會不會「變舊」「失效」？

    如果說 PolySwarm 是「把 AI 丟進真實市場，看它能不能賺錢」，

    那 TimeSeek 比較像是：「系統性地測量，這些 AI 預測者到底多久會變鈍。」

    論文連結在這裡：TimeSeek: Temporal Reliability of Agentic Forecasters

    2.1 實驗設計：10 個模型、150 個 Kalshi 合約、5 個時間點

    TimeSeek 的設定蠻嚴謹的：

    • 市場：美國 CFTC 監管的 Kalshi 二元期貨市場
    • 合約數：150 個不同市場（通膨、政治、天氣、宏觀數據等等）
    • 模型數：10 個前沿 LLM
    • 時間點：每個市場在生命週期的 5 個不同時間點做預測
    • 情境：每個預測又分成「有網頁檢索」vs「沒檢索」

    總計：

    • 150 市場 × 10 模型 × 5 時間點 × 2（有/無檢索） = 15,000 次預測

    這規模不算天文數字，但已經足夠得到一些有說服力的「時間向」結論。

    2.2 評估指標：Brier Skill Score 看誰比市場強

    他們主要用 Brier Skill Score（BriSS） 來衡量預測品質。

    簡單理解：

    • Brier 分數：
    • 介於 0~2，越小越好。
    • 例如：事件發生（=1），你預測 0.9，比你預測 0.6 要好。
    • Brier Skill Score：
    • 通常是「相對某個 baseline（例如市場價格）」的改進程度。

    • 0 代表你比 baseline 強，< 0 代表你拖後腿。

    TimeSeek 的重點就是在看：

    在不同時間點，模型的預測，到底比「市場價格」好多少？還是其實更爛？

    2.3 核心發現一：模型在「市場早期」與「高不確定」時期較有優勢

    結果蠻有趣，也某種程度符合直覺：

    • 市場剛開始、資訊還很分散的時候：
    • 模型的預測相對有競爭力，有時可以接近甚至略贏市場。
    • 市場接近結算、共識變得很強的時候：
    • 模型就比較常被市場「打臉」，表現明顯下降。

    可以把它想像成：

    • 剛開盤的時候，大家都在猜，資訊優勢還存在，模型有機會靠「廣泛檢索＋邏輯推理」抓到一些尚未體現在價格上的面向。
    • 但隨著時間過去，專業交易者＋內部資訊＋更多數據一路往市場裡灌，價格越來越凝聚，最後變成「你跟一群職業玩家在對賭」。

    在這個階段，要期望 LLM 穩定打敗市場，就有點不切實際了。

    2.4 核心發現二：檢索是好東西，但會「幫倒忙」的情況不算少

    TimeSeek 也測了「有檢索 vs 無檢索」兩種情境。

    結論：

    • 整體來說，加入網路檢索後：
    • 每個模型的 Brier Skill Score 都有提升。
    • 但如果把時間點拆細：
    • 約 12% 的「模型 × 時間點」組合裡，檢索反而讓表現變更差。

    這個結果非常值得金融圈、AI 應用圈都好好思考。

    因為我們太習慣一句話：

    「加檢索一定比較好。」

    但實務上至少有幾種「檢索幫倒忙」的場景：

    1. 檢索內容過時或誤導
    2. 舊新聞、錯資料在網路上一直都在。
    3. 模型對噪音過度自信
    4. LLM 很擅長把零碎資訊「拼一個很合理的故事」，但那故事可能建立在錯誤假設上。
    5. 真正有價值的資訊，在付費牆或專業報告裡，模型抓不到
    6. 這時候它就是在公開資訊池裡和大家一起瞎猜，反而權重過高。

    這呼應了一個殘酷現實：

    在已開放、已競爭的市場裡，「能被 LLM 找到的資訊」通常早就已經被價格內化。

    2.5 核心發現三：簡單的兩模型集成，比單模更穩，但還是「打不贏市場」

    TimeSeek 也試了簡單的 兩模型 ensemble：

    • 就是把兩個模型的預測做平均或簡單加權。

    結果：

    • 確實可以降低預測誤差，比單一模型穩一點。
    • 但整體來看，仍然無法全面超越市場本身。

    也就是說：

    到目前為止，「拿幾個前沿模型 ensemble 一下」還不構成穩定 alpha。

    這個結論對 PolySwarm、對所有「AI 交易代理」都很關鍵：

    • 多代理本身不是魔法，聚合品質、模型多樣性、資訊來源、風險管理，缺一不可。

    三、AI 交易代理的現實風險：幻覺、延遲、檢索、Alpha 幻象與監管

    看到這裡，如果你有一點量化或交易經驗，大概會開始懷疑：

    「這些 AI 代理系統，看起來很猛，但真的可以長期穩賺不賠？」

    我們來拆幾個比較實際、也有點殘酷的面向。

    3.1 幻覺：在金融裡，一次瞎掰就可以讓你爆倉

    LLM 的老毛病就是：看起來超有自信地亂講。

    在聊天機器人情境，這叫「幻覺」，最多是答錯題、讓使用者困惑；

    但在金融市場裡，幻覺會直接變成：

    • 採用錯誤數據
    • 理解錯新聞
    • 杜撰不存在的事件或來源
    • 然後下了一筆「看起來有理，其實完全錯誤」的交易。

    PolySwarm 有談到幻覺風險與校準分析，試圖用多代理共識與市場價格來緩解：

    • 如果某個代理的預測常常偏離實際結果，就降低它在聚合時的權重。
    • 用市場隱含機率當做「 sanity check 」，防止模型輸出太離譜的東西。

    但這還是有一個根本限制：

    你沒辦法完全防止 LLM 在關鍵事件上「看起來超合理卻完全錯」一次，而那一次就足以傷筋動骨。

    3.2 延遲：AI 再快，也有 API 延遲和交易路由的極限

    在延遲套利（latency arbitrage）這件事上，AI 其實不一定比傳統高頻系統更有優勢。

    • 真正的高頻交易用的是 C++、FPGA、物理距離最短的機房連接。
    • LLM 代理要：
    • 發出請求 → 模型計算 → 聚合 → 再發交易指令 → 上鏈或送到交易所。

    這整串延遲通常是 秒級 起跳，高頻交易玩的是 微秒級。

    所以，PolySwarm 比較像是在「人類反應時間窗」內做延遲套利：

    • 不是跟 HFT 競速，而是比一般手動玩家快。

    這個定位是合理的，但也意味著：

    • 一旦市場裡有越來越多自動化系統，這種套利空間會被越磨越薄。

    3.3 檢索何時幫倒忙？TimeSeek 那 12% 是一個警訊

    TimeSeek 發現：檢索在 12% 的情境裡讓模型變笨，這一點非常值得擴寫。

    幾個可能場景：

    1. 「舊 alpha」問題
    2. 很多看起來聰明的策略，其實是 2010 年就被用到爛的東西。
    3. 公開資訊中出現的投資建議，通常已經不具備結構性優勢。
    4. 資訊洪流裡，模型容易抓錯重點
    5. LLM 很會總結，但不一定懂「什麼才是對價格有邊際影響的資訊」。
    6. 檢索的時序問題
    7. 即使內容是對的，也可能是一小時前的新聞，而市場在三分鐘內就 price in。

    所以在設計 AI 交易代理時，「要不要檢索」不能是一個常數，而應該是：

    • 根據市場類型、時間點、波動程度，動態調整使用檢索的頻率與權重。

    3.4 穩定 Alpha 存在嗎？多代理 ≠ 自動印錢機

    回到最關鍵的問題：

    在這些研究裡，有看到穩定、可實際部署的 alpha 嗎？

    目前的證據比較像是：

    • AI 在某些時間段、某些市場，能提供接近市場甚至略優的預測品質。
    • 透過多代理聚合，可以一定程度提升穩定性。
    • 但要長期穩定打敗整個市場，還看不到明確證據。

    幾個原因：

    1. 市場會反應 AI 行為
    2. 一旦 AI 代理大量進場，它們本身就會改變價格行為，原本可行的策略很快就失效。
    3. 模型更新與微調成本高
    4. LLM 對世界的「隱含知識」其實會過時，需要持續對新數據做訓練或微調。
    5. 真正的 alpha 常常來自非公開資訊或結構性優勢
    6. 比如：管道、供應鏈資訊、人脈、獨家數據源。
    7. 這些是 LLM 光靠網路檢索拿不到的。

    所以，我會這樣總結：

    AI 交易代理比較像「放大你原本有的 edge」的工具，而不是憑空創造 edge 的魔法。

    3.5 監管與道德：當 AI 開始「大規模下注」現實世界事件

    最後談一個不那麼技術，但很重要的面向：監管與倫理。

    PolySwarm 論文其實有提到法規與反饋迴路風險，搭配 TimeSeek 的結果，可以看到幾個問題愈來愈接近現實：

    1. 監管：誰對 AI 下錯單負責？
    2. 如果一個全自動 AI 代理在 Kalshi 或 Polymarket 上大幅建倉，造成市場波動：
      • 交易所要不要限制某種「自動化 agent」的規模？
      • 如果 AI 因為幻覺導致誤判，造成洗倉，是開發者、部署者還是平台負責？
    3. 操縱與資訊迴路
    4. AI 代理如果開始引用社交媒體、新聞作為輸入，而同時又在市場裡下注：
      • 有沒有可能出現「自己看自己造成的新聞」、自我強化的價格泡沫？
    5. 賭博與社會影響
    6. 預測市場原本就被質疑有「賭博化政治、公共事務」的問題。
    7. 如果 AI 讓這些市場變得更高效、更容易參與，會不會放大這種影響？
    8. 道德邊界：AI 替人類做風險決策的程度
    9. 一般人如果把資產交給一個黑箱 AI 代理，連策略怎麼運作都不知道，只因為「它是某某大模型的 agent」，這基本上就是另類的「金融迷信」。

    我覺得，監管端遲早會問兩個問題：

    • 需不需要對「自動化 AI 代理」設立特別的識別與限制？
    • 是否應該要求這類系統具備某種「可解釋性」與「風險揭露」？

    結語：AI 代理不是神，卻正在改寫「誰可以參與金融市場」的邊界

    拉回一開始那個問題：

    「你會把錢交給一群 AI 小操盤手嗎？」

    在看過 PolySwarm 和 TimeSeek 之後，我的看法大概是：

    • 當輔助工具，可以。當唯一決策者，太早。
    • AI 代理目前最擅長的是：
    • 快速蒐集資訊
    • 提出合理的初步機率估計
    • 幫你做多市場、多策略的「第一輪篩選」
    • 但在「最終下注、風險承擔」這一層，
    • 人類仍然需要介入判斷，尤其是在杠桿高、尾風險重的情境。

    如果你是：

    • 做量化 / 風控 / 研究的：
    • 值得看 PolySwarm 和 TimeSeek 的完整論文，思考如何把「多代理 + 時間敏感的信任策略」加入你的 pipeline。
    • 對預測市場有興趣的：
    • 可以把 AI 當成「資訊整理助手」，而不是「自動印鈔機」。
    • 在監管或法遵領域的：
    • 現在是開始設計「AI 交易代理」規則的好時間，等整個市場都被這類系統塞滿，再來補課就太慢了。

    最後留一句我覺得很重要的提醒：

    市場不會因為你用了 LLM，就變得比較好賺。

    AI 能做的，是讓「有紀律、有方法」的人，放大自己的優勢；

    但如果只是想用一個炫炮的模型，跳過思考、直接賭一把，那你只是把傳統投機，包了一層新的 UI 而已。

    延伸閱讀

  • 從「結果對不對」到「過程可追溯」：新一代 AI 評估與合規工具長什麼樣？

    從「結果對不對」到「過程可追溯」：新一代 AI 評估與合規工具長什麼樣？

    你有沒有發現，現在大家在講「AI 評估」時，還是很習慣問一個問題：

    這個模型準不準？

    比如：考試幾分、Pass@1 多高、Bleu/Rouge 幾分、Win Rate 打贏 GPT-4 幾％。

    但當 AI 真的進到工作流程、產品線、甚至走進法規監管的世界，這個問題其實遠遠不夠。

    更關鍵的反而是：

    它是怎麼得到這個結果的？這個過程，能不能攤在陽光下？

    這篇文想聊的是：
    – 為什麼「看結果」已經不夠
    – 六條正在匯流的研究線索：
    – FactReview：把論文審稿變成「有證據、可重現」的流程
    – Compliance-by-Construction：用 argument graph + RAG 做安全認證級合規
    – Beyond Fluency：在 Agentic IR 裡，每一步都要設 verification gate
    – OpenEval：為什麼 AI 評估需要「item-level benchmark」
    – QualAnalyzer：把質性分析切成可審計的 atom
    – Context Engineering：靠結構化上下文提高「第一次就做對」的機率
    – 最後收斂成一組實用 checklist：未來你在公司導入 AI 工具時，應該要求哪些「可追溯」與「流程級評估」能力

    一句話先破題：

    過去是「對或錯」，未來會是「為什麼是這樣、證據在哪？」

    如果你只看模型最後吐出的答案，其實有點像：只看考試最後幾分，不看每一題的作答方式，也不知道監考老師有沒有睡著。

    在低風險情境，這樣用 AI 還撐得過去；但在四種場景，很快就會不夠用：

    1. 學術審稿：你敢讓一個黑箱 AI 決定論文收不收？
    2. 安全／法規合規：出事時，誰做的決策、依據是什麼，說得清嗎？
    3. 研究工作（尤其是質性研究）：審查委員問你「這個結論怎麼來的」，你不能回答「AI 覺得」。
    4. 一般知識工作（PM、法務、顧問、分析師）：一年後回頭看決策，你有沒有辦法復原當時的脈絡？

    下面我們用這四種場景，把六篇研究串一串，看新一代「可追溯 AI」大概會長什麼樣。

    場景一：論文審稿 —— FactReview 把「主觀審」變成「有證據的審」

    傳統審稿有幾個痛點：
    – 審稿人時間不夠，只能「掃一掃」
    – 很吃「論文寫得好不好看」，文筆好可能加分不少
    – 主張對不對，常常要靠 reviewer 印象或手動翻文獻
    – 更別說「真的去跑作者的 code」這件事，現實是多數人做不到

    FactReview 的核心想法是：

    不要只看投稿的故事，而是把「主張→證據→重現」變成一條可以機器協助的鏈。

    它做了幾件事：

    1. 主張萃取（claim extraction）

    2. 把論文拆成一條條主張：

      • 提出什麼方法？
      • 相較於哪些 baseline？
      • 哪些任務上「顯著更好」？

    3. 文獻定位（literature positioning）

    4. 自動去檢索相關工作，幫你看：

      • 這篇真的比「最接近」的工作好嗎？
      • 有沒有漏引、或者「重新包裝舊方法」？

    5. 執行式驗證（execution-based claim verification）

    6. 有開源 code 的情況下，直接跑 repo，在有限資源下重現關鍵實驗。

    7. 然後對每個主張打標：

      • 支持 / 部分支持 / 衝突 / 無法驗證

    8. 生成審稿與證據報告

    9. LLM 幫你把上面這些整理成一份「有段落、有引用、有重現結果」的 review。

    作者在 CompGCN 案例裡，真的跑出一個有趣的狀況：
    – 某些任務真的重現了作者結果 → 支持
    – 但在圖分類任務，整體性能主張只被「部分支持」

    這就從「我覺得作者誇大了」變成「我實際跑過、結果在這」，整個審稿過程突然有一種「工程化」的味道。

    重點不是 AI 幫你寫 review，而是：AI 幫你把 review 變成一條「證據鏈」。

    場景二：合規／安全認證 —— Compliance-by-Construction：從黑箱到「每個 claim 都要有證據」

    在高風險系統裡（醫療、航空、金融風控、關鍵基礎設施），有一個關鍵問題：

    你怎麼證明「這個系統是安全、合規」的？

    傳統做法是寫一堆文件、報告，手動整理「設計→實作→測試→審查」的證據。這種東西一來超花人力，二來其實很容易斷鏈（文件沒更新、測試沒對齊實作等等）。

    Compliance-by-Construction 想做的是一個蠻激進的改變：

    把整個合規流程，變成一張形式化的 argument graph，每一個節點都是「可以被檢查的 claim」。

    再加上 LLM + RAG，去幫你建構和維護這張圖。

    核心組件有四個：

    1. Argument Graph（論證圖）
    2. 把合規聲明拆成很多層級的 claim：
      • 系統是安全的
      • 因為控制 A、B、C 存在
      • 控制 A 的證據是測試 X、設計文檔 Y

    3. 每個 claim 必須被「下層 claim + 證據」支持。

    4. RAG（檢索增強生成）

    5. LLM 不再亂掰，而是：

      • 對每個 claim，去現有文件、測試報告、log 裡找證據
      • 找不到，就標記缺口，而不是硬生生成一段看起來合理的說法。

    6. 推理驗證核心（reasoning core）

    7. 限制 LLM 的推理邏輯，讓它不能「跳步」或做出不合理的推論。

    8. 例如：嚴格要求每個 claim 都要有明確證據指向，不能只有語義上好像合理。

    9. 溯源日誌（provenance logging）

    10. 每個 claim 是怎麼被建立、修改、接受的，都有 log。
    11. 日後 audit，能把整張 graph 走一遍。

    這種設計有一個很重要的精神：

    AI 不是「幫你寫一份漂亮的合規報告」，而是「幫你組裝一張可以被驗證的 argument graph」。

    對公司端的影響很直接：
    – 你可以具體回答「某個合規聲明是基於哪些測試、哪些文件」
    – 出事時能回溯是「哪個 claim、哪段證據」有問題
    – 監管機關要看時，不會只看到一份 narrative，而是能看到全圖

    場景三：Agentic IR —— Beyond Fluency：語言再順，也不能蓋掉「路線走錯」

    很多人現在在玩「AI Agent」：
    – 會自己規劃任務
    – 自己去搜尋資料、調用工具
    – 自己迭代思考，最後給你結果

    聽起來很酷，但現實是：

    只要前面某一步稍微偏軌，後面就會一路放大錯誤，最後看起來超流暢，但整條路徹底走錯。

    Beyond Fluency: Toward Reliable Trajectories in Agentic IR 把這個問題講得很白：

    • Agentic IR（代理式資訊檢索）其實是一個 Reason → Act → Observe 的長鏈
    • 錯誤可能發生在：
    • 規劃（plan 錯了題目）
    • 檢索（查錯資料）
    • 推理（解讀錯資訊）
    • 執行（tool 用錯）
    • 最可怕的是：
    • 語言流暢度完全不會反映錯誤程度
    • 它可以非常有自信地，優雅地，講一段完全錯的故事

    作者主張：

    不要只看「最後答得對不對」，要開始看「整條 trajectory 有沒有 integrity」。

    具體做法：Verification Gates

    在每一個「互動單元」加上 verification gate：
    – 規劃完 → 有沒有檢查「這個 plan 是否覆蓋了問題關鍵」？
    – 檢索結果 → 有沒有檢查「這些文件真的跟 query 有關」？
    – 推理步驟 → 有沒有 cross-check「結論有沒有被文本支持」？
    – 執行工具 → 有沒有檢查 API 回傳是不是符合預期格式？

    甚至在高不確定性時，要勇於選擇「不執行」或「適度退出」，而不是硬把任務完成。

    這其實就是把 agent 從：「一次跑到底，看結果」
    變成：「每一步都過關，整條路才算數」。

    換成產品語言：

    未來你在導入 Agentic 系統時，不該只問「它完成任務的成功率」，還要問：「它有沒有內建 step-wise verification？」

    場景四：AI 評估本身 —— OpenEval：沒有 item-level，就談不上嚴肅的評估科學

    AI 評估現在也有一個很大的盲點：

    • 許多 benchmark 只公布「總分」或「平均 accuracy」
    • 研究者微調 prompt、換模型，看 leaderboard 排名
    • 但我們其實不知道：
    • 哪些題目是模型的「死穴」？
    • 是不是某個子類型題目完全失效？
    • 量表本身設計有沒有偏誤？

    Position: Science of AI Evaluation Requires Item-level Benchmark Data 直接開炮：

    要建立嚴肅的「AI 評估科學」，item-level data 是必要條件。

    所謂 item-level，很簡單：
    – 不只要有「一個 benchmark 的總分」
    – 還要能看到：
    – 每一個題目（item）模型怎麼答
    – 每一題的 metadata（難度、題型、能力構面）
    – 標記者的分歧在哪裡

    這樣才有機會：
    – 做細粒度診斷：
    – 模型是否特別擅長某個子類型？
    – 評估本身是不是只測到某種偏狹的能力？
    – 檢驗 benchmark 的有效度（validity）：
    – 我們以為在測「推理能力」，結果題目其實都在考「常識填空」。

    作者也推出了 OpenEval 倉庫，牽頭推這套做法。

    實務上，這件事對企業也非常 relevant：

    當你宣稱「我們用 X 個 benchmark 評估這個模型」，在高風險場景下，監管機關很可能會追問：
    – 這些 benchmark 的 item-level 表現長怎樣？
    – 你怎麼知道它沒在某個角度完全失明？

    質性研究：QualAnalyzer 把「一整份訪談」拆成一顆顆可審計的 atom

    質性研究一直很依賴人類的「閱讀 → 詮釋 → 編碼」。
    引入 LLM 之後，很快出現兩種極端：
    – 一種是：完全信 AI，丟整份訪談給它，讓它幫忙找主題
    – 另一種是：完全不信，因為「看不懂它怎麼得出這個結論」

    QualAnalyzer 提出一個蠻優雅的折衷：

    把 LLM 的分析流程切到「非常細粒度（atomistic）」：
    – 每一小段資料（比如一個段落、一個回合）獨立處理
    – 每一顆「分析 atom」都留存完整的：prompt、input、output

    他們做了一個 Chrome extension，嵌在 Google Workspace 裡，實際演示兩個案例：
    – 論文整體性評分
    – 訪談稿的演繹主題編碼

    關鍵不是工具本身，而是方法論：

    • 分析不是一次「黑箱處理」，而是由很多小決策組成
    • 每個小決策都可以被審計：
    • 這段訪談為什麼會被編碼成這個主題？
    • AI 當時看到的上下文是什麼？
    • 如果人類不同意，可以精確指出哪個 atom 有問題

    對質性研究而言，這是大事：
    – 審查委員要的是「方法透明」
    – 有了這種 atom-level audit trail，
    – 你可以說：「這不是我瞎用 AI，而是一套可被審查的流程。」

    這概念其實可以平移到很多知識工作場景：
    – 客服 QA 標註
    – 內部文件分類
    – 品牌聲量質性分析

    只要你的任務是「看一堆文字 → 做判斷」，都應該問：
    我能不能把這個過程拆成很多小決策，每一個小決策都有 log？

    把錯一次做對：Context Engineering 用「結構化上下文」提升成功率

    前面幾個工作都在講「怎麼 audit 過程」，
    Context Engineering 則比較像是：

    在事情發生之前，先把「上下文」工程化，降低出錯機率。

    作者的觀察是：

    • 大家很愛聊「prompt 技巧」，但實務上更關鍵的是：
    • 你給模型的「上下文」是不是完整而結構化？

    於是他們提出：

    五種上下文角色（AEC-RM）：

    1. Authority：權威來源

    2. 告訴模型「應該以誰的聲音說話、遵循哪個權威標準」

    3. Exemplar：範例

    4. 給幾個好的輸入→輸出樣本，讓模型對齊風格與格式

    5. Constraint：限制

    6. 明確哪些不能做、不能編造、不能超出範圍

    7. Rubric：評分規範

    8. 告訴模型「什麼叫好的輸出」，有點像給它一份自我評分表

    9. Metadata：元資料

    10. 任務背景、使用者角色、目標受眾等

    再加上四階段 pipeline：Reviewer → Designer → Builder → Auditor
    – 不是一個人憑直覺寫 prompt，而是有明確角色分工

    實驗結果蠻直白：
    – 沒有好上下文的情況下：
    – 72% 的互動需要來回多次
    – 平均 3.8 次互動才搞定一件事
    – 「第一次就做對」只有 32%
    – 用結構化上下文之後：
    – 平均互動次數降到 2.0
    – 首次通過率升到 55%
    – 若允許多次迭代，最終成功率達 91.5%

    這件事跟「過程可追溯」也完全連在一起：

    當上下文是結構化、可版本控制的，你才能在事後說：
    「這次模型做錯，是因為 Exemplar 給得不好，還是 Constraint 定義不清？」

    收斂：未來導入 AI 工具，應該檢查的「可追溯 & 流程級評估」清單

    把上面幾條線索拉在一起，我會把未來的 AI 工具能力拆成兩大塊：

    1. 過程可追溯（Process Traceability）
    2. 流程級評估（Process-level Evaluation）

    以下是一份給「公司導入 AI 工具」用的實務 checklist，
    你可以直接拿去問 vendor、內部 AI 團隊，甚至拿來檢視自己做的系統。

    A. 過程可追溯：這個工具的「路線圖」，你看得到嗎？

    1. 步驟級 log
    2. 模型是不是把任務拆成多步？

    3. 每一步的輸入、輸出、使用的工具（API / 檢索）是不是都有記錄？

    4. 主張（claim）與證據的對齊

    5. 對於關鍵結論，能不能追溯到：
      • 是哪幾段文本、哪幾筆數據支持？

    6. 有沒有類似 FactReview 或 argument graph 的機制，
      把「主張 → 證據 →狀態（支持/部分支持/衝突）」串起來？

    7. 上下文版本控制

    8. Prompt / context 是否可版本化管理？

    9. 每次輸出，可以回到當時的 Authority / Exemplar / Constraint / Rubric / Metadata？

    10. 細粒度單元（atoms/items）

    11. 對於「長文件處理／大量樣本分析」，
      有沒有像 QualAnalyzer & OpenEval 那樣的：

      • atom-level / item-level log？
      • 可以一題一題、一段一段檢查與抽樣？

    12. 溯源日誌（provenance）

    13. 能不能回答：
      • 這個結果在哪個時間、由哪個模型版本、在什麼上下文下產生？

    B. 流程級評估：不是只看「準不準」，而是「整條流程穩不穩」

    1. Step-wise evaluation
    2. 有沒有對每個步驟的品質做評估？

    3. Agent 的 plan / retrieve / reason / execute，有沒有各自的 metrics？

    4. Verification gates

    5. 關鍵步驟前後，有沒有自動或半自動的檢查？

    6. 高風險場景：

      • 模型是否在信心不足時「選擇不執行」？
      • 是否會 escalate 給人類？

    7. Item-level benchmark data

    8. 對於內部評估集：

      • 是否保留每一題的模型輸出？
      • 是否可以做子群體分析（某類問題表現特別差）？

    9. 人類在迴路中的角色（Human-in-the-loop）

    10. 人類 reviewer / auditor 能不能有效介入：

      • 看每一個 atom/item 的決策
      • 覆寫錯誤
      • 把這些 feedback 餵回系統？

    11. 合規／責任追蹤（Accountability）

    12. 當模型建議被採用變成決策時：

      • 系統能不能記錄「誰看過、誰按下批准」？
      • 日後 audit 能不能還原「這個決策背後的 argument graph」？

    13. Context Engineering 能力

    14. 工具有沒有把上下文顯式結構化？
    15. 有沒有方法去評估「上下文品質」對結果的影響，
      而不是只調模型參數或 prompt 關鍵字？

    結尾：AI 工具的新標準——「我不只要答案，還要你給我故事的全紀錄」

    如果要用一句話總結這篇：

    未來真正成熟的 AI 系統，
    不會只跟你說「答案是什麼」，而是會把「我是怎麼走到這個答案」完整攤開。

    • FactReview 告訴我們：審稿不該只看故事，要看主張 + 文獻 + 重現
    • Compliance-by-Construction 告訴我們：合規不該只是文件，而是一張可驗證的 argument graph
    • Beyond Fluency 提醒我們：Agent 不該只看最後結果，而要有每一步的 verification gate
    • OpenEval 在推：沒有 item-level data，談不上嚴肅的 AI 評估科學
    • QualAnalyzer 展示：即便是質性研究，也可以做到 atom-level audit trail
    • Context Engineering 則說：把上下文工程化，是讓 AI 第一次就做對 的關鍵

    如果你在公司裡負責導入 AI 工具，接下來可以慢慢把標準從：

    • 「這個模型分數比別人高嗎？」

    升級到：

    • 「這個系統能不能讓我：
    • 看懂它的推理過程？
    • 驗證它的證據？
    • 追溯每個決策的上下文與責任？」

    當我們開始用這套標準選 AI，整個生態會慢慢被推向一個更健康的方向：
    – 少一點漂亮的 demo
    – 多一點「可以挺過 audit」的實戰系統

    如果你現在就在設計 AI 產品，也可以試著問自己：

    「我能不能讓使用者，不只得到答案，還能獲得一條清楚的『推理與證據路線圖』？」

    這，可能會是下一代 AI 工具真正的競爭力所在。

    延伸閱讀

  • 網站第一篇文章

    歡迎使用 WordPress。這是這個網站的第一篇文章，試試為這篇文章進行編輯或直接刪除，然後開始撰寫新文章！