取之有度，用之有节-从Harness视角破解Agent应用Token爆炸难题

摘要：Data for AI系列blog第一篇，以爆火的OpenClaw为例，解析Token爆炸根因，深入研究OpenClaw记忆和Skill管理机制的实现，给出AI Agent如何通过优化可观测性，记忆和Skill管理从而减少Token浪费的方法论，最终实现降本增效的目的

01 一、OpenClaw的流行与Token爆炸

02 二、Harness视角下的解决方案

03 三、总结和展望

一、OpenClaw的流行与Token爆炸

1.1. OpenClaw的流行

最近大家见面免不了都要问一句：你养龙虾了吗？这里的“龙虾”，指的正是近期爆火的开源AI Agent框架 OpenClaw。自2025年11月发布以来， OpenClaw在GitHub上已经获得了超过35万星标和超过7万fork（2026年4月数据），成为2026年初最受人关注的AI Agent项目之一。OpenClaw的出现让构建复杂 AI Agent 变得前所未有的简单：

从“只会说”到“能动手”‌

与传统聊天AI（如ChatGPT）不同，OpenClaw能够直接操作计算机系统‌：整理文件、发邮件、写代码、运行程序，真正实现“AI替你干活”‌

‌极低的使用门槛‌

用户通过微信、飞书等日常聊天工具即可指挥它，无需编程基础，部署只需复制一行命令，极大降低了AI智能体的使用门槛‌

强大的可扩展能力

OpenClaw支持通过新增技能、优化记忆和调整Prompt来不断提升能力。在持续使用过程中，结合记忆积累与技能扩展，可以实现“越用越好用”的效果”

‌开源生态快速扩张‌

ClawHub技能商店聚集超1.3万个插件，覆盖办公、编程、智能家居等场景，开发者用Markdown即可贡献技能，生态呈指数级增长‌

但随着越来越多的企业和个人开始大量使用 OpenClaw，一个令人头疼的问题逐渐浮出水面：Token 爆炸。根据OpenRouter ，在3月16日至22日这一周，中国模型共记录了7.36万亿个Token，比前一周增长了56.9%。

其实，Token消耗暴增并不是OpenClaw独有的问题，所有AI Agent应用从实验室到生产环境都要面临这一拦路虎。接下来，我们将以OpenClaw为例讨论一下Token爆炸的问题。首先，我们看一下OpenClaw的架构：

1.2. 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：从高层次来看，运行时在每一轮对话中执行四件事:

解析会话，当消息到达时，运行时首先确定应该由哪个会话处理它。
组装上下文，一旦会话被解析，运行时就会为模型组装上下文，组装好的上下文随后被流式传输到配置的模型提供商(Anthropic Claude、OpenAI GPT、Google Gemini或者本地模型)。
流式调用模型并执行工具调用，当模型响应时，运行时会监视工具调用并拦截它们。每个工具结果都会被流式传回到正在进行的模型生成中，模型将其整合并继续。
将更新的状态持久化到磁盘，对话轮次完成后，运行时将更新的会话状态(消息、工具调用/结果以及任何其他跟踪的状态)持久化回磁盘。

从上面的架构中我们可以看出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.ts， src/agents/openclaw-tools.ts）— bash、浏览器、文件操作、画布和核心能力
插件工具（通过 api.registerTool(toolName， toolDefinition) 注册）— 通过扩展系统添加的自定义工具

基础系统

Pi Agent Core — 来自 Agent 运行时库的基础指令

1.3. Token爆炸的常见原因

对于AI Agent来说，造成Token爆炸的常见原因有：

第一类爆炸：注入型爆炸

也就是“先全部塞进去，再让模型自己判断”。这类爆炸最常见于：

技能太多，缺少前置召回
长期记忆太长，缺少按需注入
中间状态太杂，缺少上下文裁剪

表面上看，是模型 Token 用多了。实际上看，是没有在模型调用之前，先用数据层把无关内容挡在门外。

第二类爆炸：重复型爆炸

也就是“本来记住了，但系统不会复用”。这类爆炸最常见于：

