案例研究：法律文件審查系統
本案例研究展示如何建構一個能夠自主審查法律文件、識別問題並產生綜合報告的 AI 代理。這是一個理解 AI 代理架構和控制迴圈的實際範例。
使用案例：自動化法律審查
Section titled “使用案例：自動化法律審查”法律團隊需要審查多份文件以檢查：
- 缺失或不清楚的條款
- 合規問題（GDPR、CCPA 等）
- 風險評估
- 一致性和清晰度
人工審查耗時、昂貴，且容易遺漏問題。
解決方案：AI 代理工作流程
Section titled “解決方案：AI 代理工作流程”一個能夠執行以下任務的 AI 代理：
- 掃描 法律文件資料夾
- 審查 每份文件的法律問題
- 分類 發現的問題嚴重程度（關鍵/警告/資訊）
- 產生 詳細的 LEGAL_NOTICES.md 文件
- 總結 發現於執行摘要 REVIEW_SUMMARY.md
- 追蹤 進度並向使用者顯示正在執行的步驟
範例輸入/輸出
Section titled “範例輸入/輸出”輸入：
/project/legal_docs/├── contract_v1.pdf├── terms_of_service.docx└── privacy_policy.txt輸出：
/project/legal_docs/├── contract_v1.pdf├── terms_of_service.docx├── privacy_policy.txt├── LEGAL_NOTICES.md # 每份文件的詳細發現└── REVIEW_SUMMARY.md # 包含狀態的執行摘要LEGAL_NOTICES.md 節錄：
## contract_v1.pdf
### ⚠️ 關鍵問題
**缺少終止條款**
- **位置：** 第 5 節（合約期限）- **描述：** 未明確指定終止條件或通知期限- **影響：** 若任一方想退出合約將面臨法律風險- **建議：** 新增包含 30 天通知期的終止條款
### ⚡ 警告
**不明確的付款條款**
- **位置：** 第 3 節（付款）- **描述：** 付款時程表述為「合理期限」，未指定具體天數- **建議：** 指定確切的付款條款（例如：Net 30）REVIEW_SUMMARY.md 節錄：
# 法律審查摘要
**狀態：⚠️ 需要注意**
**指標：**
- 已審查文件：3- 關鍵問題：3- 警告：4- 資訊：2
**主要建議：**
1. 立即為 contract_v1.pdf 新增終止條款2. 更新 terms_of_service.docx 以符合 GDPR 規範3. 在 privacy_policy.txt 中新增 DPO 聯絡資訊
**整體評估：**文件在執行前需要法律關注。必須處理關鍵問題。-
文件處理
- 支援多種格式：PDF、DOCX、TXT、MD
- 處理包含混合檔案類型的資料夾
- 可靠地提取文字內容
-
法律分析
- 檢查缺少的關鍵條款（終止、責任、付款）
- 驗證標準合規性（GDPR、CCPA）
- 識別模糊或含糊的語言
- 評估風險層級
-
輸出產生
- 結構化的 markdown 報告
- 清晰的嚴重程度分類
- 具體的位置參考
- 可行動的建議
-
使用者體驗
- 顯示進度（正在執行哪個步驟）
- 顯示已完成的步驟
- 可能的話提供時間估計
- 允許中斷/取消
-
可靠性
- 優雅地處理錯誤
- 重試失敗的操作
- 驗證輸出
-
效能
- 高效地處理文件
- 最小化 API 呼叫
- 使用適當的模型大小
-
成本效益
- 盡可能使用較小的模型
- 快取結果
- 避免冗餘處理
-
可觀察性
- 記錄所有動作
- 追蹤成功/失敗率
- 監控成本
本案例研究可以使用兩種不同的模式實作：
1. 簡單 ReAct 模式
Section titled “1. 簡單 ReAct 模式”最適合： 快速原型、簡單工作流程、學習
- 單一模型做出所有決策
- 一次一個動作
- 即時回饋迴圈
- 最小架構
請參閱： react-pattern.md 完整實作
優點：
- 易於實作
- 易於除錯
- 執行透明
缺點：
- 無品質檢查
- 可能陷入迴圈
- 無法從錯誤復原
- 重試效率低
2. 規劃者 + 執行者 + 驗證者模式
Section titled “2. 規劃者 + 執行者 + 驗證者模式”最適合： 生產系統、複雜工作流程、可靠性
- 分離的規劃、執行、驗證模型
- 具有驗收標準的結構化計劃
- 多階段品質檢查
- 智慧重試和重新規劃
請參閱： plan-execute-verify.md 完整實作
優點：
- 強大的錯誤處理
- 內建品質保證
- 清晰的關注點分離
- 生產就緒
缺點：
- 更複雜的架構
- 較高的初始開發成本
- 需要更多基礎設施
選擇正確的模式
Section titled “選擇正確的模式”| 標準 | 使用 ReAct | 使用計劃-執行-驗證 |
|---|---|---|
| 複雜性 | 簡單，3-5 步驟 | 複雜，5+ 步驟 |
| 品質需求 | 盡力而為即可 | 必須可靠 |
| 錯誤處理 | 可以人工介入 | 必須自動復原 |
| 成本敏感性 | 開發成本重要 | 營運可靠性重要 |
| 時程 | MVP、原型 | 生產系統 |
| 團隊經驗 | 學習 AI 代理 | 經驗豐富的團隊 |
- 覆蓋率： 成功審查的文件百分比
- 準確性： 正確識別的問題百分比（相對於人工審查）
- 完整性： 檢測到的已知問題類型百分比
- 精確度： 標記的問題中真實問題的百分比（非誤報）
- 執行時間： 審查 N 份文件的時間
- 成功率： 無錯誤完成的執行百分比
- 重試率： 需要重試的步驟百分比
- API 成本： 每份文件審查的成本
使用者體驗指標
Section titled “使用者體驗指標”- 節省時間： 相對於人工審查節省的小時數
- 使用者滿意度： 對報告品質的回饋
- 信任度： 未經驗證即接受的發現百分比
-
過度工程
- 不要對簡單任務使用計劃-執行-驗證
- 從簡單開始，僅在需要時增加複雜性
-
驗收標準不明確
- 模糊的標準導致驗證失敗
- 使標準可衡量且具體
-
忽略錯誤情況
- 並非所有文件都格式良好
- 處理 OCR 錯誤、損壞的檔案、錯誤的格式
-
進度追蹤不佳
- 沒有回饋會讓使用者焦慮
- 在每個步驟顯示進度
-
驗證不足
- 信任但驗證 - 即使是 AI 也會犯錯
- 盡可能使用確定性檢查
-
比較分析
- 比較同一文件的多個版本
- 追蹤隨時間的變更
-
範本合規性
- 對照公司標準範本檢查
- 確保存在必需的章節
-
風險評分
- 量化風險評估
- 補救措施的優先順序排序
-
整合
- 連接到文件管理系統
- Slack/email 通知
- 為問題建立 Jira 工單
-
從回饋中學習
- 儲存使用者更正
- 根據回饋微調模型
- 建立公司特定的知識庫
- ReAct 模式實作 - 簡單代理模式
- 計劃-執行-驗證模式 - 生產級模式
- Anthropic API 文件
- Claude 工具使用指南
本法律文件審查案例研究展示了核心 AI 代理概念：
- 自主性： 代理在沒有持續指導下運作
- 工具使用： 代理讀取檔案、撰寫報告
- 規劃： 代理將複雜任務分解為步驟
- 驗證： 代理驗證自己的工作
- 復原： 代理優雅地處理失敗
這些模式適用於法律審查之外的許多領域：程式碼審查、內容審核、資料分析、報告產生等等。