项目文件夹

0
Asim Aslam aa7cd6dc3b
goreleaser / goreleaser (push) Has been cancelled
Enhance support agent example and fix protoless service scaffolding (#2986)
* examples: support desk agent + blog walkthrough

A real-world, runnable example (examples/support): customers/tickets/notify
services become the agent's tools, a flow turns a ticket.created event into
the agent's work, and an approval gate guards the one action that touches a
customer. Runs with no API key (mock model) or against a live provider.

Adds blog/28 'Building a Support Agent in Go' and indexes both.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL

* fix(new): protoless services by default; fix @latest install (#2985)

micro new now scaffolds a reflection-based service by default — plain Go
types registered via service.Handle, no .proto, no Makefile proto target.
The generated project builds and runs with 'go run .' and zero external
tooling. Protocol Buffers move behind --proto (the crud/pubsub/api
templates imply it). When the proto workflow is used and protoc /
protoc-gen-go / protoc-gen-micro are missing, print exact install
instructions instead of failing with a cryptic plugin error.

Also fixes the 'go install go-micro.dev/v6/cmd/micro@latest' version
constraint conflict: the vanity go-import meta still advertised /v5, so Go
fell back to the bare module and resolved an ancient v1.x tag. Advertise
/v6 (keeping /v5 for existing users) and add a version-pin fallback note to
the install docs.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL

* fix(new,install): pin generated go.mod to current go-micro; lead install with prebuilt binary (#2985)

- micro new now requires the exact go-micro version the CLI was built from
  (via build info), falling back to 'latest' for dev builds. An explicit
  require is also more robust than a bare import: 'go mod tidy' reliably
  resolves it, where a requireless go.mod could fail vanity discovery.
- Make the precompiled binary (curl install.sh) the recommended install in
  the docs; demote 'go install' to a from-source option with the version-pin
  fallback note.
- Sync the stale internal/scripts/install.sh to the working website script
  (it expected an old micro-OS-ARCH asset name; releases ship
  micro_OS_ARCH.tar.gz).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL

* website: add corrected nginx vanity-import config (#2985)

The live go-micro.dev handler echoed the full request path into the
go-import prefix ($host$1), so go install go-micro.dev/v6/cmd/micro@latest
got prefix go-micro.dev/v6/cmd/micro — a package, not the module root — and
Go fell back to the ancient v1.x tags (version constraints conflict).

Add a dedicated /vN location that emits the module root (go-micro.dev/vN)
for any sub-path, and make the catch-all advertise the current module roots
instead of echoing arbitrary paths.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL

---------

Co-authored-by: Claude <noreply@anthropic.com>
2026-06-22 10:22:25 +01:00
2026-02-04 14:12:59 +00:00
2025-05-04 21:48:02 +01:00
2026-02-04 14:01:16 +00:00
2026-02-04 14:12:59 +00:00
2024-07-07 08:04:29 +01:00
2023-03-20 16:48:44 +00:00

Go Micro Go.Dev reference Go Report Card

Go Micro is a framework for building agents and services in Go.

Build an agent and it gets a model, memory, and tools, manages your services, and is reachable over MCP and A2A. Write services and they register, discover each other, and every endpoint is automatically an AI-callable tool. Orchestrate the deterministic parts with flows. Agents, services, and flows are all Go code — the same primitives, the same deployment — because an agent is a distributed system, and building one is building a service.

Sponsors

  

Want to support Go Micro and see your logo here? Become a sponsor — reach out on Discord.

Contents

Quick Start

Install the CLI:

# Binary (no Go required)
curl -fsSL https://go-micro.dev/install.sh | sh

# Or with Go
go install go-micro.dev/v6/cmd/micro@latest

Fastest start — no API key

Scaffold a service, run it, call it:

micro new helloworld
cd helloworld
micro run

Then in another terminal:

curl -X POST http://localhost:8080/api/helloworld/Helloworld.Call \
  -H 'Content-Type: application/json' -d '{"name":"World"}'

Generate from a prompt — with an LLM key

Set a provider key, describe what you want, and the AI designs services, writes handlers, compiles, and starts them:

export ANTHROPIC_API_KEY=sk-ant-...   # or OPENAI_API_KEY, GEMINI_API_KEY, ...
micro run --prompt "a task management system with categories" --provider anthropic

The AI designs the architecture, you review it, then it generates handlers with real business logic, compiles them, and starts them:

Services:
  ● task — Task management with status tracking
  ● project — Project organization

Generate? [Y/n]

Micro
  Services:
    ● task
    ● project
  Agents:
    ◆ agent

Then talk to your services from the console:

> Create a project called Launch, then add three tasks to it

→ project_Project_Create({"name":"Launch"})
← {"record":{"id":"p1..."},"success":true}
→ task_Task_Create({"title":"Design specs","project_id":"p1..."})
→ task_Task_Create({"title":"Write code","project_id":"p1..."})
→ task_Task_Create({"title":"Ship it","project_id":"p1..."})

Created Work category and added 'Finish report' task to it.

When you need a capability that doesn't exist, the agent generates a new service mid-conversation:

> I need to track shipping. Create a shipment for order 123 to London.

  ⚡ generating shipping service...
  ✓ shipping
  → shipping_Shipping_Create({"order_id":"123","destination":"London"})
  ← {"record":{"id":"xyz...","status":"pending"}}

  Created shipment for order 123 going to London.

Edit the generated code by hand at any time — re-running preserves your changes. Read more.

Writing Services

Under the hood, a service is a struct with methods. Doc comments and @example tags become tool descriptions for AI agents automatically.

package main

import (
    "go-micro.dev/v6"
)

type Request struct {
    Name string `json:"name"`
}

type Response struct {
    Message string `json:"message"`
}

type Say struct{}

// Hello greets a person by name.
// @example {"name": "Alice"}
func (h *Say) Hello(ctx context.Context, req *Request, rsp *Response) error {
    rsp.Message = "Hello " + req.Name
    return nil
}

func main() {
    service := micro.NewService("greeter")
    service.Handle(new(Say))
    service.Run()
}

Run it and everything is accessible — REST, gRPC, MCP, agent playground:

micro run
# Dashboard:   http://localhost:8080
# API:         http://localhost:8080/api/{service}/{method}
# Agent:       http://localhost:8080/agent
# MCP Tools:   http://localhost:8080/mcp/tools

You can also scaffold a service from a template:

micro new helloworld
micro new contacts --template crud

Building Agents

An Agent is a service with an LLM inside it. It has a proto-defined Agent.Chat RPC endpoint, registers in the registry, and is callable like any service:

agent := micro.NewAgent("task-mgr",
    micro.AgentServices("task", "project"),
    micro.AgentPrompt("You manage tasks and projects. You understand deadlines and priorities."),
    micro.AgentProvider("anthropic"),
)
agent.Run()

The agent discovers its services from the registry, scopes its tools to their endpoints, and maintains conversation memory in the store. It registers itself so micro chat and other agents can find it.

// Programmatic interaction
resp, _ := agent.Ask(ctx, "What tasks are overdue?")
fmt.Println(resp.Reply)

Multiple agents coordinate via RPC — each is a service with an Agent.Chat endpoint. micro chat routes to the right one.

micro agent list                    # list registered agents
micro call task-mgr Agent.Chat '{"message": "What tasks are overdue?"}'

Plan & Delegate

Every agent gets two built-in capabilities, exposed as tools — no extra setup, no harness:

  • plan — for multi-step work, the agent records an ordered plan in its store-backed memory and stays oriented across turns.
  • delegate — the agent hands a self-contained subtask to another agent. If a registered agent already owns the relevant services, the hand-off goes over RPC to that agent; otherwise a focused, short-lived sub-agent is created for the subtask with its own isolated context.

This keeps intelligence distributed: an agent doesn't need to know how to do everything, only who does. See examples/agent-plan-delegate.

// A sub-agent is just an agent — created with New, talked to with Ask.
// delegate-first: reuse a registered agent, or spin up a focused one.
resp, _ := agent.Ask(ctx, "Plan the launch, create the tasks, and have comms notify the owner.")

Batteries included, pluggable

Just as a service composes pluggable abstractions (registry, broker, store), an agent composes a model, memory, and tools — sane defaults out of the box, each swappable.

agent := micro.NewAgent("assistant",
    micro.AgentProvider("anthropic"),                 // model — swap the provider
    micro.AgentMemory(micro.NewInMemory(50)),         // memory — default is store-backed & durable
    micro.AgentTool("weather", "Get the weather for a city",
        map[string]any{"city": map[string]any{"type": "string"}},
        func(ctx context.Context, in map[string]any) (string, error) {
            return getWeather(in["city"].(string))    // tools beyond your services — any function
        }),
    micro.AgentMaxSteps(8),                            // guardrails
)

Memory is durable and store-backed by default (Postgres, NATS KV, or file), so an agent picks up where it left off after a restart — or supply your own with AgentMemory. Tools are your services automatically, plus any function you register with AgentTool.

Paid tools (x402)

Every endpoint is an AI-callable tool — and it can be a paid tool. Go Micro supports x402, the HTTP 402 payment standard for agents, so a tool can require a stablecoin payment and an agent can settle it autonomously. It's opt-in and carries no crypto in the framework: verification is delegated to a pluggable facilitator (Coinbase, Alchemy, self-hosted), so Base and Solana are just different facilitators.

# Charge for tool calls at the MCP gateway (off unless you set a pay-to address)
micro mcp serve --x402-pay-to 0xYourAddress --x402-network solana --x402-amount 10000
# Per-tool amounts via a config file
micro mcp serve --x402-config x402.json

See the Payments (x402) guide.

Reachable by other agents (A2A)

Within a Go Micro system, agents reach each other over RPC. To make them reachable by agents on other frameworks, Go Micro speaks the Agent2Agent (A2A) protocol. The A2A gateway discovers your agents from the registry, generates an Agent Card for each from its metadata — the same way the MCP gateway derives tools from service endpoints — and translates incoming A2A tasks to the agent's Agent.Chat RPC. No per-agent code: register an agent and it's reachable over A2A.

micro a2a serve --address :4000    # gateway: expose every registered agent over A2A
micro a2a list                     # agents and their Agent Card URLs

Or skip the gateway entirely — an agent can serve its own A2A endpoint directly, handling tasks in-process:

micro.NewAgent("task-mgr", micro.AgentServices("task"), micro.AgentA2A(":4000"))

It works both ways. To call an agent on another framework, an a2a.Client is wired into the two places that hand off work: flow.A2A(url) as a workflow step (the cross-framework Dispatch), and delegate to an http(s) URL from inside an agent.

MCP exposes your services as tools; A2A exposes your agents as agents. See the A2A guide.

Features

AI

Feature Details
Agents micro.NewAgent() — intelligent layer that manages services
Plan & delegate Built-in agent tools — plan multi-step work, delegate subtasks to other agents
Pluggable memory Durable store-backed conversation memory by default; swap with AgentMemory
Custom tools AgentTool — give an agent any function as a tool, beyond its services
Guardrails MaxSteps (stop on count), LoopLimit (stop repeated no-progress calls), ApproveTool (human-in-the-loop)
Tool middleware AgentWrapTool — wrap tool execution for logging, metrics, or retries (like client/server wrappers)
Workflows micro.NewFlow() — event-driven; one step, ordered durable steps, or triggers an agent
Durable execution Checkpointed flow steps survive a crash and resume where they stopped; store-backed by default, pluggable backend
MCP gateway Every endpoint is an AI tool automatically
A2A gateway Every agent is reachable over the Agent2Agent protocol; cards generated from the registry (micro a2a)
Payments (x402) Opt-in per-call payments for tools via the x402 standard; pluggable facilitator (Base, Solana, …)
7 LLM providers Anthropic, OpenAI, Gemini, Groq, Mistral, Together, Atlas Cloud
Interactive console micro run includes a chat console for talking to services
Service generation micro run --prompt — describe a system, get running services

Framework

Feature Details
Service registry mDNS (default), Consul, etcd
RPC client/server gRPC transport, load balancing, streaming
Pub/sub events NATS, RabbitMQ, HTTP broker
Key-value store File (bbolt), Postgres, NATS KV
Typed model layer CRUD + queries, SQLite/Postgres backends
Everything swappable All abstractions are Go interfaces

Developer experience & deployment

Feature Details
Hot reload micro run watches files, rebuilds on change
Templates micro new --template crud/pubsub/api
One-command deploy micro deploy user@server — SSH + systemd, no Docker

CLI

Command Purpose
micro run --prompt "..." Generate services + agent, start with interactive console
micro run Dev mode: hot reload, gateway, interactive console
micro run -d Detached mode (no console)
micro chat Standalone chat (when not using micro run)
micro agent list List registered agents
micro new myservice Scaffold a service
micro call service endpoint '{}' Call a service or agent from the CLI
micro build Compile production binaries
micro deploy user@server Deploy via SSH + systemd

Multi-Service Projects

Run multiple services together:

users := micro.NewService("users", micro.Address(":9001"))
orders := micro.NewService("orders", micro.Address(":9002"))

users.Handle(new(Users))
orders.Handle(new(Orders))

g := micro.NewGroup(users, orders)
g.Run()

Or use a micro.mu config file:

service users
    path ./users

service orders
    path ./orders
    depends users

Data Model

Typed persistence with CRUD and queries:

type User struct {
    ID    string `json:"id" model:"key"`
    Name  string `json:"name"`
    Email string `json:"email" model:"index"`
}

db := service.Model()
db.Register(&User{})
db.Create(ctx, &User{ID: "1", Name: "Alice", Email: "alice@example.com"})

var results []*User
db.List(ctx, &results, model.Where("email", "alice@example.com"))

Backends: memory (default), SQLite, Postgres.

AI Providers

Swap providers with a single import — same interface everywhere:

Provider Default Model
Anthropic claude-sonnet-4-20250514
OpenAI gpt-4o
Google Gemini gemini-2.5-flash
Groq llama-3.3-70b-versatile
Mistral mistral-large-latest
Together AI Llama-3.3-70B-Instruct-Turbo
Atlas Cloud llama-3.3-70b
m := ai.New("anthropic", ai.WithAPIKey(key))
resp, _ := m.Generate(ctx, &ai.Request{Prompt: "hello"})

Examples

See all examples.

Docs

Package reference: https://pkg.go.dev/go-micro.dev/v6