Agent 時代真正被改寫的，不是模型能力，而是 software 的抽象邊界
最近一直在思考一個問題：為什麼大家討論 AI agents 時，焦點總是放在「模型變強了多少」，而不是「software 本身發生了什麼事」。
嚴格來說，這兩件事的尺度完全不同。
傳統 software 的抽象邊界是什麼
在 agent 出現之前，software 的 abstraction boundary 非常清晰：function signature 定義輸入輸出，API contract 定義服務邊界，資料型別定義了什麼能進、什麼能出。工程師的工作是在這些邊界裡面寫邏輯，這個世界是確定性的。
你呼叫一個函式，它做一件事，你知道它會做那件事。這是整個現代 software engineering 的基礎假設。
Agent 把什麼東西提升成了一級工程元素
現在這個假設開始鬆動了。當你在系統裡引入一個 LLM-based agent，幾件事情同時發生：
prompt 變成了程式邏輯的一部分。 以前 prompt 是 UX 問題，現在它決定 agent 會不會做對事情。你要 review prompt 就像 review code，版本控制、測試覆蓋、regression testing 都得跟上。
tool schema 變成了介面契約。 Agent 透過 function calling 操作外部工具，tool 的描述方式直接影響 agent 會不會呼叫它、怎麼呼叫。這不是「寫好文件」的問題，這是 API design 的問題。
memory 和 policy 變成了系統狀態的一部分。 傳統 stateless 服務很好測，因為相同輸入保證相同輸出。但 agent 有 context window、有 working memory，它的行為取決於整個 session 的歷史。這讓測試和 debugging 的複雜度直接跳升一個量級。
驗證方式的根本性轉移
這才是我覺得最被低估的部分。
傳統 software 的驗證方式是 unit test + integration test。你寫測試案例，跑過就 ship。這在確定性系統裡完全夠用。
Agent 系統是 probabilistic 的。相同的 input，在不同的 context、不同的 temperature 設定、不同的模型版本下，可能給你完全不同的行為。傳統 test suite 根本抓不住這種漂移。
所以整個 verification 的重心必須轉移：
- 從「這個 function 對不對」→「這個 agent 在各種 edge case 下的行為分佈合不合理」
- 從「有沒有 crash」→「有沒有做到我希望它做的事，同時有沒有做到我不希望它做的事」
- 從「unit test coverage」→「behavioral coverage + guardrail coverage」
Observability 也跟著改變。以前你 log 函式的輸入輸出，現在你要 log agent 的 reasoning trace、tool calls 序列、memory 狀態，才有辦法在出事的時候搞清楚為什麼。
這個轉變的規模
我研究 LLM 的 hallucination，每天都在思考模型層面的問題。但說實話，模型層面的進步是漸進的，而 software 工程方法論的斷裂是突然的。
這有點像從過程式程式設計轉到物件導向，或者從 on-premise 轉到 cloud-native 的那種感覺。不是技術變強了，而是我們組織和推理程式碼的方式整個換了一套框架。
OOP 的時候，我們開始把「狀態」和「行為」綁在一起思考。Cloud-native 的時候，我們開始把「服務邊界」和「部署單元」分開思考。
Agent 時代，我們需要開始把「意圖」和「驗證」當作一級工程元素來思考。
真正的挑戰在哪裡
不是模型不夠強。benchmark 上大家都在進步。
真正的挑戰是：當 software 的核心邏輯從 hand-coded 轉向 agent-synthesized，整個 engineering 的責任邊界要怎麼重新定義。debugging 一個 deterministic bug 和 debugging 一個「agent 偶爾不照預期行動」的問題，完全是兩種思維。
governance 和 accountability 也跟著複雜化了。以前你能說「這個 bug 是因為第 42 行程式碼有問題」。現在你要說什麼？「這個 agent 的 prompt 在某個 context 下觸發了不符合預期的行為序列」？
我覺得接下來幾年，software engineering 這個領域最有趣的
不是哪個新模型出來，而是我們怎麼把 verification、observability、guardrail 這些概念建成一套成熟的實踐。
這才是 agent 時代真正的工程挑戰。
作者：陳思維