strands TypeScript SDK v0.1.6 变更解读：task-augmented MCP 工具支持与运行时 Model 导出-育师

人工智能
大模型
AI Agent
Agent 框架
多智能体
工具调用
MCP 服务

【免费下载链接】harness-sdk

Build 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

点击查看免费下载

本文基于开源仓库 harness-sdk 中 TypeScript SDK 的 v0.1.6 发布记录，深度解读该版本的两项核心能力：为 MCP 工具引入 task-augmented（任务增强）执行配置，以及将Model从类型导出升级为运行时值导出。读完本文，你将理解TasksConfig的轮询参数设计、task-augmented 执行在 SDK 中的演进状态，以及值导出Model对运行时类型判断与扩展带来的实际价值，同时掌握该版本围绕工程基建所做的一揽子改进。

版本概览：v0.1.6 改了什么

v0.1.6 发布于 2026-01-21，是 strands TypeScript SDK（@strands-agents/sdk）早期版本中的一个功能迭代版本。从发布记录看，该版本包含 1 项面向 MCP 集成能力的特性（feature）与 5 项工程类改进（other），全部为非破坏性变更（breaking: false），现有用户升级不会遭遇 API 兼容性断裂。

变更类型	涉及领域	内容摘要	对应 PR
feat	mcp	新增 task-augmented MCP 工具支持	#357
other	—	测试覆盖多个 Node 版本	#353
other	—	更新 production-minor 依赖组（3 项）	#405
other	agent	新增 PR review agent	#409
other	—	更新 production-minor 依赖组（2 项）	#410
other	—	使用 devtools strands 命令	#408
other	—	将`Model`从类型导出改为值导出	#387

其中#357（task-augmented MCP tools）由新贡献者 LucaButBoring 提交，#353与#387分别由新贡献者 SumiyaE、mangelino 提交，三者共同构成该版本的三位首次贡献者阵容。

核心特性：task-augmented MCP 工具支持

PR #357 为 SDK 的 MCP 客户端引入了task-augmented（任务增强）工具执行支持，这是 v0.1.6 最具技术分量的变更。它解决的是 MCP 工具调用场景下的一个现实问题：当某个 MCP server 上的工具需要长时间执行（例如触发一个异步任务、等待外部系统完成计算）时，简单的同步callTool难以优雅地表达"创建任务—轮询进度—等待完成"的完整生命周期。task-augmented 执行正是为此设计的执行模式。

TasksConfig：任务增强执行的配置入口

在当前仓库源码中，这一特性以TasksConfig接口的形式保留在 strands-ts/src/mcp/client.ts，并通过McpClientOptions.tasksConfig字段挂载到客户端配置上：

/** * Configuration for MCP task-augmented tool execution. */ export interface TasksConfig { /** Time-to-live in milliseconds for task polling. */ ttl?: number /** Maximum time in milliseconds to wait for task completion during polling. */ pollTimeout?: number }

TasksConfig包含两个核心参数，语义清晰：

ttl（任务存活时间）：任务轮询的生命周期上限，单位毫秒。用于限定一个任务在轮询体系中存续的最大时长，超时的任务将被视为失效；
pollTimeout（轮询超时）：等待任务完成的最大时间，单位毫秒。即客户端在任务轮询阶段愿意阻塞等待的最长时间，超过该阈值即放弃等待。

两者分别从"任务本身的生命周期"与"单次等待的上限"两个维度约束任务执行的边界，防止长时间运行的任务拖垮 Agent 的调用流程。

默认值与常量定义

同一文件中还保留了 task 轮询相关的默认常量，直接对应上述配置项的默认语义：

/** Default TTL for task polling in milliseconds (60 seconds). */ public static readonly DEFAULT_TTL = 60000 /** Default poll timeout for task completion in milliseconds (5 minutes). */ public static readonly DEFAULT_POLL_TIMEOUT = 300000

默认TTL 为 60 秒（60000ms）；
默认轮询超时为 5 分钟（300000ms）。

McpClient构造函数会在收到tasksConfig时将其保存（见 client.ts 的this._tasksConfig = args.tasksConfig），为后续的 task 执行流程提供配置上下文。

声明式配置入口：McpServerConfig.tasksConfig

task-augmented 配置不仅支持编程方式传入，还能以声明式形式写在 MCP server 配置中。在 strands-ts/src/mcp/config.ts 中，McpServerConfig同样提供了tasksConfig字段，允许在配置文件或配置对象里为某个 MCP server 条目直接声明任务增强执行参数，与command/url、prefix、toolFilters等既有配置项并列。这意味着一份 MCP server 配置文件可以在加载阶段就把任务增强策略固化下来，无需在业务代码中二次装配。

当前仓库中的演进状态：临时不可用（重要提示）

需要特别说明的是，在当前仓库代码中，task-augmented 执行正处于临时不可用状态：SDK 团队正在基于 MCP tasks 扩展（protocol extension）重建任务支持（对应 harness-sdk issue #1659），因此在重建完成前：

构造告警：当McpClient以tasksConfig构造时，构造函数会通过 logger 输出警告，明确提示"tasksConfig is set but task-augmented execution is temporarily unavailable"，并告知后续callTool将抛出异常（见 client.ts）；
调用抛错：callTool方法在检测到_tasksConfig存在时直接抛出错误，错误信息包含"Unset tasksConfig to call tools now"的处置建议（见 client.ts）；
常量闲置：DEFAULT_TTL与DEFAULT_POLL_TIMEOUT的文档注释中明确标注"Unused while task support is rebuilt"（见 client.ts）。

