AI日报 9月1日：AWS Agent Registry、Bedrock 检索与 Claude Code 修复

9月1日这期集中回答三个现实问题：AI 基础设施怎样分别处理存储性能与运行隔离，企业怎样统一治理代理、工具和技能，检索应用怎样同时做好可观测性与租户隔离。另有 Claude Code 2.1.252 修复两类会打断本地工作流的问题。

本期保留五项能够回到一手页面核对的更新。Google Cloud 的基础设施月报发表于9月1日，其余四项的一手记录发表于8月31日；这里按9月1日历史日报的收录范围整理，不把收录日期冒充来源发布日期。

正文先写来源明确确认的事实，再用普通语言解释工作方式和落地影响。本文没有部署这些架构，也没有复现版本问题；产品能力、架构边界和修复结果均按发布方原文归属，不写成本站测试结论。

基础设施与代理治理：性能、隔离和目录各解决什么问题

Google Cloud AI 基础设施更新：存储性能与 Ray 隔离分别推进
- Google Cloud 在2026年9月1日的更新中说明，Filestore 基于 Colossus 的新存储后端允许用户把 IOPS 与存储容量分开配置，并已与 GKE 深度集成。
- 同一更新还确认，GKE 上的分布式 Ray 集群已经可以使用 gVisor 沙箱。
容量决定能放多少数据，IOPS 描述存储每秒可处理多少次输入输出操作。把两者分开配置，可以按访问强度增加性能，而不必只为获得更多 IOPS 同时购买更多容量。gVisor 则是在容器工作负载与宿主内核之间增加隔离层，面向的是运行边界，不是存储速度。

在 GKE 上运行训练、数据预处理或 Ray 分布式任务的团队，可以分别检查存储瓶颈和代码隔离需求，再决定是否采用相应能力，避免把扩容、提速和安全隔离混成一个采购指标。

Google 将此次 Ray 与 gVisor 集成库明确称为实验性库，不能把“可以试用”理解成生产成熟度保证。这篇月度更新也不是相同业务负载下的对照测试；本文未测 IOPS、成本、兼容性或隔离开销，部署前仍需确认地区、配额和 GKE 版本要求。

Google Cloud · Google Cloud AI 基础设施 · 一手来源 · 2026-09-01
AWS Agent Registry 正式可用（GA）：统一登记代理、工具和技能
- AWS 在2026年8月31日宣布 AWS Agent Registry 已正式可用，并把它定位为代理、工具、技能与自定义资源的统一、可搜索、可治理目录。
- AWS 说明 Registry 在内部通过 Governance Plane 与 Discovery Plane 两个互补平面运行，用于把资源治理与日常发现分开处理。
- 面向使用者的发现结果只展示管理员或策展人批准的记录；草稿、被拒绝及影子资源不会出现。
登记表解决的是“组织里有什么、由谁维护、能否被使用”。治理平面负责记录、审批和生命周期，发现平面让获准资源被搜索和调用。这样做不会自动提高代理推理能力，但能减少团队各自维护清单、名称冲突和未经批准资源被误用的问题。

当多个团队同时创建 MCP 服务器、代理与技能时，统一目录能把负责人、状态和可发现范围放到同一治理流程中。采购或平台团队可据此建立准入规则，再让开发者只检索已经批准的资源。

GA 表示该服务已正式可用，不等于目录中的每个条目都安全或有效。管理员仍要定义审批责任、权限、更新与下线流程，并验证地区、价格和现有身份体系的接入；本文没有在真实组织中部署或压测 Registry。

AWS · AWS Agent Registry · 一手来源 · 2026-08-31
Amazon Bedrock 可观测智能检索：把规划、引用和追踪放进一套架构
- AWS 说明，托管 Knowledge Bases 的智能检索会进行多轮规划、执行检索工具，并生成带引用、由检索材料支撑的回答。
- 该参考方案建立在 Amazon Bedrock Managed Knowledge Base 与 Amazon Bedrock AgentCore 之上，并通过一条 AWS CloudFormation 链部署。
- 运行过程中会向 Amazon CloudWatch 与 AWS X-Ray 发出调用追踪片段（span）、Token 用量和指标，用于填充方案定义的七层可观测数据。
智能检索并非只做一次关键词查询：系统先判断还缺什么信息，再调用检索工具，把结果交给模型组织答案和引用。可观测层同时记录每一步调用、耗时、Token 与评估数据，出现错误时可以区分是规划、检索、模型生成还是基础设施环节出了问题。

企业知识问答如果已经从单次检索发展到多步代理流程，这套参考架构提供了一个可检查的起点。开发团队能沿调用链寻找空结果、错误引用和费用异常，运营团队也更容易建立质量与成本告警。

CloudFormation 能重复部署资源，但不会自动保证文档质量、召回率、回答正确率或费用上限。文章展示的是参考架构，本文未部署、未复现七层观测面板，也未验证不同地区与账号中的服务可用性。

AWS · Amazon Bedrock 可观测智能检索 · 一手来源 · 2026-08-31

开发工具与企业检索：修复故障，也守住数据边界

Claude Code 2.1.252 修复 macOS Bash 与权限保存故障
- Claude Code 2.1.252 修复了部分 Mac 上 Bash 命令因“task output swap refused (tasks dir moved or linked)”而失败的问题。
- 该版本还修复了一个权限持久化问题：项目尚无 .claude/settings.local.json 时，“always allow”设置无法保存。
这两项都是故障修复，不是模型能力升级。第一项处理任务目录状态导致的命令执行失败；第二项处理本地设置文件尚未创建时的首次写入路径。判断是否命中修复，应以原错误信息和项目状态为依据。

在 Mac 上遇到相同 Bash 报错，或发现“always allow”重启后丢失的用户，可以把当前版本、项目目录状态和失败命令记下来，升级后按原步骤复测，以确认问题是否真正消失。

发布记录没有证明所有 Bash 或权限问题都由这两个缺陷造成，也没有给出各 macOS 版本的完整测试矩阵。本文未复现问题；已经使用更新版本的用户不应为追溯旧修复而降级。

Anthropic · Claude Code · 一手来源 · 2026-08-31
Amazon Bedrock 多租户文档聊天架构：用认证身份约束检索范围
- AWS 说明，Amazon Bedrock Managed Knowledge Base 负责处理资料摄取、存储、向量嵌入和排序等环节。
- 示例应用调用 AgenticRetrieveStream API 时，对 user_id 传入明确的 equals 过滤条件，以限制本次检索的数据范围。
- 该过滤值由服务器根据已经验证的 JWT 构造，而不是直接采用请求正文中由客户端提交的值。
多租户系统把不同用户或组织的数据放在共享服务中，因此每次检索都必须先确定调用者身份，再把该身份映射为服务端过滤条件。先过滤候选文档，再让模型生成回答，才能避免模型在已经拿到别家资料后再靠提示词“自觉不说”。

需要让客户或内部部门查询各自文档的团队，可以据此检查访问链：JWT 在哪里验证，user_id 由谁生成，过滤条件是否覆盖每次检索，日志能否追踪身份与结果。这个顺序比单纯优化回答措辞更重要。

这是一套参考实现，不能替代 IAM、令牌校验、租户映射和越权测试。根据问题内容推断的相关性过滤不能作为访问控制；如果服务端显式过滤缺失或配置错误，模型本身不会补上可靠的数据隔离。本文未进行渗透或并发测试。

AWS · Amazon Bedrock 多租户文档聊天架构 · 一手来源 · 2026-08-31