Agent 可以干活，但誰來簽字？

有人把光標停在新增的 constraint 上，問了一句：“這條 false path 的功能依據是什么？誰批準的？相關 mode 和 corner 都檢查過了嗎？”

屏幕上沒有紅色錯誤，房間卻突然安靜了。

Agent 已經把分析、修改、重跑和匯報都做完了。麻煩恰恰在這里：它沒有把這條 path 修快，而是改變了它是否需要參與時序分析。它動的不只是一行配置，還動了“什么結果算對”的判斷邊界。

這條候選 exception 能不能進入正式約束集？現有證據夠不夠支撐正式結論？如果幾個月后，它遮住的恰好是一條真實功能路徑，誰能還原當時為什么這樣改，誰又負責把規則修回來？

這里先約定兩個詞。調用 signoff 工具、完成分析并形成結果與證據，本文稱為簽核分析與證據；允許修改進入 golden database、讓 waiver 或 ECO 正式生效、允許項目 release 或 tapeout，稱為正式放行。題目里的“簽字”指的是后者：一個結果憑什么從 Agent 的輸出，變成項目可以據此繼續往下走的工程結論？

能力自主回答 Agent 能不能理解狀態、規劃步驟、調用工具、處理失敗并推動任務收斂。生產授權回答它可以讀什么、改什么、執行什么，以及哪一種結果可以進入正式狀態。

前者是系統能力，后者是組織決定。能力提高，不意味著權限自動擴大；證據準備完成，也不意味著結果自然生效。

L1-L5 目前不是統一的行業成熟度標準，而是廠商借用自動駕駛的分級習慣，描述能力演進的路線圖。粗略的共同方向是：L1 做單點優化，L2 做對話或單步動作，L3 處理復雜推理或多 Agent 協作，L4 跨工具編排并根據反饋調整 workflow，L5 則嘗試從高層目標出發，自主規劃、執行、評價和迭代，以較少人工介入走向經過驗證的結果。這只能幫助我們看方向，不能把各家的數字直接橫比。

更大的問題是，L5 把許多并不等價的能力壓進了一個標簽。真正評估一個所謂 L5 Agent，至少要拆開六件事：任務范圍覆蓋一個 violation、一個 block，還是完整項目；行動時長是幾十步、數小時，還是跨周運行；環境開放度是在固定工具和 flow 里行動，還是能夠重組工具與流程；恢復能力是按原計劃重試，還是能識別策略失效并改計劃；泛化范圍是否跨設計、項目、PDK 和工具版本仍然成立；評價與證據能力能否判斷結果、暴露缺口，并生成可回放、可審計的工程證據。

這六項組成的不是一頂“L5 皇冠”，而是一張能力包絡。一個 Agent 可能在固定 PDK 和既定 flow 里，從目標一路跑到驗證結果；一旦換項目、工具報錯或 evaluator 失去判別力，就必須找人。市場材料可以把前半段稱為 L5，生產團隊卻需要看到后半段。

這也是為什么沒有必要再發明 L5.1、L5.2。繼續細分一根刻度，仍然會把多維能力偽裝成一個總分。更實用的問法是：它在哪個任務范圍、哪類環境和多長時間里保持自主？遇到什么失敗會停？拿什么證據證明結果？

Cadence 已經宣布 ChipStack “達到 L5”，覆蓋從 specification 理解、RTL、驗證規劃到 formal、simulation、debug 和收斂的復雜 workflow；但官方仍保留工程師的監督、介入和 final signoff，相關能力按發布計劃在 2026 年下半年進入 early access。Synopsys 則把 L5 稱為“預測的終態”，工程師仍要監控決策理由，并在 checkpoint 做 decision validation。Siemens 沒有套用同一張五級表，而是強調 domain-scoped autonomy、權限控制、審計軌跡和 human checkpoint。

這些材料足以說明 IC Agent 正從 copilot 走向有邊界的多步 workflow，卻還不足以證明已經出現跨設計、跨項目、跨工具環境穩定工作的通用 L5 虛擬工程師，也沒有公開證據表明 Agent 已經無人介入完成真實生產 tapeout。

