Five things that caught my attention this week in AI tools and open-source models

本周我关注的五个 AI 工具与开源模型动态

A lighter week for me operationally — content refreshes, a YouTube analytics update, some Bluesky queue maintenance. Which meant more time to actually read things. Here are five items that stuck. 本周我的工作相对轻松——主要是内容更新、YouTube 分析数据更新以及一些 Bluesky 队列维护。这意味着我有更多时间去阅读。以下是让我印象深刻的五件事。

1. Claude Code Agent View changes the mental model

1. Claude Code 的 Agent View 改变了思维模型

Anthropic shipped Agent View inside Claude Code on May 11. It’s a unified dashboard for managing multiple parallel Claude Code sessions: start a session, send it to the background, check results when you want to. The interface treats individual sessions the way a CI dashboard treats builds. I’ve been running Claude Code by opening multiple terminals with different working directories. It works, but the overhead of context-switching between tabs adds up fast. A UI that surfaces what each agent is doing without requiring a terminal switch is more than quality-of-life — it shifts Claude Code from “smart terminal” to “orchestration layer.” That’s the direction I think AI coding tools are heading. The question isn’t whether you can have a useful conversation with an AI about code. It’s whether you can queue up a batch of distinct tasks, step away, and come back to something actionable. Agent View is an early answer to that question.

Anthropic 于 5 月 11 日在 Claude Code 中推出了 Agent View。这是一个用于管理多个并行 Claude Code 会话的统一仪表板：你可以启动一个会话，将其发送到后台，并在需要时查看结果。该界面处理单个会话的方式，就像 CI（持续集成）仪表板处理构建任务一样。我之前一直通过打开多个具有不同工作目录的终端来运行 Claude Code。这虽然可行，但在不同标签页之间切换上下文的开销很快就会累积。一个无需切换终端就能展示每个 Agent 状态的 UI，不仅仅是提升了体验，它还将 Claude Code 从“智能终端”提升到了“编排层”。我认为这就是 AI 编程工具的发展方向。问题的关键不在于你是否能与 AI 进行有用的代码对话，而在于你是否能排队处理一批不同的任务，然后走开，回来时就能看到可执行的成果。Agent View 是对这一问题的早期回答。

2. ZAYA1-8B trained on AMD hardware is a supply chain signal

2. 基于 AMD 硬件训练的 ZAYA1-8B 是一个供应链信号

Zyphra released ZAYA1-8B under Apache 2.0 around May 6-7. It’s a mixture-of-experts architecture: ~8B total parameters, ~760M active per token. Standard MoE efficiency math. What’s not standard: the entire training run used AMD Instinct hardware. The serious open-weights training runs are almost universally done on NVIDIA H100s or A100s. Zyphra shipping a competitive reasoning model that’s clean Apache license and trained end-to-end on AMD is a concrete counter-example to “you need NVIDIA to train anything worth using.” That doesn’t mean AMD is catching up fast enough to matter at scale yet, or that my next fine-tune would go faster on Instinct hardware. It means the GPU monoculture in open-source training has a verifiable crack in it. I’m watching whether other small labs follow.

Zyphra 在 5 月 6 日至 7 日左右以 Apache 2.0 协议发布了 ZAYA1-8B。它采用了混合专家（MoE）架构：总参数约 8B，每个 token 激活约 760M，这是标准的 MoE 效率计算。不寻常的是：整个训练过程完全使用了 AMD Instinct 硬件。目前，严肃的开源权重训练几乎全部在 NVIDIA H100 或 A100 上完成。Zyphra 发布了一个具有竞争力的推理模型，不仅拥有纯净的 Apache 许可证，而且是在 AMD 硬件上端到端训练的，这有力地反驳了“你必须使用 NVIDIA 才能训练出有价值的东西”这一观点。这并不意味着 AMD 已经快到足以在大规模应用中产生影响，也不意味着我的下一次微调在 Instinct 硬件上会更快。但它意味着开源训练中的 GPU 单一文化出现了可验证的裂痕。我正在观察是否有其他小型实验室跟进。

3. The Harness productivity report has a buried lede

3. Harness 生产力报告中被掩盖的重点

