最近因為工作的關係，需要對 AI 代理人（AI Agent）進行評估，也順便做了 Agentic AI（代理式 AI）的比較。如果你也在評估或導入 AI 代理相關技術，這兩者看起來相似卻不太一樣。

我經常看到「某某工具超強」的討論，但實際用了別人的 Agent Skill 後，往往發現不太順手，效果也跟預期有落差。更何況讓任意的人提供你 Agent Skill 從安全角度來看也非常危險，因為我們會授權給 Agent 做很多事情，遠比工具軟體危險更多。

除了安全以外，還有很多理由應該要有一套自己的 Agent Skill 會更好。

你是否發現 AI 生成的程式碼，每次整合都要花大量時間重新改寫？自從 Coding Agent 被推出，就不斷有會聽到軟體工程師會被取代的聲音。然而，最近跟同事協作的過程中，整體還是符合「剩下專業的人留下」這樣整體的現況。

可能有人會認為有 Coding Agent 後「不用學習軟體開發」但沒有意識到，許多高階的軟體開發知識，都不是「實作」的問題，更多是怎麼「設計」或者「架構」

在 2025 年，我們經歷了 LLM（大型語言模型）快速進步的一年，以 AI Agent 形式的工具越來越多，用於開發軟體的 Coding Agent 也逐漸成熟到變成標準配備，而不是用來快速修改檔案的手段之一。

然而，對於軟體工程師來說，我認為 2026 年最值得投資的並不是學會 Coding Agent 這類工具的使用，而是更根本的能力。

你是否看到 Claude Code 的 Sub-Agent 功能就想設計一堆來用？Backend Agent、Frontend Agent 等等，感覺得到更強的工具，但真的需要嗎？

WebConf 2025 期間跟朋友聊到這個話題，才發現大家對 Sub-Agent 的使用時機還是相對陌生。今年有兩場演講提供了不錯的切入點：ihower 大大的 AI Agents 開發 以及 91APP 首席架構師安德魯大大的 從 Service 到 Agent。

以往對於自行架設的伺服器進行安全防護，大多是設定好防火牆（Firewall）以及像是 Fail2ban 這類根據特定規則自動阻擋的工具，就能減緩大多數網路攻擊。

直到前陣子我在家中的 GitLab 突然發了非常多密碼重設信，才發現缺乏很多手段去阻止現代的網路攻擊，單純依靠 Fail2ban 已經不足以解決問題。

因為 LLM 的不確定性，再加上大多數服務都會採取呼叫 API 的方式來使用，我們很難在測試中直接呼叫，比較好的做法是將 LLM 呼叫使用 Mock 方式處理。

如果要測試 LLM 的表現，則會使用 Evaluation（評估）的方式，並不在這系列討論的範圍中

上週五跟 Stan 也是台灣第一位 Ruby Committer（核心貢獻者）和幾位 Ruby Taiwan 核心社群成員在酒吧討論明年社群活動（RubyJam）的規劃，這就需要面對這幾年大部分社群都有實體活動衰退的問題，以及我們都認同的觀點——社群活動不是以學習知識為目的，而是以知識交流前提建立連結。

如果直接使用 Vitest 來撰寫測試，我們需要模擬大量的 API 請求和回應的檢查，這會造成單一測試非常不好閱讀，在維護新的功能時也需要反覆的產生大量重複的程式碼。

我們可以模仿 BDD（Behavior-Driven Development）風格的方式，設定「步驟」的概念，來讓測試案例變得容易理解，也能讓 AI 擴充測試時更加穩定。

前面的內容我們都注重在功能的實現，然而使用 AI 開發使用測試來確保功能的穩定也是非常重要的，至少我們不會因為產生的程式碼有一些預期外的改動，而破壞整個功能的完整性。