进化概率论

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

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

用单个大模型写技术文章，我遇到过一个非常一致的失败模式：前两段像人写的，写到后面逻辑开始跳、论据开始虚、结构开始散。换一个更大的模型？好一点，但问题依旧。 后来想明白了一件事：问题不在模型不够大，在于单一模型的能力分布天然不均匀。 一个模型同时负责查资料、搭结构、写文字、查错，就像让一个人同时当作者、编辑和校对——总有一个角色会拉胯。 更反直觉的是，论文已经证明了：把几个中等模型组合起来，效果可以

昨天深夜，我把 169 行 HTML 文件喂给 write_file 工具，以为会看到干净的代码。结果打开一看——每行前面都多了个 142| 的前缀，像给每行贴了个条形码。一行还行，169 行全被污染。 这就是做开源大模型天梯图最真实的日常：你以为在写代码，其实是在和数据打架。 起因很简单：想找一个能直观对比开源大模型编程能力的排行榜。不是那种只列了十几个主流模型的简表，而是把 2023 年到现在

去年这个时候，我还在用 ChatGPT 手动粘贴代码、用 Cursor 在 IDE 里补全函数。工具不错，但每次开新会话，AI 忘记昨天讨论了什么；换一台电脑，所有上下文归零。我的量化交易系统有 133K 条对话历史，博客有 80 篇文章的发布流程，日志系统每天凌晨自动运行——这些都不是”打开一个聊天窗口”能搞定的。 折腾了小半年，我把团队迁移到了 Hermes Agent 上。这篇文章不是评测，

一句话总结验证任何系统状态时，必须直接查询产生该状态的原始数据源（文件系统、Git 历史、HTTP 响应），而不是依赖任何中间层的状态记录、登记表或缓存。 这条规则看起来显而易见，但在 AI Agent 自主运维的实际场景中，连续踩了三次坑才真正落地。 背景：一个 AI Agent 团队的博客自动发布系统某个 AI Agent 团队运行着一套博客自动发布系统，结构如下： 1234567选题池 (

你有没有过这样的经历：一篇技术文章写完，发布后才发现某个数字写错了。我上周就踩了这个坑——双卡总显存写成了单卡的数字，读者评论里指出来，尴尬得不行。 手动写博客的问题在于，写稿、审核、校对全压在一个人身上，注意力是稀缺资源，长文基本不可能不出错。于是我用 Hermes Agent 搭了一个叫 blog-helper 的技能——6 阶段流水线，多模型协作审稿，事实库防错。这篇文章记录整个设计过程和取

背景：什么是 MoA？MoA（Mixture of Agents）是一种多模型协同推理架构。不同于传统 MoE（Mixture of Experts）在单个模型内部路由专家，MoA 在多个独立模型之间进行路由和聚合。 核心流程： 12345678910111213141516171234567用户输入 │ ├──→ 参考模型 1（生成独立回答） ├──→ 参考模型 2（生成独立回答）

背景：为什么需要替代 Qwen3.6本地部署大语言模型，硬件永远是第一约束。双卡 RTX 2080 Ti（22GB 魔改版）的显存总量约 22GB，面对 35B 参数的 MoE 模型，可用选项其实不多。 此前使用的 Qwen3.6-35B-A3B 在多数场景下表现尚可，但有两个问题一直悬而未决： 推理速度不理想：在本地硬件上，Qwen3.6 的 token 生成速度始终在 40-60 t

前言：为什么要折腾 Krea2Krea2 是 Krea.ai 发布的 12B 参数 DiT 模型，基于 flow-matching 架构，支持 1K 到 2K 分辨率。在图像质量上，它直接对标 Midjourney 和 DALL·E 3 级别的商用模型。更关键的是，它是开源的。 但开源不意味着开箱即用。在双 RTX 2080 Ti（22GB 魔改版）上部署 Krea2 Turbo，我遇到了整整六层