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

BestBlogs 早报 · 09-03｜Gemini 3.8 升级，Claude 构建电商智能体，GitHub 降本

在线阅读本期早报

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

导语

模型单价保持不变，完成工作的成本却可能变化：更强的推理会增加计算，也可能减少试错；更短的工具输出能省下上下文，也可能让智能体重新读取。理解 AI 的实际价值，需要把能力、工作过程和最终结果放在一起观察。

Google 发布 Gemini 3.8 Flash 系列，为编码和网络防御提供新的选择。Anthropic 从电商生产项目解释会话状态、工具和交易规则怎样配合。GitHub 则通过 Copilot 的具体实验，说明哪些工程调整能够减少重复工作。后面的研发、组织与评测实践，可以帮助读者把这些判断放回自己的业务。

★ 精讲一：Google 发布 Gemini 3.8 Flash 系列：升级编码与漏洞修复

来源：Google DeepMind News · BestBlogs 评分：93

Google 推出的 Gemini 3.8 Flash 系列包含两个变体。通用 Flash 面向长周期软件工程、自主任务和专业领域推理；Flash Cyber 面向漏洞发现与自动修复。两个版本共享基础智能能力，针对不同部署场景提供访问方式，也把模型评估从单轮回答延伸到持续执行。网络防御能力的展示包含厂商内部基准，补丁修复另有外部评测。

编码能力提升，任务用量需要一起看

通用 Flash 延续 3.7 Flash 的入门价格：每百万输入 token 为 0.75 美元，输出为 3.75 美元。Google 在长程软件工程、金融和法律智能体任务中展示了性能进步。对于开发者，重要的变化是模型能否在复杂工作中持续调查、调用工具并完成交付，这与短问题上的回答速度承担着不同任务。

Google 将这些提升与训练创新、网络安全领域的高要求任务联系起来。新的模型也会在复杂任务上多做推理、反复调用工具。同单价与同成本需要分开判断：一轮计算的价格没有上升，并不直接说明整项任务的支出相同。推理带来的质量收益，要和新增用量一起比较。

这使推理强度成为可以主动配置的变量。Google 建议计算效率优先的应用考虑较低的推理档位，或继续使用仍获支持的 3.7 Flash。团队可以用同一组真实任务比较完成质量、时延与总用量：容易完成的请求是否需要额外推理，复杂请求能否因为更好的规划减少往返，答案取决于业务负载。

Cyber 把漏洞发现与修复分别验证

Cyber 的测试覆盖发现问题和生成补丁。在 Google 内部涵盖 20 种编程语言的漏洞发现基准上，成功率超过 70%；这一数字对应内部测试范围。外部补丁基准 CWE-Bench 上，Google 报告的 pass@1 为 47.2%。两个数字衡量不同任务，分别帮助理解它找出问题与完成修复的能力。

实际应用方面，Chrome 安全团队报告，Cyber 生成的正确补丁数量达到受比较的大型商用模型的 2.6 倍。Google 的云漏洞研究团队还使用它在不到 2 小时内发现一个关键漏洞。这些案例为安全维护者提供了更具体的接入位置：把模型用于代码调查与修复准备，再交给既有工程流程检查和部署。

Cyber 通过 Fairwind 计划向受信防御者提供访问，包含政府机构、关键基础设施运营者与软件维护者等对象。通用 Flash 则进入 Gemini API、相关开发工具与产品。组织评估时可以先分清所需能力与访问条件，再安排真实负载测试，让试用过程能够回答具体工作中的问题。

★ 精讲二：Anthropic 电商智能体构建指南：架构、成本与生产实践

来源：Claude Blog · BestBlogs 评分：94

Anthropic 的电商智能体指南来自零售、旅行、娱乐和电信等已经运行的项目。其参考架构由一个主智能体、按需加载的技能、工具和评测组成。购物者搜索商品、比较替代品、调整购物车时，共享的是同一段历史、同一组偏好和待执行变更；架构首先要让这些信息能够连续使用。

让会话保持完整，让技能按需进入

在紧密耦合的电商对话里，按业务领域反复委派子智能体会增加交接成本。主智能体需要重新传递购物车、历史和约束，接手者也可能缺少必要状态。技能提供了另一种模块化方式：把相关步骤加载进主会话，需要的能力进入上下文，已知用户信息仍然留在原位。

这种设计仍保留适合独立任务的委派。例如深度研究可以在单独上下文里检索和尝试，最后返回简洁结果；已经拥有独立合规流程的专用服务，也可以完整接管用户会话。选择的依据是任务如何共享状态，以及谁持续负责与用户交流，而不是仅凭业务部门数量划分智能体。

