https://x.com/i/article/2100384063165284353

BestBlogs 早报 · 09-17｜Gradium 全双工语音，GKE Agent，Claude CRM 协同

在线阅读本期早报

BestBlogs.dev 是 AI 驱动的私人阅读助手。这是面向所有人的每日早报内容，如果你希望它基于你的兴趣和阅读习惯整理，可以体验「我的早报」。

导语

一段对话里，系统究竟该何时开口，何时等待，又该在何处把任务交给更强的模型或人类同事？这个问题看似属于交互细节，却一路延伸到 Agent 的执行环境和企业系统的权限边界。今天的内容不需要被塞进单一口号：语音交互、基础设施与销售协作各自回答的是不同问题，但它们都要求产品团队把能力、成本与责任放在清楚的位置。

语音产品正在从把文字念出来，走向识别语气、处理打断、调用工具并持续响应。与此同时，Agent 已不只是开发机上的一次性脚本。它会运行未知代码、等待外部工具、持有短暂凭据，也会在空闲后再次恢复。面向业务团队的 Agent 则要穿过客户关系管理系统、邮件和协作工具，把信息变成建议，甚至提出写回记录的动作。

读这期早报，可以把注意力放在三个实际判断上。第一，语音体验的自然感是否来自真实的对话机制，而非单纯缩短等待。第二，规模化运行时是否把隔离、网络与闲置资源作为设计中心。第三，业务自动化能否让用户看见数据来源、执行范围与最后的确认环节。后面的七条速览也会从语音、检索、机器人、代码协作和科学计算继续展开这些具体问题。 清楚的边界 不是限制能力的装饰，而是让能力能被放心使用的条件。

★ 精讲一：你的语音智能体还只是对讲机 — Neil Zeghidour，Gradium

来源：AI Engineer · BestBlogs 评分：89

很多语音助手已经能很快回应，却仍让人感到像在使用对讲机：用户说完一句，系统才开始说；系统开口后，用户的一声附和又会被视为打断。Gradium 的负责人从语音界面的演进解释了这个落差。人与人说话时常有重叠、短促反馈和提前接话，真正自然的互动不是整齐地轮流占用一个回合，而是双方随时调整节奏。对话系统若只会在听和说之间切换，就很难处理这些细小却频繁的变化。

原文回顾了两条技术脉络。早期语音界面可以完成受限任务，但开放对话能力有限。文本大模型出现后，语音交互能接入更广泛的知识、推理和工具调用，常见链路则是语音识别、文本模型、语音合成依次衔接。端到端语音模型把声音直接变成输入和输出，因而有机会保留语气、节奏、情绪和环境声，也能减少多次转换带来的等待。不过，声音并非只有文字内容，模型要同时理解和生成音频，计算与模型能力的分配随之变得更难。

全双工提供的是另一种对话组织方式。原文用多流语言模型描述其机制：用户和系统的音频不再被排成一条单线，而是以两条流被共同建模。双方可以同时活跃、同时安静，或一方说话一方倾听。这样，用户的嗯、对、稍等一下等反馈，不必立刻中止输出。对于客服、口语陪练、角色互动等场景，能否正确处理附和与重叠表达，往往会比单独的首字延迟更影响用户对自然感的判断。

但原文也没有把全双工等同于更强的 Agent。纯语音模型能带来更低延迟和更丰富的声音理解，复杂推理、可靠工具调用和知识更新却常仍由文本模型承担。Gradium 倾向于混合架构：较轻的全双工语音层负责维持交流、判断何时接话；后台的文本模型异步处理推理、规划和工具调用。这种拆分使前台不必让每一次闲聊都经过最昂贵的推理路径，同时保留更换后台能力的空间。

对产品团队来说，值得留下的不是某一种模型路线，而是一套评估顺序。先区分场景需要的是陪伴式连贯交流、可验证的任务执行，还是两者兼有。再观察系统面对插话、沉默、工具等待时怎样解释状态。若语音界面能平稳地交接复杂任务，用户感受到的就不只是更像人的声音，而是一段知道如何协作的对话。

★ 精讲二：Agent Substrate 现已在 GKE 上可用

来源：Google Cloud Blog · BestBlogs 评分：90

