全球 AI Agent 基础设施研究周报 · 第 7 期（2026-07-23 ~ 2026-07-29）

• • 📂 AI •
⏱ 约 105 分钟阅读
全球 AI Agent 基础设施研究周报 · 第 7 期（2026-07-23 ~ 2026-07-29）
全球 AI Agent 基础设施赛道 · 2026 第 31 周

本期覆盖区间为 2026-07-23 00:00 → 2026-07-29 24:00（Asia/Shanghai），固定扫描 24 个 AI Agent 基础设施核心对象。A 组 6 个云厂托管 Agent Runtime / Agent Platform 全覆盖；B/C/D/E 四组覆盖模型与协议控制面、开源 Agent OS / Runtime、知识获取与 Memory、Identity / Auth / Tool Permission。

这一周的主线很集中：Agent 基础设施竞争已经从“能不能把 agent 跑起来”，转到“能不能把 agent 作为受身份、权限、审计、成本和恢复机制约束的生产工作负载来运行”。云厂在托管 runtime、gateway、observability 上补企业控制面；模型厂商和框架把 tool calling、sandbox、MCP、deployment、evals 做成协议化边界；Memory 和 Identity 层则开始回答企业最关心的问题：事实从哪里来、谁能看、token 是否进模型、每次 tool call 能否追责。

本周主线

  1. 产品/技术更新：云厂 runtime、MCP gateway、sandbox、observability、programmatic tool calling、temporal memory graph 都在本周继续生产化。

  2. 生态/合作：OpenAI/Anthropic/LangChain/Databricks 与 AWS/Google/Microsoft 等平台都在围绕 MCP、A2A、ADK、Agent Framework、Stagehand、CloudBase Toolkit 等形成跨框架互操作。

  3. 采用与商业化：阿里 Token Plan、火山 Agent Plan、腾讯 TokenHub、Modal Kimi K3、Databricks 生产线 CoPilot 说明 agent workload 正在被套餐化、行业化和平台账单化。

  4. 竞争格局：AWS 偏企业 control plane，Google 偏 ADK/Agent Platform 开发链，Microsoft 偏 Foundry + M365/Entra 分发，国内云厂则用编码工具套餐、云端 NPC 和生态入口抢真实 agent 流量。

  5. 身份/权限/安全：E 组显示 token 托管、OAuth/OIDC、MCP auth、tool-level scope、ABAC、audit log、connectionId 绑定已经成为 agent 基础设施的采购门槛。

本期 TOP 5

  1. AWS AgentCore：单 Agent 可观测 + MCP 2026-07-28 Gateway。AWS 在本周同时补齐 /aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name> 单 agent log group 与 MCP 多版本 gateway，企业 SRE、安全、审计和协议迁移成本明显下降。

  2. 腾讯云 ADP 4.0 + CodeBuddy NPC。腾讯云把 AgentOps、云端沙箱、Git/CI/CD 研发闭环、Skill/Workflow 治理、TokenHub 与 CloudBase AI Toolkit 放进一个组合，国内云厂里最像“真实工作流中的 agent runtime”。

  3. OpenAI Programmatic Tool Calling。Responses API 与 Agents SDK v0.19 把模型生成 JavaScript 协调工具、allowed_callers、approval、guardrails、sessions、sandbox harness/compute 分离推到控制面核心。

  4. MCP 2026-07-28 与 Anthropic/Nango/AWS 跟进。MCP 新 revision 的 stateless requests、Mcp-Method / Mcp-Name headers、server discovery、多版本协商，让工具网关像 API Gateway 一样可授权、可路由、可审计。

  5. Zep/Graphiti：Memory 进入 provenance 与 ABAC 阶段。Zep 把 episodes、valid_at/invalid_at、source metadata、ABAC 与 graph traversal 串成可追溯记忆；Graphiti 0.29.0 降低 temporal graph ingestion 成本，memory 不再只是向量召回。

云厂平台

云厂把 Agent 当生产工作负载来治理。

AWS：AgentCore

对象：Amazon Bedrock AgentCore（AWS）

  • 本周动态：本周 AWS 对 AgentCore 的“可运维 runtime / gateway”补了两块关键底座。其一，7 月 23 日 What’s New 宣布 AgentCore observability 从分散日志改为单 Agent 单 CloudWatch log group：原先 trace spans 在共享 aws/spans，prompts/inputs/outputs 在资源级 log group；新建 agent（文中说明 2026-07-20 起，在支持 Region）默认把 traces、prompts、structured logs、stdout 聚合到 /aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>，并可对单个 agent 施加 IAM policy、CMK encryption 与订阅导出。既有 agent 通过 runtime 环境变量 UNIFIED_TRACES_DESTINATION_ENABLED=true 迁移；What’s New 写 ADOT 0.17.1+，开发文档当前写 aws-opentelemetry-distro>=0.18.0 才能识别 span destination 配置，落地时应以后者为准。其二，7 月 28 日 ML Blog 把 AgentCore Gateway 对齐 MCP 2026-07-28：新协议 stateless，单次 tool call 携带 MCP-Protocol-Version、Mcp-Method、Mcp-Name 与 _meta，支持 server/discover、ttlMs/cacheScope、W3C Trace Context、JSON Schema 2020-12；Gateway 通过 UpdateGateway 的 protocolConfiguration.mcp.supportedVersions 一次配置多版本（2025-03-26、2025-06-18、2025-11-25、2026-07-28），不需要重建 gateway 或逐 target 修改。安全边界上，AWS 明确 inbound auth（IAM SigV4 或 OAuth/JWT）与 outbound credential providers 不随协议升级改变；但新版本会把 unsupported version 返回 HTTP 400/code -32022，header-bound field 缺失/矛盾为 -32020，能力缺失为 -32021，更利于 API gateway/监控按 HTTP 层做限流、审计和告警。商业判断：AWS 本周不是在发布“新模型”，而是在把 AgentCore 从 preview/开发工具推向企业托管运行面——按 agent 隔离 observability 与协议多版本网关，是大型组织接受托管 agent runtime 的前置条件。
  • 关键数据：/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name> 单 agent log group；新建 agent 2026-07-20 起默认启用；Gateway 支持 4 个 MCP protocol versions；来源 https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-unified-observability-single-log-group/ （2026-07-23）与 https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/ （2026-07-28）。
  • 原文链接：https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-unified-observability-single-log-group/；https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/；https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-configure.html
  • 影响判断：AWS 正在把 AgentCore 的竞争点从“能跑 agent”推进到“能被企业 SRE、安全与平台团队治理”。MCP 2026-07-28 支持尤其重要：Gateway 既能承接生态协议升级，又用多版本协商降低破坏性迁移风险，这会强化 Bedrock 在跨工具、跨团队 agent 托管场景的黏性。

Google：Vertex AI Agent平台

对象：Google Vertex AI Agent Engine + Agent Builder + ADK / Enterprise Agent Platform

  • 本周动态：Google Cloud 官方博客在时间窗内未检出 Agent Engine/Agent Builder 的重大公开发布；但 ADK 开源仓库与文档在本周显示 Google 正把 Vertex AI Agent Engine 重命名/并入 Gemini Enterprise Agent Platform 的“Agent Platform Runtime”叙事，并持续补齐托管 agent 的部署、身份与沙箱边界。7 月 28 日 google/adk-python 提交 93db97d 为 adk deploy agent_engine 增加 --extra_packages / extra_packages 配置：本地文件或目录会被 stage 到构建上下文、写入 Dockerfile COPY --chown=myuser:myuser，并通过 ENV PYTHONPATH="/app:$PYTHONPATH" 使自定义包可 import，source_packages 也从 agents/<app_name>, Dockerfile 扩展到 *staged_extra_packages；这解决的是企业 agent 依赖私有工具包/共享代码部署到 Agent Platform 的打包痛点。同日 8d2ded3 增加 /agent-identity/finalize 端点，用 connector_name、user_id、user_id_validation_state、consent_nonce 完成 3-legged OAuth consent 的 Agent Identity credential finalization，说明 Google 在把“agent 以终端用户身份访问连接器”产品化。CLI 侧 6bab08f 增加首次交互式子命令 telemetry consent：采集范围限定为 subcommands/flags 名称、duration/exit state、OS/Python、Web UI feature interactions，不采集用户提供的值/参数，默认 OFF，支持 adk telemetry enable|disable|status。Java ADK 侧 8049f7e 给 ContainerCodeExecutor 加 opt-in strict sandbox：默认仍兼容旧行为但告警；开启后每次执行新建 hardened container，默认无网络、drop all Linux capabilities、no-new-privileges、read-only rootfs、/tmp 64MiB tmpfs、512MiB memory、PIDS 128、60s wall-clock timeout，并声明 ADK 2.0 会默认启用。背景文档（非本周发布）显示 Gemini Enterprise Agent Platform 的 scale 页面已把能力拆成 Agent Runtime、Sessions、Memory Bank、Feedback/Evaluation、Code Execution、Computer Use，并列明 VPC Service Controls/CMEK/Data residency/HIPAA/Access Transparency/Access Approval 的服务覆盖。
  • 关键数据：ADK Python 7 月 28 日至少出现 adk deploy agent_engine --extra_packages、/agent-identity/finalize、telemetry consent 三类提交；ADK Java strict sandbox 默认 512MiB、PIDS 128、60s、/tmp 64MiB；来源 https://github.com/google/adk-python/commit/93db97db338fa72cf5b4fef8125552f30e614b57、https://github.com/google/adk-python/commit/8d2ded3bec122845d06eb7b6ad6ab99723ab8160、https://github.com/google/adk-python/commit/6bab08fc803d26853417c4d6e71704b1a72e035e、https://github.com/google/adk-java/commit/8049f7e5362ca654bf3706ea465f8d1021ee0346（均 2026-07-28）。
  • 原文链接：https://github.com/google/adk-python/commit/93db97db338fa72cf5b4fef8125552f30e614b57；https://github.com/google/adk-python/commit/8d2ded3bec122845d06eb7b6ad6ab99723ab8160；https://github.com/google/adk-python/commit/6bab08fc803d26853417c4d6e71704b1a72e035e；https://github.com/google/adk-java/commit/8049f7e5362ca654bf3706ea465f8d1021ee0346；背景：https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale
  • 影响判断：Google 本周没有大张旗鼓发布新品牌，但代码层动作非常“平台化”：部署打包、用户授权、遥测合规、代码沙箱同时推进。相对 AWS 的 Gateway/Observability 更新，Google 更强调从 ADK 到 Agent Platform 的开发者体验闭环，并通过 Agent Identity 与 strict sandbox 为 Enterprise Agent Platform 补企业安全短板。

Microsoft：Foundry Agent Service

对象：Microsoft Foundry Agent Service

  • 本周动态：本周未发现 Microsoft Learn/Azure Updates 对 Foundry Agent Service 的正式“新功能发布”落在 2026-07-23~07-29；可计入本周观察的是 Semantic Kernel 生态在 7 月 7 日发布后，本周仍作为近两周背景影响 Agent Service 的安全与 tool boundary 走向。近 2 周背景：Microsoft Foundry 文档把 Agent Service 定位为“managed platform for building, deploying, and scaling AI agents”，入口统一到 Responses API，agent 类型分成 Prompt agents（Foundry 托管，无需维护应用代码/compute/container）与 Hosted agents（Agent Framework、LangGraph、OpenAI Agents SDK、Anthropic Agent SDK、GitHub Copilot SDK 或自有代码，容器或 zip 交给 Foundry 运行）。平台组件包括 Responses API、Agent Runtime、Tools（web search、file search、memory、code interpreter、MCP servers、custom functions）、Observability（tracing/metrics/Application Insights）、Identity & Security（Microsoft Entra identity、RBAC、content filters、virtual network isolation）以及 Publishing（Teams、M365 Copilot、Entra Agent Registry）。Code Interpreter 文档虽 ms.date 为 2026-04-03、updated_at 为 7 月 16（非本周），但对商业化很关键：Code Interpreter 除 Azure OpenAI token 费外另计费；并发两个 conversation 会创建两个 sessions；每个 session 默认 active 1 小时、idle timeout 30 分钟。Semantic Kernel 近两周 release 也偏安全治理：python-1.44.0 包含 OpenAPI server URL validation、MCP tool invocation path 上强制 excluded_functions、MCP SSE sample 默认 loopback+host validation、OpenAPI operation path hardening；dotnet-1.78.0 禁用 HttpPlugin/WebFileDownloadPlugin 默认客户端自动 redirect、强化 Core/Document/Web plugins 文件路径校验。这些不是本周 Agent Service GA 新闻，但说明 Microsoft 的 agent runtime 竞争重点已转向“工具调用边界、插件下载/路径安全、MCP 调用约束”。
  • 关键数据：Code Interpreter session 默认 active 1 小时、idle timeout 30 分钟，且并发 conversation 产生多个 session；来源 https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/code-interpreter（updated_at 2026-07-16，背景非本周）。Semantic Kernel python-1.44.0 / dotnet-1.78.0 均 2026-07-07 发布，来源 https://github.com/microsoft/semantic-kernel/releases/tag/python-1.44.0 与 https://github.com/microsoft/semantic-kernel/releases/tag/dotnet-1.78.0（近 2 周背景，非本周）。
  • 原文链接：背景：https://learn.microsoft.com/en-us/azure/foundry/agents/overview；https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/code-interpreter；https://github.com/microsoft/semantic-kernel/releases/tag/python-1.44.0；https://github.com/microsoft/semantic-kernel/releases/tag/dotnet-1.78.0
  • 影响判断：Microsoft 本周相对静默，但其 Agent Service 已形成“Foundry + Responses API + Agent Framework/SK + M365/Copilot 发布渠道”的企业栈。短期看，差异化不在 MCP 版本追新，而在 Entra/RBAC/VNet、Copilot/Teams/Entra Agent Registry 分发和工具安全 hardening；这对已有 Microsoft 365/Azure 客户仍是强绑定优势。

