最近在展會上看到一類很有意思的產品：它們不再只說自己能寫文案、做簡報或產生程式，而是開始談從一句需求走到硬體原型、工程資料、打樣甚至測試。這讓我重新想了一件事：當 Agent 開始碰到實體世界，什麼才算完成？
在純數位工作裡，我們很容易把模型輸出的文字、程式碼或設計稿當成成果。就算它還需要修改，至少交付物看起來很清楚：一份文件、一個 commit、一張圖。但一旦工作往物理世界延伸，答案本身就不再是終點。它只是讓後續工程流程得以開始的一筆輸入。
從「生成答案」走向「推進狀態」
想像一個產品需求被交給 Agent。它可以幫忙拆解功能、整理規格、產出初版 BOM、提出採購條件，甚至依照既有元件庫畫出原型方案。這些能力當然有價值，但它們都還只是提案。
真正的工程工作，會從這裡才開始：
- 這份 BOM 用的是哪一版元件規格？
- 有哪些料件交期不穩、已停產，或缺少替代料？
- 設計變更後，電路、機構、韌體與測試項目是否同步更新？
- 打樣失敗時，失敗的是假設、參數、供應商能力，還是測試方法？
- 哪些變更可以由系統自動套用，哪些一定要由工程師簽核？
這些問題沒有一個是「再問模型一次」就能解決的。因為它們處理的不是語言流暢度，而是狀態、版本、相依關係與責任。
我認為這會是下一階段 Agent 產品很重要的分水嶺：它不再只是回答得像不像專家，而是能不能把工作從一個可驗證狀態，安全地推進到下一個可驗證狀態。
實體世界最不接受「大致正確」
文字草稿有錯，可以改。程式碼出問題，至少還能透過測試、版本控制和回滾處理。可是到了實體產品、工廠設備、採購與生產，錯誤往往會累積成時間、成本與安全問題。
一個不精確的料號，可能讓採購追到錯的供應商；一個沒有同步的版次，可能讓現場拿著舊圖施工；一個看似合理的排程建議，可能忽略設備保養、換線限制或品質放行條件。
所以，Agent 進入這些領域時，最危險的不是它「不夠聰明」，而是系統把它的輸出誤當成已驗證的事實。
我會把 Agent 的產出至少分成四種狀態：
- 建議：根據已知資料提出方向，但還沒有形成正式規格。
- 草稿：已填入既有欄位或文件結構，可交由人審閱與修改。
- 待驗證變更：已影響到料件、圖面、排程、製程或設備參數，必須進入檢查流程。
- 已核准版本：有明確責任人、依據、時間與適用範圍，才能成為後續工作的基準。
這個分層聽起來不炫，但它比「讓 Agent 自主完成任務」更接近企業真的需要的能力。因為企業不是缺少建議，而是缺少能把建議安全轉成可執行工作的機制。
Agent 的上下文，必須長成工程系統的一部分
很多人談 Agent，第一個想到的是工具呼叫或模型選擇。但當它要參與工程與製造流程時，最重要的往往是上下文從哪裡來，以及能不能被追溯。
一個可靠的工程 Agent，至少要知道：
- 需求文件與設計規格目前的有效版本；
- 元件、物料、替代料與供應商資料的權威來源；
- 變更單、測試紀錄、不良原因與現場回饋如何互相連結；
- 哪些資料可以查閱、哪些可以提出草稿、哪些行為必須經過核准；
- 一旦結果不如預期，如何把失敗重新沉澱成下次可用的規則。
這代表 Agent 不該漂浮在工程系統之外，當一個很會說話的旁觀者。它應該連進需求管理、版本管理、BOM、品質、採購與製造紀錄之間，但每一步都保留原始來源與責任邊界。
換句話說，Agent 的記憶不能只是一串對話摘要。它需要的是一張能回答「為什麼這樣做、根據哪一版資料、誰核准過、後來結果如何」的工程關係網。
真正的閉環，是讓失敗回到下一次決策
我特別在意打樣、測試與現場異常這一段。很多 AI 展示停在「幫你產出一個方案」，但工程價值其實藏在方案被現實打臉之後。
如果樣品失敗，只留下「測試不過」這四個字，下一輪 Agent 再怎麼聰明，也只能重新猜一次。但如果系統能留下失敗條件、實測值、替代方案、調整過的參數與最終決策，下一次它才有可能做出比上次更可靠的建議。
這也是我認為 AI 導入工程與製造時，不能只看首次展示效果的原因。一次生成漂亮的規格，證明的是模型有能力組織資訊；能把需求、變更、驗證與失敗經驗串成閉環，才證明系統真的開始累積工程能力。
先把 Agent 放在會被驗證的位置
如果要開始做，我不會一開始就讓 Agent 直接下採購單、改設備參數或覆蓋正式圖面。比較務實的切入方式，是先讓它站在一個「有價值，但會被驗證」的位置：
- 幫工程師從歷史問題與規格中整理初版需求；
- 幫採購列出可能有風險的料件與替代方案；
- 幫品質人員串起批次、測試與異常紀錄；
- 幫主管把變更、卡點與決策項目收斂成可追蹤的工作清單。
這些任務的共同點是：Agent 可以減少搜尋、整理與初步判讀的負擔，但最後仍回到既有的工程驗證與責任流程。等到資料品質、規則與回饋紀錄足夠穩定，再逐步擴大它能推進的範圍。
當 Agent 開始碰到實體世界，我們不能再只問它能不能做出答案。更重要的問題是：它產生的東西，能不能被版本化、被驗證、被追責，也能在失敗後讓下一次決策變得更好。
答案不是交付物。能持續往前、也能安全回頭的工程狀態，才是。