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

- 阅读剩余部分 -

1. 为什么需要 A2A：Agent 互操作的三层困境 2. 协议设计深度解析 2.1 Agent Card：Agent 的数字名片 2.2 通信协议：三种协议绑定 2.3 安全模型：Web 对齐而非重新发明 2.4 流式协作：Agent 的实时对话 3. AP2 支付协议：Agent 经济的基础设施 4. 云平台集成现状：Azure/AWS/GCP 已公开集成 5. A2A vs MCP vs OpenAPI：三层协议栈的分工与协作 6. 生产部署指南 6.1 认证配置要点 6.2 多租户部署 6.3 监控与可观测性 6.4 分页与大规模任务管理 7. 生态全景：从 SDK 到 Inspector 到 TCK 8. 看法与展望：A2A 的挑战与未来 值得肯定的 仍需观察的 展望 参考 本文首发地址 https://h89.cn/arc

- 阅读剩余部分 -

一、代码全景：1900 文件的目录地图 二、引擎核心：QueryEngine.ts 的流式工具循环 2.1 核心循环：消息 → 工具 → 消息 2.2 思考模式（Thinking） 2.3 重试与错误处理 2.4 Token 计数与费用追踪 三、工具系统：40 个 Tool 的注册与权限沙箱 3.1 Tool 类型定义——所有工具的契约 3.2 ToolUseContext——工具执行的上下文宇宙 3.3 权限沙箱——三层规则 + 四种模式 3.4 工具注册表 四、上下文管理：从 CLAUDE.md 到 Prompt Cache 4.1 系统上下文：5 个 git 命令并行执行 4.2 用户上下文：CLAUDE.md 的自动发现 4.3 三层记忆架构 4.4 Prompt Cache：静态/动态分割 4.5

- 阅读剩余部分 -

一、缘起：8 小时黑客松，10 个月实战淬炼 二、AI 编程助手的核心痛点——你一定经历过 痛点 1：上下文窗口爆炸 痛点 2：令牌成本失控 痛点 3：会话信息丢失 痛点 4：重复劳动 痛点 5：单兵作战 三、ECC 是什么：不是插件，是系统 四、六大核心组件详解 4.1 Agents：38+ 个专业代理，各司其职 4.2 Skills：156+ 个领域技能，按需加载 4.3 Commands：72+ 个 legacy command shims，快速入口 4.4 Rules：常驻规则集，编码的底线 4.5 Hooks：事件驱动自动化 4.6 MCP：外部工具集成 五、持续学习 v2：让 AI 越用越懂你 v1：基于 Stop Hook 的模式提取 v2：基于 Instinct 的学习系统 六、多代理

- 阅读剩余部分 -

Hermes 在解决什么问题 为什么"长期运行"越来越重要 核心能力 1. 持久记忆 2. 自建技能与学习循环 3. 多平台触达 4. 灵活部署 v0.7.0 为什么值得注意 与常见 Coding Agent 的差别 与 OpenClaw 的对比 适合谁用 不适用场景 我的看法 引用来源 本文首发地址 https://h89.cn/archives/556.html 最近 Agent 圈里一个很值得关注的项目，是 Nous Research 的 hermes-agent。 它吸引我的地方，不是又一个"能调工具、能写代码、能调用模型"的 Agent。 而是它把重点放在了另一件事上：Agent 能不能长期运行、长期记住、长期变强。 这比单次演示难得多，也现实得多。 Hermes 在解决什么问题 今天很多 Agent

- 阅读剩余部分 -