阿里云：百炼 Agent 平台

对象：阿里云 Agent 平台（百炼 Model Studio / DashScope / PAI / 云原生 Agent 托管能力）

  • 本周动态：阿里云百炼本周的公开文档更新集中在“商业化套餐 + 可观测 + 开发者/智能体工具接入”，按官方命名应以“大模型服务平台百炼（Model Studio）”为核心，而不是单独的 Agent Runtime 品牌。7 月 27 日 Token Plan 概述显示，百炼将 AI 编程与智能体工具消费从传统按量 token 进一步包装为 Credits 订阅：个人版 Lite/Standard/Pro 限时价分别 39/139/499 元/月，5 小时限额 700/3,000/12,000 Credits，7 天限额 2,500/10,000/40,000 Credits，并标注“并发 Agent”约 1-2、3-4、6-8 个；团队版 Standard/Pro/Max 限时或标价 150/550/1,398 元/座席/月，月额度 25,000/100,000/250,000 Credits/座席，Extra Bundle 5,000 元/月给 625,000 Credits。文中强调 Token Plan 目前仅华北2（北京），采用 Credits 统一抵扣，可在 Claude Code、Cursor、Qwen Code、Qoder/Qoder CN、OpenClaw 等工具中使用，支持联网搜索、代码解释器等 Harness 工具；团队版支持多席位管理、用量分析，并承诺不使用数据训练模型。7 月 24 日百炼概览同步强调兼容 OpenAI API，分地域 base_url（北京、新加坡、法兰克福、东京、弗吉尼亚）不通用，API Key 不通用，并提供可视化智能体应用（Agent 1.0）、工作流应用、高代码应用（Python 项目部署为后端服务，具备自动化运维、可观测、日志服务）、RAG、插件与 MCP。7 月 28 日模型监控文档强化“agent 运行面”的治理：普通监控自动开启且不可关闭；高级监控可看 RPM/TPM、调用时长、首 Token 延时、失败率、Token 消耗、请求/响应日志，支持北京/新加坡/弗吉尼亚等地域，并能把指标存入私有 Prometheus 实例后接 Grafana。身份/权限上，监控列表按主账号/业务空间隔离，子业务空间成员只能看当前空间；API 统计可按 API Key 过滤，告警可通知钉钉/企业微信/Webhook/短信/邮件/电话。这些更新说明阿里云本周在把“模型平台”向“可订阅的开发者 agent runtime 消费入口”推进，重点不是独立沙箱 runtime，而是用套餐、Harness 工具和监控承接 OpenClaw/编码工具等 agent workload。
  • 关键数据：Token Plan 个人版 39/139/499 元/月、并发 Agent 1-2/3-4/6-8；团队版 150/550/1,398 元/座席/月、25,000/100,000/250,000 Credits/座席/月；高级监控支持 RPM、TPM、TTFT、p50/p99、model_usage 等 Prometheus 指标；来源 https://help.aliyun.com/zh/model-studio/token-plan-overview（2026-07-27）、https://help.aliyun.com/zh/model-studio/model-telemetry（2026-07-28）。
  • 原文链接：https://help.aliyun.com/zh/model-studio/token-plan-overview；https://help.aliyun.com/zh/model-studio/what-is-model-studio；https://help.aliyun.com/zh/model-studio/model-telemetry；https://help.aliyun.com/zh/model-studio/openclaw
  • 影响判断：百炼的路线更像“模型/工具额度运营平台 + 应用构建平台”，用 Token Plan 把 agent 使用从云资源账单转成开发者可理解的订阅制。其短板是缺少 AWS AgentCore/Gemini Agent Platform 那种清晰命名的托管 runtime/Gateway，但在中国市场用 Qwen、低价套餐、钉钉/企业微信告警和 OpenAI 兼容入口，能快速吸引编码代理与轻量智能体流量。

火山/字节：Ark Agent Plan

对象：火山引擎/字节 Agent 平台（火山方舟 Ark + Coze/扣子/Coze Studio/Coze Loop）

  • 本周动态：本周火山引擎公开动态最明确的是火山方舟“订阅 [Agent/Coding Plan]”文档在 7 月 27~29 日连续更新，叠加 7 月 28 日豆包搜索面向企业/开发者上线的媒体报道，显示字节路线从 Coze/扣子低代码搭建，延伸到 Ark 侧“Agent Plan + Harness + 编码/智能体工具”的商业化运行入口。官方 Agent Plan 个人版文档称“方舟 Agent Plan 是面向个人用户推出的订阅式大模型服务套餐包”，新增支持全模态模型及专属 Harness，采用 Agent 燃料值 Agent Fuel Point（AFP）统一计量；兼容 OpenClaw、Hermes Agent、Claude Code、OpenCode 等主流编程及 Agent 工具。套餐分 Small/Medium/Large/Max 四档，40/200/500/1000 元/月，月额度 20,000/100,000/250,000/500,000 AFP，周额度 7,000/35,000/87,500/175,000 AFP，5 小时额度 2,000/10,000/25,000/50,000 AFP；Small/Medium 仅轻量体验，不支持视频生成，Medium 及以上提供图片生成模型配额，Large 及以上提供视频生成模型配额。Harness 列表包含豆包搜索、专业数据集、Agent 记忆（OpenViking）、AI Native 应用开发底座、Agent 进化、ArkClaw 等，其中豆包搜索在表格中标注每月 500 次免费额度；图片/视频模型不受 5 小时/周额度限制，Harness 也无 5 小时/周限制，仅受月额度限制。Claude Code 接入文档（7 月 29 日更新）要求使用专属 ANTHROPIC_BASE_URL=https://ark.cn-beijing.volces.com/api/plan 与 Agent Plan API Key，普通方舟 API Key/Coding Plan Key 不可混用；ArkCLI Helper 可自动配置 Claude Code 并安装 Harness。身份/安全边界上，文档明确文本生成/向量化模型不可用于普通 API 调用，在非 AI 工具使用 Agent Plan Base URL/API Key 可能被识别为滥用并导致订阅停用或账号封禁。豆包搜索方面，官方源未在搜索中稳定返回，但多家媒体 7 月 28 日报道火山引擎上线豆包搜索服务，定位为企业/开发者构建 AI Agent 的跨语言、多模态、多垂类联网信息查询能力，融合全域互联网、行业专业知识和字节独家内容；这与 Ark Agent Plan 的豆包搜索 Harness 形成前台产品与运行套餐的闭环。
  • 关键数据：Agent Plan Small/Medium/Large/Max 为 40/200/500/1000 元/月，月额度 20,000/100,000/250,000/500,000 AFP；豆包搜索 Harness 每月 500 次免费额度；Claude Code 专属 Base URL 为 https://ark.cn-beijing.volces.com/api/plan；来源 https://docs.volcengine.com/docs/82379/2366394?lang=zh（2026-07-27）与 https://docs.volcengine.com/docs/82379/2373740?lang=zh（2026-07-29）。豆包搜索上线报道来源 https://www.jushenhome.com/news_d.php?id=847（2026-07-28，非官方媒体）。
  • 原文链接：https://docs.volcengine.com/docs/82379/2366394?lang=zh；https://docs.volcengine.com/docs/82379/2373740?lang=zh；https://www.jushenhome.com/news_d.php?id=847
  • 影响判断：字节本周的关键不是 Coze Studio 新功能，而是把“agent 工具使用”商品化为 Ark Agent Plan，并用 Harness 把搜索、记忆、数据集、AI Native 开发底座打包给 Claude Code/OpenClaw 等外部 agent。相较阿里 Token Plan，火山更强调 AFP、Harness 与 ArkClaw/豆包搜索生态；但官方 runtime/权限治理描述仍偏套餐与工具接入，企业级隔离、审计与托管 runtime 细节需要继续跟踪。

腾讯云：ADP 与 CodeBuddy

对象：腾讯云 Agent 平台（ADP / CodeBuddy NPC / CloudBase AI Toolkit / TokenHub / 元器）

  • 本周动态：腾讯云本周是 A 组里“有料”最密集的国内云厂之一，但官方/半官方来源分散在腾讯新闻、腾讯云文档和 GitHub。7 月 23 日腾讯云发布云端智能体 CodeBuddy NPC（Cloud Agent）：开发者派发任务后，NPC 可自主完成方案规划、代码开发、提交 PR、执行测试，并根据 CI 结果持续修改，直到交付可验收成果。InfoQ 深度稿披露更完整技术路线：CodeBuddy NPC 将 Git 仓库作为“AI Native Git”原生记忆，直接入驻 Git、Docker、CI/CD、质量门禁，形成“提交→验证→修复→再验证”闭环；支持 Role、SOP、Skill、Team 四个维度定制多角色 NPC 团队（产品、技术 Leader、开发、测试），并与腾讯云 CNB 平台深度集成。成本侧，官方首轮 Token 消耗从 2 万+降到约 2 千，降幅超过 90%；CNB 平台每月服务超过 10 万名开发者，并提供自主可控、数据合规可控的研发协作环境。7 月 24 日腾讯新闻报道 WAIC 2026 上 ADP 4.0 海外版发布，定位 AgentOps 平台，提供智能体构建、分发、治理一站式服务，升级智能工作台、Claw 模式、Skill 广场；企业自然语言描述需求后，智能体可在云端沙箱规划、编写、运行代码，并调用已治理 Skills、连接器、知识库、工作流。ADP 4.0 还实现 Agent 与 Workflow 双向互调，Workflow 全链路可追踪以满足合规审计，并通过 OpenAPI 开放空间、应用、Skill、插件、知识库、文档与会话等模块能力。采用方面，找钢网基于 ADP 搭建十几个“数字员工”，覆盖售前/售中/售后，年交易量约 5000 万吨、年交易额近 2000 亿元；其售前找货报价效率提升约 10~20 倍，并把行业模板对外服务 2000 多家企业；腾讯云副总裁吴运声称 ADP 客户数同比至少翻倍。平台底座上，TokenHub 文档本周更新模型列表、计费和 API Key 管理：Hy3/Hy3 preview 支持结构化输出、Function Calling、Cache，256k 上下文；DeepSeek V4、Kimi K3、GLM-5.2、MiniMax-M3、MiMo 等多模型提供 1M 上下文/Function Calling/Cache；Hy Token Plan 被定义为“面向 Agent 工作负载设计的专属订阅方案”，适配 Coding Agent、文档自动化、多步工具调用。API Key 管理支持每主账号默认 50 个 Key、IP 白名单最多 50 个网段、日/月/总 token 额度限制、限定模型/推理服务访问范围，强调最小权限和轮换。CloudBase GitHub 组织与 CloudBase-AI-Toolkit 也在 7 月 29 日更新，定位为面向 AI Coding 的后端一体化平台，通过 Plugin、Skills、MCP 把数据库、权限、云函数、Cloud Run、日志、部署接入 Claude Code、Codex、CodeBuddy、WorkBuddy、OpenClaw 等工具；v2.25.x（2026-07）提到 CloudRun/Gateway 的 VPC guidance、Domain/Route upstreamResourceType 和 path transmission。
  • 关键数据：CodeBuddy NPC 首轮 Token 消耗从 2 万+降至约 2 千，降低超过 90%；CNB 每月服务超过 10 万开发者；ADP 客户数同比至少翻倍；找钢网年交易量约 5000 万吨、年交易额近 2000 亿元、售前效率提升 10~20 倍、行业模板服务 2000+ 企业；TokenHub API Key 单主账号默认上限 50 个、IP 白名单最多 50 个网段；来源 https://www.infoq.cn/article/w6DHDb3QUYPLC1vaU8z1、https://view.inews.qq.com/a/20260724A0B8DJ00、https://cloud.tencent.com/document/product/1823/130090（2026-07-28）。
  • 原文链接：https://wap.eastmoney.com/a/202607233818864715.html；https://www.infoq.cn/article/w6DHDb3QUYPLC1vaU8z1；https://view.inews.qq.com/a/20260724A0B8DJ00；https://cloud.tencent.com/document/product/1823/130051；https://cloud.tencent.com/document/product/1823/130054；https://cloud.tencent.com/document/product/1823/130090；https://github.com/TencentCloudBase/CloudBase-AI-Toolkit
  • 影响判断：腾讯云本周把 agent 平台叙事从“模型 API + 编码助手”推到 AgentOps：ADP 负责企业智能体构建/治理，CodeBuddy NPC 把研发 agent 嵌入 Git/CI/CD，CloudBase AI Toolkit 则把后端资源以 MCP/Skills 暴露给 AI 编码工具。其竞争优势在企业协同、微信/腾讯文档/ima/乐享/CNB/TAPD 生态和落地案例；但相较 AWS/Google，公开文档里对统一托管 runtime API、跨模型协议版本和 observability 标准化仍不够集中。

