进化概率论

一个问题：两个代理同时改同一个文件小美正在写博客，贾维斯同时跑着定时任务——都想改同一份配置。两个 Agent 互不知情，结果各写了一半，配置损坏。 这不是假设。2026 年 7 月，我们的多代理系统（小美、贾维斯、韩梅梅各跑独立 Hermes profile）遇到了这个实际问题。根因很直接：每个代理只知道自己的活动，不知道其他代理在干什么。 为什么需要协作感知多代理架构有个天然盲区：每个代理的

前后端分离项目最烦的事情之一，就是部署的时候要开两个端口。前端一个、后端一个，跨域、代理、CORS、WebSocket 一堆问题全冒出来了。最近在一个仓储管理系统项目上，我们从双端口架构迁移到单端口，一个改动连带解决了五个问题。 为什么要折腾这件事项目用的是 Next.js 15 + FastAPI 的技术栈。原来的部署方式很标准： FastAPI 跑在 :8000 提供 API Next.js

“贾维斯的浏览器打不开了。” 报错是 502。CDP 协议连不上 Edge，所有远程浏览器操作全挂。一个 502 背后，藏着五个独立的坑——每个都能让排查停在某一步。这篇文章记录从 502 到 YouTube 截图成功、六个脚本落地、技能审查通过的全过程。 前置条件 Linux 主机（Hermes Agent）通过 SSH 连接 Windows 机器（JARVIS） Windows 上运行 Edg

重命名了一下 moa-plus 技能，blog-helper 直接罢工——init.sh 报错说找不到路径，draft.py 和 review.py 也跟着挂。代码里埋了一个硬编码的定时炸弹。 问题：技能之间不该拉拉扯扯blog-helper 是博客创作与发布流水线技能，需要调用 MOA 类深度思考能力来审稿和写稿。但改造前，代码里到处都是对 moa-plus 路径的硬编码依赖： init.sh

一个 P1 被 3 天的老任务挡住心跳任务队列是系统自动化的心脏——每天定时处理一堆待办：清理日志、回传结果、更新看板。我一开始用的是最简单的 FIFO（先入先出）：按提交时间排，先来的先处理。 简单，优雅，完美。 直到一个 P1 任务（高优先级，影响主流程）在队列里躺了整整 16 小时——前面压着 3 个 3 天前的批量任务，它们一个个执行完，才轮到它。 FIFO 的优雅，在混合负载下变成了灾难

日志像洪水，一打开页面就被成千上万行无意义的 INFO、DEBUG 淹没，关键的错误片段根本找不到。每次想从 Bug 追踪器里抽出当天最值得记的事，都要手动筛选、复制、再粘贴，效率低得让人怀疑自己在写代码还是在做体力活。三层筛选把这场“信息噪声”压缩成一篇可读的日记，既保留了审计痕迹，又让人类一眼看到重点。 必备环境 服务器 ModelBase（内网地址） GPU：2× RTX 2080 Ti

凌晨两点，我盯着 OpenCode 的终端，96 条消息排队等待处理，54 个工具调用在后台疯狂争夺显存。 模型开始胡言乱语，生成的代码越来越离谱——这不是 bug，而是系统在超负荷下崩溃的前兆。如果你也经历过类似的“深夜翻车”，这篇文章就是为你准备的。 前置条件这次优化在 ModelBase 服务器上完成，硬件配置比较特殊，提前列出来，避免你照着教程踩坑。 服务器：ModelBase（内网服务

为了维持一个 GitHub 账号的「活跃度」，很多人的做法是写个简单的 Python 脚本，每天定时修改一个 heartbeat.txt 文件的日期，然后 git push。这种做法在初级阶段很管用，但一旦涉及复杂的部署流程，比如我的 Hexo 博客，这种「心跳代码」就成了噩梦：它会频繁触发 GitHub Actions 的构建任务，浪费额度，甚至在某些时间点因为构建冲突导致正经的博文发布失败。

凌晨三点，运维群里有人喊了一声：“完了。”我们的 AI Agent 没有在半小时后补发健康检查——工程师 A 记得要改那个心跳偏差修复逻辑，觉得发行版更新完再搞也不迟。结果两周后，Agent 把-1 发给了生产数据库。 “记得做”等于“不会做”——这是我们掏了真金白银买来的教训。 AI Agent 系统里，最优先级的任务从来不是定时任务，而是那些“回头处理一下”的事情。而恰恰是这些不定时任务，会以

8887 条老数据，1511 条新数据，理论上合完应该是 10398 条。但最终只拿到 8908 条——差了 1490 条。数据去哪了？是丢了，还是它们本来就不该在？ 这篇文章记录 ReShare 数据库从两套独立实例合并为一套的完整过程，包括数据导出、主键冲突处理、业务级去重、以及那些让人半夜爬起来查日志的坑。 前置条件 PostgreSQL 16，源库和目标库版本一致 ModelBase 服务