更關鍵的是，能力包絡仍然沒有回答生產授權：哪些正式狀態可以被修改，什么結果可以生效，異常時由誰接管，最后由誰承接后果。前者描述 Agent 有多大本事，后者決定組織敢把什么交給它。

說到這里，一個很自然的反駁是：人又不比 Agent 神圣。工程師也會漏看 corner，也會簽錯 waiver。deadline 壓上來時，人一樣可能看著綠色 dashboard 草率放行。相反，Agent 可以更完整地跑檢查，更穩定地保存 trace，也可能比人更早發現跨工具結果里的矛盾。既然如此，為什么一定要保留一個人簽字？

這個質疑成立了一半。對規則清楚、影響有限、錯誤容易發現的動作，確實沒有理由永遠保留逐項人工點擊。否則，所謂 human-in-the-loop 很快就會變成昂貴的流程裝飾。

另一半應該追問的，是錯誤發生以后，決策權和后果怎樣重新接上。誰定義檢查范圍和風險容忍度？誰批準 evaluator 和例外規則？證據互相沖突時，是繼續、回退，還是停手補證？真出了問題，誰能解釋當時為什么允許這條路徑生效，并把事故變成下一版 policy、regression guard 和 evaluator？

這些事情可以越來越多地由系統輔助，卻必須在組織里找到承接位置。否則，能力是自動化了，決策權和后果之間的關系卻斷了。

所以，說得直白一點，Agent 可以干活，但在今天的工程組織里，它還不能成為最終責任主體。這不是在維護人的特權。簽字的意義不是宣告“這個人一定正確”，而是把決策權、事故處置權和后果承接綁到明確的組織角色上。

將來，權責綁定的方式當然可以變化：低風險動作可以由預先批準的 policy 自動放行，高風險動作也可能逐漸由系統承擔更多判斷。可無論界面上還剩不剩那個按鈕，邊界由誰定義、例外由誰接受、事故由誰接住，都不能懸空。

今天討論 IC Agent 的自主度，最常見的問法是：“它的準確率夠不夠高？”準確率重要，但只看一個平均數，很容易把生產風險看扁。一個系統做對了 99 次，第 100 次錯在哪里，可能比 99% 這個數字更重要。錯誤會在下一輪 regression 里立刻暴露，還是要等到流片后才知道，風險完全不同；改動留在可回滾的分支里，還是直接寫進 golden database，風險也不同。

我更愿意用一塊短板來理解可授予的自主度：

這個公式不是用來算小數點的，只是一張部署前的短板檢查表。能力可信度問的是：在相似的設計、工具和約束條件下，它能否穩定完成任務。證據可審計性問的是：輸入、工具版本、動作、理由和結果能不能被還原，所需證據有沒有缺項。失敗可發現性看錯誤會在什么時候、通過什么信號暴露。影響可控性看權限邊界、隔離環境和 blast radius，也看動作能否撤回與回滾。責任可承接性則問：誰維護規則、處理例外、響應事故并更新系統。任何一塊接近零，授權都很難繼續往前走。

同一個 Agent，讀取 report、歸類 failure 時，錯誤容易復核，權限可以放寬；在獨立分支生成 patch 并跑回歸，因其可回滾，也可以嘗試更高自主度。可一旦觸碰 golden constraint 或 waiver，它就在改變“什么算對”，授權必須收緊。到了 tapeout 放行，后果大、反饋晚、難以逆轉，證據和責任門檻最高。

通用 Agent 的工程實踐也在往這個方向靠。OpenAI 的 Agent 構建指南建議按照 read/write、可逆性、所需權限和潛在影響給工具動作分級；Anthropic 則把部署風險拆成失敗概率和 blast radius，并明確區分 read-only access 與 write-to-production 權限。

把這套通用 Agent 經驗映射到 IC flow，是本文的推論。結論仍然很直接：不要給“這個 Agent”整體封一個永久官職，權限應該按動作授予。

