But every time we get there, the same question creeps into my head: does the task actually need a flow this complex?

Back when model capabilities and context windows weren’t nearly as impressive, I used the Parallel pattern a lot — splitting subtasks across purpose-built agents to keep each one focused. It worked well. During one job interview, I was sharing this experience when the interviewer turned it around on me: “So what do you think an AI Agent actually is?”

As a developer, my gut answer was: an Agent is an LLM wired up to various APIs and MCP tools for external access, calling different tools based on the task at hand — plus context management, intent classification, system prompt tuning, and workflow design. But over time I realized that definition was too shallow, and it’s the kind of gap that leads to real misunderstandings.

Defining AI Agents

I came across a definition in Agentic Design Patterns by Antonio Gulli that I think is the clearest I’ve seen:

AI agent is a system designed to perceive its environment and take actions to achieve a specific goal. It’s an evolution from a standard Large Language Model (LLM), enhanced with the abilities to plan, use tools, and interact with its surroundings.

A complete Agent System runs through five core steps:

1. Get The Mission — receive the task
2. Scan The Scene — perceive the environment
3. Think it Through — plan the strategy
4. Take Action — execute
5. Learn and Get Better — improve from outcomes

These five steps are the capability framework of a fully realized Agent. It also explains why Agent design patterns — ReAct, Parallel, Route — exist in the first place: they’re all attempts to layer these capabilities on top of an LLM.

Does My Use Case Actually Need All of That?

Once you have a clear definition, the next question becomes: does your scenario actually require the full stack?

When I’m scoping a client project, I usually ask myself:

1. Does the task need to be user-initiated, or must the Agent sense its environment autonomously?
2. Is the context fixed, or does it change dynamically?
3. Does it need to learn from mistakes and improve over time?

Take the Parallel pattern — it shines in fixed-context, complex-task scenarios. The environment doesn’t change, tasks are pre-assigned, and each Agent just needs to execute its piece without worrying about the bigger picture.

Flip to a dynamic and unpredictable scenario, and ReAct pattern is the better fit. The Agent needs to continuously read the environment and adjust its strategy as new information comes in — much higher demands on perception and iterative refinement.

No pattern is inherently better than another; it’s all about fit. And figuring out fit means getting honest about what you can and can’t tolerate — which brings me to what I think is unavoidable when designing any Agent: the AI Agent Iron Triangle.

The AI Agent Iron Triangle

In Agent design, I think the same Iron Triangle applies, just with three different vertices: Accuracy, Latency, and Cost.

You can’t have all three. Know which dimension matters most before you start designing.

This is also why I think SLM (Small Language Model) based Agent Flow still has real research value. In an era where we’re spoiled by powerful large models, it’s easy to forget that in some cases, a simple SLM Agent Flow is more than enough — no need to throw money at a problem that doesn’t require it.

The Rise of OpenClaw

When OpenClaw blew up in early 2026, I got the same question over and over in client conversations: what do I make of its design, and what does it mean for Agent development?

OpenClaw’s success comes down to one thing: it gave the Agent the ability to operate the OS directly — not just calling APIs, but actually using the computer to get things done. The model is still the core, but the interface to the world changed fundamentally. How to achieve similar results with an SLM might be the next real frontier in Agent design.

I love Andrej Karpathy’s framing of LLM applications as an operating system.

It inspired me to map the relationship between LLMs and AI Agents onto computer hardware:

Back to That Original Question

“So what do you think an AI Agent is?”

After all this, my answer is: an AI Agent is a system that can perceive its environment, form a plan, and take action. But more importantly — it’s not a universal solution. Before designing one, getting clear on what your scenario actually needs matters far more than picking the right pattern.

Reference

• Agentic Design Patterns — Antonio Gulli
• Agentic Design Patterns
• Multi-agent — LangChain
• Choose a design pattern for your agentic AI system — Google Cloud
• Andrej Karpathy: Software Is Changing (Again)

