# 取之有度，用之有节-破解 Agentic 应用 Token 爆炸难题 > **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 > > **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/ > > **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。 ## 一、基础信息 - **会议类型**：专题演讲 - **Persona**：数据团队 - **时间信息**：6月23日 | 14:00 - 14:30 - **标题**：取之有度，用之有节-破解 Agentic 应用 Token 爆炸难题 - **PDF 资料**：有 - **视频回放**：有 ## 演讲人信息 ### 会议信息 - **地点**：上海世博中心（2026 亚马逊云科技中国峰会） - **日期**：2026年6月23日（Day 1） - **时间**：14:00 - 14:30 - **会议类型**：专题演讲 - **面向 Persona**：数据团队 ### 亚马逊云科技演讲人 - **吕琳**：亚马逊云科技数据专家架构师技术负责人 ### 客户 / 合作伙伴演讲人 - **于超**（聚云科技）：售前技术总监 ## 二、会议资料 PDF 转录内容 --- Page 1 --- 2026年6月23日-24日 上海·世博中心 --- Page 2 --- 取之有度，用之有节-破解 Agentic 应用 Token 爆炸难题 吕琳 于超 亚马逊云科技 数据专家架构师技术负责人 聚云科技 售前技术总监 --- Page 3 --- 今天你养龙虾了吗？ OpenClaw 为什么会成为 带来一个新的问题： Token 爆炸 2026年最火爆的 AI Agent 项目？ 实验环境到生产的拦路虎 ➢ 从“只会说”到“能动手” ➢ 极低的使用门槛 ➢ 强大的可扩展能力 Token ➢ 开源生态快速扩张 --- Page 4 --- OpenClaw 核心组件 1. Channel Adapters：将不同消息平台的差异抽象化， 提供统一的消息接口，可以对接不同消息平台。 2. Control Interfaces:提供多种方式与 Gateway 交互方 式 3. Gateway Control Plane：消息路由中心，更是安全边 界、状态管理器和协调者的统一体。 4. Agent Runtime: • 解析会话。 • 组装上下文 • 流式调用模型并执行工具调用 • 将更新的状态持久化到磁盘 --- Page 5 --- OpenClaw System Prompt --- Page 6 --- 常见的 Token 爆炸原因 黑盒型爆炸 重复型爆炸 注入型爆炸 — — — 可观测性 记忆管理 Skill 管理 --- Page 7 --- OpenClaw 的记忆管理系统以本地文件（Markdown） - SQLite 索引为核心，并结合向量嵌入（Vector Embedding）和全文检索（FTS）来提升检索效率。 ➢ MemoryIndexManager ➢ 混合搜索 ➢ 记忆同步与更新机制 ➢ Dreaming 系统 OpenClaw 如何管理记忆 --- Page 8 --- AI Agent 的记忆管理最佳实践 分层记忆和记忆策略 上下文工程和动态加载 向量存储选型 命名空间和跨会话共享 --- Page 9 --- 多种向量存储适配不同场景 Amazon Aurora Neptune Elasticache/ DynamoDB OpenSearch S3 Vectors PostgreSQL Analytics MemDB 适用场景： 适用场景： 适用场景： 适用场景： 适用场景： 适用场景： 高并发键值存储场景， 需混合搜索（语义+关键 大规模向量归档（PB 级）、 熟悉 PG 技术栈、需要混 GraphRAG 应用、需要 实时推荐、语义缓存、高 支持毫秒级读写和无缝 词）、大规模向量数据、 成本敏感型 AI 应用、冷 合查询（向量+结构化数 可解释性的 AI 推理 并发向量搜索（万级 QPS） 扩展 已有 Elasticsearch 技术 数据存储 据）、多租户 SaaS 应用 栈 特点： 特点： 特点： 特点： 特点： ▪ 图原生推理 ▪ 极致低延迟 ▪ 毫秒级响应延迟 特点： ▪ 超低存储成本 ▪ PostgreSQL 生态兼容 ▪ 超高性能 ▪ 实时索引更新 ▪ 无服务器自动扩展 ▪ 混合检索能力 ▪ 多租户强隔离&无限 ▪ 统一数据模型 ▪ 一体化查询 ▪ 显著成本节约 ▪ 全托管键值存储 ▪ 丰富分析功能 扩展 ▪ 企业级可靠性 ▪ 极致成本优化 ▪ 混合架构集成（AOS） 多态融合的全景 Serverless 数据底座，实现按需使用与自动驾驶级的弹性免运维 --- Page 10 --- S3 Vectors 空间隔离 性能隔离 安全隔离 每个索引提供独立的向量维度 目前已知的服务上限（尤其是 每个 index 都有独立的 ARN （dimension）和向量空间距离 向量的注入和查询）都是按每 （distance）配置 索引来设置的上限 每个 index 可以单独配置 IAM policy 控制每个 API 的权限 每个索引可以单独配置 SSE 索引和索引之间性能相互独立 （S3/KMS）的加密方式 （通过内部程序已验证）， 可 横向扩展 --- Page 11 --- S3 Vectors 数据源： text/images/videos 通过模型生成 embeddings CLI/SDK 插入到 S3 vector index Amazon NovaMME Nova 示例架构 相似性检索 Amazon S3 NovaMME + S3 Vectors Top-k results Vectors 查询输入： search 将查询条件转为 vector 相似性搜索 text/image/video embeddings Amazon NovaMME Nova --- Page 12 --- AgentCore Memory: 构建具有上下文感知的 Agent 简化记忆系统管理 企业级安全 深度定制化 • 只需几行代码即可存储和检索 • 在基于命名空间 (Namespaces) • 通过跨 Session 和 跨 Agent 的短 记忆。 的加密存储中，按用户、项目 期和长期记忆功能，实现行业 或业务单元划分内存。 • 自动完成向量嵌入、存储、记 领先的准确性。 忆整合和反思过程。 • 在安全的 VPC 环境中，保持数 • 支持 [1] 使用预定义的提取策 据隔离且易于检索。 略，或 [2] 使用任何模型创建 自定义逻辑。 --- Page 13 --- OpenClaw 如何管理 Skill 在 OpenClaw 中，Skills（技能）是扩展 Agent 能力的核心机制。从实现上看，OpenClaw 的技能系统主要包 括： 声明式定义 通过多来源加载 渐进式 payload 动态注入和快照 --- Page 14 --- AI Agent 的 Skill 管理最佳实践 技能检索 技能组织 渐进式 和 和 payload 按需加载 多租户管理 --- Page 15 --- 技能按需召回：告别“Token 刺客” 痛点：“填鸭式” Token 消耗巨大 解法：动态技能智能路由 50+ -> Top-N Skills Skill 1 Skill 2 Skill 3 Skill 4 企业 Agent 挂载 50+ Skill 2 Skills，每次提问全量注 向量 LLM 入所有工具说明 用户提问 Skill 5 语义路由 Skill 5 Skill 6 Skill 7 Skill 8 → API 账单爆炸 Skill 18 → 更长的 Prompt 拖慢 大模型响应 Skill 9 Skill 10 Skill 11 ...50+ 只挑出最相关的 Top-N Skills 喂给模型 成效：又快又省 ~90% ~50 ms 3-5 Token 节省 缓存命中延迟 精准 Skill 匹配 提示词消耗从~2000 锐减至~200 运行时透明拦截，用户完全无感 告别 50+ Skill 盲目全量注入 --- Page 16 --- Amazon Agent Registry：在整个组织中发现、管理和 重用 Agent、Tool、Skills 所有 Agent 的统一平台 查找已存在的内容 管理发布内容 • 统一管理：所有 Agent、Tool、MCP • 混合搜索：关键词过滤和语义搜 • 审批工作流：草稿 → 待审批 → 已审 Server 和 Skills 的单一可信数据源— 索支持自然语言查询 批，之后 Agent 才可被发现 —无论它们在何处构建或托管 • 多方式：可通过 AgentCore 控制 • 完整的生命周期跟踪：包括版本控 • 统一注册：通过指向 MCP 或 A2A 台、API 以及作为来自 Kiro、 制、弃用和审批流程钩子 Endpoint 进行注册，或通过控制台 Claude Code 的 MCP Server • IAM 访问控制：管理谁可以注册、 、SDK 或 API 手动注册 • OAuth 支持：让团队无需 IAM 凭 发现和使用 • 协议灵活：原生支持 MCP 和 A2A, 证即可构建自定义发现 UI 具有灵活的自定义架构 --- Page 17 --- OpenClaw 的可观测性 缺乏执行链路 基础层面 单纯 细粒度 /status 查询 结果展示 追踪能力 --- Page 18 --- AgentCore Observability:全面掌握 Agent 性能 状况 支持与您自选的各类 确保质量与可信度 加速产品上市时间 可观测性工具进行集成 • 全面掌握所有 AgentCore 服务 • 通过实时控制面板集中显示 Agent • 兼容 OTEL 的遥测技术可与 的 Agent 执行情况与运营指标 的运行状况和性能，以加快问题 多种可观测性工具集成，包括 解决速度 CloudWatch、Dynatrace、 • 加速调试和质量审计 Datadog、Arize Phoenix、 • 只需极简的可观测性基础设施配置 • 快速检测问题并评估性能趋势 LangSmith 和 Langfuse • 通过在 Agent 追踪信息中加入自定 • 充分利用现有的可观测性 义属性和元数据，使其与业务成果 技术栈 的关联更为紧密 --- Page 19 --- AgentCore Observability 1 2 3 Runtime AgentCore 使用 AgentCore 也支持使用第三方可观 （可选）启用 Evaluations Observability 收集 AI 测性工具收集 AI AgentCore 可观测 Agent 执行轨迹 的执行 trace. 性服务级 trace 2 1 L Framework E T T O O D P A AgentCore Observability 控制面 3 AI Agent Telemetry 板 Service Telemetry AgentCore Observability Automatic AgentCore Memory linking of AI Agent & Service AgentCore Identity generated OTEL AgentCore Gateway 3 第三方可观测性控制面板 AgentCoreBrowser & Code Interpreter 适用于任何框架、工具和运行时环境 AI Agent Telemetry --- Page 20 --- AgentCore Evaluations：基于真实世界性能提升 Agent 质量 实时质量智能 自定义业务评分 无基础设施开销 • 使用13个内置评估器对实时交 • 使用自定义评估器为特定用例构 • 从 Amazon CloudWatch 中可用 互进行采样和评分 建定制的质量评估。 的日志进行开箱即用的评 估。 • 从真实世界用户行为中获得可 • 查看各种粒度级别（整个 Trace、 操作的洞察，持续改进智能体 最终响应、单个步骤）。 • 消除构建基础设施和管理运营 性能。 复杂性所需的数月工作。 • 提供按需 (On-Demand) 和在线 评估 (Online) 两种评估模式 --- Page 21 --- 企业 人 业务产出 AI 成熟度等级： 1。试点 2。生产 3。规模化 业务价值 衡量标准 Agents • 能否及时有质量完成工作 专用 Agents 通用 Agents 作为"数字员工"为公司工作 • 成本是否合理 （业务/垂直领域） （如软件开发、客户交互中心、知识工作者） Agentic 平台 Agent 所需的通用环境、工 运行环境 记忆 工具（浏览器） 工具（代码运行） MCP 网关 技能 多 Agent 协同 具、规则、评估、治理等必 能否支持成百上千个 Agents 的开发、部署、管理、迭代 规则 评测 可观测性 安全 治理 … 要组件 安全 数据和知识 效果 • 检索准确性 为 Agent 提供相关数据 • 数据新鲜度 RAG 向量数据库 知识库 数据管道 • 覆盖范围 性能 模型 成本 • 智能水平 Claude GPT Gemini Grok Nova 以 API 调用方式为 Agents 提 • 速度 供"智能服务" • 成本 Seed Qwen GLM DeepSeek MiMo … • 上下文窗口 AI 基础设施 • 吞吐量 GPUs AI 专用芯片 为模型推理提供算力 • 每小时成本（初始采购成本、能 源效率） • 可靠性 --- Page 22 --- 从 OpenClaw 到 EasyClaw: 理论如何变成真实运行的客服 Agent --- Page 23 --- 客服，是 AI 员工最好的第一岗位 四个天然条件，让客服成为 Agent 落地风险最低、价值最快显现的场景 --- Page 24 --- 龙虾客服运行架构 六层架构：OpenClaw 理论在客服场景的完整落地 --- Page 25 --- 知识库不是文档仓库，是客服上岗手册 Bedrock KB + OpenSearch 如何让龙虾客服做到不越界、不乱答 --- Page 26 --- 风险收口 + 人机协同：Agent 的边界与成长 好的客服 Agent，知道什么时候该回答，什么时候该让人来 --- Page 27 --- 取之有度，用之有节：龙虾客服如何控制 Token 不把所有知识、历史和工具说明塞进 Prompt，而是按当前问题动态取用 --- Page 28 --- 典型案例 EasyClaw.work 龙虾管家，我们自己的龙虾客户实践 2 众人调教 1 深夜解答 --- Page 29 --- Thank you ## 三、会议回放视频转录内容 呃大家好那个我是吕琳很高兴的和于超一起跟大家分享一下这个取之有度，用之有节如何破解这个 Agentic 应用他的 Token 爆炸难题 那这里面我先调研一下就是2026 年最火的我们都知道是这个 OpenClaw 对吧那谁装过龙虾或者说在生产环境当中用过龙虾的 那举一下手看一下 ok 谢谢对其实大家都知道我们龙虾呢用你的这个这种的消息媒体对吧然后呢他从只会说到能动手 然后使用的门槛很低然后也很火爆像龙虾 GitHub 呢他这个都已经超过1.3万的各种的插件覆盖我们各种的场景 但是呢大家知道三月份中间呢 其实一周之间他的 token 消耗就增加了50% 以上 其实呢当从龙虾从这个实验环境到生产我们都会面临这个 Token 爆炸的这个问题 所以今天呢我们就拿这个龙虾来做比喻看一下龙虾是怎么来实践然后减少这个 Token 消耗的 那么龙虾呢大家都知道它的主要的一些组件呢比如说 Channel Adapters 是我们的消息的这种接入然后呢比如说我们的这个 interface 那么我们可以通过 命令行 CLI 或者 UI 与这个 Gateway 去做各种的交互然后 Gateway 的 Control Plane 呢那么如果接到我们的消息之后 他进行路由分发 agent 呢帮助来做执行然后来拼接上下文然后最后呢来执行这种任务 那么他这里呢我们会说到那么其实我们说到这个话题 token 消耗那么主要就是我们在组装这种 system Prompt 那么 system Prompt 都会包括什么呢 比如说会包括 AGENTS.md 为点 那么这里面直接明确 你的 Agent 允许去做什么 还有 SOUL.md 那么这里面直接就告诉你说那么应该用什么样的语气 应该用什么样的方式来回答我 那么还有各种的工具 那么中间有一部分是我们重点要关注的就是上下文 那么这个动态的上下文呢 会包括一方面短期的你前后几轮的对话 还有些长期的啊 比如说一些倾向啊 一些爱好啊 一些信息 然后呢 还有你各种各样的 skill 那其实这一部分是我们真正要关注的 那么其实呢 我们看到所有的这个 AI 的应用呢 那么都会看到说啊 一般来说总结起来 token 消耗呢 有三种 那么一种呢 就是所谓黑盒型爆炸 就说我们其实监控只能看到一个结果 上线前 我们可能 token 就一万上线之后直接就变成十万 那这里面我根本就不知道他到底消耗在哪儿 我是 Skill 用错啊 还是说 没有命中那个记忆 对吧 这些都是看不到的 那么这种说明什么 你的可观测性不行 那么你可观测性不行的时候 你就没法去优化他 然后第二种呢 就是当然是重复型爆炸 也就是说呢 本来这个别人已经告诉过你了 但是呢 你记不住 所以呢 每次都要客户跟这个大模型去交互重复的信息 这样会浪费 token 那么这样呢 就需要你有好的记忆管理 那么第三个呢 就是注入型爆炸 那刚才我们说这个我们这个 Skill 有很多啊 那么一个公司的 Skill 都基本上上千 那我干脆把所有的 Skill 都扔给这个 让大模型替我去选 可不可以 可以 但是这样无疑会消耗你的 token 其实你应该有更好的 Skill 管理 所以今天呢 我们就看看 从这三点上 那么 OpenClaw 是怎么做的 然后进而推出我们的最佳实践 那么首先对于记忆来说 我们 OpenClaw 它的方法 我们都知道 他主要是靠 Markdown 文件 Markdown 文件呢 那么里面记忆物理位置外 还有 SQLite 也就是说 我主要的存储是在 Markdown 文件 但是我用 SQLite 做我的索引对这些文件做索引 那么 SQLite 呢 保证我可以有向量的索引 也就是向量检索能力 同时也有全文检索能力 然后呢 我来做权重 这样的话呢 它平衡你的语义理解和精确召回之间的权重 对吧 那么同时呢 他在这里面 就你在跟他去说的时候 那么你说一定内容 达到阈值 它会做一次记忆 如果你说不说 到时间 他也会做触发记忆 或者说你有任何的文件的变更 他同样会有记忆 那么这些记忆有一些是短期的 那有一些是长期的 他们有一个 Dreaming 体系 也就是说一种模拟人类睡眠 像这种浅睡眠期 他就会频繁的扫描 然后标注你问到的这些信息 然后到深度睡眠的时候呢 我就会过一段时间 然后综合这一段时间的标注 然后决定哪些信息 进到我们的这些长期记忆中 所以大家可以看到 这个就推出来说 我们在一个 AI Agent 的记忆管理的时候 我们需要注意的点 第一 一定要分层 而且还有记忆策略 那么分层指的是什么 短期记忆 也就是说我们前后几轮的一些对话 然后呢 长期记忆呢 是从短期记忆中提取有价值的信息 那对于我们的这些 我们的记忆策略 我们可以拿到人的语义的记忆 比如说一些事实 比如说我们这里面说 我比较喜欢 Python 这个语言 或者说我这个项目是用的什么数据库 对吧 那这些信息要有 然后呢 还有用户的偏好 比如说我喜欢你跟我回答客气点 对吧 那么这些都是你所谓的语义的记忆的策略 然后呢 我们有上下文工程和动态加载 也就是说呢 我们在这个上下文工程 我们在做的时候 我们会要做到语义去重 也就是说重复说的 那我应该过滤掉 不应该让他进去 对吧 然后信息摘要 比如说我很长的一段话 可能我中间问了他很多问题 最后我可能就总结一句话 他对这个不懂 对吧 他希望我告诉他这个答案 那么然后呢 那么我们在这里面要分层做摘要 比如说我们短期记忆可能一开始会记得更详细一些 然后到长期的记忆的时候 我们会更精简一些 那么然后加载的时候 同样要做按需加载 我不会一股脑子都加载进来 对吧 比如说他要去旅游的时候 我可能就是相关的他的这种衣着啊 或者有旅游的风格啊 这些信息 我把它加载进来 但是他的编程的一些偏好 我是不需要把它加载进来的 对吧 然后呢 会有动态的清理的机制 也就是说 你的这里面短期记忆 你要把它清出去 对吧 那么然后向量选型待会我们会详细的说 然后最后一个呢 命名空间和跨会话共享这一点经常被大家忽视 其实是很重要的 也就说你想如果说我们一个公司的人进来的话 那如果没有会话共享会怎么样 一个新员工进来之后 他所有比如说我们公司的规章制度这些东西 那他每个人都要上传一遍 每个人都要学一遍 对吧 但是如果说这种有跨会话共享的话 那么我直接就可以共享这些信息 同样在编程的习惯上 如果说我能共享这些信息的话 那我在不同的项目当中 我也可以知道这个人的编程偏好 那么在这里面 其实我们可以看到 在托管的这个向量存储亚马逊云科技上有很多 那么比如说 如果说我喜欢全文检索加向量检索 那我可能会选 OpenSearch 如果有图数据库 然后再加上这个向量检索 我可能会 Neptune 然后呢 比如说如果说我这里关系数据库很熟 我可能会托用 PostgreSQL 那么这里面呢 其实待会大家如果有空的 可以移步到我们的 Data 的这个 Booth 上面 大家可以看到这么多数据库 会专门有一个 Skill 让大家可以去提问 大家可以把您使用的场景性能和成本的要求 说给这个模型听 然后呢 模型用这个 Skill 它能选择一款正确的存储 那比如说 大家可以想见 说如果我是一个这个多媒体的这么一个公司 然后呢 这个人忽然想说 我看一看以前 比如说比较空旷的这种摄影 那这个时候 他说出这句话的时候 第一个 大家可以想见一定是多模态检索 对吧 但是需要注意的什么 你有成千上万客户 每个客户当说这句话的时候 我也许只需要看我自己之前拍过的照片或者视频 我不希望别人看到 我也不希望看到别人 对吧 这叫好比说每个人都有一个自己的衣柜 我不希望跟别人共用 那这种的时候 我需要把你的空间做隔离 我把你的权限都给 我把你的性能做隔离 那这种的时候 这种 S3 Vectors 就是很好的案例 那么 S3 Vectors 在一个 vector bucket 里面 他可以建一万个索引 在一个账号下面 可以建一万个桶 也就是说你什么都不调 一个账号下面 可以去起一个 这个我们的向量索引 每个人都有自己的这种向量索引 那这样的话呢 他只需要 比如说我再次拍个照片或者视频 我一旦上传到 S3 它就会触发一个事件 然后做 embedding 然后就写入到我们的 S3 Vectors 那么后续的话 他如果用语言去查询我的视频 或者图片 这就是一个典型的多模态检索的场景 对吧 直接访问这 S3 Vectors 这样的话 你会发现 2C 的时候 如果说要求权限隔离 然后空间隔离 没有比 S3 Vectors 更好的 而且他的成本真的很低 对吧 那么刚才我们说那么多 那我们记忆管理给我们说 要分层 然后要空间 然后我们有各种策略 那么其实 AgentCore Memory 他都可以实现 对吧 你只要几行代码 你就可以存储 然后去提取你的这个记忆 而且呢 我在这个过程中 那么有各种的安全都帮你考虑到 那么如果你认为我们定制化的 这些策略不好 你还可以用你自己喜欢的模型和这种方式策略 然后去自定义 也就是说你用 AgentCore 来做这件事情 那可能就事半功倍 那么我们接下来说一下这个 skill 的管理 那么 skill 的管理 那么在这个 OpenClaw 的 skill 上 他是通过 YAML 文件加上 Markdown 来做的 那么在这里 他会有多个来源 来去检索 也就是他也有全局的 然后也有这个 workspace 的 那么同时在做渐进式 payload 就说这点很重要 当他 Skill 这么多的时候 他第一次只去载入 name 和它的描述 然后当你的 Skill 被选中的时候 他才会载入它的指引集 然后当你真的这个 Skill 被使用的时候 相关的 resource 才会加载进去 而且在这个过程中 他会留下它的快照信息 什么叫快照信息 就是你一旦进去跟他交互的时候 他这会对这个 skill 打一个快照 那么这段时间内 你的 skill 再变化 他还是用原来的 所以说 大家会看到 就是这个 OpenClaw 的 skill 做得很好 你就会发现我们要做的时候 也是应该这样去实现 首先你的技能检索 应该是渐进式 payload 的 然后你应该是按需使用的 另外还需要按组织分层 大家可以想见 对于我一个销售岗位 或者说我是一个研发岗 对吧 那我一个新员工入职的时候 如果说我能够按照我的岗位 本身就相关的 Skill 我就不需要自己去构建这个 skill 对吧 我直接继承就好了 在这里面 比如说你这种的 用这种方式去做的话 你可能原来的50多个 Skill 都放给大模型 让他去选 那么现在可能直接就拿到 token 这样的话 不但节省了 token 而且速度也会快很多 那当然在这个过程中 其实像我们这个 AgentCore Bedrock 这里面照样的会有 Agent Registry 那么 Registry 就是专门在统一的平台上 注册你相关的 Tools/MCP 或者 skills 而且在这个过程中 他会帮你去做各种的权限的管控 而且最妙的是 他会有审核机制 也就是说哪些 skill 或者哪些 mcp 可以被大家所看到 那么你可以去控制 对吧 那么最后一个 是 OpenClaw 的可观测性 其实这方面 OpenClaw 做的比较差 因为它这块基本就是/status 命令的输出 也就是说你看到的只是一些结果 那么它只能告诉你说 token 确实消耗 但是你缺乏执行链路的观测的能力 你不知道到底怎么消耗掉 那在这里 如果我们要去构建应用的话 那么我们通过这个 AgentCore 可观测性 你可以看到 它在这里 我们直接用这种托管的 feature 它会在里面直接打出来 这个 OpenTelemetry 兼容的 那么大家都知道 Agent 的应用的时候跟以前的应用不一样 以前应用我们之后 用 CloudWatch 直接看 200 有多少 然后404 的报错有多少 对吧 你只要给200 的基本就肯定对 但是模型是不一样的 那么这个 AI 我虽然给你返回了 但是对不对 是否正确你是需要判断的 或者说你的提示词变了 它的效果怎么样 你也是需要判断的 那这些呢 像比如说 LangSmith 或者 Langfuse 那么都是用来 我们做这种延迟的全链路监控的 那么现在这里用这个 AgentCore 可观测性 同样可以做到这一点 因为它是 OpenTelemetry 兼容的这种数据源 也可以用你现在所有的工具都可以用 那么在这个过程中 我们还有 AgentCore Evaluations 那么它这里面有13个内置的 我们这种 Agent 的评估器 它不断的在评估 它不断的在评估 然后在这个过程中 那么我不需要去做任何设置 然后它就会判断你返回来的模型的情况 到底是好 还是坏 然后接下来这个过程中 如果说你觉得需要用你自己自定义的模型 自定义的策略也没有问题 对吧 那这样的话 它和以前的这种工具就完全不一样 你会发现我们一方面打出来之后 可观测性放到 OpenClaw 的方式 用传统的方式 可以看到你是不是在健康运行 那么我可以看到 比如说我可以看到它的调用次数 然后成功的次数 然后等等这些监控都有 同时我还有全量的追踪 对吧 那我在这个过程中 可以对模型的效果进行评估 然后对模型 我们在运行的时候 比如说改个提示词的模板 那是不是对你的结果有不好的影响 这些我们都可以判断 对吧 所以说 如果说你用传统的 OpenClaw 这方面确实比较弱 对吧 但是如果用我们的这个 AgentCore 的这些 feature 去构建你的应用 你就会发现这个事情还是那句话 事半功倍 所以呢 我在这里呢 就是我们刚才说的这个部分呢 主要集中在 token 的消耗 这个五层架构呢 大家应该都已经很熟了 其实我们没有提到说 Data 这个部分 应该怎么来提高准确率等等这些 那么这些的部分 其实在其他的赛道都会提到 那总之一句话 就我们 Data 是我们 AI 的数据的基座 对吧 AI 的这个应用好不好 很大程度上是由数据来决定的 那么下面就请于超来帮我们介绍一下 那么他们公司在 OpenClaw 上的一些实践 谢谢大家 谢谢吕老师 好大家好 和吕老师跟那个吕老师一场去讲一讲 我们这个对于数据和 Agent 的这些理解 刚刚吕老师从前面的 OpenClaw 的整个架构出发 然后分享一下他本身的一些设计的架构 以及他原本做的不足的这些地方呢 怎么样通过我们的 AgentCore 来去做一些补充 尤其是对于大家自己在开发这种 Agent 的应用的时候 应该怎么做 所以呢 我会从这里面我介绍几个信息 就是 Agent 在这个生产环境里面 他其实在用的用的很容易呢 会遇到几个挑战 简单说就是他的 memory 可能会越来越多 他的 skill 也会越来越多 他的 knowledge 也会越来越多 那最终带来了就是这种 token 的这种失控 所以接下来我会用一个案例 就是把我们自己的一些实践 看看是不是可以验证 无论是 OpenClaw 上面去做这个事情也好 还是我们自己去构建一个 Agent 的应用也好 这些在真实业务的时候能成立 我们其实应该是在2月份吧 算是业内作为 AWS Partner 第一个 基于 OpenClaw 的理论 或者开源的产品 然后推出了一个面向企业的商业化平台 我们叫 EasyClaw 那么并且把它用在自己的一个 产品的智能客服上面 我们叫龙虾管家 那么他服务的至少当时已经是上万的 这样用户的规模 而且要7×24小时的在线 并且他的工作环境主要在一个飞书群里面 要并发的服务 然后还要保证他长期稳定运行 在这个过程中 我们最大的感受是什么 真正一个 agent 他能否从 Demo 走向生产的 已经不是模型参数了 而是他需要的数据能不能被有效的组织 有效的获取 还有效的治理 Agent 的能力确实是来自模型 但 Agent 的生产力 它恰恰来自数据 所以接下来我用这个案例来看 它是怎么落地的 先说一下为什么选择这个智能客服 作为今天地产的一个分享的典型的生产场景 其实刚把吕老师分享的理论 他讲到了 memory 讲到的技能库等等的 因此到真实业务里面 客服它恰好是一个 最容易验证 agent 的价值的岗位 因为它有这种 首先大量这种高频重复的问题 它还有这种明确的边界 去问一些产品价格规格 这些政策 它都是有据可依的 而且它需要这种跨系统的协同 就是我们现在接待的这种智能的客服 它肯定不是简单的去回复客户的问题 而是要和它后续的会员 订单等等这些去联动 然后它也有非常清晰的风险的边界 所以客服它验证的 不是说现在的模型有多聪明 而是它的 knowledge 能不能被准确地找到 它的 memory 能不能被准确地使用 还有它 Skill 能不能按需求调用 以及风险 高关度的风险 是不是可以被有效地治理 换句话说就是 客服的场景 其实也是验证 agent 的数据体系 是不是成熟了一个比较好的实验场 好 这也是我们龙虾客服的整体架构 其实从用户视角它是比较简单的 就是用户来提问 那 agent 就回答嘛 但实际上在后台中间会经历这一系列的动态 拆解的过程 首先看一个用户 它通过飞书或者企微 或者是可能业务会有自己的 app 一些自建的通道 我们发起这些请求 那这个 EasyClaw 的软件 它就会先去做这种意图的识别 然后去做这种风险的判断 再根据当前的一个问题来动态的决定 我需要哪些知识 我是否需要读取哪些记忆 再调用哪些技能 那这里最关键的其实就是 能否根据当前的这个问题 来去有效组织它最需要的数据 所以先说在知识层这一块 有些后面会单独一页去讲 我们在开始的时候 也是拿它文件直接就做 但是发现越来越多的 越来越多之后 东西越来越多 我们就改用了 Amazon Bedrock Knowledge Bases 再接到 OpenSearch 的这种方案来重新 去接进去 作为龙虾它的知识检索的体系 那在记忆上 我们复用了 OpenClaw 它现在的这种有短期 Memory 我要去保证当前的会话 然后长期 Memory 我会去保证它的客户的偏好 比如说是不是我们的 VIP 客户 高额度的充值客户 然后它历史工单是什么 它之前来咨询过什么问题 这个人的习惯 风格是什么样子 是不是特别着急 一分钟不回 它马上就骂人了 对吧 所以在技能这一层 前面讲到的像 CRM 然后还有些工单 我们都会用这种 Skill 的形式来挂接 那在需要的时候 它才会加载 最后会通过一个 可观测的平台 我们延伸出来 来去看这个 token 的 使用的全链路 到底怎么观测的 因为我们在衡量客服的龙虾 能不能正常工作的时候 我们虽然已经用了一个新的解法 但是我们还是会用一些 数据指标去验证 可用性什么 能问延时性 扩展性等等 比如说你的服务时长 我会根据这个客户 到底跟你沟通了几轮来看看 到底它是不是这个龙虾 有没有从一开始就理解了意图 快速回答问题 还是阻碍又多 最后甚至导致这种升级 才能解决问题 或者说甚至有人工介入 好 那整个过程 其实围绕了一个目标 就是让 agent 只获得 当前这个问题所需要的数据 那好 那我们现在讲一下 知识库这部分 其实大家可能自己过去 做一些 RAG 的一些应用的时候 就会有可能会有一个误区 就是那知识库 我就把所有的文档都丢进去就行了 但客服团队 那显然不是这样子 因为客服它真的需要的是什么 它不是说 我要一下子回答这个问题 要拥有所有的知识 而是我在最短的时间 我要找到最可信的答案 那所以我们在知识这里面 我们也把它拆了一个分成 第一层是 FAQ 就是高频的问题 我直接去返回标准的答案好了 第二层是 SOP 就是我明确描述哪些话能说 哪些话不能说 第三层就在 Update 了 就是把我最新的这种应用政策 或者产品信息 我要放进去 我要覆盖这个旧的知识 那第四层也是我们后面扩展的 就是 Case 就是把历史这种工单 我也作为经验的知识 我要沉淀下来 所以如果大家稍微观察一下 就会发现 这好像就像培养一个客服员工一样 对 你 FAQ 它是一个标准单 然后 SOP 它是一个工作指引 那 Update 其实就是公司最新的通知 那 Case 它其实是这种老员工的经验 那右边是整个知识处理的链路 其实这个比较常见 就是把文档各种拆分丢进去之后 我要去做 chunk 我要做 embedding 的处理 我要对我听过 听通过这个 chunk 这样的小模型去做向量化 对吧 对我去做混合检索 一直到通过 KB 来完成这个 完成这个知识的编排和召回 那从而还是为了解决 让 agent 它找到这种正确的答案 而不是让我们看起来是 它在生成一个好像合理的答案 好 那解决知识库的问题 对吧 我们就来看第二个重要的问题 很多人认为就是优秀的 agent 它应该是能够回答所有的问题 但是恰恰我们通过实践 认为这个刚好相反 就是优秀的 agent 它其实知道什么时候不回答 比如说在价格争议啊 或者说这种投诉升级的时候 那这种高风险的场景 那就得让人去转人工嘛 那如果是知识召回的置信度不够 agent 应该明确的告诉用户 这个不确定 应该找人工 而不是自己去编一个答案 那如果是涉及这种退款 或者说审批啊这种比较明确的业务动作 虽然你的那个 skill 已经让它足够去 具备这种执行的能力了 但也建议去经过人工来去确认一下 所以这样做的好处是什么样 就是当把握风险这一方面了 更重要是学习 因为每一次转人工 它其实本质 它不是说它这时候就失败了 而是它在为这个 agent 的创造这种 新的高质量的训练的样本 所以右边这个进化机制里面就看到 就是我们的人工处理沉淀出的优质的答案 我会重新的反哺到知识体系里面去 所以这个 agent 它不是一次性训练出来的 而是在这个真实业务里面不断迭代出来的 我们在整个陪跑过程中 除了我们让我们的龙虾去服务到一个小型的圈子 我们其实有两个区 一个就是它把问题解决不了 丢给到我们的人类这个客服里面去处理 这个问题解决不了 你直接去看一看 还有一个就是我们的调教群 我们把这个产品专家 还有客服专家拉进去 不断地更新 以及根据龙虾的反馈来调教 给它灌入新的知识 让它不断地成长 好 很多那个 agent 的项目 其实在 POC 阶段都表现得很好 但是上线之后就突然全面陷入一拖再拖的成本困境 成本迅速失控 大概是 应该是前期做的时候 一开始就 就把所有的知识 所有的历史记录 还有的 skill 说明 一股脑的塞进去 这个塞到 Prompt 里面去 这样导致 Prompt 就越来越长 然后那个响应越来越慢 成本自然就越来越高 我们有了足够的时间 那就发现 这个 token 的控制 其实不是做减法 我没有减少它的知识 只是说 我们减少了这种无效的知识 它塞到模型里面去 那应该让这个 agent 的学会像人一样 就是 我不需要的时候我就不看 然后呢 如果需要我才去查 所以 当用户提问之后 我就希望做这种意图的这个识别 再去动态的决定 你召回哪些知识啊 你要读哪些记忆啊 加载哪些 skill 啊 最后 来组装出当前这个问题 最小的这种有效的上下文 所以 这跟吕老师前面讲 这个 memory 的动态的加载 skill 的安全的召回啊 还有这个上下文工程 其实是一个道理 因此呢 这个 token 的爆炸 其实本质上它不是这个模型的问题 而是数据治理的问题 真正控制的方式 它就不是这种 少给模型信息 而是在正确的时间 给正确的信息 这是我们理解这个 取之有度 用之有节 那最后用我们的那个 龙虾管家做一个总结啊 其实龙虾管家本身 它不是今天我们 我们要分享重点啊 我们 只是把它做一个验证场 我们真正验证的是什么呢 就是当我的 memory 我可以分层管理啊 knowledge 我也可以 精准召回的时候 还有这个 skill 可以做到按需加载 还有这个 Observability 呢 它是可以持续治理的时候 那这个 agent 就有机会 真正进到这种生产环境啊 所以过去一年我们 越来越相信一件事情 就是未来这种企业之间竞争了 它不会只是模型啊 就是模型因为 因为它越来越普及嘛 对真正拉开差距的是什么 是这种企业管理数据的这种能力 就是谁能去 把更好的组织好你的那个 knowledge 啊 就更好地去呈现你的 memory 然后呢去更好的调动的一堆的 skill 然后做好这个 agent 的治理啊 就能够更快的把的 agent 的 从这个 demo 啊 用到这个就是变成了生产力 所以既然我在这里对中 想分享想表达的是怎么样 就是 agent 的时代里面 其实数据啊不是燃料 而是 agent 它能不能规模化落地 规模化落地的一个基础设施啊 好 谢谢大家