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

🧑‍🏫 這支是法律 AI 平台 Legora 的分享。講者說明怎麼借用 coding agent（專門幫工程師寫程式的 AI agent）的做法，來打造法律 agent。agent 指的是能自己規劃步驟、使用工具、把任務做完的 AI。後半段有兩個實際 demo：一個是 AI 自己改合約，另一個是一次整理上百份文件。看完會知道 AI 助手做「真正的工作」是什麼樣子，也知道人該在哪些地方把關。

• 14:23 linter 可以再延伸：在 linter 裡做 LLM-based 的檢查，處理比較不機械化的問題，讓回饋迴圈的感覺很接近寫程式
  ↳ linter 是寫程式時自動挑錯的檢查工具。講者說，裡面也可以讓 LLM（像 Claude 這類大型語言模型）檢查沒有固定規則的問題。這樣 agent 改完就能馬上收到回饋，跟寫程式一樣。
• 14:23 講者接著談最後一類：打造 agent 時必須自己「發明」的東西，任何領域都有對應的例子
  ↳ 講者把打造 agent 要做的事分成三類：直接沿用、改一改再用、自己發明。這裡講最後一類：coding agent 沒有現成做法，得為自己的領域量身打造的部分。
• 14:55 每個領域都有從業者每天要解決的專屬任務，希望 agent 能做得跟人一樣好，才能得到最好的結果
  ↳ 光有通用能力還不夠。agent 必須把這個行業每天在做的核心工作，做到跟專業人員一樣好，使用者才會覺得真的好用。
• 14:55 法律領域的例子是 due diligence：Company A 收購 Company B 時，律師要確認這筆交易沒有問題
  ↳ due diligence 就是盡職調查。A 公司要買下 B 公司之前，律師要先把 B 公司徹底檢查一遍，確認沒有藏著會讓交易出事的問題。
• 15:26 律師得逐一審閱 Company B 與其他方簽的所有合約和其他有拘束力的文件，大公司可能有成千上萬份
  ↳ 難的是數量。B 公司跟客戶、供應商、員工簽的每份合約，還有其他有法律效力的文件，全部都要看。大公司可能有成千上萬份，一份份人工讀非常耗時。
• 15:26 平台上已經有 Tabular Review：像表格的介面，每一列是一份文件，新增欄位並指定要擷取的內容，就能做結構化資料擷取
  ↳ Tabular Review 是 Legora 平台本來就有的功能，長得像 Excel：一列是一份文件。你加一欄並寫明要抓什麼，例如「到期日」，AI 就幫每份文件填好。這就叫結構化資料擷取。
• 15:59 不必讀完整份文件，靠 LLM 擷取相關資訊來掌握大量文件的全貌，律師再篩選特定當事方或 red flag 深入追查
  ↳ 律師不用每份都讀完，先從表格看出整體樣貌。接著再篩出特定對象或 red flag（值得警覺、要追查的疑點）深入看，把時間花在刀口上。
• 15:59 做法是讓 agent 用跟人一樣的方式使用 Tabular Review 這個平台功能
  ↳ 他們沒有另外幫 agent 做一套工具，而是讓它像律師一樣操作同一個功能。人用得順手的工具，agent 也能拿來用。
• 16:29 agent 把整個資料夾的文件丟進工具，自己指定要擷取哪些內容，產生儲存格的值後，再篩選這一大張表，找出跟任務有關的資訊
  ↳ 流程是：把整個資料夾丟進去，自己決定要開哪些欄位，等 AI 把表格填完，再篩這張大表，找出跟任務有關的內容。
• 16:29 其他領域也有類似情況：會計師需要很機械化地做 reconciliation，醫師大概也有很特定的任務
  ↳ reconciliation 是對帳，也就是會計師逐筆核對兩邊帳目有沒有對上，很機械化。醫師也有自己的專屬任務。意思是每個行業都有屬於自己、需要量身打造的核心工作。
• 16:59 可以把這部分想成 agent 最後約 20% 的工作，讓它在特定領域真正做得好
  ↳ 通用的 agent 能力大約能完成八成工作。最後約兩成要靠針對這個領域的專屬功能補上，才會從「堪用」變成「真的好用」。
• 17:29 Demo 1：登入後會看到聊天框。專案「Employment Agreements」裡有幾份虛構員工的僱傭合約，以及一份 HR policy
  ↳ Demo 1 開始。登入後會看到一個聊天框。專案「Employment Agreements」（僱傭合約）裡有幾位虛構員工的合約，還有一份 HR policy，也就是公司的人事規章。
