法律 agent 從 coding agent 繼承了什麼：來自 Legora 的經驗（第 1/2 段）

🧑‍🏫 Legora 是做律師用 AI 的新創公司，這支影片是他們的工程師在講：怎麼把「寫程式的 AI」已經磨好的做法，搬到法律工作上。重點不只在法律，任何整天處理文件的工作，都能從這套思路看出 AI 為什麼有時做得好、有時會漏東漏西。

• 00:17 講者 Jakob Emmerling 是 Legora 的工程師。Legora 做給律師用的協作型 AI，這場的主題是：打造法律 agent 時怎麼向 coding agent 學習
  ↳ 講者 Jakob Emmerling 是 Legora 的工程師，Legora 做給律師用的 AI 協作工具。這場在談：做法律 agent（會自己拆步驟、動手把任務做完的 AI）時，可以跟寫程式的 AI 學什麼。
• 00:17 Legora 在做一個以 AI 為基礎的律師工作空間，讓律師在上面從頭到尾完成法律任務
  ↳ Legora 想做的不只是一個回答問題的聊天機器人，而是一個工作空間。律師從接到任務到交出成品，整個流程都在裡面跟 AI 一起完成。
• 00:51 六個月前他們意識到，打造 agent 的方式必須改變。起因是 AI 寫程式的演進圖：從不好用的 autocomplete、好用的 autocomplete、chatbot，一路走到 agent、background agent
  ↳ 他們回頭看 AI 寫程式怎麼一路變過來：autocomplete（自動補完）從難用變好用，再到聊天機器人，然後是會自己動手的 agent，最後是 background agent，也就是在背景自己跑的 agent。看到這條演進，他們覺得自己打造 agent 的方式也得改了。
• 01:29 回頭看六個月前，coding 以外的其他垂直領域其實明顯落後。他們開始思考：為什麼 coding 進步這麼快、agent 在 coding 上這麼強，在法律工作上卻還不行
  ↳ 半年前，寫程式以外的領域明顯落後。他們問的是：同樣的 AI，為什麼在寫程式上已經能自己做完大任務，換到法律工作就不行？於是決定去拆解寫程式那邊到底做對了什麼。
• 02:07 coding 跟法律工作有很多相似處：都大量建立在前人的成果上、都以文字文件為主、組織與事務所內部有嚴格慣例、都有很強的審查文化
  ↳ 寫程式跟法律工作其實很像：都是拿前人的成果來改，例如舊程式碼、範本合約；主要都在處理文字；每家公司或律所都有自己嚴格的寫法規矩；而且做完一定有人要審。
• 02:07 審查文化的例子：工程師上線前會互相 review pull request（現在也 review agent 的 PR）；律師則是 associate 起草，partner 審閱並簽核後才交給客戶
  ↳ 審查的例子：工程師改完程式會送 pull request，請同事審過才上線；現在連 agent 提的修改也要審。律所這邊是 associate（資淺律師）先起草，partner（合夥人）看過、簽核後才交給客戶。
• 02:42 這些相似處不是法律和 coding 獨有，任何知識工作都跟 coding 有很多相似點。講者認為，在其他垂直領域做產品的人很值得做這個比對練習
  ↳ 講者提醒，這些共通點不是法律獨有，任何知識工作都跟寫程式有很多相似的地方。如果你在其他行業做 AI 產品，值得逐項比對，看哪些寫程式的經驗能搬過來用。
• 03:12 向 coding agent 學習可分三類：一是可以原封不動沿用的，二是需要轉譯的，三是必須為自己領域發明的
  ↳ 向寫程式的 agent 學，可以分三種：一是原封不動直接拿來用；二是概念可以借，但要改成適合自己領域的版本；三是寫程式那邊根本沒有，只能自己發明。