但每次聊到這裡，我心裡都會浮現一個疑問：任務的複雜度，真的需要設計出這麼複雜的流程嗎？

在早期，模型能力與 Context Window 還沒那麼強的時候，我常用 Parallel pattern 將不同子任務分配給預先設計好的 Agent，效果相當顯著——讓模型能更專注在特定任務上。記得有一次面試，我和面試官分享這段經驗，他反問我：「你認為什麼是 AI Agent？」

作為開發者，我當時的直覺是：Agent 就是一個 LLM，背後串接各種 API/MCP 工具存取外部資源，讓 LLM 根據任務需求調用不同工具來完成目標，這其中也包含Context的管理，任務的辨別能力等等…但簡化來說，就是呼叫一次 LLM provider 的 API、管理呼叫API時chat_history的刪減，優化System Prompt(意圖判斷的能力)，並且為工作流程進行設計。

但我漸漸發現，這樣的定義過於簡化，也容易產生認知上的落差。

AI Agent 的定義

受益於 Agentic Design Patterns（Antonio Gulli 著），我認為這是我看過對 AI Agent 最清晰明瞭的定義，他說：

AI agent is a system designed to perceive its environment and take actions to achieve a specific goal. It’s an evolution from a standard Large Language Model (LLM), enhanced with the abilities to plan, use tools, and interact with its surroundings.

一個完整的 Agent System 包含以下幾個核心步驟：

1. Get The Mission — 接收任務
2. Scan The Scene — 感知環境
3. Think it Through — 規劃策略
4. Take Action — 執行行動
5. Learn and Get Better — 從結果中學習與優化

這五個步驟，構成了一個完整 Agent 的能力。

我覺得這也回答到，一個完整的Agent能力是複雜的，各式各樣的AGENT設計模式（ReAct、Parallel、Route）都是為了讓LLM疊加上這些能力。

我的場景，真的需要完整的 Agent 能力嗎？

有了清晰的定義之後，下一個問題就是：使用場景是否需要這麼完整的能力？

面對客戶需求，我通常會先問自己幾個問題：

1. 任務需要使用者主動提供，還是 Agent 必須能自主感知環境？
2. 情境是固定的，還是動態變化的？
3. 是否需要從錯誤中學習並持續優化？

以 Parallel pattern 為例，它適合在情境固定、任務較為複雜的場景下使用。在這種情況下，Agent 不需要太強的環境感知能力，因為任務已被預先分配好，Agent 只需專注完成各自的子任務，不需要思考整體流程或應對情境變化。

相反，若場景是動態且不可預測的，ReAct pattern 則更為適合。Agent 需要持續感知環境的變化，根據新的資訊調整行動策略，這對環境感知與迭代優化的能力要求都更高。

各種Pattern的設計沒有好壞，只有適不適合的問題，選擇前一定要先釐清可以接受哪些，以及不能接受哪些，這也帶到我認為在設計 Agent 的時候，無法避開的一個重要議題：AI Agent 的 Iron Triangle。

AI Agent 的 Iron Triangle

設計 AI Agent 時，我認為同樣存在一個類似的 Iron Triangle，只是三個頂點換成了：Accuracy（準確性）、Latency（延遲）、Cost（成本）。

三者無法兼得，設計前必須先釐清你最在乎哪個維度。

這也是我認為基於SLM（Single Large Model）Agent Flow 設計仍然具備研究價值的原因，因為在被各種強大的大型語言模型寵溺的當下，可能讓我們忽略了，在某些場景下，簡單的 SLM Agent Flow 就足夠了，不需要為了追求更高的準確性而投入更多成本。

爆紅的OpenClaw

2026年初，OpenClaw 的爆紅，也讓我在和其他公司或客戶交流時，很常被問到，我怎麼看待 OpenClaw 的設計，以及它在 Agent 設計上的啟示。OpenClaw 的成功，主要在他在設計上直接讓 Agent 具備操作系統的能力，不再是單純的串接各種API，而是操作電腦去達成任務。但模型依舊是核心，如何使用SLM也達到不錯的效果，或許會是下一個Agent設計的挑戰。