Google Cloud 发布的 Agent Substrate，解决的是另一层问题：当大量 Agent 要长期运行、生成代码、访问工具并等待外部反馈时，执行环境怎样既安全又不浪费资源。个人在本地启动一个编码 Agent，与平台同时管理成千上万个沙箱，是两类不同的工程问题。后者不仅要安排算力，还要处理未知代码的隔离、网络出口、凭据保护、突发创建，以及大量任务处于等待状态时的资源回收。

Agent Substrate 以 Kubernetes 为底座，把 Agent 的执行生命周期与底层机器管理拆开。公告称它可以使用硬件隔离的微型虚拟机或 gVisor 沙箱运行代码，并以出口代理施加细粒度网络规则。凭据由运行环境在 Agent 代码不可直接触及的位置注入，目的在于减少未知代码读取密钥或向外泄露数据的机会。这里最关键的不是让 Agent 获得更多系统权限，而是在必须执行代码的前提下，把内核与网络的信任边界默认做严。

它还把闲置任务视作运行时的一等问题。自主 Agent 会等待模型返回、工具响应或人工审批，若每个等待任务一直占有 CPU 和内存，规模上去后成本很快失控。Agent Substrate 会保存沙箱状态并暂停调度，再在需要时恢复。Google 在公告中给出的目标包括半秒以内恢复和高频暂停恢复能力，这些数字来自产品发布，实际部署仍取决于镜像、任务类型和集群配置。但设计思路很明确：对 Agent 平台，暂停和恢复的质量与一次执行的速度同样重要。

开源与可移植性让这条消息不只是某个托管服务的更新。运行时试图兼容 Kubernetes 环境和不同的 Agent 框架，使团队能在既有平台约束下评估它。选择这类基础设施时，可以先从三个问题入手：未知代码被隔离到什么粒度，网络与凭据访问是否能审计，任务等待时能否释放资源而不丢失状态。模型、框架和工具会持续变化，这些平台约束反而是长期要面对的部分。

它与前一条语音架构存在一种有用的对照。语音层把自然对话与深度推理分开，运行时把 Agent 执行与机器管理分开。两者都不是为了增加层次，而是让延迟、成本和风险各有归属。对正在从原型走向多人使用的团队而言，先明确这些归属，通常比把更多任务交给 Agent 更能决定系统是否可持续。

★ 精讲三：Salesforce 接入 Claude：销售与客服工作流

来源：Claude Blog · BestBlogs 评分：88

Anthropic 与 Salesforce 推出的测试版插件，把销售人员已有权限范围内的账户、商机和销售管道带到 Claude 里。它包含三十七项面向客户经理日常工作的技能，覆盖账户研究、通话准备、管道检查和客户关系管理更新。销售人员并不缺少资料，困难在于一场会前准备可能要来回查 Salesforce、邮件、通话记录和 Slack。把这些分散线索放到一个任务上下文中，才能让 Agent 生成可检查的摘要和下一步建议。

插件给出的使用方式相当具体。早晨简报可以汇总当天会议、临近成交的交易、可能有风险的商机和未回复消息。准备会面时，系统可从客户记录、协作线程和邮件里整理当前进展、尚未解决的问题以及需要关注的人员。围绕某笔交易，它还能按团队的方法检查资格缺口、尚未接触的利益相关方和成交日期风险，再起草业务说明、跟进计划或需要补全的字段。它承担的是信息汇聚和初步组织，而非替销售人员判断客户关系。

这项发布里最值得关注的是写回的控制方式。Salesforce 仍然是记录系统，用户使用自己的 Salesforce 凭据登录，Claude 只能读取既有权限允许的数据。默认情况下，系统提出的商机阶段、成交日期、跟进任务等变更需要销售人员批准后才会写入。这样的安排让 Agent 不止能生成摘要，也能参与业务动作，同时把不可逆或会影响团队判断的步骤保留在人手里。

对于考虑部署企业 Agent 的团队，这是一份很实用的产品清单。第一，数据来自哪些已经授权的系统。第二，Agent 是只读、提出建议，还是可发起写入。第三，写入由谁确认，确认前用户能否看到依据。若这三点不能讲清楚，再丰富的连接器也很难变成稳定流程。相反，从会前资料、会后纪要、待跟进事项等可复核任务开始，能让团队逐步校准 Agent 的价值与风险。

