Data for AI：取之有度，用之有节！从Harness视角破解Agent应用Token爆炸难题

OpenClaw的流行与Token爆炸OpenClaw的流行最近大家见面免不了都要问一句你养龙虾了吗这里的“龙虾”指的正是近期爆火的开源AI Agent框架OpenClaw。自2025年11月发布以来OpenClaw在GitHub上已经获得了超过35万星标和超过7万fork2026年4月数据成为2026年初最受人关注的AI Agent项目之一。OpenClaw的出现让构建复杂AI Agent变得前所未有的简单从“只会说”到“能动手”与传统聊天AI如ChatGPT不同OpenClaw能够直接操作计算机系统整理文件、发邮件、写代码、运行程序真正实现“AI替你干活”。极低的使用门槛用户通过日常聊天工具即可指挥它无需编程基础部署只需复制一行命令极大降低了AI Agent的使用门槛。强大的可扩展能力OpenClaw支持通过新增技能、优化记忆和调整Prompt来不断提升能力。在持续使用过程中结合记忆积累与技能扩展可以实现“越用越好用”的效果‌。开源生态快速扩张ClawHub技能商店聚集超1.3万个插件覆盖办公、编程、智能家居等场景开发者用Markdown即可贡献技能生态呈指数级增长。但随着越来越多的企业和个人开始大量使用OpenClaw一个令人头疼的问题逐渐浮出水面Token爆炸。根据OpenRouter在3月16日至22日这一周中国模型共记录了7.36万亿个Token比前一周增长了56.9%。其实Token消耗暴增并不是OpenClaw独有的问题所有AI Agent应用从实验室到生产环境都要面临这一拦路虎。本文将以OpenClaw为例讨论Token爆炸的问题。下面先一起了解下OpenClaw的架构。OpenClaw的架构图1如图1所示OpenClaw的核心组件包括1.Channel Adapters将不同消息系统的差异抽象化提供统一的消息接口可以对接不同消息系统。主要职责包括身份认证入站消息解析访问控制以及出站消息格式化。2.Control Interfaces提供多种方式与Gateway交互方式以适合不同的用例包括Web UI、CLI、macOS App和Mobile nodes。3.Gateway Control Plane它不仅是消息路由中心更是安全边界、状态管理器和协调者的统一体。当入站消息到达时Gateway通过访问控制检查对其进行路由解析应该处理它的会话并将其分派给适当的Agent。它协调系统状态包括会话、在线状态指示器、健康监控和cron任务。4.Agent Runtime从高层次来看运行时在每一轮对话中执行四件事:解析会话当消息到达时运行时首先确定应该由哪个会话处理它。组装上下文一旦会话被解析运行时就会为模型组装上下文组装好的上下文随后被流式传输到配置的模型提供商或者本地模型。流式调用模型并执行工具调用当模型响应时运行时会监视工具调用并拦截它们。每个工具结果都会被流式传回到正在进行的模型生成中模型将其整合并继续。将更新的状态持久化到磁盘对话轮次完成后运行时将更新的会话状态(消息、工具调用/结果以及任何其他跟踪的状态)持久化回磁盘。从上面的架构中可以看出OpenClaw为模型组装的上下文是决定Token消耗的关键因素它包括从持久化的JSON会话文件加载的会话历史这样每个会话可以随时间保持连续性。通过读取workspace配置文件并将它们组合成单个指令栈来构建的动态system prompt。通过语义搜索拉取记忆例如先前相关的对话轮次或笔记这样模型只看到最相关的历史上下文而不是不断增长的完整记录。图2如图2所示OpenClaw通过组合多个来源构建最终的系统提示词发送给模型workspace配置文件AGENTS.md核心Agent指令捆绑的默认配置。这是操作基线——定义Agent允许做什么、全局约束以及适用于所有会话的不可协商规则。SOUL.md个性和语气指导可选。定义语音和交互风格——Agent如何说话和组织答案但不涉及工具行为或安全边界。TOOLS.md用户特定的工具约定可选。这是您关于如何在您的环境中使用工具的个人笔记而不是工具注册表OpenClaw会自动向模型提供工具定义。动态上下文每轮组装会话历史当前对话中的最近消息。技能skills/skill/SKILL.md技能定义和使用说明技能存在的必要条件。包含结构化指南的文件用于使用可用工具完成特定任务可以理解为操作手册或标准操作程序。记忆搜索语义相似的过往对话提供有用的上下文。工具定义自动生成内置工具src/agents/pi-tools.tssrc/agents/openclaw-tools.tsbash、浏览器、文件操作、画布和核心能力。插件工具【通过api.registerTool(toolNametoolDefinition)注册】通过扩展系统添加的自定义工具。基础系统Pi AgentCore来自Agent运行时库的基础指令。Token爆炸的常见原因对于AI Agent来说造成Token爆炸的常见原因有以下几类。第一类爆炸注入型爆炸即“先全部塞进去再让模型自己判断”。这类爆炸最常见于技能太多缺少前置召回。长期记忆太长缺少按需注入。中间状态太杂缺少上下文裁剪。表面上看是模型Token用多了。实际上看是没有在模型调用之前先用数据层把无关内容挡在门外。第二类爆炸重复型爆炸即“本来记住了但系统不会复用”。这类爆炸最常见于明明上轮已经找过这个知识点这轮又重新搜一遍。明明某个skill调用路径已经稳定还是每次从零选择。明明用户偏好和业务上下文之前就存在这次又重新推理一遍。这类成本非常隐蔽因为它不像一次超长prompt那么刺眼。它更像水龙头没关严一天一滴看账单时才发现地板已经泡烂了。第三类爆炸黑盒型爆炸这是企业最怕的一种不是花了钱而是不知道钱为什么花掉。您需要清楚调了几个skills。哪一步用了大模型哪一步只是检索。memory命中了没有。命中失败是recall问题、索引问题还是上下文策略问题。真正贵的是首轮决策还是中间重试。如果这些都看不见优化就无从谈起。Harness视角下的解决方案有一个历史故事很契合这个场景隋末瓦岗军攻占洛口仓向百姓散粮却缺乏管理百姓皆至无限制取粮路上往往背不动又抛弃导致从仓城到郭门的路上米粮堆积如白沙被车马践踏造成极大浪费。最终瓦岗军因为粗疏的管理并没有充分发挥洛口仓丰富仓储的优势而落败。本质上这种“资源无序消耗”与Agent系统中的Token浪费高度类似。Token爆炸并不是因为模型不够聪明需要太多上下文才能理解任务而是因为缺乏高效的运行时资源管理方法。正如Vivek Trivedy在《The Anatomy of an Agent Harness》中所说AgentModelHarness。除了Model其他所有的部分都属于Harness包括各种代码配置和执行逻辑等等。其实Token所有问题都可以归结为推理花多少Token计算预算信息进多少Memory上下文供给能力暴露多少Skill能力调用下面继续以OpenClaw作为典型示例分析如何监控Token消耗如何通过管理上下文和Skills来减少Token浪费。Token消耗监控OpenClaw实现在当前版本的OpenClaw中系统已经具备了一定程度的Token使用可见性但整体仍停留在较为基础的层面。OpenClaw可以通过状态查询命令如/status展示最近一次模型调用的input/output Token数量以及预估成本同时也提供了对上下文窗口占用情况的查看能力使开发者能够大致感知当前prompt的规模。这些能力本质上依赖于诸如Amazon Bedrock等底层模型返回的usage数据。然而这类监控能力本质上属于“结果展示”而非“过程观测”。系统并不会对Token消耗进行结构化记录也缺乏跨会话、跨任务的统计分析能力。例如session持久化中虽然保存了完整对话历史和Token使用数据但这些数据缺乏结构化的分析能力无法支持跨会话、跨任务的统计分析和趋势洞察。更关键的问题在于OpenClaw当前缺乏对Agent执行链路的细粒度追踪能力。在一次完整的任务执行过程中Token消耗可能分散在多个阶段Prompt构建、记忆检索、技能注入、工具调用以及多轮推理循环中。但系统无法回答诸如“哪一个阶段消耗最多Token”或“某个Skill是否导致上下文膨胀”等关键问题这使得优化工作往往只能依赖经验而缺乏数据支撑。更进一步OpenClaw也尚未提供Token预算管理机制。例如无法为单个任务或用户设置Token上限也缺乏在预算超限时自动降级模型、裁剪上下文或提前终止执行的能力。AI Agent应用优化措施在优化方向上一个直观的思路是引入云厂商提供的可观测性能力。例如当OpenClaw运行在Amazon Bedrock之上时可以借助其原生的CloudWatch指标如InputTokenCount、OutputTokenCount、TimeToFirstToken等对模型调用进行监控。此外通过将调用日志写入Amazon CloudWatch Logs或Timestream也可以实现对Token消耗的时序分析和热点定位。更进一步Amazon Bedrock AgentCore Observability提供了一种更高层次的观测能力。它可以对一次完整的Agent调用进行拆解展示执行过程中的多个步骤并记录每一步对应的模型调用次数、延迟以及Token使用情况。这种能力已经从“单次模型调用”提升到了“任务级执行链路”能够帮助开发者理解一个复杂任务在宏观层面的资源消耗结构。但需要注意的是即便是AgentCore Observability其可见性仍然存在边界。它能够观测“调用了多少次模型”却无法洞察“Prompt是如何构建的”。例如系统仍无法直接得知某一轮对话中Skill描述、记忆片段或系统提示词各自占用了多少Token。这意味着在进行精细化优化如裁剪无效上下文或压缩技能描述时仍然需要在Agent Runtime内部引入额外的埋点与追踪机制。从工程角度来看一个完整的Token可观测体系应当覆盖三个层级模型调用层LLM usageAgent执行层任务/步骤级tracingPrompt构建层上下文组成分析当前OpenClaw已经具备第一层能力引入Amazon Bedrock AgentCore可以补足第二层而真正决定优化深度的第三层仍然需要在框架内部实现。换句话说OpenClaw当前可以回答“花了多少Token”Amazon Bedrock AgentCore可以回答“在哪些步骤花了Token”而真正决定优化空间的问题是“这些Token究竟是被Skill描述、记忆片段还是系统提示词消耗掉的”记忆管理OpenClaw实现图3如图所示OpenClaw的记忆管理系统以本地文件MarkdownSQLite索引为核心存储和管理历史会话的记忆内容并结合向量嵌入Vector Embedding和全文检索FTS来提升检索效率。其记忆管理策略包括以下几个关键部分MemoryIndexManager记忆状态的中枢OpenClaw通过MemoryIndexManager来跟踪和管理记忆状态。所有会话历史和任务相关的内容都被存储为Markdown文件并通过SQLite数据库进行索引。MemoryIndexManager负责索引构建、向量生成、检索调度等核心逻辑是整个记忆系统的执行中枢。这套系统通过插件注册机制实现了良好的扩展性:registerMemoryRuntime定义索引和检索的核心逻辑。registerMemoryEmbeddingProvider添加新的嵌入模型如本地Llama、Amazon Bedrock等。registerMemoryFlushPlanResolver确定何时持久化或压缩记忆。系统支持本地模型、Amazon Bedrock等多种嵌入提供商并通过插件机制注册在运行时选择可用Provider。混合搜索:语义与关键词的协同OpenClaw采用了混合搜索Hybrid Search策略结合了向量搜索和传统的全文检索技术。这种设计使得系统能够在不同场景下提供更高效、更相关的结果:向量搜索系统通过memory_search工具计算查询Embedding与chunks_vec表中向量数据之间的余弦相似度选择语义上最相关的记忆项。全文搜索FTS5当需要通过关键词匹配历史记忆时系统使用memory_get工具配合FTS5进行查找。FTS5采用BM25算法为搜索结果打分这对于查找特定标识符或精确信息非常有效。混合评分使用加权组合公式ScoreVectorWeight×VectorScoreFtsWeight×FtsScore平衡语义理解和关键词匹配。时间衰减结果可以根据时间进行衰减优先考虑最近的上下文。这种混合检索机制本质上是在“语义召回”和“精确匹配”之间做权衡以提升不同查询类型下的稳定性。记忆同步与更新机制OpenClaw实现了一套完善的同步机制确保索引数据的实时性和一致性:文件监听系统通过chokidar文件监听库检测memory/目录的变化确保对记忆库的变动能及时更新。会话同步监听AgentMessage事件当会话的消息数达到一定的增量阈值时触发增量更新操作。在活跃聊天期间系统会对更新进行防抖处理。原子性重建索引在临时文件中构建新索引完成后进行原子性交换防止索引损坏。定时同步除了实时同步外系统还会定期进行记忆同步确保外部更新能够在预定时间内反映到记忆数据库中。Dreaming系统短期到长期的记忆提升OpenClaw的一个独特性是其后台“做梦”Dreaming机制这是一个记忆整合过程模拟了人类记忆的巩固过程自动将重要的短期记忆转化为长期知识存储在MEMORY.md中。本质上这一机制将“是否被频繁使用”作为信号实现了一种自动化的记忆重要性排序与长期化过程Light Sleep浅睡眠频繁扫描识别候选记忆并记录“回忆”次数。REM Sleep深度睡眠更深层的整合过程基于频率和相关性对候选记忆打分。提升评分机制使用加权公式综合考虑频率检索次数、相关性语义得分和多样性唯一查询数。AI Agent应用优化措施通过OpenClaw的例子您可以看到要减少Token浪费记忆管理至关重要。对于AI Agent应用来说以下是几个可能的改进点分层记忆架构与记忆策略核心原则区分不同时间尺度和重要性级别的记忆并根据内容类型选择合适的记忆策略。分层设计短期记忆层仅包括当前会话和最近几轮对话保持即时上下文的连贯性。长期记忆层全局知识库包含经过验证的重要信息和用户偏好。每个层级的记忆可以按需加载避免无关的记忆内容影响当前任务。同时采用滑动窗口机制防止对话上下文无限增长系统仅保持最近N轮对话的完整上下文超出部分通过压缩或摘要来减少Token消耗。通过分层记忆和动态加载可将记忆相关的Token消耗最多降低40-60%。记忆策略不是所有对话内容都需要长期保存应根据场景确定哪些信息值得记忆语义记忆Semantic Memory存储客观事实、用户偏好和基础知识如项目配置、技术栈选择等。情景记忆Episodic Memory捕获交互经验存储对话内容和完整上下文用于学习过去经验。用户偏好记忆User Preference Memory识别和提取用户偏好、选择和风格如编码风格、沟通偏好等。摘要记忆Summary Memory对长对话生成摘要保留关键信息的同时大幅减少Token占用。触发机制可以采用轮次触发每3-5轮对话自动生成摘要或事件触发任务完成、场景转换等关键节点记录信息。譬如Amazon Bedrock AgentCore Memory正是采用了这种分层设计。它明确区分了短期记忆Short-term Memory和长期记忆Long-term Memory短期记忆捕获单个会话内的逐轮交互维护即时上下文。长期记忆则自动从对话中提取关键洞察跨多个会话持久化知识保留。同时AgentCore提供了以下多种内置记忆策略每种策略针对不同类型的信息提取进行了优化SemanticMemoryStrategySummaryMemoryStrategyUserPreferenceMemoryStrategyEpisodicMemoryStrategy上下文工程与动态加载核心原则通过内容优化和加载策略的双重手段最大化记忆的价值密度最小化Token消耗。内容优化策略语义去重在索引和检索阶段进行语义去重确保相同或高度相似的记忆不被多次加载到上下文中可以通过向量相似度阈值来识别重复内容。信息摘要使用对话总结将长对话压缩为短文本保留关键信息。例如将一段10轮的技术讨论压缩为“用户询问了关于X技术的Y问题最终确定使用Z方案”。分层摘要对不同时间尺度的记忆采用不同粒度的摘要。近期记忆保留更多细节远期记忆仅保留核心要点。加载策略按需加载根据任务的复杂度、当前上下文窗口的剩余空间以及记忆的相关性得分动态决定加载多少记忆内容。简单查询可能只需要1-2条记忆而复杂任务可能需要10条。上下文预算管理为记忆检索设置Token预算确保记忆内容不会挤占任务执行所需的上下文空间。动态清理在任务完成后自动清理不再需要的短期记忆释放资源。对于长期未被访问的记忆可以降低其优先级或进行归档。过期机制为记忆设置时效性标记对于时间敏感的信息如“本周的会议安排”在过期后自动降低其检索权重。上下文工程Context Engineering强调根据任务需求动态组织信息。系统应该实现“智能调度”功能决定何时从记忆中检索信息、如何组织和呈现给LLM。譬如Amazon Bedrock AgentCore的Summary策略展示了内容优化的实践系统可以自动生成会话摘要将冗长的对话历史压缩为简洁的要点在保留关键信息的同时大幅减少Token消耗。向量存储选型与扩展核心原则根据规模和性能需求选择合适的向量存储方案。实施策略个人使用场景当AI Agent用于个人使用数据量小且没有跨用户数据检索的需求时SQLite和Amazon S3 Vectors都可以满足需求且成本较低提供快速原型验证能力。其中SQLite适合本地开发和小规模部署而Amazon S3 Vectors有更好的持久性和扩展上限。大规模客户使用场景当AI Agent面对大量客户时如果每个客户只需要检索自身数据希望数据完全隔离且成本敏感可以选择Amazon S3 Vectors如果客户的数据之间需要共享且对响应时间有要求可以考虑使用专业化向量数据库例如Amazon Aurora PostgreSQL或Amazon OpenSearch Service并通过Serverless来节省成本应对负载波动。需要权衡本地化部署的便利性和云端服务的性能优势。可以采用可插拔的存储后端设计让用户根据场景选择合适的方案。命名空间管理与跨会话共享核心原则通过层级化的命名空间结构支持不同粒度的记忆隔离和共享可实现跨设备或跨实例的记忆同步减少重复检索。实施策略1.命名空间组织引入层级化的命名空间结构支持不同粒度的记忆隔离和共享例如用户级命名空间存储特定用户的偏好和历史。项目级命名空间存储特定项目的上下文和知识。全局命名空间存储通用知识和常见问题解答。2.跨会话记忆共享允许在不同任务或会话之间共享有价值的记忆尤其是对于常见的基础信息或已验证的知识。这样可以避免每次重新加载相同的信息减少Token消耗。3.云存储与记忆同步对于需要跨设备或跨实例共享记忆的场景可以通过Amazon S3、Amazon DynamoDB或其他存储方案实现记忆的云端同步。通过缓存机制减少对远程存储的请求频次平衡性能和一致性。譬如Amazon Bedrock AgentCore Memory的命名空间组织方式提供了一个成熟的参考模式。它支持层级化的命名空间结构如/strategy/{memoryStrategyId}/actor/{actorId}/session/{sessionId}允许开发者根据业务需求灵活定义记忆的隔离边界和共享范围这种设计已经在多租户场景和企业级应用中得到验证。Skill管理OpenClaw实现图4如图4所示在OpenClaw中Skills技能是扩展Agent能力的核心机制。开发者可以将外部API、本地脚本或工具能力封装为技能并在任务执行过程中由Agent动态调用。从实现上看OpenClaw的技能系统主要由声明式定义多来源加载渐进式披露动态注入四部分组成。声明式定义首先在定义层面每个技能以目录为单位组织并通过SKILL.md文件进行声明。该文件采用YAMLMarkdown的结构YAML部分用于描述技能元数据如名称、描述、依赖条件、安装方式等Markdown部分则提供更详细的使用说明。这种设计既方便机器解析也利于在Prompt中直接使用。多来源加载其次在加载机制上OpenClaw支持多来源技能并按照优先级进行合并与覆盖Workspace Skills工作区级优先级最高Managed Skills全局共享Bundled Skills内置技能Extra Directories扩展目录这种分层设计既支持项目级定制也支持全局复用。在技能可用性判断方面系统会根据运行环境对技能进行评估例如操作系统匹配、依赖是否存在、环境变量是否满足等并根据metadata.openclaw.install中定义的方式自动完成安装。渐进式披露机制为了避免一次性加载所有技能描述导致上下文膨胀OpenClaw采用了三层渐进式披露策略Level 1-元数据通常~100 Tokens启动时加载所有技能的name和descriptionAgent据此决定激活哪项技能。Level 2-指令通常5k Tokens技能被激活时加载完整的SKILL.md正文。Level 3-资源按需仅在执行过程中需要时加载引用文件、脚本和资产。这种设计使得Agent可以配置大量技能而不会压垮上下文窗口。动态注入与快照在运行阶段技能并不会直接作为“函数调用”存在而是会被转换为Prompt片段注入到Agent上下文中包括技能描述用于模型理解能力范围使用方式说明必要的环境信息此外OpenClaw在会话开始时会对技能进行Snapshot快照固定当前会话的技能集合和状态从而保证多轮对话的一致性。这种设计避免了技能在对话过程中发生变化带来的不确定性。AI Agent应用优化措施从OpenClaw的实现可以看出Skill管理的核心问题并不在“如何定义技能”而在于如何在正确的时机让模型看到“正确数量的技能信息”。从系统架构角度看Skill管理可以进一步拆解为四个层次的问题Selection选择哪些技能避免加载过多无关技能。Injection如何注入技能信息控制Prompt中的Token开销。Execution如何执行技能优化调用成本与延迟。Governance如何管理技能支持多租户与权限隔离。技能检索与按需加载核心目标避免将所有技能一次性注入上下文而是只加载与当前任务相关的技能。常见优化方式基于语义的技能检索将技能描述向量化根据用户意图匹配最相关技能。任务驱动选择结合当前任务类型或意图分类筛选技能。技能分级区分“核心技能”和“扩展技能”仅默认加载高频技能。譬如Amazon Agent Registry正是为解决这一问题而设计的集中式发现服务。Amazon Agent Registry是一个完全托管的发现服务提供集中式目录来组织、把关和发现组织内的资源用于管理企业内的Agent、tools、skills、MCP servers和自定义资源。它提供以下能力混合搜索能力结合语义理解和关键词匹配支持自然语言查询如“帮我找一个可以分析日志的工具”和精确名称查找。MCP原生访问Registry本身提供MCP端点AI Agent可以直接调用Registry进行技能搜索实现真正的“按需发现”。灵活的组织方式支持按资源类型agent registry、MCP server registry、skill registry、开发阶段production、QA、development或团队/业务单元创建多个注册表实现精细化的技能分类和检索。Agent在运行时可以基于这些元数据进行筛选和选择从而实现“按需发现”而不是在启动阶段加载所有技能。这种设计将技能选择从Prompt层前移到系统层提高了扩展性和可控性。Prompt注入优化与渐进式披露在多数Agent框架中Skill并不是“被调用”而是“被描述”。这意味着Skill的真正成本在Prompt而不是执行。优化重点1.渐进式披露如OpenClaw所示采用元数据→指令→资源的三层加载模式在启动时仅加载约100 Tokens的元数据技能激活时加载5k Tokens的完整指令执行时按需加载资源文件。采用渐进式暴露通常可将技能描述的Token消耗从平均15k降低至3-5k。2.技能描述压缩只保留能力边界和关键用法避免冗余说明。3.Token预算管理元数据层控制在100 Tokens以内。指令层控制在5k Tokens约500行以内。超过此限制的内容应拆分到references/目录作为按需加载的资源。4.去重与合并避免多个技能描述重复表达相同能力。技能组织与多租户管理在多用户、多项目场景下技能管理需要解决“隔离与共享”的核心问题。从架构层面来看技能的组织通常分为三个层级用户级技能User scope服务于个人的特定需求和工作习惯。项目级技能Project scope在团队内部共享以提升协作效率。全局技能Global scope则作为组织的通用能力基础供所有用户使用。这种分层结构需要通过命名空间或层级目录来实现确保不同范围的技能既能保持隔离性又能在需要时被灵活复用。在实际的企业级AI Agent应用中这种技能管理的职责主要由Agent框架层来承担。以OpenClaw为例它通过workspace-level skills、global skills和bundled skills的三层加载机制实现了技能的灵活组织和按需加载。用户可以在自己的工作空间中定义个性化的技能团队可以在项目目录中共享协作所需的技能而系统级的通用技能则被安装在全局路径供所有用户访问。总结和展望本文以OpenClaw为例集中介绍了在AI Agent应用中如何通过优化可观测性、记忆管理和Skill管理来减少OpenClaw的Token浪费从而缓解成本压力。总而言之Memory和Skill本质上都是Token的“消费者”而Token监控是所有优化策略的最终反馈闭环。但正如前文所述的AgentModelHarness除了这三个部分Harness还有很多核心功能需要坚实的数据基础配合。本系列后续文章将逐一深入探讨在可观测性、记忆管理和Skill管理方面的亚马逊云科技最佳实践不仅包括亚马逊云科技托管服务的解决方案也包括第三方或者自建解决方案的要点。此外后续还会探讨Harness其他的核心功能以及如何打造坚实的数据基座来实现这些功能敬请期待亚马逊云科技2026创新实践日来啦全球专家领衔解码Agentic AI时代的数据基石扫码下方海报二维码即刻报名参与4月22日·上海4月24日·北京13:00-17:30与您不见不散左滑查看更多精彩内容新用户注册海外区域账户可获得最高200美元服务抵扣金覆盖Amazon Bedrock生成式AI相关服务。“免费计划”账户类型确保零花费安心试用。星标不迷路开发更极速关注后记得星标「亚马逊云开发者」听说点完下面4个按钮就不会碰到bug了