一次被 Metadata Lock 隐藏的 AI 聊天故障：从 CommunicationsException 到长事务排查

这篇文章记录一次线上故障：Java 应用里一条普通查询，最终抛出来的是 CommunicationsException。表面看像网络或连接池问题，实际是被 DDL 等待放大的 metadata lock。 排查过程横跨 4 层： MySQL DDL 与 metadata lock 机制 JDBC 驱动的超时表现 连接池里的空闲连接与未结束事务 应用层对异常语义的误判 先说结论根因是： 某些旧
AI
#AI工作日志 #Spring Boot #MySQL #MyBatis #Druid #故障排查 #后端工程

本地启动 iot-app 禁用 Kafka 配置实践

本地联调 iot-app 时，常见诉求是继续读取 Nacos 里的大部分配置，但不要连接 Kafka。直接把 Nacos 配置删掉通常不现实，因为同一个应用还依赖数据库、Redis、业务开关等其他远程配置。 这次采用的做法是：保留 Nacos 配置加载，只在 local 环境禁用 Kafka 自动装配和消费者注册，同时提供一个 no-op KafkaTemplate，让依赖 KafkaTempla
后端
#Java #Spring Boot #Kafka #Nacos #本地开发

HBuilderX 改了 uni-app 代码后，怎么在微信开发者工具里看到更新

这篇整理一次最近联调 uni-app 小程序时连续踩到的几个坑： 改了 accountPage.vue 和 pages.json，微信开发者工具里就是看不到更新 HBuilderX 运行到微信开发者工具时，微信侧没有自动拿到最新项目 登录时报错： 1login:fail 系统错误，错误码：41002, appid missing [undefined] 本机 Java 服务联调时报错： 1
#uni-app #微信小程序 #HBuilderX #微信开发者工具 #联调

单模型编排四阶段改造复盘：从提示词、护栏到记忆与清理

这次复盘对应 sample_ai_service 近期一轮比较完整的单模型编排内核治理。目标不是“再做一套新框架”，而是在不改外部 API 契约、不打乱 SSE 事件语义的前提下，把原本耦合较重的编排实现，收敛成可以继续演进的 runtime 分层。 先给结论：这轮改造真正完成的，不是几个 helper 函数的搬家，而是把项目推进到了“单 LLM 编排 + Java MCP 工具执行”的清晰架构上
AI
#AI工作日志 #FastAPI #MCP #Guardrails #Memory #AI编排 #Prompt Engineering #工程复盘

项目技术选型调研：通用Agent与LangGraph+LlamaIndex对比

这篇文章基于实际业务场景（原子查询工具 + RAG 分析）给出技术选型依据，重点对比 OpenClaw 这类强 Agent 项目与 LangGraph + LlamaIndex 组合方案。 1. 调研结论（先给结论）对于当前项目定位（“可控的数据查询与分析助手”，而非“全自主代码代理”），推荐主选型为： 编排内核：LangGraph 数据/RAG 层：LlamaIndex 工程护栏参考
AI
#技术选型 #LangGraph #LlamaIndex #OpenClaw #Agent Engineering #AI工作日志

单 LLM 节点不是简化：OpenClaw Prompt 注入范式与护栏工程化重构

前言这篇文章写给已经在做 Agent 编排、并且踩过“意图层拆太多 + Prompt 越改越乱 + 护栏和主流程耦合”坑的工程师。 核心观点先摆在前面： 单 LLM 节点不是“把所有事都丢给模型”。 OpenClaw 的关键价值，不在“单节点”，而在“模型自决 + 工程护栏 + Prompt 注入可插拔”。 真正可维护的实现，必须把 决策、注入、护栏、记忆 四层切开。 一、单节点到底是什么：
AI
#OpenClaw #Agent Engineering #AI工作日志 #ReAct #Prompt Injection #Guardrails #Memory

从双层意图到单 LLM 自决：OpenClaw 范式与护栏工程化落地

很多 AI 编排系统一开始都会走到同一个架构： 先做 intent parser（判定 chat / tool） 再进入 ReAct（plan/act/observe） 这套架构可控，但随着需求复杂化，经常出现三个问题： 决策重复（先判一次 intent，再让 planner 再判一次） 状态割裂（intent 状态和 tool 状态不同步） prompt 分裂
AI
#OpenClaw #AI工作日志 #Memory #AI Orchestrator #Tool Guardrails #Function Calling

从零把 uni-app 接到微信开发者工具：HBuilderX 全流程与踩坑复盘

这篇写给后端同学：不懂前端也能把 uni-app 项目跑到微信开发者工具里预览页面。 核心结论先说： uni-app 源码目录不能直接当小程序目录导入微信开发者工具。 必须先用 HBuilderX 编译，拿到 unpackage/dist/build/mp-weixin 产物。 再让微信开发者工具打开这个产物目录（或通过 project.config.json 的 miniprogramRoot
#uni-app #微信小程序 #HBuilderX #工程化 #踩坑

AI Chat 网关化重构工作日志：Java AI Gateway 签名上下文与 Python 鉴权落地

本篇记录本次 AI Chat 网关化重构的落地结果，重点是把请求入口、认证与业务上下文注入统一收口到 Java 网关，再由 Python 控制平面执行编排。 改造摘要 Java 成为 AI Gateway 统一入口： 前端不再直连 Python，而是走 /api/mock-ai/*。 Java 在转发到 Python 前注入两类内部头： X-AI-GW-TOKEN X-AI-BIZ-CONTE
AI
#AI工作日志 #AI网关 #Java #Python #FastAPI #鉴权 #联调复盘 #SSE

基于 OpenClaw 对照改造 iot-framework AI Orchestrator：终结非工具问题 CLARIFY 循环

背景这次改造聚焦一个真实线上体验问题：用户问的是通用解释类问题（本质不需要工具），Orchestrator 仍然进入 ReAct 规划，随后触发 CLARIFY，并在后续交互里反复追问，形成“看起来一直要补信息”的循环感。 目标很明确：在不扩大系统复杂度的前提下，借鉴 OpenClaw 的分层思路，把“是否需要工具”尽早判定，把 CLARIFY 收紧到真正可执行的场景，让非工具问题直接回到 CHA
AI
#OpenClaw #AI工作日志 #FastAPI #ReAct #Orchestrator #CLARIFY #奥卡姆剃刀