工具应复用现有业务系统。搜索服务提供已经排序的结果，库存、购物车和促销系统维护各自规则，模型判断哪些内容符合用户目标、怎样组织和呈现。把业务逻辑留在已有系统里，也使后续规则变更有清楚的维护位置，避免在工具封装中重新拼出另一套订单或履约逻辑。

界面同样进入工具契约。模型通过 present_products 等展示工具输出结构化参数，服务端校验并补齐资料，客户端负责渲染。展示参数还要反映真实的行列和顺序，用户说左边第三件商品时，模型才能根据对话记录理解指代。界面状态与自然语言由此保持一致。

按变化频率组织上下文

缓存是生产设计的一部分。指南把请求划为全局、会话和易变内容：共用系统说明与工具定义在前，用户资料和历史居中，当前时间或页面状态放在末尾。由于缓存按相同前缀复用，稳定内容越早出现，后续轮次越有机会沿用已有计算。频繁变化的字段放在开头，则会让整个请求更容易失去复用机会。

长期记忆也需要明确归属。Anthropic 建议将事实放进业务自己的存储，按用户记录来源、类别等信息，并提供查看、更正、删除和保留期限管理。写入可以交给异步过程，从用户与助手的对话提取事实，避免商品介绍或评论被误存为用户偏好。这样既照顾会话时延，也便于管理记忆质量。

用业务规则执行交易，用状态快照检验结果

模型提出购物车或经营变更，实际执行由服务端控制的确认流程接手。交易工具接受服务器发出的标识，审批后再次按当前规则检查限制。指南还要求按写入后的状态判断购买上限，并对同会话的购物车写入排序，避免并发请求叠加超过限制。约束落实在状态变化发生的地方。

评测则直接构造会话快照：系统说明、工具、历史和当前请求组成一个可重放起点，随后检查最终状态与展示结果。已经出现矛盾要求、经过多次工具调用的场景尤其有意义。真实故障沉淀下来，团队修改某个技能或提示词时，就能检查相邻能力是否受到影响。

这份指南把电商智能体拆成了可讨论、可实施的责任分工。业务团队维护规则，平台维持共享能力和发布节奏，模型在得到授权的工具范围内理解需求。先把一个购买或商家运营流程完整走通，再讨论新增技能和更换模型，团队更容易知道每项变化应该由谁验收，以及怎样证明它改善了服务。

★ 精讲三：GitHub 如何在保证任务质量的同时提高 AI 编程的成本效率

来源：The GitHub Blog · BestBlogs 评分：87

GitHub 的 Copilot 实验从一个反例开始：命令输出变短，任务成本却可能增加。在团队测试的 RTK 集成与工作负载中，有用信息被压掉后，模型会重新打开原始结果或执行命令，增加交互轮次，并把更多历史继续带入上下文。局部节省需要放到完整任务里核算。

区分内容类型，保留继续工作的线索

团队最后采用了选择性压缩。源代码、代码差异和任意脚本结果保持原样；搜索结果可以重排分组，但不删除匹配；安装、构建、测试和进度输出中的重复信息，才在收益足够明显时压缩。处理方式由信息用途决定，避免因为统一缩短输出让模型重新做一次探索。

原始结果仍有恢复路径，而且恢复行为本身成为评估信号。团队观察智能体是否重新打开文件、重复命令、收窄搜索或增加轮次。如果这些动作频繁发生，可能意味着压缩删除了需要的信息。该方法把优化的反馈接回具体行为，比只盯着单次返回长度更容易解释成本变化。

一项更直接的调整是移除读取文件时的逐行编号。旧编辑工具依赖行号定位，当前工具则根据周围文本匹配修改，因此日常读取附加的行号已经不再承担同样作用。删去格式后，源码逐字保留。GitHub 的离线测试中推理成本下降约 5%，线上实验中用户平均每日推理成本下降约 3%。

这些百分比对应不同实验环境。线上所跟踪的质量和满意度指标未出现实质退化，让团队能够确认这一改动确实省去了模型不用的信息。行号在差异或短片段中仍有用途，文章讨论的是完整文件读取场景。对自己的工具输出做同样检查，通常比直接删减内容更容易保持行为稳定。

提示词压缩也需要行为回归测试

Copilot 用一轮自我改写压缩了启动并行任务的提示词，初次离线评估看起来可行。线上实验却暴露了另一种变化：一些独立的自定义智能体开始顺序工作。压缩把谨慎考虑并行的指导变成更硬的调度规则，原来希望保留的协作行为随之改变。

