尧图网页设计 
人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk点击查看免费下载导读本文围绕 0011-context-strategy.md 这篇跨 SDK 设计文档展开剖析 Strands SDKPython 与 TypeScript如何通过一个统一的contextManager/context_manager参数把上下文管理从零散的手工插件组合收敛为auto与agentic两种开箱即用的策略预设。你将理解 L0上下文窗口/ L1会话历史/ L2长期记忆三级缓存层级、v1 已交付与 v2 提议的组件拆分、conversationManager的迁移路径以及 L1 存储模型批量写入、游标、归档与删除的底层设计。文中所有结论均有对应源码佐证并给出可直接落地的配置示例。1. 问题背景20% 与 80% 的差距任何有一定规模的 Agent 最终都会撞上上下文长度上限。Strands 此前已经提供了处理这一问题的积木外部化externalization、压缩compression、会话管理器conversation manager、钩子hooks——但这些是彼此独立的扩展点用户需要自己去发现、配置并组装。设计文档 0011-context-strategy.md 指出这造成了一个典型的 20%/80% 缺口20% 场景追求完全控制的资深用户愿意手动组合所有扩展点80% 场景只想让上下文管理开箱即用的普通开发者。随着上下文管理能力不断增多每个新特性都意味着又一个需要接线wire up的插件或工具缺口只会越来越大。项目在 TENETS.md 中主张显而易见的路就是快乐路径the obvious path to be the happy path以及简单的事情就该简单simple things to be simple。因此本设计的核心结论是上下文管理应该是一行配置one-liner而不是一次组合练习composition exercise。方案落点是一个位于Agent构造函数上的contextManager参数——它背后依然是资深用户手动配置的那套扩展点只是把合理的选择为其余用户预先做好了。2. 缓存层级一切操作都是层级间的搬运设计文档将上下文管理映射为一个三级缓存层级见 0011-context-strategy.md 第 2 节每一次上下文操作本质上都是层级之间的数据移动层级是什么访问成本由什么支撑L0 — 上下文窗口agent.messages模型每次请求所见的内容可能包含摘要原消息已被驱逐零已在上下文中内存消息列表L1 — 会话历史消息的追加式append-only日志仅在存在消费者agentic 模式或memoryManager时才会写入每次摘要前批量写入低检索工具调用ContextManager存储FileStorage、S3Storage等L2 — 长期记忆跨会话知识——归档记忆、语义搜索索引、学到的事实超越当前会话持久存在较高查询 从持久化存储加载Memory 原语、向量存储、托管记忆服务需要明确本设计文档的边界本设计覆盖L0 ↔ L1会话内上下文管理L2长期记忆是独立原语memoryManager超出本文范围在本设计的视角下L1 在会话生命周期内是追加式且不可变的工具结果缓存tool result cache是独立的——短生命周期、自动驱逐且不可变与 L1 不同。L1 的存储内部细节见 Appendix EL1 存储模型。3. 策略预设谁控制 L0contextManager参数接受一个策略strategy它决定了谁控制 L0——哪些内容留在上下文窗口、何时压缩到 L1见 0011-context-strategy.md 第 3 节。两种策略共享同一套基础设施当上下文压力累积时压缩 L0超大工具结果被单独缓存retrieveToolResult始终可用让 Agent 无需推理上下文即可恢复被截断的输出。二者的核心区别auto框架与内容交互agenticAgent主动推理自身的上下文状态。逻辑住在插件里而不是工具里。工具只是面向 Agent 的、对插件方法的包装。在 auto 模式下框架通过钩子调用插件方法例如阈值触发时执行ContextCompression.compress()在 agentic 模式下同样的钩子仍然作为安全网触发但同时也注册了工具让 Agent 可以主动调用同样的方法。策略决定的是暴露哪些工具——而不是存在哪些逻辑。3.1 两种策略的能力矩阵能力autoagentic框架在阈值命中时压缩YesYes框架缓存超大工具结果YesYesAgent 可恢复被截断的工具输出YesretrieveToolResultYesAgent 可主动触发压缩NoYescompressContextAgent 可保护消息免于驱逐NoYespinMessageAgent 可读取 L1NoYesgetHistoryAgent 可搜索 L1NoYessearchHistoryAgent 可生成上下文感知的子 AgentNoYesdelegateWithContextAgent 可查看自己的上下文预算NoYesgetContextBudget3.2auto—— 框架决定框架透明地管理 L0当上下文压力累积时L0 中的消息被摘要化或丢弃。auto 模式下不会产生任何 L1 写入——只有当存在消费者agentic 模式或memoryManager时 L1 才会被写入。Agent 甚至感知不到上下文管理正在发生——它只是永远不会撞墙。唯一暴露的工具是用于恢复截断输出的retrieveToolResult。适用场景还不想思考上下文的初学者可预测性比自主性更重要的生产部署大规模、成本敏感的工作负载需要轻量、免维护上下文管理的多 Agent 系统任何只要别出问题的人。3.3agentic—— Agent 决定注意agentic目前是实验性的依赖模型是否能有效使用上下文管理工具这一研究结论。auto先行发布并是主要关注点。auto所做的一切仍然会发生——Agent额外获得主动管理自身 L0 的工具。它可以决定何时压缩、保护什么免于驱逐、以及在 L1 中浏览被驱逐的消息。适用场景能从上下文状态的自省中获益的研究型 Agent 和编码助手长时运行的自主 Agent以 Agent 自主性为核心目标的探索式开发多 Agent 编排中的父 Agent。3.4 成长与所有权随着上下文管理能力演进更多策略可能被加入。遵循 TENETS.md 中的 pay-for-play按需付费原则Strands 团队拥有这些预设并保留对其做破坏性变更的权利——预设内部解析成什么哪些插件、哪些默认值可能随版本变化需要稳定性的用户应该直接配置插件而不是依赖预设的内部实现所有预设配置的默认值阈值、策略、token 限制必须由基准测试benchmarking数据驱动任何默认值都不应仅凭直觉设定。4. v1已交付contextManager: auto作为可选项v1 以**可选项opt-in**的形式交付contextManager: autoPython 侧为context_managerauto。在 v1 中contextManager只接受字符串值autoAgent 直接将输入解析为插件和一个会话管理器不经过中间类。ContextManager类负责 token 估算、预算、游标在 v2 中才引入供需要生命周期钩子或直接存储访问的资深用户使用。默认值是undefined/None即不启用上下文管理——这样升级不会造成意外也给了项目时间去验证行为可靠后再设为默认。4.1 v1 接线了哪些组件组件作用基准验证的默认值ContextOffloader通过AfterToolCallEvent钩子把超大工具结果缓存在内存中短生命周期、自动驱逐。Agent 看到截断预览。提供retrieve_offloaded_content工具按需访问。v2 中更名为ToolResultCache配置键从contextOffloader改为toolResultCachemaxResultTokens1500previewTokens750SummarizingConversationManagerBeforeModelCallEvent钩子检查 L0 token 用量是否超过阈值超过则摘要化 L0 中较旧的消息summaryRatio0.3compressionThreshold0.85上述默认值在本仓库的实现中得到了印证Python harness 的 agent.py 中定义了_AUTO_MAX_RESULT_TOKENS 1_500与_AUTO_PREVIEW_TOKENS 750并据此构造 offloaderagent.pyTypeScript harness 的 agent.ts 中durableOffloader()同样以maxResultTokens: AUTO_MAX_RESULT_TOKENS、previewTokens: AUTO_PREVIEW_TOKENS实例化ContextOffloader。4.2 与conversationManager共存v1 尊重用户自带的会话管理器当用户提供了自己的会话管理器时用它替代默认的SummarizingConversationManageroffloader 无论如何都会被加上。// 使用默认的 SummarizingConversationManager 主动压缩 const agent new Agent({ contextManager: auto }); // 使用用户自己的会话管理器offloader 仍然会被添加 const agent new Agent({ contextManager: auto, conversationManager: new SlidingWindowConversationManager({ windowSize: 20 }), });# 使用默认的 SummarizingConversationManager 主动压缩 agent Agent(modelmodel, context_managerauto) # 使用用户自己的会话管理器offloader 仍然会被添加 agent Agent(modelmodel, context_managerauto, conversation_managerSlidingWindowConversationManager(window_size20))两条额外规则如果用户插件列表中已经有一个ContextOffloader它不会被覆盖本仓库中 harness 通过hasOffloader(plugins)检测plugins.some((p) p instanceof ContextOffloader)见 agent.ts 与 agent.py有状态模型stateful models会同时拒绝contextManager和conversationManager——它们自己管理服务端的会话状态。4.3 存储注意事项v1 的 offloader 使用InMemoryStorage——内容不会跨进程重启持久化。使用sessionManager且需要持久化 offloaded 内容的 Agent应通过plugins参数提供带持久化存储的显式ContextOffloader。作为对比本仓库的 harness SDK 在启用会话时会把 offloaded 产物落盘到会话目录${sessionDir}/offloaded无会话时落在一次性临时目录见 agent.ts这是 harness 层对持久化 offloader的落地实现。5. v2提议三项变更v2 提议三项变更见 0011-context-strategy.md 第 5 节auto成为默认——每个 Agent 默认获得上下文管理除非显式退出agentic交付——Agent 参与上下文管理conversationManager被弃用——其压缩职责移交ContextCompression。5.1 插件分解每个插件承担单一内聚职责。ContextManager不是插件——它是配置解析后得到的顶层类拥有共享基础设施存储、token 估算、预算跟踪、游标并组合下面这些插件。插件从ContextManager读取数据而不是彼此依赖组件角色领域工具模式ContextManager配置解析器 共享基础设施存储、token 估算、预算、游标getContextBudgetagentic始终ToolResultCache插件缓存超大工具结果retrieveToolResult两种ContextCompression插件L0 写入——压缩、钉住pinningcompressContext、pinMessageagentic两种ContextNavigation插件从 L1会话历史读取getHistory、searchHistory仅 agenticContextDelegation插件上下文感知的子 Agent 生成delegateWithContext仅 agenticv2 还引入了OnContextOverflowEvent——一个在上下文长度错误时触发的新生命周期事件取代会话管理器中不透明的重试逻辑。SDK 已经把所有 provider 的此类错误归一化为ContextWindowOverflowError——这个事件只是把该错误暴露给插件。5.2conversationManager弃用路径v2 中ContextCompression接管了压缩和 L1 写入会话管理器不再有事可做。弃用分三步走v1共存两者并行存在无冲突v2弃用发出弃用警告若两者都设置了contextManager优先v3移除conversationManager从构造函数类型中移除。迁移对照表Appendix DconversationManager今天contextManager等价写法new SlidingWindowConversationManager(){ compression: { strategy: truncate } }new SummarizingConversationManager(){ compression: { strategy: summarize } }NullConversationManagerfalse自定义子类{ compression: { strategy: customFn } }6. 设计文档附录完整配置与代码示例6.1 v1 代码示例v1 — auto 最小配置import { Agent } from strands-agents/sdk; const agent new Agent({ contextManager: auto, tools: [shell, fileRead], });from strands import Agent agent Agent(modelmodel, context_managerauto, tools[shell, file_read])v1 — auto 用户自己的会话管理器import { Agent } from strands-agents/sdk; const agent new Agent({ contextManager: auto, conversationManager: new SummarizingConversationManager(), tools: [shell, fileRead], });from strands import Agent from strands.agent.conversation_manager import SummarizingConversationManager agent Agent(modelmodel, context_managerauto, conversation_managerSummarizingConversationManager(), tools[shell, file_read])6.2 v2 代码示例v2 — 默认无需任何配置import { Agent } from strands-agents/sdk; const agent new Agent({ tools: [shell, fileRead], }); // 上下文管理默认开启。SandboxStorage auto 策略。v2 — 自定义存储import { Agent } from strands-agents/sdk; import { S3Storage } from strands-agents/storage-s3; const agent new Agent({ contextManager: { storage: new S3Storage({ bucket: my-session }), strategy: auto, compression: { threshold: 0.8, protectedMessages: 2 }, }, tools: [shell, fileRead], });v2 — Agentic 模式import { Agent } from strands-agents/sdk; const agent new Agent({ contextManager: agentic, tools: [shell, fileRead], }); // ContextCompression ContextNavigation ContextDelegation 全部激活。 // Agent 自己控制 L0压缩、钉住、搜索 L1 历史。v2 — 类实例资深用户import { Agent, ContextManager } from strands-agents/sdk; import { S3Storage } from strands-agents/storage-s3; const cm new ContextManager({ storage: new S3Storage({ bucket: my-session }), strategy: agentic, }); const agent new Agent({ contextManager: cm, tools: [shell, fileRead], }); // 直接访问存储例如用于 Memory 集成或测试 cm.storage; // S3Storage 实例 await cm.dispose(); // 用完后清理v2 — 退出上下文管理import { Agent } from strands-agents/sdk; const agent new Agent({ contextManager: false, tools: [shell, fileRead], });v2 — 从 conversationManager 迁移// 迁移前v1 —— 在 v2 中仍可用但有弃用警告 const agent new Agent({ conversationManager: new SummarizingConversationManager(), }); // 迁移后v2 const agent new Agent({ contextManager: { compression: { strategy: summarize } }, });6.3ContextManagerConfig完整字段contextManager在AgentConfig上是内联联合类型不设独立类型别名与model参数模式一致interface AgentConfig { contextManager?: auto | agentic | ContextManagerConfig | ContextManager | false; } interface ContextManagerConfig { storage?: Storage; // 默认SandboxStorage strategy?: auto | agentic; // 默认auto tokenCountingStrategy?: auto | heuristic; // 默认auto // ToolResultCache 插件配置 toolResultCache?: { threshold?: number; // 超过该 token 数即缓存结果待定 maxAge?: number; // 自动驱逐时间单位 ms待定 } | false; // ContextCompression 插件配置 compression?: { threshold?: number; // 上下文窗口比例0–1]默认0.7 strategy?: truncate | summarize | CompressionFn; // 默认summarize protectedMessages?: number; // 默认1 } | false; // ContextNavigation 插件配置仅 agentic navigation?: { searchStrategy?: keyword | semantic; // 默认待定 } | false; // ContextDelegation 插件配置仅 agentic delegation?: { maxChildContextRatio?: number; // 分享的父上下文比例待定 } | false; }字段说明与默认值一览字段默认值说明storageSandboxStorage支撑 L1。每次摘要前批量写入消息每批一个文件。被所有插件共享。strategyauto谁控制 L0框架auto还是 AgentagentictokenCountingStrategyauto由ContextManager拥有的 token 估算策略。auto优先使用 provider 原生 API失败时回退到启发式估算heuristic始终使用估算。插件从ContextManager读取 token 计数。toolResultCache启用ToolResultCache插件配置。设为false可禁用。toolResultCache.threshold待定超过该 token 数的工具结果被缓存toolResultCache.maxAge待定缓存工具结果的自动驱逐时间compression启用ContextCompression插件配置。设为false可禁用。compression.threshold0.7触发压缩的上下文窗口比例0–1]。若 L1 有消费者压缩前会先批量写入消息。compression.strategysummarize被驱逐消息在 L0 中以什么替代summarize浓缩块、truncate彻底移除、或自定义CompressionFncompression.protectedMessages1钉在 L0 中的初始消息数永不驱逐navigation启用agenticContextNavigation插件配置。设为false可禁用。在auto下被忽略。delegation启用agenticContextDelegation插件配置。设为false可禁用。在auto下被忽略。6.4 策略解析结果// 存储配置在 ContextManager 层级完成并传递给各插件 auto → [ new ToolResultCache({ ... }), new ContextCompression({ storage, ... }), ] agentic → [ new ToolResultCache({ ... }), new ContextCompression({ storage, ... }), new ContextNavigation({ storage }), new ContextDelegation({ storage }), ]在 Agent 构造函数中的类型解析逻辑if (typeof contextManager string) → new ContextManager({ strategy: contextManager }) if (contextManager instanceof ContextManager) → 直接使用 if (typeof contextManager object) → new ContextManager(contextManager) if (contextManager false) → null禁用本仓库的 harness 实现印证了这一解析路径Python harness 的配置校验允许auto、agentic、offoff映射为false、布尔false、或配置对象config.pyagent.py 中context_enabled判定非None/非False遇到Mapping配置则展开为ContextManager(**context_manager)。6.5 压缩策略策略L0 中保留什么truncate丢弃最旧消息滑动窗口跳过被保护的summarize摘要替代被驱逐的消息6.6 能力成长的归属规则新的 L1 能力 → 放在 ContextCompression写入或 ContextNavigation读取 新的工具结果行为 → 放在 ToolResultCache 新的压缩策略/启发式 → 放在 ContextCompression 新的 agentic 浏览工具 → 放在 ContextNavigation 新的委派能力 → 放在 ContextDelegation 新的配置旋钮 → 给一个合理默认值预设用户永远看不到它 全新的插件 → 预设自动组合它7. 备选方案评估Appendix B设计团队评估并拒绝了以下备选方案理由值得关注仅类原语无配置对象路径new Agent({ contextManager: new ContextManager(...) })被拒绝作为唯一路径——强迫常见场景也做 import 实例化字符串简写auto更简单。但类实例作为资深用户路径被接受——设计同时支持两者。预设作为独立插件类new Agent({ plugins: [new AutoContextManager()] })——可发现性差构造函数参数比插件 import 更容易被发现。工厂静态方法Agent.withAutoContext({ tools: [...] })——必须暴露完整构造函数参数集且暗示另一种 Agent。单一统一插件new Agent({ plugins: [new ContextManager({ mode: agentic, ... })])——能力增长会走向上帝对象God object、无法独立交付插件、预设反而隐藏了分解。单一整体类无插件分解ContextManager把压缩、缓存、导航、委派全装进一个类——上帝对象、与可组合的插件架构相悖、限制未来扩展。最终采纳了ContextManager这个命名但架构不同它是一个薄的配置解析器组合独立插件而非单体。8. 组合边界情况Appendix Cv1用户同时提供预设与 conversationManagernew Agent({ contextManager: auto, conversationManager: new SlidingWindowConversationManager({ windowSize: 20 }), });行为使用用户的会话管理器。ContextOffloader仍然负责工具结果缓存。无冲突。v2用户同时提供两者已弃用new Agent({ contextManager: agentic, conversationManager: new SummarizingConversationManager(), });行为contextManager优先。发出弃用警告。v2用户提供了重叠的 ContextCompressionnew Agent({ contextManager: agentic, plugins: [new ContextCompression({ storage: new S3Storage(...) })], });行为用户的ContextCompression胜出去重。预设的ContextNavigation仍然注册。9. Appendix EL1 存储模型注意这是实现细节可能变化。外部行为L1 追加式、游标作用域读取是稳定的物理存储布局不是。9.1 物理存储当 L1 存在消费者agentic 模式或memoryManager时每次摘要前消息会被批量写入 L1。每批是一个独立文件包含当时完整的messages数组。每条消息携带一个turn ID元数据中的一个单调递增标识符按 Agent 轮次分配。在 auto 模式且没有memoryManager时不发生任何 L1 写入。storage/ batch-001.json # 第 1–25 轮的消息第一次摘要前写入 batch-002.json # 第 26–50 轮的消息第二次摘要前写入 ...消息只写入一次。每批只包含自上一批以来的新消息。9.2 游标Cursors游标是指向扁平日志的起始指针——一个 turn ID。从该 turn 往后的所有内容就是 Agent 可见的 L1。游标存储在两处Agent 状态内存中——会话期间快速访问会话元数据持久化——在崩溃与会话恢复后依然存在。9.3 与快照Snapshots的关系快照在 SDK 中已经存在SessionManager并继续按原样工作——某个时间点 messages 数组的完整副本。在快照之外游标作为会话元数据一并存储。快照负责会话持久化/恢复游标负责 L1 可见窗口。二者独立共存。9.4 归档Archival对于长时运行的 Agent起始游标可以向前移动。游标之前的消息被归档——物理上仍在 L1 中但对searchHistory和getHistory不可见。Memory 仍然可以读取完整日志忽略游标。这就提供了 L1 之上的滑动窗口且不删除任何东西[archived | ← 起始游标 → | 对 Agent 可见 ] [第 1–50 轮 | | 第 51–200 轮 ]9.5 读取行为getHistory—— 返回自起始游标向前的消息。支持分页。searchHistory—— 自起始游标向前的关键词搜索。归档消息不被搜索。memoryManager—— 读取完整日志忽略游标用于 L1 → L2 抽取。9.6 删除逃生舱ContextManager暴露deleteMessages(turnIds)方法按 turn ID 物理删除 L1 中的特定消息。只有归档消息起始游标之后可以被删除——可见消息不能。使用场景隐私/合规用户要求删除数据、长时运行 Agent 在 Memory 抽取完所需内容后回收存储。await agent.contextManager.deleteMessages([turn_12, turn_13, turn_14]);10. 常见问题Anticipated QuestionsQ为什么 v1 中auto不是默认值需要先验证行为。v1 是 opt-in以便与早期采用者一起验证。v2 在确认可靠工作后将其设为默认。Q用户从 v1 升级到 v2 会发生什么两处变化(1)auto成为默认——未设置contextManager的 Agent 现在自动获得它不想如此的用户可设置contextManager: false。(2) 内部升级——ToolResultCache取代ContextOffloaderContextCompression取代会话管理器压缩——外部行为相同。Q如果用户提供了自己的插件呢去重按类型检测跳过预设版本。用户的ToolResultCache、ContextCompression或ContextNavigationv2胜出。Q为什么是配置对象而不是类v1 只接受字符串简写——无需 import、零仪式。v2 中配置对象和类实例ContextManager也被接受供需要生命周期钩子、直接存储访问或可测试性的资深用户使用——与model参数的模式一致。v1 中 Agent 直接把配置解析为插件/工具v2 中它解析为一个拥有 token 估算、预算和游标的ContextManager实例。Q如果模型不能有效使用上下文管理工具怎么办这正是agentic处于实验性的原因。auto以经过验证的框架驱动行为先行交付。Qv2 中用户还能留在conversationManager上吗可以但会收到弃用警告。它仍然工作——若两者都设置contextManager优先。v3 中移除。QMemory 与上下文管理是什么关系Memory 是独立原语memoryManager参数有自己的模式和存储——超出本设计范围。contextManager拥有 L0 ↔ L1会话内memoryManager拥有 L1 → L2跨会话知识抽取。Agent 充当两者间的经纪人——memoryManager获得对contextManager的 L1 的读取权限用于抽取。用户独立配置两者。11. 仓库中的实现印证与阅读入口如果你想进一步验证本文内容可以按以下路径深入设计文档team/designs/0011-context-strategy.md以及其关联设计 0003-context-management.md、0008-proactive-context-compression.md、0009-context-offloader.mdPython 实验性实现strands.experimental.context_manager见 strands-py/src/strands/experimental/context_manager/init.py它通过context_manager参数挂到 Agent 构造器提供ContextManager、ContextManagerConfig、ContextStrategy、SummarizeConfig、TruncateConfig、Offload与预设名STRATEGY_PRESET_NAMESPython harness 落地harness-py/src/strands_harness/agent.pycontext_manager: ContextManagerOption defaults.DEFAULT_CONTEXT_MANAGER与 harness-py/src/strands_harness/config.py配置校验auto/agentic/off/false/配置对象TypeScript harness 落地harness-ts/src/agent.tscontextManager参数语义注释、harness-ts/src/agent.tscontextEnabled/contextCustom判定、hasOffloader去重、durableOffloader与会话目录联动、harness-ts/src/config.tscontextManager: HarnessConfigContextManager配置字段。适用范围与限制说明auto为 v1 已交付的 opt-in 参数agentic、ContextManager类、OnContextOverflowEvent及conversationManager弃用均属 v2 提议且agentic处于实验状态——在设计文档层面auto才是 v2 的默认策略而本仓库 harness 层的DEFAULT_CONTEXT_MANAGER已将上下文管理作为默认开启auto体现了 v2 方向的提前落地。生产环境请以当前发布版本的文档与源码为准。赞分享人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk点击查看免费下载相关推荐Strands Python SDK v1.44.0 发布解析内存管理、上下文管理预设与多智能体增强Strands Python SDK v1.44.0 发布解析内存管理、上下文管理预设与多智能体增强 Strands 是一个开源的生产级 AI Agent S人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务MXNet.jl 中的 Context 计算设备上下文CPU/GPU 管理与底层实现解析MXNet.jl 中的 Context 计算设备上下文CPU/GPU 管理与底层实现解析 导读 本文以 MXNet 的 Julia 语言绑定MXNet.jl深度学习机器学习人工智能OpenViking 架构解读:用 viking:// 虚拟文件系统与 L0/L1/L2 分层加载管理 AI Agent 的上下文OpenViking 架构解读:用 viking:// 虚拟文件系统与 L0/L1/L2 分层加载管理 AI Agent 的上下文 本文基于 OpenVikin人工智能AI AgentAgent 记忆RAG后端数据库上一篇如何在Foobar2000中实现酷狗QQ网易云逐字歌词完美同步ESLyric歌词源终极指南下一篇把多台 Mac 拼成一台本地 AI 超算exo 快速上手指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Strands Context Strategy 设计解析：用 `contextManager` 预设接管 L0/L1 上下文管理
人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk点击查看免费下载导读本文围绕 0011-context-strategy.md 这篇跨 SDK 设计文档展开剖析 Strands SDKPython 与 TypeScript如何通过一个统一的contextManager/context_manager参数把上下文管理从零散的手工插件组合收敛为auto与agentic两种开箱即用的策略预设。你将理解 L0上下文窗口/ L1会话历史/ L2长期记忆三级缓存层级、v1 已交付与 v2 提议的组件拆分、conversationManager的迁移路径以及 L1 存储模型批量写入、游标、归档与删除的底层设计。文中所有结论均有对应源码佐证并给出可直接落地的配置示例。1. 问题背景20% 与 80% 的差距任何有一定规模的 Agent 最终都会撞上上下文长度上限。Strands 此前已经提供了处理这一问题的积木外部化externalization、压缩compression、会话管理器conversation manager、钩子hooks——但这些是彼此独立的扩展点用户需要自己去发现、配置并组装。设计文档 0011-context-strategy.md 指出这造成了一个典型的 20%/80% 缺口20% 场景追求完全控制的资深用户愿意手动组合所有扩展点80% 场景只想让上下文管理开箱即用的普通开发者。随着上下文管理能力不断增多每个新特性都意味着又一个需要接线wire up的插件或工具缺口只会越来越大。项目在 TENETS.md 中主张显而易见的路就是快乐路径the obvious path to be the happy path以及简单的事情就该简单simple things to be simple。因此本设计的核心结论是上下文管理应该是一行配置one-liner而不是一次组合练习composition exercise。方案落点是一个位于Agent构造函数上的contextManager参数——它背后依然是资深用户手动配置的那套扩展点只是把合理的选择为其余用户预先做好了。2. 缓存层级一切操作都是层级间的搬运设计文档将上下文管理映射为一个三级缓存层级见 0011-context-strategy.md 第 2 节每一次上下文操作本质上都是层级之间的数据移动层级是什么访问成本由什么支撑L0 — 上下文窗口agent.messages模型每次请求所见的内容可能包含摘要原消息已被驱逐零已在上下文中内存消息列表L1 — 会话历史消息的追加式append-only日志仅在存在消费者agentic 模式或memoryManager时才会写入每次摘要前批量写入低检索工具调用ContextManager存储FileStorage、S3Storage等L2 — 长期记忆跨会话知识——归档记忆、语义搜索索引、学到的事实超越当前会话持久存在较高查询 从持久化存储加载Memory 原语、向量存储、托管记忆服务需要明确本设计文档的边界本设计覆盖L0 ↔ L1会话内上下文管理L2长期记忆是独立原语memoryManager超出本文范围在本设计的视角下L1 在会话生命周期内是追加式且不可变的工具结果缓存tool result cache是独立的——短生命周期、自动驱逐且不可变与 L1 不同。L1 的存储内部细节见 Appendix EL1 存储模型。3. 策略预设谁控制 L0contextManager参数接受一个策略strategy它决定了谁控制 L0——哪些内容留在上下文窗口、何时压缩到 L1见 0011-context-strategy.md 第 3 节。两种策略共享同一套基础设施当上下文压力累积时压缩 L0超大工具结果被单独缓存retrieveToolResult始终可用让 Agent 无需推理上下文即可恢复被截断的输出。二者的核心区别auto框架与内容交互agenticAgent主动推理自身的上下文状态。逻辑住在插件里而不是工具里。工具只是面向 Agent 的、对插件方法的包装。在 auto 模式下框架通过钩子调用插件方法例如阈值触发时执行ContextCompression.compress()在 agentic 模式下同样的钩子仍然作为安全网触发但同时也注册了工具让 Agent 可以主动调用同样的方法。策略决定的是暴露哪些工具——而不是存在哪些逻辑。3.1 两种策略的能力矩阵能力autoagentic框架在阈值命中时压缩YesYes框架缓存超大工具结果YesYesAgent 可恢复被截断的工具输出YesretrieveToolResultYesAgent 可主动触发压缩NoYescompressContextAgent 可保护消息免于驱逐NoYespinMessageAgent 可读取 L1NoYesgetHistoryAgent 可搜索 L1NoYessearchHistoryAgent 可生成上下文感知的子 AgentNoYesdelegateWithContextAgent 可查看自己的上下文预算NoYesgetContextBudget3.2auto—— 框架决定框架透明地管理 L0当上下文压力累积时L0 中的消息被摘要化或丢弃。auto 模式下不会产生任何 L1 写入——只有当存在消费者agentic 模式或memoryManager时 L1 才会被写入。Agent 甚至感知不到上下文管理正在发生——它只是永远不会撞墙。唯一暴露的工具是用于恢复截断输出的retrieveToolResult。适用场景还不想思考上下文的初学者可预测性比自主性更重要的生产部署大规模、成本敏感的工作负载需要轻量、免维护上下文管理的多 Agent 系统任何只要别出问题的人。3.3agentic—— Agent 决定注意agentic目前是实验性的依赖模型是否能有效使用上下文管理工具这一研究结论。auto先行发布并是主要关注点。auto所做的一切仍然会发生——Agent额外获得主动管理自身 L0 的工具。它可以决定何时压缩、保护什么免于驱逐、以及在 L1 中浏览被驱逐的消息。适用场景能从上下文状态的自省中获益的研究型 Agent 和编码助手长时运行的自主 Agent以 Agent 自主性为核心目标的探索式开发多 Agent 编排中的父 Agent。3.4 成长与所有权随着上下文管理能力演进更多策略可能被加入。遵循 TENETS.md 中的 pay-for-play按需付费原则Strands 团队拥有这些预设并保留对其做破坏性变更的权利——预设内部解析成什么哪些插件、哪些默认值可能随版本变化需要稳定性的用户应该直接配置插件而不是依赖预设的内部实现所有预设配置的默认值阈值、策略、token 限制必须由基准测试benchmarking数据驱动任何默认值都不应仅凭直觉设定。4. v1已交付contextManager: auto作为可选项v1 以**可选项opt-in**的形式交付contextManager: autoPython 侧为context_managerauto。在 v1 中contextManager只接受字符串值autoAgent 直接将输入解析为插件和一个会话管理器不经过中间类。ContextManager类负责 token 估算、预算、游标在 v2 中才引入供需要生命周期钩子或直接存储访问的资深用户使用。默认值是undefined/None即不启用上下文管理——这样升级不会造成意外也给了项目时间去验证行为可靠后再设为默认。4.1 v1 接线了哪些组件组件作用基准验证的默认值ContextOffloader通过AfterToolCallEvent钩子把超大工具结果缓存在内存中短生命周期、自动驱逐。Agent 看到截断预览。提供retrieve_offloaded_content工具按需访问。v2 中更名为ToolResultCache配置键从contextOffloader改为toolResultCachemaxResultTokens1500previewTokens750SummarizingConversationManagerBeforeModelCallEvent钩子检查 L0 token 用量是否超过阈值超过则摘要化 L0 中较旧的消息summaryRatio0.3compressionThreshold0.85上述默认值在本仓库的实现中得到了印证Python harness 的 agent.py 中定义了_AUTO_MAX_RESULT_TOKENS 1_500与_AUTO_PREVIEW_TOKENS 750并据此构造 offloaderagent.pyTypeScript harness 的 agent.ts 中durableOffloader()同样以maxResultTokens: AUTO_MAX_RESULT_TOKENS、previewTokens: AUTO_PREVIEW_TOKENS实例化ContextOffloader。4.2 与conversationManager共存v1 尊重用户自带的会话管理器当用户提供了自己的会话管理器时用它替代默认的SummarizingConversationManageroffloader 无论如何都会被加上。// 使用默认的 SummarizingConversationManager 主动压缩 const agent new Agent({ contextManager: auto }); // 使用用户自己的会话管理器offloader 仍然会被添加 const agent new Agent({ contextManager: auto, conversationManager: new SlidingWindowConversationManager({ windowSize: 20 }), });# 使用默认的 SummarizingConversationManager 主动压缩 agent Agent(modelmodel, context_managerauto) # 使用用户自己的会话管理器offloader 仍然会被添加 agent Agent(modelmodel, context_managerauto, conversation_managerSlidingWindowConversationManager(window_size20))两条额外规则如果用户插件列表中已经有一个ContextOffloader它不会被覆盖本仓库中 harness 通过hasOffloader(plugins)检测plugins.some((p) p instanceof ContextOffloader)见 agent.ts 与 agent.py有状态模型stateful models会同时拒绝contextManager和conversationManager——它们自己管理服务端的会话状态。4.3 存储注意事项v1 的 offloader 使用InMemoryStorage——内容不会跨进程重启持久化。使用sessionManager且需要持久化 offloaded 内容的 Agent应通过plugins参数提供带持久化存储的显式ContextOffloader。作为对比本仓库的 harness SDK 在启用会话时会把 offloaded 产物落盘到会话目录${sessionDir}/offloaded无会话时落在一次性临时目录见 agent.ts这是 harness 层对持久化 offloader的落地实现。5. v2提议三项变更v2 提议三项变更见 0011-context-strategy.md 第 5 节auto成为默认——每个 Agent 默认获得上下文管理除非显式退出agentic交付——Agent 参与上下文管理conversationManager被弃用——其压缩职责移交ContextCompression。5.1 插件分解每个插件承担单一内聚职责。ContextManager不是插件——它是配置解析后得到的顶层类拥有共享基础设施存储、token 估算、预算跟踪、游标并组合下面这些插件。插件从ContextManager读取数据而不是彼此依赖组件角色领域工具模式ContextManager配置解析器 共享基础设施存储、token 估算、预算、游标getContextBudgetagentic始终ToolResultCache插件缓存超大工具结果retrieveToolResult两种ContextCompression插件L0 写入——压缩、钉住pinningcompressContext、pinMessageagentic两种ContextNavigation插件从 L1会话历史读取getHistory、searchHistory仅 agenticContextDelegation插件上下文感知的子 Agent 生成delegateWithContext仅 agenticv2 还引入了OnContextOverflowEvent——一个在上下文长度错误时触发的新生命周期事件取代会话管理器中不透明的重试逻辑。SDK 已经把所有 provider 的此类错误归一化为ContextWindowOverflowError——这个事件只是把该错误暴露给插件。5.2conversationManager弃用路径v2 中ContextCompression接管了压缩和 L1 写入会话管理器不再有事可做。弃用分三步走v1共存两者并行存在无冲突v2弃用发出弃用警告若两者都设置了contextManager优先v3移除conversationManager从构造函数类型中移除。迁移对照表Appendix DconversationManager今天contextManager等价写法new SlidingWindowConversationManager(){ compression: { strategy: truncate } }new SummarizingConversationManager(){ compression: { strategy: summarize } }NullConversationManagerfalse自定义子类{ compression: { strategy: customFn } }6. 设计文档附录完整配置与代码示例6.1 v1 代码示例v1 — auto 最小配置import { Agent } from strands-agents/sdk; const agent new Agent({ contextManager: auto, tools: [shell, fileRead], });from strands import Agent agent Agent(modelmodel, context_managerauto, tools[shell, file_read])v1 — auto 用户自己的会话管理器import { Agent } from strands-agents/sdk; const agent new Agent({ contextManager: auto, conversationManager: new SummarizingConversationManager(), tools: [shell, fileRead], });from strands import Agent from strands.agent.conversation_manager import SummarizingConversationManager agent Agent(modelmodel, context_managerauto, conversation_managerSummarizingConversationManager(), tools[shell, file_read])6.2 v2 代码示例v2 — 默认无需任何配置import { Agent } from strands-agents/sdk; const agent new Agent({ tools: [shell, fileRead], }); // 上下文管理默认开启。SandboxStorage auto 策略。v2 — 自定义存储import { Agent } from strands-agents/sdk; import { S3Storage } from strands-agents/storage-s3; const agent new Agent({ contextManager: { storage: new S3Storage({ bucket: my-session }), strategy: auto, compression: { threshold: 0.8, protectedMessages: 2 }, }, tools: [shell, fileRead], });v2 — Agentic 模式import { Agent } from strands-agents/sdk; const agent new Agent({ contextManager: agentic, tools: [shell, fileRead], }); // ContextCompression ContextNavigation ContextDelegation 全部激活。 // Agent 自己控制 L0压缩、钉住、搜索 L1 历史。v2 — 类实例资深用户import { Agent, ContextManager } from strands-agents/sdk; import { S3Storage } from strands-agents/storage-s3; const cm new ContextManager({ storage: new S3Storage({ bucket: my-session }), strategy: agentic, }); const agent new Agent({ contextManager: cm, tools: [shell, fileRead], }); // 直接访问存储例如用于 Memory 集成或测试 cm.storage; // S3Storage 实例 await cm.dispose(); // 用完后清理v2 — 退出上下文管理import { Agent } from strands-agents/sdk; const agent new Agent({ contextManager: false, tools: [shell, fileRead], });v2 — 从 conversationManager 迁移// 迁移前v1 —— 在 v2 中仍可用但有弃用警告 const agent new Agent({ conversationManager: new SummarizingConversationManager(), }); // 迁移后v2 const agent new Agent({ contextManager: { compression: { strategy: summarize } }, });6.3ContextManagerConfig完整字段contextManager在AgentConfig上是内联联合类型不设独立类型别名与model参数模式一致interface AgentConfig { contextManager?: auto | agentic | ContextManagerConfig | ContextManager | false; } interface ContextManagerConfig { storage?: Storage; // 默认SandboxStorage strategy?: auto | agentic; // 默认auto tokenCountingStrategy?: auto | heuristic; // 默认auto // ToolResultCache 插件配置 toolResultCache?: { threshold?: number; // 超过该 token 数即缓存结果待定 maxAge?: number; // 自动驱逐时间单位 ms待定 } | false; // ContextCompression 插件配置 compression?: { threshold?: number; // 上下文窗口比例0–1]默认0.7 strategy?: truncate | summarize | CompressionFn; // 默认summarize protectedMessages?: number; // 默认1 } | false; // ContextNavigation 插件配置仅 agentic navigation?: { searchStrategy?: keyword | semantic; // 默认待定 } | false; // ContextDelegation 插件配置仅 agentic delegation?: { maxChildContextRatio?: number; // 分享的父上下文比例待定 } | false; }字段说明与默认值一览字段默认值说明storageSandboxStorage支撑 L1。每次摘要前批量写入消息每批一个文件。被所有插件共享。strategyauto谁控制 L0框架auto还是 AgentagentictokenCountingStrategyauto由ContextManager拥有的 token 估算策略。auto优先使用 provider 原生 API失败时回退到启发式估算heuristic始终使用估算。插件从ContextManager读取 token 计数。toolResultCache启用ToolResultCache插件配置。设为false可禁用。toolResultCache.threshold待定超过该 token 数的工具结果被缓存toolResultCache.maxAge待定缓存工具结果的自动驱逐时间compression启用ContextCompression插件配置。设为false可禁用。compression.threshold0.7触发压缩的上下文窗口比例0–1]。若 L1 有消费者压缩前会先批量写入消息。compression.strategysummarize被驱逐消息在 L0 中以什么替代summarize浓缩块、truncate彻底移除、或自定义CompressionFncompression.protectedMessages1钉在 L0 中的初始消息数永不驱逐navigation启用agenticContextNavigation插件配置。设为false可禁用。在auto下被忽略。delegation启用agenticContextDelegation插件配置。设为false可禁用。在auto下被忽略。6.4 策略解析结果// 存储配置在 ContextManager 层级完成并传递给各插件 auto → [ new ToolResultCache({ ... }), new ContextCompression({ storage, ... }), ] agentic → [ new ToolResultCache({ ... }), new ContextCompression({ storage, ... }), new ContextNavigation({ storage }), new ContextDelegation({ storage }), ]在 Agent 构造函数中的类型解析逻辑if (typeof contextManager string) → new ContextManager({ strategy: contextManager }) if (contextManager instanceof ContextManager) → 直接使用 if (typeof contextManager object) → new ContextManager(contextManager) if (contextManager false) → null禁用本仓库的 harness 实现印证了这一解析路径Python harness 的配置校验允许auto、agentic、offoff映射为false、布尔false、或配置对象config.pyagent.py 中context_enabled判定非None/非False遇到Mapping配置则展开为ContextManager(**context_manager)。6.5 压缩策略策略L0 中保留什么truncate丢弃最旧消息滑动窗口跳过被保护的summarize摘要替代被驱逐的消息6.6 能力成长的归属规则新的 L1 能力 → 放在 ContextCompression写入或 ContextNavigation读取 新的工具结果行为 → 放在 ToolResultCache 新的压缩策略/启发式 → 放在 ContextCompression 新的 agentic 浏览工具 → 放在 ContextNavigation 新的委派能力 → 放在 ContextDelegation 新的配置旋钮 → 给一个合理默认值预设用户永远看不到它 全新的插件 → 预设自动组合它7. 备选方案评估Appendix B设计团队评估并拒绝了以下备选方案理由值得关注仅类原语无配置对象路径new Agent({ contextManager: new ContextManager(...) })被拒绝作为唯一路径——强迫常见场景也做 import 实例化字符串简写auto更简单。但类实例作为资深用户路径被接受——设计同时支持两者。预设作为独立插件类new Agent({ plugins: [new AutoContextManager()] })——可发现性差构造函数参数比插件 import 更容易被发现。工厂静态方法Agent.withAutoContext({ tools: [...] })——必须暴露完整构造函数参数集且暗示另一种 Agent。单一统一插件new Agent({ plugins: [new ContextManager({ mode: agentic, ... })])——能力增长会走向上帝对象God object、无法独立交付插件、预设反而隐藏了分解。单一整体类无插件分解ContextManager把压缩、缓存、导航、委派全装进一个类——上帝对象、与可组合的插件架构相悖、限制未来扩展。最终采纳了ContextManager这个命名但架构不同它是一个薄的配置解析器组合独立插件而非单体。8. 组合边界情况Appendix Cv1用户同时提供预设与 conversationManagernew Agent({ contextManager: auto, conversationManager: new SlidingWindowConversationManager({ windowSize: 20 }), });行为使用用户的会话管理器。ContextOffloader仍然负责工具结果缓存。无冲突。v2用户同时提供两者已弃用new Agent({ contextManager: agentic, conversationManager: new SummarizingConversationManager(), });行为contextManager优先。发出弃用警告。v2用户提供了重叠的 ContextCompressionnew Agent({ contextManager: agentic, plugins: [new ContextCompression({ storage: new S3Storage(...) })], });行为用户的ContextCompression胜出去重。预设的ContextNavigation仍然注册。9. Appendix EL1 存储模型注意这是实现细节可能变化。外部行为L1 追加式、游标作用域读取是稳定的物理存储布局不是。9.1 物理存储当 L1 存在消费者agentic 模式或memoryManager时每次摘要前消息会被批量写入 L1。每批是一个独立文件包含当时完整的messages数组。每条消息携带一个turn ID元数据中的一个单调递增标识符按 Agent 轮次分配。在 auto 模式且没有memoryManager时不发生任何 L1 写入。storage/ batch-001.json # 第 1–25 轮的消息第一次摘要前写入 batch-002.json # 第 26–50 轮的消息第二次摘要前写入 ...消息只写入一次。每批只包含自上一批以来的新消息。9.2 游标Cursors游标是指向扁平日志的起始指针——一个 turn ID。从该 turn 往后的所有内容就是 Agent 可见的 L1。游标存储在两处Agent 状态内存中——会话期间快速访问会话元数据持久化——在崩溃与会话恢复后依然存在。9.3 与快照Snapshots的关系快照在 SDK 中已经存在SessionManager并继续按原样工作——某个时间点 messages 数组的完整副本。在快照之外游标作为会话元数据一并存储。快照负责会话持久化/恢复游标负责 L1 可见窗口。二者独立共存。9.4 归档Archival对于长时运行的 Agent起始游标可以向前移动。游标之前的消息被归档——物理上仍在 L1 中但对searchHistory和getHistory不可见。Memory 仍然可以读取完整日志忽略游标。这就提供了 L1 之上的滑动窗口且不删除任何东西[archived | ← 起始游标 → | 对 Agent 可见 ] [第 1–50 轮 | | 第 51–200 轮 ]9.5 读取行为getHistory—— 返回自起始游标向前的消息。支持分页。searchHistory—— 自起始游标向前的关键词搜索。归档消息不被搜索。memoryManager—— 读取完整日志忽略游标用于 L1 → L2 抽取。9.6 删除逃生舱ContextManager暴露deleteMessages(turnIds)方法按 turn ID 物理删除 L1 中的特定消息。只有归档消息起始游标之后可以被删除——可见消息不能。使用场景隐私/合规用户要求删除数据、长时运行 Agent 在 Memory 抽取完所需内容后回收存储。await agent.contextManager.deleteMessages([turn_12, turn_13, turn_14]);10. 常见问题Anticipated QuestionsQ为什么 v1 中auto不是默认值需要先验证行为。v1 是 opt-in以便与早期采用者一起验证。v2 在确认可靠工作后将其设为默认。Q用户从 v1 升级到 v2 会发生什么两处变化(1)auto成为默认——未设置contextManager的 Agent 现在自动获得它不想如此的用户可设置contextManager: false。(2) 内部升级——ToolResultCache取代ContextOffloaderContextCompression取代会话管理器压缩——外部行为相同。Q如果用户提供了自己的插件呢去重按类型检测跳过预设版本。用户的ToolResultCache、ContextCompression或ContextNavigationv2胜出。Q为什么是配置对象而不是类v1 只接受字符串简写——无需 import、零仪式。v2 中配置对象和类实例ContextManager也被接受供需要生命周期钩子、直接存储访问或可测试性的资深用户使用——与model参数的模式一致。v1 中 Agent 直接把配置解析为插件/工具v2 中它解析为一个拥有 token 估算、预算和游标的ContextManager实例。Q如果模型不能有效使用上下文管理工具怎么办这正是agentic处于实验性的原因。auto以经过验证的框架驱动行为先行交付。Qv2 中用户还能留在conversationManager上吗可以但会收到弃用警告。它仍然工作——若两者都设置contextManager优先。v3 中移除。QMemory 与上下文管理是什么关系Memory 是独立原语memoryManager参数有自己的模式和存储——超出本设计范围。contextManager拥有 L0 ↔ L1会话内memoryManager拥有 L1 → L2跨会话知识抽取。Agent 充当两者间的经纪人——memoryManager获得对contextManager的 L1 的读取权限用于抽取。用户独立配置两者。11. 仓库中的实现印证与阅读入口如果你想进一步验证本文内容可以按以下路径深入设计文档team/designs/0011-context-strategy.md以及其关联设计 0003-context-management.md、0008-proactive-context-compression.md、0009-context-offloader.mdPython 实验性实现strands.experimental.context_manager见 strands-py/src/strands/experimental/context_manager/init.py它通过context_manager参数挂到 Agent 构造器提供ContextManager、ContextManagerConfig、ContextStrategy、SummarizeConfig、TruncateConfig、Offload与预设名STRATEGY_PRESET_NAMESPython harness 落地harness-py/src/strands_harness/agent.pycontext_manager: ContextManagerOption defaults.DEFAULT_CONTEXT_MANAGER与 harness-py/src/strands_harness/config.py配置校验auto/agentic/off/false/配置对象TypeScript harness 落地harness-ts/src/agent.tscontextManager参数语义注释、harness-ts/src/agent.tscontextEnabled/contextCustom判定、hasOffloader去重、durableOffloader与会话目录联动、harness-ts/src/config.tscontextManager: HarnessConfigContextManager配置字段。适用范围与限制说明auto为 v1 已交付的 opt-in 参数agentic、ContextManager类、OnContextOverflowEvent及conversationManager弃用均属 v2 提议且agentic处于实验状态——在设计文档层面auto才是 v2 的默认策略而本仓库 harness 层的DEFAULT_CONTEXT_MANAGER已将上下文管理作为默认开启auto体现了 v2 方向的提前落地。生产环境请以当前发布版本的文档与源码为准。赞分享人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk点击查看免费下载相关推荐Strands Python SDK v1.44.0 发布解析内存管理、上下文管理预设与多智能体增强Strands Python SDK v1.44.0 发布解析内存管理、上下文管理预设与多智能体增强 Strands 是一个开源的生产级 AI Agent S人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务MXNet.jl 中的 Context 计算设备上下文CPU/GPU 管理与底层实现解析MXNet.jl 中的 Context 计算设备上下文CPU/GPU 管理与底层实现解析 导读 本文以 MXNet 的 Julia 语言绑定MXNet.jl深度学习机器学习人工智能OpenViking 架构解读:用 viking:// 虚拟文件系统与 L0/L1/L2 分层加载管理 AI Agent 的上下文OpenViking 架构解读:用 viking:// 虚拟文件系统与 L0/L1/L2 分层加载管理 AI Agent 的上下文 本文基于 OpenVikin人工智能AI AgentAgent 记忆RAG后端数据库上一篇如何在Foobar2000中实现酷狗QQ网易云逐字歌词完美同步ESLyric歌词源终极指南下一篇把多台 Mac 拼成一台本地 AI 超算exo 快速上手指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考