前两条讨论了交谈的节奏和沙箱的边界，这一条把边界落到业务记录上。自然的界面、快速的执行环境，最终都要接进具体组织的权限体系。好的业务 Agent 不会把人排除在流程之外，而是减少反复整理信息的时间，让人把注意力放回客户判断、优先级和最后的确认。

速览

阶跃发布语音大模型 StepAudio 3，拿下多个全球第一！

来源：阶跃星辰 · BestBlogs 评分：90

阶跃星辰发布 StepAudio 3 系列，覆盖实时交互、语音识别、文本转语音、音频生成和音乐创作。它把语音能力放进一个覆盖理解、表达和创作的产品序列，而不是只更新某一项单点能力。

公告称 StepAudio 3 Realtime 支持原生全双工对话，并在 Artificial Analysis 的对话动态榜单取得百分之九十八点九的综合得分；语音推理准确率榜单给出百分之九十九点七。相关排名来自厂商引用的第三方榜单，仍应结合具体语言、噪声和任务场景测试。

与 Gradium 的分享并读，会更容易看到语音产品的竞争正在变细：它既要理解说了什么，也要判断何时回应、怎样保持节奏，还要把推理与任务执行接进对话。模型指标之外，用户在真实打断和长任务中感受到的连续性，才会决定这些能力是否有用。

从内存饥渴的 HNSW 到量化 SPANN：Pinterest Manas 平台的技术演进

来源：InfoQ · BestBlogs 评分：85

Pinterest 的 Manas 检索平台要处理数十亿级向量，并服务首页、搜索、相关推荐、广告和通知等发现体验。随着语料增长，依赖内存的向量索引会把硬件成本和部署弹性推到更紧张的位置。

团队对 HNSW 与 IVF 索引使用标量量化和乘积量化，再把大规模倒排列表移到固态硬盘上的 SPANN 服务中。原文的实验显示，不同量化方案在索引体积、召回和查询吞吐间存在明显取舍，在线工作负载报告了百分之二十到三十的服务成本节省。

这条经验适合用来审视检索系统的目标函数。高召回、低延迟、低内存与高吞吐不会自动同时出现，团队需要先确认用户体验最敏感的是哪一项，再选择压缩方式和存储层级。把取舍显式写进架构，通常比追逐单一基准更可靠。

无问芯穹联合清华、上交正式开源具身端侧推理引擎 APXInf，Pi 0.5 性能 SOTA

来源：量子位 · BestBlogs 评分：86

无问芯穹联合清华大学、上海交通大学开源 APXInf，面向机器人本体上的具身模型推理。它支持 Jetson Orin、Jetson Thor 与 RTX 4090 等平台，目标是把模型开发、验证和设备部署连接起来。

文章给出的 Jetson Thor 测试中，Pi 0.5 FP8 的端到端推理延迟从二百七十八毫秒降到二十六毫秒以内，频率达到三十八点四六赫兹。结果来自发布方测试，真正的设备表现还会受模型、传感器和控制链路影响，但它说明端侧运行时优化会直接影响感知到动作的闭环。

对具身系统，模型效果好并不等于机器人能稳定工作。小批量负载、功耗限制、硬件适配和长时间运行都必须被纳入部署设计。把运行时视为模型能力的一部分，能帮助团队更早发现从演示到实物之间的差距。

用 1393 个 Agent 重构 Hermes 代码库：削减 34.4% 的实践复盘

来源：meng shao(@shao__meng) · BestBlogs 评分：91

Nous Research 复盘了 Hermes 代码库的一次大规模重构：一千三百九十三个子 Agent 参与协作，非测试 Python 代码从一百多万行缩减三成多。目标不仅是删代码，也包括把巨型文件和过长函数拆到更容易理解的尺度。

这次协作把仓库切成三十六个互不重叠的组，每个工人在独立 git worktree 中处理任务，顶层编排者主要协调而不直接改代码。接口保真则依靠工具 JSON schema 与命令行帮助做逐字节比对，任务中断后还能利用已提交的改动和任务书恢复。

这份复盘的重点不是并行数字本身，而是如何让并行不互相踩踏。清晰的文件边界、可独立验证的接口和可恢复的任务记录，能把 Agent 协作从一次性尝试变成可检查的工程过程。代码库越大，这些约束越值得先建立。