也就是说，v0.1.6 引入了 task-augmented MCP tools 的设计与配置模型（TasksConfig、TTL/轮询超时语义、声明式配置入口），而当前主干代码正处于将该能力迁移到官方 MCP tasks 扩展的过渡期。如果你当前直接使用最新源码，请不要设置tasksConfig，否则所有 MCP 工具调用都会抛错；未设置时，callTool走常规路径：先惰性连接、校验参数为 JSON 对象、注入 OpenTelemetry 追踪上下文，再以服务端工具名直接调用（见 client.ts）。

运行时能力增强：Model 从类型导出升级为值导出

v0.1.6 的另一项值得关注的变更是 PR #387：将Model从类型导出（type export）改为值导出（value export）。

源码层面的实现证据

在当前仓库中，Model是定义于 strands-ts/src/models/model.ts 的抽象基类：

export abstract class Model<T extends BaseModelConfig = BaseModelConfig> { abstract updateConfig(modelConfig: T): void abstract getConfig(): T get modelId(): string | undefined { return this.getConfig().modelId } get stateful(): boolean { return false } abstract stream(messages: Message[], options?: StreamOptions): AsyncIterable<ModelStreamEvent> async countTokens(messages: Message[], options?: CountTokensOptions): Promise<number> { return estimateTokensHeuristic(messages, options) } // ... }

而在 SDK 的统一入口 strands-ts/src/index.ts 中，它以值导出的形式对外暴露：

export { Model } from './models/model.js'

值导出带来什么

从 TS 语义看，"值导出"意味着Model不再仅仅是编译期类型，而是作为运行时真实存在的类对象被导出。从源码结构可以推断，这一变化带来的实际收益包括：

instanceof运行时判断：第三方代码可以基于Model抽象类对任意 model provider 实例做运行时类型归属判断，例如provider instanceof Model，这在类型擦除后的 JavaScript 运行时依然成立；
类扩展与装饰：作为值导出的类可以在运行时被extends继承、被装饰器包装或被工厂函数实例化，为模型路由（如 strands-ts/src/models/routing/router.ts 的ModelRouter）等需要以类为单位的插件机制提供运行时入口；
跨模块一致性：统一从入口重新导出，使import { Model } from '@strands-agents/sdk'既能用于类型标注，也能用于运行时逻辑，避免"类型只能编译期用"的割裂体验。

需要强调的是，这是一个非破坏性变更：对于只把Model当作类型使用的既有代码，升级后行为完全不变；新增的运行时能力属于纯增量收益。

工程基建改进：多版本测试、PR review Agent 与依赖治理

v0.1.6 的其余变更集中在工程流程与依赖治理，同样值得了解：

多 Node 版本测试（#353）

PR #353 将测试矩阵扩展到多个 Node 版本。对于 SDK 类库而言，这是保证跨运行时兼容性的基础投入——不同 Node 大版本在异步 I/O、fetch、Web Streams 等 API 上的行为差异，很可能影响 MCP streamable-http 传输与 Agent 流式输出的实际表现。多版本 CI 测试能提前暴露这类兼容性问题，也解释了为何该版本后续可以放心地合并依赖升级。

PR review Agent（#409）

PR #409 为仓库引入了一个PR review agent。这是"用 Agent 构建 Agent 基础设施"的实践：SDK 团队使用自家（strands）能力构建自动化代码评审流程，对提交的 Pull Request 进行审查。从仓库定位看，这与本项目"生产级 AI Agent SDK"的自我演进定位一致，也侧面验证了 Agent harness 在真实工程流程中的可用性。

依赖治理与开发工具链（#405、#410、#408）

#405 与 #410：两次production-minor依赖组批量升级，分别包含 3 项与 2 项更新。production-minor语义化分组表明这些升级仅包含 minor/patch 级别、不影响主版本 API 的依赖变更，属于常规依赖维护；
#408：将开发流程切换到devtools strands命令，统一了开发工具链的入口，属于内部工程效率优化。

新贡献者阵容

v0.1.6 迎来了三位新贡献者，他们的贡献领域恰好覆盖了本版本的三个技术方向：

LucaButBoring：提交 #357，实现 task-augmented MCP tools 特性；
SumiyaE：提交 #353，建立多 Node 版本测试矩阵；
mangelino：提交 #387，完成Model的值导出改造。

升级与使用建议

综合以上分析，针对 v0.1.6 及当前主干代码，给出三条实操建议：

暂不启用tasksConfig：由于 task 支持正基于 MCP tasks 扩展重建（#1659），当前设置tasksConfig会导致callTool抛错。若你的代码依赖 task-augmented 执行，请持续关注后续版本对该扩展的落地；普通 MCP 工具调用不受影响，可直接使用loadServers或手工构造McpClient接入。
利用Model值导出做运行时逻辑：升级后可以放心地在运行时使用instanceof Model、扩展Model基类或将其作为值传递，用于模型路由、provider 分类与装饰器场景；纯类型用法无需任何改动。
跟随依赖升级：本版本的依赖升级均为 production-minor 级别，风险低，建议常规节奏跟进，以保持在多 Node 版本测试矩阵覆盖下的兼容性基线。