明明上轮已经找过这个知识点，这轮又重新搜一遍
明明某个 skill 调用路径已经稳定，还是每次从零选择
明明用户偏好和业务上下文之前就存在，这次又重新推理一遍

这类成本非常隐蔽，因为它不像一次超长 prompt 那么刺眼。它更像水龙头没关严，一天一滴，看账单时才发现地板已经泡烂了。

第三类爆炸：黑盒型爆炸

这是企业最怕的一种。不是花了钱，而是不知道钱为什么花掉。我们需要：

调了几个 skills
哪一步用了大模型，哪一步只是检索
memory 命中了没有
命中失败是 recall 问题、索引问题还是上下文策略问题
真正贵的是首轮决策，还是中间重试

如果这些都看不见，优化就无从谈起。

二、Harness视角下的解决方案

有一个历史故事很契合这个场景，隋末瓦岗军攻占洛口仓向百姓散粮却缺乏管理，百姓皆至无限制取粮，路上往往背不动又抛弃，导致从仓城到郭门的路上米粮堆积如白沙，被车马践踏，造成极大浪费。最终，瓦岗军因为粗疏的管理，并没有充分发挥洛口仓丰富仓储的优势而落败。本质上，这种“资源无序消耗”与Agent系统中的Token浪费高度类似。Token 爆炸并不是因为模型不够聪明，需要太多上下文才能理解任务，而是因为缺乏高效的运行时资源管理方法。

正如Vivek Trivedy 在《The Anatomy of an Agent Harness》中说的那样，Agent = Model + Harness。除了Model其他所有的部分都属于Harness，包括各种代码，配置和执行逻辑等等。其实Token所有问题都可以归结为：

推理花多少（Token），计算预算
信息进多少（Memory），上下文供给
能力暴露多少（Skill），能力调用

那么接下来我们继续以OpenClaw作为典型示例，分析一下如何监控Token消耗，如何通过管理上下文和Skills来减少Token浪费。

2.1. Token消耗监控

2.1.1 OpenClaw实现

在当前版本的 OpenClaw中，系统已经具备了一定程度的 Token 使用可见性，但整体仍停留在较为基础的层面。OpenClaw可以通过状态查询命令（如 /status）展示最近一次模型调用的 input/output Token 数量以及预估成本，同时也提供了对上下文窗口占用情况的查看能力，使开发者能够大致感知当前 prompt 的规模。这些能力本质上依赖于底层模型（如 OpenAI、Anthropic 或 Amazon Bedrock）返回的 usage 数据。

然而，这类监控能力本质上属于”结果展示”，而非”过程观测”。系统并不会对 Token 消耗进行结构化记录，也缺乏跨会话、跨任务的统计分析能力。例如，session 持久化中虽然保存了完整对话历史和Token使用数据，但这些数据缺乏结构化的分析能力，无法支持跨会话、跨任务的统计分析和趋势洞察。

更关键的问题在于，OpenClaw当前缺乏对 Agent 执行链路的细粒度追踪能力。在一次完整的任务执行过程中，Token 消耗可能分散在多个阶段：Prompt 构建、记忆检索、技能注入、工具调用以及多轮推理循环中。但系统无法回答诸如”哪一个阶段消耗最多 Token”或”某个 Skill 是否导致上下文膨胀”等关键问题。这使得优化工作往往只能依赖经验，而缺乏数据支撑。

更进一步，OpenClaw也尚未提供 Token 预算管理机制。例如，无法为单个任务或用户设置 Token 上限，也缺乏在预算超限时自动降级模型、裁剪上下文或提前终止执行的能力。

2.1.2 AI Agent应用优化措施

在优化方向上，一个直观的思路是引入云厂商提供的可观测性能力。例如，当 OpenClaw运行在 Amazon Bedrock 之上时，可以借助其原生的 CloudWatch 指标（如 InputTokenCount、OutputTokenCount、TimeToFirstToken 等）对模型调用进行监控。此外，通过将调用日志写入 CloudWatch Logs 或 Timestream，也可以实现对 Token 消耗的时序分析和热点定位。