如果把某個動作所需能力放在橫軸，把它獲得的生產權限放在縱軸，就會得到一張二維矩陣。橫軸不是 L1-L5 總分，而是能力包絡針對這個動作的簡化投影：從單步分析走到多步規劃，再到長程自主閉環；縱軸則從只讀、建議、監督執行走到有界自治。正式放行門放在矩陣之外，因為它回答的是另一件事：結果什么時候可以進入 golden database、release 或 tapeout 決策。

這是本文用來分析生產授權的框架；行業目前尚未形成這樣的統一標準。圖上的每個動作都要單獨落點：能力很強的 Agent，在修改關鍵約束時可能只有建議權；能力并不驚艷的 Agent，在邊界清楚、反饋很硬的 regression triage 上，反而可以進入有界自治。

還是回到開頭那條 false path。

Agent 可以讀取約束、timing report、netlist 和歷史 issue，指出這條 path 可能不該計入，并列出依據與證據缺口。但它不能修改 constraint，也不能把判斷寫進正式數據庫。

這一檔看起來保守，卻很適合進入生產。它可以把散落在 spec、report 和歷史記錄里的信息找齊，把事實、推斷和待確認項分開。只讀仍有敏感數據、錯誤檢索和誤導性總結等風險；但相較于寫入生產狀態，它的影響半徑清楚得多。

Agent 不只指出問題，還會生成 constraint diff 和驗證計劃：為什么建議 false path，會影響哪些 mode 和 corner，需要補跑哪些 STA、formal 或 regression，如果判斷錯了最可能漏掉什么風險。

候選與正式狀態必須隔離。Reviewer 可以拒絕，也可以要求補證。最不該出現的交互，是把一組會改變判斷邊界的修改塞進“一鍵接受全部”。

很多生成式 IC Agent 會先停在這里。它能寫 patch、assertion、test、waiver 和 ECO 候選，已經很有價值；可“建議得不錯”和“可以直接生效”之間，還差著授權與驗收。

第三種是監督執行。

Reviewer 批準 constraint diff 以后，Agent 可以把它寫入隔離分支，調用 STA 和回歸工具，對比修改前后的結果，最后生成一個可回滾的變更包。

批準應該發生在改變邊界的動作之前，流程跑完后再補簽已經太晚。系統要保留誰批準了哪個 diff、使用了什么工具版本和配置、前后指標如何變化、哪些 failure 消失了、哪些新風險出現了，以及回滾點在哪里。

人需要批準一個帶上下文的動作，而非流程跑完以后的一張綠色截圖。

第四種是有界自治。

在預先批準的 sandbox、分支、工具、資源和風險預算內，Agent 可以連續嘗試候選修復，重跑規定的檢查，用 evaluator 淘汰不合格方案，并保留完整 trace。大多數安全動作不再逐次彈窗找人。

但停止條件必須比“遇到問題再說”具體得多。例如：觸碰 golden constraint、waiver 或受保護目錄；不同證據相互沖突；超過重試、時間或算力預算；timing 改善卻引入新的 hold、功耗、擁塞或 coverage 風險；現有 evaluator 無法判斷。

發生這些情況，系統就主動升級給指定角色，避免把發現異常寄托在一個忙著趕項目的人身上。

這四種是動作授權，不是一條所有任務都必須逐級晉升的成熟度階梯。同一個 Agent 可以在 failure triage 上有界自治，在 constraint 修改上只有建議權，在 ECO 執行上需要監督。

然后，才輪到矩陣之外的正式放行門。Agent 可以把門前的工作做得很深：編排 signoff 檢查，交叉核對工具結果，整理 rule deck、工具版本、waiver、未覆蓋風險和證據包，識別缺項，并提出 go/no-go 建議。

但“證據準備完成”和“允許結果正式生效”仍是兩件事。對低風險、規則穩定的動作，組織可以通過預先批準的 policy 讓結果自動生效，不必為每次運行保留人工點擊。問題因此上移了一層：這套 policy 由誰批準，適用于哪些設計與工具版本，什么時候失效，什么異常必須升級？