云厂平台洞察

本组洞察：本周云厂托管 Agent Runtime 的主线是“从模型调用转向可治理的 agent 工作负载”。AWS 把 AgentCore 的单 agent observability 与 MCP 2026-07-28 多版本 Gateway 补齐，Google 在 ADK 侧补部署打包、Agent Identity 与代码沙箱，腾讯云用 ADP/CodeBuddy NPC 把 AgentOps、云端沙箱、Skill/Workflow 治理与真实研发流程结合；国内阿里、火山则明显用 Token Plan/Agent Plan 把 Claude Code、OpenClaw 等外部 agent 工具的消耗订阅化，并把搜索、代码解释器、记忆、数据集等 Harness 作为套餐卖点。横向看，企业采用的关键门槛已从“有没有强模型”变成五类基础设施：身份/OBO 与 API Key 最小权限、代码/浏览器/云端沙箱隔离、trace/log/Prometheus/CI 可观测闭环、MCP/Skills/Workflow 等工具协议治理、以及可预测的套餐成本。下一阶段值得重点盯三件事：MCP 新协议在各厂 Gateway 的跟进速度；中国云厂 Agent Plan/Token Plan 是否会从个人/编码工具套餐升级到企业级 runtime SLA；以及 ADP/CodeBuddy/CloudBase 这类“agent 嵌入真实工作流”的平台能否沉淀统一开放 API，而不是停留在产品生态内闭环。

协议控制面

模型厂商与框架把工具调用、部署、评测和数据治理变成控制面。

OpenAI：Responses 控制面

对象：OpenAI Responses API + Agents SDK

  • 本周动态：本周 OpenAI 的 agent 控制面有两条实质推进。第一，OpenAI Agents SDK Python 在 7 月 27 日发布 v0.19.0、7 月 29 日发布 v0.19.1。v0.19.0 的 release 原文称这是“significant new OpenAI Responses feature area: Programmatic Tool Calling”，新增 agents.tool.ProgrammaticToolCallingTool，让受支持的 Responses 模型生成 JavaScript 来协调合格工具；它支持 per-tool allowed_callers、结构化 function-tool 输出，并接入 Runner streaming、guardrails、approvals、sessions 与 RunState。同周文档《Programmatic Tool Calling》进一步把边界讲清：应用在 Responses 请求中加入 { "type": "programmatic_tool_calling" }，再在函数、custom、MCP、apply_patch、local/hosted shell、code_interpreter 等工具上设置 allowed_callers: ["programmatic"] 或 ["direct", "programmatic"]；模型生成的程序在隔离 V8 runtime 内运行，不提供 Node.js、包安装、直接网络、通用文件系统、子进程或持久 JS 状态，只能通过请求中允许的工具触达外部系统。返回项也成为控制面契约：program、嵌套 function_call（带 caller.caller_id）、program_output，客户端必须把 caller 原样带回，才能恢复正确 program。第二，Sandbox Agents 文档本周上线/更新，明确 SandboxAgent 是 beta，TypeScript/Python SDK 可用，强调 harness 控制面与 sandbox compute 执行面的分离：harness 拥有 agent loop、model calls、tool routing、handoffs、approvals、tracing、recovery、run state；sandbox 负责文件、命令、包、mount、端口和 snapshot。v0.19.0/0.19.1 的安全和企业化信号很强：日志对 Realtime、RunState、models、tools、MCP、sessions、sandboxes、tracing 做敏感载荷脱敏；v0.19.1 又修复 WebSocket server errors retry、input guardrail 失败时取消 streaming model、BatchTraceProcessor max_batch_size 等。路线判断：OpenAI 正把 Swarm 谱系从轻量多 agent demo，推进到 Responses 原生工具编排 + Agents SDK 托管 loop + sandbox 执行边界三层；这对 LangGraph 等框架形成上游挤压，但仍把审批、客户自有工具和安全边界留给应用层，利于企业集成。
  • 关键数据：openai/openai-agents-python v0.19.0 于 2026-07-27 04:10:05Z 发布，v0.19.1 于 2026-07-29 07:44:24Z 发布；仓库截至抓取时 28,276 stars、4,397 forks、53 open issues，pushed_at 2026-07-29T23:15:48Z。来源：https://api.github.com/repos/openai/openai-agents-python/releases?per_page=10 与 https://api.github.com/repos/openai/openai-agents-python
  • 原文链接：https://github.com/openai/openai-agents-python/releases/tag/v0.19.0；https://github.com/openai/openai-agents-python/releases/tag/v0.19.1；https://developers.openai.com/api/docs/guides/tools-programmatic-tool-calling；https://developers.openai.com/api/docs/guides/agents/sandboxes；https://developers.openai.com/api/docs/guides/agents
  • 影响判断：OpenAI 的控制面重心从“模型调用 API”进一步上移到“可审计的工具执行拓扑”：直接调用、programmatic 调用、SDK loop、sandbox compute 被拆出明确边界。短期会提升复杂工具链的性能和成本效率；长期看，allowed_callers、approval、ZDR、sandbox mounts 会成为企业采购时评价 agent 平台安全性的关键字段。

Anthropic：MCP 与 Agent SDK

对象：Anthropic Claude Agent SDK + MCP

  • 本周动态：本周 Anthropic/MCP 侧最有料的是 MCP 协议与 SDK 进入 2026-07-28 线，并与 Claude Agent SDK 的工具/子任务能力形成闭环。MCP Python SDK 在 7 月 28 日发布 v2.0.0 stable，原文称“supports the 2026-07-28 revision of the Model Context Protocol and serves every earlier revision from the same server”，并说明 pip install mcp 现在安装 2.x。v2 的关键控制面变化包括：2026-07-28 revision 支持无握手的 stateless requests、server/discover、subscriptions/listen、multi-round-trip requests；同一 MCPServer 可同时服务 2025-era 客户端；Client(target) 自动协商版本。旧 FastMCP 名称迁移为 MCPServer，新增 first-class Client；extension APIs、OpenTelemetry 默认开启、协议类型拆为独立 mcp-types；安全侧强化 stdio 与 auth：stdio servers 将 handler subprocess 和 stray prints 挡在 wire 外，stdout serving 时转 stderr；OAuth 增加 RFC 9207 issuer validation、SEP-990 identity assertion flow 与 client-credentials extension。TypeScript SDK 同周 v1.30.0 / @modelcontextprotocol/server@2.0.0 也围绕最终 wire revision 修正：serverInfo 从 DiscoverResult body 移到 result _meta，per-request envelope 的 clientInfo 从 required 降为 SHOULD，并引入 SERVER_INFO_META_KEY。Claude Agent SDK Python 在 7 月 24 日 v0.2.127 修复 query() 在后台任务仍运行时过早关闭 stdin 的 bug；原文点名场景是 run_in_background: true subagents 里的 SDK-MCP tool calls 会因“Stream closed”失败并绕过 PreToolUse hooks。7 月 25 日 v0.2.128 又把 bundled Claude CLI 升至 2.1.220。Anthropic Messages API 的 MCP connector 文档给出了远程 MCP 商业化边界：需要 beta header anthropic-beta: mcp-client-2025-11-20，请求里用 mcp_servers 定义 URL/name/OAuth bearer token，用 tools: [{ type: "mcp_toolset", mcp_server_name }] 配置工具集；支持 allowlist/denylist/per-tool config、多 server；但目前只支持 tool calls，server 必须公开 HTTPS（Streamable HTTP 或 SSE），本地 STDIO 不能直连；可用于 Claude API、Claude Platform on AWS、Microsoft Foundry 的 Hosted on Anthropic deployment，不在 Bedrock/GCP 上提供。路线判断：Anthropic 把 MCP 做成“协议控制面”，把 Claude Agent SDK 做成“本地/CLI 执行控制面”，并通过远程 MCP connector 把企业 SaaS 工具接入 API 层；身份、权限和审计开始从 prompt 约束迁到 URL、OAuth、toolset allowlist、PreToolUse hooks 和 OpenTelemetry。
  • 关键数据：MCP Python SDK v2.0.0 于 2026-07-28 13:41:36Z 发布；TypeScript SDK 1.30.0 于 2026-07-27 17:54:36Z 发布；Claude Agent SDK Python v0.2.127 于 2026-07-24 17:27:47Z、v0.2.128 于 2026-07-25 01:49:41Z 发布；anthropics/claude-agent-sdk-python 截至抓取时 7,758 stars、1,191 forks、392 open issues。来源：https://api.github.com/repos/modelcontextprotocol/python-sdk/releases?per_page=10；https://api.github.com/repos/modelcontextprotocol/typescript-sdk/releases?per_page=10；https://api.github.com/repos/anthropics/claude-agent-sdk-python/releases?per_page=10；https://api.github.com/search/repositories?q=org:anthropics+agent+sdk
  • 原文链接：https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.0.0；https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/1.30.0；https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/%40modelcontextprotocol/server%402.0.0；https://github.com/anthropics/claude-agent-sdk-python/releases/tag/v0.2.127；https://github.com/anthropics/claude-agent-sdk-python/releases/tag/v0.2.128；https://platform.claude.com/docs/en/agents-and-tools/mcp-connector
  • 影响判断：MCP 的 2026-07-28 revision 将“连接握手/发现/订阅/多轮请求”标准化，降低了各家 agent runtime 与企业工具之间的适配成本。Claude Agent SDK 的 stdin/background-task 修复虽小，但直接关系到子 agent、MCP tool call、PreToolUse hook 的权限边界，说明 Anthropic 正在把开发者体验和治理链路一起补齐。

LangChain：部署与评测

