Deep Dive Into AI Agent

對話

從最小的 LLM 對話開始

from google import genai

client = genai.Client(...)
user_prompt = input("> ")
response = client.models.generate_content_stream(
        model="gemini-3.1-flash-lite", 
        contents=user_prompt
    )

for chunk in response:
	print(chunk.text, end="", flush=True)

多輪對話

Agent 的最底流程其實也就是一個 While True 的 loop， 裡面會把每次 User 的 prompt 以及 LLM 的 Response 不停累積在 History 的 List 裡面 (每次可能都會存在 DB 或是其他 file 裡面)

from google import genai

history = []

client = genai.Client(...)

while True:
	
	# Get User Prompt
	user_prompt = input("> ")
    if not user_prompt.strip():
        continue
    if user_prompt.strip() == "/exit":
        print("Happy Coding!!")
        break
	# Add User Prompt to History
	history.append(Message(role="user", text=user_prompt))
	contents = message_to_contents(history)
	
	# Ask LLM
	response = client.models.generate_content_stream(
        model="gemini-3.1-flash-lite", 
        contents=contents
    )
    
	text = response.text or ""
	
	# Add LLM Response to History
    history.append(Message(role="assistant", text=text))
    
    # Show Result to User
	print(text)

如何使用工具呢？

LLM chat 非常有局限性，例如：

1. 時效性： LLM 模型不可能每天都把資料即時的訓練 LLM 模型，現在使用的模型可能是去年訓練完 freeze 的， 那如果想詢問 up to date 的問題呢？
2. 互動性： LLM 模型如何跟外部的系統做互動呢？
3. 不確定性：LLM 模型是 non-deterministic 的， 例如問他 strawberry 有幾個 r 有時候也會錯誤

這時候就可以讓 LLM 去使用我們寫好的 function 去做 web search, call api 或是執行 deterministic 的邏輯

Function Calling

現在的 LLM 模型基本上都支援可以傳一個 tool List 做使用， tool 本身包含

1. name: function 的名字，可以用來作 dispatch
2. description: 用來讓 LLM 知道什麼時候可以用以及怎麼用這個 tool
3. function args: 讓 LLM 知道要傳入哪些參數

...

response = client.models.generate_content_stream(
        model="gemini-3.1-flash-lite", 
        contents="1 + 2 = ?",
        config=types.GenerateContentConfig(
                tools=[types.Tool(function_declarations=[
	                types.FunctionDeclaration(
		                name="add",
		                description="Add Two numbers",
		                parameters_json_schema={ 
			                'properties': { 
				                'num1': { 
					                'title': 'Num1', 
					                'type': 'integer' 
					            }, 
					            'num2': { 
						            'title': 'Num2', 
						            'type': 'integer' 
						        } 
						    }, 
						    'required': ['num1', 'num2'], 
						    'title': 'add', 
						    'type': 'object' 
						}
	                )
                ])]
            ),
    )
...
candidate_content = None
function_calls = []
if response.candidates:
	candidate_content = response.candidates[0].content
	if candidate_content:
		parts = candidate_content.parts or []
        function_calls = [p.function_call for p in parts if p.function_call]

...

for fc in function_calls:
	print(fc.name) # add
	print(fc.args) # {num1: 1, num2: 2}               

Skill 是什麼？

當我們有越來越多種任務想交給 Agent 去做之後， 將所有的 Domain Knowhow 或是工作流程都寫在 System Prompt 會導致 Context 的浪費，於是傾向使用漸進式揭露的 Skill 注入資訊到 Context 內。

而 Skill 本身其實就是一個可以去讀取某個資料夾內文件內容及執行 script 的 tool。 會多注入一個 Tool，例如 get_skill_instruction， 且 System Prompt 裡面會有如何去使用 Skill 的指令，例如