进一步地，Bedrock AgentCore Observability 提供了一种更高层次的观测能力。它可以对一次完整的 Agent 调用进行拆解，展示执行过程中的多个步骤，并记录每一步对应的模型调用次数、延迟以及 Token 使用情况。这种能力已经从”单次模型调用”提升到了”任务级执行链路”，能够帮助开发者理解一个复杂任务在宏观层面的资源消耗结构。

但需要注意的是，即便是 AgentCore Observability，其可见性仍然存在边界。它能够观测”调用了多少次模型”，却无法洞察”Prompt 是如何构建的”。例如，系统仍无法直接得知某一轮对话中，Skill 描述、记忆片段或系统提示词各自占用了多少 Token。这意味着，在进行精细化优化（如裁剪无效上下文或压缩技能描述）时，仍然需要在 Agent Runtime 内部引入额外的埋点与追踪机制。

从工程角度来看，一个完整的 Token 可观测体系应当覆盖三个层级：模型调用层（LLM usage）、Agent 执行层（任务/步骤级 tracing）以及 Prompt 构建层（上下文组成分析）。当前 OpenClaw已经具备第一层能力，引入 Bedrock AgentCore 可以补足第二层，而真正决定优化深度的第三层，仍然需要在框架内部实现。

换句话说，OpenClaw当前可以回答”花了多少 Token”，Bedrock AgentCore 可以回答”在哪些步骤花了 Token”，而真正决定优化空间的问题是：”这些 Token 究竟是被 Skill 描述、记忆片段，还是系统提示词消耗掉的？”

2.2. 记忆管理

2.2.1 OpenClaw实现

[图3]

如图3所示，OpenClaw的记忆管理系统以本地文件（Markdown）+ SQLite索引为核心，存储和管理历史会话的记忆内容，并结合向量嵌入（Vector Embedding）和全文检索（FTS）来提升检索效率。其记忆管理策略包括以下几个关键部分：

1. MemoryIndexManager：记忆状态的中枢

OpenClaw通过MemoryIndexManager来跟踪和管理记忆状态。所有会话历史和任务相关的内容都被存储为Markdown文件，并通过SQLite数据库进行索引。MemoryIndexManager负责索引构建、向量生成、检索调度等核心逻辑，是整个记忆系统的执行中枢。这套系统通过插件注册机制实现了良好的扩展性:

registerMemoryRuntime：定义索引和检索的核心逻辑
registerMemoryEmbeddingProvider：添加新的嵌入模型（如OpenAI、本地Llama、Bedrock等）
registerMemoryFlushPlanResolver：确定何时持久化或压缩记忆

系统支持多种嵌入提供商（如本地模型、OpenAI、Google Gemini、Amazon Bedrock和Mistral），并通过插件机制注册，在运行时选择可用Provider。

2. 混合搜索：语义与关键词的协同

OpenClaw采用了混合搜索(Hybrid Search)策略，结合了向量搜索和传统的全文检索技术。这种设计使得系统能够在不同场景下提供更高效、更相关的结果：

向量搜索：系统通过memory_search工具计算查询Embedding与chunks_vec表中向量数据之间的余弦相似度，选择语义上最相关的记忆项
全文搜索(FTS5)：当需要通过关键词匹配历史记忆时，系统使用memory_get工具配合FTS5进行查找。FTS5采用BM25算法为搜索结果打分，这对于查找特定标识符或精确信息非常有效
混合评分：使用加权组合公式 Score = (VectorWeight × VectorScore) + (FtsWeight × FtsScore)，平衡语义理解和关键词匹配
时间衰减：结果可以根据时间进行衰减，优先考虑最近的上下文

这种混合检索机制本质上是在“语义召回”和“精确匹配”之间做权衡，以提升不同查询类型下的稳定性。

3. 记忆同步与更新机制

OpenClaw实现了一套完善的同步机制，确保索引数据的实时性和一致性：

