端侧 Java 服务里有一类配置读写很容易被忽略：系统配置表看起来很小，单次 selectById 也很快，但高频轮询、状态推送、版本上报叠在一起后，会把 SQLite 打成持续背景负载。 这次要处理的不是一次慢 SQL，而是低价值的高频读写。目标也很明确：不改变业务配置语义，减少系统配置读写次数，把优化开关做成可回退能力。 现场数据监控窗口是 30 秒。某台端侧设备上的数据库监控大致是这样： 1

这次主要补的是 Agent 编码之后的下一段路：代码可以自动改了，但构建完成、镜像确认、部署调试机这几步还断在人工操作里。结果就是 Agent 写完代码以后，仍然不知道什么时候可以部署，也不知道应该拿哪一个镜像去跑调试。 最后落下来的方案没有做成一套很重的发布平台，而是先把调试闭环打通：构建脚本上报状态，后台服务记录构建产物，Agent 查询成功镜像，再调用仓库里的受控部署脚本更新调试机。 目标当

这次排查的是边缘端 Java 服务的一次现场 CPU 飙高。 现象很直接：某天 15:30 到 16:00 左右，Java 进程 CPU 很高，日志里持续报 SQLite/JDBC 连接获取失败。现场关闭“测点缓存”功能并重启后，服务恢复。这个功能之前一直开着，只有那天爆了一次，后面也没有再打开。 一开始很容易把问题归到测点缓存上：关了它就好了，那是不是缓存库坏了？但日志和库文件检查对不

一台现场小电脑通过 SSH 登录后不断刷： 12channel 3: open failed: connect failed: Connection refusedchannel 4: open failed: connect failed: Connection refused 现场刚经历过一次升级中断，第一反应很容易落到 Java 服务、SSH 配置、端口转发、Docker 容器状态这些方向

最近做了一个内部文档同步工具，目标很简单：把浏览器里有权限访问的语雀知识库定时同步成本地 Markdown，再给后续 Agent 检索、引用和 RAG 使用。 真正卡住的不是目录解析，也不是 Markdown 入库，而是登录态。Playwright 自带 Chromium、Playwright channel: "chrome"、系统 Chrome 独立 Profile 都试过

项目里有一个 app_manage，前端是 React + Vite，后端是 Python + FastAPI。最开始的问题很直接：service.sh 启动时，能不能把前端也一起拉起来，并且把 Python 服务的默认首页切到这个前端。 这类需求第一次看，很容易顺手想到 service.sh 里再后台起一个 npm run dev。它能跑，但不太像一个稳定的服务发布方案。真正要先分清的是，这个前

这次要做的需求不复杂：让 AI 助手的回答从“等几秒后整段出现”，改成“边生成边显示”的打字机效果。 一开始最容易想到的改法，是把现有的 GET /messages 改成 SSE。看起来改动小，前端也已经有一个拿消息的入口。但把链路顺下来以后，这个方向很快就卡住了，因为 /messages 在当前系统里承担的是历史投影和断线补齐，不是当前这一次提问的实时生成通道。 先把链路看清楚当前链路其实是三段

这次讨论最后收敛到的不是某一条 prompt 怎么写，而是 AI Agent 的上下文到底该怎么分层。 当时链路里已经出现了一个比较典型的问题：用户问“给我看看你的 prompts”“你的模型是什么”“你的指令是什么”这类问题时，系统虽然有安全策略，但模型还是会用自然语言复述一部分内部实现，包括 function calling、工具名、运行模式和系统约束。再往下看 prompt 结构，问题也就比

最近在收一条 AI 日志链路。诉求不复杂：AI 相关日志要单独落到 ai-chain.log，但每行日志尾巴上那串 [aiChain= aiConversationId= aiToolCallId= aiToolName=] 太重了，想砍掉大部分字段，最好日志正文里连 aiChain=true 都不要看到。 这类问题很容易改着改着偏成“怎么把日志打印得更短”，但代码顺下来以后会发现，核心不在展示，

这次改动不复杂，判断比实现更重要。 我们原来的知识问答链路是本地 Agent 自己调 knowledge.search。问题不是它查不到东西，而是查出来的结果太大，tool_result 又会进 transcript，后面的 plan、loop、verify、answer 几轮都会把这包结果再塞回 prompt。实际看下来，单次 llm_request 很快就从两三百 KB 涨到五百多 KB，最后