開完項目會錄音躺在文件夾里群里已經開始有人問“紀要呢”這類場面你可能比我更熟。以前我的做法是把錄音拖進播放器邊聽邊敲鍵盤一小時的會至少搭進去兩小時整理最后列出來的待辦還總是漏項等項目復盤時被問“當時不是說了要跟進嗎”只能尷尬翻錄音。后來我把 Octo-ASR 接進 OCTO 工作流讓語音轉寫自動跑完再由工作流里的 LLM 節(jié)點把口語化的流水賬整理成結構化會議紀要最后把待辦拆出來直接派發(fā)給對應的 Agent整條鏈路跑通之后會一開完任務清單基本就在工作臺上排好了。這篇文章就把這套用法完整拆一遍包括我接入時調過的參數、測試過的模型組合、踩過的一些坑以及最后的可擴展方向。如果你也在做 agent 相關開發(fā)尤其是想把“會上說的事”變成“系統里能執(zhí)行的任務”這套流程應該能給你不少可落地的參考。1. 先想清楚轉寫、紀要與派單分別解決什么問題很多人在搭這類系統時容易犯一個錯誤以為把 ASR 的結果丟給大模型直接就能輸出紀要并派單。我最初也這么干過結果發(fā)現中間省略了太多關鍵環(huán)節(jié)。Octo-ASR 輸出的是一段帶時間戳和說話人標簽的文本它并不理解“誰該對這件事負責”O(jiān)CTO 工作流里的 LLM 節(jié)點雖然能做歸納和判斷但如果輸入的文本太原始模型也會被口語中的冗余信息帶偏。所以第一步不是寫代碼而是把整條流程拆清楚。1.1 Octo-ASR只負責“轉寫”不負責“理解”O(jiān)cto-ASR 這類開源 ASR 工具的核心價值是“把聲音變成文字”。它做得好的地方在于語音識別準確率、說話人分離diarization和較長音頻的批量處理能力。但它有一個嚴格的工作邊界它不會判斷哪些內容是閑聊、哪句話是真正的決策、誰在分配任務。這些語義層面的工作Octo-ASR 完全不參與。我之前在測試時遇到過一種尷尬情況把會議錄音轉寫出來后文本里出現了“小劉你回頭跟客戶確認一下時間”這樣的句子。ASR 能準確識別出每個字也能標出這是“發(fā)言者 A”說的但它不會告訴你“這是一個待辦任務”。如果要讓系統自動把這條語句變成一條派發(fā)給小劉的待辦需要下游的 LLM 節(jié)點結合上下文去推斷這句話包含一個明確的動作確認時間、一個明確的負責人小劉因此符合待辦條件。所以Octo-ASR 在整條鏈路中的角色是一個“高質量原材料提供者”而不是最終的決策者。只要轉寫文本足夠干凈、說話人區(qū)分足夠準確后續(xù)的 LLM 節(jié)點才能有飯吃。這也是我后來在接入 OCTO 工作流時最強調的一點先把轉寫質量做扎實再談智能化。1.2 從轉寫文本到會議紀要OCTO工作流里真正干活的是LLM節(jié)點OCTO 工作流的定位是一個流程編排平臺它可以把多個節(jié)點串聯起來ASR 轉寫節(jié)點、文本增強節(jié)點、LLM 摘要節(jié)點、待辦提取節(jié)點、Agent 派發(fā)節(jié)點等。每個節(jié)點之間通過 JSON 傳遞數據節(jié)點各自處理一個獨立任務。以我的實現為例OCTO 工作流里跑的主要是三步ASR 節(jié)點把錄音文件轉成帶時間戳和說話人的純文本LLM 節(jié)點拿到這段純文本用固定的提示詞模板做信息抽取和摘要輸出一個結構化的 JSON里面包含會議主題、關鍵決議、行動項、負責人和截止時間路由節(jié)點根據 JSON 里的負責人字段把每一個行動項派發(fā)給對應的 Agent 實例Agent 再去做后續(xù)的日程提醒、消息推送或任務創(chuàng)建。這個架構看起來不復雜但每一步都有很多細節(jié)。尤其是第二步的 LLM 節(jié)點它的輸出格式如果不做嚴格的 JSON Schema 約束就會出現字段名不統一、待辦和風險項互相混淆的問題。我前面說“直接丟給大模型”不夠用原因也在這里大模型需要的是結構化任務的拆分而不是一次性自由發(fā)揮。所以在設計 OCTO 工作流時我建議把“紀要整理”和“待辦提取”拆成兩個節(jié)點而不是讓一個提示詞既做摘要又做任務分解。拆分的好處是每一段的任務更單純模型的表現也更穩(wěn)定。紀要整理節(jié)點負責把口語轉成有條理的會議概要待辦提取節(jié)點再基于概要找出所有包含責任人、動作和時限的句子形成待辦清單。這樣即使紀要節(jié)點出一個字段錯誤也不會拖垮待辦提取節(jié)點。2. Octo-ASR接入前的準備模型選型、音頻預處理與輸出格式接入 Octo-ASR 之前需要做三件事選模型、搞音頻、定輸出格式。這三件事看起來基礎但它們決定了后面所有環(huán)節(jié)的地基。2.1 模型選型先想好離線還是在線實時還是非實時Octo-ASR 有不同規(guī)格的模型可用大模型和小模型的識別準確率差異明顯但也要看你具體的使用場景。離線批量轉寫如果會議已經錄制完不要求實時字幕就用大模型。它的中文長音頻識別能力更強對專有名詞的容錯率也更高。我這邊跑一小時會議錄音離線批量模式大概用 5 到 8 分鐘左右完成轉寫具體耗時看 GPU 配置。在線實時轉寫如果要做直播字幕或實時紀要就得用輕量級模型配合流式接口。輕量模型在安靜環(huán)境下滿足日常使用但會議場景里的多人重疊發(fā)言容易亂需要額外做 VAD語音活動檢測和降噪處理。有一點容易忽略Octo-ASR 的模型對中文口語表達的優(yōu)化程度并不均衡。有些版本對英文表現很好但中文語速快、口音重時識別錯誤率會明顯上升。我在接入前專門拿了三場真實會議錄音做對比測試最后選了中文適配更好的模型底座把熱詞表加上之后人名和項目代號基本都能正確識別了。建議在接入之前先拿你所在團隊的真實會議錄音做一個基準測試而不是直接用默認模型上生產。因為每個團隊的專有名詞不同直接上線大概率會遇到識別率低的問題。2.2 音頻預處理采樣率、降噪和切分不能省Octo-ASR 對輸入音頻有一定要求常見的是 16kHz 單聲道 WAV。很多會議錄音原始文件是 48kHz 雙聲道直接喂給 ASR 雖然不會報錯但會造成特征提取不一致影響識別準確率。我在實測中遇到過一次同一段錄音用原文件轉寫和用先轉成 16kHz 單聲道再轉寫錯誤率能差 2 到 4 個百分點。預處理步驟大致是這樣用 ffmpeg 把音頻統一轉成 16kHz 單聲道 WAV做簡單的降噪處理去掉空調聲和風扇聲如果整段錄音很長先做 VAD 切分再分段轉寫。VAD 切分有一個實際意義它能把“無人說話”的空檔去掉避免 ASR 在靜音段產生幻覺文本。我遇到過最離譜的情況是一整段靜音被轉寫成了“會議開始”后面還帶了幾句編造的內容。后來我在轉寫前加了 VAD 過濾這類幻覺基本消失。關于切分的粒度我建議分段控制在 30 秒到 60 秒之間。太短會導致上下文丟失太長則容易在多人說話時互相串擾。Octo-ASR 本身支持長音頻但內部還是會做分塊處理你切分的邊界和它內部的邊界錯位時可能出現句子被攔腰截斷的問題。加了上下文重疊之后轉寫質量會更穩(wěn)。2.3 輸出格式直接影響下游解析成本Octo-ASR 的輸出一般支持純文本、SRT 字幕和帶完整元信息的 JSON。如果你只是自己聽錄音SRT 就夠了但如果要接 OCTO 工作流一定要用 JSON 格式。一個好的 JSON 輸出至少包含這些信息字段說明用途start句子開始時間秒便于回溯定位end句子結束時間秒便于回溯定位speaker說話人編號或名稱角色指代識別text轉寫文本供 LLM 分析confidence置信度分數用于過濾低質量轉寫低置信度的句子建議單獨標記出來不要讓它們混入正常的紀要素材。我之前試過把置信度 0.3 以下的句子也喂給 LLM結果模型把一段“嗯嗯嗯好的好”也總結成了“與會者表示同意”非常誤導。接入 OCTO 工作流時ASR 節(jié)點的輸出 JSON 會直接作為下一個節(jié)點的輸入。用 JSON 的好處是字段清晰后續(xù)的 LLM 節(jié)點提示詞里可以直接引用text和speaker不需要做額外的文本解析。3. OCTO工作流里的“會議紀要整理”節(jié)點轉寫文本到手之后下一步是把口語化的內容整理成會議紀要。這一步是整個流程中最容易被低估的環(huán)節(jié)。很多人以為只要把文本丟給大模型說一句“幫我整理會議紀要”就行但真實場景里模型會被各種干擾信息帶偏。3.1 提示詞模板要從“流水賬”中提取“五要素”我給紀要節(jié)點設計的提示詞不是簡單的“總結一下”而是要求模型從文本中提取五類核心信息會議主題與目標關鍵議題與討論過程最終決議行動項誰在什么時間前做什么遺留問題與風險。實踐下來效果比開放式總結穩(wěn)定得多。模型不需要發(fā)揮只需要做信息抽取和歸類漏內容的概率大幅下降。我的提示詞模板大概長這樣你是會議紀要助手。下面是一段會議轉寫文本包含說話人標簽和時間戳。 請?zhí)崛∫韵挛孱愋畔?1. 會議主題 2. 關鍵議題及結論 3. 明確決議 4. 行動項必須包含負責人、動作、時間限制如果有 5. 遺留問題與風險 要求 - 只基于文本中確有依據的信息不要補充原文沒有的內容。 - 行動項必須使用如下格式輸出負責人 | 動作 | 截止時間 | 原句摘錄。 - 如果某類信息為空請輸出 無。 - 輸出為 JSON不要使用 Markdown 表格。 轉寫文本 {asr_text}注意最后兩條要求很重要。很多第一次寫提示詞的人會忽略“輸出為 JSON”和“不要使用 Markdown 表格”結果模型返回一段富文本下游就傻眼了。我在 OCTO 工作流里給 LLM 節(jié)點配置了 Response Format 強制 JSON但提示詞里再寫一遍會更保險模型輸出更穩(wěn)定。3.2 說話人角色歸一化避免“小劉”“劉工”指代混亂真實會議里一個人可能有多種稱呼。上一句叫“小劉”下一句叫“劉工”再后來說“小劉總”。如果直接把說話人標簽帶入待辦提取會出現同一個人被拆成多個負責人的情況。解決辦法是在紀要節(jié)點里增加一步角色歸一化先讓 ASR 輸出每個說話人的編號比如speaker_0、speaker_1上一步之后用一個單獨的 LLM 節(jié)點根據上下文把每個說話人編號映射到實際姓名或角色在提示詞里指定一個已知團隊名單名稱列表讓模型在名單里選擇最可能的對應人。例如轉寫文本里出現“讓我們部門確認一下排期”而團隊名單里有“王明后端負責人”紀要節(jié)點就應該把這句話掛到王明的名下。這一步如果沒有做待辦派發(fā)時會出現“負責人小劉”這種讓下游 Agent 無法識別的名稱。我建議把團隊成員名單做成一個靜態(tài)配置文件放在工作流里作為上下文注入。名單字段不需要很復雜維護一個“常用稱呼到正式姓名”的映射表就夠了。團隊不大時用字典映射最直接團隊很大時可以讓模型根據歷史紀要學習稱呼歸屬。3.3 紀要去噪哪些內容可以丟哪些必須留會議錄音里的廢話比例通常不低。我在測試時發(fā)現一段 60 分鐘的會議錄音去掉寒暄、點外賣、閑聊和口頭禪之后有效內容常常不到 40 分鐘。如果這些干擾信息全部留給后面的待辦提取節(jié)點誤判概率會顯著上升。我的去噪策略分兩層第一層在 ASR 輸出階段把置信度低的句子標記為low_confidence紀要節(jié)點直接忽略這些句子不參與總結。第二層在 LLM 提示詞中明確告訴模型哪些內容不屬于紀要范圍。比如以下內容應被忽略 - 寒暄與閑聊如今天天氣不錯 - 口頭禪與重復語句如嗯嗯就是說 - 與會議主題無關的日常事務如中午吃什么 - 單純的附和如對是的這聽起來很基礎但真的能明顯減少紀要的篇幅和質量問題。模型在提取信息時會更有目標性不會把“下午三點前把方案發(fā)我”這種句子丟掉因為它在任務語句里。去噪還有一層深意它不是把信息丟掉而是把信息從“所有人說的一堆話”中分離出來。一個合格紀要的產出應該讓讀者只看紀要就能了解會議全貌而不用翻回原始轉寫文本。這是我在實際使用中體會最深的一點。4. 待辦提取與Agent派發(fā)最難也最容易出錯的一段紀要整理出來之后最核心的環(huán)節(jié)就是待辦提取與派發(fā)。這一步之所以難是因為它要求系統不僅能識別“這是一件待辦”還要能判斷“這件待辦該給誰、什么時候要做完、優(yōu)先級高不高”。4.1 待辦字段設計負責人、時限、優(yōu)先級、原句摘錄缺一不可我先設計了一個待辦的 JSON 結構后來在真實項目里不斷調整最終穩(wěn)定成了這樣{ id: todo-20250115-001, action: 確認客戶新版接口的接入時間, assignee: 王明, due_date: 2025-01-20, priority: high, source_text: 這個接口的時間王明你去跟客戶確認一下下周要定下來。, timestamp_start: 1523.4, timestamp_end: 1528.7, status: pending }字段看起來多但每一個都有實際用途source_text用于追溯派發(fā)給 Agent 后如果 Agent 執(zhí)行時需要看上下文可以隨時跳回原始會議文本甚至跳回錄音時間點。timestamp_start和timestamp_end用于對齊錄音團隊中有爭議時可以直接定位到會議上說的那一句話省去翻錄音的麻煩。due_date是提取出來的“軟時限”。如果原文說“下周之前”模型應該把它轉成具體的2025-01-20這樣 Agent 才能在排期里生成任務。在提示詞里我要求模型對每一條待辦都必須給出source_text。不給沒關系模型很容易編造出原文沒有的任務。加上原句摘錄之后每一條待辦都能在紀要里找到證據這是一個非常強的約束。4.2 從負責人到Agent實例的路由設計待辦提取完成之后剩下的問題就是“怎么把待辦交給正確的 Agent”。這里又分兩種思路。第一種是靜態(tài)路由在 OCTO 工作流里配置一個負責人到 Agent 實例的映射表。比如“王明”對應一個負責項目跟進的 Agent“李婷”對應一個負責日程管理的 Agent。待辦 JSON 的assignee字段直接查表找到對應的 Agent API 就把待辦推送過去。第二種是動態(tài)路由不配置固定映射而是讓一個調度 Agent 根據待辦的內容判斷該交給誰。這種方式更靈活適合 Agent 數量多、職責邊界不清晰的場景但會多一層推理開銷。我建議第一天先做靜態(tài)路由等到跑通了團隊也確實需要更復雜的分發(fā)邏輯時再上動態(tài)路由。原因很簡單動態(tài)路由一旦出錯你很難判斷是待辦提取的問題還是調度 Agent 的問題。而靜態(tài)路由邏輯透明任何一條派發(fā)失誤都可以直接看路由映射表排查。路由消息本身也有講究。不要把整個待辦 JSON 全部塞給 Agent應該按目標 Agent 的接收能力做裁剪。比如有的 Agent 是通過 Webhook 接收消息它只關心action和due_date那source_text可以放到附注里。如果 Agent 對接的是 IM 機器人可能還需要把待辦格式化成自然語言提醒你有一個待辦任務 內容確認客戶新版接口的接入時間 截止時間2025-01-20 優(yōu)先級高 來源會議2025-01-15 項目評審會這一步看似瑣碎但直接決定了 Agent 拿到消息之后能不能正確處理。我之前踩過坑把完整 JSON 發(fā)給一個只接受文本指令的 Agent結果它把所有 JSON 內容當作一條指令執(zhí)行鬧了笑話。4.3 派發(fā)確認與失敗重試沒有回執(zhí)的派發(fā)等于白派待辦派發(fā)之后工作流不能就此結束否則很容易出現“系統顯示已派發(fā)但 Agent 根本沒收到”的情況。我給派發(fā)環(huán)節(jié)加了三層保障ACK/NACK 回執(zhí)每個 Agent 在接收待辦后必須返回一個確認信號。收到 ACK 代表任務已經進入 Agent 自己的隊列收到 NACK 或超時未響應則觸發(fā)重試。有限重試重試次數我設置為 3 次間隔 1 分鐘、5 分鐘、15 分鐘遞增。重試超過 3 次后把待辦轉到一個“人工補發(fā)隊列”由運維人員或項目助理手動處理。對齊兜底定期用待辦列表與 Agent 內的任務列表做比對發(fā)現 Agent 側缺失任務就重新推送。這一步適合對系統性可靠性要求高的團隊。有了這三層保障派發(fā)才算閉環(huán)。第一次實現時我沒有加回執(zhí)結果有一場重要會議的 12 條待辦里有 4 條 Agent 根本沒收到沒有人知道。后來檢查日志才發(fā)現是 Agent 服務重啟時把隊列弄丟了。加入 ACK 回執(zhí)后這類問題在 1 分鐘內就能被暴露。5. 實測中的坑與調整從1小時錄音到全員收到任務流程搭好后我找了一場真實會議做了完整測試一場一小時左右的線上項目評審會參會 6 人最后轉寫文本約 7000 字。下面說說實測結果、參數調整以及幾個容易忽略的坑。5.1 實測數據轉寫、紀要與派發(fā)各用了多長時間這次實測的完整流程耗時如下環(huán)節(jié)耗時說明音頻預處理轉 16kHz VAD 切分約 20 秒用 ffmpeg 自動完成Octo-ASR 轉寫約 6 分鐘使用離線大模型GPU 環(huán)境下紀要去噪與整理約 40 秒LLM 節(jié)點處理 7000 字文本待辦提取約 10 秒獨立 LLM 節(jié)點Agent 派發(fā)約 5 秒靜態(tài)路由 ACK 回執(zhí)整個過程接近 8 分鐘。會議結束后我泡了杯茶回來Team 群里已經收到了任務提醒。這個速度當然不是“實時”但對于會議場景已經能接受。如果希望更快可以換成輕量模型加并行處理轉寫時間能壓到 2 分鐘左右代價是識別準確率略有下降。最終這場會議提取出 10 條待辦對照人工整理的原始錄音逐條核對準確檢出 8 條漏掉 1 條因為原句表述太模糊“那個事再跟進一下”沒有明確負責人和時限多提取 1 條把一句“要是沒事的話就可以先這樣”誤判成了結束時間確認后來靠低置信度過濾和二次校驗攔住了。5.2 多人同時說話時轉寫錯亂用 VAD 和聲紋分離緩解線上會議最常見的坑是多人同時開麥ASR 對重疊語音處理得很吃力。Octo-ASR 的說話人分離是基于聲紋特征做的同一聲源若被壓縮得太厲害會頻繁切換說話人標簽。我實測中遇到過一個案例兩位同事同時講話轉寫結果被 ASR 識別成 5 個不同的說話人同一人在一句內來回切換身份標簽標簽之間沒有邏輯關聯。我的處理方案是在轉寫前做更細粒度的 VAD 切分只保留能量較高的語音段讓重疊部分盡量各自獨立若實在無法區(qū)分在 ASR 輸出中標記為overlap并在紀要節(jié)點中讓模型忽略這些片段避免它們對紀要產生干擾。這個方案能一定程度緩解問題但要徹底解決還是得從硬件出發(fā)。有條件的話給會議室裝一個全向麥配合每個座位的獨立麥克風陣列轉寫質量會上一個臺階但成本也高。預算有限就先在軟件層做過濾。5.3 “回頭再說”“之后同步”被誤判成待辦閾值和二次校驗雙重控制ASR 轉寫后的文本里“回頭再說”“之后再同步給你”這類模糊語句出現頻率極高。LLM 提取待辦時很容易把它們當成行動項產生大量無效待辦。我加了兩個控制手段。第一個手段是置信度閾值在待辦提取節(jié)點中要求模型輸出的待辦必須滿足“明確負責人 明確動作”兩個條件模糊語句直接跳過。沒有通過這兩個條件的一律不輸出。第二個手段是二次校驗新增一個校驗節(jié)點用獨立的提示詞重新審視待辦列表以下是提取出的待辦清單。對于每一條待辦請檢查 1. 原句中是否真的包含負責人 2. 原句中的動作是否明確“回頭再說”不算明確動作 3. 如果只有負責人的稱謂但對任務描述模糊請標記為“需要人工確認”。二次校驗比直接提取的準確率提升很多因為它相當于用另一個視角重新審了一遍本質上是“多重采樣一致性”的簡化版。之前沒有加校驗時誤判率達到 15% 左右加上之后降到了 4% 以內。5.4 模型幻覺出的假任務最小校驗鏈路必須要有大模型在處理長文本時偶爾會“腦補”。我在測試中遇到過一條不存在的待辦模型把“如果方案的接口不穩(wěn)定我們再想備選方案”提取成了“備選方案需要評估”但實際原文是討論假設情況并不是安排任務。還有一次模型憑空造了一個負責人名字原文根本沒有這個人出場。應對幻覺任務我總結出三個做法用source_text強制綁定每一條待辦沒有原句摘錄的待辦直接丟棄在提示詞里明確寫“只基于原文不要補充任何原文沒有的信息”對置信度低的句子在待辦提取之前就過濾掉防止模型基于低質量文本進行推斷。這三個做法單獨拿出來效果有限但疊加起來能有效降低幻覺概率。我還是那句話盡量不給模型自由發(fā)揮的空間讓它做抽取而不是做創(chuàng)作。6. 這套流程還能往哪些方向擴展如果這套會議紀要和待辦派發(fā)的鏈路你已經跑通了可以先別急著收工。我接下來打算把 OCTO 工作流往周邊場景延伸這里一并分享三個階段。6.1 第一階段把會議紀要同步到知識庫和項目空間會議紀要生成后可以直接推給企業(yè)的知識庫系統自動歸類到對應項目目錄下。這樣后期查找信息時不用在 IM 聊天記錄里翻找直接去知識庫搜索就行。同時紀要和待辦可以關聯到項目管理工具里讓每條待辦自帶“會議來源”屬性方便項目復盤時回溯決策過程。這個階段的核心仍然是把數據格式整理干凈。所以前面設計的 JSON 結構在擴展時能直接復用。6.2 第二階段讓Agent帶著記憶執(zhí)行待辦如果把待辦只發(fā)給 Agent 就算完那是比較淺的用法。更有意思的是讓 Agent 具備記憶能力在多次會議之間積累上下文。比如這次會議提到“客戶接口尚未確認”下一次會議又提到“接口確認了”Agent 如果能讀取歷史記憶就會知道這個待辦已經閉環(huán)不必再次提醒。關于 Agent 的記憶體系短期記憶當前會議、中期記憶最近幾周的待辦、長期記憶項目歷史決策記錄是可以拆開做的。短期記憶直接存在工作流上下文里中期記憶存成任務列表長期記憶則可以讓 Agent 定期把歷史紀要里的重要結論寫入向量庫。這樣 Agent 在接到新待辦時可以通過語義檢索找到以前的關聯決策執(zhí)行起來更準。6.3 第三階段多Agent協作時把路由升級為動態(tài)調度當 Agent 數量增多靜態(tài)路由的映射表會變得很難維護。此時可以考慮引入一個調度 Agent它讀取待辦內容結合所有 Agent 的能力描述決定由誰執(zhí)行甚至可以把一條大任務拆成多個子任務分派給不同 Agent。這其實就是吳恩達在多 Agent 課程里講的“三明治架構”在具體場景里的實踐。不過我還是那個建議先靜態(tài)、后動態(tài)。第一版系統不需要追求花哨穩(wěn)定性是最重要的。等到你手里有三個月以上的真實數據知道各類待辦實際會被哪些 Agent 正確處理了再做調度決策才有依據。最后說一個我個人的體會會議紀要自動整理這件事技術難點不在 ASR也不在 LLM而在流程設計與提示詞約束。你要讓模型在明確邊界內做抽取而不是給它無限的自由度要讓每一步輸出都可追溯而不是黑盒一鍋燜。先把 Octo-ASR 的轉寫質量調到能接受的水平再把 OCTO 工作流里的節(jié)點拆細、提示詞寫嚴最后的派發(fā)環(huán)節(jié)加上回執(zhí)和重試這套流程在大部分團隊里都是可以落地的。如果時間有限建議先只做“轉寫 待辦提取”不要一上來就追求全套自動化。我見過很多項目是因為步子邁得太大最后卡在 Agent 派發(fā)的可靠性上連基礎的前兩步都沒用起來。一步步來比什么都快。