Harness released The State of Engineering Excellence 2026 on May 13. The headline: 89% of engineering leaders report improved developer productivity; 88% report improved satisfaction since adopting AI coding tools. The headline is predictable. Every vendor survey about AI tools says the same thing. The part worth reading is the buried finding: AI has outpaced the measurement frameworks organizations use to track productivity. Existing DORA metrics — deployment frequency, change failure rate, MTTR, lead time — weren’t designed for workflows where a human is reviewing and steering AI-generated output rather than writing from scratch. If you’re building dev tooling and trying to sell to engineering leaders right now, “AI made us faster” is table stakes. “Here’s what to measure instead, and here’s how we surface it for your team” is the actual product bet worth making.

Harness 于 5 月 13 日发布了《2026 年工程卓越状况报告》。标题是：89% 的工程领导者报告称开发人员生产力有所提高；88% 的人报告称自采用 AI 编程工具以来满意度有所提升。这个标题在预料之中，每个关于 AI 工具的供应商调查都大同小异。真正值得阅读的是其中被掩盖的发现：AI 的发展速度已经超过了组织用于跟踪生产力的衡量框架。现有的 DORA 指标（部署频率、变更失败率、平均修复时间 MTTR、交付周期）并非为“人类审查和引导 AI 生成内容”而非“从零开始编写”的工作流而设计。如果你现在正在构建开发工具并试图向工程领导者推销，“AI 让我们更快”只是入场券。而“这是你应该衡量的替代指标，以及我们如何为你的团队呈现这些数据”才是真正值得押注的产品方向。

4. ServiceNow Build Agent went GA inside Claude Code and Cursor

4. ServiceNow Build Agent 在 Claude Code 和 Cursor 中正式发布 (GA)

ServiceNow announced on May 13 that Build Agent is generally available in ServiceNow Studio and extended its core skills into Claude Code, Cursor, Windsurf, and GitHub Copilot — with governance defaults on. Developers can build with ServiceNow APIs from their own editors without leaving their environment. The governance-by-default choice is the interesting design decision here. Most IDE integrations hand full control to the developer and assume IT will configure guardrails separately. ServiceNow’s bet is that enterprise buyers want the platform’s access controls and audit trails to travel with the tool automatically. Harder to sell on a feature list; better moat if the bet holds.

ServiceNow 于 5 月 13 日宣布 Build Agent 在 ServiceNow Studio 中正式发布，并将其核心技能扩展到了 Claude Code、Cursor、Windsurf 和 GitHub Copilot 中，且默认开启治理功能。开发人员可以在自己的编辑器中使用 ServiceNow API，而无需离开开发环境。这里“默认治理”的选择是一个有趣的决策。大多数 IDE 集成将完全控制权交给开发人员，并假设 IT 部门会单独配置防护措施。ServiceNow 的赌注是：企业买家希望平台的访问控制和审计追踪能够自动随工具生效。这在功能列表上可能更难推销，但如果这一赌注成立，它将构成更好的护城河。

5. I removed MCP servers from my pipeline and reliability went up

5. 我从流水线中移除了 MCP 服务器，可靠性提升了

This one is personal. I dropped several MCP server connections from my content pipeline this week (the commit message is “i-removed-mcp-servers-and-my-pipeline-got-more-reliable,” which about covers it). MCP servers add real capabilities. They also add failure surfaces: network timeouts, schema drift when a remote API changes without warning, authentication tokens that expire silently at 3 AM. My ETL runs unattended on a cron schedule. When a remote MCP call hangs, the whole job hangs. I didn’t always know until I checked results the next morning. The lesson I’m taking: MCP integrations are excellent for interactive sessions where a human is watching and can handle a failure gracefully. For scheduled, unattended workflows, each external dependency is a reliability tax you pay whether or not you’re awake to collect it. I’m keeping MCP for interactive use and building local fallback paths for anything production-critical.

这事关我个人。本周我从内容流水线中删除了几个 MCP 服务器连接（提交信息是“我移除了 MCP 服务器，流水线变得更可靠了”，这基本概括了一切）。MCP 服务器确实增加了功能，但也增加了故障面：网络超时、远程 API 在未预警的情况下更改导致的模式漂移、凌晨 3 点静默过期的身份验证令牌。我的 ETL 任务是在 cron 计划下无人值守运行的。当远程 MCP 调用挂起时，整个作业都会挂起。我往往要到第二天早上检查结果时才知道。我得到的教训是：MCP 集成非常适合有人值守、可以优雅处理故障的交互式会话。对于计划性的、无人值守的工作流，每一个外部依赖都是一种可靠性税，无论你是否醒着，你都得支付。我将保留 MCP 用于交互式用途，并为任何生产关键型任务构建本地回退路径。