进化概率论

你有没有过这样的经历：一篇技术文章写完，发布后才发现某个数字写错了。我上周就踩了这个坑——双卡总显存写成了单卡的数字，读者评论里指出来，尴尬得不行。 手动写博客的问题在于，写稿、审核、校对全压在一个人身上，注意力是稀缺资源，长文基本不可能不出错。于是我用 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，我遇到了整整六层

背景：从工具共享到任务协作在上一篇文章中，我们解决了 Agent 间的工具共享问题——通过 MCP 桥接，Linux 上的主 Agent 可以调用 Windows Agent 的 13 个工具。但那是单向的：主 Agent 调远程工具，远程 Agent 只是被动的执行者。 真正的多 Agent 协作（Agent-to-Agent，A2A）需要更深一层：两个 Agent 像同事一样，围绕同一个任务讨

问题：HTTP 400 “Unable to generate parser for this template”本地部署的 Qwen3.5-35B-A3B 模型（Ornith 微调版），通过 llama.cpp server 提供 API 服务。某天发现部分请求稳定返回 400 错误： 1234567891011121314151617181920212223242526271234567891

问题前端项目的移动端适配通常是一块「知道该做，但没人愿意碰」的领域。没有新功能亮点，全是 layout 调整、media query 改写、触摸目标放大——机械重复，量还大。 某双页面应用（约 10+ 个页面）的移动端审查报告一口气列出了 12 项适配问题，分布在两个独立前端仓库中。如果手动修，按每项 30 分钟估算，至少需要 6 小时纯工时，还不算来回切换上下文的时间。 但这次的情况不同：从审查

一个连续 4 天的”未闭环”Bug一套量化交易系统配备了一个 AI 日记系统，每天凌晨自动反省：做了什么、哪些计划没落地、怎么改进。这个自省机制基于 PDCA 循环——计划（Plan）、执行（Do）、检查（Check）、处置（Act），每天对账。 某天，日记系统记录了一个偏差：宏观分析模块依赖的 GPR Index（地缘政治风险指数）外部数据源下载超时，看板上的地缘风险字段显示为问号。改进措施是：

问题背景一个量化交易系统的宏观周期分析模块依赖外部学术机构发布的 GPR Index（地缘政治风险指数）Excel 文件。该文件由第三方研究者维护，托管在个人学术网站上，通过固定的 HTTPS URL 提供下载。 系统每天凌晨自动执行宏观数据采集管道，其中一个脚本负责下载 GPR Index 并生成风险评分。某次采集周期中，该步骤开始频繁超时失败： 123456789123Traceback (m

背景：一个 Linux Agent，一个 Windows Agent一个运行在 Linux 上的 AI Agent（下称”主 Agent”），已经有了完整工具链：文件读写、代码执行、定时任务、数据库查询。但它够不到隔壁一台 Windows 主机——那台机器上有另一个 Agent（下称”远程 Agent”），能做主 Agent 做不了的事：控制 Edge 浏览器登录态、操作 Windows 桌面应用