人工智能大模型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-agentsPython SDK1.32.0发布于 2026-03-20属于非破坏性breaking: false的修复型小版本。本次更新共包含 3 项修复分别落在 OpenTelemetry 指标采集、模型依赖管理与双向流式bidirectional streaming响应处理三个方向并迎来了两位新贡献者stephentreacy、atian8179。strands-agents 是 harness-sdk 仓库中面向生产环境 AI Agent 的开源 Python SDK与 TypeScript 版本共享同一套 Agent harness 设计理念支持任意模型、任意云环境。v1.32.0 是一个典型的稳定优先小版本没有新增功能全部精力用于让可观测性数据更完整、让依赖解析更可控、让流式工具调用语义更准确。本文将以该版本 changelogsite/src/content/changelog/sdk/python-v1.32.0.md为骨架逐条拆解三项修复的来龙去脉并结合仓库源码说明它们为什么重要、修复后行为如何、以及你升级后应当如何验证。一、v1.32.0 变更总览该版本的 frontmatter 完整记录了发布元数据与站点侧渲染site/src/config/changelog.ts中的 SDK 流标签约定一致Python 流对应Strands harness Python。三条变更均为fix类型、均不破坏现有 API具体如下类型影响范围变更内容PR作者fixevent-loop / otel确保所有 cycle 指标都包含结束时间与耗时#1903stephentreacyfix依赖管理为 mistralai 依赖收紧上界pin upper bound#1935mkmeralfixbidirectional-streaming当流式响应包含 toolUse 块时覆盖 end_turn stop reason#1827atian8179版本发布同时收录了两位新贡献者stephentreacyPR #1903与atian8179PR #1827。对社区而言这一版本也意味着双向流式bidi工具调用路径得到了更严谨的语义修正。二、修复一事件循环Event Loop周期指标补全结束时间与耗时变更原文ensure all cycle metrics include end time and durationPR #1903作者 stephentreacycommitadfeb972.1 这项修复针对什么问题strands-agents 的事件循环event loop是 Agent 主循环的核心每一轮模型调用 工具执行构成一个 cycle。为了对 Agent 进行可观测性监控SDK 会为每个 cycle 记录 OTel 指标包括 cycle 计数、起始计数、结束计数以及耗时直方图。修复前部分 cycle 指标缺少**结束时间end time与耗时duration**的落盘导致基于 OTel 的监控面板难以稳定地计算周期耗时趋势。2.2 源码中的指标骨架该修复直接作用于事件循环指标聚合层核心实现集中在 strands-py/src/strands/telemetry/metrics.pyTrace数据类约 L50-L101内置了end_time字段与end(end_time)、duration()方法duration()在 trace 未结束时返回None结束时返回end_time - start_time并在序列化输出中同时携带end_time与duration两个键EventLoopMetrics维护cycle_durations: list[float]并提供start_cycle()约 L277与end_cycle()约 L305两个入口end_cycle()内部完成三件事累加event_loop_end_cycle计数器、通过event_loop_cycle_duration直方图记录本次耗时、将耗时追加进cycle_durations列表最后调用cycle_trace.end(end_time)为 trace 补上结束时间戳。这正对应 changelog 中所有 cycle 指标都包含结束时间与耗时的修复目标无论是计数器、直方图还是 trace都以同一套end_time/duration语义收口。2.3 事件循环中指标的实际触发点指标并非凭空产生而是在事件循环的执行路径上被真实调用。在 strands-py/src/strands/event_loop/event_loop.py 中event_loop_cycle函数在每轮开始时通过agent.event_loop_metrics.start_cycle(attributesattributes)开启一个 cycle约 L271并生成唯一event_loop_cycle_id在正常结束路径约 L335与异常/中断路径约 L366上均调用agent.event_loop_metrics.end_cycle(...)收尾递归子循环约 L788与工具调用循环结束处约 L968同样调用end_cycle确保无论 Agent 从哪条路径退出 cycle指标都能被完整记录。这意味着修复后的行为是全局性的只要是经由事件循环执行的 Agent 会话每个 cycle 的结束时间与耗时都会稳定出现在 OTel 指标流中。2.4 对应的 OTel 指标名MetricsClient在 metrics.py约 L587-L653注册了相关埋点event_loop_cycle_countCounterevent_loop_start_cycleCounterevent_loop_end_cycleCounterevent_loop_cycle_durationHistogram单位秒tool_durationHistogram单位秒升级到 v1.32.0 后你可以在 OTel 采集端重点观察event_loop_cycle_duration直方图是否持续产出数据——这是验证本修复最直接的方式。仓库的遥测测试 strands-py/tests/strands/telemetry/test_telemetry.py 与 strands-py/tests/strands/event_loop/test_event_loop.py 覆盖了指标采集与汇总逻辑可作为回归参考。三、修复二为 mistralai 依赖收紧上界变更原文pin upper bound for mistralai dependencyPR #1935作者 mkmeralcommitae283973.1 为什么需要给依赖加上界Mistral 模型在 strands-agents 中通过独立的模型适配层接入对应的可选依赖组为mistral。给mistralai设置上界upper bound是依赖治理的常见手段当上游 SDK 发布破坏性变更例如修改客户端 API、消息结构或流式事件格式时不加限制的宽松区间如2.0.0会让使用pip install的用户在下次安装时静默拉到不兼容版本从而破坏模型适配层。3.2 当前 pyproject.toml 中的实际约束修复后的依赖声明位于 strands-py/pyproject.toml 第 55 行mistral [mistralai2.0.0,3.0.0]即最低要求2.0.0最高不得超过3.0.0。这与仓库中其他模型适配组的管理风格一致例如openai组openai1.68.0,3.0.0、gemini组google-genai1.67.0,3.0.0都采用下限满足功能、上限规避破坏的双端约束策略。同一文件第 51-53 行还以注释形式记录了 litellm 因 Python 3.14 兼容性问题而收紧版本的先例可见该仓库对依赖版本治理有明确的工程规范。3.3 落地位置与升级建议模型适配层实现位于 strands-py/src/strands/models/mistral.py其从mistralai.client导入Mistral客户端因此mistralai的 API 形态直接影响适配层正确性相应测试位于 strands-py/tests/strands/models/test_mistral.py使用了mistralai.client.models中的UserMessage类型构造消息。升级到 v1.32.0 后若你使用 Mistral 模型建议执行pip install strands-agents[mistral]并确认解析结果落在mistralai2.0.0,3.0.0区间内若你的既有环境已装有mistralai 3.x则需要主动降级以满足新约束。四、修复三流式响应含 toolUse 块时覆盖 end_turn stop reason变更原文override end_turn stop reason when streaming response contains toolUse blocksPR #1827作者 atian8179commit38c1ab64.1 场景背景strands-agents 的实验性双向流式bidirectional streaming简称 bidi能力允许 Agent 与模型之间建立持续的双向数据流。模型在流式输出中可能先发出END_TURN之类的结束信号但随后又携带工具调用块toolUse/tool_use。如果 SDK 直接采信END_TURN作为最终 stop reasonAgent 循环就会错误地认为回合已结束从而跳过本应执行的工具调用——这是流式工具调用场景中典型的过早终止缺陷。4.2 修复后的行为以工具调用语义覆盖结束信号修复的核心逻辑体现在 strands-py/src/strands/experimental/bidi/models/bedrock.py约 L819-L831流式事件流中解析content_end事件并提取stopReason当stopReason END_TURN但当前响应实际包含工具调用块非最终文本时不再把END_TURN当作回合终点而是将其改写为tool_use语义当stopReason INTERRUPTED时映射为barge_in用户打断其余正常结束映射为complete并继续维护响应转录。这种以响应实际内容为准、覆盖协议层结束信号的策略保证 Agent 的决策循环不会被提前切断。同一路径上的其他模型适配层也遵循类似的 stop reason 语义例如 strands-py/src/strands/experimental/bidi/models/google.py 在正常结束回合时上报stop_reasoncomplete。4.3 stop reason 在下游如何被消费在事件循环层strands-py/src/strands/experimental/bidi/agent/loop.py 会依据stop_reason分派逻辑用户打断barge_in、事件自然结束event.stop_reason、模型出错/不完整error/incomplete约 L605-L695在遥测层strands-py/src/strands/experimental/bidi/_telemetry.py约 L103-L120将stop_reason映射为 OTel 语义约定属性gen_ai.response.finish_reason使工具调用导致回合结束这一行为在监控数据中可被清晰检索在转录层strands-py/src/strands/experimental/bidi/io/transcript.py 通过stop_reason barge_in识别并记录打断事件。修复后当流式响应包含工具调用块时你会在遥测中看到gen_ai.response.finish_reasontool_use而非错误的end_turnAgent 也会正常进入工具执行阶段。五、升级验证清单与影响范围5.1 兼容性说明v1.32.0 的三条变更breaking均为false不涉及公共 API 破坏升级路径平滑。但请注意以下行为差异OTel 指标event_loop_cycle_duration等周期指标的完整性提升监控告警规则可以开始依赖end_time/duration字段依赖解析Mistral 用户需要满足mistralai2.0.0,3.0.0若当前解析结果超出该区间请在升级前调整bidi 流式流式工具调用的回合结束语义更准确依赖旧提前结束行为的自定义逻辑如有需要同步审视。5.2 建议的验证步骤升级后运行 SDK 自带遥测测试与事件循环测试确认指标埋点路径无回归strands-py/tests/strands/telemetry/test_telemetry.py执行pip install strands-agents[mistral] --dry-run或pip index versions mistralai核对依赖区间若使用 bidi 能力构造一个流式响应含工具调用的用例检查事件循环最终 stop reason 是否为tool_use并在 OTel 后端确认gen_ai.response.finish_reason取值。六、结语v1.32.0 是 strands-agents Python SDK 在可观测性、依赖治理与流式语义三个维度的一次集中打磨OTel 周期指标从此具备完整的时间维度Mistral 依赖版本得到明确锚定双向流式场景下的工具调用回合不再被错误的end_turn信号提前终结。对于正在生产环境运行 Agent harness 的团队这是一个值得平滑升级的稳定版本对于想深入了解事件循环指标链路与 bidi 流式实现的开发者本文给出的源码路径metrics.py、event_loop.py、bedrock.py可作为继续阅读的入口。赞分享人工智能大模型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-agents Python SDK v0.1.1 版本解读Bedrock 请求标识、LlamaAPI 文档与发布流程strands agents Python SDK v0.1.1 版本解读Bedrock 请求标识、LlamaAPI 文档与发布流程 本文基于仓库内 chan人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务MCP Python SDK 发布流程全解从依赖升级、双发布线管理到 PyPI 发布与回滚MCP Python SDK 发布流程全解从依赖升级、双发布线管理到 PyPI 发布与回滚 本篇技术指南以本仓库根目录的 RELEASE.md https:/人工智能MCP 服务MCP ClientsNode.js 20.20.0 (LTS) 安全发布深度解读CVE 修复、依赖升级与发布流程解析Node.js 20.20.0 LTS 安全发布深度解读CVE 修复、依赖升级与发布流程解析 导读 2026 年 1 月 13 日Node.js 项目正式发前端文档上一篇如何在浏览器中实现专业的Web扫码功能Html5-QRCode完整指南下一篇redis-py 集群模式完全指南RedisCluster 连接、命令路由、Multi-key 与只读模式实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 strands-agents Python SDK v1.32.0 发布解读：事件循环 OTel 指标补全、Mistral 依赖上界与双向流式 stop reason 修复
人工智能大模型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-agentsPython SDK1.32.0发布于 2026-03-20属于非破坏性breaking: false的修复型小版本。本次更新共包含 3 项修复分别落在 OpenTelemetry 指标采集、模型依赖管理与双向流式bidirectional streaming响应处理三个方向并迎来了两位新贡献者stephentreacy、atian8179。strands-agents 是 harness-sdk 仓库中面向生产环境 AI Agent 的开源 Python SDK与 TypeScript 版本共享同一套 Agent harness 设计理念支持任意模型、任意云环境。v1.32.0 是一个典型的稳定优先小版本没有新增功能全部精力用于让可观测性数据更完整、让依赖解析更可控、让流式工具调用语义更准确。本文将以该版本 changelogsite/src/content/changelog/sdk/python-v1.32.0.md为骨架逐条拆解三项修复的来龙去脉并结合仓库源码说明它们为什么重要、修复后行为如何、以及你升级后应当如何验证。一、v1.32.0 变更总览该版本的 frontmatter 完整记录了发布元数据与站点侧渲染site/src/config/changelog.ts中的 SDK 流标签约定一致Python 流对应Strands harness Python。三条变更均为fix类型、均不破坏现有 API具体如下类型影响范围变更内容PR作者fixevent-loop / otel确保所有 cycle 指标都包含结束时间与耗时#1903stephentreacyfix依赖管理为 mistralai 依赖收紧上界pin upper bound#1935mkmeralfixbidirectional-streaming当流式响应包含 toolUse 块时覆盖 end_turn stop reason#1827atian8179版本发布同时收录了两位新贡献者stephentreacyPR #1903与atian8179PR #1827。对社区而言这一版本也意味着双向流式bidi工具调用路径得到了更严谨的语义修正。二、修复一事件循环Event Loop周期指标补全结束时间与耗时变更原文ensure all cycle metrics include end time and durationPR #1903作者 stephentreacycommitadfeb972.1 这项修复针对什么问题strands-agents 的事件循环event loop是 Agent 主循环的核心每一轮模型调用 工具执行构成一个 cycle。为了对 Agent 进行可观测性监控SDK 会为每个 cycle 记录 OTel 指标包括 cycle 计数、起始计数、结束计数以及耗时直方图。修复前部分 cycle 指标缺少**结束时间end time与耗时duration**的落盘导致基于 OTel 的监控面板难以稳定地计算周期耗时趋势。2.2 源码中的指标骨架该修复直接作用于事件循环指标聚合层核心实现集中在 strands-py/src/strands/telemetry/metrics.pyTrace数据类约 L50-L101内置了end_time字段与end(end_time)、duration()方法duration()在 trace 未结束时返回None结束时返回end_time - start_time并在序列化输出中同时携带end_time与duration两个键EventLoopMetrics维护cycle_durations: list[float]并提供start_cycle()约 L277与end_cycle()约 L305两个入口end_cycle()内部完成三件事累加event_loop_end_cycle计数器、通过event_loop_cycle_duration直方图记录本次耗时、将耗时追加进cycle_durations列表最后调用cycle_trace.end(end_time)为 trace 补上结束时间戳。这正对应 changelog 中所有 cycle 指标都包含结束时间与耗时的修复目标无论是计数器、直方图还是 trace都以同一套end_time/duration语义收口。2.3 事件循环中指标的实际触发点指标并非凭空产生而是在事件循环的执行路径上被真实调用。在 strands-py/src/strands/event_loop/event_loop.py 中event_loop_cycle函数在每轮开始时通过agent.event_loop_metrics.start_cycle(attributesattributes)开启一个 cycle约 L271并生成唯一event_loop_cycle_id在正常结束路径约 L335与异常/中断路径约 L366上均调用agent.event_loop_metrics.end_cycle(...)收尾递归子循环约 L788与工具调用循环结束处约 L968同样调用end_cycle确保无论 Agent 从哪条路径退出 cycle指标都能被完整记录。这意味着修复后的行为是全局性的只要是经由事件循环执行的 Agent 会话每个 cycle 的结束时间与耗时都会稳定出现在 OTel 指标流中。2.4 对应的 OTel 指标名MetricsClient在 metrics.py约 L587-L653注册了相关埋点event_loop_cycle_countCounterevent_loop_start_cycleCounterevent_loop_end_cycleCounterevent_loop_cycle_durationHistogram单位秒tool_durationHistogram单位秒升级到 v1.32.0 后你可以在 OTel 采集端重点观察event_loop_cycle_duration直方图是否持续产出数据——这是验证本修复最直接的方式。仓库的遥测测试 strands-py/tests/strands/telemetry/test_telemetry.py 与 strands-py/tests/strands/event_loop/test_event_loop.py 覆盖了指标采集与汇总逻辑可作为回归参考。三、修复二为 mistralai 依赖收紧上界变更原文pin upper bound for mistralai dependencyPR #1935作者 mkmeralcommitae283973.1 为什么需要给依赖加上界Mistral 模型在 strands-agents 中通过独立的模型适配层接入对应的可选依赖组为mistral。给mistralai设置上界upper bound是依赖治理的常见手段当上游 SDK 发布破坏性变更例如修改客户端 API、消息结构或流式事件格式时不加限制的宽松区间如2.0.0会让使用pip install的用户在下次安装时静默拉到不兼容版本从而破坏模型适配层。3.2 当前 pyproject.toml 中的实际约束修复后的依赖声明位于 strands-py/pyproject.toml 第 55 行mistral [mistralai2.0.0,3.0.0]即最低要求2.0.0最高不得超过3.0.0。这与仓库中其他模型适配组的管理风格一致例如openai组openai1.68.0,3.0.0、gemini组google-genai1.67.0,3.0.0都采用下限满足功能、上限规避破坏的双端约束策略。同一文件第 51-53 行还以注释形式记录了 litellm 因 Python 3.14 兼容性问题而收紧版本的先例可见该仓库对依赖版本治理有明确的工程规范。3.3 落地位置与升级建议模型适配层实现位于 strands-py/src/strands/models/mistral.py其从mistralai.client导入Mistral客户端因此mistralai的 API 形态直接影响适配层正确性相应测试位于 strands-py/tests/strands/models/test_mistral.py使用了mistralai.client.models中的UserMessage类型构造消息。升级到 v1.32.0 后若你使用 Mistral 模型建议执行pip install strands-agents[mistral]并确认解析结果落在mistralai2.0.0,3.0.0区间内若你的既有环境已装有mistralai 3.x则需要主动降级以满足新约束。四、修复三流式响应含 toolUse 块时覆盖 end_turn stop reason变更原文override end_turn stop reason when streaming response contains toolUse blocksPR #1827作者 atian8179commit38c1ab64.1 场景背景strands-agents 的实验性双向流式bidirectional streaming简称 bidi能力允许 Agent 与模型之间建立持续的双向数据流。模型在流式输出中可能先发出END_TURN之类的结束信号但随后又携带工具调用块toolUse/tool_use。如果 SDK 直接采信END_TURN作为最终 stop reasonAgent 循环就会错误地认为回合已结束从而跳过本应执行的工具调用——这是流式工具调用场景中典型的过早终止缺陷。4.2 修复后的行为以工具调用语义覆盖结束信号修复的核心逻辑体现在 strands-py/src/strands/experimental/bidi/models/bedrock.py约 L819-L831流式事件流中解析content_end事件并提取stopReason当stopReason END_TURN但当前响应实际包含工具调用块非最终文本时不再把END_TURN当作回合终点而是将其改写为tool_use语义当stopReason INTERRUPTED时映射为barge_in用户打断其余正常结束映射为complete并继续维护响应转录。这种以响应实际内容为准、覆盖协议层结束信号的策略保证 Agent 的决策循环不会被提前切断。同一路径上的其他模型适配层也遵循类似的 stop reason 语义例如 strands-py/src/strands/experimental/bidi/models/google.py 在正常结束回合时上报stop_reasoncomplete。4.3 stop reason 在下游如何被消费在事件循环层strands-py/src/strands/experimental/bidi/agent/loop.py 会依据stop_reason分派逻辑用户打断barge_in、事件自然结束event.stop_reason、模型出错/不完整error/incomplete约 L605-L695在遥测层strands-py/src/strands/experimental/bidi/_telemetry.py约 L103-L120将stop_reason映射为 OTel 语义约定属性gen_ai.response.finish_reason使工具调用导致回合结束这一行为在监控数据中可被清晰检索在转录层strands-py/src/strands/experimental/bidi/io/transcript.py 通过stop_reason barge_in识别并记录打断事件。修复后当流式响应包含工具调用块时你会在遥测中看到gen_ai.response.finish_reasontool_use而非错误的end_turnAgent 也会正常进入工具执行阶段。五、升级验证清单与影响范围5.1 兼容性说明v1.32.0 的三条变更breaking均为false不涉及公共 API 破坏升级路径平滑。但请注意以下行为差异OTel 指标event_loop_cycle_duration等周期指标的完整性提升监控告警规则可以开始依赖end_time/duration字段依赖解析Mistral 用户需要满足mistralai2.0.0,3.0.0若当前解析结果超出该区间请在升级前调整bidi 流式流式工具调用的回合结束语义更准确依赖旧提前结束行为的自定义逻辑如有需要同步审视。5.2 建议的验证步骤升级后运行 SDK 自带遥测测试与事件循环测试确认指标埋点路径无回归strands-py/tests/strands/telemetry/test_telemetry.py执行pip install strands-agents[mistral] --dry-run或pip index versions mistralai核对依赖区间若使用 bidi 能力构造一个流式响应含工具调用的用例检查事件循环最终 stop reason 是否为tool_use并在 OTel 后端确认gen_ai.response.finish_reason取值。六、结语v1.32.0 是 strands-agents Python SDK 在可观测性、依赖治理与流式语义三个维度的一次集中打磨OTel 周期指标从此具备完整的时间维度Mistral 依赖版本得到明确锚定双向流式场景下的工具调用回合不再被错误的end_turn信号提前终结。对于正在生产环境运行 Agent harness 的团队这是一个值得平滑升级的稳定版本对于想深入了解事件循环指标链路与 bidi 流式实现的开发者本文给出的源码路径metrics.py、event_loop.py、bedrock.py可作为继续阅读的入口。赞分享人工智能大模型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-agents Python SDK v0.1.1 版本解读Bedrock 请求标识、LlamaAPI 文档与发布流程strands agents Python SDK v0.1.1 版本解读Bedrock 请求标识、LlamaAPI 文档与发布流程 本文基于仓库内 chan人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务MCP Python SDK 发布流程全解从依赖升级、双发布线管理到 PyPI 发布与回滚MCP Python SDK 发布流程全解从依赖升级、双发布线管理到 PyPI 发布与回滚 本篇技术指南以本仓库根目录的 RELEASE.md https:/人工智能MCP 服务MCP ClientsNode.js 20.20.0 (LTS) 安全发布深度解读CVE 修复、依赖升级与发布流程解析Node.js 20.20.0 LTS 安全发布深度解读CVE 修复、依赖升级与发布流程解析 导读 2026 年 1 月 13 日Node.js 项目正式发前端文档上一篇如何在浏览器中实现专业的Web扫码功能Html5-QRCode完整指南下一篇redis-py 集群模式完全指南RedisCluster 连接、命令路由、Multi-key 与只读模式实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考