<available_skills>
	You have access to a set of skills listed below. Each skill is shown only as a
	short name and description — the FULL instructions live in a separate file and
	are NOT included in this prompt.
	
	...
	
	<procedure>
		1. Read every <skill_description> below.
		2. For each, ask: could this skill plausibly apply to the user's task? (1% counts.)
		3. If yes → call `get_skill_instruction(name=...)` with that skill's exact name.
		4. Follow the returned instructions exactly. Do not paraphrase or shortcut them.
		5. If no skill applies, proceed normally.
	</procedure>
	
	Never guess or invent a skill's behavior from its description alone — the
	description is only a hint for matching. The real instructions are only
	available via `get_skill_instruction`.
	
	<skills>
		<skill_name> Foo Skill </skill_name>
		<skill_description> When to use this Foo Skill and when not to </skill_description>
		
		<skill_name> Bar Skill </skill_name>
		<skill_description> When to use this Bar Skill and when not to </skill_description>
	</skills>
</available_skills>

他解決了 Context Window 有限的問題， 當需要 Skill 的時候才會把需要的訊息載入，也可以使用定義好的 Script 去得到某個 deterministic 的 sub-result。 然而 Skill 本身也有局限

1. 本質上也只是把 prompt inject 到 context 裡面， 隨著任務進行 Skill 本身的資訊就可能被稀釋掉 (Lost in the Middle)
2. 使用的前提是 LLM Model 判斷要使用這個 Skill 才會載入，相反的如果 LLM 沒有載入的話就沒用

Context Engineering

我們先大致看一個 Agent 的 Flow

history = []

while True:
	
	# Get User Prompt
	user_prompt = input("> ")
	# Add User Prompt to History
	history.append(Message(role="user", text=user_prompt))
	contents = message_to_contents(history)
	
	for _ in range(MAX_TOOL_ITERATION):
		# Ask LLM
		response = client.models.generate_content_stream(
	        model="gemini-3.1-flash-lite", 
	        contents=contents
	    )
    
		if not function_calling(response):
			print(response.text)
			# Add LLM Response to History
		    history.append(Message(role="assistant", text=text))
		    break
		
		# get tool response and send to LLM in next iteration
		tool_response_parts = []
		for fc in function_calling(response):
		    func = tools_registry[fc.name]["func"]
			result = func(**dict(fc.args or {}))
            tool_response_parts.append(
				types.Part.from_function_response(
					name=fc.name or "",
					response={"result": result},
				)
			)
		contents.append(types.Content(role="user", parts=tool_response_parts))	

這邊我們先關注 contents 裡面包含了哪些東西。

1. history
2. system_prompt
3. user_prompt
4. tool result ( 這邊可能包含了 tool, RAG, Skill 等等 )

這個 contents 就是 LLM 的 Context。 而問題是該放哪些東西給 LLM 能夠讓它在任務上表現得最好呢？ 直覺上隨著 LLM 模型支援的 Context 越來越大，我們可以將所有東西都餵給 LLM 並祈禱它表現良好。 但是事實上隨著 Context Window 中 token 數量的增加，模型準確回憶上下文資訊的能力會下降 (Context Rot)， 並且隨著任務的進行許多細節的注意力也會逐漸被稀釋 (Lost in the Middle)，所以如何決定有哪些東西要進 Context 就是 Context Engineering。 大致有以下幾種面向考慮

Write

把資訊寫到 context 外部，如 memory 或是檔案，需要時再讀回。

Select

在每次任務前要怎麼將有用的資訊放進 Context 內呢？ 主要有 3 種

1. Rule-Base Select: 例如預先規定一定要載入 CLAUDE.md
2. Model-Base Select: 依任務挑選要載入的 skill
3. Retrieval-based Select: 使用相似度分析從外部資料庫拿相關資訊

Compress

當 Context 越來越大時， 我們可以對其內容進行壓縮，以最小的 token 數保留盡可能多的資訊。 或者對內容進行剪枝。 然而風險是可能有些細節會被 LLM 給丟失導致上下文缺失，並且根據 Compress 或是剪枝的方式也會導致 KV Cache 失效

Isolation

當任務可能會消耗大量 Context 時可以委託其他 Context 互相隔離的 Agent 去執行並且得到壓縮過後的 Summary 以達到減少 Main Agent 的 Context 消耗。然而風險一樣是細節可能被 Sub Agent 給丟失掉，並且會有較高的延遲以及總 token 消耗。

Reference

• Function Calling
• Effective context engineering for AI agents
• Lost in the Middle
• Context Rot
• Transformers KV Caching Explained