文件监听：系统通过chokidar文件监听库检测memory/目录的变化，确保对记忆库的变动能及时更新
会话同步：监听AgentMessage事件，当会话的消息数达到一定的增量阈值时触发增量更新操作。在活跃聊天期间，系统会对更新进行防抖处理
原子性重建索引：在临时文件中构建新索引，完成后进行原子性交换，防止索引损坏
定时同步：除了实时同步外，系统还会定期进行记忆同步，确保外部更新能够在预定时间内反映到记忆数据库中

4. Dreaming系统：短期到长期的记忆提升

OpenClaw的一个独特特性是其后台”做梦”(Dreaming)机制，这是一个记忆整合过程，模拟了人类记忆的巩固过程，自动将重要的短期记忆转化为长期知识（存储在MEMORY.md中）。本质上，这一机制将“是否被频繁使用”作为信号，实现了一种自动化的记忆重要性排序与长期化过程：

Light Sleep（浅睡眠）：频繁扫描，识别候选记忆并记录”回忆”次数
REM Sleep（深度睡眠）：更深层的整合过程，基于频率和相关性对候选记忆打分
提升评分机制：使用加权公式，综合考虑频率（检索次数）、相关性（语义得分）和多样性（唯一查询数）

2.2.2 AI Agent应用优化措施

通过OpenClaw的例子我们可以看到要减少Token浪费，记忆管理至关重要。对于AI Agent应用来说，以下是几个可能的改进点：

1. 分层记忆架构与记忆策略

核心原则：区分不同时间尺度和重要性级别的记忆，并根据内容类型选择合适的记忆策略。

分层设计：

短期记忆层：仅包括当前会话和最近几轮对话，保持即时上下文的连贯性
长期记忆层：全局知识库，包含经过验证的重要信息和用户偏好

每个层级的记忆可以按需加载，避免无关的记忆内容影响当前任务。同时，采用滑动窗口机制防止对话上下文无限增长：系统仅保持最近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提供了多种内置记忆策略，包括SemanticMemoryStrategy、SummaryMemoryStrategy、UserPreferenceMemoryStrategy和EpisodicMemoryStrategy，每种策略针对不同类型的信息提取进行了优化。

2. 上下文工程与动态加载

核心原则：通过内容优化和加载策略的双重手段，最大化记忆的价值密度，最小化Token消耗。

内容优化策略：

语义去重：在索引和检索阶段进行语义去重，确保相同或高度相似的记忆不被多次加载到上下文中。可以通过向量相似度阈值来识别重复内容
信息摘要：使用对话总结将长对话压缩为短文本，保留关键信息。例如，将一段10轮的技术讨论压缩为”用户询问了关于X技术的Y问题，最终确定使用Z方案”
分层摘要：对不同时间尺度的记忆采用不同粒度的摘要。近期记忆保留更多细节，远期记忆仅保留核心要点

加载策略：

按需加载：根据任务的复杂度、当前上下文窗口的剩余空间以及记忆的相关性得分，动态决定加载多少记忆内容。简单查询可能只需要1-2条记忆，而复杂任务可能需要10+条
上下文预算管理：为记忆检索设置Token预算，确保记忆内容不会挤占任务执行所需的上下文空间
动态清理：在任务完成后自动清理不再需要的短期记忆，释放资源。对于长期未被访问的记忆，可以降低其优先级或进行归档
过期机制：为记忆设置时效性标记，对于时间敏感的信息（如”本周的会议安排”），在过期后自动降低其检索权重

上下文工程（Context Engineering）强调根据任务需求动态组织信息。系统应该实现”智能调度”功能，决定何时从记忆中检索信息、如何组织和呈现给LLM。

譬如Bedrock AgentCore的Summary策略展示了内容优化的实践：系统可以自动生成会话摘要，将冗长的对话历史压缩为简洁的要点，在保留关键信息的同时大幅减少Token消耗。

3. 向量存储选型与扩展

核心原则：根据规模和性能需求，选择合适的向量存储方案。

实施策略：