• 18:00 下的任務是：聖誕節期間給每位員工多一週假，並先規劃要做的工作
  ↳ 使用者交代的任務是：聖誕節期間讓每位員工多放一週假。而且要 agent 先規劃要做哪些事，不要急著動手。
• 18:00 agent 先熟悉環境，搜尋 employment agreements、vacation、time off，找出有哪些合約和政策
  ↳ agent 沒有要使用者提供檔案，而是自己用 employment agreements、vacation、time off（休假）這些關鍵字去搜尋，弄清楚有哪些合約和規章。
• 18:32 agent 列出的計畫：審閱所有僱傭合約、修改合約加入 Christmas shutdown 條款、更新 HR policy manual
  ↳ 它提出三個步驟：先看過所有僱傭合約，再在合約裡加入 Christmas shutdown 條款（聖誕節停工放假的規定），最後同步更新人事規章。
• 19:04 就像把 agent 丟進 codebase，它會先自己收集脈絡；使用者不用告訴它有哪份政策、哪五份合約要改
  ↳ codebase 是一個軟體專案的全部程式碼。coding agent 會先自己讀程式碼摸清狀況，這個 agent 也一樣，自己找出該改哪份規章、哪五份合約，使用者不用一一交代。
• 19:04 使用者可以針對計畫跟 agent 反覆調整，例如不要另開章節、換個措辭
  ↳ 計畫可以來回修改。例如跟它說「不要另外開一個章節」、「這句換個說法」，就像跟同事討論交辦的工作。
• 19:36 送出計畫後，背後跑的就是前面講的編輯迴圈：讀文件 → 推理要改什麼 → 呼叫編輯工具 → 回頭重讀確認修改正確
  ↳ 計畫確定後，agent 會一直重複這個循環：讀文件、想好改哪裡、呼叫編輯工具修改，最後回頭再讀一次，確認改對了。
• 20:09 agent 先把要改的文件複製到另一個空間修改，讓使用者在寫回原檔前先審閱變更
  ↳ 它不直接動原檔，而是先複製一份到旁邊修改。等使用者看過、同意之後才寫回去，避免改錯了救不回來。
• 20:39 有一份測試用合約原本就有 Christmas shutdown 條款，agent 決定一併修改，讓日期跟其他合約一致
  ↳ 有一份測試用的合約本來就有聖誕停工條款。agent 沒有略過，而是順便把日期改成跟其他合約一致。
• 20:39 可以看到每份文件新增了什麼、所有修改，以及原始文件的 redline 版本
  ↳ 使用者可以看到每份文件加了什麼、所有修改內容，還有 redline 版本。redline 就像 Word 的追蹤修訂，會把改過的地方直接標在原文上。
• 21:09 redline 保留正確的格式和縮排，在 benefits 段落加入 Christmas shutdown 條款；接著也在年假政策的對應段落加上 redline
  ↳ redline 保留了原本的格式和縮排，新條款加在 benefits（員工福利）段落。人事規章裡年假那一段，也同樣標出了修改處。
• 21:39 agent 還主動想起草員工公告 memo，使用者可以選用哪個範本、決定 memo 的樣子
  ↳ agent 還主動提議起草一份給全體員工的公告 memo（內部通知信）。要用哪個範本、長什麼樣子，由使用者決定。
• 22:11 Demo 2：另一個專案有約 100 份 due diligence 可能遇到的雜項文件，例如保險單、workers compensation
  ↳ Demo 2 開始。另一個專案裡有大約 100 份盡職調查時可能碰到的雜項文件，例如保險單、workers compensation（職災補償）相關文件。
• 22:41 用事先準備好的 prompt，要求 agent 對所有檔案做結構化審閱：有哪些合約類別、重要當事方、有沒有 red flag
  ↳ 使用者貼上事先寫好的 prompt，也就是給 AI 的指令，要 agent 整理所有檔案：有哪些合約類別、重要當事方是誰、有沒有 red flag。
• 22:41 prompt 也要求 agent 把所有僱傭合約放進一個資料夾，留給之後的工作使用
  ↳ 同一份 prompt 也要求把所有僱傭合約集中放進一個資料夾，方便之後接著處理別的工作。
• 23:18 因為 prompt 不夠詳細，agent 沒有直接動手，而是先寫計畫
  ↳ 因為指令寫得不夠細，agent 沒有馬上動手，而是先寫出計畫，再照著計畫做。