• 03:12 可直接沿用的：to-dos、planning、sub-agents、sandboxes、human in the loop。這些是 coding agent 摸索出來的 UX 或長時間任務的解法，對 agent 普遍適用
  ↳ 可以直接搬的有：to-dos（待辦清單）、planning（先訂計畫）、sub-agents（把子任務分給其他 agent）、sandbox（隔離的執行環境）、human in the loop（關鍵動作讓人把關）。這些做法任何 agent 都用得上。
• 03:43 這些可沿用的東西，正好是用 Anthropic 的 agent SDK，甚至 managed agents 時就直接內建的
  ↳ 這些功能，用 Anthropic 的 agent SDK（打造 agent 的開發工具包），或更進一步用 managed agents 時就已經內建了，不用自己從頭做。
• 03:43 需要轉譯的：你的領域裡某個問題長得很像 coding 的某個子問題，但不能直接照搬，要先看懂 coding 怎麼解，再把那個模式轉到自己的領域
  ↳ 需要轉譯的情況是：你遇到的問題，本質上跟寫程式裡某個小問題很像，但細節不同，不能照抄。要先看懂寫程式那邊是怎麼解的，抓出背後的模式，再用自己領域的方式重做一次。
• 04:19 必須自己發明的（Legora 的例子）：每個回答都要有 grounding 和 citations，讓律師能查證說法出處；以及為 due diligence 處理大量文件
  ↳ 要自己發明的，以 Legora 為例有兩個：一是每個回答都要有 grounding 和 citations，也就是每句說法都有依據、附上出處，讓律師能查證；二是 due diligence（交易前的盡職調查），要一次處理大量文件。
• 04:52 沿用範例一 planning mode：跟 coding agent 做大任務時，會先訂詳細計畫，而不是丟個 prompt 就讓它跑好幾小時。先訂計畫可以一起探索問題、蒐集 context、事先做好決定，執行時 agent 就不用替你做決定
  ↳ planning mode 是指在 agent 開工前，先跟它一起訂好詳細計畫。這樣可以一起把問題搞清楚、備齊 context（背景資料），重要的決定也由你先拍板，agent 執行時就不必替你做主。
• 05:25 在 Legora，律師遇到較大的法律任務，也是先規劃、反覆修改計畫，對所有決定和假設都滿意後再讓 agent 執行。這是 coding agent UX 的一對一移植
  ↳ Legora 把這套一對一搬過來：律師遇到較大的案子，會先跟 agent 來回修改計畫，確認每個決定和假設都沒問題，才讓它開始做。
• 05:55 沿用範例二是工具呼叫／危險動作的核准：coding agent 執行沒有 sandbox 的 shell 指令前會先問你；法律 agent 也一樣，你不會希望它隨便刪掉重要的客戶文件
  ↳ 第二個直接搬的是「危險動作先問」：寫程式的 agent 要執行沒放在 sandbox 裡的指令前，會先問你一聲。法律 agent 也一樣，要刪文件前得先問，免得重要的客戶文件被誤刪。
• 06:29 這套 UX 直接照搬，因此省下自己反覆嘗試、找出最佳 UX 的過程
  ↳ 因為直接用寫程式那邊已經驗證過的操作設計，Legora 省下了自己反覆試錯、摸索哪種操作方式最好用的時間。
• 06:29 轉譯範例是文件編輯：律師很愛用 Microsoft Word，大量時間花在起草、redlining、審閱文件和來回修改，所以法律 agent 一定要把這件事做好
  ↳ 轉譯的例子是改 Word 文件。律師大量時間都花在 Word 裡起草、redlining（標出修改處，讓對方看得到改了什麼）、審閱和來回改稿，所以法律 agent 一定要把這件事做好。
• 07:03 docx 編輯比純文字難：docx 其實是一堆 XML 檔打包成的 zip，裡面有大量 metadata 和雜訊，不像改 markdown 那麼簡單
  ↳ 難的地方在於：docx 看起來是一份文件，其實是一包壓縮起來的 XML 檔（一種用標籤標記結構的格式），裡面塞滿格式設定之類的雜訊。不像 markdown 這種純文字格式，直接改字就好。
