进化概率论

凌晨三点，我像往常一样跑 systemctl restart autoquant。日志里一行红字刺眼：service autoquant.service: restart counter 10637 hit max, refusing to start。 10637 次。这个服务在过去 24 小时里被 systemd 反复拉起、反复杀掉，像被谁下了一个死循环的咒。而罪魁祸首，是半年前一个再”顺手”

回测跑出来一条只涨不跌的净值曲线，胜率 100%，最大回撤 0%。 这不是圣杯，这是 bug。 策略里买入后该卖出的信号一次都没触发，仓位从开仓那天起就锁死在账户里。净值曲线”看起来”只涨不跌，只是因为它从来没结算过亏损。最讽刺的是，这个 bug 的源头只是一个 copy-paste：把 buy 分支的代码复制到 sell 分支，忘了把一个布尔标志从 True 改成 False。 copy-pas

你的 AI Agent 每天和你聊几十轮，用户说的每一句话都飘散在上下文窗口里，下一次对话就忘了。这不是”记忆力差”的问题——是你根本没有把用户的声音当成一种数据资产来管理。VoC（Voice of Customer）技能就是来解决这个问题的。 问题：反馈在飘，改进在赌没有 VoC 闭环的 AI Agent，至少有三个具体痛点： 反馈即焚——用户说”这个功能不好用”，Agent 答了一声”好

本文是对《双卡2080Ti跑大模型：PCIe带宽是瓶颈吗？一次深度实测》的重算修正版。原文的显存带宽天花板计算存在量化精度错误，导致理论极限被高估了近一倍。修正后，结论方向不变（显存带宽是瓶颈，PCIe 不是），但数字全部对齐。 为什么要重算原文的核心论证链是这样的： Qwen3.6-35B-A3B 每次只激活约 3B 参数 Q4_K_M 量化 → 按 2 bytes/param

为什么写这篇我有一个 AI Agent 集群，分布在不同的机器上： 代理 机器 系统 Hermes 版本 代理 A 内网服务器 1 Linux v0.20.0 代理 B 同机，独立 profile Linux v0.20.0 代理 C 内网服务器 2 Windows v0.20.0 代理 D NAS UGOS (Linux) v0.10.0 需求很简单：让这四个代理互相

五个 AI Agent、几十个技能文件，没有一个统一的审查标准。每次新建技能都靠经验判断”好不好”，换了个人写就不一样了。这篇文章记录 skill-optimizer 从 v1.0 的五维人工清单，升级到 v3.5 的七维脚本评分引擎的全过程。 问题：技能越多，质量越难管我们团队有五个 AI Agent、每个都在写技能。技能是 Hermes Agent 上扩展 Agent 能力的标准方式——一

MCP 工具调用失败：’CallToolResult’ has no attribute ‘isError’凌晨 0:28，agent.log 跳出一行红色 ERROR： AttributeError: ‘CallToolResult’ object has no attribute ‘isError’ 工具调用失败了。但奇怪的是，我的 Agent 主流程没断，任务继续跑，用户无感知。更奇怪的

一个整点定时任务，执行到 Step 3「发送心跳卡片」时卡住。日志里塞了 50 行文字描述——每一行都是”执行以下命令”。问题不在描述不准确，而在于：Agent 必须先把这 50 行读完，才能执行一行命令。 我在 2026 年 7 月中旬做了一次改造：把 agent-heartbeat 技能的 Step 描述从”人读”模式改成”机器执行”模式。改动很小——一个 shell 脚本 + 几行 SK

每次给 AI Agent 开一个新 profile（韩梅梅、李雷、露西……），都会顺手起一个 hermes gateway run。一个 profile 一个进程，五个 profile 五个进程，听着很合理——直到微信 bot 突然全线失联，日志里全是 “Weixin bot token already in use”。 这就是多 Gateway 进程的 Token 锁冲突。表面看是微信 bot

翻车现场一个扫码页面，在电脑浏览器上看着一切正常——卡片撑满屏幕，底部对齐手机 home 指示线。 切到手机上，卡片高度比屏幕多出了几十像素。没有滚动条，但手指能从下往上拖动，页面会回弹。看起来像是：内容比视口”大了一圈”，但又没有大到需要滚动条。 同一个 div，同一套 CSS，PC 完美、手机溢出。 第一轮排查：是不是父容器没撑高直觉反应：肯定有某个父容器没设 h-full，导致子元素的高度计