对象：LangChain / LangGraph / LangSmith Deployment

  • 本周动态：本周 LangChain 生态有明确产品化动态，重点是把 agent harness、部署和评测观测串成“框架无关控制面”。7 月 28 日 LangGraph 发布 1.2.10，release 内容包括 stream_events v3 返回类型与 native projections、add_node 暴露 trace_policy、CLI 允许 langgraph-api 版本到 1.0.0 等；虽然变更不如大版本激进，但说明 LangGraph 核心在继续围绕 streaming、trace 与部署 API 对齐。更重要的是，LangSmith Deployment 文档本周被搜索/抓取为最新页面，明确其定位为“workflow orchestration runtime purpose-built for agent workloads”，支持 durable execution、real-time streaming、horizontal scaling，并强调可部署 LangGraph/LangChain、Google ADK，以及通过 Functional API 或 deployments-wrap-sdk 部署 Claude Agent SDK、Strands、CrewAI、AutoGen 等其他框架。部署形态分为 Cloud（LangChain 在 AWS/GCP 全托管，需 Plus plan 或以上）、Self-hosted with control plane（企业计划、Kubernetes）、Hybrid（LangChain 托管控制面，Agent Servers/data plane 在客户基础设施）、Standalone Agent Server（Docker/Compose/Kubernetes，自带 PostgreSQL、Redis、LangSmith license，无控制面）。这把 LangGraph Platform 从“图编排库”提升为跨框架 agent runtime。7 月 29 日 Deep Agents v0.7 发布则从 harness 侧降本：base input tokens 从约 6k 降到约 2k，减少 65%；具体做法是移除隐藏 base system prompt、内置 tool descriptions 缩短 43%、TodoListMiddleware 默认移除改为 opt-in。其评测矩阵覆盖 autonomous/conversational/long-context 三类，四个模型 gpt-5.6-luna、gemini-3.6-flash、claude-sonnet-4-6、claude-opus-4-8；文中称 reward 总体稳定，gpt-5.6-luna tokens 降 34%、cost 降 15%、reward 升 4%。这反映 LangChain 对“上下文工程/控制面提示词”的判断：新模型更依赖清晰工具 schema 与 middleware，而不是厚重通用 prompt。LangSmith 侧，本周 Similarweb 案例把长报告 agent 评估方法落地：deterministic checks 校验是否调用/避免工具、结构化输出是否有效；LLM-as-judge 负责语义质量；长报告用 rubric、faithfulness checks 与 A/B baseline，而每个评分列都能回链 trace。横向看，LangChain 继续把可观测、评估、部署、memory 和安全沙箱商品化：Newsletter 提到 LangSmith Sandboxes free trial、Fleet Slack 一键接入、voice-agent tracing；Memory 文档强调 short-term thread checkpoints 与 long-term namespace stores，为跨 session agent 提供状态层。
  • 关键数据：LangGraph 1.2.10 于 2026-07-28 18:34:14Z 发布；langchain-ai/langgraph 截至抓取时 38,443 stars、6,476 forks、650 open issues，pushed_at 2026-07-28T18:34:13Z；Deep Agents v0.7 报告 base input tokens 约 6k→约 2k、下降 65%，tool descriptions 缩短 43%，gpt-5.6-luna tokens 下降 34%、cost 下降 15%、reward 上升 4%。来源：https://api.github.com/repos/langchain-ai/langgraph/releases?per_page=10；https://api.github.com/repos/langchain-ai/langgraph；https://www.langchain.com/blog/deep-agents-v0-7
  • 原文链接：https://github.com/langchain-ai/langgraph/releases/tag/1.2.10；https://docs.langchain.com/langsmith/deployment.md；https://docs.langchain.com/langsmith/observability.md；https://docs.langchain.com/oss/python/concepts/memory.md；https://www.langchain.com/blog/deep-agents-v0-7；https://www.langchain.com/blog/how-similarweb-evaluates-long-form-agent-research-reports-with-langsmith；https://www.langchain.com/blog/july-2026-langchain-newsletter
  • 影响判断：LangChain 的竞争策略不是和 OpenAI/Anthropic 争单一模型原生 SDK，而是做跨框架部署、观测、评估和 memory 的中立控制面。Deep Agents v0.7 的“删 prompt、强 schema/middleware”会成为 agent harness 的降本样板；LangSmith Deployment 的 hybrid/self-hosted/standalone 形态则直接对准企业数据驻留和平台团队治理需求。

Databricks：数据治理 Agent

对象：Databricks Mosaic AI Agent Framework / Agent Bricks

  • 本周动态：本周 Databricks Agent/Agent Bricks 的公开动态集中在行业落地和 Unity Catalog 治理化控制面，而不是 GitHub SDK release（GitHub 搜索 org:databricks + mosaic/agent 未找到直接对应本周 release；相关公开代码以 industry solution 形式出现）。7 月 29 日 Databricks 发布《Agents for production lines: Trusted decisions in real time》，推出/展示 ProdLine CoPilot：一个基于 Databricks Data Intelligence Platform 的复合 AI 系统，面向 CPG 包装线实时决策。文章给出具体技术路线：PLC/SCADA 通过 Zerobus Ingest 以 gRPC/REST 推入 Unity Catalog Delta tables，配合 Lakeflow Spark Declarative Pipelines 形成 Bronze/Silver/Gold；MES/ERP/LIMS 以镜像、batch 或 CDC 低频进入同一 governed catalog；同一表再供 SQL、Genie、AI Search、Model Serving 和 agents 使用。agent 架构上，orchestrator 先从 Unity Catalog 加载 machines/events/schedule/inventory/quality/constraints 的当前状态，再把意图路由给专家 roster，而不是一个大 agent。专家包括 Downtime Analyst、Quality Specialist、Supply Chain Advisor、OEE Coach、Schedule Optimizer、Maintenance Predictor、Strategic Advisor、Shift Briefing。工具层也很具体：SQL Query/Genie Space 做 governed reads，Calculator 用 Python/NumPy/Pandas 运行 OEE、recovery、depletion math，Anomaly Detector 用 Z-score/IQR，Plan & Constraints 保存速度、CIP、changeover、overtime policy，Similar Cases 从 Databricks AI Search 检索历史事件；Schedule Recovery 用 MILP（OR-Tools SCIP），Stochastic Schedule 用 SAA + scenarios，Production Forecast 用 Monte Carlo（文中例子 1,000 paths）。安全边界上，文章反复强调 human-in-the-loop：line manager 批准 recovery，Quality 批准 hold/release，Maintenance 批准 work scope/timing，CMMS/QMS/LIMS/MES/APS 写回都设计为 draft 而非自动控制。对应 GitHub 仓库 production-line-copilot 也已 web_fetch，README 显示它是 Apache-2.0、Databricks Asset Bundle，包含 19-machine 实时仿真、8 specialist agents、Zerobus、Unity Catalog、Lakebase serving、Node/Express + React app、默认 databricks-gpt-5-mini + databricks-gpt-5 endpoints。 平台层文档也在本周相关抓取中体现 Agent Bricks 的控制面扩展：Databricks “Use agents” 页面列出 AI Playground、Knowledge Assistant、Supervisor Agent、custom agents、agent tools、MCP、Agent Services、MLflow Tracing、Agent Evaluation/monitoring。Supervisor Agent 文档说明它可协调 Genie Agents、agent endpoints、Unity Catalog functions、MCP servers、custom agents，且内置访问控制，终端用户只能访问其对每个 subagent/数据已有权限的内容；web search 使用 databricks-gpt-5 Foundation Model API，并且每次公共 web search 前都提示用户批准。Agent Services（Beta）则把外部 agents 注册为 Unity Catalog securable：可在 Catalog Explorer 中发现，权限沿用 UC grants，创建需 USE CATALOG/USE SCHEMA/CREATE SERVICE/USE CONNECTION，运行期调用暂不可用但注册和权限管理已可用；可授予 EXECUTE、READ_METADATA、MANAGE、ALL_PRIVILEGES。MCP 文档进一步把 Unity AI Gateway 定为 enterprise control plane：MCP servers 和 LLM endpoints 的访问、credential management、activity monitoring 统一治理；managed MCP servers 包括 Genie、AI Search、Databricks SQL、Unity Catalog functions，外部 MCP 通过 Unity Catalog connections + managed OAuth 处理凭据。
  • 关键数据：生产线案例给出 15–20 machines、world-class OEE 约 85%、许多工厂 low-to-mid 70s、500 cases/hour、24/5、€10 contribution/case 时 1 个 OEE 点约 €300K/年，Schedule Optimizer 示例测试 1,000 scheduling scenarios；production-line-copilot README 显示 19-machine simulation、8 specialist agents、~1s SSE playback、默认 databricks-gpt-5-mini + databricks-gpt-5。来源：https://www.databricks.com/blog/agents-production-lines-trusted-decisions-real-time；https://github.com/databricks-industry-solutions/production-line-copilot
  • 原文链接：https://www.databricks.com/blog/agents-production-lines-trusted-decisions-real-time；https://github.com/databricks-industry-solutions/production-line-copilot；https://docs.databricks.com/aws/en/agents/custom-agents/build-agents；https://docs.databricks.com/aws/en/agents/agent-bricks/multi-agent-supervisor；https://docs.databricks.com/aws/en/ai-gateway/agent-services；https://docs.databricks.com/aws/en/agents/mcp/；https://docs.databricks.com/aws/en/agents/custom-agents/agent-tool
  • 影响判断：Databricks 的 agent 战略明显偏“数据/治理原生”：把 agents 当 Unity Catalog、AI Gateway、MLflow、Model Serving、Delta/Lakebase 的新工作负载，而非单独聊天产品。其优势在企业数据权限、血缘、审计、评估和 HITL 写回；挑战是开发者生态与轻量体验不如 OpenAI/Anthropic/LangChain，但在制造、金融、电信等已有 lakehouse 客户中，可信数据闭环会是强卖点。

协议控制面洞察

本组洞察：本周协议/控制面趋势非常清晰：模型厂商和框架都在把“agent 能做什么”拆成可治理的执行边界。OpenAI 用 allowed_callers、program/program_output、sandbox harness/compute 分离来约束工具调用；Anthropic/MCP 用 2026-07-28 revision、remote MCP connector、OAuth 与 SDK hook 修复来标准化工具接入；LangChain 用 LangSmith Deployment/Observability/Evals/Memory 做跨框架 runtime；Databricks 则把 MCP、Agent Services、Supervisor、MLflow 与 Unity Catalog 统一到企业数据治理平面。竞争焦点正在从“谁的模型更会调用工具”转向“谁能证明工具、身份、数据、审批、成本和评估都在同一个可审计控制面里”。

执行环境

执行环境层开始把会话、沙箱、浏览器、GPU 和代码运行解耦。

OpenClaw：Agent OS

对象：OpenClaw

  • 本周动态：本周有重大公开动态。GitHub Release API 显示 v2026.7.2-beta.5 于 2026-07-28T03:23:12Z 发布（北京时间 7月28日 11:23），这是典型 Agent OS / Gateway 层面的密集迭代，而非单点应用功能。发布说明把重点放在“状态安全与恢复、通道持久投递、会话回退/分叉、交互式 MCP Apps、结构化问题与审批、会议与实时 Talk、本地推理与引导设置”。其中基础设施信号最强的是：持久数据引入“quarantine store”、crash-recoverable SQLite snapshots、crash-durable filesystem publication、schema-upgrade data-loss rejection、rollback-writer snapshot recovery；通道入口改为 shared ingress drain 与 dead-letter recovery，覆盖 Telegram、Signal、Slack、QQBot、Twitch、Synology Chat、Tlon、IRC、Zalo User；sessions 支持从单条消息 rewind/fork、跨 Web/native 分支切换、Codex upstream session fork、branch-safe queued sends 与 stale-pane write rejection。README 同期强调 Gateway 是“single control plane for sessions, channels, tools, and events”，默认 host tools，但群组/非主会话可配置 agents.defaults.sandbox.mode: "non-main"，Docker 为默认 sandbox backend，SSH/OpenShell 也可用；默认 sandbox 通常允许 bash/process/read/write/edit/session tools，拒绝 browser/canvas/nodes/cron/gateway/channel actions。安全边界上，本周修复还包括 forged-marker/web-search boundary bypass、非 owner ACP session 暴露、unsafe explicit approval IDs、secret redaction 与 exec/OAuth approval hardening。GitHub API 截至抓取时显示仓库 384,505 stars、80,815 forks、pushed_at 2026-07-30T02:04:43Z，说明其本周仍在高频推进。路线判断：OpenClaw 正把“个人助理”底层做成可靠的本地优先 Agent OS，核心竞争点不是模型调用，而是可恢复会话、跨通道入口、审批/权限与工具运行时的系统性治理。
  • 关键数据：v2026.7.2-beta.5，2026-07-28T03:23:12Z 发布；Release note 声称本轮 audited record 覆盖 3,908 merged PRs；GitHub 384,505 stars / 80,815 forks（来源：https://api.github.com/repos/openclaw/openclaw/releases?per_page=5 与 https://api.github.com/repos/openclaw/openclaw ，抓取 2026-07-30）。
  • 原文链接：https://github.com/openclaw/openclaw/releases/tag/v2026.7.2-beta.5 ；https://github.com/openclaw/openclaw ；https://api.github.com/repos/openclaw/openclaw/releases?per_page=5 ；https://api.github.com/repos/openclaw/openclaw
  • 影响判断：OpenClaw 的本周变化把 Agent OS 的评价指标从“能否调用工具”推进到“崩溃、升级、分支、审批、通道重放是否可恢复”。如果这些能力稳定，开源 Agent runtime 会更接近个人/团队常驻基础设施，而不是一次性 CLI agent。竞争上，它会与云端 sandbox/runtime 形成互补：OpenClaw 管控入口、权限和会话；E2B/Modal/Daytona/Browserbase 负责隔离执行面。

E2B：代码沙箱