• 07:33 舊做法：上層 agent 把編輯意圖交給另一個 reasoning model，它根據文件 context 和高層指示，判斷要改哪些地方（例如 50 頁範本要在第 1、3、5、6 頁插入內容）
  ↳ 舊做法是分工：主 agent 說要改什麼，交給一個專門推理的模型，由它判斷要改哪些位置。例如一份 50 頁的範本，要在第 1、3、5、6 頁插入內容。
• 08:04 這個 reasoning model 不寫出完整修改內容，因為 token 會非常多；而過去模型常會變得 lazy，範本填到文件中間就開始出問題
  ↳ 這個推理模型只標出位置，不寫完整內容，因為全部寫出來 token（模型計算文字量的單位）會非常多。而且以前的模型容易偷懶，範本填到文件中間品質就開始走樣。
• 08:04 接著把每個編輯標記分派給個別模型，寫出含樣式資訊的完整修改，並參考前後文把內容融入文件。這解決了很多 exhaustiveness 問題
  ↳ 接著把每個要改的位置各派給一個模型，讓它寫出含格式的完整內容，並參考前後文接得自然。這讓 exhaustiveness，也就是「該改的地方全部改到」，改善很多。
• 08:37 但也帶來新問題：大量獨立的 LLM 呼叫，各自推理、context 不同、工具不同，產生各種 handoff 問題
  ↳ 但代價是出現一大堆各自獨立的 AI 呼叫，每個看到的資料不同、手上的工具不同、各自推理。彼此交接（handoff）時就很容易出錯。
• 08:37 handoff 問題的例子：上層 agent 加了新工具後，會指示編輯模型用某個工具去抓 context，但編輯模型根本沒有那個工具。agent 越強大，這類怪問題越多
  ↳ 舉例來說，主 agent 新增了工具之後，會叫編輯模型「用那個工具去查資料」，但編輯模型手上根本沒有那個工具。agent 越強大，這種對不上的怪問題就越多。
• 09:10 反觀 coding agent 最後都收斂成同一種做法：在迴圈中讀取、編輯、驗證。讀取通常以行為單位，讀的是簡單的純文字檔
  ↳ 反觀寫程式的 agent，大家最後都收斂到同一招：讀、改、檢查，不斷循環。讀的時候通常一行一行看，讀的也都是簡單的純文字檔。
• 09:42 編輯靠 string replace、patch 或以行為單位的編輯工具；改完後模型會推理下一步，或跑靜態型別檢查、linting 等
  ↳ 改的時候，用 string replace（找到這串字換成那串）、patch 或按行修改的工具。改完之後，模型會想下一步要做什麼，或跑型別檢查、linting（自動抓格式和低級錯誤）之類的檢查，確認沒有改壞。
• 09:42 他們拿 coding agent 試大型文件，要它在 20 個地方做精準修改，結果直接成功，沒有過去編輯法律文件時那些 exhaustiveness 問題
  ↳ 他們直接拿寫程式的 agent 去改大型文件，要它在 20 個地方做精準修改。結果一次就成功，以前改法律文件時常見的漏改問題都沒有出現。
• 10:18 新做法：同樣的編輯迴圈，有 read 工具、edit 工具和 verify 步驟，只是工具實作不同
  ↳ 所以新做法就是照搬這個循環：一樣有讀取工具、編輯工具和檢查步驟，差別只在這些工具背後怎麼處理 Word 檔。
• 10:18 讀取時先把 docx 轉成 intermediate representation：一個扁平、單一的文字檔，讓 agent 可以直接操作
  ↳ 讀取時，先把 docx 轉成 intermediate representation（中間格式），也就是一份扁平、乾淨的純文字檔。agent 可以像看程式碼一樣直接讀它。
