惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 叶小钗
爱范儿
爱范儿
WordPress大学
WordPress大学
Last Week in AI
Last Week in AI
博客园 - 聂微东
雷峰网
雷峰网
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 三生石上(FineUI控件)
T
Tailwind CSS Blog
博客园 - Franky
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园_首页
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 司徒正美
月光博客
月光博客
大猫的无限游戏
大猫的无限游戏
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
The Cloudflare Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
人人都是产品经理
人人都是产品经理
宝玉的分享
宝玉的分享
罗磊的独立博客
Jina AI
Jina AI

Show HN

GitHub - astefanutti/shaderbang: Shebang for Shaders Show HN: Generate Claude Code Workflows using Spec Driven Development approach Show HN: AI agents for UK GDAD PCF roles and their skills The Two Pillars: Mixer Mode and Meta-Software in the Reorganization of Software Work After AI GitHub - JaiCode08/teleport-env What 1,000+ Harness Experiments Taught Me About Self-Improving Agents Show HN: Liiists, a Markdown-first, iOS and CLI list app SwiperTab – Get this Extension for 🦊 Firefox (en-US) GitHub - kouhxp/fftext: Summarize, explain, fact-check, or translate any text, URL, or file. No GPU. No cloud. One command GitHub - sweetpad-dev/sweetpad: Develop Swift/iOS projects using VSCode GitHub - dogmaticdev/IRON: IRON a.k.a. Intermediate Representation Object Notation is a Interpreter/Database that is used to create Programming Languages. GitHub - sjhalani7/vaen: Package your AI coding harness into a portable .agent file, and share it across repos, teams, & the community without ever having to copy-paste instructions, skills, MCP config, or secrets. Show HN: Gandalf the Grader Show HN: Citadeld – replay any CI failure locally from a single file GitHub - tdortman/cuSBF: High-Performance GPU Super Bloom Filter coral-ai/claude-code-token-xray at main · Coral-Bricks-AI/coral-ai GitHub - ulyssestenn/funes: Funes is a Git-based framework for LLM-managed knowledge work: an AI Librarian ingests raw sources, builds an interlinked Markdown knowledge base, and uses it to produce cited reports, analyses, and other outputs. GitHub - ThatXliner/gah: Git Add Hunk, built for agents to use GitHub - harmont-dev/harmont-cli: Command-line client for the Harmont CI platform GitHub - brooksmcmillin/mcp-authflow: OAuth 2.0 Authorization Server framework for MCP servers GitHub - javaid-codes/audit-supply-chain-agents GitHub - amorey/gochan: A small library of common channel architectures for Go, inspired by Rust GitHub - arifozgun/OpenGem: Free, Open-Source AI API Gateway with Gemini, OpenAI & Anthropic Compatibility in 1 file GitHub - Pranesh950/BioPetals: 🌸 Run BIOxAI models at home, BitTorrent-style. Fine-tuning and inference up to 10x faster than offloading GitHub - cnguyen14/bounty-doctor: Diagnose a GitHub bounty issue before you waste hours: detects honeypot scam repos, AI-bot attempt swarms, and stale contests. Show HN: CoreMCP – MCP Server for On-Prem DBs Show HN: KittyHTML – Render HTML/CSS as an inline image in your terminal GitHub - bingud/filemat: Web-based file manager Show HN: TruthLens – Free multi-signal deepfake image detector GitHub - apexlocal-jz/claude-usage-tray: Windows system-tray app showing your Claude Code rate-limit usage at a glance. Zero deps, ~300 lines of PowerShell. Cross-IDE (works regardless of VS Code, Cursor, plain terminal).
Build Your Own AI Agent CLI in 150 Lines
asim · 2026-06-02 · via Show HN

Building an AI agent CLI

May 30, 2026 • By the Go Micro Team

We introduced micro chat — a CLI that lets you talk to your microservices through an LLM. People asked how it works under the hood. The honest answer: it’s about 150 lines, and there’s no magic. This post walks through every piece so you can build your own — for go-micro, for your own framework, or for whatever services you have.

By the end, you’ll understand the four moving parts of any tool-calling agent and have working code you can adapt.

The Problem

You have services. They do things — create users, send emails, query orders. You want to ask for those things in plain English and have the right service called automatically.

An LLM can do the reasoning (“the user wants to send an email, so call the email service”), but it needs three things from you:

  1. A list of tools it can call, with descriptions and parameters
  2. A way to execute a tool when it picks one
  3. Conversation memory so follow-up questions make sense

That’s the whole problem. Let’s solve each part.

The LLM needs to know what’s available. In go-micro, every service registers its endpoints with the registry, including request types and field metadata. We turn that into a tool list:

tools := ai.NewTools(reg, ai.ToolClient(client))
discovered, err := tools.Discover()

discovered is a []ai.Tool — one per service endpoint. Each has a name (users_Users_Create), a description (from the handler’s doc comment), and a parameter schema (from the request struct’s fields).

