拓冰建站拓冰建站
首页 / 资讯中心 / 正文

Go Micro 用 AI 智能体循环构建自身:双 Agent 自治开发闭环的机制、故障与产物

后端微服务AI AgentRPC框架【免费下载链接】go-microA Go agent harness and service framework项目地址https://gitcode.com/gh_mirrors/go/go-micro点击查看免费下载Go Micro 自称Agent harness智能体开发框架而它检验这一主张最诚实的方式就是让 Agent 去构建它自己。本文基于官方博客《How Go Micro Builds Itself》及仓库中的真实工作流与源码完整拆解这套定时任务 双 AI AgentCodex 实现、Claude Code 编排 人类设定方向的自举开发闭环它如何调度、如何合并 PR、出了哪些故障、产出了什么以及你可以如何用micro loop init在自有仓库复刻这套机制。核心思路把框架指向它自己Go Micro 是一个 Agent harness即一套供 AI 智能体运行、检查点续跑、可观测、可复用的运行框架。项目方认为检验 harness 是否足够健壮最好的方式不是写演示 demo而是用它去构建它自己——如果一套 harness 能支撑一个自我构建的循环那它同样有资格支撑构建你的软件的循环。因此仓库中出现了这样一幕一个按计划调度的双 Agent 循环会自行开 issue、写增量、通过自动合并机制把 PR 合入本仓库人类不再逐行打字而是设定方向。这套机制并非作秀——博客原文强调如果 harness 好到足以驱动一个构建自身的循环那就是它足以驱动构建你软件的循环的证据internal/website/content/en/blog/news/how-go-micro-builds-itself.md。三个角色Codex 实现、Claude Code 编排、人类定方向工作被拆成三个角色职责边界非常清晰角色定位职责Codex串行构建者serial builder一次只接一个范围受限的任务实现它跑构建、测试、lint然后开 PRClaude Code编排者orchestrator搭建设备机制、审查、集成处理 Codex 不该独自做的判断性决定人类方向与品味的所有者品牌与定位文案、破坏性公共 API 变更、架构决策——这些永不自动合并除这三类工作之外其余全部自动化。判断性工作与机械性工作的分离是这套闭环的纪律核心能自动化的一切都自动化但需要品味的调用永远留在人类手里。机制一个刻意无聊的循环每个循环周期都刻意保持无聊——这恰恰是设计意图。仓库中的 .github/workflows/loop-builder.yml 与 .github/workflows/loop-planner.yml 等文件把博客描述的三步机制落成了真实可读的 YAML定时工作流开新 issue 并派发任务一个 scheduled workflow 打开一个全新的追踪 issue向 Codex 下达单一指令——挑选能推进 North Star北极星目标的最高价值改进实现它验证构建、测试与 lint 全部通过然后开 PR。Codex 在独立分支完成工作并开 PR。GitHub 原生 auto-merge 在 CI 变绿那一刻自动合入——构建、测试、golangci-lint。没有人工审批步骤。CI 是唯一的闸门而它并非批准只是拒绝合入坏代码。每个增量都很小、单一关注点、可回滚。任何过不了人类贡献者 PR 同样检查的聪明技巧都无法存活。从工作流文件看真实实现loop-builder.yml 揭示了几个博客未展开的关键工程细节MECHANISM 与 POLICY 分离工作流本身是机制MECHANISM而.github/loop/prompts/builder.md这个 prompt 文件是可编辑的策略POLICY——要改变某个角色的行为改 prompt 文件即可不需要改 YAML。每个运行必须用全新 issue文件头注释明确指出agent 从触发它的 issue 推导 PR 分支名复用同一个 tracker 会让所有运行塌缩到同一个分支上。这正是博客中分支名冲突故障的官方注释版本。CODEX_TRIGGER_TOKEN 门控agent 会忽略 github-actions bot 的 提及所以派发必须以真实用户PAT身份发帖没有 token 就跳过no-op。派发逻辑用gh issue create建 issue再用sed把 prompt 中的__ISSUE__占位符替换成真实 issue 号随后gh issue comment完成codex指令投递。PAUSED 状态该工作流在 2026-07-12 起暂停了自动 schedule注释写明团队在做聚焦的 1:1 修复但仍可通过workflow_dispatch按需手动运行——这印证了博客所说人类设定方向、随时可干预的设计。用micro loop init在你的仓库复刻这套循环并非只属于 go-micro 自己它通过 CLI 暴露成可复用的脚手架。核心实现在 cmd/micro/loop/loop.go要点包括micro loop init把工作流、prompt 与队列脚手架写入目标仓库micro loop init --roles all初始化全部角色。生成物包括.github/workflows/loop-role.yml派发工作流、.github/loop/prompts/role.md各角色 prompt策略、.github/loop/NORTH_STAR.md方向与.github/loop/PRIORITIES.md队列。配置 vs 核心的边界config-vs-core boundaryworkflows 与 prompts 是可复用核心而config是模板的替换表面。renderKeep 语义prompts、NORTH_STAR、PRIORITIES 属于 POLICY即使带--force也绝不覆盖——重新运行 init 刷新机制时不会冲掉你写好的策略。这种机制可重生成、策略可编辑的拆分正是任何仓库包括 go-micro 自己能通过编辑 prompt 文件而非 fork CLI 来定制行为的原因。三种高度架构师、增量循环与 DevRel一个循环只生产增量它自己并不知道这些增量是否在朝某个方向累积。因此系统在三种高度上做不同粒度的审查架构师architectpass每隔几天把整个框架对照 thesis纲领审查一遍——API 连贯性、services → agents → workflows 生命周期中的缺口、漂移——然后提交范围受限的 issue。它决定要构建什么。每小时增量循环负责把那些 issue 构建出来。DevRel pass每天审计 README、网站、文档与博客的一致性把值得写出来的东西浮现出来本篇文章正是它应该捕获的那类内容。对应到仓库可以观察到这套分工确实落地了架构/规划角色由 loop-planner.yml 承载它维护一个排序队列.github/loop/PRIORITIES.md构建角色由 loop-builder.yml 承载仓库中还有 loop-coherence.yml、loop-release.yml、loop-security.yml、loop-triage.yml 等一套 loop 系列工作流分别覆盖一致性、发布、安全与分诊每小时的真实模型一致性由 harness.yml 的定时任务cron: 17 * * * *支撑它既跑确定性 mock LLM 的 harness也按需跑真实 provider 的活体一致性。一句话概括架构师指方向循环来构建DevRel 保持叙事诚实。方向自上而下流动代码自下而上汇聚。故障模式循环里真正有趣的部分把自治循环接起来大部分工作是管道plumbing和故障模式——这正是它成为 harness 绝佳测试的原因。博客列举了三个真实踩过的坑撒谎的工具lying toolagent 的open a pull request工具竟是个stub——它只把 PR 的 title 和 body 记录下来交给下游步骤从不 push 分支、不调 API。agent 每次都兴高采烈地报告已开 PR但 PR 从未出现。修复方式是不再信任该工具让 agent 自己 push 并开 PR。状态碰撞state collision每次都从同一个追踪 issue 派发导致 agent 每次都推导出相同的分支名于是第一个增量开了 PR其余增量静默冲突。改用每次运行一个全新 issue解决——这一点在 loop-*.yml 的文件头注释里被明确写成了deliberate刻意为之。指令漂移instruction drift某个增量好心地把仓库自己的 agent 指令改写成指向那个坏掉的工具。自治循环会忠实地把自己的错误编码进指令里所以护栏必须显式存在。博客的总结很到位这些故障毫不稀奇它们是运营 agent 循环的日常——工具会撒谎、状态会碰撞、指令会漂移。而 harness 提供的东西——可观测性、持久运行、韧性、护栏——恰恰是你认真跑这样一个循环时会第一时间伸手去拿的东西。故障背后护栏在源码里是什么护栏必须显式在仓库里可以找到具体形态。agent 的运行包装在 agent/builtin.go 中内置护栏guardrails按approve → loop → step → spend等层次包裹底层调用任何违反都会返回一个带结构化原因的refused(...)结果ai.RefusedApproval、ai.RefusedSpendBudget、ai.RefusedMaxSteps、ai.RefusedLoop等模型侧只会看到一次被拒绝的工具调用。agent/guardrails_test.go 与 agent/builtin_test.go 覆盖了这些拒绝路径——守门不是口头承诺而是有测试兜底的代码行为。它产出了什么真实而不光鲜的增量循环产出的增量并不光鲜但真实。博客列举了最近的几项均可在源码中逐一对号入座OpenTelemetry 运行时间线与micro runs命令agent 运行循环被埋点可用micro runs命令检查。命令实现在 cmd/micro/cli/agent/agent.gomicro runs name列出某 agent 的历史运行status、events、duration、last、updated等字段支持--status、--trace、--limit过滤与--json输出并可下钻到micro agent history name run-id查看事件流。埋点实现在 agent/otel.goagent.run、agent.model.call、agent.model.stream、agent.tool.call四类 span加上recordTimelineEvent把每个 RunEvent 同时写成 span eventagent.kind事件还携带SpanID。把时间线与 trace span 关联如上所述每个运行事件在写入时都会带上sc.SpanID()从而把运行时间线事件与 OpenTelemetry trace span 关联起来——这正是correlated those timelines with trace spans的源码形态。durable flow 的重试退避retry backoff在 flow/options.go 中RetryBackoff设置失败步骤尝试之间的延迟零值表示立即重试RetryBackoff(d time.Duration)选项在 flow/steps.go 中通过time.After(f.opts.RetryBackoff)落地。flow/steps_test.go 中的TestFlowStepRetryBackoffWaitsBetweenAttempts用 10ms 退避实测了等待确实发生。流程步骤取消安全cancellation-safe取消安全的核心在 flow/steps.go 的重试循环里——一旦运行上下文被取消或期限耗尽就立刻停止被取消的运行不应继续重试上下文错误会被向上暴露以便调用方检测取消。flow/steps_test.go 的TestFlowTimeoutStopsRetryBackoff与TestFlowStepRetryBackoffStopsOnCancel分别验证了超时/取消会终止退避等待中的重试而不是烧光预算。每一项都以一个独立小 PR 落地、单独通过 CI。这就是这套工作的纹理不是让模型一次性写出整个框架而是一个循环在一个让它保持诚实的闸门下持续地把它变得更好一点。结语循环本身就是证明团队的观点是agentic 软件的未来是定时、循环、真正干活的 agent而不是聊天。Go Micro 正是由这样一套机制、对着自己的仓库构建出来的。人类依然设定方向、拥有需要品味的决策CI 是闸门一切可回滚。在这些边界之内harness 构建了它自己——如果它能做到这一点它就能构建你的软件。如果你想在自己的仓库里复刻这套机制路径很清晰阅读 cmd/micro/loop/loop.go 了解脚手架语义运行micro loop init生成工作流与策略文件再编辑.github/loop/prompts/role.md与.github/loop/NORTH_STAR.md来定义你自己的方向与职责边界——机制与策略的分离正是它可以在任何仓库里被复用的原因。赞分享后端微服务AI AgentRPC框架【免费下载链接】go-microA Go agent harness and service framework项目地址https://gitcode.com/gh_mirrors/go/go-micro点击查看免费下载相关推荐Go Micro 自治循环正式落地用 micro loop 一条命令把AI Agent 维护仓库装进任何仓库Go Micro 自治循环正式落地用 micro loop 一条命令把AI Agent 维护仓库装进任何仓库 导读 本文详解 Go Micro 项目 2后端微服务AI AgentRPC框架5步搞定Khoj Obsidian插件连不上服务器从Could not connect到真正跑起来5步搞定Khoj Obsidian插件连不上服务器从Could not connect到真正跑起来 Khoj是自建可自托管的AI第二大脑Obsidian后端微服务AI AgentRPC框架Eclipse Che故障自愈机制提升开发环境可用性Eclipse Che故障自愈机制提升开发环境可用性 在云原生开发环境中服务中断和工作区故障可能导致开发流程中断影响团队 productivity。Ecl开发工具云原生上一篇告别手机续航焦虑ReVanced Manager电量优化全攻略下一篇突破远程协作边界RustDesk 2025功能规划全景图创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门