• 10:49 一組編輯工具直接作用在這份 intermediate representation 上，agent 可以在讀和改之間來回、看到自己的修改，並持續循環
  ↳ 編輯工具也直接改這份中間格式。agent 可以讀、改、再讀，看到自己剛剛改了什麼，一直循環到做完為止。
• 11:21 第一次試是做 POC，沒有結構化的 eval set，只是 vibe check：跟模型對話，看看效果如何
  ↳ 第一次嘗試只是 POC（概念驗證，先做個原型看行不行得通）。他們沒有正式的 eval set（測試題庫），只做 vibe check：直接跟模型對話，憑感覺看效果如何。
• 11:21 做出第一版 Word 編輯功能的同事提議測試：把一份 10 頁文件逐段從英文翻成瑞典文。這件事在舊架構或舊模型上很難完整做完
  ↳ 做出第一版 Word 編輯功能的同事出了一題：把一份 10 頁文件逐段從英文翻成瑞典文。這種又長、每段都要顧到的任務，用舊架構或舊模型很難完整做完。
• 12:22 agent 逐段翻譯，有時會迷路，就重讀全文，發現上面漏了一段再回去補，這樣持續約 10 分鐘。最後打開文件，全部都翻好了
  ↳ agent 一段一段翻，有時會搞不清進度，就重讀全文，發現前面漏了一段再回去補。這樣跑了大約 10 分鐘，打開文件一看，全部都翻好了。
• 12:22 最有趣的是，為了測試新 harness 和工具設計的效果，整個測試是用 Haiku 跑的，講者說「這甚至不是一個好模型」。這讓他們意識到，模仿 coding agent 的工具設計可能真的有用
  ↳ 最關鍵的是，這次測試用的是 Haiku（Anthropic 較小型的模型），講者還說它「甚至不算好模型」。連它都做得到，代表效果來自工具設計，模仿寫程式 agent 的設計方向是對的。
• 12:57 講者的心智模型：讓模型感覺自己幾乎就在 coding agent harness 裡，只是在做法律任務
  ↳ 講者的核心想法是：讓模型覺得自己幾乎就待在寫程式的 harness（包在模型外面的整套工具和流程）裡，只是這次處理的剛好是法律任務。
• 12:57 因為 harness 的工具設計很像，會產生類似的執行軌跡，就能吃到 coding agent harness 上做過的 reinforcement learning 和 fine tuning 的好處，很多東西直接免費獲得
  ↳ 因為寫程式的 harness 上已經做過大量 reinforcement learning（強化學習）和 fine tuning（微調）。工具設計長得像，模型做事的過程就會像，那些訓練成果等於免費拿來用。
• 13:28 另一個例子是法律文件的 linting，基本上就是「法律文件版的 ESLint」。靜態型別檢查這類工具能讓 agent 在機械性的細節上得到回饋迴圈
  ↳ 另一個例子是法律文件的 linting，就像寫程式常用的檢查工具 ESLint 的法律版。它負責抓機械性的小錯，讓 agent 改完馬上得到回饋，知道哪裡要修。
• 13:28 法律文件裡也有很多可以靜態驗證的東西，能幫 agent 完成較大的任務
  ↳ 法律文件裡也有很多東西，可以用固定規則自動檢查、不需要人判斷。有了這種檢查，agent 比較能獨力做完大型任務。
• 14:05 例子：大型合約開頭引用了後面某一段，agent 卻把那段刪了。用靜態方式檢查所有引用是否仍然有效，再回饋給 agent：「你可能要改一下底下引用到這裡的段落」
  ↳ 舉例：大型合約開頭引用了後面某一段，agent 卻把那段刪了。系統可以自動檢查所有引用是否還對得上，再提醒 agent：「下面有段落引用到這裡，你可能要一起改。」

Legora 第一次用新的 docx 編輯迴圈做 POC（把 10 頁文件逐段從英文翻成瑞典文）時，用的是哪個模型？