我很喜歡 Andrej Karpathy 將 LLM 應用比擬為作業系統的說法。

這也啟發我用這個框架去解釋LLM 和 AI Agent 的關係：

參考資料

• Agentic Design Patterns — Antonio Gulli
• Agentic Design Patterns
• Multi-agent — LangChain
• Choose a design pattern for your agentic AI system — Google Cloud
• Andrej Karpathy: Software Is Changing (Again)

It’s been nearly six months since I last wrote about Claude Code Hooks, and the progress in large language models during this period has been nothing short of staggering. We’ve seen Gemini 3.0, the new IDE tool Antigravity, Claude Opus 4.5, and most recently GPT-5.2—all within just a few months. The sheer speed of iteration in the AI space is mind-blowing. It’s got me thinking about whether I should invest more time into leveraging AI tools to streamline my workflow and automate more of my daily tasks.

How Claude Code Has Evolved Over the Past Six Months

Claude Code has come a long way during this time. Starting from basic functionality, it can now orchestrate Subagents to tackle complex tasks collaboratively. The ecosystem has expanded with plugins, a marketplace, and other features that make extending functionality much more accessible. There’s also the introduction of Skills, which let users define their own workflows and have Claude Code execute tasks according to these predefined procedures. These advancements have made Claude Code significantly more powerful and versatile across various use cases.

What Are Subagents?

According to Claude Code’s official documentation, Subagents are specialized agents designed to handle specific tasks. In my view, their primary purpose is to solve the problem of overly long context windows in a single conversation, which can hamper the model’s effectiveness. By breaking down complex tasks into subtasks handled by different Subagents, you reduce the burden on any single conversation while allowing each Subagent to focus on its specific domain—ultimately improving both efficiency and accuracy.

Use Cases for Subagents

I think this feature shines brightest when you need to orchestrate multiple MCP tools. If you’ve used VS Code Copilot extensively, you probably know that loading too many MCP tools in a single project can eat up a lot of context, making it harder for the model to effectively utilize them.

Defining a Subagent is straightforward—just create a .md file like this:

---
name: your-sub-agent-name
description: Description of when this subagent should be invoked
tools: tool1, tool2, tool3  # Optional - inherits all tools if omitted
model: sonnet  # Optional - specify model alias or 'inherit'
---

Your subagent's system prompt goes here. This can be multiple paragraphs
and should clearly define the subagent's role, capabilities, and approach
to solving problems.

Include specific instructions, best practices, and any constraints
the subagent should follow.

---

What Are Skills?

Here’s how Anthropic officially defines Skills:

Claude is powerful, but real work requires procedural knowledge and organizational context. Introducing Agent Skills, a new way to build specialized agents using files and folders.

Essentially, Skills help Claude Code better understand your workflows and organizational context, enabling it to complete tasks more effectively.

Consider this scenario: you’ve connected multiple MCP tools to Claude Code, but you really only need it to complete a specific task. Let’s say you want the agent to query data from a PostgreSQL database, format it into a report, and update it in Notion. Throughout this entire workflow, you might only use a handful of tools from a much larger toolkit. By defining the process steps through a Skill, you reduce the cognitive load on the LLM—it doesn’t have to figure out which tools to use because you’ve already specified that, allowing it to focus on the task itself.

This is quite similar to what many people do during Vibe Coding, where they predefine certain workflows or steps for the agent to follow. The Skill concept works the same way, except it establishes a kind of “standardized workflow format” that’s easier to extend or port to other CLI tools down the line.

Codex CLI now supports Skills too: Codex Agent Skills

Don’t Build Agents, Build Skills Instead

A few days ago, while browsing YouTube, I came across a video titled Don’t Build Agents, Build Skills Instead. It made some compelling points:

Code is all you need.

And:

Code is the universal interface

This got me thinking—could we treat CLI tools like Claude Code as general-purpose agents that help with generating reports and organizing data, rather than just writing code? Or maybe we should start viewing these procedural Skills as apps, with the Agent serving as the OS that helps us run them. After all, when it comes to integrating with third-party systems, any LLM web app—whether Gemini, ChatGPT, or others—just isn’t as convenient as working in a CLI environment.

Final Thoughts

In summary, the introduction of Subagents and Skills opens up new possibilities for CLI tools and enables exploration of more real-world applications. That said, from a pure Vibe Coding tool perspective, I still prefer Cursor at the moment. Besides being significantly faster than VS Code Copilot, it offers a direct browser element selection feature for frontend development that makes interaction much smoother. The pricing is also more flexible—unlike Claude Code Pro and Max, which lack a middle-ground option. When I get the chance, I’ll share more thoughts on my experience with Vibe Coding tools.

距離上一次介紹 Claude Code Hooks 已經過了將近半年時間，這段期間內無論是大型語言模型的進步，包含 Gemini 3.0，新的IDE工具 Antigravity、Claude Opus 4.5 或是最近出來的 GPT-5.2，時間也才短短經歷了幾個月而已。這些模型的進步速度之快，讓人不禁感嘆 AI 領域的迭代速度真是神速。也開始讓我思考，是不是要投入更多時間來研究如何讓 AI 工具更有效率地協助我的工作，或是自動化更多我的日常任務。

Claude Code 在這半年的進化

在這段期間內，Claude Code 也有了不少進化。從最初的基本功能，到目前可以規劃 Subagents，共同處理複雜任務，也延伸了 plugin 的概念、marketplace 等生態系，讓使用者可以更方便地擴展功能。另外還有引入 Skill 的概念，讓使用者可以定義自己的 workflow，並讓 Claude Code 根據這些技能來執行任務。這些進化讓 Claude Code 變得更加強大，也更適合用於各種不同的應用場景。

什麼是 Subagents？

Subagents 在 Claude Code 官方的 Docs 中被定義為專門處理特定任務的 Agents，我覺得主要目的就是解決單一對話的 Context 過長導致模型無法有效處理的問題。透過 Subagents，可以將複雜任務拆解成多個子任務，並由不同的 Subagents 來處理，這樣不僅可以減少單一對話的負擔，也能讓每個 Subagent 專注於特定的任務，提高整體的效率和準確性。

Subagents 的應用場景

這個功能我認為最適合運用在需要調度 MCP 工具的情境，常使用 VS Code Copilot 的人應該會知道，當同一專案調度過多的 MCP 工具時，可能會占用過多的 context，導致模型無法有效利用這些工具來完成任務。

撰寫方式也很容易，只需要透過撰寫一份 .md 檔案如下，就可以定義一個 Subagent，包含可用的工具及模型等資訊：

---
name: your-sub-agent-name
description: Description of when this subagent should be invoked
tools: tool1, tool2, tool3  # Optional - inherits all tools if omitted
model: sonnet  # Optional - specify model alias or 'inherit'
---

Your subagent's system prompt goes here. This can be multiple paragraphs
and should clearly define the subagent's role, capabilities, and approach
to solving problems.

Include specific instructions, best practices, and any constraints
the subagent should follow.

---

什麼是 Skill？

從 Anthropic 官方對於 Skill 的定義來看：

Claude is powerful, but real work requires procedural knowledge and organizational context. Introducing Agent Skills, a new way to build specialized agents using files and folders.

其實可以理解，Skill 就是為了幫助 Claude Code 更好地理解使用者的工作流程和組織背景，從而更有效地完成任務。

可以想像情境，假設我們在 Claude Code 同時串接了多項 MCP 工具，但是其實只是想要讓 Claude Code 幫忙完成特定的任務。隨機的舉例，假設是希望 Agent 到 PostgreSQL 資料庫中查詢特定的資料，並將資料整理成報表，更新到 Notion 中。在這整個流程中，可能只會調動到龐大工具中的幾項工具，透過 Skill 定義好步驟流程，可以減少讓 LLM 去思考到底要調用哪些工具，反而可以專注在任務本身。