个人使用场景：当AI Agent用于个人使用，数据量小且没有跨用户数据检索的需求时，SQLite和S3 Vectors都可以满足需求且成本较低，提供快速原型验证能力。其中SQLite适合本地开发和小规模部署，而S3 Vectors有更好的持久性和扩展上限。
大规模客户使用场景：当AI Agent面对大量客户时，如果每个客户只需要检索自身数据，希望数据完全隔离，且成本敏感，可以选择S3 Vectors；如果客户的数据之间需要共享，且对响应时间有要求，可以考虑使用专业化向量数据库，例如Aurora PostgreSQL或Amazon OpenSearch Service，并通过Serverless来节省成本应对负载波动。

需要权衡本地化部署的便利性和云端服务的性能优势。可以采用可插拔的存储后端设计，让用户根据场景选择合适的方案。

4. 命名空间管理与跨会话共享

核心原则：通过层级化的命名空间结构，支持不同粒度的记忆隔离和共享，可实现跨设备或跨实例的记忆同步，减少重复检索。

实施策略：

命名空间组织：引入层级化的命名空间结构，支持不同粒度的记忆隔离和共享。例如：
- 用户级命名空间：存储特定用户的偏好和历史
- 项目级命名空间：存储特定项目的上下文和知识
- 全局命名空间：存储通用知识和常见问题解答
跨会话记忆共享：允许在不同任务或会话之间共享有价值的记忆，尤其是对于常见的基础信息或已验证的知识。这样可以避免每次重新加载相同的信息，减少Token消耗。
云存储与记忆同步：对于需要跨设备或跨实例共享记忆的场景，可以通过AWS的S3、DynamoDB或其他存储方案实现记忆的云端同步。通过缓存机制减少对远程存储的请求频次，平衡性能和一致性。

譬如Bedrock AgentCore Memory的命名空间组织方式提供了一个成熟的参考模式。它支持层级化的命名空间结构（如/strategy/{memoryStrategyId}/actor/{actorId}/session/{sessionId}），允许开发者根据业务需求灵活定义记忆的隔离边界和共享范围。这种设计已经在多租户场景和企业级应用中得到验证。

2.3. Skill管理

2.3.1 OpenClaw实现

[图4]

如图4所示，在OpenClaw中，Skills（技能）是扩展Agent能力的核心机制。开发者可以将外部API、本地脚本或工具能力封装为技能，并在任务执行过程中由Agent动态调用。从实现上看，OpenClaw的技能系统主要由声明式定义 + 多来源加载 + 渐进式披露 + 动态注入四部分组成。

1. 声明式定义

首先，在定义层面，每个技能以目录为单位组织，并通过SKILL.md文件进行声明。该文件采用YAML + Markdown的结构：YAML部分用于描述技能元数据（如名称、描述、依赖条件、安装方式等），Markdown部分则提供更详细的使用说明。这种设计既方便机器解析，也利于在Prompt中直接使用。

2. 多来源加载

其次，在加载机制上，OpenClaw支持多来源技能，并按照优先级进行合并与覆盖：

Workspace Skills（工作区级，优先级最高）
Managed Skills（全局共享）
Bundled Skills（内置技能）
Extra Directories（扩展目录）

这种分层设计既支持项目级定制，也支持全局复用。在技能可用性判断方面，系统会根据运行环境对技能进行评估，例如操作系统匹配、依赖是否存在、环境变量是否满足等，并根据metadata.openclaw.install中定义的方式自动完成安装。

3. 渐进式披露机制

为了避免一次性加载所有技能描述导致上下文膨胀，OpenClaw采用了三层渐进式披露策略：

Level 1 – 元数据（通常~100 Tokens）：启动时加载所有技能的name和description，Agent据此决定激活哪个技能
Level 2 – 指令（通常<5k Tokens）：技能被激活时加载完整的SKILL.md正文
Level 3+ – 资源（按需）：仅在执行过程中需要时加载引用文件、脚本和资产

这种设计使得Agent可以配置大量技能而不会压垮上下文窗口。

4. 动态注入与快照

在运行阶段，技能并不会直接作为”函数调用”存在，而是会被转换为Prompt片段注入到Agent上下文中，包括：

