进化概率论

sensenova 免费模型的隐藏坑：token plan limit exhausted vs RPM RateLimitError凌晨 03:00，Hermes 的 cron 心跳脚本突然连续抛出 RateLimitError。我看了一眼异常栈，第一反应是加个 time.sleep(60) 重试——过去遇到这种报错都是这么解决的。 结果重试了 200 次全部失败。 问题不在频率，在配额：免费套

凌晨 3:45，是我这套 AI Agent 系统的发刊时间。5 个 profile、12 个 cron 任务一起撞墙，new-api 直接 429。这篇文章记录从撞墙到稳定运行的全过程。 现象：半夜的 429 风暴问题暴露得很快。某夜 3:55，韩梅梅的 blog-helper cron 报 HTTP 429: RateLimit，同一时段李雷的 ReShare 同步、AutoQuant 的回测

我的回测引擎里有一个隐蔽的 bug，藏了三个月才被发现：RSI、布林带、肯特纳通道三个策略，每个都只产生了第一次买入信号，之后再也没卖过。 回测报告显示”100% 胜率、单笔交易”，看起来完美——实际上是信号死了。 根因是一行 copy-paste：卖出分支里把 in_buy 设成了 True，本该是 False。结果卖出后买入锁一直挂着，下一个买入信号永远被”已持仓”挡住，整条信号链断裂。这不是

MACD 金叉买入、SMA 趋势确认，这是最经典的两个技术指标组合。教科书告诉你”参数用 12/26/9 和 5/20”，但从来没告诉你——这些数字是随便选的，换个市场、换个标的，它们大概率不是最优的。 我做了一件事：把 MACD 的快慢线周期和 SMA 的窗口长度展开成一个参数网格，每个格点跑一遍回测，看收益分布长什么样。结果很反直觉——最优参数不在教科书的默认值附

凌晨三点，我像往常一样跑 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 能力的标准方式——一