其實就滿類似很多人在 Vibe Coding 時會預先定義一些流程或是步驟，來讓 Agent 遵守步驟完成任務，Skill 的概念也是類似的。只是像是更早提出這個概念，有點像是提出一個「流程化的標準」，方便日後擴展，或是沿用到其他CLI工具中。

現在 Codex CLI 也支援Skills：Codex Agent Skills

Don’t Build Agents, Build Skills Instead

前幾天在瀏覽 YouTube 時，看到一支影片，標題是 Don’t Build Agents, Build Skills Instead，其中提到：

Code is all you need.

以及

Code is the universal interface

其實也讓我思考，我們是否也可以把 Claude Code 這類 CLI 工具，也當作 General Purpose Agent，他可以幫忙產報表、整理資料，而不是僅限於程式碼生成。又或是開始把這些流程化的 Skill，視為一種 APP，而 Agent 只是 OS，來協助我們執行這些 APP。因為其實對於使用任何一項LLM Web App，無論是Gemini，ChatGPT…，在串接第三方的系統時，其實都不如在CLI環境中來得方便。

結語

總結來說，Subagents 與 Skills 的引入，讓CLI工具有更多的可能性，也探索更多可能的生活場景，但如果以Vibe Coding工具的角度來看，我目前還是比較喜歡使用Cursor，除了運行時間上遠快於VS Code Copilot以外，在前端開發上，也提供直接點選網頁元素的方式來完成任務交互，在價錢上面也有比較多種選擇，不像是 Claude Code Pro 以及 Max 之間沒有可選的中間方案。之後有時間的話，也會再來分享更多關於VibeCoding工具的使用心得。

Claude Code Hooks is an event-driven automation mechanism that allows you to automatically execute specified shell commands before or after Claude Code performs certain operations.

When using Claude Code, you often want to complete a custom task after a specific operation finishes, before continuing with subsequent tasks.

While you can achieve this with well-crafted prompts before starting a session, sometimes we want these custom tasks to be rigorous and not rely on the LLM to make decisions. This is where Claude Code Hooks comes in handy.

Common Use Cases for Claude Code Hooks:

Claude Code Hooks events are categorized into PreToolUse, PostToolUse, Notification, Stop, SubagentStop, and more.

Users can configure which scenarios should trigger hooks.

For example:

In the PostToolUse scenario, when Claude Code executes Write, Edit, or MultiEdit operations, the corresponding hooks will be triggered.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "/home/user/scripts/format-code.sh"
          }
        ]
      }
    ]
  }
}

How to Send Telegram Notifications with Claude Code Hooks

Let’s create a simple example where Claude Code automatically sends a Telegram notification when it’s waiting for your input.

First, write a simple shell script that sends Telegram notifications.

#!/bin/bash

# Script for sending Telegram notifications
TELEGRAM_SCRIPT="/home/jimmy/script/telegram-notify.sh"

# I want the notifications to look nice, so I wrote a format_notification function to handle the notification format
format_notification() {
    local hook_data="$1"

    # Check if jq is available
    if ! command -v jq >/dev/null 2>&1; then
        echo "🤖 Claude Notification
💬 jq not available - raw notification" | "$TELEGRAM_SCRIPT"
        return 0
    fi

    # Extract message and hook_event_name from hook input
    local message
    local hook_event_name

    message=$(echo "$hook_data" | jq -r '.message // "No message"' 2>/dev/null)
    hook_event_name=$(echo "$hook_data" | jq -r '.hook_event_name // "Unknown"' 2>/dev/null)


    local formatted_message="🤖 <b>Claude Notification</b>
💬 $message"

    # Send Telegram notification
    echo "$formatted_message" | "$TELEGRAM_SCRIPT"

    return $?
}