If you’re not using go-micro, this is the part you’d write yourself: enumerate your functions/endpoints and build a list of {name, description, parameters}. The registry just makes it automatic.

Part 2: Create the Model

m := ai.New("anthropic",
    ai.WithAPIKey(apiKey),
    ai.WithTools(tools),
)

Two things happen here. ai.New picks the provider (Anthropic, OpenAI, Gemini, etc. — all the same interface). ai.WithTools(tools) wires up the execution side: when the model says “call users_Users_Create with these args,” the handler routes it to the right RPC and returns the result.

That’s the second piece — the way to execute. The Tools object does double duty: Discover() builds the list, and its handler executes the calls.

Part 3: Track the Conversation

hist := ai.NewHistory(50)

History is a plain message accumulator with a size limit. It’s not magic — it’s a []Message with Add, Messages, and Reset. You add the user’s prompt and the model’s reply after each turn, and pass the accumulated messages back on the next call. That’s how follow-up questions work.

Part 4: The Loop

Now wire it together. The core of ask is just this:

func ask(ctx context.Context, m ai.Model, hist *ai.History, tools []ai.Tool, prompt string) error {
    hist.Add("user", prompt)

    resp, err := m.Generate(ctx, &ai.Request{
        Prompt:       prompt,
        SystemPrompt: systemPrompt,
        Tools:        tools,
        Messages:     hist.Messages(),
    })
    if err != nil {
        return err
    }

    if resp.Reply != "" {
        hist.Add("assistant", resp.Reply)
        fmt.Println(resp.Reply)
    }
    for _, tc := range resp.ToolCalls {
        args, _ := json.Marshal(tc.Input)
        fmt.Printf("  → called %s(%s)\n", tc.Name, args)
    }
    if resp.Answer != "" {
        hist.Add("assistant", resp.Answer)
        fmt.Println(resp.Answer)
    }
    return nil
}

Read it top to bottom:

  1. Record the prompt in history
  2. Call the model with the prompt, the system instruction, the tool list, and the conversation so far
  3. Print the reply and record it
  4. Show which tools were called (the model decides, the handler executes — we just report)
  5. Print the final answer after tools ran

The model’s Generate does the heavy lifting: it decides whether to call tools, the handler (from step 2 of setup) executes them, and the model produces a final answer. We never wrote any “if user wants email, call email service” logic. The LLM does that reasoning from the tool descriptions.

The REPL

Wrap ask in a read-loop and you have a chat:

scanner := bufio.NewScanner(os.Stdin)
for {
    fmt.Print("> ")
    if !scanner.Scan() {
        return nil
    }
    line := strings.TrimSpace(scanner.Text())
    switch line {
    case "":
        continue
    case "exit", "quit":
        return nil
    case "reset":
        hist.Reset()
        continue
    default:
        if err := ask(ctx, m, hist, discovered, line); err != nil {
            fmt.Printf("error: %v\n", err)
        }
    }
}

That’s it. Discover tools, create a model, track history, loop. Four pieces.

Why It’s So Short

The brevity comes from the framework doing the right things:

  • Services are self-describing. Doc comments become tool descriptions. The @example tag gives the LLM a usage hint. You don’t hand-write tool schemas.
// CreateUser creates a new user account.
// @example {"name": "Alice", "email": "alice@example.com"}
func (h *Users) CreateUser(ctx context.Context, req *pb.CreateRequest, rsp *pb.CreateResponse) error {
    // ...
}
  • Providers are uniform. Anthropic, OpenAI, Gemini, Groq, Mistral, Together, Atlas Cloud — all behind one ai.Model interface. Switching is one string.

  • Execution is wired automatically. ai.WithTools(tools) connects tool calls to RPC dispatch. No glue.

If you stripped go-micro out and built this against raw HTTP services, you’d add maybe 50 lines: a function to enumerate your endpoints and a function to call one by name. Everything else stays the same.

Make It Yours

The 150 lines are a starting point. Ideas for extending it:

  • Add a confirmation step before destructive tool calls (“This will delete 3 records. Continue?”)
  • Log every tool call to an audit trail or your observability stack
  • Filter the tool list so the agent only sees certain services
  • Swap the REPL for a Slack bot — same ask, different input source
  • Pre-load a system prompt with domain knowledge about your services
  • Trigger it from events instead of stdin — that’s exactly what micro flow does

The point of micro chat was never to be a finished product. It’s a demonstration that turning services into an agent is a small, comprehensible amount of code — not a framework you have to learn, just a pattern you can copy.

Try It, Then Read It

go install go-micro.dev/v5/cmd/micro@latest
micro run                                          # start your services
ANTHROPIC_API_KEY=sk-ant-... micro chat --provider anthropic

The full source is cmd/micro/chat/chat.go — about 220 lines including flags, help text, and provider env-var handling. The agent core is the ~40 lines you saw above.

Build your own. It’s more approachable than you think.


Go Micro is an open source framework for distributed systems development. Star us on GitHub.