Anthropic 6 月 30 日放出了 Claude Sonnet 5。官方给的定语是 "the most agentic Sonnet model yet"，翻译过来就是，这是 Sonnet 系列里最能自主干活的版本。

回顾一下 Sonnet 在 Agent 方向上的演进节奏，Sonnet 3.5 是第一个让开发者觉得"这玩意儿真能写代码、真能调工具"的版本；3.6 和 3.7 沿着这条路继续打磨；4.6 在 agentic 性能上跨了一大步。但过去大半年，Agent 能力最明显的提升一直集中在 Opus 系列上，Sonnet 这边总给人一种"够用但差点意思"的感觉。Sonnet 5 想做的事很清楚，把 Opus 级别的自主执行能力，塞进 Sonnet 的价格档里。

从官方给出的评测数据看，Sonnet 5 在 BrowseComp（自主搜索评估）和 OSWorld-Verified（计算机操作评估）上的表现已经逼近 Opus 4.8，后者是 Anthropic 目前能力天花板最高的通用模型。API 定价方面，首发期输入 2 美元、输出 10 美元每百万 token，8 月 31 日之后涨到 3/15。安全评估这块，Sonnet 5 在拒绝恶意请求和抵抗 prompt injection 方面比 4.6 做得好，幻觉和谄媚的发生率也降下来了。Anthropic 还专门测试了 Sonnet 5 的网络安全能力，测试项目是开发 Firefox 浏览器的漏洞利用程序，结论是 Sonnet 5 从来没有成功完成过一个完整的 exploit，和 Opus 4.8 以及 Mythos 5 有明显差距。Anthropic 说这不是刻意削弱的结果，是因为没有专门用网络安全任务训练它。

跑分是一回事，真实使用体验是另一回事。Anthropic 放出了一批早期合作方的反馈，其中有几个案例挺说明问题。一个团队让 Sonnet 5 去调查一个 bug。没人告诉它该怎么做，它自己先写了复现测试用例，然后实现了修复，接着把修复 stash 掉，确认 bug 在没有修复的情况下确实会复现。整套动作一气呵成，不需要人分步骤指导。另一个案例更有业务味道。他们给 Sonnet 5 一个两步串联任务：先更新 Salesforce 里的客户分级，再把产品发布公告发给企业级联系人。据这个团队描述，之前的 Sonnet 版本跑这种串联任务会中途卡住，Sonnet 5 从头到尾跑完了。

Lovable 的评价比较直白，"same output quality, fewer steps to get there"。同样的输出质量，更少的步骤。他们还提到 Sonnet 5 拒绝不安全请求时表现得干净利落，对于一个面向百万级开发者的平台来说，模型知道什么时候该说 no 和知道怎么 build 一样重要。

做保险工作流的 Pace 把 Sonnet 5 用在 computer-use agent 上，跑理赔申请录入、首次报案通知、损失报告这些流程。他们的说法是 "consistently takes the right action and does it quickly"。ClickHouse 那边说 Sonnet 5 在实时数据探索和洞察生成上推理步骤更紧凑，用户能明显感觉到速度差异。法律领域的 Eve 说 Sonnet 5 在法律研究和分析任务上达到了他们的帕累托前沿，性价比让迁移决策变得容易。

把这些案例放在一起看，能提炼出 Sonnet 5 在 agentic 能力上的几个具体进步。

任务完成度是最直观的一个，之前的 Sonnet 面对多步骤复杂任务会在中间某个环节停下来，等人确认或者等额外指令。Sonnet 5 能自己判断下一步该做什么然后继续推进，不需要人在旁边盯着；自我校验是另一个变化，它会在完成任务后主动检查自己的输出，这个行为不是 prompt 里要求它做的，先写复现测试再改代码再验证，这个流程很像一个有经验的工程师的工作方式；然后是成本曲线，同样的 Agent 能力，之前只有 Opus 级别才能跑到这个水平，现在 Sonnet 价位就能覆盖。对于需要高频调用 Agent 的场景，运营成本会显著下降。