Next, configure hooks in Claude Code. After entering the Claude Code CLI interface, use /hooks to enter the hooks configuration screen, which looks like this:

Go to the Notification field and click “Add new hook”, enter the path to the shell script we just wrote, and also adjust whether this hook is a project setting or a global user setting. At this point, your settings.json will show your hooks configuration as follows:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "/home/jimmy/script/claude-notification-message.sh"
          }
        ]
      }
    ]
  }
}

Now you can start testing. I often switch to other windows while Claude Code is running.

I frequently encounter situations where it’s waiting for my approval, but I don’t notice. This feature helps remind me.

Here’s an example where I ask Claude Code to execute a Bash command to create a folder:

When it triggers a Notification, it automatically sends me a Telegram notification.

Never forget that you asked Claude Code to do something again! 😂

Conclusion

When configuring Claude Code Hooks, you can also use Hook Output to determine the logic for successful and failed hook executions, using Exit Code or JSON Output. Additionally, matchers can be configured for MCP tool usage scenarios, making it convenient to execute planned hooks when triggering specific MCP tools. By setting up comprehensive hooks, you can make Claude Code usage more rigorous and reduce the time spent checking for errors afterward.

References

Claude Code Hooks Official Documentation

Claude Code Hooks 是一種 事件驅動的自動化機制，允許你在 Claude Code 執行某些操作之前或之後，自動執行你指定的 shell 命令。

在使用 Claude code時，常常會希望執行完特定任務時，可以先完成某個使用者自訂的任務，再繼續延續執行後續的任務。

雖然這都可以在開啟session前用足夠好的prompt要求model執行，但有時候我們希望這些自訂任務可以足夠嚴謹，不仰賴LLM來做決定，這就是Claude Code Hooks 的用武之地。

Claude Code Hooks 常見的使用情境分為以下幾種：

Claude Code Hooks 的事件驅動分為 PreToolUse、PostToolUse、Notification、Stop、SubagentStop 等等情境

使用者可以調整決定什麼情境才要驅動hooks

舉例:

在PostToolUse的情境下，當 Claude Code 執行了Write、Edit或MultiEdit等操作時，就會觸發相對應的hooks。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "/home/user/scripts/format-code.sh"
          }
        ]
      }
    ]
  }
}

如何使用 Claude Code Hooks 寄送 Telegram 通知

接下來開始時做一個簡單的範例，當 Claude Code 執行需要等待你的輸入時，會自動寄送 Telegram 通知。

首先先寫一隻簡單的 shell script，這個 script 會寄送 Telegram 通知。

#!/bin/bash

# 寄送 Telegram 通知的腳本
TELEGRAM_SCRIPT="/home/jimmy/script/telegram-notify.sh"

# 因為我希望寄送的通知可以稍微美觀點，所以另外寫一個format_notification 函式來處理通知格式
format_notification() {
    local hook_data="$1"
    
    # Check if jq is available
    if ! command -v jq >/dev/null 2>&1; then
        echo "🤖 Claude Notification
💬 jq not available - raw notification" | "$TELEGRAM_SCRIPT"
        return 0
    fi
    
    # 抓取hook input 訊息中的 message 和 hook_event_name
    local message
    local hook_event_name
    
    message=$(echo "$hook_data" | jq -r '.message // "No message"' 2>/dev/null)
    hook_event_name=$(echo "$hook_data" | jq -r '.hook_event_name // "Unknown"' 2>/dev/null)
    

    local formatted_message="🤖 <b>Claude Notification</b>
💬 $message"
    
    # 寄送 Telegram 通知
    echo "$formatted_message" | "$TELEGRAM_SCRIPT"
    
    return $?
}

接下來到claude code中設定hooks，進入claude code cli介面後，使用 /hooks 進入hooks設定介面，會出現以下畫面：