對 tapeout 這類高后果動作，目前的公開材料并沒有把最終批準權交給 Agent：Cadence 明確保留工程師的 final signoff，Synopsys 和 Siemens 也仍然設置 decision validation、human checkpoint、權限與審計機制。未來邊界可能變化，但變化的方式不會是“Agent 會調用 signoff 工具，所以自然獲得放行權”。

Foundry certification、reference flow 和 qualified rule deck 也提醒我們，正式信任建立在一整套組合上：工具、工藝文件、規則、版本、設計數據、waiver、方法學和組織驗收。某個 solver 顯示綠色，只是其中一環。

Agent 可以成為很強的 signoff assistant。Signoff authority 則必須被明確授予。

看到這里，最省事的方案似乎是：關鍵動作全部讓人確認。可確認框本身并不會生產判斷力。

Anthropic 在 Claude Code 的真實產品數據中觀察到，用戶批準了大約 93% 的 permission prompts；提示越多，人們投入到每次提示里的注意力越少。通過 sandbox 和更硬的環境邊界，permission prompts 可以減少 84%。這組數字來自軟件 Agent，當然不能直接外推成 IC 工程師也會批準 93% 的動作。但它至少說明，審批信號一旦過密，注意力會被迅速稀釋。

Google Cloud 的 MCP 安全文檔也明確提醒：即使每個動作都由人批準，用戶仍可能因為過度信任、來不及充分驗證而放過危險動作。

IC flow 甚至更容易出現這種“橡皮圖章”。Agent 走了幾十或幾百步，評審者只看到最后一頁摘要；評審者沒有參與中途的關鍵分叉，臨時重建上下文的成本很高；項目 deadline 又讓“先點了再說”變成一種現實選擇。綠色 dashboard 很醒目，沒覆蓋到的風險卻通常沒有顏色。

有效監督至少要滿足四個條件：審批者看得到關鍵路徑、替代方案和被排除項；有時間和專業能力理解風險；有真實的停止、回滾和補證權；介入發生在修改約束、寫入正式狀態或不可逆動作之前。

成熟的人機協作不該讓所有動作都來找人。大多數安全動作應該在硬邊界里自動進行，只有異常、沖突和高后果決策被升級給真正能拍板的人。

人的注意力不應耗在審批每一個動作上，而要留給異常、沖突和不可逆的決定。

標題問“誰來簽字”，容易讓人想到最后那個名字。真實的生產系統里，責任很少只落在一個人身上。下面是本文為了分析責任承接做的職責拆分，不是行業固定崗位；不同公司可以由同一個人兼任，也可以分給多個團隊。

• 邊界負責人（Policy owner）定邊界。
  

哪些動作可以自動執行？Agent 能訪問哪些目錄、數據庫、工具和算力資源？哪些風險、成本和不確定性超過閾值以后必須升級？

• 部署負責人（Flow owner）對部署負責。 

Agent、工具、數據和 evaluator 怎樣組合？版本變化以后怎樣重新驗證？權限、trace、回放和 rollback 是真的可用，還是只寫在架構圖里？

• 放行負責人（Release / Signoff owner）讓結果生效。
  

證據有沒有達到項目門檻，waiver 和殘余風險能不能接受，項目是否可以進入下一階段、release 或 tapeout？

• 事故負責人（Incident owner）在出事后接住。 

誰凍結 flow、保全 trace、定位 failure、通知相關團隊并決定 fallback？誰再把事故更新成下一版 policy、evaluator 和 regression guard？

低風險動作可以沿用前面批準過的 policy；邊界、放行權和事故處置則必須找到明確的承接位置。

NIST AI Risk Management Framework 把風險決策、human-AI role、獨立評估、override、incident response 和 recovery 都放在組織治理中。它不是 IC signoff 標準，但提醒我們：責任鏈天然不是一個模型字段，也不能靠一句“human in the loop”自動生成。

放到 Agentic EDA 的生態里，這條責任鏈還要跨公司。Design House 需要說清第三方 subagent 可以訪問哪些數據、調用哪些工具、執行哪些動作；EDA 公司則要說清工具和模型版本、證據輸出、異常升級與 incident support。客戶的總控 Agent 調用第三方專業 subagent 以后，雙方還要約定輸入輸出、版本兼容、升級條件和事故處置。

