后端微服务AI AgentRPC框架【免费下载链接】go-microA Go agent harness and service framework项目地址https://gitcode.com/gh_mirrors/go/go-micro点击查看免费下载导读本文以 go-micro 的 AGENT_DESIGN.md 为核心系统讲解 Agent 接口的完整设计Agent 本质上是内嵌了 LLM 的 Service拥有真实 RPC 端点Agent.Chat、在注册中心中登记注册并可通过plan/delegate等内置工具编排其负责的服务。读完本文你将掌握如何用micro.NewAgent创建单服务/多服务 Agent、通过Ask编程式调用、配置记忆与护栏Guardrails、使用持久化 Checkpoint 恢复运行以及如何通过micro chat、A2A 网关实现跨 Agent、跨框架通信。一、设计原则Service 能力Agent 智能go-micro 对 Agent 的核心定位是一句话An agent IS a service。它不是一个独立于微服务体系之外的新物种而是服务家族中的一员Agent 是一个服务——它拥有真实的 RPC server、由 proto 定义的Agent.Chat端点并且和普通服务一样在注册中心注册Agent 与服务的差别只在于职责——Service 暴露的是能力capabilityAgent 暴露的是智能intelligenceAgent 内部编排这些能力两者处于同一抽象层——同一个包、同一个水平、同一种通信方式RPC。文档给出了这一对称性的直观代码micro.NewService(task) // creates a service micro.NewAgent(task-mgr) // creates an agent (which is also a service)从源码看这一对称性在 micro.go 中得到兑现NewService与NewAgent是两个语义平行的构造函数NewAgent内部只是把agent.Name(name)追加到选项列表后委托给agent.New。也就是说Agent 复用了服务层全部基础设施注册中心、客户端、存储、broker而不是另起炉灶。Agent 接口定义type Agent interface { Name() string Init(...AgentOption) Options() AgentOptions Ask(ctx context.Context, message string) (*Response, error) Run() error Stop() error String() string }接口的语义可以划分为三组方法语义Name()/Init(...)/Options()/String()生命周期与元信息取名字、应用选项、读取配置Ask(ctx, message)编程式 API发一条消息得到一个结构化ResponseRun()/Stop()以服务方式运行/停止启动真实 RPC server在注册中心注册Agent.Chat端点并阻塞需要说明的是实际实现 agent/agent.go 中的接口比文档多一个Stream(ctx, message) (ai.Stream, error)方法——这是流式对话扩展Stream适合即时取词更重要的聊天场景而带工具编排的完整 Agent 运行仍走Ask。Ask返回的Response在实现中还包含RunID与ParentID字段agent/agent.go用于把本次运行与工具调用、trace span、持久化 run timeline 关联起来被委派的子 Agent 运行则通过ParentID记录血缘。二、Proto 定义Agent 就是一个 RPC 服务Agent 的对外接口由 protobuf 定义agent/proto/agent.proto与文档给出的最小示例相比仓库中的agent.proto已扩展出StreamChat流式端点、parent_id与run_id字段service Agent { rpc Chat(ChatRequest) returns (ChatResponse) {} rpc StreamChat(ChatRequest) returns (stream ChatResponse) {} } message ChatRequest { string message 1; string parent_id 2; // 关联派发本请求的工作流/Agent 运行 } message ChatResponse { string reply 1; string agent 2; repeated ToolCall tool_calls 3; string run_id 4; // 关联工具调用、trace 与 run history string parent_id 5; // 委派子 Agent 运行时设置 } message ToolCall { string id 1; string name 2; string input 3; string result 4; }一旦 Agent 以服务方式运行任何 go-micro 客户端都可以直接调用它无需任何特殊协议micro call task-mgr Agent.Chat {message: What tasks are overdue?}这条命令会经由标准client.Call打到task-mgr的Agent.Chat端点。从实现看agent/agent.go 中的Chat方法就是标准的 proto handler 签名func(ctx, *ChatRequest, *ChatResponse) error内部把请求转交给ask再把Response的Reply、Agent、RunID、ParentID及工具调用序列回填到响应中。三、AgentOptionsAgent 的完整配置面文档列出了 Agent 的核心配置结构仓库实现 agent/options.go 在此基础上补充了大量字段。下表把两者合并标注默认值依据newOptions中的初始化逻辑type AgentOptions struct { Name string // Agent 名称 Services []string // 该 Agent 负责管理的服务决定工具作用域 Prompt string // 系统提示词身份、领域知识、行为边界 Provider string // LLM 提供商anthropic、openai、gemini、ollama 等 Model string // LLM 模型名可选 APIKey string BaseURL string // 非默认端点本地 Ollama、代理 Address string // Agent 服务端点地址 Registry registry.Registry // 服务发现默认 registry.DefaultRegistry Client client.Client // 调用服务端点与其他 Agent默认 client.DefaultClient Broker broker.Broker // Agent 服务端点的消息总线 Store store.Store // 默认记忆的底层存储默认 store.DefaultStore HistoryLimit int // 保留的最大对话轮数默认 50 Memory Memory // 可插拔对话记忆默认store 持久化记忆 // 模型与工具的超时/重试 ModelTimeout time.Duration // 每次 provider Generate 调用超时默认 30s ModelMaxAttempts int // provider 生成尝试次数默认 1重试需显式开启 ModelRetryBackoff time.Duration // 瞬时失败基础退避默认 100ms ToolTimeout time.Duration // 每次工具执行超时默认 30s ToolMaxAttempts int // 工具执行尝试次数默认 1 // 护栏Guardrails MaxSteps int // 每次 Ask 的最大工具调用数0 不限 LoopLimit int // 相同工具相同参数的最大重复次数默认 30 关闭 Approve ApproveFunc // 人机协同/策略闸门在每个动作执行前调用 // x402 付费工具预算 MaxSpend int64 ToolSpend map[string]int64 Payer x402.Payer Budget int64 // 其他 Checkpoint flow.Checkpoint // 与 flow 共享的持久化运行后端 A2AAddress string // 直接以 A2A 协议提供该 Agent如 :4000 TraceProvider trace.TracerProvider TraceInputs bool // 是否在可观测记录中写入原始用户消息默认 false }几个值得注意的默认值与细节LoopLimit默认开启且值为 3agent/options.go。设计注释解释了原因相同参数的重复调用必然是无进展死循环永远不会有价值MaxSteps只能限制总量只有LoopLimit能识别同一动作重复执行。模型与工具重试默认关闭MaxAttempts1。原因很实在一次 provider Generate 会跑完整个工具执行回合自动重试等于重放已执行过的、可能有副作用的工具调用工具同理有副作用前请先保证幂等。Approve只对动作生效——服务工具与delegate会被闸门拦截而内部的plan工具不经过审批agent/options.go。函数式选项文档中的选项在 micro.go 中以AgentXxx前缀暴露给顶层包。示例agent : micro.NewAgent(task-mgr, micro.AgentServices(task), micro.AgentPrompt(You manage tasks. You understand deadlines and priorities.), micro.AgentProvider(anthropic), )常用选项速查顶层函数作用micro.AgentServices(names...)设置 Agent 管理的服务micro.AgentPrompt(p)设置系统提示词micro.AgentProvider(p)设置 LLM 提供商micro.AgentModel(m)/micro.AgentAPIKey(k)/micro.AgentBaseURL(url)模型、密钥、自定义端点micro.AgentMaxSteps(n)/micro.AgentLoopLimit(n)步数上限与循环检测micro.AgentApproveTool(fn)人机协同审批钩子micro.AgentMemory(m)自定义记忆实现micro.AgentWrapTool(...)注册工具执行中间件日志、指标、重试micro.AgentWithCheckpoint(c)/micro.AgentResume(...)持久化运行与恢复micro.AgentMaxSpend(...)/micro.AgentToolSpend(...)/micro.AgentPayer(...)/micro.AgentBudget(...)x402 付费工具预算控制四、可插拔组合与 Service 相同的中间件哲学文档强调Agent 的组装方式与 Service 完全一致——一组小型的、带可用默认值的可插拔部件部件默认实现如何替换Model第一个注册的 providermicro.AgentProvider/micro.AgentModelMemorystore 持久化、重启不丢micro.AgentMemory(m)ToolsAgent 负责的服务RPCplan/delegatemicro.AgentTool(name, desc, schema, fn)注册任意函数Guardrails循环检测开启micro.AgentMaxSteps、micro.AgentLoopLimit、micro.AgentApproveToolTool middleware无micro.AgentWrapTool(...ai.ToolWrapper)包装工具执行Memory 接口type Memory interface { Add(role, content string) Messages() []ai.Message Clear() }仓库实现 agent/memory.go 与文档一致且提供了多个构造器NewMemory(store, key, limit)默认的持久化记忆。进程内保留一份截断到limit条的对话缓冲同时写入 storeAgent 重启后从 store 恢复现场NewInMemory(limit)非持久化仅进程内NewRetrievalMemory(store, key, activeLimit)活动上下文有界但每一轮都被归档供确定性召回RecallNewCompactingMemory(store, key, maxMessages, keepRecent)超过maxMessages后把旧轮次压缩成摘要消息最近keepRecent轮保持原文。值得强调的是默认的Recall是确定性、与 provider 无关的agent/memory.go按查询词在归档消息中的出现次数打分排序不依赖 embedding 或模型调用需要语义召回时用实现MemoryRecall接口的自定义后端替换即可。工具中间件AgentWrapTool工具执行链路采用了与 client/server wrapper 相同的洋葱模型。从 agent/builtin.go 的toolHandler可以看到执行栈的完整组装developer wrappers最外层可观察一切包括护栏拒绝 → trace → context → planWrap维护计划 → stepWrapMaxSteps 步数上限 → loopWrapLoopLimit 循环检测 → spendWrapx402 预算预留 → approveWrap人机审批 → checkpointToolWrap持久化记录 → toolRetryWrap可选重试 → x402PayWrap402 挑战付费 → toolTimeoutWrap工具超时 → baseHandler自定义工具 / delegate / RPC 调用最内层micro.AgentWrapTool允许开发者在护栏之外、最外层插入自己的包装逻辑因此能观察到每次调用及其结果包括被护栏拒绝的调用micro.NewAgent(worker, micro.AgentWrapTool( func(next ai.ToolHandler) ai.ToolHandler { return func(ctx context.Context, call ai.ToolCall) ai.ToolResult { res : next(ctx, call) log.Printf(id%s tool%s, call.ID, call.Name) return res } }))五、Scoped ToolsAgent 的工具作用域文档指出Agent 只能看到分配给它的服务的端点同时排除自身端点防止 Agent 调用自己。实现位于 agent/agent.go 的discoverTools从ai.Tools发现注册中心里的全部端点过滤掉以a.opts.Name .开头的自身端点若设置了Services只保留以任一所属服务名开头的端点追加开发者用WithTool注册的自定义工具非临时ephemeralAgent 再追加内置工具plan、delegate、request_input。这套作用域机制让task-mgr 只管 task 服务成为结构性保证而不是提示词约定。六、内置能力plan 与 delegate内置工具不是服务端点而是 Agent对自身和对其他 Agent 的能力。它们被直接接进 Agent 的工具处理器——没有独立的 harness、循环引擎或图引擎LLM 像调用任何工具一样调用它们agent/builtin.go。plan保持方向感面对多步任务Agent 记录一个有序计划一系列步骤每步包含task与statuspending/in_progress/done。计划持久化到 store并在后续轮次回显进系统提示词让 Agent 始终知道自己进行到哪一步database agent, table {name}: plan — current plan从实现看handlePlan会把计划写入 Agent 的作用域 store键为planbuildPrompt则把已保存的计划追加进系统提示词agent/agent.gocompleteNextPlanStep会在某个步骤对应的工具成功执行后自动把状态翻转为done。此外planWrap还充当纪律约束存在未完成计划步骤时禁止 delegate必须先完成计划再委派。delegate委派优先delegate工具把自包含子任务交给另一个 Agent解析顺序为Delegate-first目标注册中心里有对应 Agent即某服务在 metadata 中声明typeagent→ 通过 RPCAgent.Chat发送子任务。智能保持分布式——领域专家 Agent 处理自己的服务否则创建一个专注的临时子 AgentNew(...)Ask(...)给它全新、隔离的上下文询问子任务后即销毁若to是http://或https://URL则走 A2A 协议调用外部框架的 Agent。子 Agent 只是另一个 Agent——没有新的 spawn/fork 概念。临时子 Agent不加载也不持久化任何历史且没有内置工具因此它不能 plan、不能再次 delegate——这从机制上限制了递归深度agent/builtin.go 的handleDelegate展示了完整实现。这些能力会自动附加到任何非临时 Agent 上因此既有NewAgent服务和micro chat路由免费获得这些能力。request_input请求人工输入顺带一提仓库内置工具中还包含request_input当 Agent 需要缺失信息、决策或人工指示时暂停运行运行被以input-required状态持久化等待人工输入后恢复——对应 CLI 的micro agent resume-input。七、记忆持久化Agent 状态隔离在自有表空间Agent 把对话历史持久化到 store重启后记忆仍在。更关键的是状态隔离每个 Agent 的状态通过store.Scope被限定在自己的表空间内数据库agent表{name}因此 Agent 之间、Agent 与服务/流程之间不会共享全局表database agent, table {name}: history — conversation history plan — current plan实现上stateStore()对底层 store 做store.Scope(s, agent, a.opts.Name)处理agent/agent.go作用域句柄在每次操作时注入 database/table而不修改底层 store 本身。这也是micro agent history task-mgr能展示某 Agent 独有对话的底层原因。八、Durable Ask / StreamAskCheckpoint 运行恢复Agent 可以通过micro.AgentWithCheckpoint(...)接入与 flow 相同的检查点后端。启用后每次Ask或StreamAsk运行都会持久化输入、终态、响应和工具调用记录全部落盘。关键场景如果进程在某个工具已完成、但模型尚未返回最终答案时崩溃或断线用相同的 checkpoint store 重启 Agent然后调用micro.AgentResume(ctx, ag, runID) // 普通恢复 micro.AgentResumeStreamAsk(ctx, ag, runID) // 流式恢复恢复时的行为对应 agent/checkpoint.go 的resume实现已完成的运行直接从 checkpoint 反序列化响应返回不重新调用模型暂停paused置回 running 并继续进行中/失败的运行从保存的输入消息继续执行askLocked会复用同一runID已完成的工具调用直接由 checkpoint 提供不会再次执行——即不重放副作用。同时MaxSteps、循环检测、审批暂停、request_input暂停等护栏对恢复后的运行继续生效。仓库还提供agent.Pending/agent.ResumePending顶层为micro.AgentResumePending用于启动恢复循环时按最旧优先顺序排空所有未完成的持久化运行。micro.AgentResumeInput(ctx, ag, runID, input)则专门恢复等待人工输入的运行。九、注册Agent 是带 metadata 的真实服务Agent 通过server.NewServer注册为真实服务附带 metadataserver.Metadata(map[string]string{ type: agent, services: task,project, })这段 metadata 在 agent/agent.go 的Run中实际生效。该 server 拥有真实地址、真实 transport、真实端点。micro agent list正是通过检查 server metadata 中的typeagent来发现 Agent 的delegate判断目标是否为 AgentisAgent同样依赖这段 metadata。十、Routermicro chatmicro chat是一个路由器从注册中心发现 Agent 并通过 RPC 分发一个 Agent→ 直接client.Call(agentName, Agent.Chat, ...)路由多个 Agent→ LLM 对意图分类调用route_to_agent工具没有 Agent→ 回退到直接访问服务当前行为。十一、Agent 间通信就是 RPCAgent 之间通过标准 RPC 互相调用。Agent 是服务有Agent.Chat端点因此任何 Agent 都可以像调用服务一样调用其他 Agent// From inside an agents logic, call another agent: client.Call(comms-mgr, Agent.Chat, ChatRequest{Message: Notify Alice})没有特殊协议、没有 broker topic只有 RPC。跨框架A2A 网关以上覆盖了 go-micro 系统内部的 Agent。要让 Agent 覆盖到其他框架——也让其他框架的 Agent 能到达你的——存在A2A 网关gateway/a2a用micro a2a serve运行它是 Agent 侧的 MCP 网关对等物。它从注册中心发现 Agent基于每个 Agent 的 metadata 生成 Agent Card。十二、用法模式单服务 Agentagent : micro.NewAgent(task-mgr, micro.AgentServices(task), micro.AgentPrompt(You manage tasks.), micro.AgentProvider(anthropic), ) agent.Run()多服务 Agentagent : micro.NewAgent(project-mgr, micro.AgentServices(task, project, milestone), micro.AgentPrompt(You manage the project system.), micro.AgentProvider(anthropic), ) agent.Run()编程式调用agent : micro.NewAgent(support, ...) agent.Init() resp, _ : agent.Ask(ctx, What tickets are open?)Agent 与服务并存func main() { svc : micro.NewService(task) svc.Handle(new(TaskHandler)) agent : micro.NewAgent(task-mgr, micro.AgentServices(task), micro.AgentPrompt(You manage tasks.), micro.AgentProvider(anthropic), ) go svc.Run() agent.Run() }十三、CLI 操作文档给出了完整 CLI 面仓库在 cmd/micro/cli/agent/agent.go 中实现并新增了preflight、doctor、demo等辅助命令micro agent list # 列出运行中的 Agent注册中心typeagent micro agent describe task-mgr # 显示 Agent 详情 micro agent history task-mgr # 显示存储的对话作用域 store micro agent history task-mgr run-id # 显示某次运行的完整历史支持 --json/--status/--trace/--limit micro agent resume-input task-mgr run-id --input text # 用人工输入恢复 input-required 运行 micro agent preflight # 首次运行前检查本地前置条件 micro agent doctor # 诊断 chat/gateway/注册/provider/恢复问题 micro chat # 自动路由到 Agent micro call task-mgr Agent.Chat {message: ...} # 直接 RPClist与history/runs的分工在服务、Agent、流程之间保持一致list展示正在运行的组件来自注册中心按类型过滤history/runs展示持久化状态来自作用域 store无论组件当前是否在运行都可查看。micro flow list # 列出运行中的 flow注册中心typeflow micro flow runs checkout # 某 flow 的持久化 run 历史作用域 store十四、生成micro run --promptmicro run --prompt会同时生成服务和Agentmicro run --prompt task management system Generated: task/ ← service project/ ← service agent/ ← agent (manages task, project)生成的 Agent 从环境变量MICRO_AI_PROVIDER与MICRO_AI_API_KEY读取 LLM 提供商与密钥。十五、什么没有改变Agent 的引入是增量的不破坏任何既有用法服务仍然是服务——同样的接口、同样的代码、同样的部署方式可以只运行服务、不运行 Agent可以直接通过micro call、API 或 MCP 调用服务框架接口registry、client、server、store完全不变micro run、micro deploy、micro build行为不变。结语从源码看 Agent 的设计取舍结合 agent/agent.go、agent/options.go、agent/builtin.go 等实现可以看到go-micro 的 Agent 设计贯彻了三个核心取舍以 Service 为底座复用全部基础设施、以可插拔部件为扩展点Model/Memory/Tools/Guardrails 均可替换、以持久化为可靠底线记忆、计划、运行检查点全部落盘并可恢复。如果你要动手实践仓库提供了从 first-agent 到 agent-demo、agent-durable持久化运行等一系列可直接运行的示例。赞分享后端微服务AI AgentRPC框架【免费下载链接】go-microA Go agent harness and service framework项目地址https://gitcode.com/gh_mirrors/go/go-micro点击查看免费下载相关推荐Astryx 组件契约规范用 component-spec 模板承载 Agent 可读的设计系统知识Astryx 组件契约规范用 component spec 模板承载 Agent 可读的设计系统知识 Astryx 是一个fully customizabl前端UI组件设计系统在 Windsurf 中落地 agent-skills用 .windsurfrules 承载工程技能的完整配置指南在 Windsurf 中落地 agent skills用 .windsurfrules 承载工程技能的完整配置指南 agent skills 是一组面向 AIAI 技能开发工具AI 评测Benchmarkany-agent实现多Agent框架统一接口的Python库any agent实现多Agent框架统一接口的Python库 项目介绍 any agent 是一个由Mozilla AI团队开发的Python库旨在为开发上一篇推荐开源项目TBPlayer - 强大的视频播放与缓存解决方案下一篇探索gRPC-Rust高性能的RPC框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考