团队停止实验，先为这个问题加入回归评测，再调整提示词。最终版本保留独立任务可以并行、同时考虑副作用的含义。这使评测更接近用户实际需要：一项行为能否继续发生，应在压缩之前就有验证方式。提示词减少字数的过程，也可以成为梳理系统约定的机会。

后台通知提供了另一条降本路径。过去，命令或子智能体结束后，模型先收到通知，再请求已经产生的结果。多个任务相继完成，就可能反复进行这种取件式交互。现在符合条件的结果可以批量装入已有工具返回格式，随着通知一起送达，减少不携带新判断的模型往返。

这项通知调整报告了约 2.3% 的 token 相关用量下降。原文将输出压缩、格式移除、提示词和通知列为独立实验，效果不能直接相加。共同的实践方法是先用离线任务发现可能的收益，再在真实使用中验证质量和成本，遇到行为变化就补充测试，而不是只依赖一个汇总数。

团队可以先检查重复格式和无效通知，再评估日志压缩是否引发回读、重试或遗漏。这为模型选型之外提供了具体改进方向：减少原本不需要模型参与的步骤，让完整任务以更少的重复工作完成。

速览

【AI新闻】Claude Fable/Mythos 5.1：新SOTA模型，75%缓存价格削减但70%更多输出令牌

来源：Latent.Space · BestBlogs 评分：86

Latent.Space 梳理了 Claude Fable/Mythos 5.1 的发布，包含编程、知识工作能力与缓存读取价格变化。缓存读取单价下降 75%，对长会话尤其相关：智能体会反复携带历史和工具结果，已有上下文的复用成本会影响持续执行的总支出。

文章同时引述 Artificial Analysis 的测试，报告输出 token 用量约为此前的 1.7 倍，其测量中的单任务净成本增加约 20%。这些观察与厂商缓存单价描述的是不同层面。任务组成、推理强度和缓存占比变化，都可能让实际账单呈现不同结果；模型之间是否共享权重的讨论仍应按社区推测看待。

因此，新版本可以和原配置放进同一组实际任务比较，记录结果质量、缓存命中、输出用量与完成时间。与前面的 GitHub 实验一起看，模型发布提供新的能力选择，工程测量则帮助团队判断这些能力在自己的流程中能换来什么。

大淘宝 AI 驱动研发体系的实践和思考

来源：大淘宝技术 · BestBlogs 评分：91

__XPOSTER_deh23_IMAGE_5__

大淘宝技术介绍了 Price360-KB 的项目实践，把业务知识、源代码、协作规则和验证证据组织进一个 Git 工作空间。稳定资料随代码版本维护，日志、配置、数据库和工作项状态仍从权威系统实时获取。智能体执行时将两类信息汇合，减少新会话反复补充背景的负担。

团队把长期知识区分为业务规则与跨系统技术上下文，避免重新写一套代码说明。每次需求留下 PRD、方案、用例与验证结果，交付结束后再把确认过的知识回流。规则、技能与确定性脚本各自承担协议、任务组织和门禁执行，形成持续维护知识的路径。

老系统可以从现有资料与代码起步，把知识更新嵌入真实迭代。对业务团队而言，价值在于每次交付同时增加下一次工作的上下文：今天发现的规则和排障线索，怎样在下次需求中可靠地被找到，又怎样跟随代码变化一起更新？

Claude Code 团队如何用 Claude Code 重塑软件开发流程

来源：Claude · BestBlogs 评分：90

Claude Code 团队分享了通过 Claude Tag 等工具开展开发的方式：给出目标，让智能体读取产品背景和团队决策，推进方案、实现、验证与反馈。团队成员的经验显示，任务的单位逐渐从一段代码扩展到一个需要持续完成的工作，而远程环境让执行能够越过本地会话的结束。

代码审查采用先并行查找、再归并核验的方法，用多角度复核过滤误报。提交修改时附上测试、截图等产物，让人能够检查实际行为。团队也讨论了随着模型能力变化，旧有功能可能需要收缩或改造，工程工具应继续围绕当前真实的失败方式演进。

这种工作方式给人留下的责任更明确：判断目标、理解服务划分和检查交付结果。与大淘宝的实践相互参照，一边重视长期业务知识，一边强调可检查的运行产物；两者都让更大范围的委派有了具体依托。

对话兰小欢：置身 AI 事内，不要拿旧理论硬套新现实｜AI 透镜研究系列

来源：腾讯研究院 · BestBlogs 评分：90

__XPOSTER_deh23_IMAGE_7__

腾讯研究院与兰小欢的对话从风险、责任和可替代性理解 AI 组织。兰小欢认为，个人借助智能体可以完成更多工作，但组织还承担隔离风险、提供赔偿能力和持续履约的作用。执行能力的扩大，与个人能够承受的损失并不会同步增长。

