企業導入 AI agent 時，最容易高估模型，低估組織記憶。

很多討論還停在「哪個模型比較會寫 code」、「哪個 agent 跑得比較久」，但真正進公司之後，第一個卡住的常常不是智商，而是常識。這個常識不是通用常識，是公司自己的做事方法：repo 怎麼分層、什麼 PR 不能碰、哪種 migration 要找誰 review、哪些系統只能讀不能寫、哪個測試失敗代表真的壞了，哪個只是環境抖動。

所以近期企業開始談 agent skills、model harness、內部工作手冊，代表的不是提示詞工程又換名字，而是 AI 導入進入第二階段：從「找一個聰明外包」變成「訓練一個能上工的新同事」。差別很大。前者靠模型能力撐場，後者需要制度、上下文、權限、記錄與驗收。

誰該在意？不是只有 AI 平台團隊。工程主管、資安、內部工具、資料平台、甚至 PM 都該看。只要你的 agent 會碰真實 repo、真實客戶資料、真實部署流程，它就不只是生產力工具，而是一個會執行任務的新操作介面。這時候，公司知識如果還散在 Slack、老工程師腦中、過期 wiki、零碎 README，agent 只會把混亂放大。

錯誤理解是，以為把 SOP 丟進 system prompt 就夠了。比較現實的是，prompt 只能解決一小段指令問題，不能替你建立可維護的工作邊界。真正需要整理的是：哪些任務可以自動做、哪些要人工批准、失敗要怎麼回滾、輸出要怎麼驗收、不同模型能拿到哪些工具。這些東西如果沒有版本化、可審查、可重用，最後就會變成每個團隊各寫一套神秘咒語。

較穩健的採用方式，是先選一條高頻但邊界清楚的流程做成 agent skill，例如修小型 bug、整理客服工單、產生資料品質報告、更新內部文件。不要一開始就追求全自動。先把輸入、權限、可用工具、禁止事項、完成標準與人工交接點寫清楚，再觀察 agent 失敗在哪裡。每一次失敗，不只修 prompt，也要問：這是不是暴露了公司流程本來就沒寫清楚？

結論很簡單：下一波 agent 競爭，不只看誰的模型更強，也看誰能更快把組織知識變成可執行、可治理、可迭代的工作介面。真正值得投資的，不是把 agent 放進公司，而是讓公司有能力教它怎麼工作。