对象：E2B

  • 本周动态：本周有明确 SDK/CLI 发布。GitHub Release API 显示 2026-07-24 发布 e2b@2.36.0 与 @e2b/python-sdk@2.35.0，2026-07-27 发布 e2b@2.36.1 与 @e2b/cli@2.16.0。技术上，2.36.0 的关键变化是把 sandbox filesystem 类型补齐到 symlink：新增 FileType.SYMLINK / 'symlink'，并在 JS、Python sync/async 中返回 symlinkTarget / symlink_target，解决 envd 新版本将符号链接报告为 FILE_TYPE_SYMLINK 后 SDK 过去 list/getInfo 识别不足的问题。同期 API client 从最新 specs 再生成，提到 SandboxNetworkConfig、SandboxIam workload-identity models、SandboxTimeoutRequest/SandboxSnapshotRequest/SandboxRefreshRequest 等命名 schema，并明确 access-token auth 被标记为 deprecated、API keys 成为推荐路径；还升级 tar 到 7.5.19 以覆盖 node-tar DoS advisory。Python SDK 2.35.0 更偏运行时传输层：sandbox RPC（commands、PTY、filesystem watch）从 vendored e2b_connect 迁到官方 Connect RPC client connectrpc，HTTP transport 为 Rust reqwest/hyper 的 pyqwest，protobuf runtime 改为 Buf protobuf-py，提前关闭 command/watch stream 会发送 RST_STREAM，降低 abandoned stream 泄漏。7月27日的 2.36.1 和 CLI 2.16.0 是安装与兼容性打磨：glob 从 11 升到 13，npm install e2b 包数从 37 降到 26；CLI 清掉 deprecated glob@10 警告，npm install @e2b/cli 从 183 降到 145 packages，同时 Node 22 floor 从 >=22 调整为 >=22.9.0（Node 20 仍 >=20.18.1 <21）。README 原文定位 E2B 为“run AI-generated code in secure isolated sandboxes in the cloud”，并提供 JS/Python Sandbox.create()、sandbox.commands.run() 与 Code Interpreter SDK runCode()，self-hosting 支持 AWS/GCP（Azure/Linux machine 列为未绿灯）。
  • 关键数据：e2b@2.36.0 2026-07-24T14:45:46Z；@e2b/python-sdk@2.35.0 2026-07-24T14:45:49Z；e2b@2.36.1 2026-07-27T13:35:42Z；@e2b/cli@2.16.0 2026-07-27T13:35:45Z；GitHub 13,186 stars / 978 forks（来源：https://api.github.com/repos/e2b-dev/E2B/releases?per_page=5 与 https://api.github.com/repos/e2b-dev/E2B ，抓取 2026-07-30）。
  • 原文链接：https://github.com/e2b-dev/E2B/releases/tag/e2b%402.36.1 ；https://github.com/e2b-dev/E2B/releases/tag/e2b%402.36.0 ；https://github.com/e2b-dev/E2B ；https://api.github.com/repos/e2b-dev/E2B/releases?per_page=5
  • 影响判断：E2B 本周不是大规模产品发布，而是把 sandbox runtime 的“真实文件系统、RPC 生命周期、API 身份模型、安装体积/Node 兼容”补齐，这些都是 agent computer 从 demo 走向生产的必要基础。SandboxIam/workload identity 与弃用 access-token auth 的信号尤其值得关注，说明代码解释器沙箱正在从单 API key 走向更细粒度的身份边界。相较 Modal 的通用 serverless 容器和 Daytona 的 workspace computer，E2B 更聚焦 AI-generated code execution 的 SDK 体验与 envd 控制面。

Modal：GPU 与 Sandbox

对象：Modal

  • 本周动态：本周有产品/生态动态。Modal 7月27日发布《Kimi K3 by Moonshot now available on Modal》，宣布 Moonshot Kimi K3 在发布日即上 Modal。原文给出的技术/商业信息很具体：Kimi K3 是 2.8T 参数多模态 MoE，896 个专家中每 token 激活 16 个，1M token context window，native vision；Modal 与 Moonshot、vLLM 做 day-zero support，在 Shared API 上采用 token-based pricing，也可作为 Auto Endpoint 获取 dedicated capacity，并配套针对 K3 架构定制训练的 DFlash speculative decoder。性能数据为“从 100 到 460 tokens/s，交互性快 360%”；吞吐“从 800k 到 1.5 million TPM per GPU，高 88%”；DFlash 训练最终使用 32 个 B300 nodes，其中 28 个以 TP8 跑 K3 生成 hidden states，4 个训练 draft model。虽然这条新闻中心是模型托管，但对 Agent 执行环境的意义在于：Modal 正把 serverless GPU、OpenAI-compatible Shared API、dedicated Auto Endpoint 与 speculative decoding 组合为长上下文 agentic workloads 的推理执行面。另一个本周/近期待验证的原始材料是 Modal docs 的 Sandboxes 与 OpenCode 示例：Modal 明确把 Sandbox 定义为“secure containers for executing untrusted user or agent code”，modal.Sandbox.create 可在 Python/JS/Go 中运行任意命令，默认最大 lifetime 5 分钟，可设置到 24 小时；readiness probe 支持 TCP/Exec，lifecycle events 包括 Created、Scheduled、Started、Ready、Finished；OpenCode 示例把 coding agent 放进 Modal Sandbox，开放 encrypted_ports=[4096]，用 modal.Secret 保存 OPENCODE_SERVER_PASSWORD，可通过 modal shell {sandbox.object_id} 进入调试，也可把 GitHub PAT 和 Modal credentials 注入到隔离环境。GitHub modal-labs/modal-client 本周 pushed_at 为 2026-07-29T21:17:07Z，README 还强调 JS/Go SDK 可用 Modal Sandboxes、invoke deployed Modal Functions，并提供官方 modal skills install 给 coding agents 使用。
  • 关键数据：Kimi K3：2.8T 参数、1M context、460 tokens/s、1.5M TPM/GPU、32 B300 nodes 训练 DFlash；Modal GitHub 495 stars / 110 forks，pushed_at 2026-07-29T21:17:07Z（来源：https://modal.com/blog/kimi-k3-by-moonshot-now-available-on-modal 与 https://api.github.com/repos/modal-labs/modal-client ，日期 2026-07-27/抓取 2026-07-30）。
  • 原文链接：https://modal.com/blog/kimi-k3-by-moonshot-now-available-on-modal ；https://modal.com/docs/guide/sandboxes ；https://modal.com/docs/examples/opencode_server ；https://github.com/modal-labs/modal-client ；https://api.github.com/repos/modal-labs/modal-client
  • 影响判断：Modal 正从“跑函数/跑 GPU”扩成“agent workloads 的通用执行平面”：一边是长上下文模型推理和 spec decoding，另一边是可运行不可信代码的 sandbox 与长期任务。它的优势是通用云基础设施和 GPU 供给，不是专门的 agent OS；因此会与 OpenClaw 这类控制面、E2B/Daytona 这类 agent sandbox 形成生态竞合。

Daytona：Composable Computer

对象：Daytona

  • 本周动态：本周无重大公开发布；但近两周/近月背景非常关键且需列为执行环境格局变化。GitHub README 原文在仓库顶部声明：“As of June 2026, Daytona’s core development has moved to a private codebase. This repository will receive no further updates, fixes, or releases.” 这意味着开源 daytonaio/daytona 在本周虽有 pushed_at 2026-07-24T07:12:07Z 和 GitHub API 活动，但公开主线已不是产品真实核心开发位置，后续研究应转向 docs、私有云服务与新组织 github.com/daytona。同时，公开文档显示 Daytona 的平台定位已从传统云开发环境转为 AI-generated code / agent workflow runtime：文档首页称其提供 “full composable computers — sandboxes — for AI agents”，每个 sandbox 有 dedicated kernel、filesystem、network stack、allocated vCPU/RAM/disk，启动“under 90ms”，支持 SDK/API/CLI 管理 lifecycle、filesystem、process/code execution、runtime configuration、stateful environment snapshots。Sandboxes 页给出具体资源与安全边界：默认 container sandbox 为 Linux container；也提供 VM sandboxes（dedicated Linux VM 或 Windows OS）和 GPU sandboxes（NVIDIA H100、H200、RTX Pro 6000、RTX 4090、RTX 5090）。默认资源 1 vCPU/1GB RAM/3GiB disk，组织最大 4 vCPU/8GB RAM/10GB disk；GPU sandbox ephemeral，最高 16 vCPU/192GB RAM/512GB disk。默认 snapshots 包括 daytona-small、daytona-medium、daytona-large、daytona-gpu、daytona-vm-small/medium/large、windows-small/medium/large，并支持 language="python"|"typescript"|"javascript" 直接 code_run。区域方面，公共 managed region 只有 us 和 eu；Dedicated regions 由 Daytona 管理但独占给组织；Custom regions 通过 BYOC 接入自有机器，容量只受接入 compute 限制。MCP 文档显示 Daytona MCP Server 可接 Claude、Cursor、Windsurf，工具覆盖 sandbox management、file system、git、process/code execution、computer use、preview。身份/权限上，API key、组织 limits、regions/BYOC、MCP config 与 sandbox 隔离构成主要边界。
  • 关键数据：公开开源仓库最新 release v0.190.0 发布于 2026-06-23（背景，非本周）；GitHub 72,100 stars / 5,653 forks，pushed_at 2026-07-24T07:12:07Z；文档称 sandbox 启动 under 90ms，公共 region 为 us/eu，GPU sandbox 最高 16 vCPU/192GB RAM/512GB disk（来源：https://github.com/daytonaio/daytona 、https://api.github.com/repos/daytonaio/daytona 、https://www.daytona.io/docs/sandboxes/ ，抓取 2026-07-30）。
  • 原文链接：https://github.com/daytonaio/daytona ；https://api.github.com/repos/daytonaio/daytona ；https://www.daytona.io/docs ；https://www.daytona.io/docs/sandboxes/ ；https://www.daytona.io/docs/regions/ ；https://www.daytona.io/docs/mcp/
  • 影响判断：Daytona 的公开开源降频/私有化迁移削弱了“开源 Agent runtime”属性，但其产品叙事已非常清晰地押注 composable computer：container/VM/Windows/GPU、snapshots、MCP、BYOC region。对企业 agent 执行面而言，Daytona 更像“可持久 workspace computer”，区别于 E2B 的代码解释器优先、Modal 的 serverless GPU/函数优先。风险是公开可验证 roadmap 变少，商业信任更多依赖服务文档与客户证明。

Browserbase：浏览器 Runtime

对象：Browserbase

  • 本周动态：本周无重大公开动态。近两周背景（非本周）是 Browserbase 7月22日发布《Code mode is all you need》，把 browser agent runtime 的接口范式明确从“更多工具 schema”转向“在安全执行环境里让模型写普通代码”。原文 TL;DR 称，对大量 agent task，“best tool is a small code-execution surface”，让模型针对 typed capabilities 写代码，并把安全 enforcement 放到模型之下，而不是为每个动作包一层 bespoke tool call。文章以 browser agent 为例指出，DOM、Browser APIs、page.evaluate() 已是天然可编程接口，agent 不必依赖通用 extract_product_cards 之类工具，而可写页面特定 JavaScript 提取/交互；但也承认 visual interfaces、canvas、cross-origin frames、downloads、native permission prompts 等仍需要 specialized primitives。安全边界部分很关键：sandbox 只是起点，必须 broker credentials、在 proxy 层 enforce capabilities、scope underlying identity、control egress、separate reads from writes、preserve traces、design for retries。结合 Browserbase docs，本周可观察到的产品底座包括：平台口径为 cloud browsers、web search、page fetching、sandbox runtime 和 major LLMs “one API key”；Runtime 可按 schedule 或 on demand 跑 browser agents；Stagehand v3 quickstart 通过 npx create-browser-app 创建项目，new Stagehand({ env: "BROWSERBASE" }) 后暴露 act、extract、observe、agent，示例中可实时查看 https://browserbase.com/sessions/${stagehand.browserbaseSessionID}；session metadata 使用 userMetadata，JSON 字符串化后需低于 512 字符，可用 List Sessions API 的 q=user_metadata['env']:'staging' 检索；Identity/Verified 页面强调 Scale plan 上的 purpose-built Chromium 与 real fingerprints、Cloudflare Signed Agents/Web Bot Auth、CAPTCHA solving、proxies、1Password credentials。GitHub browserbase/stagehand README 定位为 “The SDK For Browser Agents”，支持自然语言与代码混合、auto-caching/self-healing，并提供 act()、agent().execute()、extract()；GitHub API 抓取显示 23,673 stars / 1,630 forks，pushed_at 2026-07-30T01:55:00Z。整体判断：Browserbase 的核心不只是云浏览器，而是在把浏览器、身份、回放/观测、代码执行和 Stagehand 抽象组合成浏览器 Agent runtime。
  • 关键数据：本周公开重大动态 —；背景（非本周）：《Code mode is all you need》页面 HTML 标注 dateTime=2026-07-22；Stagehand GitHub 23,673 stars / 1,630 forks，pushed_at 2026-07-30T01:55:00Z；Browserbase docs 标注 Stagehand 22k GitHub stars、700k+ weekly downloads；session metadata 限制 512 characters（来源：https://www.browserbase.com/blog/code-mode-is-all-you-need 、https://api.github.com/repos/browserbase/stagehand 、https://docs.browserbase.com/introduction 、https://docs.browserbase.com/features/sessions ，抓取 2026-07-30）。
  • 原文链接：https://www.browserbase.com/blog/code-mode-is-all-you-need ；https://github.com/browserbase/stagehand ；https://docs.browserbase.com/introduction ；https://docs.browserbase.com/features/sessions ；https://docs.browserbase.com/features/stealth-mode ；https://docs.stagehand.dev/v3/first-steps/quickstart
  • 影响判断：Browserbase 的路线正在把“浏览器即工具”升级为“浏览器 + code mode + identity policy”的执行环境，特别适合网页没有稳定 API、但 DOM/页面运行时可编程的场景。它与 E2B/Daytona 的通用代码沙箱不同，竞争壁垒在云浏览器会话、反机器人/授权身份、session observability 与 Stagehand 的生产化缓存/自愈。短期内，合规身份（Verified/Web Bot Auth）会比单纯 stealth 更重要。

