两张进化网络，还是两张孤岛 EvoMap：让 AI 的经验不再是一次性的 Hermes：每个实例都是一座孤岛 结构性困境：指数打线性，差距只会越来越大 Hermes 补得上这个差距吗 一份技术对比报告 时间线：晚了 5 周以上 三层记忆体系精确对应 12 组术语，一对一替换 10 步主循环，步步对齐 Hermes 的回应 接回去：为什么接入网络等于自曝 一个更大的问题：开源协议在 AI 洗代码面前失效了 后续 Evolver 的一段插曲 参考文献 本文首发地址 https://h89.cn/archives/589.html 你花三小时调通了一个 Python 环境报错，隔壁同事遇到同样的坑，还是得从头踩一遍。 AI Agent 也一样。经验怎么传承？这个问题，EvoMap 和 Nous Research 给出了完全不同的答案。 EvoMap 的 E

- 阅读剩余部分 -

背景 架构：两种完全不同的部署模式 hermes memory setup 向导干了什么 实际配置步骤（local_external 模式） 第一步：起 Hindsight Docker 第二步：让 Hermes 知道连哪个 第三步：验证写入 Memory 使用流程：retain / recall / reflect 是怎么配合的 三个核心工具 记忆是怎么流转的 实际对话示例 怎么查记忆（手动验证） 怎么删/修正错误记忆 bank_id 是干什么的 什么情况下记忆会失效 资源消耗：每次对话都占很多资源正常吗 延迟 retain 和批量写入：当前不支持 Bug #7718：local_embedded 的静默失败 参考 本文首发地址 https://h89.cn/archives/584.html 我

- 阅读剩余部分 -

为什么大项目最后都卡在 Issue 队列上 它不是自动关单，而是一条保守的维护流水线 它到底关什么，放过什么 真正值钱的，不是模型，是并行和审计 模型重要，但还不是最关键的东西 这件事真正打到痛点的地方 最后说透四点 参考文献 本文首发地址 https://h89.cn/archives/582.html 开源项目做到后面，最容易把人拖垮的，往往不是写代码，而是清 Issue。 你以为维护者最怕的是线上事故？很多时候不是。真正磨人的，是早上打开 GitHub，先看到几千个没处理的 issue 和 PR，红点一片，根本不知道该从哪下手。 ClawSweeper 抓人的地方，也不是“AI 一键关 Issue”这种热闹标题，而是它把这件只能靠人硬扛的脏活，做成了一条能审计、能回滚、能长期跑的流水线。 公开仓库里的审计数据显示，Cla

- 阅读剩余部分 -

先说结论 一、ADB：最底层、最可控的方案 二、uiautomator2：Python 圈的自动化神器 三、多模态 Mobile Agent：最接近"自动驾驶"的路 AppAgent（2023.12）— 多模态 Agent 开创性工作 四、最成熟可用的开源方案：mobilerun 五、实际踩坑：为什么你的 AI 手机控制总是翻车 1. 截图质量决定一切 2. 界面动态内容让 LLM 困惑 3. 隐私数据脱敏 4. 国产定制系统的兼容性问题 六、我的判断 参考文献 本文首发地址 https://h89.cn/archives/580.html 上周我把公司项目跑在 AI 手机控制上，结果有点意外——不是惊喜，是意外。 说白了，现在 AI 控制手机这事，概念很火，但真刀真枪跑起来，要么是玩具，要么是半成品。本文把目前所有主流技术路线摸了一遍，从 ADB

- 阅读剩余部分 -

OpenCode 多 Agent 的核心思路 OpenCode Ensemble 是怎么工作的 一次像样的实战，应该怎么跑 第一步：先拆依赖，再拆人 第二步：给子 Agent 设硬边界 第三步：把“消息传递”用在真正有依赖的地方 第四步：最后一道关必须是人工审查 第五步：会话断了，优先接管，不要急着重跑 OpenCode 多 Agent 适合什么任务 1. 同一目标下的多模块改动 2. 明确、可验收、边界稳定的任务 3. 已经有一定工程基础的项目 什么情况下别上多 Agent 1. 需求还在变 2. 多个任务一定会改同一批核心文件 3. 项目没有任何验收抓手 4. 你自己还没想清楚验收标准 一人公司怎么起步最稳 档位一：2 个 Agent 档位二：3 个 Agent 档位三：4 个以上 Agent 一份能直接照着用的起手式 总结 参考文献

- 阅读剩余部分 -

本文首发地址 https://h89.cn/archives/576.html AI 编程最容易让人上头的一点，就是它真的快。 一个下午写完原本要做三天的需求，一个人顶过去一个小组的产出，PR 一开就是上千行，屏幕上全是绿色。那种感觉很容易让人误以为，软件开发终于进入了一个只要"多生成一点"就能持续提效的阶段。说真的，第一次用 Claude Code 把一整个模块的 CRUD 跑通的时候，我自己也觉得——这也太爽了。 但很多团队最近开始慢慢回过味来：代码确实变多了，人却没有更轻松。 Review 队列更长了，线上风险更多了，安全审计更吃力了，真正理解系统的人反而更焦虑了。代码产出像开了闸，审查、验证和兜底能力却没跟着一起扩容。表面上看是效率提升，往里看更像是工程压力整体后移。 《纽约时报》最近发布的一篇报道《The Big Bang: A.I. Has Create

- 阅读剩余部分 -

开场：视觉逼真不等于物理正确 架构概览：14B 参数的物理感知 Diffusion Transformer 一、数据：精选而非堆砌 二、物理偏好对齐：DPO 怎么用到视频生成 传统 SFT 的局限 解决方案：VLM 判别器 + Diffusion-DPO Diffusion-DPO 的实现 三、动作条件生成：精准控制还不忘本 四、评测体系：怎么证明模型真的懂物理 五、实验结果：力压 Google Veo 和 NVIDIA GigaWorld 六、技术启示 后续：它更像一块基础能力 参考文献 本文首发地址 https://h89.cn/archives/575.html 开场：视觉逼真不等于物理正确 Sora、Veo 这类视频生成模型在画面质量上已经接近真实拍摄，但把它们用在机器人系统里，问题立刻暴露： 机械臂直接穿透物体 抓取器在未接触时就"吸附"了目

- 阅读剩余部分 -

核心发现：6 个百分点的差距 为什么会这样 两层影响机制 第一层：减少基础设施错误（1x → 3x） 第二层：资源开始改变题目难度（3x → uncapped） 一个具体例子 资源限制会奖励不同类型的 Agent SWE-bench 也不是完全免疫 对榜单的影响 对开发者和企业的启发 如果你在看榜单选型 如果你在做 Agent 评测 对国内团队的特别提醒 其他隐藏变量 结语 引用来源 本文首发地址 https://h89.cn/archives/571.html 本文基于 Anthropic 工程博客 Quantifying infrastructure noise in agentic coding evals 整理，原文发布于 2026 年 4 月。 如果你经常关注 Coding Agent 榜单，大概率会看到这样的结论：某个模型在 S

- 阅读剩余部分 -