1300 万天压到 0.25 秒！分子之心用 AI 把化学反应拍成电影，成果登 Science 子刊

来源：新智元 · BestBlogs 评分：86

分子之心介绍反应性机器学习力场 QuantaMind，目标是在接近密度泛函理论精度的同时，以更接近经典分子动力学的速度模拟化学反应。论文聚焦的难处在于，模型不仅要看对单个结构，还要在长时间轨迹里稳定地处理成键、断键和过渡状态。

文章称其训练纳入非平衡构型与过渡态数据，并把不同精度层次的量子化学设置编码进模型。在一个包含一万七千多原子的酶体系中，研究者模拟了完整催化循环，并从轨迹中抽取构型做独立的 DFT 单点验证。内部测试还报告十万原子级体系每一步约零点二五秒的耗时。

这类结果的价值在于把化学研究从少量静态构型，推进到更长的连续过程。数字需要在具体体系与验证方式下理解，但如果模型能先提供反应机制和候选突变的线索，实验团队就可能把更多精力放在更有希望的验证路径上。

Claude for Small Business：新工作流、集成与培训

来源：Claude Blog · BestBlogs 评分：88

Claude for Small Business 新增四十三个工作流和二十七项工具集成，覆盖线索处理、报价、营销内容和月度对账等小企业常见事务。它还配套线下研讨会与合作伙伴培训，试图把工具连接、任务模板和使用方式一起交付。

公告举例说明，商家可以让 Claude 汇总客户关系管理信息、财务工具、邮件和协作平台的数据，再按设定的周期生成简报或草稿。部分任务可以等待人工确认后执行，连接器不足时也能从导出的报表或手动提供的信息开始。

小团队从这类产品中获得的启发，是先选输入清楚、结果容易复核的重复事务。自动化的价值不在于一次接管所有后台工作，而在于减少信息搬运，让经营者更快看到该处理什么、为什么处理，以及哪里仍需人工判断。

语音智能体不只会说话：Charlie Guo 谈三种可混用模式与原生实时音频 | OpenAI

来源：AI Engineer · BestBlogs 评分：86

OpenAI 的开发者体验团队提出，语音智能体不一定要用语音回答。它可以是语音到语音的交谈，也可以是用户说话后触发操作，或在事件发生时用声音提醒用户，三种模式可以按产品任务混合使用。

分享把原生实时音频与传统的识别、文本推理、语音合成链路对照。直接处理音频有机会保留语气、节奏和背景声等信息，而工具调用和推理能力又能让声音成为软件操作的一层入口。对需要等待的任务，先给出简短提示也能帮助用户理解系统状态。

这为语音产品提供了一个简单的起点：先问声音在当前交互里承担什么角色。是陪练式回应、免手操作、无障碍提醒，还是对复杂界面的补充？把声音当成多种反馈手段之一，能避免为了像真人交谈而让产品不停说话。

今日小结

回顾今天的内容，语音 Agent 的难点在于对话节奏与任务委派，Agent 平台的难点在于隔离、网络与闲置资源，企业 Agent 的难点则落在既有权限与人工确认。它们共同提醒我们，能力越能主动执行，系统的边界越应该清楚。

时间有限时，可以先从 Gradium 的全双工讨论理解语音交互，再读 Agent Substrate 看运行环境的约束，最后用 Salesforce 接入 Claude 的案例检查企业流程。对检索、机器人、代码协作或科学计算感兴趣的读者，可把速览当作各自领域的实践入口。

你所在团队的 Agent 最容易在哪一步失去用户信任，是它误解了交互节奏、无法解释执行状态，还是写入业务系统前缺少确认？这个问题没有统一答案。如果已经有一项自动化在稳定运行，也欢迎分享它靠什么边界与反馈机制获得了使用者的信任。

👉 近期早报

• BestBlogs 早报 · 2026-09-16

• BestBlogs 早报 · 2026-09-15

• BestBlogs 早报 · 2026-09-14

• BestBlogs.dev 第 112 期：可托付的智能

• BestBlogs.dev 第 111 期：经验复利

• BestBlogs.dev 第 110 期：新的稀缺

BestBlogs 是 AI 驱动的私人阅读助手，帮助你发现真正适合你的高质量内容，关注你感兴趣的来源和主题，每天生成一份更适合自己的「我的早报」，欢迎体验和关注我们。