進入在Notification的欄位中Add new hook，輸入我們剛剛寫好的 shell script 路徑，也一起調整這個hooks為專案設定還是使用者全域設定。 這時候的settings.json會顯示你的hooks設定如下：

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "/home/jimmy/script/claude-notification-message.sh"
          }
        ]
      }
    ]
  }
}

接下來就可以開始測試了，我自己很常在 Claude Code 執行時跳到其他視窗

很常遇到，在等待我approve，我卻沒有注意到，這時候就可以透過這個功能來提醒我。

這邊以請Claude Code 執行Bash命令串建一個資料夾作為舉例：

當他觸發 Notification 的時候，會自動寄送 Telegram 通知給我

再也不會忘記自己有叫Claude Code 做事了！😂

結論

在設定 Claude Code Hooks 時，還可以運用Hook Output來決定執行hooks成功及失敗的對應邏輯，可以使用Exit Code或是Json Output來決定。 除此之外，matcher也可以設定在mcp tool 使用的情境，方便在觸發特定的mcp tool時，執行規劃好的hooks。透過設立好完善的hooks，可以讓 Claude Code的使用更加嚴謹，減少產生錯誤後續檢查的時間。

參考資料

Claude Code Hooks 官方文件

Google released Gemini CLI on June 26, 2025, joining the Agent CLI competition. Developers can use their personal Google account to log in and use Gemini CLI for free. It provides Gemini 2.5 Pro with a 100 token context window. The model request quota can reach 60 requests per minute and up to 1,000 model executions per day — all completely free.

Comparing Claude Code and Gemini CLI

After initially trying Gemini CLI, I found that the usage experience isn’t very different from Claude Code. It also supports non-interactive mode, MCP integration, and notably has native support for GoogleSearch and WebFetch functionality. For memory management, you can use --checkpoint to manage memory usage and -s to enter sandbox mode, avoiding pollution of the local environment.

Installing Gemini CLI:

npm install -g @google/gemini-cli

After successful installation, you’ll see the following message:

Now you can start using Gemini CLI. Here are some basic commands:

View token usage

/stats

List available tools

/tools

Execute commands without entering interactive mode

gemini -p "your prompt"

Will Claude Code Fall from Grace?

For now, Claude Code remains a solid choice, especially with its integration across different platforms. Claude 4’s code comprehension and problem-solving capabilities are also outstanding. However, Gemini CLI offers a great alternative for users who don’t want to pay, and being fully open source brings more possibilities to the product.

Google 在 2025 年 6 月 26 日發佈了 Gemini CLI，也一起加入了Agent CLI 競賽的行列，並且提供開發者使用個人Google帳號登入就能免費使用Gemini CLI。 提供 Gemini 2.5 Pro 以及 100 token 的 context window。並且在model的請求額度可達到每分鐘 60 次，每日最多可達 1,000 次的模型執行額度，而這些 完全免費

Claude Code 與 Gemini CLI 的比較

初步簡單的適用Gemini CLI，會覺得目前跟Claude Code使用上沒有太大的差別， 同樣支援免互動介面的操作模式，支援MCP的串接，比較特別的是原生支援了GoogleSearch跟WebFetch 的功能， 並且在記憶管理上可以說用 --checkpoint 來管理記憶體的使用以及支援 -s 進入sandbox 模式，避免污染本機環境

安裝 Gemini CLI：

npm install -g @google/gemini-cli

當安裝成功後會看到以下訊息：

接下來就可以使用 Gemini CLI 了，以下是一些基本的使用指令：

觀看 token 使用量

/stats

列出可用工具

/tools

不進入互動模式執行指令

gemini -p "你的prompt"

Claude Code 會跌入神壇嗎！？

目前看來，Claude Code 仍然是個不錯的選擇，特別是已經整合了不同的平台。且Claude 4 在程式碼的理解以及解決問題的能力也非常出眾，但Gemini CLI 也提供了不想課金的使用者一個不錯的選擇，並且完全開源，也為產品帶來了更多的可能性。