技能描述（用于模型理解能力范围）
使用方式说明
必要的环境信息

此外，OpenClaw在会话开始时会对技能进行Snapshot（快照），固定当前会话的技能集合和状态，从而保证多轮对话的一致性。这种设计避免了技能在对话过程中发生变化带来的不确定性。

2.3.2 AI Agent应用优化措施

从OpenClaw的实现可以看出，Skill管理的核心问题并不在”如何定义技能”，而在于：如何在正确的时机，让模型看到”正确数量的技能信息”。

从系统架构角度看，Skill 管理可以进一步拆解为四个层次的问题：

Selection（选择哪些技能）：避免加载过多无关技能
Injection（如何注入技能信息）：控制Prompt中的Token开销
Execution（如何执行技能）：优化调用成本与延迟
Governance（如何管理技能）：支持多租户与权限隔离

1. 技能检索与按需加载

核心目标：避免将所有技能一次性注入上下文，而是只加载与当前任务相关的技能。

常见优化方式：

基于语义的技能检索：将技能描述向量化，根据用户意图匹配最相关技能
任务驱动选择：结合当前任务类型或意图分类筛选技能
技能分级：区分”核心技能”和”扩展技能”，仅默认加载高频技能

譬如AWS Agent Registry正是为解决这一问题而设计的集中式发现服务。AWS Agent Registry 是一个完全托管的发现服务，提供集中式目录来组织、把关和发现组织内的资源,用于管理企业内的agents、tools、skills、MCP servers和自定义资源。它提供：

混合搜索能力：结合语义理解和关键词匹配，支持自然语言查询（如”帮我找一个可以分析日志的工具”）和精确名称查找
MCP原生访问：Registry本身提供MCP端点，AI agents可以直接调用Registry进行技能搜索，实现真正的”按需发现”
灵活的组织方式：支持按资源类型（agent registry、MCP server registry、skill registry）、开发阶段（production、QA、development）或团队/业务单元创建多个注册表，实现精细化的技能分类和检索

Agent 在运行时可以基于这些元数据进行筛选和选择，从而实现“按需发现”，而不是在启动阶段加载所有技能。这种设计将技能选择从 Prompt 层前移到系统层，提高了扩展性和可控性。

2. Prompt注入优化与渐进式披露

在多数Agent框架中，Skill并不是”被调用”，而是”被描述”。这意味着：Skill的真正成本在Prompt，而不是执行。

优化重点：

渐进式披露：如OpenClaw所示，采用元数据→指令→资源的三层加载模式，在启动时仅加载约100 Tokens的元数据，技能激活时加载<5k Tokens的完整指令，执行时按需加载资源文件。采用渐进式暴露，通常可将技能描述的Token消耗从平均15k降低至3-5k。
技能描述压缩：只保留能力边界和关键用法，避免冗余说明
Token预算管理：
- 元数据层控制在~100 Tokens以内
- 指令层控制在<5k Tokens（约500行）以内
- 超过此限制的内容应拆分到references/目录作为按需加载的资源
去重与合并：避免多个技能描述重复表达相同能力

3. 技能组织与多租户管理

在多用户、多项目场景下，技能管理需要解决”隔离与共享”的核心问题。从架构层面来看，技能的组织通常分为三个层级：

用户级技能（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监控是所有优化策略的最终反馈闭环。

但就像我们说的Agent = Model + Harness，除了这三个部分，Harness还有很多核心功能需要坚实的数据基础配合。本系列后续文章将逐一深入探讨在可观测性，记忆管理和Skill管理方面On AWS的最佳实践，不仅仅包括AWS托管服务的解决方案也包括第三方或者自建解决方案的要点。此外，我们还会探讨Harness其他的核心功能以及如何打造坚实的数据基座来实现这些功能，欢迎大家阅读。

➡️ 下一步行动：

相关产品：

Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
Amazon Bedrock AgentCore — 加快代理投入生产的速度
Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
Amazon S3 Vectors — 云原生向量存储
Amazon OpenSearch — 搜索和分析引擎

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客