执行环境洞察

本组洞察：本周执行环境层的主线是“控制面与执行面解耦、并在执行面下沉安全策略”。OpenClaw 代表本地优先 Agent OS：会话、通道、审批、cron、插件与工具 runtime 需要持久化、可回放、可分叉、可恢复；E2B/Daytona 代表代码/工作区 sandbox：文件系统类型、RPC 生命周期、workload identity、snapshots、VM/GPU/BYOC 决定 agent 能否安全跑真实任务；Modal 代表 serverless GPU/容器执行和长上下文推理供给；Browserbase 代表浏览器执行面，正在从“点击工具”走向“页面内 code mode + 身份/代理/回放”。共同趋势是：模型面对更少、更通用的 typed/code interface，权限、凭证、网络、审计、重试和审批被放到 runtime/proxy/OS 层强制执行。下一阶段基础设施竞争不只是启动速度或价格，而是谁能同时提供可观测执行、细粒度身份、崩溃恢复、可复用技能/脚本，以及对高后果写操作的可靠治理。

记忆与知识

Memory 层从简单召回走向来源、权限、时间和可删除性。

Firecrawl：外部知识获取

对象：Firecrawl

  • 本周动态：本周有两条值得记录的公开动态。其一，Firecrawl 在 2026-07-29 前后更新了面向 Agent 的网页搜索 MCP 叙事，官方博客把 Firecrawl MCP 定位为“Search, Scrape, Crawl, Map, Interact in a single API”，并列出 firecrawl_search、firecrawl_scrape、firecrawl_map、firecrawl_crawl / firecrawl_check_crawl_status、firecrawl_agent / firecrawl_agent_status、firecrawl_interact、firecrawl_browser_create/execute/delete/list 等工具面；原文强调 MCP 服务器覆盖“search, scraping, crawling, browser automation, and an autonomous research agent in a single install”，这说明 Firecrawl 正从单点抓取 API 继续向 Agent 外部知识获取“上下文层”扩展。博客还引用 SimpleQA 内部评测：GPT-5.4 agent 使用 Firecrawl /search + web_fetch 得分 94.7%，并称新的相关性模型只返回回答问题所需的页面 excerpt，Token 约减少 10x。其二，7-29 GitHub commit fccab9d 增加 feat(api): proxy /labs/search to the labs service (#4165)，提交说明该 pass-through router 会认证调用者、通过 team flag gate，并转发到 LABS_SEARCH_URL；不在该层检查/扣减 credits，而由下游服务用调用者 key 走既有公开 endpoint 计费。这体现了 Firecrawl 在 search labs / experimental routing 上把身份、团队开关和计费路径拆开。补充背景：最近正式 release v2.11.0（6-19，非本周）已加入 /v2/search/research、redactPII、deterministicJson、cdpUrl、keyless core endpoints、WWW-Authenticate: Bearer realm="firecrawl"、searchZDR 等，安全边界从“能抓”提升到“抓取前后能做 PII、ZDR、Bearer discovery、monitor recipient confirmation”。
  • 关键数据：GitHub firecrawl/firecrawl 约 157,929 stars、pushed_at 2026-07-30T00:40:49Z；v2.11.0（2026-06-19，背景）列出 Firecrawl Research Index 覆盖 3M+ arXiv papers，并称 arXivQA recall 相比下一名高 18%；官方博客称 SimpleQA 得分 94.7%、token 约少 10x。来源：https://api.github.com/repos/firecrawl/firecrawl ，https://api.github.com/repos/firecrawl/firecrawl/releases?per_page=10 ，https://www.firecrawl.dev/blog/best-web-search-mcp
  • 原文链接：https://www.firecrawl.dev/blog/best-web-search-mcp ；https://www.firecrawl.dev/blog/claude-code-web-research-tokens ；https://api.github.com/repos/firecrawl/firecrawl/commits?since=2026-07-22T16:00:00Z&until=2026-07-29T16:00:00Z&per_page=10
  • 影响判断：Firecrawl 的核心竞争点不是“又一个 search API”，而是把检索、抽取、爬取、浏览器执行和研究循环包装为 Agent 可连续调用的上下文基础设施。7-29 的 labs/search proxy 显示其在做更细的团队级实验开关和计费隔离；结合 PII redaction、ZDR、Bearer discoverability，企业落地会更关注合规可控的外部知识摄取，而非单纯爬取成功率。

Mem0：通用记忆层

对象：Mem0

  • 本周动态：Mem0 本周公开动态非常密集，核心集中在 SDK release、向量后端兼容性、身份字段边界和生态集成。2026-07-25 发布 Python SDK v2.0.14 与 Node SDK v3.1.2。Python 版新增 Oracle AI Vector Search provider（oracledb），支持 connection pooling、HNSW / IVF index、JSON metadata filtering 和 6 种 distance metrics；这把 Mem0 的 memory layer 后端从常见 Qdrant/Milvus/Pinecone/OpenSearch 进一步推进到 Oracle 企业数据库场景。Node v3.1.2 与 Python v2.0.14 同步修了多类 vector store filter 语义问题：Cassandra compound field filter 不再只应用第一个 operator；Chroma where-clause 不再丢同字段范围、多字段 $or、$not 下 contains/icontains；Milvus 对 "*" wildcard filter 不再 literal match；OpenSearch "*" 会转 exists query；Milvus/OpenSearch/MongoDB 的 BM25 keyword search 改读 textLemmatized。这些看似是 bugfix，实质是 Memory API 多租户过滤和 hybrid retrieval 的正确性基础。更重要的是 v2.0.13（UTC 7-22 19:41，对上海时间为 7-23 凌晨，属本周窗口）明确修复 update() metadata 覆盖或注入 user_id、agent_id、run_id、actor_id 的问题，称这些 identity fields 创建后不可变，避免 memory 被移动到另一个 tenant scope；同版还将 Pinecone delete_col()/reset() 限定到 configured namespace，避免 reset 一个 namespaced store 时擦掉共享 index 的其他 namespace。7-29 commit e168d48 增加 “Zapier app for Mem0 (#6518)”，显示其商业采用路径从 SDK/框架集成扩展到自动化 SaaS 工作流；同日 ea2ee07 移除 OpenMemory from monorepo，暗示产品线拆分或仓库治理调整。
  • 关键数据：GitHub mem0ai/mem0 2026-07-30 抓取为 62,054 stars、7,236 forks、788 open issues；Python SDK v2.0.14 与 Node SDK v3.1.2 均 published_at 2026-07-25；v2.0.13 published_at 2026-07-22T19:41:55Z（Asia/Shanghai 为 7-23）。来源：https://api.github.com/repos/mem0ai/mem0 ，https://api.github.com/repos/mem0ai/mem0/releases?per_page=10
  • 原文链接：https://api.github.com/repos/mem0ai/mem0/releases?per_page=10 ；https://api.github.com/repos/mem0ai/mem0/commits?since=2026-07-22T16:00:00Z&until=2026-07-29T16:00:00Z&per_page=10
  • 影响判断：Mem0 本周的价值在于“记忆层正确性”而非华丽新概念：过滤器、namespace、identity immutability、hybrid search 字段一致性共同决定了长期记忆是否会串租户、漏召回或误召回。Oracle provider 与 Zapier app 说明其在同时走企业数据库适配与低代码生态分发，竞争上会更像“通用 memory middleware”，与 Zep/Graphiti 的 temporal graph 路线形成差异。

Zep：可追溯记忆

对象：Zep

  • 本周动态：本周 Zep 有一篇直接命中 Agent Memory 基础设施核心问题的官方长文《How Zep tracks provenance in agent memory》（7月下旬，搜索结果标注 5 days ago，落在 2026-07-23~07-29 窗口）。原文把“记忆可信度”从召回效果推进到 provenance / lineage / ABAC：Zep 指出，只在 fact 上存一个 source_id 不足以支撑 agent memory，因为 LLM extraction 会把多条 chat message、document、record 合成一个事实，entity resolution 会把 “J. Smith” 与 “John Smith” 合并，后续数据又会 invalidates old facts；因此单值 source pointer 会在合并、改写、失效时漂移。Zep 的解法是把 provenance 做成图结构：raw sources 作为 episodes 原样保存，entities 是跨 episodes 抽取的节点，facts 是带时间戳的 edge；每个 derived node/edge 在 construction time 绑定产生它的 episodes，事实被再次确认或被新 episode 推翻时，edge 的 episode 集合继续增长，valid_at / invalid_at 区分“世界中何时为真”和“系统何时知道”。这篇文章还把 provenance 与权限直接连接：episode ingestion 时打的 metadata（source system、verification status、department、classification）会投影到所有由它派生的 fact/entity 上；Enterprise ABAC 文档显示 Zep 用 RBAC 管理人类管理员，用 ABAC 管理 API key 对项目数据的访问，策略分 action layer 与 attribute layer，可用 default_allow / default_deny、policy set、off/report_only/enforce 模式控制 read/write/destructive action，并基于源 metadata 过滤 graph.search/list/read 结果。Graph search 文档同时显示，Zep 搜索不只是 vector memory，而是 semantic similarity + BM25 + optional breadth-first search + RRF hybrid retrieval，并提供 scope="auto" 一次检索 edges、nodes、episodes、observations、thread summaries 后按 max_characters（默认 2500，最高 50000）组装可直接放进 prompt 的 context block。路线判断：Zep 本周在公开叙事里把“agent memory”从长期偏好/聊天摘要，推进到“可追溯、可删除、可按来源授权的动态知识状态层”，这对医疗、金融、法务等高信任场景比单纯 memory benchmark 更关键。
  • 关键数据：Graph construction inference cost 过去 6 个月降低 40%；Zep graph search auto scope 默认 max_characters=2500、上限 50000；ABAC 为 Enterprise Plan，仅 API key 层，支持 action layer + attribute layer、default_allow/default_deny、off/report_only/enforce；来源 https://blog.getzep.com/how-zep-tracks-provenance-in-agent-memory/、https://help.getzep.com/attribute-based-access-control、https://help.getzep.com/searching-the-graph（抓取 2026-07-30）。
  • 原文链接：https://blog.getzep.com/how-zep-tracks-provenance-in-agent-memory/；https://help.getzep.com/attribute-based-access-control；https://help.getzep.com/searching-the-graph
  • 影响判断：Zep 的信号是 memory layer 正在和 identity/security layer 融合：事实不只是被召回，还必须证明“从哪来、当前是否仍有效、谁有权看”。这让 Zep/Graphiti 路线区别于简单向量库记忆，也会迫使 Mem0、Letta、LangGraph Memory 等竞品补 provenance、source-scoped filter 与右删传播能力。

Letta：有状态 Harness

对象：Letta

  • 本周动态：本周未检出 Letta 在 2026-07-23~07-29 窗口内的重大公开发布；官方文档与 GitHub releases 页可作为近两周/近月背景，显示其仍在把 MemGPT 谱系推进为“stateful agent runtime / harness”。Letta 文档首页把产品定位为 “The platform for building stateful agents”，强调 Letta agents learn from experience and improve with use，harness open source，并可用于 coding agents、personal assistants、AI coworkers 与嵌入式 stateful agents。使用路径上，Letta 把 Agent SDK、Letta Cloud 托管、Letta App Server 自托管、desktop app、本地文件、Skills、Schedules、Channels、always-on computer、GitHub Action 组成一个“常驻 agent runtime”叙事，而不是单纯 memory API。GitHub releases 页当前可见的 Letta Server 0.16.7（背景，非本周）对基础设施更有参考价值：默认 global context window 从 32k 提到 128k，修复 context window reset / compaction overflow / BYOK summarization / Gemini 2.5+/3.x multi-turn tool calling，新增 conversation forking、idempotent conversation streaming、request-scoped system overrides、conversation recompile endpoint；memory/memfs 侧修复 available_skills block 重复、git memory sync、projection-style git memory rendering、manual block edits trigger recompile；安全侧阻断 ImageContent file:/// 本地文件访问绕过、阻断 internal MCP server targets，并把 multi-agent tools 移到 less privileged execution environment。这些背景说明 Letta 的基础设施重心是“有状态 agent 的上下文压缩、记忆文件系统、会话/分叉、技能、定时任务与自托管可靠性”。身份/权限维度上，Letta 相比 Zep/Graphiti 的 ABAC provenance 叙事更偏 harness 内部边界：本地文件、MCP server、multi-agent tool privilege、BYOK 错误标记、self-hosted App Server；若本周没有新 release，报告中不应强行写成新动态。
  • 关键数据：本周重大公开动态 —；背景 release note 显示 Letta Server 0.16.7 将默认 context window 32k→128k，包含 173 commits since 0.16.6，新增 conversation forking、idempotent streaming、conversation recompile endpoint，并修复 file:/// ImageContent bypass 与 internal MCP server targets；来源 https://github.com/letta-ai/letta/releases、https://docs.letta.com/（抓取 2026-07-30，背景非本周）。
  • 原文链接：https://docs.letta.com/；https://github.com/letta-ai/letta/releases
  • 影响判断：Letta 的价值仍在“把 memory 变成 agent harness 的常驻状态管理”，适合需要自托管、技能、日程、文件和长期上下文的个人/团队 agent。短板是本周缺少清晰新公告，且在企业 memory provenance / ABAC / source-level deletion 方面公开叙事不如 Zep；但它在 conversation forking、compaction、memfs 与 always-on runtime 上与 OpenClaw 有相邻竞争/互补关系。

Graphiti：时间知识图谱

对象：Graphiti

  • 本周动态：本周 Graphiti releases 页可见 graphiti-core 0.29.0 发布说明，是 D 组里最直接的 temporal knowledge graph runtime 更新。0.29.0 的主线是“让 ingestion 更便宜，让 search pipeline 更容易演进”。首先，新增 combined node + edge extraction path：过去节点抽取与边/事实抽取通常需要两次 LLM call，现在可通过 use_combined_extraction=True 在 extract_nodes_and_edges_bulk 中用一次调用产生 nodes 与 edges；同时 _extract_and_resolve_nodes 与 extract_edges 支持把 multiple episodes batched into one prompt，通过 [Episode N] headers 与 episode_indices 把抽取结果映射回来源 episode。其次，timestamp resolution 被拆成独立 extract_timestamps / extract_timestamps_batch 步骤，使 valid_at / invalid_at 不再与结构化 fact extraction 竞争 prompt budget；这对“事实何时有效”与“系统何时知道”分离非常关键。第三，search pipeline 做了大规模内部重构，graphiti_core/search/search.py 约 1k lines changed，并补 tracing test coverage，为后续 reranker/search 变化铺路；这直接关系到 Agent Memory 的低延迟、高可解释召回。第四，新增 saga abstraction：Graphiti.summarize_saga(saga_id)、SagaNode 与 refreshed prompt，把多 episode narrative rollup 变成一等能力；新增 fact_triple episode type 与 EpisodicNode.episode_metadata，支持 customer-defined filtering keys。安全/正确性上，0.29.0 修复 attribute merging：节点/边的 attribute dict 不再覆盖 uuid、group_id、created_at、timestamps 等 first-class fields；Kuzu 后端需要 schema migration，RelatesToNode_ 增加 reference_time TIMESTAMP。README 同时强调 Graphiti 是为 agents 构建 temporal context graphs 的 OSS 框架：facts 有 validity window，episodes 是 ground truth/provenance，检索结合 semantic + keyword + graph traversal，支持增量更新而非全量重算；并提示 Graphiti MCP server 可给 Claude、Cursor 等 MCP clients 提供 temporal-aware memory。
  • 关键数据：graphiti-core 0.29.0：combined extraction opt-in use_combined_extraction=True；episode indices 变为 0-based；Kuzu RelatesToNode_ 需新增 reference_time TIMESTAMP；新增 Graphiti.summarize_saga(saga_id)、fact_triple episode type、EpisodicNode.episode_metadata；来源 https://github.com/getzep/graphiti/releases、https://github.com/getzep/graphiti（抓取 2026-07-30）。
  • 原文链接：https://github.com/getzep/graphiti/releases；https://github.com/getzep/graphiti
  • 影响判断：Graphiti 0.29.0 的意义不是新增一个 memory demo，而是降低 temporal graph ingestion 成本、强化 provenance/filtering/search pipeline，为 Zep 的托管 memory 平台和开源自托管用户提供更可运营的图构建层。与 Mem0 的 vector/hybrid memory middleware 相比，Graphiti 更押注“事实随时间变化、来源可追溯、图谱可增量更新”；缺点是运维复杂度和图数据库依赖更高。

记忆与知识洞察

本组洞察：本周 Memory/Knowledge State 层的共同趋势是从“把历史塞进向量库”升级到“可追溯、可过滤、可按权限裁剪、可随时间失效的上下文基础设施”。Firecrawl 把外部知识获取做成 search/scrape/crawl/browser/research-agent 一体化 MCP；Mem0 在 identity fields immutable、namespace reset、vector filter correctness、Oracle provider 上补多租户正确性；Zep/Graphiti 明确把 episodes/provenance/valid_at/invalid_at/ABAC/source metadata 做成 memory 的核心；Letta 则继续沿 stateful harness、memfs、compaction、conversation forking、自托管 runtime 方向演进。五维看：产品更新集中在 MCP、hybrid retrieval、graph ingestion、context assembly；生态合作是 Claude/Cursor/OpenClaw/自动化工具接入；采用商业化开始区分托管平台与 OSS core；竞争格局从 Mem0 的通用 middleware、Zep/Graphiti 的 temporal graph、Letta 的 harness/runtime 分层；身份权限安全则从 API key 扩展到 source-level metadata、tenant-scoped filters、不可变身份字段、右删传播与内部 MCP/文件访问边界。

身份与权限

Identity 层正在回答每次工具调用是谁、用谁的凭据、能否追责。

Composio：工具会话

对象：Composio

  • 本周动态：本周未看到 Composio 官方博客/变更日志发布重大产品公告，但 GitHub 与文档侧有可验证更新：ComposioHQ/composio 仓库 README 现定位为 SDK monorepo，强调“1000+ pre-authenticated toolkits、per-user sessions、authentication、triggers、sandbox”，并给出 v3 当前接入模式：composio.create(user_id) 创建按用户隔离的 session，session.tools() 输出原生 tool，或用 session.mcp.url 暴露 hosted MCP endpoint；README 还说明默认 session 会带 meta tools，在运行时发现、认证、执行 app tools，避免把数百个 tool definition 一次性塞进模型上下文。GitHub releases 页本周可见 pre-release/patch 级变更：修复 npm/editor tooltip 中 package homepage 指向不存在 main 分支的问题、刷新依赖范围与 lockfile、在 provider tool schema 输出前规整重复 JSON Schema required 条目。这些不是功能大版本，但 schema 规范化直接关系到 tool permission 与 provider adapter 的可靠性：重复 required 可能造成工具参数校验不一致，进而扩大模型误调用或绕过参数约束的概率。身份/权限侧，Composio 当前优势是把外部 SaaS 连接抽象为 user-scoped session、auth config、connected account，并支持 hosted MCP；弱点是公开 repo 主要是 SDK/adapter，不等同于可审计的托管 runtime。近两周背景中，Nango 7月27日竞品文章称 Composio 有 1,047 toolkits，GitHub 单 toolkit 可超过 800 tools，并提到 2026年5月安全事件中约 5,001 个 GitHub OAuth token 与 5,241 个 API key 暴露或可能暴露、企业层才提供 action-level RBAC 与每次 tool call audit trail。结合 MCP 2026-07-28 新规，Composio 的 hosted MCP 若要进入企业生产，需要尽快对齐 stateless MCP、Mcp-Method/Mcp-Name 网关授权、RFC 9207 iss 校验、DCR→CIMD 迁移，并把审计日志与最小权限从 Enterprise-only 升级为默认安全姿态。
  • 关键数据：1000+ toolkits（GitHub README，https://github.com/ComposioHQ/composio，2026-07-30抓取）；1,047 toolkits、约5,001 GitHub OAuth tokens 与5,241 API keys 暴露/可能暴露为竞品文章引用（https://nango.dev/blog/best-enterprise-grade-agent-api-integration-providers/，2026-07-27）；本周 patch commit 包括 7125576 schema required 去重、fa933a6 homepage 修复、58bc93b 依赖刷新（https://github.com/ComposioHQ/composio/releases，2026-07-30抓取）。
  • 原文链接：https://github.com/ComposioHQ/composio；https://github.com/ComposioHQ/composio/releases；https://docs.composio.dev/；https://nango.dev/blog/best-enterprise-grade-agent-api-integration-providers/
  • 影响判断：Composio 仍是“超大工具目录 + 会话化 MCP/SDK 接入”的代表，适合内部自动化与快速覆盖 SaaS 操作面；但在 Agent 身份层，它的信任恢复重点已从“工具多”转为“token 托管可审计、每次工具执行可追责、越权 blast radius 可控”。MCP 本周规范升级让网关可按 header 做授权/限流，正好给 Composio 这类平台提供把权限边界下沉到 MCP 网关层的机会。

Arcade：MCP 授权

对象：Arcade

  • 本周动态：Arcade 本周没有 GitHub release 包，但有直接落在身份/权限面的代码与文档进展。ArcadeAI/arcade-mcp 仓库在 7月24日合入 c04b52c：fix(arcade-mcp-server): derive engine URL from arcade login coordinator，把 cloud.<domain> 登录 coordinator 自动映射到配套的 api.<domain> engine，并明确“非生产登录（如 staging domain）不应把 token 发到 production engine 然后得到 401”。这个修复看似部署体验问题，实质是 token audience/issuer 边界问题：CLI 登录得到的凭据必须只交给同一环境的授权/执行面，否则可能形成跨环境 token 混用、错误审计归属或不可解释的授权失败。Arcade 文档本周可见的安全体系已比较完整：Authorized Tool Calling 明确 Arcade 处理 OAuth 2.0、API keys、user tokens，client.tools.authorize(tool_name="Gmail.ListEmails", user_id=...) 生成用户授权 URL，用户只批准已同意的数据范围；执行时只传 user_id，Arcade 记住并刷新授权 token，直到过期或撤销。MCP server 侧，Arcade 把安全拆成两层：Resource Server Auth（front-door）在每个 HTTP request 校验 Bearer token，按 sub 提取 context.user_id，并支持 WorkOS/Auth0/Descope、multi-IdP、issuer/JWKS/audience 校验；Tool-Level Authorization 则由 @app.tool(requires_auth=GitHub(scopes=["repo", "read:user"])) 声明每个工具所需 OAuth scope，Arcade 在 runtime 注入 token，client 与 LLM 不见 secret。审计方面，Arcade Audit Logs 文档（7月18日，近两周背景）称“默认开启、无需启用”，可在 dashboard 过滤，也可通过 /api/v1/orgs/{org_id}/audit_logs 与 /api/v1/orgs/{org_id}/projects/{project_id}/audit_logs 拉取到 SIEM；字段包括 client_ip、action、source、principal_id、user_id、resource_type、data，并有 100 requests/60s/IP rate limit。竞争判断：Arcade 在 E 组维度上最强的是 MCP-native 的双层授权模型与 OAuth 2.1 Protected Resource 文档化，弱点是公开 release 节奏弱、GitHub releases 为空，且相较 Nango 的同步/webhook/大量集成生态更偏“tool execution runtime”；若企业要求每次 tool execution 的细粒度审计、DLP 与审批，仍需确认审计是否覆盖工具调用全链路而不仅是控制面管理动作。
  • 关键数据：7,500+ agent-optimized tools across 81 MCP servers（Arcade docs/README，https://github.com/ArcadeAI/arcade-mcp 与 https://docs.arcade.dev/，2026-07-30抓取）；GitHub stars 982、forks 101、open issues 16、7月24日提交 c04b52c 修复 coordinator→engine URL（https://github.com/ArcadeAI/arcade-mcp/commit/c04b52c，2026-07-30抓取）；Audit Logs API rate limit 100 requests/60s/IP，Last updated July 18, 2026（https://docs.arcade.dev/en/guides/audit-logs）。
  • 原文链接：https://github.com/ArcadeAI/arcade-mcp；https://github.com/ArcadeAI/arcade-mcp/commit/c04b52c；https://docs.arcade.dev/en/guides/tool-calling/custom-apps/auth-tool-calling；https://docs.arcade.dev/en/learn/server-level-vs-tool-level-auth；https://docs.arcade.dev/en/guides/create-tools/secure-your-server/secure-your-mcp-server；https://docs.arcade.dev/en/guides/audit-logs
  • 影响判断：Arcade 正把“Agent 调工具”包装成身份平台问题：先验证谁能访问 MCP server，再按工具声明的 scope 向第三方 API 取用户授权。MCP 2026-07-28 的 stateless 与 header routing 会放大这种架构价值，但 Arcade 需要用更清晰的 release/changelog 与 tool-call-level audit 证据来赢得大型企业采购。

Nango：MCP 网关

对象：Nango

  • 本周动态：Nango 是本组本周最密集的对象。7月29日官方博客《MCP gateway vs MCP proxy》直接回应 MCP 2026-07-28 之后的治理层分工：MCP gateway 是 agent 与 MCP servers 之间的中央入口，负责 authentication、authorization、routing、audit logging；MCP proxy 只做传输桥接或聚合，不一定有 policy layer。文章点名新版 MCP 去掉 Mcp-Session-Id，新增 Mcp-Method 与 Mcp-Name headers，使中间层无需解析 body 即可路由；同时强调 MCP security best practices 禁止 token passthrough，server 不应把从 client 收到的 token 转发给上游 API，外部 SaaS OAuth token 应由独立 integration provider 托管。Nango 借此把自身定位为 gateway 下方的 credential/integration 层：https://api.nango.dev/mcp 暴露已启用 action functions，调用方只传 Authorization: Bearer <ENV-SECRET-KEY>、connection-id、provider-config-key，每个 request 按 connection 注入对应用户凭据；MCP Auth 文档还说明可让用户连接 Notion/Linear/HubSpot 等外部 MCP server，Nango 负责 MCP OAuth、client registration/PKCE、token 存储刷新，并通过 Proxy API 发起 JSON-RPC。7月24日 Sage Intacct OAuth 文章提供了典型 token 托管事故复盘：同一 Sage Intacct user+company 重复授权会让旧 connection refresh token 失效；Nango 通过 per-connection auth logs 识别“第二次授权”触发，并建议一 user/company 只保留一个 authorization-code connection、独立环境用不同用户或 client credentials。GitHub 侧，本周 master 有 7月29日 62da67c：新增/扩展 audit resource-action 类型，覆盖 connection refreshed/metadata_updated/updated/deleted、integration updated/deleted、function deleted、api_key updated/deleted、sync enabled/disabled/frequency_changed、member removed/role_changed、environment variables_changed、billing plan_changed、app_auth password_changed 等；这把控制面 mutation event 类型锁死到 endpoint policy，利于权限审计与合规取证。同日 6825803 增加 self-hosted Management MCP server setup，要求 NANGO_MANAGEMENT_MCP_SERVER_URL=https://mcp.example.com 且 hostname 不同于 NANGO_SERVER_URL，Nango 用 request hostname 区分 Management MCP 与 public API，endpoint 为 /mcp；cd43450 将 env var 从 Control Plane MCP 改名为 Management MCP，更清晰地区分管理面。身份/权限判断：Nango 的优势是把 OAuth token、API key、connection ownership、action execution logs、OpenTelemetry export、MCP server 和外部 MCP Auth 串成一条链；风险点是 hosted MCP 当前使用环境 secret key + connection header，企业必须在自身后端完成“当前用户→connectionId”的强绑定，避免 header 被代理层误配导致横向越权。
  • 关键数据：900+ APIs（GitHub README/Docs，https://github.com/NangoHQ/nango，2026-07-30抓取）；5,000+ customizable pre-built tools（https://nango.dev/blog/mcp-gateway-vs-mcp-proxy，2026-07-29）；GitHub stars 11,293、forks 1,231、open issues 148、7月23~29 有多次 commits，包括 62da67c audit、6825803 Management MCP setup、cd43450 env var rename（GitHub API/commit pages，2026-07-30抓取）；OpenTelemetry 支持 Sync executions、Action executions、Third-party API webhook executions、Proxied requests（https://nango.dev/docs/guides/platform/observability.md）。
  • 原文链接：https://nango.dev/blog/mcp-gateway-vs-mcp-proxy；https://nango.dev/blog/fix-sage-intacct-oauth-token-invalid-refresh-failures；https://github.com/NangoHQ/nango/commit/62da67c；https://github.com/NangoHQ/nango/commit/6825803；https://github.com/NangoHQ/nango/commit/cd43450；https://nango.dev/docs/guides/auth/mcp-auth.md；https://nango.dev/docs/guides/functions/tool-calling.md；https://nango.dev/docs/guides/platform/observability.md
  • 影响判断：Nango 正从“OAuth/token 管理 + sync”扩展到 Agent tool governance 的底座层，尤其是 MCP Auth 与 Management MCP 让它既能接外部 MCP server，也能被管理面 agent 操作。短期竞争上，Nango 会持续用“开源、可审计、OpenTelemetry、per-connection logs、BYOC/自托管”对冲 Composio/Arcade/Pipedream 的工具目录优势；但最终安全成败取决于客户是否正确实现 connectionId 与本地用户/租户的授权绑定。

Pipedream：Connect 工具面

对象：Pipedream Connect

  • 本周动态：Pipedream 本周没有看到独立 Connect 产品公告，但 GitHub 仓库在 7月28~29日连续出现“AI-optimized”组件更新，说明 Connect/MCP 工具面的优化仍在推进。典型例子是 ca91c36：feat(gmail): eval-driven fixes to the AI-optimized Gmail actions，把 Gmail action 版本升到 0.3.0，新增 fields 参数、bodyText 派生字段、bodyChars、bodyTruncated/snippetTruncated 等安全与可用性提示，并在描述中明确“Never answer a question about what an email SAYS from snippet”，因为 snippet 只是约 200 字前缀；超预算时如果调用方显式指定 fields，则丢整条消息而不是悄悄删字段。这类改动对 Agent 权限边界很关键：它不是 OAuth 层，而是 tool schema / tool description / output budget 层，减少模型基于不完整数据做出越权或误导性结论。ba70fa6 对 Expensify create report action 加 // x-pd-ai: optimized，并把 expense 入参说明改为“array of JSON strings”而非 raw JSON objects，降低工具调用参数错配；ded9d8a 为 WhoisFreaks 增加 bulk DNS/IP reputation/WHOIS actions，标注 destructiveHint: false、readOnlyHint: true、openWorldHint: true，说明 Pipedream 正把 MCP/AI tool annotations 当成权限与风险提示面来维护。产品文档侧，Connect Overview 称可向 app 或 AI agent 增加 3,000+ integrations，Pipedream MCP 可提供 10,000+ tools；MCP 开发文档给出 remote server https://remote.mcp.pipedream.net/v3，支持 SSE 与 streamable HTTP，开发者用 client credentials OAuth 获取 access token，每次请求带 Authorization、x-pd-project-id、x-pd-environment、x-pd-external-user-id、x-pd-app-slug，可选 x-pd-account-id/x-pd-oauth-app-id/registry。Managed Auth 的 Connect token 是按 external_user_id 与 environment scoped，4小时过期且一次性使用；若 tool call 需要用户连接账号而尚未连接，MCP server 会返回 Connect Link URL。安全文档显示 Connect via API or MCP 不存储也不记录 request payload/response bodies；OAuth grants、API keys、environment variables 生产库静态加密，AWS KMS AES-256-GCM，key 年度轮换；Pipedream API 建议使用 workspace-admin 管理的 OAuth clients，tokens 短期、带 scopes，access tokens 为 ED25519 签名 JWT、1小时过期。竞争判断：Pipedream 的强项是公开组件仓库、3,000+ app/10,000+ tool 覆盖、用户连接和 MCP 一体化；弱项是 end-user isolation 很依赖调用方正确传 external_user_id/accountId，而 Connect 声明不记录 payload/body 也意味着合规审计若要还原每次 tool call 的参数与结果，需要客户在自身侧另建审计层。
  • 关键数据：3,000+ APIs/apps、10,000+ tools（https://pipedream.com/docs/connect 与 https://pipedream.com/docs/connect/mcp/developers，2026-07-30抓取）；GitHub stars 11,579、forks 5,738、open issues 4,487（GitHub API，2026-07-30抓取）；Connect tokens 4小时过期、一次性使用（https://pipedream.com/docs/connect/managed-auth/tokens）；Pipedream REST API access tokens 1小时过期，ED25519 JWT（https://pipedream.com/docs/privacy-and-security）。
  • 原文链接：https://github.com/PipedreamHQ/pipedream；https://github.com/PipedreamHQ/pipedream/commit/ca91c36；https://github.com/PipedreamHQ/pipedream/commit/ba70fa6；https://github.com/PipedreamHQ/pipedream/commit/ded9d8a；https://pipedream.com/docs/connect；https://pipedream.com/docs/connect/mcp/developers；https://pipedream.com/docs/connect/managed-auth/tokens；https://pipedream.com/docs/privacy-and-security
  • 影响判断：Pipedream 正把既有 integration component 资产改造成 Agent/MCP 可调用工具，重点从“能连 API”升级为“工具描述足够让模型安全地调用”。但在企业 Agent identity 场景，Pipedream 更像大规模 managed auth + tool catalog，缺少 Nango/Arcade 那种明确的 gateway policy/audit narrative；最适合需要快速覆盖大量 SaaS、且愿意在自家应用层补足用户授权与审计闭环的团队。

身份与权限洞察

本组洞察：本周 MCP 2026-07-28 把 Agent auth/tool permission 基础设施推到新阶段：stateless core、Mcp-Method/Mcp-Name headers、RFC 9207 iss 校验、CIMD 取代 DCR、Protected Resource/EMA 等变化，让“工具网关”可以像 API gateway 一样按身份、方法、工具名、租户做统一授权与审计。四个对象的竞争焦点明显分层：Arcade 强在 MCP-native 双层授权（front-door Resource Server Auth + tool-level OAuth scopes）；Nango 强在 OAuth token/connection 托管、MCP Auth、OpenTelemetry 与审计控制面；Pipedream 强在 3,000+ app/10,000+ tool 的组件覆盖和 Connect token；Composio 强在超大 toolkit 与 agent-friendly session/CLI，但需要用更默认化的审计和权限边界修复安全信任。下一阶段企业采购会少问“有多少 tools”，更多问：每次 tool call 是谁以谁的凭据发起、是否只暴露允许的工具、token 是否永不进模型、是否能证明参数/结果/上游 API 调用、是否能在跨租户/跨环境/跨 MCP server 的场景下避免 token passthrough 和 confused-deputy 越权。

信息校验

信息校验：24 对象 / 24 条关键数据段 / 34 条结论判断 / 去重后 145 个原文链接，全部对应 ✅

说明：正文保留研究报告中的对象、数据、判断与链接；仅对章节顺序和标题做读者向编排，未新增外部事实。

🏷️ 标签： #AIAgent #Agent基础设施 #AgentRuntime #MCP #AgentMemory #AgentIdentity

📖 相关阅读

全球 AI Agent 基础设施研究周报 · 第 6 期（2026-07-16 ~ 07-22）
AI 2026/07/23
全球 AI Agent 基础设施研究周报 · 第 5 期（2026-07-09 ~ 07-15）
AI 2026/07/16
全球 AI 创业公司研究周报 · 第 6 期（2026-07-08 ~ 2026-07-14）
AI 2026/07/15
全球 AI Agent 基础设施研究周报 · 第 4 期（2026-07-02 ~ 07-08）
AI 2026/07/09
上一篇
MCP 2026-07-28：Claude 连接器生态进入生产化阶段