开发日志 2026-09-18：微服务本地全链路验证、基线陷阱与多 Agent 巡检机制#

前言#

今天的主线是两件事：把一套 Java 微服务项目在自己的 Mac 上从零跑通并验证核心链路，以及在多 Agent 协作的工作流里继续打磨「自动化巡检」这套基础设施。中间还撞上了一个很典型的隐蔽问题——你以为你在验证最新代码，其实不是。照旧，把真实过程和踩坑记下来。

一、把一套 Java 微服务在本地完整跑起来#

接手类项目最怕「纸上谈兵」：文档看了三遍，不如服务真正起来一次。今天的目标就是在一个 Mac 开发机上，把一套 Spring Cloud 架构的微服务项目（10 个服务左右）完整跑通，并验证从前端到数据库的核心链路。

整体步骤比想象中顺：

• 配置中心先行：Nacos 2.4.3 以 standalone 模式启动、配置存储挂外部数据库。这一步的关键检查点是「配置真的拉到了」——12 个配置文件逐个确认非空，而不是只看控制台启动无报错
• 依赖服务补位：微服务的 Redis 配置写的是 localhost，本地用 Homebrew 装一个补上
• 构建：JDK 8 + Maven 打包，10 个 fat jar 全过，没遇到缺依赖的问题
• 注册健康：全部服务起来后，逐个查 Nacos 的实例列表确认 healthy=true，而不是只看进程活着
• 链路验证：前端起 Vite 开发服务器，走一遍登录——验证码图片渲染 → 请求经网关转发 → 认证服务校验 → 用户查询落库，每一跳都有日志可对

两个值得记的细节：

一是**「服务起来了」和「链路通了」是两回事**。10 个进程全部 LISTENING、注册中心全部 healthy，只能证明「各自活着」；真正有价值的是拿一条业务请求（登录）从头穿到尾，中间任何一跳断了都会暴露。

二是已知非致命错误要「登记」而不是「消灭」。本地没部署分布式事务的 TC Server，每个服务启动时都会打一行 RM 注册失败的 ERROR 然后自动重试。这种错误在日志里很唬人，但它有明确的成因、明确的自愈行为、不影响验证目标——正确的做法是记进文档「已知非致命项」，而不是为它搭一整套不需要的基础设施。

二、验证基线过期：你验证的到底是哪个版本？#

全链路跑通之后被问了一个扎心的问题：「你的代码是最新的吗？」

拉远端一比对，坏了一半：配置中心相关的仓库是最新的，但微服务主仓库和前端仓库的本地基线落后了整整一天的更新——一千多个文件的差距，包含大量业务变更。

根因很有意思：本地的代码检出走的是「共享 bare 仓库」中转，上游的镜像同步提交（上游版本库 → git 镜像）落在我检出之后。也就是说，检出那一刻拿到的确实是当时最新的，但「当时」已经过期了。工具没错、时序错了。

这次的处理思路是把验证结论分层评估，而不是全部推倒：

• 基础设施层结论不受影响：配置中心链路、依赖服务、构建工具链——这些和业务代码版本无关，可以保留
• 业务层结论必须重验：微服务业务代码和前端都是旧版，登录链路验证的是旧版行为，新版可能引入新的启动依赖或配置项

沉淀下来的检查习惯：任何验证动作开始前，先回答「我验证的是哪个 commit」；任何验证结论输出时，带上这个 commit。听起来是常识，但在多仓库、有镜像同步延迟的环境里，这一步比想象中容易漏。

三、给多 Agent 团队做自动巡检，并治理「回声循环」#

我的日常工作流里有多个 AI Agent 协作：有拆解路由的、有写代码的、有评审的、有巡检的。人多（?）力杂，最怕的不是干得慢，而是「没人处理」的断档。今天继续迭代这套巡检机制，几个设计点：

• 断档检测：扫描所有进行中的任务，超过阈值时间没有新活动、没有认领动作的，判定疑似断档，由巡检 agent 显式 @ 责任方重新触发
• 状态一致性：「已交付但还挂着『进行中』」的任务会被修正为「待验收」——看板上的状态必须反映事实，否则所有依赖状态做决策的自动化都会被污染
• 审核链完整性：检查每条交付是否显式 @ 了接手方、待决策项是否走了固定的通知格式，缺了就补
• 失败任务检查：找最近失败的 run，区分原因后改派或上报

今天最有意思的收获是治理回声循环：巡检 agent 完成巡检后会在任务单上发一条报告，而「有新评论」又会触发被巡检对象的运行，对方的收尾评论又触发巡检 agent——几个回合下来，一群 agent 在那儿礼貌地互相打招呼，烧着 token 什么都没干。

解法是把「收口」做成显式动作：巡检场次若无待办事项，发布报告后立即把本单置终态并清空认领，断掉触发链；同时给巡检 agent 加一条「识别回声」的规则——如果触发自己的评论正是自己上一轮的产出、且全局没有任何新指令，就静默退出，不发评论、不跑巡检。

心得：多 Agent 系统里，通信本身是有副作用的。人类团队的「已读不回」是礼仪问题，agent 团队的「已读必回」是架构问题——必须在机制上给「不回复」留出合法的位置。

四、区分「任务失败」和「任务从未运行」#

今天还处理了一类基础设施故障：某个 agent 的运行时短暂离线，挂在其上的任务两次报 runtime_reconnect_timeout。

这类故障的排查有个关键证据点：任务的 started_at 是空的。这说明任务从未启动、零产出——不是执行到一半失败，而是压根没跑。两者的处置完全不同：前者要检查产出是否受损，后者只需要核实原因后重新派发。最终确认运行时恢复在线，原样重派，交付物无需重做，自愈闭环。

另一个经验是单点角色的兜底策略：出故障的角色如果是单点（没有同职能的备份副本可以改派），兜底动作就不是改派，而是「若再次失败立即升级上报」——把重试上限和升级路径提前定好，而不是失败两次之后现场开会。

结语#

今天的四个片段其实是同一个主题的四面：验证的可信度。服务全链路穿一遍才算验证、验证要绑定 commit 才可复现、看板状态要符合事实才可依赖、「任务失败」要区分「从未运行」才能正确处置。工程系统里，让信息保持真实是有成本的，而这套成本花得值。