• 23:18 agent 先建立 tabular review，並知道 100 份文件需要幾分鐘讓 AI 逐一處理
  ↳ 它先建立一張 tabular review 表格，也知道 100 份文件要讓 AI 一份一份處理，會花上幾分鐘。
• 23:48 agent 要寫出所有要放進 tabular review 的內容，所以這是一個很長的 tool call，需要一點時間
  ↳ tool call 是 agent 呼叫某個工具去做事的動作。這次它要一口氣寫出表格裡所有欄位和擷取說明，內容很長，所以要等一下。
• 24:18 Tabular Review 畫面：每一列是一份文件，欄位定義要擷取的資料；agent 自己決定擷取文件類別，並寫出詳細 prompt 說明怎麼擷取
  ↳ 畫面上一列是一份文件，一欄是一項要抓的資料。「文件類別」這欄是 agent 自己決定加的，它還寫了詳細說明，告訴 AI 該怎麼判斷。
• 24:52 它不只是平面的資料表，而是完全互動、可審閱的介面，右側可以同時看到文件和擷取出的資料點
  ↳ 這不是只能看的死表格。點下去之後，右邊會同時顯示原文件和抓出來的資料，可以直接對照檢查。
• 24:52 律師可以驗證答案，例如看到文件被標成 compliance regulatory，以及模型這樣分類的理由
  ↳ 律師可以驗證 AI 的答案。例如某份文件被標成 compliance regulatory（法規遵循類），旁邊會寫出模型為什麼這樣分類。
• 25:24 點一下就能在文件中 highlight 出內容的來源；驗證後可以標記為 verified，系統會追蹤驗證進度
  ↳ 點一下，原文裡答案的出處就會被標亮。確認沒問題可以標成 verified（已驗證），系統會記錄整體核對到哪裡了。
• 25:54 資深律師可以請 associate 複核資料點，人與 AI、人與人之間都能在這個介面上協作
  ↳ 資深律師可以請 associate（事務所裡通常較資淺的受僱律師）複核部分資料。所以人和 AI、人和人都能在同一個畫面上分工合作。
• 25:54 它也擷取了當事方，點 citation 會跳到文件對應位置；還提出 red flag，例如僱傭合約裡有 placeholder
  ↳ 表格也抓出了當事方，點 citation（引用出處）就會跳到原文位置。它還標出 red flag，例如僱傭合約裡還留著 placeholder，也就是「[姓名]」這種沒填的空格。
• 26:24 agent 在背景完成任務；tabular review 可以當作 human in the loop 步驟，用來驗證結果、更了解底層資料
  ↳ agent 在背景把事情做完。這張表也是 human in the loop 的環節，意思是在流程中安排人來檢查把關，讓律師驗證結果，也更了解手上的資料。
• 26:54 agent 的成果：找出文件類別、重要當事方、一些 red flag，並把所有僱傭合約移到專屬資料夾
  ↳ 最後的成果：分好文件類別、列出重要當事方、找出幾個 red flag，也把所有僱傭合約搬進專屬資料夾。
• 27:24 為什麼 coding 在 AI 採用上領先？可能原因之一：工程師比較願意嘗試新工具、採用新技術
  ↳ 講者問：為什麼寫程式這個領域的 AI 應用跑得最快？一個可能的原因是，工程師本來就比較願意嘗試新工具、新技術。
• 27:24 另一個可能原因：解決 coding 能帶動軟體工程其他領域的成長，更快加速進展
  ↳ 另一個可能的原因：把寫程式這件事做好，會連帶加速軟體開發的其他環節，整體進步就滾得更快。
• 27:59 做其他垂直領域的人不必在意它為什麼領先，持續觀察 coding agent 推出了什麼就好
  ↳ 他的建議是：做其他領域的人不必糾結原因，只要持續關注 coding agent 又推出了什麼新東西就好。
• 27:59 任何垂直領域 agent 的框架：可用的直接重用、相似但不同的就轉譯、剩下的為自己的領域發明
  ↳ vertical agent 是專為某個行業打造的 agent。做法分三步：能直接用的就沿用；類似但不一樣的，就改成自己領域的版本；完全沒有的，就自己發明。
• 27:59 coding agent 每推出新東西，就拿來用（講者原話是 steal it），從中受益
  ↳ 講者的原話是「steal it」（偷過來）：coding agent 每推出新招，就拿來套用在自己的領域，直接受益於它們先走一步的成果。

講者認為，打造垂直領域 agent 時，哪一部分需要自己「發明」？