他用律所、审计等场景解释签字和责任为何仍然重要，并沿付款链观察利润流向哪里。信息变得容易获得之后，议价能力可能集中到暂时难以替代的位置；Token 可以计费，却会随模型和分词方式变化，难以单独解释完整产业关系。

这为 AI 商业判断提供了一种具体问法：谁掌握决定，谁承担失败，客户为什么无法轻易换掉这一环？把这些问题放回合同、交付和责任安排中，可以帮助团队理解自己的价值来源，也为人员分工和产品承诺提供更扎实的依据。

Google AI Agents 挑战赛作品背后的 4 个工程模式

来源：Google Developers Blog · BestBlogs 评分：86

Google 从 AI Agents Challenge 的实际作品提炼四种工程模式：双向 MCP 工具接口、事件驱动并发、同标准回退验证，以及调用昂贵模型前的分层路由。它们分别处理能力复用、执行等待、降级质量和推理支出，适合按当前系统的瓶颈逐项判断。

一个案例让性能分析能力通过工具接口供其他智能体调用；另一个案例让主模型和备用模型的输出经过同一个验证函数。这样，切换模型不会漏掉原有检查。对于互不依赖的任务，事件总线则允许它们响应相同信号，减少串行等待。

这些模式与 Anthropic 的单会话架构各有场景：共享购物车的紧耦合交互需要保持上下文，独立事件处理则适合分开运行。先描述状态怎样流动、任务怎样依赖，再选择协作结构，比按智能体数量判断架构更能指导实施。

1.5 TB 压到 214 GB，Hy4 preview 轻量版来了

来源：腾讯混元 · BestBlogs 评分：90

腾讯混元通过 Sherry 稀疏三值量化和逐层混合精度，把 Hy4 preview 权重从约 1.5 TB 缩小到 214 GB。较敏感的层保留较高精度，耐受压缩的部分使用更低比特表示，让有限存储优先分配给影响效果的部分。

团队报告，量化后长文理解和检索表现接近原版，数学任务有小幅回落。异构设备演示将笔记本与服务器结合，以 1.02 token/s 运行模型。这个数字对应演示配置，说明现有设备组合能够运行该权重，也让用户直观看到实际等待速度。

对希望本地使用模型的团队，新的选择是同时比较权重大小、任务效果和输出速度。在硬件预算已定的情况下，逐层量化和联合调度提供了试验路径；是否适合日常使用，则可以由自己的文档、代码与工具调用任务给出答案。

AI Agent 应用精细化评测：评测体系设计与工程实践

来源：阿里技术 · BestBlogs 评分：92

阿里技术以商品中心的智能体为例，构建覆盖感知、规划、记忆和工具的精细化评测。端到端测试判断用户任务是否完成，模块评测帮助定位失败原因：意图识别、路由选择、历史信息保留与工具参数，都可以成为单独观察的对象。

测试集覆盖知识问答、多轮对话、异常输入、多意图和长对话等场景，成本与时延指标通过运行埋点采集。体系还区分信息忠实性和信息源准确性：模型是否忠实使用获得的材料，与知识库本身是否正确，需要分别治理。

这类设计让评测报告能够指导下一步修改，而不仅给出一个总分。把失败用例、模块表现和完整任务结果连接起来，团队更容易解释一次优化的收益，也能发现质量、成本和速度之间的取舍。它和 Copilot 的实验共同说明，好的测量应该帮助人找到具体可改的环节。

今日小结

回顾今天的内容，Gemini 更新了模型与防御能力，Anthropic 解释交易会话怎样组织，GitHub 展示任务成本怎样从具体工程环节改善。能力、状态与反馈分别构成一组可观察的选择，让团队能够沿实际工作判断收益。

正在选择模型，可以先比较 Gemini 与 Fable 的能力和用量；准备搭建产品，可以从 Anthropic 电商指南进入，再结合大淘宝和 Google 的实践检查上下文与协作方式；已有系统需要优化，则从 GitHub 实验和阿里评测体系寻找可测量的切入点。

也欢迎分享你的经验：最近一次有效改进来自模型升级、业务知识整理，还是减少重复调用？当智能体可以承担更多执行工作，你会保留哪些环节亲自判断？具体任务与结果，往往能让这些讨论更有参考价值。

👉 近期早报

• BestBlogs 早报 · 2026-09-02

• BestBlogs 早报 · 2026-09-01

• BestBlogs 早报 · 2026-08-31

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

• BestBlogs.dev 第 109 期：程序员的职业未来

• BestBlogs.dev 第 108 期：智能的执行层

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