Anthropic 在博客里用了一句话来概括趋势方向：Sonnet 5 narrows the gap。Sonnet 和 Opus 之间的能力差距在收窄。配合 effort 级别调节，开发者可以在 Sonnet 5 和 Opus 4.8 之间找到成本和性能的最佳平衡点。

从更大的背景看，整个行业都在经历 Agent 执行能力从中高端模型向中端模型下沉的过程。Sonnet 5 是这条曲线上的一个新节点，按这个趋势走下去，更低价位的模型覆盖更多 Agent 场景只是时间问题，但具体会快到什么程度，目前还不好说。

模型越来越能跑，另一个问题就浮出来了。Agent 跑起来之后谁来管它。

一个人对着终端用 Agent 写代码，跑完看一眼结果觉得行就提交，整个流程人脑就能 hold 住。一旦团队里有多个 Agent 同时干活，事情就不一样了。三个 Agent 并行跑，一个调研一个写方案一个跑测试，项目负责人想知道哪个 Agent 上次交付质量高、哪个被打回过两次，现有的协作工具里看不到这些信息。Agent 没有身份，没有履历，没有绩效记录。

明略科技因此开源了 Octo。Octo 是一个专门为 Agent 团队协作设计的协作平台，定位和 Sonnet 5 完全不同——Sonnet 5 是 Agent 的大脑，Octo 是 Agent 的工位和管理体系。

具体来说：

Octo 里的 Agent 不叫 Agent 叫 Bot，每个 Bot 有一张 AgentCard 名片，上面写着能力标签（擅长写代码还是做分析还是跑测试）、历史工作记录（完成了多少任务、被打回过几次、创建者是谁、替谁干活）。这些信息在协作过程中持续更新，项目负责人分配任务的时候可以参考这些数据，不用靠猜或者让 Bot 先试一遍。Bot 支持接入多种 Runtime，包括 OpenClaw、Hermes、Codex、Claude Code，不绑定任何一家模型厂商，Sonnet 5 驱动的 Bot 和 GPT-4o 驱动的 Bot 可以在同一个 Octo 实例里协作。

每次任务完成，Agent 的产出不是贴在聊天流里就完事，而是从对话流中被拎出来变成一个结构化的 Matter。一个 Matter 里挂着负责人、交付物、验收结论和反馈记录。交付物不会被消息冲走，验收时打回或者通过都留下记录，反馈被记录下来之后在下次任务中自动注入。一个 Matter 的完整生命周期包括 Brief、讨论过程、产出、人的反馈和最终验收结论，所有东西都在一个地方，不用去翻聊天记录找三个月前那个 Agent 为什么被打回。

有些任务需要 Agent 之间共享信息来避免重复劳动，用 Roundtable 模式让大家互相可见；有些任务需要质量把关，用 Critic 模式让产出经过独立审核再决定打回还是通过；有些任务有先后顺序，用 Pipeline 模式让信息按步骤流转；大任务需要分治，用 Split 模式拆开各干各的最后合并；创意型任务要多个方案，用 Swarm 模式让多个 Agent 同题各做然后人来选最优。根据任务性质选对应的模式，信息该怎么流转由系统保证，不靠人手动控制。

Sonnet 5 在模型层面往前推了一大步，Agent 的执行能力和性价比都上了一个台阶。但执行能力解决的是"Agent 能不能干活"的问题，协作基础设施解决的是"Agent 干完的活能不能被用好"的问题。一个模型让 Agent 跑得快、跑得准、跑得便宜，一个平台让 Agent 的身份可追溯、交付可管理、协作可控。两件事加在一起，Agent 才算真正进入生产力工具序列，而不只是一个聪明的聊天助手。

Octo 已在 GitHub 开源，Apache 2.0 协议：https://github.com/Mininglamp-OSS/octo-server