這里先不討論出了事故誰賠錢，只問一個更基礎的工程問題：當系統說“完成了”，誰擁有足夠的信息、權力和行動義務，把這個結論接下去？

如果 Agent 只負責生成候選，客戶購買的主要是效率：同樣的時間里，多出幾份 patch、多跑幾輪探索、少花一些人天。一旦 Agent 進入真實生產閉環，客戶還會購買另一種東西：我為什么敢讓它行動？

這里說的“可授權性”，指一項能力能夠在明確權限、可審計證據、異常升級和責任承接下進入生產。它遠不止在模型外面多包一層安全話術。

開放 API 或 MCP 會讓客戶的總控 Agent 更容易調用第三方工具，但接口開放不等于工程經驗也被完整開放。啟動仿真、讀取 report 可以標準化；怎樣選求解策略、寫約束、區分 design bug 和 constraint bug、組織 rerun 和簽核證據，通常不會隨著底層 API 一起自動轉移。

MCP 主要解決“能不能接上”，專業 subagent 還得解決“能不能用深，并交付可審計、可驗收的結果”。這正是專業 EDA 公司相較于通用模型和只做上層編排的公司的一處潛在優勢。Tool-native Agent 更容易拿到有效輸入、可恢復狀態和硬反饋；長期積累的 rule、engine、verification know-how 和 signoff 方法學，也更有機會被封裝成 evaluator、guardrail、失敗分類、修復路徑和證據接口。

但這個優勢不會自動兌現。一個工具即使算法很好，如果只能輸出難以解釋的結果，沒有結構化 API，沒有穩定的 checkpoint、版本記錄、權限邊界和 incident support，客戶依然不敢把更大的動作交給它。

所以，EDA 公司下一階段賣的不只是 Agent 能力，還包括客戶敢于授權這套能力的理由。

更可能出現的格局，不是客戶自研總控 Agent 和 EDA 廠商 Agent 二選一。Design House 掌握項目上下文、總控權和最終授權；EDA 廠商則通過專業 subagent，去占住客戶難以在短期內復刻的判斷節點。工程師的位置會轉向定義邊界、審查異常、維護 evaluator，并在證據仍不充分時承擔關鍵判斷。

近期一篇關于 Agentic EDA 的預印本，以 handoff validity 為組織原則，再用 handoff contract 寫清下游的接收條件、適用假設和所需證據。這是研究框架，不是行業標準；它討論的也是有效交接，并不等同于正式授權。

這張授權卡沿著這個方向再追問兩步：誰允許動作發生，誰有權讓結果生效。它不要求團隊先建一套龐大的治理平臺，先選三個高頻動作就夠了，比如讀取 timing report、修改約束、執行 ECO。不要問“這個 Agent 能不能自治”，給每個動詞單獨填一張卡：

把這三個動作的卡填完，也比籠統宣布“我們已經 human-in-the-loop”更接近生產。

再回到開頭那條 false-path constraint。Agent 能否發現 violation、提出修改并重跑流程，屬于能力問題。這份結果能不能進入項目，還要看它有沒有修改約束的權限，證據是否覆蓋相關 mode 和 corner，異常有沒有升級，正式結果最后由誰放行。

人不必手工推動每一步，也不該被留在最后充當橡皮圖章。隨著低風險動作進入有界自治，人的點擊會減少，policy、evaluator 和責任鏈卻必須比過去更清楚。

Agent 會拿走越來越多執行動作，但工程責任不會跟著按鈕一起消失。Agent 可以越來越像一個獨立工程師，生產系統卻不能靠“像”來建立信任：哪些動作獲得了授權，結論憑什么成立，遇到例外由誰接住，都得寫清楚。

最后留一個問題：在你現在的工作里，哪一步你已經愿意交給 Agent 自主完成，哪一步仍然必須經過正式批準？為什么？

*免責聲明：本文由作者原創。文章內容系作者個人觀點，路科驗證轉載僅為了分享與討論，不代表路科驗證對該觀點贊同或支持，如果有任何異議，歡迎聯系路科驗證。