DMBlog onepage/ Rahul/ Agentic Engineering
Rahul · X Article · 2026-06-23

Agentic Engineering 核心概念：從 Agent Loop 到 Guardrails

這篇長文的重點不是再介紹一個新框架，而是把 agent 系統中反覆出現的基本構件整理出來：Agent 如何循環、狀態住在哪裡、工具如何接上、subagents 如何協作，以及什麼護欄能避免它把事情做壞。

Source: X Article / indexed mirrors X source Medium mirror
Source type
X Article
Published
2026-06-23
Core topic
Agent systems
Use case
工程心智模型
Read first

不要先學框架，先學會辨認 agent 系統的骨架

Rahul 的主張很直接：AI agent 工具每週都在變，但底層概念變得慢很多。開發者真正需要的是一張框架無關的地圖，看到 Claude Code、LangGraph、CrewAI、AutoGen 或任何新工具時，能立刻判斷它把哪些能力做成內建，哪些仍要自己補。

一個 agent 不只是「會聊天的模型」。它是 LLM 加上工具、狀態與迴圈。模型每一步都要根據目前上下文決定要不要行動，行動後再把觀察結果帶回下一輪。這個循環能做事，也會累積風險，所以配置、權限、檢查與可觀測性不是外掛裝飾，而是 agentic system 的主體。

01 / Agent

從回答者變成執行者

Chatbot 通常答完就停；agent 會在多輪中選工具、讀結果、更新計畫，直到任務收斂。

02 / State

狀態不是只有上下文

當前 context、檔案、資料庫、memory、任務進度與工具輸出，都可能是 agent 判斷下一步的狀態。

03 / Pattern

多 agent 需要分工模式

Planner/executor、router/specialist、map-reduce fan-out 都是在處理同一件事：把工作切給合適的上下文。

System map

把概念分成五層，才知道每個設計在解什麼問題

這篇文章公開索引到的目錄，從核心 building blocks 延伸到 configuration、capability、orchestration、guardrails 與 observability。這個分層比單純背名詞有用，因為它讓你知道每個功能是為了控制行為、擴充能力、協調工作、降低風險，還是用來追查事後到底發生什麼。

Foundation

Agent、Execution Loop、Agent State、Common Patterns

先理解 agent 是如何在 think-act-observe 迴圈中運行，以及狀態如何在上下文、檔案、memory 和任務進度之間流動。

Config

CLAUDE.md / AGENTS.md、Workflow Files、Prompt Caching、Context Rot

配置層決定 agent 在開始做事之前會讀到什麼規則。這些規則越短、越明確、越常用，越能抵抗長上下文中的注意力稀釋。

Capability

MCP、Live Document Retrieval、Persistent Memory

能力層決定 agent 能接觸什麼世界：工具、即時文件、搜尋、專案知識與跨 session memory。能力越大，權限邊界越要清楚。

Orchestration

Subagents、Agent Loops、Handoff、Work Isolation

當一個 agent 不夠用，系統需要把工作拆給乾淨上下文的 subagents，並用摘要、檔案或 worktree 管理 handoff 和衝突。

Control

Sandboxing、Permissions、Hooks、Pre-Commit Gates、Tracing、Metrics

控制層讓 agent 的行動可限制、可阻擋、可回放、可量測。這也是 demo 和 production 最大的差別。

Config layer

配置不是文件，是 agent 每一步都會讀到的行為約束

文章反覆強調 config files 的重要性，原因很簡單：如果你不告訴 agent 專案的 package manager、測試命令、禁止事項、風格規則，它就會用訓練資料中最像的答案補空白。結果可能是用錯工具、寫出不合專案的模式，或在每次任務中重新猜測團隊習慣。

Config files 要短而硬CLAUDE.md 或 AGENTS.md 適合放每次都重要的規則：工具鏈、目錄邊界、提交規則、不可讀取或不可修改的範圍。
Workflow files 要按需載入Skills、rules、slash commands 適合放任務流程，例如 TDD、code review、debugging。不是每次任務都需要，就不要常駐。
Prompt caching 改變成本曲線長 config 會被每輪重讀；快取可以降低重複 prefix 的成本與延遲，但前提是內容穩定且真的值得保留。
Context rot 會讓好規則失效上下文越長，模型越容易忽略關鍵規則。把 generic boilerplate 塞進 system prompt，常常比沒有規則更糟。
Guardrails

Agent 能碰到真實工具後，安全邊界就變成工程主線

只會回答的模型，錯了通常只是文字錯；能執行命令、改檔案、呼叫 API 的 agent，錯了就可能造成真實副作用。Rahul 把 sandboxing、permissions、hooks、prompt injection defense 和 pre-commit gates 放在同一層，這個排序很務實：不要只靠模型「自覺小心」，要讓系統在工具層、提交層和觀測層都能攔截。

脆弱的 agent 工作流

  • 自動信任外部 repo 的 config 或 MCP
  • 所有工具一次全開，沒有細分讀寫權限
  • 危險命令只靠模型自己判斷
  • 沒有測試、lint、typecheck 或 pre-commit gate
  • 失敗後只剩聊天紀錄，無法重播或定位問題

可上線的 agent 工作流

  • 外部內容一律視為不可信輸入
  • 讀、寫、網路、shell、提交權限分層授予
  • 高風險工具經 hooks 或人類批准
  • 所有變更通過 deterministic gates
  • 每次 tool call、模型版本、成本與結果都有 trace
Where to start

如果要把這篇變成行動，從四個小改動開始

不需要一次把完整 agent platform 做出來。對個人或小團隊來說，最有槓桿的起點是：把常駐規則寫短、把重複任務寫成 workflow、把工具權限切細、把結果驗證自動化。這四件事會直接改善每天使用 agent 的可靠性。

寫一份可審查的 AGENTS.md限制在真正會影響結果的規則：工具命令、架構約束、禁止行為、測試要求。每一行都要能被刪除或驗證。
把常做任務沉澱成 workflow例如「修 bug 前先重現」、「改 UI 後截圖驗證」、「寫 migration 後跑 schema check」。流程比口頭提醒更容易被 agent 遵守。
先關掉不必要工具，再逐步授權讓 agent 預設只能做必要動作。需要網路、寫檔、執行 shell 或推送時，再用明確情境開權限。
用測試和 trace 取代感覺每個 agent workflow 都要留下可檢查的輸出：測試結果、lint、typecheck、截圖、成本、耗時、tool-call history。

這篇文章最值得帶走的，是「agent 不是魔法，是一組可工程化的控制迴圈」。